Responsive design is a new name for an old concept. The term responsive used to be applied mainly when talking about a website’s speed (i.e., if a website was fast, it had a good response time). Lately, the term has been co-opted for a different purpose. A responsive website now refers to a website that responds to its viewport. It used to be that web designers had to concern themselves only with a minimum screen resolution of 640 pixels by 480 pixels and a maximum resolution of 1280 by 1024 pixels. Two factors have led to both the floor being dropped and the ceiling being raised. First, the sharp rise in mobile and tablet devices used to access the web has dropped the floor all the way down to 240 by 320 pixels. Second, a sharp increase in screen resolutions coupled with the introduction of widescreen monitors has raised the resolution ceiling to 2560 by 1440 pixels (and possibly even larger than that). How are we expected to produce a website that looks good given such a range of devices?
Why bother?
The first question worth asking is, “Should I even bother?” The very simple answer is that you may not have a choice. A lot of clients these days are asking that their websites work on an iPhone. You can go a couple of ways if that’s the case: build a responsive website, or duplicate your efforts and build two parallel websites for the exact same content.
If that isn’t specified as a requirement, though, how do you decide whether a responsive website makes sense? Begin by putting yourself in your visitor’s shoes. Depending on the type of website you’re working on, it may not be worth the added trouble. Are people going to be accessing this site frequently when they’re on the go? What sort of actions will they need to take?
For certain sites, the decision is obvious: anything that’s related to travel and tourism would likely benefit from a mobile-friendly view. How much do you wish that your favorite restaurant would allow you to view its menu on your cell phone? Maybe it does, and that’s why it’s your favorite!
Here’s another great example: where we live, there can be some really great windstorms in the winter, and the power goes out often. The local power company has a wonderful mobile-friendly (albeit not responsive) website that allows you to view the status of the power outage affecting your area and see when it estimates that it’ll have service restored. During an outage, not many folks will be able to power up their desktop computers and connect to the Internet, so a cell phone is their lifeline to the outside world.
Now that we’ve (hopefully) made the case for building a responsive design, how do we go about taming this beast?
The good news is that, nothing is really different from what we designers have had to deal with since the beginning of the Web. In this case, the technology has just improved and made it easier for us to deal with these variations.
The first step in developing a responsive website (and one that can take place during your early discussions with your client) is determining which device(s) you’re designing for. Will this website benefit from being mobile-phone friendly? The argument can be made that any website benefits from being mobile-friendly. For example, if you have a mobile-friendly shopping site, people will buy when they’re on the go. If you have a mobile-friendly news site, people will read it when they’re commuting to and from work. And if you have a mobile-friendly event-registration website, people will be able to sign up for your event anytime and anyplace!
We might be going overboard here; but honestly, you should think about whether there’s any benefit to making your website iPhone and Android-compatible. Are tourists likely to reference your site while on vacation? It’s far more likely that they’ll be looking for local information using a mobile device than a desktop computer. Also, think about the scenarios where you use a mobile device; does this business/organization/individual’s website fit into one of those scenarios. If you reach an impasse here and just can’t decide, do a quick estimation of how much added time “going responsive” will take and present your client with a dollar figure. How long will it take to recoup that cost based on the perceived benefits of a mobile site?
Using the prior power company example, the financial benefit of a mobile site lies in the savings achieved by not having to have as large a call center answering calls that revolve around, “When will my power be back on?” Instead, folks can access that information themselves online. It’s not hard to appreciate that such a website would pay for itself pretty quickly.
Screen size isn’t the only limitation of a mobile device, however; bandwidth is also a concern. Despite the rapid pace of development in cell phone networks, they do still lag behind the fastest home and business connections available. Compound this with the issue of coverage being inconsistent in all areas, and you could find that some visitors are having to view your website at speeds that are much lower than what you originally planned for (most websites aren’t designed with dial-up Internet access in mind these days).
There are a few really simple things you can do with speed in mind: serve up alternate, smaller images for mobile devices or eliminate some images altogether. But we’re getting ahead of ourselves here!
Making the decision early on in the process makes it easier on you, the developer, to produce a website that will work at a range of resolutions. You can opt to either design from the top down (highest resolution to lowest) or from the bottom up. We would argue that taking the bottom up approach is actually better because you’ve got the largest number of constraints in mind from the start.
Unfortunately, decisions aren’t always made early on. We’re going to continue with our project from the previous chapters; the difference is that now we’ve made the decision to produce a website that works on the following:
- desktop machines
- tablet devices
- mobile phones
We’ve made it this far, so we need to do just a little added legwork. For example, do we have to produce separate style sheets for each device, and do we have to produce separate websites for each device? There’s really good news on this front: by making use of the “cascade” part of Cascading Style Sheets (that we discussed in our chapters on CSS), we can reuse the majority of the style information we’ve already got and override only those parts that we need to (like font sizes and margins).
So, we’re already off to a good start on this front. Thus far, all of our development work has been specified in proportional units (ems and %) instead of fixed units (pixels). This means, in its current form, the Summer Smash 2012 website will scale somewhat. Check out Figure 7-1 to see how we’re currently doing on a 320 by 480 display. It’s definitely legible, but we can do better. Had we used fixed units, things could be way worse though.
Figure 7-1. This is how our website currently looks on a small screen. There’s definitely some room for improvement in our margins and in the sizes of things!
Figure 7-2 shows the same website implemented using fixed widths and pixel sizes for text. Note that we’d have to scroll to the right to see the rest of the site.
Figure 7-2. Things could be far more dire—if we hadn’t used proportional units in our original design, this is what we’d be looking at right now.
We talk a lot about the old days, and we’ll just take one more step back. Detecting specific browsers or devices isn’t a new idea; in fact, during the browser wars of the 90s, it was considered an almost essential survival tool. If you wanted to do anything other than display a simple, table-based page, you were left using JavaScript to sniff out which useragent (i.e., which web browser) was accessing your page.
Useragent sniffing isn’t a foolproof way of operating, though. It’s really easy to spoof a specific useragent, and it actually became common practice because some websites would shut out or deny access to you if you weren’t using their preferred browser (e.g., Internet Explorer or Netscape Navigator). As a result, you just can’t trust the self-reporting that goes on. Think of it this way: you’re familiar with those stickers that say “Hello, my name is” where a person writes in his name. How can you be sure that this person wrote in his real name? And how do you know that the Reillys aren’t impersonating the Parkers (by the way, this can be a really fun thing to do, depending on the situation!).
Thus it would be better to be able to sort things out based on certain characteristics instead of a name. Similarly, it would be better to look for a 480 by 320 screen instead of the following:
Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3
That’s where the @media query comes in; it lets you specify one or more properties of the target device in order to apply one or more rules specifically to that device.
In our case, we’re looking specifically at the screen medium (we can also use media queries to specify print styles). We also want to target specific breakpoints; that is, we want to identify certain resolutions where we’re likely to be transitioning from one device to another. This will enable us to make our site display perfectly on each of the three devices that we’ve identified:
@media screen and (max-width: 520px) {
…
}
This little snippet says that, for any screen with a width up to 520 pixels wide, we need to apply the rules that follow. This rule targets all of our small-scale devices, but not tablets—those devices start at resolutions higher than that.
Let’s jump right in and add a few phone-specific rules to our style sheet:
@media screen and (max-width: 520px){
div#pagewrap {
width: 100 %;
margin: 0;
}
header {
padding: 0.5em;
}
header h1 {
font-size: 1.5em;
}
header p {
font-size: 0.7em;
font-family: Verdana, Arial, sans-serif;
font-weight: bold;
}
}
There are a few tweaks, here. First, the page takes up the entire screen width. There’s no reason to narrow it down and center it on such a small screen, so we’ve set the width to 100 % and removed the margins. We’ve also decreased the padding on the header and shrunk the header text down a bit. At 0.7em, the tagline is a bit difficult to read in the Frijole font-face, so we’ve also changed the font to Verdana (but still made it bold). Our header is looking pretty good now (see Figure 7-3); however, our content still needs some work:
Figure 7-3. We’ve cleaned up the size and padding on our header and made our layout use the entire width of the screen.
section#registration_form {
float: none;
width: 100 %;
}
aside {
float: none;
width: 100 %;
}
We’ve removed the floats here and placed our content in a more linear format. Small screens aren’t too conducive to having multiple columns of text, so we’ve also taken out our sidebar and placed it after our registration form. We’ve got things looking acceptable now, but let’s do a few more tweaks to improve readability and make the best use of the little screen real estate we have. Here’s the completed media query for this screen width (see Figure 7-4).
Figure 7-4. Our completed smartphone-friendly layout. The most notable changes: We’ve moved our sidebar down below our registration form and gone to a one-column layout.
@media screen and (max-width: 520px){
div#pagewrap {
width: 100 %;
margin: 0;
}
header {
padding: 0.5em;
}
header h1 {
font-size: 1.5em;
}
header p {
font-size: 0.7em;
font-family: Verdana, Arial, sans-serif;
font-weight: bold;
}
section#registration_form {
float: none;
width: 100 %;
margin-bottom: 1em;
}
aside {
float: none;
width: 90 %;
font-size: 0.8em;
margin: 0 auto;
}
input[type = "text"], input[type = "tel"], input[type = "email"] {
width: 90 %;
}
footer {
font-family: Verdana, Arial, sans-serif;
font-size: 0.7em;
}
}
Because we’re using max-width, testing is really easy. We can just resize our browser window down to view our narrow version, and then resize it up to see it snap back to our regular layout. That’s not to say that we shouldn’t also test it on iPhones/Android phones, especially if we’ve got some advanced formatting, or we’re using complex JavaScript. But a simple browser resize is just fine to help us check over things quickly.
We’ve got one more stop to make on the road to device nirvana—let’s see how things would look on a tablet screen (like an iPad). Whereas our phones have a maximum width of 520 pixels, our tablets have a maximum width of around 768 pixels (and really, on anything wider than that our site just looks normal). So let’s give our window a quick resize and see how we’re looking at 768 pixels, as seen in Figure 7-5.
Figure 7-5. The current state of affairs on tablet devices. It’s definitely not too dire, but there are still some things we can clean up here to make it look great on a medium-sized screen.
All in all, it’s not too bad. There are a few issues we want to address here, though. For example, let’s reduce the whitespace around the header a bit and clean up that sidebar. We can also widen the form fields a bit. To do this, we’ll create an @media query that looks for a max-width of 768px and… hey, wait a minute! If we’re looking at a max-width of 768px, won’t anything written here also apply to our smaller-screen devices?
Yes, absolutely! What we want to do here is make these style declarations above our 520 media query in the style sheet, so that any declarations we make in that @media query will override the declarations in the 768 media query. We can also take advantage of this to simplify things. For example, we can move our form field’s width declaration up (and a few other things):
@media screen and (max-width: 768px){
div#pagewrap {
width: 95 %;
margin: 1em auto;
}
aside {
font-size: 0.8em;
}
input[type = "text"], input[type = "tel"], input[type = "email"] {
width: 90 %;
}
}
In the preceding snippet, we’ve widened the page, reduced the margins, and decreased the size of the sidebar a bit (this rule was moved from our 520 media query). Now our page looks as it does in Figure 7-6. At smaller screen sizes, everything still looks as it did before, but we’ve prevented duplication in our rules.
Figure 7-6. Our tablet-friendly view
Here’s our completed source code:
/* Tablet styles */
@media screen and (max-width: 768px){
div#pagewrap {
width: 95 %;
margin: 1em auto;
}
aside {
font-size: 0.8em;
}
input[type = "text"], input[type = "tel"], input[type = "email"] {
width: 90 %;
}
}
/* Phone-specific styles */
@media screen and (max-width: 520px){
div#pagewrap {
width: 100 %;
margin: 0;
}
header {
padding: 0.5em;
}
header h1 {
font-size: 1.5em;
}
header p {
font-size: 0.7em;
font-family: Verdana, Arial, sans-serif;
font-weight: bold;
}
section#registration_form {
float: none;
width: 100 %;
margin-bottom: 1em;
}
aside {
float: none;
width: 90 %;
margin: 0 auto;
}
footer {
font-family: Verdana, Arial, sans-serif;
font-size: 0.7em;
}
}
Summary
Using the cascade in CSS has allowed us to progressively enhance our site and offer a range of display formats to a range of devices. Because styles can be globally applied, and then overridden based on screen-sizing criteria that we specify, we can avoid doing a lot of extra work and duplicating style sheets for different versions.
It’s important to identify what device(s) we’re targeting early in the process and to start at the bottom (the smallest device). Also, we should use proportional units instead of absolute units and identify the maximum-width breakpoints where we need to tweak the display for a particular device. Next, we need to optimize our design for the device. A two column layout isn’t the best plan for a smartphone, whereas a single column of text is just too much for a widescreen display. We need to plan accordingly.