This is the third article in a series that I was asked to write for work. The previous articles discussed the changes in workflow and some of the technical ingredients of responsive web design. In this final article, we dive a bit deeper and discuss some more advanced techniques in order to optimize a website for mobile performance as well as legacy browser support.

We previously wrote about changes in workflow and basic techniques of responsive web design, so now let’s dive into something more challenging: optimizing website performance for mobile. While we’re adding complexity, let’s go ahead and add a dash of legacy browser support as well. This may seem like an odd mix of requirements, but let’s face it: Sometimes we find ourselves in a position where we have to simultaneously forge ahead with modern technologies while ensuring that we don’t forget about site visitors with less capable browsers.

To demonstrate some handy mobile-first methods, we’ll be referencing techniques used on the Media Multiplyer site. It’s a fairly small site (only a few pages), but it was a perfect opportunity to explore experimental front-end development techniques.

Luckily we’re not alone

One of my favorite things about the web development industry is the wonderfully open community of developers who are willing to share their knowledge and expertise. Brad Frost is one of those generous and impressively talented developers. He has written extensively on the subject of mobile and responsive web design, and his expertly curated collection of responsive patterns is an excellent resource to which I often refer. He’s also written an article, “Creating a Mobile-First Responsive Web Design,” that I consider a great primer on mobile-first techniques that we can use in our work today.

I was already excited about responsive web design, but admittedly I had certain reservations about performance on mobile devices. For instance, if we build a site that looks and works great on our large desktop monitors with high-speed local area networks, how will that same site perform on phone screens with a significantly slower data connection? In Brad’s article, he references Luke Wroblewski’s concept of mobile first, which encourages teams to “focus on only the most important data and actions” in an application. In other words, consider small screens first and concentrate on what’s really important for the user: easily accessing high-quality content.

Brad’s mobile-first technique starts by including two style sheets: a basic style sheet that gets downloaded on all devices, and an enhanced style sheet that only gets downloaded on tablets and larger screens. The basic style sheet has colors, typography, and minimal layout styles—the stuff that looks good on a small screen. The enhanced style sheet does heavy lifting by layering on more complex styles for layout, flexible grids, large background images, etc.

The advantage of this technique is that small-screen mobile devices will only download what’s included in the basic style sheet. Larger screen devices, such as tablets, laptops and desktop computers will benefit from both style sheets.

Don’t tell me. Show me.

Let’s take it one step at a time and go through the Media Multiplyer site code together. The first thing we need to do is set the screen width to the actual width of the device using the meta viewport tag. This will start the process of optimizing our site for a mobile experience.

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

We’re accomplishing two things: We’re setting the viewport width to the width of the device as well as setting the zoom level to 100% (that’s the 1.0 part at the end). It’s important to note that we’re not disabling the user’s ability to zoom the page itself by adding “maximum-scale=1″ or “user-scalable=no” properties. You may have seen these in the wild before. Or you may have run across sites on your mobile device that didn’t allow you to zoom in and wondered why. With our simplified meta viewport tag, the user will still be able to pinch-to-zoom to take a closer look at the images, text and other content.

The next step is to include both style sheets. We link the basic style sheet as usual:

<link rel="stylesheet" href="basic.css"
   media="screen, handheld">

…and then we link the enhanced style sheet using a clever media query trick:

<link rel="stylesheet" href="enhanced.css"
   media="screen and (min-width: 40em)">

We’re downloading the enhanced.css file, but also adding a media query attribute that specifies a minimum screen width, preventing it from getting downloaded on small screens. So, in turn, any large background images or other assets specified in the enhanced style sheet won’t get downloaded either.

You may also have noticed that we’re specifying the “min-width” media query with an em-based instead of px-based unit of measurement. This will create a proportional media query that will help users who have used the zoom feature in their browser to increase text size, etc. In our example, a media query of 40em is calculated with the following simple formula:

640px target ÷ 16px context = 40em result

In other words, a 40em “min-width” media query is roughly equivalent to 640px, assuming a baseline font size of 16px.

The other important thing to note is the use of a “min-width” instead of “max-width” media query. If we used a “max-width” media query, the enhanced.css file would also download on devices with small screens. We’re going to continue that trend of using “min-width” media queries in our enhanced.css file as we progressively enhance our styles for larger screens. So, for instance, we could add a media query like the following:

