A recurring theme in Web design is whether adaptation for mobile should be carried out server side or client side. In my view, we should separate content adaptation and style adaptation in the same way that we separate content and style more generally.
Some factors to bear in mind:
Bandwidth on mobile is limited compared with desktop. OK, the mobile user might be on wi-fi but equally, they might be on a flaky GPRS connection and paying for every byte. Therefore you should deliver a minimal number of bytes to mobile devices. Sending more than trivial amounts of content to a mobile device and then using CSS display:none is, at best, lazy.
Implication → use server side techniques to adapt the content for mobile.
The device knows how big its viewport is, even if you don't, and you have reasonable control over the viewport anyway. Replicating a pixel-perfect design across multiple browsers is time consuming and almost always unnecessary. I make no claim of graphic design skills, but designs that can allow for at least some difference between browsers are going to be more robust than those that demand very precise measurements.
Implication → use client side techniques to adapt the style for mobile.
The ability that users of smartphones have to zoom in and out of Web pages is a really good way of looking at desktop designs on small devices. It's a hack to get around the enormous number of sites built without any thought for mobile users (and sadly not all such sites are old). Be in no doubt: zooming in and out proves that you're using a really smart device to access a badly engineered site.
Implication → you never have to zoom in or out of a mobile-friendly site.
Using a Device Description Repository (DDR) such as WURFL, Device Atlas or Morfeo, you can determine a lot of information about a user's device. You can find out its screen size, capabilities and so on, and the more common the device used, the more accurate the information will be. But in my view, the most important thing to know is: "is this person on a mobile connection?". A DDR won't tell you that unfortunately. The API that will tell you that very useful information is under development in the W3C Device API WG but it's not here yet. Even when it is finished, it's a client side API so getting that information back to the server is going to take a bit of interaction.
You can, however, get an "almost certainly on mobile so be conservative" signal using a simple 'mobile detection' script. Several have been produced in recent years such as these from Richard Shepherd and Pascal V. On this site I use the one available from Google Code. They all work the same way:
- set up an 'isMobile' variable with a value of logical false;
- look for any of a series of clues that the device is mobile and, if found, set the variable to logical true.
Is it perfect? No, but it's not bad, and if you ensure that your user remains in control, i.e. can override the detection script by forcing either the mobile or desktop 'view,' then it's good enough.
My own Web site here is very simple - hand coded with a bit of PHP-driven templating - so the content I want to deliver to mobile is almost the same as for desktop but there are a couple of areas of difference, the main one of which is image size.
The lazy way to do handle images is to send a really big image to the device and use CSS media queries to define the size you really want it to be and rely on the browser to resize it for you. This is bad.
Really, really bad.
Why? Because resizing images takes processing power - something that is in relatively short supply on mobile. Furthermore, using processor power means that you're also demanding battery power - again, that's a limited resource on mobile. I well remember an early Mobile Web Best Practices when the now sadly late Kimmo Raatikainen made the point that one of the biggest problems faced by mobile device manufacturers was how to dissipate the heat of the processor.
It's not just the processing required to resize the image. If your markup doesn't include the dimensions of an image then the browser initially guesses how much space to leave for it. Once it 'knows' either by looking at the intrinsic size of the image or by a CSS definition (or both), it then has to reflow the page - again, that's another hit of the processor and the battery.
Implication → Image elements should include the dimensions in the markup.
In my next post, I'll show how I do that on this site but, if you know just a little PHP, it's not that hard (try clicking the Desktop/Mobile link, top right of the page).
As the variety of devices continues to grow, the delineation between mobile, tablet, netbook, laptop and desktop is becoming increasingly difficult to judge. Ethan Marcotte's suggestion is Responsive Web Design. Start with the assumption that the screen size is small (i.e. mobile) and design for that. Now, what you would do differently if the screen were a little wider? Say, at least 480 pixels wide? Or 600? Or 800? You can define styles for these different width viewports and invoke new stylesheets at each width using media queries. Again, the way I do this on this site is the subject of a separate post but there's a lot of information about Responsive Web Design online already and you can get a really quick taste for it from my own experiment with adding media queries to the CSS @import rule.
By using server side techniques to adapt the content (the text and the images) you have a high probability of sending appropriate content to the user's device. If your script gets it wrong, the user at least has the chance to override the automatic detection.
Client side Responsive Web Design handles the rest, adapting the layout of the page to match the available viewport.