Mobile web content adaptation techniques

Introduction

This article will help you pick from amongst the many techniques for building a mobile website. It doesn’t describe how to do it, rather it instead tries to help you to pick the right approach. Before we begin it’s worth clarifying exactly what the goal of the exercise is. Generally speaking, people who are looking to build a mobile site fall into two categories. They’re either:

trying to make an existing website work passably well on mobile devices or,
building a mobile experience from the ground up

These two goals are quite different and tend to result in different approaches and solutions. The former goal tends to boil down to making a site resolution independent such that it works on a reasonably wide range of devices of differing screen sizes, but retaining existing site structure, navigation and use cases. The latter aims to build a mobile web experience that caters for a mobile user’s use cases (whether they’re actually on the move or not) by building a different set of views and interactions with the site.

In order to distinguish between the techniques available this article will use the terms resolution independence and content adaptation respectively. The former refers to making your existing site work more flexibly when faced with different resolutions, the latter means creating a designed-for-mobile experience with all that that entails.

Evolution of content adaptation

For the first decade or so of the mobile web there was a clear distinction between the mobile web and the desktop web, and there was really only one technique available to make content work well across multiple devices: server-side adapation. This means logic in the server that would detect the device in question and make changes to the delivered content to ensure that it worked. In fact, server-side adaptation was usually necessary to make the content work at all—failing to do so would render your content unviewable on many devices. In the last 5 or so years however, things have gotten quite a bit more complex: the capabilities gap between mobile and desktop browsers has now been filled by an array of smartphones of all shapes and sizes and tablets. Even the humble feature phone is inheriting rich browser features as WebKit-based browsers start to show up in lower-end phones. This has led to three outcomes:

There is no longer a clear distinction between mobile and desktop devices—it is now a smooth continuum from the humble Nokia 1100 all the way to full desktop browsers
Now that many devices have rich, capable browsers with good JavaScript support, there are new techniques available for adapting content for these new devices
Some people now question the very need to use content adaptation at all, given that most smartphones can readily display almost any website

This article is designed to serve as a reference that describes many of the content adaptation techniques available, and some of the benefits and issues with each one.

The following table lists the main techniques in use today.

Name	Core principle	Content adapt- ation	Resolution independ- ence	Context Inspec- tion	Performance	Pros	Cons	Device library reqd?	Example	Summary
Responsive design	Serve same HTML to every device. – flexible grid – media queries – flexible images	No	Yes	No	Good, but performance on lower devices limited by sending large resources to all devices, network speed may also be issue.	Good technique for making site less dependent on browser resolution Future-friendly: does not require device database to be maintained.	Inefficient image handling in its basic form Achieves resolution independence only	No	mediaqueri es	Achieves resolution independence but not content adaptation. Inefficient images issue — same image delivered to all devices. Complex to build well.
Mobile-first responsive design	Same as responsive design but defaulting to serve mobile-friendly version	No	Yes	No	Good, but performance on lower devices limited by sending large resources to all devices	Removes image inefficiency issue	Achieves resolution independence only	No	Boston Globe	Only really useful variant of responsive design for building a mobile website
Progressive enhancement	Serve base HTML to device, use JavaScript to build up functionality as far as possible	Yes	Yes	Yes	Not great – client-side logic that implements the build-up logic necessarily takes some time to execute, network speed issues may impact effectiveness.	Full adaptation possible	Building mobile and desktop functionality from single base seems limiting	No	None known, but any site implemented entirely in JQM would be example	Effectively moves adaptation logic to client Often used in conjunction with responsive design
Server-side adaptation	All logic on server, client receives only what is required	Yes	Yes	No	Limited only by server performance	Full adaptation possible Fine-grained controls	Device detection library required (usually commercial)	Yes	Facebook Google, most top internet brands	Standard technique for 10+ years Full content adaptation possible but with cost of having to use server-side library
Hybrid	Use device detection to serve initial device-sensitive HTML payload, use client-side progressive enhancement to build up	Yes	Yes	Yes	Good, with reservations. All clients get initial page quickly but subsequent enhancement may impose delays	Full adaptation possible, but can also utilise client-side knowledge (e.g. config settings, real-time data) to add to experience	Device detection library required Complex	Yes	browser. nokia.com	Probably best of both worlds, but currently very complex to build

This table merits some discussion as it necessarily glosses over some of the complexity and nuances for the sake of brevity. I’ll look at each technique in turn.

Responsive Design

The term responsive design owes most of its current mindshare to Ethan Marcotte who popularised it with his May 2010 article in the influentual A List Apart website and a subsequent book, published in 2011, Responsive Web Design. Ethan outlined a set of design principles and techniques that allow a website to be flexible enough to work well at varying resolutions, including mobile devices. In fact, fluid design has always been a goal of enlightened web developers, but Ethan outlined a concrete set of techniques that are readily implementable by most web designers without requiring new tools, hence the appeal of his solution.

