Everything we engineer is responsive, by default.
It means that the default approach we take to content strategy, information architecture, design and engineering is that the same content will be consumed on a variety of devices.
The textbook definition of Responsive Web Design requires a website to use media queries, a fluid grid and flexible images. In reality we now refer to "responsive design" as a website that adapts to the viewing environment.
'Responsive' is not a line item. It's design. Jason Pamental
As when designing components, it's essential that we clarify some terms. Correct people if they are mis-used, because it can lead to big confusion.
Pre-responsive there were three layout options:
Fixed layouts use columns of fixed width, often 960 or 1024px, which don't change when the browser viewport changes. Easiest to design and build, but limited to common desktop resolutions.
Liquid layouts use percentages to maintain proportions as the screen width changes (e.g. one column 25% the other 75%). These are often full-width layouts, but suffer when screen size gets small.
Elastic layouts are similar to liquid, but use base text size, instead of percentages, as the unit of size. This means the layout can stretch as the user increases their text size, retaining line length.
We now have two models that replace these:
Adaptive layouts tend to be a series of fixed-width layouts that are swapped using media queries. Designers often pick common device widths such as
480 (iPhone), and
1024 (iPad). The benefit is that fixed-width design is safe and easy, but the disadvantage that not everyone uses an iPhone or an iPad, and you end up managing many widths for each template.
Fluid-responsive layouts are liquid (proportions maintained using percentages) with media queries to re-adjust the percentages at different screen sizes. This is our preferred method because it allows us to tweak the layout at widths where the content needs adjusting, not adjusting the content to fit a device width.
When a layout re-adjusts at a given device width, for example a side column moves under the main column when no horizontal space is available, we call this a breakpoint. Within these layouts however, components are built to be fluid and will flex until the next breakpoint change. A component itself can be adjusted independently of layout breakpoints. We call these micro adjustments tweakpoints.
Responsive design is hard and is challenging our normal workflow. Let's get a couple of process ideals out of the way.
It's not about mobile first—or just small screen first—it's about content-first. But it happens that thinking about what works for mobile does work for other things as well.
We don't design in the browser, but tend to decide in browser. Use the medium that gets the point across in the most articulate and meaningful way whether it's code, drawing, Photoshop, Illustrator, Omnigraffle, Axure, or oils on canvas. We're aiming for a happy medium between a folder full of PSDs and an art director standing behind you pointing at pixel numbers in Chrome devtools.
The technical requirements for responsive design (media queries) are only satisfied in modern HTML5 browsers. In legacy browsers we stick with fixed width layouts that are well-supported. Real users do not drag to resize their browser width to test if a website is responsive, so we do not cater for this use case.
The following are some common patterns you should use.
<meta name="viewport" content="initial-scale=1.0">
AppendAround is a really simple way to move elements in the DOM based on container visibility. Attach event handlers using delegation so that they remain intact even when the component HTML is removed from the DOM and added to another container.
We don't have a one-size-fits-all solution for responsive images, however we favour BBC-News/Imager.js for its ease of use.
Again, there is no one solution, so we are experimenting with SVGs, icon fonts and 2x-sized spritesheets. Until we drop IE8 support, icon fonts tend to be the best cross-browser solution.