This post is a description of a modified version of the Less framework by Joni Korpi, which I’m calling Less+. You can download a bundled .zip file with my modifications on the Less+ project page.
The web of today is not always viewed on a computer monitor. There are a big number of devices with different screen resolutions that people use to access the web, and thus websites won’t always be displayed as intended on different devices. For web designers, this is an issue.
Why adaptive web design?
A good example of a UI fail is the local Public transportation company; Ăstgötatrafiken. They have a great website with really cool maps integration etc, but using the website with a cellphone is a massive fail. Instead, they have made an App that they want people to download. I think this is a massive fail. As a user, you don’t think like that. You just pull out your phone from your pocket, and google ’östgötatrafiken’. Then you’ll land on their site, but there nothing will work properly. That creates cranky users.
Another thing that really bothers me is always zooming. This drives me crazy. Me as a user just wants to be supplied with a version of the site that I don’t need to zoom on, and where buttons are nice and big so I can click them with my fingers. Prefferably without zooming.
One popular solution for this is creating websites that recognize the useragent and send the user to a special site. This is cool, but this requires a special page. And, it requires that the useragent actually tells the website that it is a phone (or whatever).
A lot of CMS solutions got readymade solutions for this, but these plugins / modules are not really themed as the ”regular” webpage. Also, they (usually) only support Smartphones, and not other devices such as tablets or future devices.
So, to summarize, here are the pros of using adaptive web design:
- The website actually works well with other devices than the computer
- Apps Schmapps – No app needed!
Different kinds of adaptive design – Fluid-width VS Static-width.
Adaptive web design can be split up in two different kinds of technologies; Fluid-width & Static-width. Fluid width is the one, in my opinion, that show the most promise for the future. The 960.gs framework can be used with a fluid width layout, and that’s great for creating a website that keeps the same proportions in all device resolutions. The Less framework by Joni Korpi however, works a little bit differently. Less uses static width and media-queries to switch between different designs for different popular screen resolutions.
Less covers 4x popular screen types:
- 3-Column view: Small screens (Portrait / 320px, iPhone etc)
- 5-Column view: Small screens (Landscape / 480px, iPhone etc)
- 8-Column view: Medium screens (768px, iPad, Small laptops etc)
- 13-Column view: Big screens (1280px >, Desktop screens, TVs & what not)
This is, in my opinion, a much smarter solution than trying to show the website using the same proportions. Sure, that might be cool for switching between a 768px screen and a huge TV, but for smartphones? I Think not. A solution that WOULD work however, is combining the two technologies. A fluid-width website together with mediaqueries using 2 or 3 of the mentioned media-query calls would work great.
Different mobile browsers also use different screen resolutions. Currently, native browsers often emulate 320px resolutions (like the iPhone), while non-native browsers (I.e. Opera, firefox) report the actual screen resolution. On the HTC Desire HD the Native browser reports 369×546, Firefox 480×800 and Opera Mini 480×764 (The actual screen size is 480×800). Thus, different browsers will show totally different designs. This issue would also be taken care of by using a fluid-width design for the mobile devices.
The only problem about using this kind of design is that it is mostly intended for non-pixel based UI elements. Meaning, this kind of site would look awesome and perform awesome – but only if most UI elements were generated by the browser (or if the designer was clever enough not to put design dependencies on pixel-based items). Sure, this works great for ’for fun projects’, but using this kind of technique for client stuff? Thats tough, especially if you use some lovely CSS3 for your UI elements and most of your clients clients use IE7. Thats a UI fail, because most people won’t see any of the lovely stuff that you see in your Chrome or Safari browser. Thus, objectives are not met, and the client is a bit unhappy. Oh noez! đ
A good example of a site that pulls it off however is the MailChimp UI – they combine pixel based objects with non-pixel based objects in a beautiful fashion that makes my eyes fill up with joy. And oh, and if you are interested in trying MailChimp out, register using this link and give me some MonkeyRewards love <3 so that I can send more newsletters :). And if you speak / read / get off on Swedish, please sign up for my newsletter. It’s Spam-free – promise! And plz, give me all the data on you. I love my data!
Anyway; using a Static-width approach might not be the next-generation thing to do, but its the thing to do for the next couple of years for commercial projects. The only problem with the Less framework is that it, in its original state as published by Joni Korpi, more or less avoids Internet Explorer < 9. For IE, it fails and only shows the 8-column ’default’ design. Sure, that’s good if your interest is in punishing IE users, but it doesn’t work very well explaining to a client that ”IE < 9 users can piss off, web standards rulez!”. And sure, most of us think like that (I know I think like that đ ), but its not a good approach if you are going to use this framework in commercial projects. So, what do we have to do?
Conquering browser incompability (I.e. Internet Explorer)
To understand the enemy, you must think like the enemy. When thinking like Internet Explorer I feel like not supporting any modern web standards, being non-progressive, evil and ugly. This mostly applies to three different topics: Media-queries, CSS3 and HTML5.
Media-queries
The main issue with the Less framework in Joni Korpis version is that it ALWAYS falls back on the 8-col design if using IE < 9. This must be taken care of, because 46% (as of feb 2011, est) of users online use IE < 9. Also, using Jonis inline coding creates a HUGE CSS file. We need to make it work in IE, and we need to minify that stuff. How can this be done? By splitting up the CSS into several documents and using our friend JS, of course.
After splitting up the CSS we simply use the Jquery Media Queries library built by Protofunc. This solution was originally suggested by Richard Shepherd on his blog. This enables IE < 9 to view our beautiful 1280 > design, as long as the user has JS.
If the user uses IE < 9 with JS turned off, we need a fallback. This can be achieved by calling the 8-col version of the site before the media-queries are initiated. In this version I’m using the Jquery Media Queries library version 1.19, since 1.20 seem to malfunction in IE. Our <head> thus looks something like this:
<!-- Global Stylesheets -->
<link rel="stylesheet" href="reset.css" media="screen" />
<link rel="stylesheet" href="fonts.css" media="screen" />
<link rel="stylesheet" href="style.css" media="screen" />
<!-- Fallback if browser does not support media queries + javascript (Read: Internet Explorer < 9) -->
<!--[if lt IE 9]>
<link rel="stylesheet" href="8col.css" media="screen" />
<![endif]-->
<!-- Media Queries / Less -->
<link rel="stylesheet" href="13col.css" media="only screen and (min-width: 1212px)" />
<link rel="stylesheet" href="8col.css" media="only screen and (max-width: 1211px) and (min-width: 768px)" />
<link rel="stylesheet" href="5col.css" media="only screen and (max-width: 767px) and (min-width: 480px)" />
<link rel="stylesheet" href="3col.css" media="only screen and (max-width: 479px)" />
<!-- Jquery -->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>
<script src="js/jquery.mediaqueries1.19.js"></script>However: This makes coding somewhat of a nag, since we get a lot of inheritance issues.
CSS3 & The general CSS-approach
The first thing we need to address is HOW to write CSS successfully. I’m suggesting to have the following in mind when approaching CSS:
- We want to kill any and all inheritance
- We need to establish what UI elements should use graceful degradation
- We need to establish what UI elements should look differently on different devices / resolutions
- Buttons / Navigation for mobile devices
- Fancypants details
- Etc
Inheretance is a big issue, so my approach here has been to start working on the 13-col design and applying the following to pretty much all objects:
display: block;
word-wrap: break-word;
margin: 0px 0px 0px 0px;
padding: 0px 0px 0px 0px;
width: auto;
height: auto;This enables us to later on decide what margin / padding the object should have, and also if it should be displayed at all. The word-wrap is needed, because sometimes humans use fancy words. Those fancy words tend to be a bit long. That can lead to that the browser renders the word ”outside” the screen / container, and that’s just not right. The word-wrap can also successfully be applied in the reset.css document. I then just copy / paste my CSS from the 13-col document (not the <body>, obviously), and then make the modifications needed.
As established previously, IE < 9 and CSS3 does not work properly, so my suggestion is to use CSS2-based UI elements for buttons etc since these are ’Vital’ UI objects, but for some objects objects that is not as vital I use CSS3.
HTML5
I just LOVE HTML5. It makes my HTML look beautiful, and its so easy to understand the relationship between different objects. Best thing ever! Although, the <hgroup> tag is not liked very much by my SEO friends, it is still a beautiful standard and a nice approach to any project. But; IE < 9 doesn’t really like HTML5. To defeat the evilness that is IE most people use JS, and this script is also included as standard in the Less Framework. However, since we are all about backwards compability in this here ’ol project, we can’t rely on JS. Some IT-admins at a lot of BIG companies thinks ”Better safe than sorry” and thus kills JavaScript completely. That’s not cool, because this totally breaks our pretty site using HTML5. That would result in a website pretty much without any CSS, since the only thing IE can recognize is the <body> tag.
What then? Well, we can use HTML 5 ’Light’. That is, using the <head> of HTML5, and then using the HTML5 naming conventions – but using regular <div> containers. <article class=”food”> then translates to <div class=”article food”>. This keeps some of the ’nice and tidy’ feeling in the code, and if if you’d ever feel like it’s just a matter of search and replace in your code and it’s all HTML5 again baby!
The upside to this is that IE < 9 (Minus the JS) accepts it and actually displays the page with CSS. Fallback established!
Tools to aid in the development
A great tool for speeding up development is to use the Less Grid overlay JS by @RnowM. When testing the site, a simple click on ’Show Grid’ displays the grid.
On the Less Framework website there are are a few different resources that could aid in the development, amongst other some Photoshop and Fireworks templates by Ari Palo.
Summary
By modifying the Less framework and adding some JS magic to it we get a very potent framework for developing cross-device websites. You can download a bundled .zip file with my modifications on the Less+ project page.