Responsive design, as orginally outlined is based on three core techniques:

A flexible grid—making sure that the underlying page grid scales nicely with screen resolution rather than using fixed pixel dimensions
Flexible images—images that work well within a flexible grid
CSS media queries—using CSS styling tailored to ranges of resolutions or types of device

By using these techniques it is possible to serve a single HTML document to a wide range of devices and expect a reasonable result: with a bit of hackery to support older browsers, sites built using this technique will typically work well on all desktop browsers and most smartphones. You can find many examples at mediaqueri.es.

Note: Jeffrey Zeldman, publisher of Ethan’s book subsequently advised that the term responsive design should be broadened to include any means to achieve the goal, not just the techniques outlined by Marcotte.

The term responsive design is an appropriate label for the technique—it is a set of design principles designed to achieve resolution independence. Unfortunately, responsive design often gets confused with building a “proper” mobile site leading to the unfortunate effect of developers assuming that, because they’ve used responsive design, their site is now mobile-friendly and they’ve “done” their mobile site. Granted, building a responsive site is far better than doing nothing at all, but falls short of a true mobile solution that harnesses the power of mobile.

To be fair, Ethan himself does not advocate this approach for creating a mobile site and quite sensibly suggests that the best approach depends on the project. From his book:

“But most importantly, responsive web design isn’t intended to serve as a replacement for mobile web sites. Responsive design is, I believe, one part design philosophy, one part front-end development strategy. And as a development strategy, it’s meant to be evaluated to see if it meets the needs of the project you’re working on.”

As a means to achieving a mobile website, responsive design (as originally described) suffers from three problems:

Achieves only resolution independence, does not facilitate content adaptation
The techniques outlined are inefficient as seen from the mobile point of view—devices will download full desktop-sized images even if they are not fully visible, or visible at all.
Responsive design does not lend itself well to low-end devices since the same block of HTML is delivered to all devices, large or small. The much vaunted Boston Globe site, a responsive design tour de force, does not work well or at all on popular phones such as the Motorola RAZR or Nokia 6100.
It doesn’t offer a means to utilise real-time data from the mobile device to enhance the mobile experience (nor does it preclude it)

Responsive design is a passable way to achieve resolution independence, and may be sufficient cases where a site has limited use cases, but falls short of a solution for building a made-for-mobile web site.

Mobile-First Responsive Design

Since the publication of Ethan’s article and book a number of people have pointed out that responsive design may make more sense if used in an inverted manner: if you design your site such that the default rendering of a page is mobile-friendly some of the issues with responsive design appear to go away. In particular, the issue with unecessarily large images being downloaded by mobile devices can be solved with this approach. Current best practice with this variant of the technique is to initially serve mobile-friendly images to all devices and then, browser willing, swop them out one by one for desktop-sized images. Scott Jehl from The Filament Group (the group behind the Boston Globe site) has very helpfully made available the script that they use to do this.

A side benefit of mobile-first design is that it can act as a “wedge” to help designers make the case for removing unnecessary clutter that invariably accumulates on desktop sites over the years, since the mobile-first design forces this approach.

Mobile-first responsive design is a compelling update to the original set of techniques, but not without its problems:

Again, it achieves only resolution independence, does not facilitate content adaptation
It requires that the desktop site be redesigned from scratch also, though you could argue that this is a good thing.

In summary, if your goal is to create a mobile website, mobile-first progressive design is the only really useful variant of responsive design, since it is truly able to scale from low-end devices all the way to desktop browsers.

Progressive Enhancement

Progressive enhancement (PE) is a newly popular entrant to the content adaptation space, but first conceived almost a decade ago by Steven Champeon and Nick Finck in their article Inclusive Web Design for the Future, presented at SXSW. The idea behind progressive enhancement is to serve a single base page to every device, with associated JavaScript enhancement logic. If the device is very rudimentary, it will ignore or fail to run the JavaScript and be left with a reasonable low-end experience; if the device is a smartphone or desktop browser the JavaScript code will add functionality progressively to the page, until it is built up to the optimal level for the device in question. In theory there is no upper bound to the richness that can be layered onto the base, and you could scale page richness smoothly from feature phone to desktop browser.

The appeal of PE is obvious: it can cater for the full spectrum of devices—low level devices are well catered for (it is a fail-safe solution); more capable devices are not limited by a lowest-common-denominator experience. PE is the approach used by the just-released jQuery Mobile library, of which dotMobi is a sponsor. In effect, PE moves the logic of content adaptation from the server to the client. This approach has two problems:

The progressive build-up that is at the core of this technique necessarily takes time to execute, and this delay is very much dependent on the device in question, and possibly the network. As an example, certain models of Blackberry support the requisite JavaScript in theory, but in practice run it too slowly to be useful.
Again, as with previous techniques, using a single base HTML file across a number of use-cases feels like a limiting approach.

