Blog

Thoughts on Responsive Breakpoints

(I originally wrote 90% of this nearly a month ago before I got busy and forgot to post it, but here it is)

I’ve been debating back and forth about this with a few people about ‘what breakpoints should be’ when building a responsive site, and it looks like this extends into the general web community as a whole. Some people (the folks on the now famous Boston Globe redesign for instance) say to go ahead and set your default breakpoints at common screen widths: 1024, 960, 480, 320 etc (Device based breakpoints). Some people (*cough* Marc Drummond *cough*)  say to just put in a breakpoint when your design starts looking wonky at a certain size (I call this The Awkwardness Approach). Some people suggest other in-between sort of things.

My hard held feeling is that setting all your breakpoints at common device widths is completely counterintuitive to the whole idea of responsive design. It’s a serious case of dragging our feet out of the ‘old way’. If we’re really being device agnostic (or maybe I made that up as being the ‘purpose’ of responsive design), then it’s best to get away from thinking of specific devices as quickly as possible and instead just make something that looks the best it can at any size. Of course that’s easier said than done. But consider the multiplicity of Android devices and the fact that on larger desktop monitors fewer and fewer people are browsing with their browser maximized, and it looks like the widths are going to be somewhat arbitrary anyway.

I also really appreciate the distinction Patrick Grady makes: that breakpoints are not where the design looks best, they’re where the design breaks and needs new rules to come in and rescue it. Not to mention if it’s a popular width, any slight variation in viewport width is more likely to completely rejigger the design.  Grady suggests setting breakpoints at the midpoints between common device sizes (the sizes that would be less likely to be a user’s screen resolution). This makes more sense to me than following device sizes, though it still is tied to the devices themselves.

I don’t really see how the awkwardness approach necessarily creates more media queries or pickiness than using set device-based (or even interdevice-based) ones. If you make a tiny tweak each time something looks a bit iffy, then it it does, but that’s never how I thought it should be done. As you’re squeezing down your window and something starts to look not as good, rather than fixing the single element that’s making things look bad, why not

  • go back a bit so it doesn’t get as close to looking bad
  • generally re-arrange your design, thinking about not just the present width, but what elements are on the verge of becoming a problem as the design shrinks further.

Approaching a design this way might reduce the number of media queries necessary when using a liquid grid (which I understand may be necessary for a design to be responsive, otherwise it is just adaptive? Who knows… this terminology still seems somewhat amorphous).

I should admit that I haven’t had the chance to work on a fully fluid responsive design yet, so this is all pie in the sky theorizing. I think, though, if we really want to cast off the confines we inherited from print design (ie. the notion of paper size) it’s best to design so that sites look good at every size and not spend time thinking about specific devices. That might not be the most practical way to go now, but it seems to me to be where things are going.

One Response to “Thoughts on Responsive Breakpoints”

  1. Zak says:

    In terms of an actual process, I like the idea of mobile-first. I looked into the origins of the term this weekend and found this (now slightly old) blog post by Luke W. (http://www.lukew.com/ff/entry.asp?933)

    As far as planning out your design, I see this process as:

    1. Start with the smallest screen your site will be viewed on and manage all the necessary aspects of your design/relevant content.

    2. Move up a screen dimension and repeat step 1. Rework the design if necessary. If possible/prudent, add some extra features/bells and whistles.

    I haven’t had an opportunity to work through this process yet, but I like the logic behind it.

Leave a Reply