So, just like many other businesses, we have started implementing Responsive Web Applications at work. In fact, one of the new big projects will be built entirely with this concept. But before I start babbling away, let me give you my two cents of what responsive web design is. The idea is basically this: different users have different needs. A smartphone user has very specific and much more focused needs than that of a tablet or desktop. Responsive web design (RWD, coined by Ethan Marcotte) focuses on a “one size fits all approach.” One web application that can be viewed and optimized for different viewport experiences such as: wide screen TVs, desktop browsers, tablets, and smartphones.
To get a bit more technical, the idea is to have one HTML structure or code base that can be controlled and optimized by the CSS for different devices. It does so very elegantly by only detecting the resolution of the device/viewport. It doesn’t care about the device type or web browser running. So, if a specific resolution is detected, it applies certain presentation rules to optimize the experience for that resolution. In fact, this technique is gaining more ground that it has become an obvious alternative to creating native mobile apps. Ok … enough babbling. If you need more information on responsive web design, I highly suggest reading Ethan Marcotte’s article. Need more information still? Then also read Ethan’s book on the topic. It is simply remarkable.
But just like many other development strategies/approaches, nothing comes without a little bit of pain, mistakes and lessons learned. So, let me summarize some of the early lessons learned from using Responsive Web Design at work while catering for multiple viewports.
Lesson 1: Scale Up … Not Down
Ok, story time … After I finished optimizing a prototype web app for tablets and smartphones at work, it was time to demo progress to the product manager, Bob Robertson. Bob is not just a typical product manager. He has enough technical knowledge to call good developers out on their bullshit. He has very good understanding of usability and UX. Bottom line, he knows enough to be dangerous. But anyway, I digress. As I was showing Bob the web application, I said: “Notice as I resize my browser window how the modules scale down and optimize for the lower resolution so that …” And that’s when Bob interrupted me and said: “We don’t want it to scale down … We want it to scale up.” I liked the way Bob put a twist on this. However, I didn’t know exactly why I liked it.
Later during the week when we decided to display things in a slightly different order for mobile, I found myself going back to restructure the HTML. I didn’t like that very much. It was a simple change that affected the maintainability of the code. So, I thought: what would happen if it’s a bigger change? That’s when I really understood why Bob wanted me to take the progressive enhancement approach rather than graceful degradation. It is certainly easier to add components to your current design as you move up. It is the best way to code with change in mind. Additionally, designing at the smallest screen real estate forces you to think about your content. It forces you to assign priority to your content/structure. For instance, the content of most importance to the mobile user will most likely be the main content for tablets/desktops. Consequently, this content get higher priorities.
Now, let’s pause and think for a second … The truth is, if you’re writing a simple blog, either approach, progressive enhancement or graceful degradation, will work for you. However, if you’re writing a web application that’s complex in terms of interactions, themes, workflows, authentication and personalization, then progressive enhancement is a “must-take approach.” This will prevent you from spending lots of time refactoring your HTML. Why is this so important? Well … it’s not important at all if you’re the sole developer. It is extremely important, however, if you work within a large team with lots of shared HTML snippets, where changing one line of code can affect other workflows and developers.
Lesson 2: Avoid HTML duplication, when possible
Since we’re dealing with only one HTML structure for multiple viewports, sometimes unnecessary markup is rendered while not viewed. And even though the HTML rendered may not account for much, the less HTML rendered, the better the overall performance of the application. As a developer, it’s easy to have temptations to add more HTML to account for differences between viewports. And even though this is acceptable in some cases, it should be looked at as a last resort. To give a quick example, imagine a submit button that has the caption “Submit” on the desktop view. If the requirement is to have a button with an icon for the mobile view, developers might be tempted to add another html component (image), hide it at the desktop view, then show it at the mobile view.
Search page for desktop
Same search page for mobile (at a lower resolution)
Well, you can certainly accomplish the same effect without duplicating the HTML by just adjusting the CSS. In this case, you would include the submit button as usual. Then for the mobile view, you assign a background image to the button while moving the text off the screen. The “text-indent” CSS property is your friend here.
Obviously, that was a very simple example but it demonstrates using the same HTML structure while catering for aesthetic differences through the CSS.
Lesson 3: Handle responsive images with care
Most modern browsers handle image re-sizing quite well. Unfortunately, older versions of Internet Explorer don’t do the same and the quality of the images can suffer significantly when shrunk down. Especially if the image you’re dealing with has lots of text on it. Most likely, you will end up with an ugly, pixelated image. The good news is that there are some scripts out there that can handle this issue quite well in older versions of IE. I’m not going to get into the technical details of what these scripts do exactly. Instead, I have some references at the bottom of this article to some solutions Ethan Marcotte has come up with.
Another point is that it doesn’t always make sense to re-size images down to the mobile view. When shrunk down, images might be a bit too small to be meaningful. In some cases, it may make more sense if the image itself is a “crop-out” of the original image … Yes, another version of the image. But before you get all angry about the multiple HTTP request for both images, Ethan has been collaborating with the Filament group to experiment with mobile-first images that scale up responsively, all while not requesting multiple images. See further readings at the bottom of this article.
Lesson 4: Accept that there is no silver bullet
Remember at the beginning of the article when I said RWD works by only detecting the screen resolution? Well, I lied … Sort of lied anyway. To be clear though, RWD should work by only detecting screen resolutions. But due to the presence of un-elegant browsers such as older versions of IE, you will have to do more than just detecting screen resolutions. Yep … You got it. You will have to check for browser versions in your code. The question is, we’re targeting mobile, so why is IE so important? Simple answer … Windows Mobile browsers are detected as IE7. Yuck! So, if you need to cater for Windows mobile phones, you need to check the browser version.
And the funny thing is that Microsoft already knows that their browser is yucky and not standards-compliant so they support conditional comments in the HTML. These comments are ignored by all other browsers but get picked up by IE.
<!--[if lt IE 9]> <link href="ie8.css" rel="stylesheet" type="text/css"> <![endif]--> <!--[if IEMobile]> <link href="winmobile.css" rel="stylesheet" type="text/css"> <![endif]-->
IEMobile is also detected as IE7. In this case, winmobile.css will be loaded if IE7 or IE mobile is detected, which causes problems. To get around this problem, you have to fall back on another conditional stylesheet that applies to any version less than IE9 (as shown above).
I sort of lied about something else as well … Sorry, but in some cases, you will not only be using CSS. But JavaScript can also come to the rescue when used with CSS. For instance, you may need some fancy interactions at the desktop level but not at the mobile view. These types of interactions typically require a JavaScript library. So you may choose not to load these JavaScript libraries conditionally. But this time, not using conditional comments. You will be using just regular JavaScript conditional logic.
Lesson 5: Team communication
If you’re a one man shop, then you’re the project/product manager, designer, developer and quite possibly, the sole user 
But, unfortunately (or may be fortunately), we don’t all work in this environment. For large scale applications, you often find different teams working together on the same project. Thus, cross-team communication is absolutely necessary. But it doesn’t stop there. You also need to communicate cross-job descriptions. From Product folks to UI/UX designers to developers … all have to be on the same page. Design meetings have to occur cross teams with developers and designers working together. That means being just a web developer is not desirable. You need to be a developer who understands how designers work. Likewise, being just a designer without understanding the basics of the web in general and responsive web design in specific is also dangerous.
Closing thoughts
Browsers have been getting better over the last couple of years. And HTML5/CSS3 are gaining more traction day after day. We’re constantly hearing about big companies ditching native mobile apps for HTML5 alternatives. Some of which are utilizing Responsive Web Design in their implementations. With that in mind, I strongly think that RWD is the way forward. When faced with limited time and resources, RWD just makes a lot more sense than developing a separate mobile site or native mobile app. It is also a great way for developing/desigining for change. For instance, I hate it when I have a widescreen monitor viewing a website that occupies only a small fraction of that, with small text that requires me to zoom in to read comfortably. Developers should adapt to that just as well as they adapt for mobile.
So … Design Responsively.
Further Readings