Responsive Website Design

By Varun Grover – Software Engineer – Core Center of Excellence, Widgets Team

If you follow Web Design/Development for professional reasons (or just pure passion), it’s likely that you’ve come across “Responsive Web Design.” This writeup is a modest attempt at demystifying Responsive Design, and the typical challenges for its effective implementation.

What is responsive design? And why is it important?

A website is responsive when it (and its included content) can be served contextually, in order that it demonstrate high usability, when users access it from limited-capability devices like mobiles.

According to Ethan Marcotte (who originally came up with the idea) and Smashing Magazine , “it’s not only about adjustable screen resolutions and automatically resizable images, but rather about a whole new way of thinking about design.”

First things first, why should we be concerned about it? Lets go through a few facts to help us gauge the relevance:

  1. Mobile penetration far outnumbers that of conventional desktops/laptops/internet. For reasons of simplicity, I refer to mobiles (not just the latest ones) / tablets (these two are the biggest contributors) / hybrids / gaming devices / smart TVs etc. as ”devices.”
  2. Much of the internet traffic from these devices goes towards consumption of “content” (in addition to regular websites, it includes stuff like videos, maps, m-commerce, etc).
  3. Although the biggest drivers are smartphones and tablets, others are also going to only increase as there are very compelling use-cases around each of these. Since tablets are already nearing critical mass, there is a measurable dip happening in the usage of netbooks and laptops towards conventional browsing. It’s just too convenient to use a tablet for that!

With these in mind, it should be obvious that it’s in our business and technical interests that we make our websites, and their content, friendlier (usable) for consumption across devices (at least for those 20% that contribute to 80% traffic). Watch those bounce rates!

Very Important Note: Responsive design builds on top of Progressive Enhancement. So if you are doing a lot of intrusive scripts or replacing/removing a lot of styles, the thought process is wrong and it is NOT a responsive design.

The 100 feet view of the css strategy – Fluid Grid, Media Query

Considering the wide variety of device view-ports, aspect ratio, and, resolution, we need to stop thinking about pixel perfect layouts . Ditch the fixed grids like 960gs and adopt typographic grid (fluid grid) layouts like fluid960gs. You can read more about fluid grids in this excellent article (again by Ethan Marcotte).

The underlying principle is to use relative units (or no units!) for specifying the structural and typographic dimensions. This allows a very fluid cascade effect originating from the body (or screen) width.

For instance, in the case of fluid 960gs, the width rule on the root container element is something like this:

.container_16
{
width: 92%;
margin-left: 4%;
margin-right: 4%;
}

Design for the most-limited browser among the target devices. Typically these browsers may not support Media Queries – “absence of media query is the first media query”. Here are some examples of Media Queries

<link rel=”stylesheet” type=”text/css” href=”/style.css” media=”screen and (min-width:300px)”>

<style>
@media screen and (orientation:landscape) {
/* one or more rule sets… */
}
</style>

Thumbrule – media query should be used to only enhance; not “replace” styles. This is in alignment with the “mobile first” philosophy, which in a nutshell is:

Mobile Site + @media queries = full desktop site

The fluid grid (and some amount of css) can do the heavy lifting for adapting to the different device sizes. We then do not need to write a huge bunch of media queries for that. Please note that a few media queries are still written for doing major layout adaptations. For instance, we probably want to show a sidebar for related content if the viewport width happens to be more than 720px.

<style>
/*sidebar is not displayed by default.. mobile first! */
#sidebar {
display: none;
}



@media screen and (min-width:720px) {
#sidebar {
display: block;
}
}
</style>

Typically we might need to use some amount of nested media queries. The first level (on the link tag) is for major layout changes; the next level (inside these css files) is for device-specifics. However, be aware that there are always going to be devices with their own quirks and edge cases. So, as much as possible, avoid putting in those workarounds – less is more, keep it simple.

Aside: The future looks very interesting:

http://www.w3.org/TR/css3-layout/
http://www.w3.org/TR/css3-grid-layout/
http://www.w3.org/TR/css3-multicol/
http://www.w3.org/TR/css3-flexbox/