h2 {
    font-size: 21px;
}

@media all and (min-width: 52em) {
    h2 {
        font-size: 24px;
    }
}

In this example, the font size for our h2 elements will be 21px by default and 24px for everything with a screen width larger than 52em (about 832px).

We can even change the layout from two columns to four columns:

.column {
    width: 50%;
}

@media all and (min-width: 48em) {
    .column {
        width: 25%;
    }
}

Of course, there’s just one small catch in our plan: Our original media query attribute is not supported by Internet Explorer 8 since it doesn’t support CSS3 media queries. So site visitors browsing our site with IE 8 will only get the basic styles. This could be a problem because we need to support IE 8 in our project, so what can we do?

Consider the options

On the subject of support for IE 8, there are a few options to consider:

1. Do we simply ignore IE 8 since we’re concentrating on “emerging technologies” for our site?
2. Do we accept the fact that IE 8 will get a basic yet functional experience compared to modern browsers?
3. Can we somehow enable IE 8 to take advantage of our enhanced style sheet?

Admittedly, the first option is probably not a practical solution. Internet Explorer 8 usage still represents a significant proportion of the overall browser market, so it’s important not to ignore it.

While the second option is better, we can go one step further.

Another option to consider is redundantly referencing the enhanced style sheet for IE 8 only. This creates an additional server request, but that shouldn’t be a big deal since we’re restricting it to non-mobile devices. Here’s how to achieve that:

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="enhanced.css">
<![endif]-->

So now non-mobile IE 8 devices will download the enhanced style sheet and all is good, right? Well, not quite yet. Our enhanced.css file will naturally contain media queries too, so we’ll need to add some CSS rules specifically for IE 8 to fully cover our bases.

If we wrap the html element in a conditional comment, we can conveniently add a class for IE 8:

<!--[if IE 8 ]> <html lang="en-US" class="ie8"> <![endif]-->

Now we can duplicate the media queries we’ve added in enhanced.css and target IE 8 with a CSS rule of its own. For example, we could add a CSS rule like this:

.ie8 h2 {
    font-size: 24px;
}

Fine-tune the details

Using this method, we can go through the enhanced.css file and make sure that IE 8 will get the same (or at least similar) styles as all the modern browsers. We don’t necessarily need to duplicate every single style included in the media queries. None of the fun CSS3 features, like rounded corners, box shadows and gradients will be available to IE 8, so there’s no need to include them. But we can tailor the experience for IE 8 to include the important elements like layout, background images and font sizes.

This is the second blog article that I was recently asked to write for work. In the first article, we discussed how responsive web design can require changes in workflow and strategy. This one is a beginner’s guide to responsive web design where we briefly discuss each of the three technical ingredients.

In Ethan Marcotte’s groundbreaking article published on the blog A List Apart, he helped us think about the web in a more flexible way, where the display of all-important content can adapt to the capabilities of devices instead of being boxed in by fixed-width, inflexible layouts. Let’s take a look at each of Ethan’s three original technical ingredients and see what they can do for us.

Fluid grids

In the beginning (well, in web terms anyway), all websites were responsive. You might remember the early days of the web as fondly as I do. Everything was exciting and new. It was also very simple compared to today’s web. We authored plain old semantic HTML, sprinkled in a few decorative images and released it to the world. We weren’t concerned with locking things down, so consequently our page layouts naturally flexed and breathed as needed.

Somewhere along the line we started using HTML tables and spacer graphics to turn all the random chaos into beautifully ordered web pages. But tables were intended for tabular data (like a spreadsheet), not for layout and presentation. So we converted our table-based code to more web standards-centric CSS layouts. This was more “responsible” and allowed us to separate structure from presentation. We felt like we were doing the “right thing” once again. But we were still locking things down with non-flexible pixel-based layouts. What happened to our beloved flexibility?

If we want our content to be adaptive, we need to convert those pixels to percentages so that our layouts can stretch and contract when the browser viewport changes (as viewed on small screens, tablets, and so forth). In our CSS file we need to change things like this:

.main {
    float: left;
    width: 660px;
    margin-right: 20px;
}

