Responsive Web Design - Not The Holy Grail

Responsive Web Design (RWD) is increasingly becoming legacy web designers' answer to solving usability for mobile devices. While responsive design may make sense in some instances, in a majority of cases, it simply doesn't.

 First a quick Wikipedia explanation of Responsive Web Design:

Responsive Web Design indicates that a web site is crafted to use  fluid proportion-based grids, to adapt the layout to the viewing environment, and also use flexible images. As a result, users across a broad range of devices and browsers will have access to a single source of content, laid out so as to be easy to read and navigate with a minimum of resizing, panning, and scrolling.

This sounds great in theory.  A single front end code base to cover all screen sizes: big browser, tablet and smartphone.  This paradigm may work well for content-focused sites (i.e. a marketing campaign landing page or a blog) but it's applicability doesn't extend much beyond that.

Think Tasks Not Content

Most sites aren't made to simply consume content; they provide self-service capabilities, user and social interactions and integrated feedback mechanisms. In these cases RWD patterns fall down. The tasks users expect to complete in the mobile channel will often be decidedly different than in the big browser.  Users are often looking to do a subset of their normal tasks on a mobile device, or a different set of (mobile only) tasks all together.  They will also expect to perform these tasks in a more streamlined manner.  Responsive Web Design may address changes in page layout but it doesn't address significant changes in a site's information architecture, or the workflow a user may follow to perform a particular function.  Take a look at the difference in American Airlines big browser and mobile web layouts for example:

The design of the mobile site (information architecture, features and workflow) are considerably different than the big browser site.  Even the tasks are different (i.e. Mobile Boarding Pass).  RWD only addresses a small part of this equation. Using a RWD pattern in this case would actually require quite a bit more development than managing separate front-end code bases for the two channels.

The Native App Channel

Responsive Web Design patterns also do not effectively address the native app equation.  Whether or not a company is looking to invest in native apps now, eventually they will need to.  If they want to save money, companies need to think about native apps while they are laying down the architecture for their mobile web channel.

The best way to lay the groundwork for native is by building a mobile site that utilizes an ajax-enabled mobile web framework (i.e. JQuery Mobile or Sencha Touch) that integrates with back-end content and services via web services (typically JSON).  Sites that utilize an asynchronous web service interaction model can reuse their mobile web services in the native channel.  This gives you the flexibility to build fully native applications in the future without incurring additional server-side development cost.  This pattern also sets the stage for integration with future human-computer interfaces like augmented reality devices and the internet of things.

There is a place for RWD,  but its functions are limited to content-focused sites. Arguably, even in those cases the cost savings will quickly diminish as the features and user experience of the two different channels inevitably diverge.

Be careful of web designers pedaling legacy web techniques to solve future platform problems. We need to utilize next generation patterns and technologies to take advantage of next generation opportunities.