Designing for Breakpoints

By Stephen Hay from

A note from the editors: We’re pleased to present an excerpt from Chapter 7 of Responsive Design Workflow, Stephen Hay’s new book, available now from New Riders.

Figure 7.6
Figure 7.6: Most websites need very few major breakpoints.

Jeremy Keith notes that what happens between the breakpoints is just as important as the breakpoints themselves—perhaps even more so. While I agree with this, we do have to start somewhere. In a way, this part of the process reminds me of storyboarding, or creating animation keyframes, with the in-between frames being developed later. We’re going to do that here.

Major breakpoints are conditions that, when met, trigger major changes in your design. A major breakpoint might be, for example, where your entire layout must change from two columns to four.

Let’s say you’ve chosen three basic design directions from your thumbnails. Think about what your major breakpoints will look like (Figure 7.6). And here’s the key: try to come up with as few major breakpoints as possible. That might sound crazy, since we’re talking about responsive design. After all, we have media queries, so let’s use about 12 of them, right? No! If a linear layout works for every screen and is appropriate for your particular concept, then there’s no need for different layouts. In that case, simply describe what will happen when the screen gets larger. Will everything generally stay the same, with changes only to font size, line height and margins? If so, sketch those. For these variations, make thumbnails first, explore some options, and then move on to larger, more detailed sketches. Use your breakpoint graph as a guide at first and make sketches according to the breakpoints you’ve estimated on your graph.

When thinking about major breakpoints, remember to think about device classes. If you’re thinking about smartphones, tablets, laptops/desktops, TVs, and game consoles, for example, you’re heading in the right direction. If you’re thinking in terms of brand names and specific operating systems, you’re on the wrong track. The idea is to think in terms of general device classifications and, sometimes, device capabilities. Capabilities are more important when designing web applications, since you should be thinking about what screens will look like both with and without any particular capability.

Rough sketches of major breakpoints can help you determine:

  • Whether or not more major breakpoints are needed
  • Which design choice will be the most labor intensive; you might opt for a design that will better fit within time and budget constraints
  • Whether or not a particular device class has been neglected or needs further consideration
  • What technologies you’ll need to develop the design responsively

Rough sketches are more detailed than thumbnails, but they shouldn’t take a long time to create. In a short period, you should have a sketch of each major breakpoint for each of your chosen designs. This should be enough to decide on one of the designs.

[Full article]

Sensible jumps in responsive image file sizes

Photograph of fish and chips store


Last year, I wrote about the challenges of picking responsive images breakpoints and how I found it a nearly unsolvable problem. It has vexed me since.

But I have a new idea on how we might be able to define responsive image breakpoints that is based on a performance budget.

Before I begin, I should note that a lot of this is a thought experiment. I don’t yet know how practical this approach would be.

Brief refresher on responsive image breakpoints

Without going into all of the details about responsive image breakpoints, the short version is that most people are picking the breakpoints for responsive images based on one of two criteria:

  1. Based on what Scott Jehl referred to as “sensible jumps in file size to match screen dimension and/or density” OR
  2. Simply matching the image breakpoints to the major breakpoints being used for the design.

While the first method is more efficient and will probably result in better image sizes, my suspicion is that defining “sensible jumps in file size” is so nebulous that most web developers are going to choose to do the second, easier option.

That is unless we can find a formula to calculate what constitutes a sensible jump in file size and that’s what got me thinking about performance budgets.

What is a performance budget?

I’m not sure how long the idea of a performance budget has been around, but I first became cognizant of the idea when Steve Souders talked about creating a culture of performance on the Breaking Development podcast.

Tim Kadlec expanded on the idea in a recent blog post. He cites the BBC which determined that “each page to be usable within 10 seconds on a GPRS connection and then based their goals for page weight and request count on that.

So that’s the basic idea. Establish a performance budget and stick to it. If you add a new feature to the page and you go over budget, then you have a three options according to Steve (and transcribed by Tim):

  1. Optimize an existing feature or asset on the page.
  2. Remove an existing feature or asset from the page.
  3. Don’t add the new feature or asset.

What is the performance budget for flexible images?

Let’s apply this idea of a performance budget to responsive design. In particular, let’s treat the idea of flexible images as a feature. Because flexible images are a feature, we need a budget for that feature.

