Skip to main content

Six Ways You're Using Responsive Design Wrong

Posted by manning_pubs on December 19, 2012 at 5:51 PM PST

Six Ways You're Using Responsive Design Wrong

by Matthew Carver, author of The Responsive Web

Staying on the cutting edge of of web design can be tough, and oftentimes you only learn from making mistakes. Making mistakes is sometimes the best way to know that you are breaking new ground. In this article, Matthew Carver, the author of The Responsive Web, gives a few tips that his experience in responsive web design has taught him. He hopes you can learn from his mistakes before making a few of your own.

There's a great chance you're viewing this article on a cellphone or tablet. This is the chief argument in the pro column of responsive web design. As designers and front-end developers advocate for the practice as a means to solve the problems that arise from the browsers' move from the traditional environment to handheld and tablets, responsive web design has come under some sharp criticism. Most critics tend to look to flawed implementations of responsive design and development as indicators that the practice itself is flawed.

Suggesting that, because the philosophy of responsive web design is flawed, it therefore should be abandoned is like suggesting that, because a site built in PHP might have a security flaw, the language itself is flawed. The problem isn't the philosophy or the language; rather, it's the implementation.

It's important to understand that what we call "responsive web design" today is just a way of lumping together a set of practices and theories. Ultimately, the goal is a sort of "one Web" standard in which sites adapt to the users' needs. In my book, currently available in a Manning Early Access (MEAP) format, I outline a path towards this one web philosophy.

There I emphasize that the responsive web is about adaptation; therefore, our approach to building it must adapt. With responsive web design, teams need to work closely together to build a site. Instead of passing off deliverables along the "website assembly line", teams need to iterate and improve upon each other's work.

Figure 1 The responsive web is about recognizing the internet as a cross device platform.

Wireframes, layouts, and development all need to work together to build a site from a mobile-first approach. There is definitely some ebb and flow to this process, and I don't think anyone has yet to completely crack the responsive workflow, so feel free to find the balance that works for your team.

Figure 2 In this new, more agile approach, user experience and development happen iteratively. Deliverables are passed along and reviewed in an iterative cycle.

With this approach, the developer also needs to rethink his toolset. While in the traditional, pixel-perfect, web the emphasis was on recreating the creative asset, in this approach the emphasis is on adaptiveness. Using the standard pixel widths and font sizes won't do anymore. We need something a little more fluid.