In practice, the best use for PE techniques is to smooth-over differences in a range of mobile devices, rather than as a comprehensive content adaptation solution.

Server-side Adaptation

Server-side adaptation is a technique that has been in use since the dawn of the mobile web, over twelve years ago. It relies on a device detection library or database installed on the web server (or a remote web service) to detect the device accessing the web site and return its capabilities. This set of capabilities allows the web developer to fine-tune the resulting page to match the device’s capabilities with a very high level of control. Due to the device detection involved, this technique of adapting to the device is sometimes called “browser sniffing”. Despite the claims of its detractors, browser sniffing is extremely reliable and accurate, with good solutions typically reporting in excess of 99.5% accuracy in detecting devices in the wild.

The effectiveness of this technique speaks for itself: it is still by far the most common content adaptation technique and is used by almost every major internet brand that takes its mobile presence seriously, including Google, Facebook, Amazon, Youtube, Ebay and Yahoo. We in dotMobi also use it for our own goMobi service. It is difficult to find a successful mobile website that does not use server-side content adaptation.

Server-side adapation is not without its problems, however. There are two main issues:

It requires the web developer to use a device detection solution which needs to be kept up to date. Most device detection solutions are now commercial.
It doesn’t assist you in utilising real-time information from the browser to help you better serve the context of the user e.g. using GPS coordinates or device orientation to better tailor the information that you serve to the user

The current leader in the device detection industry is DeviceAtlas.

Hybrid Approach

The final technique that I will be examining today is loosely called a hybrid approach, since it combines elements of server-side adaptation and progressive enhancement. In essence, this approach works by delivering an initial page based on server-side adapation principles but then enhances the result by capturing device properties via client-side JavaScript, and using the captured information to fine-tune subsequent pages delivered to the device. This approach was first published by the indomitable Bryan Reiger and Stephanie Rieger who have been meticulously documenting their path through various content adaptation solutions on yiibu.com. Interestingly, the Riegers arrived at this solution having tried variants of almost everything previously described on this page.

The Riegers are using a device detection solution in conjunction with a “tacit database” of properties sourced from the browser itself, using a modernizr-like JavaScipt script. Rather than describe it in full detail here I recommend that you take a look at their presentation: Adaptation: Why responsive design actually begins on the server.

This hybrid approach is probably the best of both worlds—you get the benefits of high-speed server-side adaptation, combined with the ability to fine-tune the results based on properties sourced from the device itself. The user gets an initial page that is well-suited to the device, with no performance overhead, and subsequent visits to pages on the site may improve on this experience. There are two downsides, however:

It is relatively complex to implement, as the Riegers themselves readily admit. This complexity is due to two factors: 1) you need to implement a database to store the browser-sourced properties and, 2) you need to build the JavaScript to extract these properties from the browser and get them into this database.
On first visit, a full round-trip is required between the server and the browser before you get to benefit from the properties sourced from the browser. This delay can be removed on subsequent requests by using cookies.

Summary

Having looked at all of the techniques available, how do you choose between them? Overall, of course, the answer is “it depends”. That said, it is the opinion of this author that any technique based on the premise of using a single HTML document to address all devices is fundamentally flawed for the same reason that most television content is not re-purposed movies, and most websites are not pixel-perfect copies of paper publications. Yes, for some types of websites such as blogs, one can argue that there are limited use cases for interacting with a site, and hence a single set of interactions may suffice across both desktop and mobile uses, but in the more general case this seems like a serious limitation at best, and a lost opportunity at worst. As James Pearce so succinctly said:

“How will client-side feature detection turn a airline’s brochure-ware web site into a mobile electronic check-in service? Progressive enhancement assumes that all users want the same thing, but with jiggled layout.”

Is it really feasible for an airline to use the same basic template for their mobile and desktop sites? What about a weather forecast site? If you really want to deliver a first-class mobile experience, responsive design and progressive enhancement will not work well enough. A quick look at the top Alexa sites confirms this—a true mobile experience needs to tailor the HTML, not just move around pixels and divs so that they fit within the browser window.

In summary, if all you want to do is make sure that your site works on a few high end mobile devices, and you don’t care particularly about catering for the mobile web user, try the responsive design approach, or the mobile-first responsive design. If the use cases for your site are limited this might actually work quite well.

If, on the other hand, you want to deliver a full designed-for-mobile experience or you want to cater for all mobile devices out there and not just smartphones, you don’t really have a choice: server-side adaptation or a hybrid approach is the only solution that will work. There is a reason why essentially all of the top internet brands use this approach.

This advice is based on belief in the new medium: we believe that the mobile web is a new medium, not a shrunken version of an old medium, a super-able medium rather than a disabled medium, a fresh new web rather than an ersatz web. The best and most successful uses of this new medium will be those that treat it as such.