And as long as we’re making up the rules, let’s establish a few more hypotheticals:

  • The page we’re working with has 10 images on it of varying formats and visual content.
  • We haven’t reached our performance budget yet so we don’t have to remove other features, but we still need to make sure that flexible images do not add too much to the page weight.
  • We’ve concluded that flexible images can add up to 200k to the page above what the size of the page would be if we provided fixed width images. We picked 200k because it is ~1 second at HSDPA (recent mobile) speeds. And well, 200k is a nice even number for this thought experiment.
  • Because this page has 10 images on it, each image has a 20k budget for flexible images.

One thing to keep in mind, 200k isn’t the cap for the file size of all ten images combined. Instead, it is the price we’re willing to pay for using flexible images instead of images that are perfectly sized for the size they are used in the page.

[Full article]

Environments for Humans online Responsive Web Design Summit 2013 – Day 3 of 3

Responsive Web Design Summit - Day 3

Responsive Web Design Summit - Day 3I’m attending the Environments for Humans online Responsive Web Design Summit 2013 – Day 3 of 3. I’m summarizing the talks rather than going into detail to avoid infringing on the presenters’ copyrights.

Today’s presentations focus on code. Extremely informative!

Fractal CSS: There Is No Breakpoint, by Ben Callahan

  • Major Approaches
    • Single CSS File
    • Multiple CSS Files (global.css, local.css)
    • Breakpoint Based Partials (base.css, no-mq.css)
    • Module Based Partials (mq.css, no-mq.css or mq.scss, no-mq.scss)
  • Major breakpoints with minor “tweakpoints” inbetween

Responsive Web Design with SASS+Compass, by Sam Richards

  • “The Web is an Inherently Unstable Medium” — Ethan Marcotte
  • Media Queries
    • “Start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT!” — Stephen Hay
  • Fluid Grids using Singularity
    • Symmetric Grids
    • Asymmetric Grids
    • Semantic Grids (HTML, SASS)
    • Responsive Grid Context (SASS)
    • Nested Grid
  • Fluid Media using Toolkit
    • Basic Fluid Media
    • Intrinsic Ratios (SASS, CSS)

Responsive Layouts beyond the Sidebar, by Jen Simmons

  • Previous workflow
    • PSDs as final handoff to client without developer involvement
    • 960 grid – 1 or 2 sidebars – fixed/fluid/responsive
  • Design content structure
    • Blocks vs. chunks
  • Design source order
    • Turn off design styles to make sure your hierarchy is correct and site is accessible
  • Design narrowest layout, then wider and wider layouts
  • Recommendations
    • Learn HTML, CSS, layout CSS
    • Let a framework do the heavy lifting

Navigation in Responsive Web Design by Erick Arbé

  • RWD can be difficult
    • Explaining RWD to clients; the lack of a static design phase; navigation; images; tables; converting old fixed-width sites; what to serve users of old versions of IE; testing time and cost
  • Content strategy
    • Retro-fitting an existing website to become responsive can be difficult, especially one with a large menu
    • Smaller sitemap = easier to build responsive nav
  • Building your responsive navigation
    • Hover vs. Touch; top level menu items; two sets of navigation?; a simple JS function; some easy CSS to implement; position: fixed; mobile first!; using your mobile nav as your desktop nav
  • Navigation patterns and examples
    • Avoid position: fixed; build mobile first; can use mobile nav patterns on desktop
    • Add padding; grid/percentage based; multi-toggle/accordion; footer nav; select nav; off-canvas/page slide; no sub-nav

Rebuilding a university homepage to be “responsive”. Twice. In less than a year. by Erik Runyon

  • Why RWD Matters
  • Our Path to Responsive
  • 2011 Redesign
  • 2012 Redesign
    • 1. Global
      2. Screen
      3. @media queries as needed
      4. Hi-res/retina specific
      5. Print (yes, print)
    • Hiding content is NOT a mobile strategy
  • Responsible Responsive
    • Modem speeds moving to broadband speeds
    • But outside of 3G and Edge areas, speeds are still very slow
    • Web page sizes are getting bigger
    • Conclusion: RWD is not mobile friendly e.g. because all images are downloaded, even ones that aren’t used with mobile
    • But the web is, and RWD CAN be