To hell with bad devices: Responsive web design and web standards

Lately, I have been thinking a lot about responsive web design, mobile design in general and the argument over web applications vs native apps. Here’s my take.

Rightly or wrongly, I have long been a practitioner of fixed-width layouts. More specifically, em-based layouts. These layouts respond to resizing of text, allowing for consistent line length for readability, even with larger font sizes. The drawback is that resized layouts can result in horizontal scrollbars appearing, and that such designs do not necessarily work well with varying viewport sizes.

While I had looked at fluid layouts, my concern was that at viewport sizes different from the optimal design, the layout tended to get clunky. At small sizes, layout elements got bunched up and very short line lengths made for bad reading of text. Similarly, at very large sizes, line lengths became extreme. And either way, image sizes remained the same, dwarfing smaller screens or becoming isolated on larger screens. So while I understood the reasoning behind fluid layouts, the drawbacks held me back from implementing them. Instead, I would add in a separate stylesheet for handheld devices, which while it did not solve everything, did make improvements, particularly when mobile web traffic was small before smartphones with more capable browsers appeared on the scene.

Ethan Marcotte changed my mind.

In May 2010, he published the article Responsive Web Design on A List Apart. He boldly articulated a new paradigm for the web that married the flexibility of liquid designs with the ability to ensure designs handled various sizes well. Pretty smart: use media queries to establish layout breakpoints where a design can shift to adapt to the viewport size. Also, resize images on the fly so they stay in proportion with the layout as the viewport size shifts.

A few months later, I had the opportunity to see Ethan articulate this new design ethos at An Event Apart. I took a few notes. Ethan impressed me with the zen quality of his talk: the dude is deep.

Responsive web design has been a huge topic over the last year. I even attended a session on responsive web design at Twin Cities Drupal Camp this spring. People all over are trying to figure out how to make responsive web design work for them.

Luckily, Ethan continues to help: he recently released a book, aptly titled Responsive Web Design, through the amazing A Book Apart. I’ve read through the ebook a couple times: I can’t stress how useful it is to view videos that demonstrate the techniques Ethan just explained so eloquently in the text.

I particularly appreciated Ethan’s discussion of how to integrate responsive web design into an actual workflow, based on his recent experience working on a responsive redesign of The Boston Globe. My understanding from reading other’s notes is that this is the focus of his talks at An Event Apart this year.

The other best nugget from the book is the focus on incorporating the mobile first principles Luke Wroblewski has been promoting. I can’t wait to read Luke’s addition to A Book Apart, again the aptly titled Mobile First. Ethan explained many practical techniques to start with a mobile layout and progressively enhance it for larger viewports: this is particularly important with images, since having mobile browsers download desktop-sized images can cause slowdowns.

I could write a detailed review of this wonderful little book, but many others have done so already. So let me just say this: for a quick read, the ideas in this book represent as big a sea change to me as when I first read Jeffrey Zeldman’s Designing with Web Standards.

I remember reading that book about seven years ago and thinking that I won’t do web design the same way anymore. Because of the way he articulated how standards mattered, I was willing to put CSS to work in place of tables to handle the heavy lifting of layout.

I feel the same way now about responsive web design. Designing a fixed layout just doesn’t make sense anymore. The wide variety of viewport sizes from a wide variety of devices means that assuming a baseline screen size of 800 pixels or 1024 pixels just isn’t tenable anymore.

Device-specific design

In trying to get up to speed on best practices for mobile web design, I’ve come to realize there are at least two camps. One seems interested in pursuing responsive web design notions so that one set of content can be repurposed for multiple devices.

Another camp, however, seems very interested in tracking down the huge variety of features for each mobile device or set of mobile devices and delivering modified code and often different content to those various devices. At Twin Cities Drupal Camp, I attended another session on mobile web development that seemed to come at the problem from this perspective.

The arguments for device-specific design revolve around a few factors:

  • Variety of screen sizes
  • Variety of internet connection speeds
  • Variety of browser capabilities to handle aspects of HTML, CSS and JavaScript
  • Variety of contexts implied through the use of a mobile device

Because of the variety of variables at play, some argue for delivering different web experiences based on those factors.

Context

Let’s start with the last factor: context. For example, somebody out and about must only care about certain types of information about a restaurant, so we’ll just deliver that and leave off the rest.

Those are the mobile websites I hate.

I use my iPhone at home while we’re watching TV. So does nearly everyone else. So if I’m at home, why should I get just a subset of the information you have on your regular website? Assumptions about context implied by the use of mobile devices can often be wrong.

At a minimum, this sort of site should have an escape hatch so that users can access the full website. Even that can be annoying, though. Often I have clicked on a link to a news item in Twitter, only to be taken to the home page of a “mobile-optimized site.” It is not optimal if I have to search for the content that the link should have taken me to directly. Usually I just give up: no mobile web views for you!

What about the second and third factors, internet connection speed and browser capabilities? Does this sound familiar to anybody else but me? Those are the exact problems prevalent in the late 90s which the web standards movement worked to address.

Speed

Since then, our home and work internet connection speeds have gotten faster, so our designs have added larger images and big Javascript libraries that can be a big issue for mobile devices. Here’s my prediction: five years from now, mobile browsing speeds will increase to the point where speed will not necessarily be as big a differentiator. And sometimes, it’s not even that big a factor now: I often use my iPhone on wi-fi, which is usually pretty zippy. Device processor speeds will increase: desktop computers may always be faster, but for web browsing purposes, the differences will erode. That said, we live in the here and now, so speed can be an important consideration.

  • Efficient standards-based code is a good remedy for some issues with large file sizes.
  • Do you really need that Javascript library? Load it if you need it. This helps desktop users as well.
  • Think about image sizes: see if there’s a way you can have smaller images hardcoded into your HTML and then use Javascript to load larger images for larger viewports. This does mean that the few desktop users without Javascript might get smaller images than desired or poorly upscaled images.

