First, a little history. Responsive design is the fourth major evolution in web design.
The first generation of web design, circa 1994, was “full screen width because we can’t do any better”. In this era, you had to build sites to be very forgiving of a diverse and primitive browser landscape, one frequently lacking support for even the most basic HTML features. <center> and <h1> were hot stuff! Ironically, it tends to age pretty well, because there’s simply nothing there to age.
The second generation showed up in the late 1990s with table-based design. All of a sudden, you could wrap content in a table, or later, some carefully cantilevered div elements, and have it sit in a fixed-width column in the centre, of the screen. Finally! Some control! Unfortunately, this often led to layouts that were brutally inflexble… comical looking on a big screen, while still forcing people to scroll on small ones.
Since screens kept getting bigger throughout the 2000s, shifting from 800×600 to 1920×1080, people started to notice that older sites adapted poorly and looked funny.– a 640-pixel column in the centre of the screen seems a bit inadequate these days. This brought on the third generation of design mentality: the “liquid layout”. You might specify a few fixed-width elements, but then allow the rest to pour, like a liquid, across the remaining available space of the browser window. This definitely improved compatibility across a broad range of devices, but it had the drawback of being optimized for none of them. Even if you knew that 35% of your audience was usjng, say, an iPhone with a 640-pixel-wide screen, you couldn’t do much to specifically anchor the site to look good in it.
Responsive design attempts to combine the adaptive facilities of “liquid layouts” with the ability to perfect and control you get in a fixed-width design.
In a responsive layout, you typically make extensive use of “design breakpoints”– developing sets of conditions that trigger changes to the design.
For example, a set of breakpoints might be:
- For “desktop-sized” screens bigger than 960 pixels wide, show the menu at the same level as the logo, on the far right.
- On “tablet-sized” screens, 640-960 pixels wide, show the menu below the logo.
- On “phone sized” screens, less than 640 pixels wide, hide the menu entirely and show a button the user presses to display the full menu.
This means that the layout will look sensible and controlled at the screen sizes you’re likely to actualy encounter, but still fall back to a sensibly flowed backup.
Also notice that it can be done without changing the underlying HTML document– just loading different rules from a single stylesheet. Many other approaches to supporting different devices rely on “recognize an iPhone is requesting the page and send it custom content.” These are doomed to fail because you can’t reliably detect every possible device that’s going to see your page. They also typically require multiple versions of pages or stylesheets, prone to falling out of synch.
While it all sounds very compelling, it’s important to recognize that responsive page layouts require a certain degree of forgiveness in design.
A fundamental factor in responsive design is “linearization”. As the screen gets narrower, content that would have been placed side by side ends up stacked. It remains readable, because you can keep a sensible text size, but there are some design conventions that linearize poorly. Consider, for example, a product image stacked behind two blocks of text: when the two blocks can no longer sit side-by-side, how will you display the product image so it still looks good?
Responsive design also often means losing control of height– a design might call for a 640×300 pixel block of text on a desktop screen, but when it’s rewrapped to fit on a mobile device, you’re at 320×600.. This means that backgrounds need to be either scalable or tile-able, so that you don’t end up with gaps or unexpected repetitions.
It’s also important to note there aren’t “automatic right” answers for dealing with images. True scalable image support, like SVG documents, is spotty, and your typical photograph is a non-scalable bitmap anyway. The solutions are either to not scale the image, leaving it an awkward size in some situations, or recognize that scaling may result in a picture that’s blurry or pixelated.
A popular technique to offer some control over this to use a scaling- and boundary combination… for example:
This pattern will leave the image’s size within a range, while still allowing it to adapt somewhat to the size of the screen it’s on. However, you might, instead, want to replace the image with an element containing a background-image– letting you swap the background out for different versions at different breakpoints. This technique is useful if you would rather “crop” the image than scaling it.
There are also promises of soon-to-come HTML improvements, like the <picture> element, that may allow us to go straight to “tell the browser to load a roughly appropriately-sized image, from a list of choices, for the situation”.
Responsive design does, however, provide some very sensible tools to actually respond to different customer *needs*. For example, all those “download our app” buttons may only be visible if you’re within the “mobile device” breakpoints, but plugin-dependent or mouse-pointer-required interactive features magically get hdden.
In order to get the most out of responsive design, it’s worth preparing not just the typical single mockup of a page or template, but several. This allows you to plan out your intended breakpoints, and resolve any potential ambiguity in regards to scaling and linearization choices.