Fluid images

The concept of Fluid Images is originally attributed to Richard Rutter. Its a straightforward css rule (or a set of rules) that prevents images from exceeding the width of the parent container. It’s as simple as this:

<style>
img {
max-width: 100%;
}
</style>

Here is a simple HTML page to test this. Load this up in a browser and resize the browser window width less than the image width:

<html style=”overflow:hidden;”>
<head>
</head>
<body style=”margin: 0px;”>
<img style=”max-width: 100%;” src=”http://www.alistapart.com/d/responsive-web-design/ex/site/f-mycroft.jpg”&gt;
</body>
</html>

Here is another excellent example.

Responsive Images

There is a concept called “responsive images” which goes beyond fluid images. The phrase was first coined by by Scott Jehl. The phrase usage has grown to refer to any technique for loading images at an appropriate size for a responsive design.

The fundamental challenge in achieving truly responsive images (that work natively and do not require javascript / url-rewriting hacks) is that <img> tag does not support contextual / conditional image source selection. Neither is there any way to do this via css – which anyway would not be semantic as <img> tags are used to load image “content” as compared to background images which are used to load decorative/styling images.

If we try to specify multiple <img> tags and conditionally hide them through media queries, the images are still requested.

This does not work (image should not be requested, but it is):

<!doctype html>
<html>
<head>
<style type=”text/css”>
.test {
display: none;
}
</style>
</head>
<body>
<img src=”http://www.alistapart.com/d/responsive-web-design/ex/site/f-mycroft.jpg&#8221; />
</body>
</html>

Neither does something like this (both images are requested):

<!doctype html>
<html lang=”en”>
<head>
<title>Responsive Images using object tag</title>
<style>
object {
display: none;
}
img {
display: none;
}
@media screen and (max-width:499px) {
.default {
display: block;
}
.default > img {
display: inline-block;
}
}
@media screen and (min-width:500px) {
.min500 {
display: block;
}
.min500 > img {
display: inline-block;
}
}
</style>
</head>
<body>
<img src=”http://www.alistapart.com/d/responsive-web-design/ex/site/f-moriarty.jpg&#8221; />
<img src=”http://www.alistapart.com/d/responsive-web-design/ex/site/f-holmes.jpg&#8221; />
</body>
</html>

There are a lot of efforts in the community to help address this problem. Unfortunately almost all of them would use intrusive javascript to achieve it. One of the key efforts (by Filament Group) relies on javascript + cookies + URL rewriting in order to achieve this. This, however, does not seem to be the right approach. Static content needs to be served off CDNs which cannot possess the logic / contextual knowledge to do this. Further, URL rewriting could cause problems with proxies and caches en-route.

Here are a few links to some of the efforts towards responsive images:

Experiment by Filament Group

Article on A List Apart

Following the principle of “Less is more”, it might not be a bad option if we can retain a single image (medium resolution) and use the max-width rule to keep it fluid. If the device happens to be a desktop/laptop, a link to full-size image could be shown. This cannot be done for all the cases, but if its a healthy compromise, it might be worth it.

Aside: Background images used for styling are never a problem as they are completely controlled via CSS and are not downloaded when applies to “hidden” containers. A word of caution – do not rely on background images to be applied on all devices as it is disabled on some of those.

Viewport Meta Tag

Mobile Safari originally introduced the viewport meta tag to let the web authors specify the viewport’s size and scale.

To cite MDN – Mobile browsers like Fennec render pages in a virtual “window” (the viewport), usually wider than the screen, so they don’t need to squeeze every page layout into a tiny window (which would break many non-mobile-optimized sites). Users can pan and zoom to see different areas of the page.

So what all this means is that the initial scale at which the website can be viewed is dynamic as there is not a fixed screen-width to viewport mapping. There is good documentation by Apple around this.

Here is the tag that typically needs to be used:

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

Content Adaptation

