Adaptive vs. responsive design & development

Published
Written by
John Kavanagh

Now incarcerated as almost trivial marketing 'buzz' words, there really are differences between responsive and adaptive design and development techniques, although any modern site should really use both..

Photograph of a laptop and mobile phone on a desk

The terms 'Adaptive web design' (AWD) and 'Responsive web design' (RWD) are both used widely in both design and development circles, and although neither are particularly new concepts, the explosion in mobile and tablet-based internet surfing over the past few years (with nearly 40% of internet traffic coming from mobile phones in 2013 according to research carried out by comScore) means that the drive to ensure new developments are optimized for all devices has never been stronger.

Both approaches stem from the idea that in order to provide the best user experience on various devices you need to treat your design with forethought and make appropriate alterations to the codebase. Whilst Responsive design/development revolves around how content is represented and displayed on-screen (often using break-points to change a appearance of the site based on the screen dimensions on the visiting device), Adaptive design can be thought of as an advancement in Progressive Enhancement: identifying the visiting browser's capabilities and enhancing the application to suit. This has become much more relevant as the CSS3 specifications move forward quickly, fragmenting the browser marketplace with partial, or vendor-specific support.

Naturally the two techniques aren't mutually exclusive; you can (and should) be using both together to optimise a site's performance, but it is equally as important to understand the differences between them to ensure a new development is as future-proof as possible.

Responsive

In a nutshell responsive design is all about the dimensions of the visiting browser's viewport. With a responsive site you can pull the edge of your browser window in and out and watch as the page layout 'responds' fluidly to your movement. One of the big reasons for the complete rebuild of my own personal site was to introduce this. Go ahead and pull the window in and out to see what I mean. I'll wait.

The home page of johnkavanagh.co.uk at various screen widths
Responsive views of the Hubble project in the johnkavanagh.co.uk portfolio

The Responsive approach focuses on layout, hierarchy and creating an optimal reading experience regardless of viewport: the goal being to use CSS media queries (using @media) and fluid elements to create flexible layouts which make best use of the screen real-estate available. The same HTML markup is delivered to every device, only the display is adjusted to the device's screen.

This one-codebase-fits-all approach is a huge advantage in developing responsive sites quickly; theoretically it removes the headache of maintaining multiple code versions targetting multiple devices. However in practice using the same code implies that the mobile version of the website loaded on smartphones has the same size and complexity as the desktop version of the site does. This particularly becomes an issue where smartphones - possibly over slower GSM internet connections - have to download and process all of the data for a site regardless of whether it is all relevant to what that particular device is capable of displaying or not. Without careful optimisation and compression of the CSS this can lead to slow-loading and bloated page sizes.

Bloat isn't only confined to the CSS either: I have seen many examples of responsive websites where developers have simply decided to use display: none within media queries to hide large portions of the markup at set viewports: essentially duplicating fragments of the page and show/hiding them. From my own experience this issue most commonly manifests in two totally separate versions of the site navigation (one for desktop and one for mobile), introducing any number of additional problems aside from the obvious duplicate-content and accessibility. This show/hide approach in responsive design or development is wrong and can almost always be avoided with careful consideration both at design and development phases.

Adaptive

In contradiction to responsive development, adaptive development focuses on the user first and the browser second. Although it shares features such as the use of media queries with responsive development, adaptive design uses progressive enhancement to provide features to those devices capable of utilising them without compromising the experience of users who can't make use of those features. The principle being to create a firm (and usable) foundation to a website and then add additional features and enhancements on top of it.

Adaptive Designs decide whether to apply certain CSS classes or not based on the information gathered about the device and browser abilities. Typically using JavaScript library like Modernizr, the site will determine whether the browser recognizes specific features and adapt accordingly: choosing what markup to display and how to display it for the best user experience.

Using Modernizr as an example, the library not only injects feature-specifc class names into the <html> tag to allow you to write feature-dependant/targeted CSS, but also provides a very simple JavaScript API, so finding out if a visitor - for example - supports touch events is as simple as Modernizr.touch. Finding the current page dimensions in the form of media queries is equally as easy allowing you to tailor your functionality to different types of user.

This is particularly relevant given how splintered feature support is becoming as new features in CSS3 are adopted but also leads to a development quandary: part of the skill in adaptive development is knowing where to draw the line in order to balance those extra layers of fine-tuning (and the associated maintenance cost) with real-world usage and value to the user.

I use adaptive techniques in my own site for a number of features, some of them more obvious than others:

  • In my portfolio pages the slider will react to touch events if you visit on a touch-enabled device (although you can also click-drag for a similar effect on conventional keyboard-and-mouse devices). The slider also does not feature arrow buttons if you have touch capability.
  • The back-end of my site detects whether your device is capable of making telephone calls and - if it is - includes tel: links behind telephone numbers throughout the site (particularly on the contact page). It also displays a phone icon top-right in the site header which can be clicked to make a direct call.
  • If you are outside the UK then the phone numbers displayed on the site will automatically include the UK international dialing code (+44).

These are all little features that allow another level of optimisation without compromising use for anyone else; using a tel: link behind telephone numbers for everyone would mean that when non-phone users click on it the site would simply appear broken.

Pros and cons

Both approaches have their advantages and shortfalls, some considerations are:

  • Both rely in-part on media query support which - although now reasonably wide-spread for view sizes - support is far more patchy for things like detecting high-density displays or device orientation.
  • Adaptive design relies either on less-than-reliable 'device-sniffing' via the back-end to determine device capabilities, or else the use of JavaScript which means heavier page loads and the need to accommodate those users who opt to surf the 'net with JavaScript disabled.
  • Adaptive design can allow for bigger variations between mobile and desktop views, but at the expense of development time and maintenance: it takes longer to build and it takes longer to maintain.
  • Both techniques work well for simple-functioning sites but are more complex to implement where you have particularly large pages or complex requirements. There is risk of a snowball effect where large projects become interlinked and unwieldy, making them difficult to maintain in team environments.
  • Percieved limitations can lead to less interesting designs, although this relates much more to individual taste and the capability of your front-end developer!

So which one is right?

There is no right or wrong option here, the most important thing to remember is that the two are not mutually exclusive: both fall under the strategy of giving the user the best possible experience regardless of their device capabilities, and that's something that every web developer should be striving towards.

Comments powered by Disqus
Top