Stop Designing for Devices

Posted

Let’s start off by getting one thing clear, this is a straight up rant. Enjoy my rage fueled comments and feel your emotions start to boil over as you either take personal offense or realize that you completely agree. What has gotten me to this point is the constant stream of crap I see about responsive web design (RWD). We are getting fed article, after article, after article of people preaching RWD as the solution for all of the devices out there.

The truth is that yes, RWD can indeed be that solution but the way we are being told to approach it is all wrong. Let’s take a look at the problem. The original problem we had was that phones were becoming a more realistic interface for browsing the web. The devices were ready for a browsing experience but the sites we design were not. We were fundamentally rooted in the idea of designing for a screen size. From the old days of asking which monitor size is the most popular, to the evolution of the 960/980 pixel grid.

Our initial solution was to serve up mobile-specific sites to mobile-specific devices. These sites would render well on a mobile device where we could assume not just different screen sizes but also different methods of interaction. It didn’t take long to find holes in this solution. The development and more importantly, maintenance, of a mobile site added up to time and resources companies didn’t have. At the same time that this problem was really coming to a head another was starting to emerge.

Just as the mobile browsing experience was starting to get rich we were introduced to the iPad. From there the scene has exploded into hundreds of devices of all shape (not really, they are all rectangles) and size. Clearly maintaining different sites for different devices is downright impossible now and will only continue to get worse. The lesson we have learned from all of this is that it is a bad idea to try and maintain our websites based on existing technology.

The Solution, Yay!

Enter stage left, responsive web design. RWD is the answer to everything, right? Well, no. It’s not. But it is an answer. RWD does give us the power to deliver a website to a range of devices and resolutions while maintaining a single code base, a huge weight lifted off of site maintenance. However, it would seem that we still haven’t tossed that old habit of picking our favorite resolutions to design for. And this is what really drives me crazy about all of these articles that discuss RWD and how to execute it. They pretty much always have the process correct, get your grid going, figure your images out and slap some media queries in there and boom, done (it’s not really this easy).

However, we can’t help but come back to setting up media queries for those old familiar resolutions. 320, 480, 768 pixels, where do these measurements come from? Stop pre-picking your breakpoints based on popular devices. Please, I beg you. If you design your site to work great on the iPad today then you’ll have to go back and fix it tomorrow. It is entirely possible to design a web experience that looks wonderful not just on the devices we have today but on the devices that we will have tomorrow and in the years to come.

How to Really Define Breakpoints

So if we don’t want to use device widths for breakpoints how do we figure out what our breakpoints should be? Well I’m going to tell you.

Look at your damn design you moron.

The mobile-first approach works wonders as an approach for developing a responsive site so start there. The first iteration of your design should work on a resolution of 0 pixels and up, including but not limited to, infinity. Once this is looking great all you’ve got to do is break it. Stretch your design out and at some point you will certainly stop, look at it and say, “hey, this kind of looks like total shit”. First off, you should watch your mouth. Second, you now have your first breakpoint. There is a good chance that this breakpoint doesn’t fall exactly at 320 or 480 pixels. There is an even better chance that you could apply this breakpoint at a range of probably 100 pixels and be just fine, it’s just that easy. This is your process, rinse and repeat.

At the end of the day you’ll have a series of breakpoints built around the process of fixing your site when it starts to look bad. This is why my site has breakpoints of 500, 800, 1000 and 1400 pixels. Because somewhere around those ranges things started to get out of hand and some design changes were called for.

Now my site looks just fine on my phone and it looks just fine on my 24 inch widescreen monitor and everywhere between. I don’t care what resolution the next wave of devices is going to have because my site will probably look just fine on them. When you attach your breakpoints to the specific requirements of the design at hand and ensure that adjustments are made based on the restrictions of your content you can design a site that finally breaks away from a screen.

3 Responses to “Stop Designing for Devices”

  1. GoodBytes

    Good point. I start out mobile first and make sure I use percentage based widths as much as possible, that limits the use of breakpoints to start with, but when I do need breakpoints I’ll stop getting back to those well-known iphone and ipad breakpoints since they’re note that future proof like you mention. Thanks for the tip!

    Reply
  2. Stefan

    Hi Jason,

    You tell us not to design for devices and base the breakpoints on the width of the devices.

    But your approach is basically the same. You look to your design and stretch it till it looks like crap and set your breakpoint.

    When your have a design for a specific resolution (because designing for devices doesn’t excist, you design for a resolution) you do exactly the same. You put your breakpoints on the spots that are needed.

    So is your approach really different? I don’t think so..

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>