Six Ways You're Using Responsive Design Wrong
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.
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 CSS3Rob Crowther
Sass and Compass in ActionWynn Netherland, Nathan Weizenbaum, Chris Eppstein, and Brandon Mathis