Beyond Responsive Web Design

Responsive Web Design (RWD) has really come into its own since 2010. This is due in large part to the explosion of mobile devices, notably smartphones and tablets, into the marketplace over the past couple years. But even the best and brightest minds in the field recognize that responsive is only part of the answer.

Let’s take a step back for a moment ask ourselves, “Why do we want to use responsive in the first place?” Because we want to reach as many people on as many devices as possible. Right? We don’t want to loose out on opportunities because our visitors don’t use a specific device or have the latest and greatest browser. Right?

Ultimately this goal is really about putting our content (products) in front of the greatest number of potential customers. To do that our content will need to meet them where ever they are, on what ever device they use and to do that will require us to look beyond simple responsive web design.

 

Where Responsive Starts and Ends

RWD is defined by three things – media queries, fluid grids and flexible images. Its role is to re-arrange and shuffle elements around to best fit the available space of a given screen size. That’s all responsive was initially conceived to handle and it does it well, but that’s all it does.

RWD really doesn’t take into account things like bandwidth, browser capabilities, interaction methods (pointer, touch, voice), or device capabilities. It has limited native capability when it comes to adapting content an no capability to optimize resources for different devices.

 

Where Responsive Ends, Adaptive Begins

Adaptive design is a cousin of RWD if you will. One these cousins goes by the name of RESS. Back in Sept. of 2011,Luke Wroblewski wrote an article about combining Responsive Design + Server Side Components​ (RESS for short) to serve up adaptive, device optimized content upon request. The goal being to never send more then necessary to a user device and make sure what is sent is ideally suited for that devices capabilities. It’s like caller-id for web pages.​​

How it works: A device calls to the server to see a page, the server identifies the device through the use of a Device Description Repository (DDR), the DDR tells the server all the devices capabilities, then the server pulls chunks of code (modules) and assembles (using a template language like Mustache), then sends, the adapted, optimized content back to the device. It’s like caller-id for web pages.

When we combine responsive with adaptation we come even closer to delivering the ideal user experience to each person regardless of how they arrived. This is a challenge that will only continue to grow over time as there seems no end in sight for the ways people will access our content.

 

OMG, it’s Huge!!!

Sending the same image or video used for a desktop design of a site to a smartphone will completely negate any benefit gained through responsive or adaptive design techniques. On the flip side if we send an image optimized for smartphone to a desktop with a 24″ monitor it’s going to look terrible to say the least.

What do we do? How do we optimized our content for every unique screen size? We don’t. The best we can do, and the only way to remain sane, is to define ranges of screen sizes and optimize for them. For example: screens from 320px to 599px get image-small, screens from 600px to 1024px get image-medium and 1025px and up get image-large. You get the idea.

This is at the same time one of the easiest and most troublesome aspects of trying to reach everyone with a single design. There are, at the time of this writing, several techniques to address this problem but all have their drawbacks and limitations. Luckily the W3C is working on it and hopefully we’ll have a standard solution in the not to distant future.

For now the Picturefill.js solution by Scott Jehl is one of the better ways to handle serviing up the most appropriate image for a given device. It mimicks a proposed standard currently under consideration by the W3C and WHATWG​and is a great way to progressively ehnance a website. It’s not perfect but it’s a great start.

 

To What End?

If this seems complicated that’s because it is. No amount of sugar-coating is going to make this any easier to swallow. So why go through all this work? In short, so user have a great experience on any device and engage them in way that fulfills business goals.

Each of these progressive enhancement techniques, responsive, adaptation and optimization, build on the other to accomplish our ultimate goal of reaching the largest audience regardless of where they are or what they’re using to view our content. Each one removes an obstacle from the users path to completing their goals. In the end, helping users complete their goals is good for business.

Responsive + Adaptive + Optimized = Great User Experience

More information and ideas on the subject:

http://www.lukew.com/ff/entry.asp?1509

http://www.slideshare.net/4nd3rsen/ress-responsive-design-server-side-components-10084972

http://www.dmolsen.com/mobile-in-higher-ed/2012/02/21/ress-and-the-evolution-of-responsive-web-design/

http://www.slideshare.net/yiibu/adaptation-why-responsive-design-actually-begins-on-the-server

https://github.com/scottjehl/picturefill​

Published by

Mike Donahue

Just a guy that's passionate about creating useful, usable and desirable experiences for all humans. I love nature and wildlife photography, it's my source of artistic expression and inner peace. I live and play in South Florida with my wife Nikki and our girls (dogs) Layla and Cassidy.

Leave a Reply

Your email address will not be published. Required fields are marked *