Chapter 1. Responsive Design: A Quick and Dirty Intro

A couple years ago, Riley had a problem. His business—Riley’s Terrific Turnip Sauce—was exploding and his phone wouldn’t stop ringing with new orders. So Riley did what any ambitious small business owner would do: he took it to the Web. He did a little reading and in a few days’ time had set up an online order form so he could take orders 24-7 without ever talking to anyone. This was an overwhelming success.

Fast-forward to now, however, and Riley’s tried-and-true order form isn’t chugging along like it used to. He’s starting to get complaints about it being hard to use on this customer’s iPad or not loading right on that customer’s smartphone. Riley is once again in a bind and this time he’s stumped, so he comes to you for help.

Lucky for you, you’ve been hearing some shop talk about a thing called responsive design that aims to solve this very problem, but you don’t know what the heck it is.

So, What the Heck Is Responsive Design?

In the context of the Web, responsive web design (RWD) is sort of a technical one-size-fits-all paradigm for websites. “All” in this case refers to all resolutions, meaning anything from a tiny Android phone to a 30-inch desktop monitor.

However, unlike that Velcro hat you won in a contest, one size really does fit all with RWD. Rather than just stretching or squishing to fit into the viewing device or browser window as is done in fluid designs, RWD allows you to actually craft different layouts per resolution so that each size gets a truly tailored experience. All that is done with the same code, and without requiring JavaScript (for the most part).

The idea here is to write CSS that only applies to resolutions in a specific range. That way, we can write code that applies only to phones, code that applies only to tablets, and code that applies only to regular desktop/laptop devices.

In responsive design, each resolution range has what’s called a “breakpoint” at either end. This is the point where one layout or set of styles transtions to another, often based on device width.

For example, there is often a breakpoint between the layout served to smartphone users and that for tablet users, usually somewhere around 768px device width. You’ll often have three breakpoints (smartphone, tablet, and desktop) but you can just as easily have more or less.

A Simple Example

This will make more sense if you look at some code. Like I said, we need a way to make CSS only apply when the site is viewed in a specific resolution, and the way we do that is by using @media queries (referred to as “media queries”).

Media queries can do lots of things, but typically you just want to use them to specify a minimum width, a maximum width, or both. Here’s what they look like:

div.column {
  width: 100px; /* The default, used by desktop browsers. */
}
@media only screen and (max-width: 1024px) {
  div.column {
    width: 20%; /* Override for smaller than desktop browsers (tablets). */
  }
}
@media only screen and (max-width: 767px) {
  div.column {
    width: 100%; /* Override for smaller than tablet browsers (smartphones). */
  }
}

Easy, right? Right!

Stop the Scaling!

That code will work fine in desktop browsers, but if you view it on a smartphone it’ll still be zoomed out like it is on non-responsive sites. What gives?

To fix this, we have to tell smartphones not to default to zoomed out, and instead just show things at the regular size. To do that, we add this little snippet of code to our markup, in the <head> section:

<meta name="viewport" content="width=device-width, initial-scale=1">

Now, when we open up the site in a smartphone, it’ll be correctly zoomed to normal size and we’ll get our beautiful and responsive mobile-friendly styles.

Why Does This Rock?

This is downright life changing for a number of reasons:

  • You don’t have to snoop user agents on the server side to serve different code.
  • You don’t have to do any funky JavaScript interaction that alters things after the page has loaded.
  • Every visitor gets 100% the same code no matter what device they’re using.
  • You can reuse (not duplicate) your default code and just override things where needed.
  • You can get really specific really easily about which CSS applies to which resolution.
  • Built-in browser support for all of the A-level browsers (even in Internet Explorer, starting with version 9).

There are lots of reasons to like RWD, and not very many to dislike it.

Back to Riley

So let’s make Riley’s simple business site responsive. The site’s HTML and default CSS is built for desktop users, so we need to update it to scale down well to tablet visitors and then to smartphone visitors. Luckily, Riley’s site is about as simple as they come, and we can get by with just the viewport tag and this super simple CSS:

@media only screen and (max-width: 767px) {
  div {
    width: 100%;
    float: none;
  }
}

Ta-da! Riley’s site is responsive and the users can rejoice! Right? Well, no. The site doesn’t break on smartphones, and users can read everything without zooming in and out since everything is just a single column that takes up the full width of the screen.

However, maybe there’s more to this picture. In Riley’s case, we started with a site built for desktop users and altered it to work for tablet and smartphone users, but is this the right order to follow? Would it make more sense to start with a site built for mobile users and work our way up? Let’s talk about that.