into something like this:

.main {
    float: left;
    width: 68.75%;
    margin-right: 2%;
}

In this simple example, I’m assuming the overall layout width, as viewed on a desktop browser, is 960 pixels. By using Ethan’s simple fluid grid formula, we divide the target width (660 pixels) by the context (960 pixels) to provide our percentage result (68.75%). Here’s the simple formula:

target ÷ context = result

This is a tough concept to describe in words, so let’s take a peek at Ethan’s original responsive demo website. Go check out his website and resize your browser by slowly dragging the right edge toward the left so that it collapses to a tall, narrow viewport. This will approximate what it’s like to view the website on a bunch of devices with a variety of screen widths. It’s not exactly the same, but it demonstrates the concept visually and that’s good for our purposes here.

No, really: go ahead and take a look. I’ll wait until you get back.

See what I mean? Did you see how the design responds and adapts to the width of the browser window as the available viewing space changed? This is one of the most powerful aspects of responsive web design. Not only can we linearize the content (stack it from top to bottom), but we can also optimize our layout for a variety of device sizes and capabilities. It’s important to remember that we’re changing the presentation of the content, not the foundational markup itself. Under the hood it’s the same HTML code, but the layout changes shape and the images shrink and expand as needed. Speaking of images, let’s move on to our next responsive web design ingredient.

Flexible images

So now our layout is fluid and flexible. How do we get those pesky images to flex with the rest of the content? We need to allow the images to shrink while retaining their original proportions. Again, we turn to CSS and add the following rule for our image tags:

img {
    max-width: 100%;
    height: auto;
}

Well that wasn’t too difficult. One more thing before we’re finished with our flexible images. We need to remove the width and height attributes from our image tags, which leaves us with:

<img src="monkey.jpg" alt="image description">

Nice and simple. Now our images will proportionately shrink down as the available screen width decreases. An important point to keep in mind: it’s not a good idea to increase the dimensions of an image (i.e., start with a small image and stretch it bigger), so we’ll need to create our graphics the right size for the desktop layout and let CSS do the job of shrinking them down as needed. Keep in mind that these large images might be accessed on a mobile phone with a slow connection, so it’s still a good idea to compress and size them as you would normally.

We still need a way to make some minor layout adjustments from time to time, which brings us to our third and final responsive web design ingredient.

Media queries

Actually, one of the components of media queries, called media types, has been around for a while. Have you heard of a “printer” style sheet? That’s when the developer creates CSS rules that are only used when a web page is printed. The screen ignores them, but the printer uses them to format the content for a printed page.

With responsive web design, we can also query the browser for things like minimum and maximum width, device type and other useful features. If we decide that the content in our large-screen, three-column layout gets too tall and narrow on small screens, we can use media queries to make adjustments. We can also change things like background images, colors, font styling and more. Here’s a simple media query that changes the background color as the viewport increases:

.container {
    background-color: blue;
    color: white;
}

@media screen and (min-width: 480px) {
    .container {
        background-color: red;
    }
}

@media screen and (min-width: 960px) {
    .container {
        background-color: green;
    }
}

Do you see how that works? On a small smartphone screen, the container’s background color would be blue. On a medium tablet screen, it would be red. And on a large desktop computer, it would be green. If you were to resize your browser you’d see each in turn as the screen size changed.

I was recently asked to write a blog article on responsive web design at work. I immediately agreed to write the article, but I struggled a bit when I sat down to actually write it. So I broke it into three articles: a gentle introduction, a beginner’s guide, and an advanced topic. This is the first article that I wrote. It deals with my personal struggle to wrap my brain around how this whole responsive web design thing was going to fit into my development world.

For the past 15 years or so I’ve made a living building carefully handcrafted, pixel-precise websites. I’ve absolutely loved the challenge of tackling even the most daunting visual designs handed to me by talented web designers. You know the kind of websites I’m referring to…. They look more like a printed work of art and less like a simple word-processed document with text and decorative clip art. Irregular column widths, multiple overlapping graphics, endless variation from one page to the next, all wrapped in a fly-out navigation structure three levels deep—and it needs to look the same in a dozen browsers. No problem… how soon can I start?

