I had someone email me yesterday. The message started with an aggressive sales pitch about how they were a, “hip, fast-moving company in an exciting growth industry” (this is code for “we may not exist this time next year”); they continued on to explain, in great detail, how they were looking for a, “Rockstar, ninja UI designer with serious Web 2.0 experi…”<delete>. I hate buzzwords. I think that makes me hip, actually.

Responsive design is one of those things that is bordering on a buzz word at this point, but when you break it apart it’s actually pretty simple. It boils down to 3 things:

  • Using percentage widths instead of pixel widths in your CSS (a flexible layout – been around for years), so 33% for a column instead of 300px.
  • Using CSS media queries to adjust the layout/typography/design when they get messed up as you shrink the browser window (literally making the browser window smaller).
  • Using a special “viewport” <meta> tag in the <head> of your HTML document to zoom in the body when it’s loaded on a phone.

The design will “respond” to whatever window size the user is viewing your page/site/app at. Your design “responds” so it’s “responsive,” get it? Good, that’s pretty much all there is to it. Obviously, it’s more than slapping that stuff together and calling it a day, but for the purposes of an introduction that’s a good starting point. There are good responsive designs and bad ones, but the development pattern is so new that we still have a ton of room for exploration.

When should you build a responsive design?

The big question, of course, is when to use responsive design vs. another model. Maybe we can shed some light on this.

Do you remember a phone called the Palm Pre? It had an operating system that went by the handle: WebOS. This was the first mobile OS where the apps were built with HTML, CSS and JavaScript. Well, that phone failed miserably (bad hardware), and Palm broken my heart when it was bought out by Hewlett Packard and WebOS was delegate to the software graveyard (I think they’re using it on printers or something now).

Palm came up with a methodology called “build once, deploy everywhere,” which is why WebOS was built on an HTML, CSS, and JavaScript base. They knew that there was a lot of power in having a single codebase for an application no matter where it was being used (or a phone or on the web). This is what initially attracted me to responsive web design (before it was cool, of course).

With traditional mobile Web (bleh, buzzphrase) development you have your main Web presence, and then a separate mobile presence that is targeting towards a specific list of devices. This pattern actually worked fine when we were only interested in the iPhone, but now that there’s a never ending list of devices to target, including a rapidly growing tablet market, it gets harder and harder to get a handle on. In many cases you end up with 3 separate code bases to maintain for the same application. If you’re a university or large company… forget about it. The number of application instances gets completely absurd after each gets split into web – mobile – tablet. Responsive design takes are of this by letting you target screen sizes rather than specific devices. Rather than iPhone, Android, Symbian, Blackberry, etc. We only look at devices with small screens, which takes care of them.

While you can’t throw a blanket over everything and say “it should all be responsive,” you can certainly look at what you’re doing to a design at the phone/small screen level and ask yourself one question: ”What makes this mobile?” If the only answer you have is about the screen size or adjusting the design to fit on a phone you probably have a responsive candidate on your hands.

“Build once, deploy everywhere.” Brilliant.

Resources & Further Reader

If you’re looking to get started with responsive design, here are some places you can start:

Author Tim Wright

More posts from this author

How we work Process

Product Hero Talin Wadsworth