By focusing on adaptiveness and giving the site a fluid layout, your site stands to gain:

  • A layout that adapts to variations in screen size technology. If a new web-enabled product hits the market with an uncommon screen size (I'm looking at you, iPhone 5!), then you are already prepared for it.
  • But optimizing for mobile first, you prioritize load times from the beginning of development. Faster sites are always better.
  • Cross-browser layout issues can actually be easier to resolve with fluid CSS.

So, if we are going to try to use the responsive philosophy to alleviate our mobile development woes, then we needs to start using it right. The first step in overcoming is admitting you have a problem, so here are six common mistakes designers make in building responsive sites.

1. The answer to all of life's problems: More CSS

The easiest trap to fall into with responsive web design is bloated CSS. This is a problem I most find myself getting snagged by. CSS bloat is the most common mistake people make and oftentimes the hardest to solve right away.
In an effort to make a site that functions well access all devices, I often find myself adding more and more CSS to handle different scenarios or overwriting styles again and again for various viewports. The problem is made worse by the habit of using a single stylesheet for the entire site, a practice popularized years ago to reduce the amount of HTTP requests made to a server.

One solution is to minimize and compress CSS. This will help reduce the overall file size greatly and can be done either prior to a site launch or on the fly with the YUI Compressor Plugin, if you're using TextMate. If you're like me and use a preprocessor such as Less or Sass, you can have your CSS compressed as you process it.

Another solution I've found for this problem is breaking CSS into two separate files, one for mobile and one for everything else. The mobile styles serve as a style guide when building from a mobile-first perspective and are still used on larger screen, leaving only the layout adjustments to be served in the second file.

2. jQuery plugin overload

This drives me absolutely insane. Does your site need a slideshow? Better use a jQuery plugin! What about that cool animation you saw on that one site? Better get a plugin to emulate that.

JavaScript can be a very dense language and jQuery does a great job of lightening the load for rapid development. Admittedly, I've found it necessary once every blue moon to use a plugin in a time crunch, but there's no substitute for rolling your own jQuery for simple features.

A lot of times that plugin you're using comes with a lot of features you won't use, and, granted, it might be a small file size to begin with, but when you add one on another on another it can get a little out of control.

3. If my website is "squishy" then it's "responsive"

Responsive web design is about much more than just scaling the browser window down and having the site "transform" into a mobile site. It's about making sure your site respects the users preferences, and that can extend beyond just what size device they use and into preferred font sizes and bandwidth limitations. Don't get me wrong, layout is a big part of what makes a responsive site, but the layout is just the tip of the iceberg.

For instance, being truly responsive means serving appropriate images and assets for the device in use. With retina displays recently coming to laptops, high-density images are now of even more importance, but when the user is on a small-screen device, you need to serve an image with a smaller dimension. However, in the case of an iPhone 4 or 5, you'll want to serve an image with increased pixel density as well as a smaller size.

There are also the common issues of positioning and user interface design patterns. Right now, the smartest minds on the web are trying to solve these issues, but, in the meantime, we need to find solutions for the users' immediate needs.

4. Social media buttons everywhere!

Like, tweet, follow, friend, share, and send on literally everything. Some pages offer 10 or 20 opportunities to share on a single page. All those buttons add up, and, after a while, they can really start to cause your load time to drag.

There's nothing wrong with a solid social strategy, but make sure that strategy extends beyond simply throwing a collection of buttons and third-party APIs onto your page. There are ways to cut down on the load burden of these little buttons by using link-based sharing or through asynchronous loading techniques.

5. A breakpoint for every Apple product

There's a big world of mobile devices out there, much bigger than iPhones, iPads, and MacBooks. In the recent months, smartphones and tablets have been released in a variety of sizes with an even more varied set of capabilities. There are no longer the safe breakpoints of 320, 640, 960, and 1024 px.

Since there is such a wide range of screen sizes and shapes on the market now, it's important not to design your site with specific breakpoints in mind. A better strategy is to start with a small-screen design and start expanding it in the browser. Once the layout starts to look awkward, it's time to start considering some tweaks.

6. Too small to touch

When browsing a tablet or a mobile device, you navigate the site with your fingers. On desktop browsers, you use a cursor and a keyboard. This seems like a pretty obvious difference, but one important distinction that's easily overlooked is the size of the input. Apple's design standards recommend a 44 px by 44 px target for anything intended to be tapped.

Finding ways to accomplish this can make designing navigation truly difficult. This is why it's important to establish a solid responsive navigation strategy early. Finding a design pattern and establishing it early in the wire-framing phase of a site build is the best way to avoid the trouble of trying to shoehorn a large top-level navigation into a small screen.


There are a lot of misconceptions inherent to any advancing technology. When designing a responsive site, it's important to keep in mind that a lot of the ways we do things are simply remnants of the way things used to be.
If you are building a website at this moment, it will be trafficked by handheld devices. Building responsive sites can be a difficult task, but it's a necessary one if you want to ensure all of your visitors get the best experience possible.

Here are some other Manning titles you might be interested in:

Hello! HTML5 and CSS3

Hello! HTML5 and CSS3
Rob Crowther

Secrets of the JavaScript Ninja

Secrets of the JavaScript Ninja
John Resig and Bear Bibeault

Sass and Compass in Action

Sass and Compass in Action
Wynn Netherland, Nathan Weizenbaum, Chris Eppstein, and Brandon Mathis

responsive102.png68.35 KB
responsive103.jpg9.17 KB
responsive104.jpg10.76 KB
responsive105.png29.83 KB
responsive101a.png13.29 KB


The images have been modified and made smaller. Thanks for ...

The images have been modified and made smaller. Thanks for your comments! Manning Publications

Much irony here. Visiting this story at work caused my ...

Much irony here.

Visiting this story at work caused my browser to hang and eventually I had to kill the IE process.

At home, on a Mac, it took some 30 seconds to load and was very unresponsive whilst scrolling.

Wanting to make this comment was painful. I gave up waiting for the login page to proceed, instead ironing my shirt and having a cup of coffee instead. I did finally get logged in, but had to navigate back three pages to get to the story, clicked on 'add comment' which then put me back to the top of the page so had to scroll down again.

OK, it's not the fault of the original poster, but ironic nonetheless!

I had to kill my browser, too (Alt+SysRq+F ;) It's probably ...

I had to kill my browser, too (Alt+SysRq+F ;)
It's probably caused by the super-gigantic (9654x5117) PNG images...

I always try got good, relevant and useful information about ...

I always try got good, relevant and useful information about website designing from your new and relevant posts, I am sure your blog will continuously update us.

Thanks to all of you member for sharing your knowledge and ...

Thanks to all of you member for sharing your knowledge and information .