After finishing a particularly difficult website build, I secretly enjoy hearing the comforting praise from a designer who marvels at how my web page looks “exactly like the original Photoshop comp.” I also like the occasional, “Wow, is that the comp or the HTML?”

Learning to let go

A few years ago I realized those same fixed-width, tightly controlled layouts were increasingly difficult to “get just right” in the quickly expanding universe of mobile devices and user contexts. And it wasn’t because Internet Explorer couldn’t quite keep up with Chrome and Firefox (but, let’s face it—that was also true). Almost overnight those clever works of visual design and code were being viewed on tiny phones, tablets of all sizes, small laptops and smaller netbooks… and even huge TV screens via game console browsers.

I just couldn’t keep up. I felt like I had lost control. I felt angry and frustrated. I briefly considered other career options. Surely there’s got to be a better way! At about this same time, I read Ethan Marcotte’s original responsive web design article published on A List Apart. But honestly, I was having a really tough time getting a grip on this new way of thinking. It was like I was going through the five stages of grief:

• Denial: “Surely this will never work. It will go away if I just ignore it.”
• Anger: “I’m not giving up pixel-precise control! That’s my specialty!”
• Bargaining: “We’ll make minor adjustments so that it looks good on tablets. We can build a separate mobile site for the rest.”
• Depression: “I don’t want to go through this again. I already gave up table-based layouts.”
• Acceptance: “Hey, maybe this could work after all. I’ll try it out and see what happens.”

I had enjoyed Ethan’s presentations at a couple of web design conferences and was immediately impressed with his quiet confidence and broad knowledge of, well… pretty much all things web. I was also more than a little intimidated by the fact that he can do so many things so well. He’s an accomplished conference speaker, published author, web designer and front-end developer. Those last two skills, designer and developer, are key to this whole thing working because responsive web design (RWD) requires true collaboration between the web designer and the front-end developer. Ethan can do both… which must be a big advantage.

Let the healing begin

But in my world, I could see this might be problematic. How is this going to work in a typical agency workflow where someone else creates the design, and I write the code while they move on to another project? The truth is, it probably won’t work like that… at least not without some changes to our processes and mental models of how we think about and ultimately design for the web. With RWD we’ll need more collaboration during the design and development phases of the project to allow minor course corrections along the way. We’ll need to rely less on static Photoshop comps and perhaps even start to design in the browser. We’ll need to try things out in the browser to see what parts of the design work and what needs slight modifications in order to be more flexible.

In Ethan’s original A List Apart article, while borrowing from the field of architecture, he challenged us to embrace the inherent flexibility of the web. Move with the ebb and flow, as it were. Instead of building a single device-specific display of our website, we should create a “flexible foundation” in which the content can adapt to the capabilities—and limitations—of the vast array of devices available today and in the future. His original RWD recipe includes the following three technical ingredients:

1. Fluid grids
2. Flexible images
3. Media queries

How does that make you feel?

About now, maybe you’re feeling some of the same anxiety I initially felt about RWD. Well, I’m here to tell you it’s OK. Lately I’ve discovered that it’s more of a journey than a destination. It’s simply a method of designing and building websites, and there are a lot of things to consider. We’re still trying to figure out how to make it all work. And like most things, there’s no single right way to do it. So we’ll take it one step at a time and experience it together.

The other day I saw some front-end code that just plain angered me. I wasn’t upset that the website looked bad in the browser or that it wasn’t faithful to the original visual design. It was just poorly executed. It lacked semantics, clarity, and direction. It seemed obvious that the developer simply mailed it in. That experience compelled me to write a few words about craftsmanship and good old fashioned pride in one’s work.

As I sat down to write about this subject I decided early on that I’d take a positive approach in hopes of inspiring others instead of pointing fingers at a bad example (which is why I’m not including a link to the bad code in question). So I searched the web using keywords like “handmade websites,” “beautiful code,” and “web craftsman” in hopes of finding people like me who take pride in a job well done. In my search, I found a bunch of people who go to great lengths to create carefully handcrafted custom web solutions… and don’t hesitate to mention that they’re pleased with their accomplishments. They point out things like: attention to detail, finesse, simplicity, ease of use, and even performance. I edited my own About page to capture some of these same points because I feel strongly that they’re good things to do on every project, even if it takes a bit more time.