While the content should not be coupled to any target platform, the user experience can be optimized for some of these. Devices have their limitations for various types of content. Also older devices may not support XHR, so loading up scripts to attempt a pushState is useless and redundant (even if its progressive). This asks for feature detection and content adaptation. These involve making use of device databases like DeviceAtlas or WURFL, UA strings, and some real-world context information. Client side detection comes way at the end of the request cycle, and hence is not very helpful.

Content adaptation really needs to depend on doing the heavy lifting at the server-side – this would invariably need to use device databases and UA strings (at least at time of session initiation for the purpose of creating profile cookie). Cookies generally become unavoidable in these scenarios. There are problems still unsolved – unknown devices, an ever-changing set of capabilities(and specs!), and no real intelligent defaults.

How do we serve, say, javascript to the device from the CDN. No contextual information with CDN; and we don’t want to serve swfObject as a part of the bundle to iPhones! (Hint: contextual bundles!)

The “less is more” paradigm has never been more important when it comes to web interfaces. No matter how good looking it is, it must not be an impediment to the users who are more interested in consuming the content. We need to get the interface out of the way.

Conclusion

There is a real need for websites to be seamlessly usable across a multitude of devices. Considering the varied state of spec-implementations in the browsers, the flux (and deficiencies?) in the specs, and the ongoing innovations by the dev community, its hard to point a particular strategy, towards achieving this, as the “best” one. Further, one size rarely fits all. However, any strategy that is adopted should need to still align on the fundamental guidelines (that remain as sacrosanct as ever) – Progressive Enhancement, WPO, and Accessibility.

Demo URL

http://vaeroon.github.com/4/

Some References

http://www.alistapart.com/articles/responsive-web-design/

http://www.alistapart.com/articles/fluidgrids/

http://dev.opera.com/articles/view/love-your-devices-adaptive-web-design-with-media-queries-viewport-and-more/

http://zomigi.com/blog/essential-considerations-for-crafting-quality-media-queries/

http://adactio.com/journal/4494/

https://github.com/scottjehl/Respond

http://code.google.com/p/css3-mediaqueries-js/

http://www.alistapart.com/articles/fluid-images/

http://clagnut.com/sandbox/imagetest/

http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/

http://www.cloudfour.com/responsive-imgs/

http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/

https://github.com/filamentgroup/Responsive-Images

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

Appendix

Here are some observations to note:

–  The “:hover” state on iPod touch / iPhone/ iPad seems to be sticky – an element with :hover state does not seem to lose it unless another focusable element on the page receives the focus.

–  The orientation media query does not work on the older iPod touch / iPhone devices. Some references:
–  http://www.1stwebdesigner.com/css/how-to-use-css3-orientation-media-queries/
–  http://www.thecssninja.com/css/iphone-orientation-css
–  http://menacingcloud.com/?c=cssMediaQueries
–  http://stackoverflow.com/questions/8430762/orientation-media-query-css-doesnt-work-on-ipod-w-ios-4-2-1

–  As of date, there is a defect in the iPod touch / iPhone / iPad devices – whenever there is an orientation change from portrait to landscape, the zoom factor of the page seems to change in a manner that causes the content to overflow horizontally. User needs to manually zoom out in order to reset it and view the entire content. Some references:

–  http://stackoverflow.com/questions/2557801/how-do-i-reset-the-scale-zoom-of-a-web-app-on-an-orientation-change-on-the-iphon

–  http://adactio.com/journal/4470/

–  The H5BP folks have launched the Mobile Boilerplate which looks awesome, really!

About collectivegenius
Everyone has a voice and great ideas come from anyone. At Cobalt, we call it the collective genius. When technical depth and passion meets market opportunity, the collective genius is bringing it’s best to the table and our customers win.

2 Responses to Responsive Website Design

  1. I was extremely pleased to find this website.
    I need to to thank you for ones time just for this fantastic
    read!! I definitely savored every little bit of it and i
    also have you book-marked to look at new stuff in your site.

    Like

  2. An intriguing discussion is worth comment. There’s no doubt that
    that you should publish more about this topic, it
    may not be a taboo matter but usually people do not discuss
    such topics. To the next! Cheers!!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: