Improving Responsive Web Design Part 1 – The Problem

Responsive Web Design (RWD) has seen a tremendous rise in popularity over the past year as designers/developers search for an elegant solution to dealing with the ugly reality of browser fragmentation on the web due to the ever-increasing influx of new mobile devices on the market.

While it seems that much of the industry was hoping that this new approach to web design would be the ‘silver bullet’ we’ve all been searching for, as with all design approaches this one is not without its challenges.

Let’s look at some of the popular Responsive Design sites to better understand the challenges.

Grey Goose

Boston Globe

Starbucks

Red Bull Music Academy

Even though all of these above sites do an excellent job in responding to device dimensions, they are not being responsive to the connection speed, latency, device capabilities and dare I use the word “context”. Serving 1.49MB in case of Red Bull or even 650KB in case of Grey Goose is not an acceptable response size for a mobile user on a 3G connection speed. The richer you make the desktop experience, the greater this additional overhead will be.

So here are the challenges with Responsive Design:

Images

One area of weakness of Responsive Design is related to the handling of images and other media types on a page. Traditional Responsive Design relies on a one-size-fits-all approach where a single image is either scaled up or down to properly size itself for a given viewport.

While at a high-level this may ‘make sense’ it quickly falls apart when you start looking at the details and the resulting websites. Viewports range in size from 320×240 for a low level mobile device upwards to 1920×1080 for a HD1080 display. Obviously sending an image optimized for 1080p display to a mobile device is not a good idea. Likewise sending a mobile sized image to a high definition desktop display and scaling it up is likely to make your designer’s head explode due to the high loss in image fidelity.

Image size concerns aside, there is also the question of image composition itself. Framing an image for a 3” display probably should be done differently than that of a 24” screen. There is a difference in utility that is more than just scaling; it’s about communicating a message.

There are few solutions to overcome flexible media challenge, but each of them come with a drawback.

Device Specific Features

Another area of contention with Responsive Design relates the way you are forced to handle device specific features. In a responsive paradigm all devices have to load the code for the feature whether they can use it or not.

One area where this is becoming a concern is related to leveraging ‘app like’ functionality of new devices such as touch events, accelerometers and gyroscopes. In a responsive website these features are detected on the client using JavaScript and as such the code to deal with these must all be downloaded by the user. Essentially you have just used up some of your consumers limited mobile bandwidth with no gain for the end user – you just slowed down the user experience. This situation will only worsen as new device classes and display contexts like smart TV browsers emerge.

Content Prioritization

Content targeting for a specific device can be problematic when serving the same HTML/CSS/JS to all devices. Once the source order of the page has been set, it can be a challenge to reorder the content or bubble up relevant content for a specific device type. Additionally personalization based on device, user preferences, or user profile can be a lot harder to achieve.

Typically changes in the content from a responsive model involve simple information hiding. I would argue about prioritizing content for a specific device in most of the cases, but there is definitely a need for it on a Mobile device. One good example of this is NFL. When you access the scores section of the site on a Mobile device, the site just displays the current score, but on desktop it shows videos and other content.

The Overall Challenge

I’m sure there are a lot of talented individuals reading this thinking, “Yeah, but I can fix that and make it work…” And I agree, these challenges aren’t wicked problems that have no possible solutions, they are addressable. But the front-end code is already responsible for so much:

• Progressive Enhancements
• Cross-browser Support
• CSS Browser Hacks
• Shims and Fallbacks
• Polyfills
• Vendor Pre-fixes
• Script Loaders
• Conditional Logic
• DOM Manipulation
• Analytics

Addressing all the needs of Responsive Design is going to quickly add a significant amount of code to the HTML, JS and CSS files which have a direct relation to increased code maintenance, increased up-front build times, and increased QA time for regression testing all devices. Obviously this larger code base and added complexity will lead to more bugs and larger overall file sizes of page assets which will ultimately be visible to the end-consumer in the form of a slower site that is not responding in expected ways.

If only there were an alternative… (Stay tuned for the next installment!)

Contributions from: @sashasklar, @JohnnyReading, @mutootum