Choosing device sizes to support for your responsive designs
Don’t.
The problem isn’t anything to do with devices, pixel counts, or screen sizes. The problem is an inappropriate approach to designing in this medium. If you’re still using that approach don’t worry, it’s not your fault. We’ve all been guilty of it for a long time.
Designers have always (well, almost always) begun their design process by setting limitations to work inside. The size of the screen. At first it was 640px, then we all jumped to 800, then 1024, and so-on. It’s always been a bad approach because there is no such thing as a standard size for desktop, a standard size for mobile, or an acceptable compromise for any of them. Setting ourselves limits and designing inward from them has been working well enough until recently because up until recently the variation in device sizes wasn’t huge. Today there are simply too many bits of hardware out there that have so many different screen sizes, and even the ones that do have the same screen size often have different viewport sizes. We can’t design for some imaginary standard number of pixels anymore. We have no idea what size canvas people are viewing our stuff on.
What do we do then?
We start in the browser - sorry, if you’re used to comping up in Photoshop first that’s not going to help overly much these days. It’s great for look and feel - incredibly important in fact because designing purely in the browser tends to produce boring predictable type-based designs. But forget trying to craft a complete PSD and then translate it into a website. That isn’t going to work well either. We need to be designing visuals as we build. The two can no longer be separated into differing stages, the one now informs the other.
- Start with the smallest layout.
- Use liquid layouts only, no fixed width units anywhere.
- Stay with that layout and increase the browser width. When it looks funky, that’s your new breakpoint. Add a media-query and get designing from there up.
- Repeat the last step until there’s no bigger monitor in your possession.
Resources
If that’s left you with as many questions as when you started, you’ll do well to have a read of the following resources:
- Mobile First from A Book Apart.
- Mobile First an article from Net Magazine
- Adaptive Web Design a small book by Aaron Gustafson
- Responsive Web Design a small book by Ethan Marcotte
Good luck, and have fun!
Entry Information
- Posted:
- Sun, 8th Jan 2012 at 17:01 UTC
- Filed under:
- Tags:
Comments
skip to comment formI do agree with most of this post, however this point is bugging me a little:
«Use liquid layouts only, no fixed width units anywhere.»
For the smallest layouts, make them liquid. It is perfecly fine to use fixed width layouts smaller than your known, larger layouts. Make them in steps. It's OK. No worries.
While it's possible and you'll get away with it better, it's not an approach I'd recommend - especially if you're using liquid at the start and your designs build on top of each-other as they scale up. Why switch methodology just because the numbers got bigger?
As with Bjorn, I agree on the overall premise, but I would say that "no fixed widths at all" falls into the "shades of grey" category.
May not be a comfortable method for others, or suitable for every project, but just seems to work for me.
There could be instances where some elements on page are required but just won't work at the lowest res.
It may then be better to set a min-width on the element and accept that users may need to do some horizontal scrolling at a designated break-point.
I also don't feel it is necessary to go smallest first, as media queries can let you treat each resolution break-point as an entirely different layout - or even visual design - should the designer wish / spec allow.
My process is usually 1) Styling for what will be the most universally "used" resolution bracket, so to speak - based on research / type of site / stats etc. 2) Remove any rules specific for that and place in the relevant media query set, leaving "universal" styling as the foundation / starting point for other resolutions.
^ Especially useful for when clients are pushing to see something. So universal and "majority user" considerations, then everything else and the kitchen sink
I reckon break-points based on "looking funky" is spot on. Let the content dictate. Especially when we consider the billions of resolution variations we are now faced with. Is crazy.
@Kev
There are always shades of grey, but I stand by the idea of going liquid first as a highest preference. As you say, there may well be cases where breaking that rule is advisable, but I'd suggest those are rare.
Smallest first has numerous benefits. It ensures that smaller devices load the least resources, which stops them from exhausting their memory and keeps performance up. If you start at the top and write CSS over-rides to replace/remove styles you can often find the device will download all of the resources even though it will only apply the final "smallest" one.
Careful authoring of your CSS media queries allows you to do entirely different designs with no shared CSS, but it's rare that'd be advisable - if you're having an entirely different layout and design chances are you're trying to solve a different problem which means chances are good the content should be different too.
When you say "start in the browser" are you saying design in code before Photoshop?
*I'm new at this. Don't hate.
Great post — I love the focus and elegance of your approach, rather than getting caught up in assuming that tons of breakpoints are needed to design for everything properly.
But I also think that for larger displays, switching to some form of fixed-width does add value. Otherwise line lengths grow too much and impair readability. Though limiting line length by scaling text size could also solve this problem. Just saying that line length is an issue, and fixing width is one way to solve that issue on larger displays.
@Huda
Yep, unreadable or uncomfortable line-lengths are good indications for where to add break points for a new media query. You could either adopt a new layout or you could adjust the text size and leading.. I do both on http://adaptive-images.com - resize your browser and check how the layout and the font-size for the gallery text changes 
lol, no worries!
It's because you can't simulate how the site behaves in a liquid layout with a fixed width visual in Photoshop. It tends to be easier to get the real content for the page done in mark-up, shrink your browser down as low as you intend to support, and doing basic layout in code. Re-scale until you find the breaking point of the layout and you then know the range of sizes your graphics will need to allow for in that particular design bracket. So, you may need to support 320px wide up to 460px in one layout before you jump to another layout (for which you'll need to do some more graphics).
@Kristofer
Thanks
I dont agree with this post.
The biggest problem with media queries is that mobile device load the extra code, images etc.
Even if we use the "Smallest first" technique we cannot be sure that mobile device don't load extra resources either this must be server side solution.
For normal mobile version now, and at least the next couple of years, we need to create a separate versions.
@exessqd_ru
It seems you've misunderstood how Progressive Enhancement and mobile first work. Going mobile first and using progressive enhancement does exactly what you want - it doesn’t load assets that can’t be used. For example, if your device doesn’t have a resolution higher than 400px wide it never even requests the stylesheets that are for higher resolutions. Never loads the stylesheets, never loads their linked assets. That's the point.
I suggest you either read up on the links posted above or have a look at http://adaptive-images.com and deconstruct the code if you learn better that way.
Nice tips. It's good to wean people off tunnel vision when it comes to web design. Your technique is concrete and simple, should help people get started.
That is pretty smart. I have to admit, starting up browser first instead of photoshop was not something I expected when I read "What do we do?, haha. Your strategy makes perfect sense also, kudos Matt. Shared on G+!