Browser capabilities

Web standards taught us that using browser sniffing techniques to deliver different code to different browsers is inefficient in so many ways. Is there a bigger difference now between device browsers than there was between desktop browsers in the 90s? If you use progressive enhancement techniques, should it matter?

So all told, I’m just not that convinced that the arguments for device-specific design are compelling enough to devote the time and effort necessary to customize content and code for specific devices.

Responsive vs device-specific design: Workforce considerations

One factor I haven’t heard discussed much is the amount of time necessary for each approach. I know I’m not alone in that I’m a one-person team.

Making a layout flexible and adapting it to handle various viewport size breakpoints: doable.

Understanding the exact details of dozens if not hundreds of devices and customizing output and content for subsets of those devices? Not as doable.

Anything is possible given time and effort, but does the additional time justify whatever marginal improvement there is over a responsive approach?

For me, no.

For a large corporation or agency with sufficient staff and with a sufficient level of expertise, maybe.

I would argue that for small shops and one-person in-house design teams, a responsive approach is the way to go.

The danger of device-specific support

Last year I wrote a post that I think serves as a warning for the path of device-specific support: “We are why IE6 lingers on.”

The gist is that the reason IE6 has hung on so long is because we hacked our CSS to ensure an acceptable appearance in IE6 despite its incorrect handling of numerous aspects of CSS. As much as we cared about web standards, we deviated from those standards to accommodate IE6, and thus, this web deviant was able to thrive. Users of IE6 had no idea something was wrong with IE6, because they never saw the ill effects of having a bad browser.

If the web appeared broken in IE6, Microsoft might have been forced to innovate faster and IT managers might have been quicker to upgrade to a new version of IE.

I worry that the same could happen with device-specific support. If we cater to the incapable browsers, there is little incentive for device manufacturers to implement better browsers or for users to upgrade to better browsers.

The trouble of course is that this is a prisoner’s dilemma. If we all refused to support bad browsers, the web would get better. However, there is a fairly high incentive to ensure that our site does not look broken to somebody with a bad browser, because if our competitor accommodates the bad browser, and we do not, then we look bad.

The key I believe is to let go of pixel perfect support. If we use the same web standards approaches of progressive enhancement while using responsive web design techniques, we should be able to avoid the pitfalls of device-specific support while delivering an acceptable experience to nearly all devices.

What about apps?

I believe another aspect of this discussion is the argument over whether we should create web applications or native apps.

How often have you heard that developing native apps for iOS or Android or the seemingly doomed Blackberry is a betrayal of the principles of the web?

I have an iPhone and an iPad, so from my experience, there are some things for which I like to have apps. Shockingly, I don’t think this makes me a web apostate. Here’s the key, I believe:

Stop thinking of a smartphone as a phone.

Think of it as a small computer that happens to make phone calls. Once you make that shift in thinking, some common arguments don’t make sense anymore. An assertion, for example, that it is an abomination to the web to create native apps rather than web applications: would you really say that nobody should write any software applications for a desktop computer anymore? I love what can be done with HTML, CSS and Javascript, but are those, combined with back-end server processing languages, really the ultimate way to write a computer program? Is Photoshop a terrible program because it isn’t written with HTML?

Would a web application be available to more people? Probably yes.

Of course many software developers want to get paid for their work. iOS in particular has succeeded in creating a viable market for software where people will actually pay to use an app. That has often not been true for web applications (with many fine exceptions).

That said, should everything be an app?

No!

I have often seen politicians announce proudly that they now have an app, and when I go to take a look at it, it’s a repurposing of the content on their website. In that case, a responsive web design for their site would probably be much better.

Where apps are useful is when you have a task that you do repetitively. While you can launch web applications from the home screen of an iOS device just as easily as you can with a native app, how they are handled from that point on differs. Because a web application opens within Safari, it is subject to the whims of how your tabs are used. If you take a break from using the application and browse a bunch of links in Twitter, perhaps your web application will need to be loaded up again, and the state of use is lost. With a native app, you can pretty easily switch back and forth between apps without losing state even with long breaks in between.

The lack of a native app to this point is probably why I don’t use Facebook very much on my iPad.

That there is even an argument about this seems silly to me: the people have already voted. People have downloaded apps billions of times. People like native apps. That doesn’t mean everything can or should be a native app, but the existence of responsive web design techniques does not negate the need or desire for native apps. Both can coexist in peace and harmony.

I also wonder if the same people arguing for web applications instead of native apps are using responsive techniques or if they are creating device-specific support. Because if they are taking the time to cater to the needs of specific devices, how is that really all that different than creating a native app?

Obviously, it’s still different. However, I wonder if sometimes the hype around HTML5 is somewhat reminiscent of how Java was going to be a platform-agnostic savior of web applications. Develop once, publish anywhere, right? The trouble is that as much as we have fought for web standards, the difficulty of handling different devices demonstrates that we have not yet reached nirvana. Writing the same code once does not mean it will automatically work precisely the same everywhere. Somebody said on Twitter recently that in many ways, this means “write once, debug everywhere.”

I have more hope than that. While there are no miracle pills that solve everything, I believe responsive web design is the best path forward to address the challenges of adapting our designs and our content to multiple devices as long as we are willing to let go of pixel perfect precision. In many ways, this is a continuation of the same path that the web standards community has already been walking.

Thank you, Ethan, for leading the way.