The abuse and misuse of Responsive Web Design
In the past few years, the web design community has seen the use of media queries in CSS grow exponentially. The ability to change and tweak our designs according to various conditions is a powerful tool that helps bring our content to a wide variety of screen sizes. However, something is going wrong that needs to be brought to light before it becomes a problem too large to manage:
People are starting to design around devices more than they are designing around content.
The first time that I saw RWD in use, was when Jon Hicks redesigned his own website using media queries. Take careful notice of his approach. This was just the beginning of RWD, it was device-agnostic, liquid, and had just the right amount of break points. It was the model for us all to follow.
Lately , there appears to be a movement into creating media query sets that are targeted at very specific screen resolutions, i.e. very specific devices. Sometimes going to extreme measures and creating a vast amount more work than necessary. Consider this website that lists media queries per device: http://nmsdvid.com/snippets/
The problem with the mindset of device-specific design is threefold: 1) Building a site targeted at a batch of modern phones and tablets isn’t very future-proof, 2) It mis-balances the line between design and content, and 3) The media query stack begins to add an unecessary amount of weight to the css.
For example, consider the following workflow:
- Create a list of devices that the website needs to adapt to (typically a half-dozen or more phones and tablets that can be listed as “target devices”).
- Create a list of screen resolutions for each of these devices.
- Craft a media query layout for each of the resolutions listed.
Now, let’s see a very similar workflow, but focused on content:
- Evaluate the line-lengths of the content and image sizes within the design.
- Create a list of browser widths that the content should adapt to.
- Craft a media query layout for each of the widths listed.
Yes, there is certainly overlap in the two workflows above. For example, this doesn’t absolve you from testing on common devices. Nor should you not create a mobile-friendly layout (in fact, mobile is a great place to start your design). The key difference is in learning how to define your content break points in a way that looks good on the phones, tablets, and desktops of today as well as tomorrow. Recognizing that we correct our community mindset right now, rather than 5 years down the road will be critical in helping keep the issue from getting completely out of hand.
Content > Device. Always.
Now that I’ve had a chance to explain my concerns. Let’s go over some solutions, shall we?
First, (realizing that this is going to be difficult for some of you) you need to seriously start thinking about working with liquid layouts. By establishing just a small handful of break-points, you can let the box-model to the hard part by filling in those pixel differences that will cover many similar-sized containers. Yes, designing a liquid site is harder than fixed-width, because that’s not how Photoshop and Fireworks do things, but deal with it; the extra time you spend on it now will quite possibly save your bacon further down the road.
Next, strongly consider font sizes and line-lengths in relation to your browser (be it a phone, tablet, or desktop). The goal should be focused on how balanced your content is, how well it reads, and how easy it is to use whithin those bounds. Feel free to take advantage of min-width and max-width properties to manage the fit of your containers.
Naturally, you are going to face some very difficult and unique challenges as you delve deeper into the world of Responsive Web Design in respect to your own personal work, but staying far away from creating a dozen different fixed-width layouts is going to be your best bet in ensuring that what you produce is as future-proof as possible.