While I was poking around looking for inspiring words to share, I ran across Joshua Porter’s presentation On Being a Web Craftsman on SlideShare. It’s truly one of the best things I’ve read in years. It’s only 17 slides total, but it so eloquently captures what I feel strongly about and what I aspire to be—a web craftsman. There are several great ideas captured in those few slides, but I think this one is my favorite:

Craftsmen are not driven by money or recognition, but by simply doing Good Work.

I really love that… because it’s so true. I feel like it’s definitely worth it to do “good work” on every project. Toward the end of Joshua’s presentation, he includes a slide titled “Trouble Spots” that really hits close to home:

Craftsmanship takes a lot of time.
Craftsmen have trouble managing people.
Craftsmen don’t necessarily play well with others.
Craftsmen tend not to be business savvy.

I don’t necessarily think these are negative. I think they’re good qualities to have because they so accurately describe someone who goes out of their way to create something good and honest… and possibly even beautiful. Perhaps you feel the same.

That’s right! I’ve re-written all of the HTML and CSS code on this site so that it’s now fully responsive. In other words, if you’re looking at this on a desktop computer, you can slowly resize your browser (i.e., click the lower-right corner and drag it to the left) and watch all of the website’s content shift around as the window gets smaller and smaller until you reach the approximate size of a mobile phone. The overall layout, all of the text, and even the images will respond to the size of the browser at all dimensions. As the browser gets smaller, the site shrinks to properly fit. If you’re looking at this site on your mobile phone, you’ll just see a simple, clean, and performance-oriented website. The HTML code and all the content throughout the entire site are the same for all devices and screen widths.

There are several methods of doing responsive web design, but after much research and agonizing, I decided to take the mobile first approach. I did quite a lot of reading and experimenting over the last several weeks and decided to use my own website as the test. I must say, I had serious reservations about being able to make the mental shift to thinking about the mobile experience at the beginning, but I was pleasantly surprised with the process when I actually started coding. When you break it down, it’s really just an extension of the concept of progressive enhancement which I’ve been a big fan of for many years. I generally try to separate the underlying structural markup (HTML) from the presentation (CSS) and behavioral layer (JavaScript) when building any website, but this seemed like taking it to a whole new level.

The other thing that I was surprised about was how comfortable I’ve become over the last few years at designing in the browser. I had a pretty clear mental picture of the final desktop layout, but I made numerous adjustments to the CSS in reaction to what’s happening in the browser at various widths. Also, I didn’t sit down with Photoshop and create design comps of the three typical browser widths (CSS media query breakpoints). For me, it’s much easier to see what’s going on in the browser and make adjustments to the code along the way.

I’ve always supported the “content is king” way of thinking, so the whole mobile first approach made a lot of sense to me—it places the content front and center from the very beginning. This may seem like an obvious thing to do, but you may be surprised to find out that it’s far from the norm in the field of web design. Websites are usually designed with fake content (called greeking in the industry). This approach has always confused me… how can you design a site without any of the content? What happens if the content that eventually gets written doesn’t fit into the neat, tidy, conveniently designed spaces? Well, it often doesn’t fit. That’s the problem.

I’m not primarily a visual designer, so when I decided to do this redesign (really it’s more of a rebuild), I needed a visual design to start with, so I maintained the basic look and feel of the existing WordPress theme that I bought a couple years ago (Elefolio by WooThemes). I like the simplicity of the design with the neutral colors and overall non-intrusive approach that features the portfolio items nicely. Working with an existing visual design also closely matches the way that I normally work—partnering with a visual designer—so that was a familiar and comfortable starting point. I made several enhancements to the original design, but some visual elements are still present.

Additional Reading

Interested in reading more about responsive web design and mobile first? Look no further… here’s a short list of online resources that I found extremely useful while I was doing all of my research, experimentation, and development.

• Responsive Web Design article on A List Apart by Ethan Marcotte
• Responsive Web Design book by Ethan Marcotte
• Mobile First book by Luke Wroblewski
• Creating a Mobile-First Responsive Web Design by Brad Frost
• Responsive Web Design Patterns by Brad Frost
• Head First Mobile Web book by Lyza Danger Gardner, Jason Grigsby