Responsive design

Everything we engineer is responsive, by default.

What 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

Adaptive or Fluid?

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.

Traditional layouts

Pre-responsive there were three layout options:

Fixed

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

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

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.

Responsive layouts

We now have two models that replace these:

Adaptive

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 320 or 480 (iPhone), and 768 or 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

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.

Workflow and approach

Responsive design is hard and is challenging our normal workflow. Let's get a couple of process ideals out of the way.

Mobile first. Really?

We don't practice mobile-first development. We might sometimes design mobile-first, using small screens as a lens to focus on what's important, but the reality is that we still build desktop-first. While we still support browsers that don't support media queries, we should not require JavaScript to serve CSS.

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.

Designing in the browser. Really?

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.

Browser and device support

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.

Common patterns

The following are some common patterns you should use.

Viewport meta

<meta name="viewport" content="initial-scale=1.0">

Breakpoints and tweakpoints

Susy is our go-to grid framework when using Sass. We also use elementQuery for component-level tweakpoints. Measurements in px are preferred over cryptic decimal ems.

DOM manipulation

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.

Images

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.

Icons

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.