[caption id="attachment_8294" align="aligncenter" width="618"] Google Web Search Interest: responsive design. Worldwide, Jan 2010 - Jan 2013.[/caption] Responsive design is a phrase within Web development that has come to seem more fashionable than useful, but it does have meaning. We will try to clarify what responsive design is, and the benefits it provides.

The Beginning

In May 2010, inspired by John Allsopp‘s 2000 article “A Dao of Web Design“ and the “responsive architecture” movement in the physical world, Ethan Marcotte wrote an article simply called “Responsive Web Design.” The design and development community took notice and, about six months later, the larger business community did, too. Several in-depth articles came out in late December and early January 2011, which were accompanied by the January 2011 launch of Media Queries, a showcase of responsive designs around the web. In September, the Boston Globe launched their responsive redesign, proving its utility for major web properties. This was followed by other notable redesigns such as Sony, Starbucks, Microsoft, and Time Magazine. Interest in responsive design has only continued to grow.

What is Responsive Design?

So what exactly is responsive design? It is a device-independent design philosophy that says a single Website should make its content available to all users, regardless of the device they choose to access it with. Not only that, but this content should conform to the form factor of the device without being concerned about the exact type of device. This stands in stark contrast to the idea of mobile-only Websites or device-specific “apps.” Responsive design is a direct reaction to what Scott Jensen calls the coming “zombie apocalypse of smart devices.” We are no longer just dealing with Web browsers on desktop or laptop computers, but also phones, tablets, handheld game devices, 4k televisions, and devices we haven’t even imagined yet. If we only look at tablets, for example, they can come in 4, 7, or 10-inch varieties. They can run Android, iOS, or Windows operating systems. They can be standard or high “Retina” resolution. It is not only difficult to develop customized sites or applications for each of these individual devices, it is unsustainable. Responsive design aims to solve this problem by creating a design that can visually adapt one set of content to any device on which it might render—either now or in the future. This is not a single layout, but a way of managing how the layout changes as the content is displayed on any size screen.

Using Responsive Design

There are certainly technical challenges in implementing responsive design. For example, writing page styles so that they break down well or serving optimized images for certain screen resolutions become more difficult when dealing with older Web browsers, though these issues have largely been solved through best practices, functionality shims, and workarounds. Responsive design is, at its core, a design methodology that requires coordination and constant iteration between design and development teams. For many organizations, this requires a wholesale change in their design and development process. This change isn’t necessarily easy or cheap to execute, but for those applications that would be best served by responsive design, we believe that the investment is worth it. A smooth responsive design workflow often requires designers and developers to be working side-by-side, in order to experiment with and tweak layouts. To avoid getting stuck in the same device proliferation trap, we don’t want to set layout breakpoints based on specific device widths, but instead, based on how the design itself appears to naturally break down. Finding these “sweet spots” requires designers and developers to collaborate at a new level. It is similar to the pair programming used by the Extreme Programming agile development methodology. Indeed, this could be considered an agile design methodology. Upstatement’s article “How to Approach a Responsive Design,” written after their experience with the Boston Globe, highlights some of these considerations.

Arguments Against Responsive Design

As with any methodology, there are those who aren’t quite sold. Responsive design is no different. There are several arguments that are often raised against responsive design, but they essentially boil down to two topics: context and performance. Argument 1: Mobile Users Only Want Context-Specific Information A common argument for a mobile-specific web site is that mobile users only want limited information, presumably because they are accessing the Web on a busy Manhattan street corner in the pouring rain. This argument is more common for marketing sites than standalone applications. It indicates a belief that certain parts of a site may be more important to users at certain times than others. Making assumptions about the behavior of your users is dangerous. Surveys from Compete and Google show that people will use their mobile device anywhere and for anything. Google found that “93 percent of smartphone owners use their smartphones while at home,” and “72 percent use their smartphones while consuming other media, with a third while watching TV.” This indicates a user base that is free to browse the web at their leisure. These users are more likely to want the “full” site experience. Published in August 2012, research from Google (PDF) on cross-platform consumer behavior reinforces this point: 90 percent of users use multiple devices sequentially to perform the same task. In many cases, the user sends a link from one device to themselves to be opened on another device. The only way this works is if the same link works on all devices. Responsive design allows this, while multiple device-specific sites often do not. If you have ever been unable to see a desktop link on your mobile device, or vice versa, you may understand the frustration you may spare your users. As with most things on the Web, nothing holds true 100 percent of the time, and we should address each project as a unique case. If your users really do opt for different experiences on mobile and desktop browsers, then analytics will reveal this and a separate mobile site may very well make sense. On the other hand, it may be worth wondering whether your desktop users actually require anything more than the mobile users. That additional content may not have any value for them, either. This is the idea behind the concept of mobile-first design. Argument 2: Shipping an Entire Site to a Mobile Browser is Bad for Performance This is a valid point. Why are we sending all of the assets we would normally send to a desktop site to a mobile device, which may have limited bandwidth or processing power? Presuming that we have analyzed our content, and are serving content that is useful for all users, this argument generally comes down to sending overly-large images, audio, or video to mobile devices. It doesn’t have to be this way. Performance doesn’t matter any less in responsive design than it does in regular design. We need to be careful of how we deliver assets to the customer and should never deliver assets that the user will not see. There are techniques to fix this, and we must implement them as necessary. We also have to consider the reverse. Why send smaller assets to a mobile device that may be on a high-speed connection with a high-resolution screen? What happens when that same user changes location and is now on a reduced bandwidth? The typical ways of handling this with responsive design break down, because they are only concerned with the size of the device. But there are ways to deal with this, as well. We have the ability to do on-the-fly bandwidth detection in order to deliver the best assets for the user at any given time, and it is an option we should strongly consider. Again, we should be careful making context-related assumptions for our users, but asset throttling based on bandwidth may be a good solution.

The Future: Environmental Design

Future browser support of new features in HTML5 will allow us to tailor unique experiences to users depending on the capabilities that exist on whatever device they are using at any given time. Devices will have the ability to recognize idleness, ambient light, proximity to other devices, their physical location, network connection, and battery status, and share that with the Web browser. Using responsive design then frees us to roll out these enhanced experiences to all capable devices as we add them. This is taking full advantage of the idea of progressive enhancement.

Takeaway

For those applications that are best served by presenting all of the same content to users regardless of device, responsive design is the best way we currently have to accomplish it. Responsive design does require a fundamental change in the design/development process for many organizations, but should—in the end—provide a better customer experience. Responsive design does, however, bring its own challenges. We must be even more aware of customer usage, performance and bandwidth considerations, and deal with them in a responsible manner. When we combine responsive design with some of the new HTML5 features that are becoming available to us within mobile and other devices, we have the ability to change the way we present on the web to create a truly unique experience for our users. Better yet, this experience can be built on a maintainable and hopefully future-proof codebase. In this way, we will come ever closer to the ideal of responsive architecture, as presented in the physical world.   Bob Holt is a JavaScript engineer at Bocoup. Bob has a background in economics, finance, non-profit development, finance, and education, all of which he tries to shoehorn into his approach to developing for the open web. In his free time, Bob enjoys music, photography, and watching football in all its forms. Image: Google