Mobile First Versus Desktop First

Whenever you’re talking about adapting the user experience to different devices and sizes, you’re eventually going to get into a discussion on whether it’s better to default to the best possible user experience and then dumb things down on devices that don’t support them (i.e., “graceful degradation”) or start with the lowest common denominator and add shiny features in for devices that support them (i.e., “progressive enhancement”).

You might be asking yourself what the difference is, and if so, you’re asking the right question. The difference is subtle, but important.

In graceful degradation, you build the site specifically for users with all the top capabilities and technologies—specifically, desktop users with good, up-to-date browsers. Once that’s done, you then selectively remove highly interactive features such as <canvas> and high-performance features such as animations for devices that can’t handle them and for outdated browsers. You’ll also want to adapt the layout as the screen size gets smaller by removing extraneous sections, resizing images, stacking columns on top of each other rather than beside each other, and so on.

In progressive enhancement, you build the site first for mobile users. This means you make the site for users with touch-based devices and a small screen, so all the functionality you provide or the designs you come up with are specifically designed to look good and work well on smartphones. And then, once that’s done, you can restyle the design for larger resolutions or add in things that touch-based users would have trouble with.

In this book, I push progressive enhancement because it makes mobile the default, and for good reason.

Mobile Web Users Are A Huge Sector and Growing Fast

There are well over a billion mobile web users worldwide, and a good portion of those are mobile-only users (meaning they almost never use a non-mobile web browser), including about 25% of mobile web users in the United States. Mobile apps have been downloaded over 10 billion times and about 85% of all newly purchased phones have web browsers included.[1]

This is obviously a huge market, and also one that is steadily increasing. So the logical reaction is to accommodate them.

All that said, why can’t we default to desktop and still serve mobile users a good experience? Why should mobile be the first target?

The Importance of the First Target

It’s important to target mobile first, because mobile users are quickly becoming the most important demographic for the majority of new websites. Targeting them first ensures that they have the best experience possible.

Think about it logically. If you build a site for desktop users, everything else becomes an afterthought by definition. For example, suppose that your desktop design includes a fancy slideshow, a sweet widescreen layout, or some hover effects. When the time comes to make it work for mobile, you’ll probably just remove that stuff and replace it with the bare minimum. You might cut out the slideshow or just display all of the items at once. You might stack the widescreen layout with each section on top of the next. You might remove whatever section had the hover effects, if they’re not absolutely necessary. In the end, mobile users will probably end up with what is basically the desktop site except with stuff removed or rearranged so that it doesn’t break on mobile.

However, if you build with mobile first in mind, you’re a lot more likely to take advantage of everything mobile has to offer. Maybe you’ll be able to make use of the touchscreen to build a rich touch-based UI. Maybe you’ll use the accelerometer for some interactive feature. Maybe you are just more likely to build an awesome design that looks great on small resolutions than if you were just trimming down a desktop design.

How Mobile First Changes Our Example

Let’s put this in terms of (very very simple) code. The super simple CSS I created for Riley earlier is a desktop-first example, since the default styles are for desktop users and then we override them for tablet and mobile users. Here’s how it looks when you update it to be mobile first:

div.column {
  width: 100%; /* The default, used by mobile browsers. */
}
@media only screen and (min-width: 768px) {
  div.column {
    width: 20%; /* Override for larger than mobile browsers (tablets). */
  }
}
@media only screen and (min-width: 1024px) {
  div.column {
    width: 100px; /* Override for larger than tablet browsers (desktops). */
  }
}

Can you see the difference? It’s all about what gets the default styles, and what gets the overridden styles. Like I said, a subtle difference, but an important one.

Back to Riley (Again)

How could we have altered Riley’s site so that it’s not only responsive, but also follows the mobile-first methodology? Well, it’s a little more complicated given that we were provided with desktop CSS as the default and we need to make mobile CSS the default, thereby providing the desktop CSS in the form of overrides, but as always, it’s possible.

Ideally, we’d want to do a from-scratch design for mobile using the basic style guide and branding from the existing site, and then adapt that to the desktop. That may mean a bit of a desktop redesign, but for good reason (as explained earlier).

Now you’re familiar with the basics of responsive web design in general, but you probably have no idea how to apply it to Drupal. Don’t worry, I didn’t forget—after all, that is the point of this book, right? So let’s see!


[1] Source: mobiThinking’s compendium of 2013 mobile statistics.

Get Responsive Theming for Drupal now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial