Adam Churchill: Welcome everyone, to another episode of the SpoolCast. We kicked off the 2011 Virtual Seminar Series with Ethan Marcotte, teaching us about responsive web design.

What's that? Well, combining flexible grid-based layouts and media queries, responsive web design is a technique that can help you design beyond the desktop for the ever-widening range of resolutions, devices and browsers.

There was a lot to talk about that day. We didn't get to it all, and Ethan has graciously offered to come back and tackle some of the questions that we didn't get to address in the seminar. Hey, Ethan, welcome back!
Ethan Marcotte: Hey, Adam, thank you so much for having me. It's great to be here.
Adam: Now, folks who didn't listen to this particular seminar, you can still get at it in UIE's User Experience Training Library. There's over 55 recorded seminars from experts just like Ethan Marcotte. Ethan, for those listening who weren't with us for your presentation, can you give us a brief overview? What is responsive web design?
Ethan: I'd love to. It's something I've been really excited about for the past year or two and been thinking a lot about it in terms of, well, this concept of design in general regardless of what medium it's in, whether it's the web or graphic design or whatever. Design really flourishes under constraints. The more known quantities that we have to deal with, the more creative solutions we can often apply. Because really, design is all about creating order out of chaos.

Now, that can kind of run counter to a little bit of the web's innate flexibility. As designers, the moment we publish something online we surrender so much control to the people that are actually digesting our content, that are reading our sites, to their browser preferences, to their window sizes, to the actual characteristics to the device they're viewing our sites on.

There's a little bit of attention there because I think our instinct as designers is to basically introduce constraints to sort of set those ideal parameters. So we'll create fixed-width websites to suggest the ideal parameters and to which this content should be read. Or maybe we'll create separate mobile websites or separate device-specific websites.

The problem is, I think, that desire to sort of impose constraints at some point feels a little not scalable to me. At some point we can't keep up with the pace of technology. Because as mobile browsing has exploded over the past couple of years and that number is just going to keep going up, the emergence of tablets and other kinds of Internet-ready devices, our job has never been more challenging than it is right now, just this ever-widening landscape of browsers and devices.

So as we move beyond the desktop, I think there's a lot we can learn from this other design discipline called responsive architecture, where architects have been sort of re-imagining what a space can do and how it can sort of adapt and respond to the needs of the people that occupy it, changing the shape of walls and changing the shape of a space to accommodate different sizes of crowds.

So I think that rather than trying to impose constraints on the web, we can see its flexibility as an asset and better design for it. And as you sort of said in your intro, Adam, the ingredients of a responsive web design are basically three components.

It's a flexible or a fluid grid-based layout with images and media inside of that grid that work in a flexible context, and then finally, CSS3 media queries. So that's more or less how I structured my talk was taking each one of those ingredients in turn and showing how they sort of lock together to create this more responsive approach to designing for the web.

So we looked a little bit at some of the very simple mathematics behind translating a grid-based layout designed in an image editor like Photoshop or Fireworks and translating into a flexible context in CSS. And then we looked at some ways to manage fixed-width elements like movies and images inside of that flexible context.

And then finally, kind of an introduction to the CSS3 media queries, which allow us to actually query the physical characteristics of the device or browser that's rendering our content, and basically sort of reorient our designs, allow our designs to kind of self-correct to provide an optimal experience for different classes of users.

That's kind of the nitty-gritty, low-level stuff of responsive design, but then I kind of wrapped up the talk with thinking about how responsive design actually impacts our workflow in the studio. How do we manage a responsive design project? And we looked at a couple different strategies for doing that.

Now it's kind of early days yet, and I sort of used a very abstract case study inspired by some of my work, but it was more of a conversation starter to say, "Hey, here's some of the stuff that's worked really well for me in my practice. Maybe you can improve on it." So that's the, I guess, elevator pitch version of the talk.
Adam: Excellent. Let's get to some of those questions that were left over. There was this concept that came up, this one-web approach. Can you speak more about that, and in particular, folks were wondering how you convince your clients to go about it with that concept in mind?
Ethan: That's a fantastic question, and there's a really great debate going on right now about the merits of this one-web approach. The really short version is basically, responsive web design is at the face of it you could say about serving one document to every device and every browser, but changing the presentation and changing the experience on the front end so that, as I said before, you can sort of rethink the experience and optimize the experience for different classes of browsers and devices.

Now, this runs counter a little bit to the approach that's been advocated by a lot of people in the mobile web design side for a long time, because they've been dealing with an incredibly fragmented landscape of browsers and devices. Phones and PDAs and other kinds of devices that are so drastically fragmented in terms of their capabilities that they've been having to serve up separate sites basically geared to different kinds of devices.

So for example, if I'm in a mobile context, perhaps the argument might be that I'm going to want to see less content and perhaps order it in a different way than if I'm on a desktop. So responsive design can actually borrow from some of that and start thinking about mobile first and start considering, "OK, well, what's the design that's most critical to people that are maybe on a lower bandwidth or are maybe perhaps on the go?"

Maybe their attention is a little bit distracted by other elements around them. And then sort of scaling up from that point. By starting with that one document, we can then layer CSS on top of that with media queries to basically progressively enhance the design and rethink the experience of those different resolution break points.

In terms of how we convince clients of the merits of that, then, I think that really comes down to showing them the benefits rather than describing what they can do. The sort of "show, don't sell" principle.

Find some really inspiring examples of responsive design that are out there. Some of my favorites are hicksdesign.co.uk, which is Jon Hicks's personal website, and his portfolio is also housed there as well. He's a professional designer and illustrator, and it's one of the first and still one of the best examples of responsive design on the web.

Dan Cederholm's site simplebits.com is beautiful as well. Designmadeingermany.de is one of my favorites. They publish an online magazine that's I think at volume five or something like that as their responsive version. And at any device or browser or resolution point it's just a compelling, beautifully art-directed experience.

But they've been using a responsive approach to really consider, "Well, what's the best way to sort of typographically set this module? How do we want this element to be interacted with on a touch device versus a keyboard and mouse display?"

Showing some live examples can really be a great showpiece when you're trying to convince people of the one-web approach. A little bit more on the financial or practical side, actually try to spend some time researching the production and maintenance costs involved with maintaining separate sites that are specific to a class of devices.

But it's also important to remember that a responsive approach or the one-web approach, it's very possible it might not be the best one for your project or for your client. Last year, I worked on an event site for my previous employer, and it was called cogaoke.com. It was a karaoke party that we threw at a conference.

And we saw the mobile site as basically sort of being very much a night of experience. You could get directions to the venue, and then basically during the performance there was a live voting app that would be available on the website, but just to people in the audience.

But the desktop experience was drastically different. You know, it was available for months in advance. People could get information on the performers, they could vote on people that they wanted to see at the venue, and they could also browse a library of songs that were going to be available.

So the needs of those two different contexts, those two different experiences, were drastically different. And it would have been irresponsible of us to basically pack the markup for both of those into one site, and then just use CSS to basically toggle the experience contingent on the browser or the device.

So I think responsive design is an incredibly powerful approach and a really compelling one to think about, but it's entirely possible that it might not be the right approach for you. So basically, find some inspiring examples of responsive design that are out there, take a look at the cost-benefit analysis of whether or not separate sites are even tenable for you. And then, basically just take a look at whether or not responsive design is the right approach. I think that's the best way to go.
Adam: Carmichael wants to know if responsive web design also adapts to connection speeds and not just pixel dimensions of a device.
Ethan: That's a great question. So Carmichael, the short answer is no, but the long answer is a little bit more interesting, hopefully.

So responsive design is taking one layout and then using CSS3 media queries to sort of reorient it to different displays. Basically, there's nothing in media queries that allow us to sort of detect the connection speeds of the device or browser. But it's important to note that mobile sites actually can't do that either. Both responsive design and device-specific websites both have their blind spots and it's important to know where those are.

Mobile websites, a lot of them are sort of founded on the concept that if the display is smaller, then there might be less bandwidth available. And certain responsive designs as well are guilty of making that same assumption. But that can be a little bit of a resolution fallacy if you think about it for a second, because in the age of portable 3G hotspots and devices like the iPod Touch, which are WiFi only, it's really critical for us to take a hard look at how our audiences are actually interfacing with our designs and not just the kinds of devices that they're using.

My expectations for when I'm on my iPhone and accessing your site on my personal network are going to be very drastically different than if I'm, say, running to the bus stop and I'm trying to get some information quickly about, say, a flight reservation or something. So that's important research that I think we need to do, and whether you choose to do a mobile site or a responsive site, we're not really exempt from doing that.

But that said, for a responsive approach there are ways that we can sort of be smart about the bandwidth that we're asking our users to consume. We can use media queries to basically progressively enhance our design as the resolution range gets wider and wider. Starting from a baseline of basically a very mobile-friendly linear site, and then introducing layout complexity and heavier graphics and heavier assets as the resolution gets wider and wider.

My personal, or my professional site ethanmarcotte.com is kind of a quick case study in doing this. Basically, if you have an incredibly narrow browser window or if you're on your mobile phone, you'll be getting sort of the baseline layout. It's very linearized, very simple, but still has a lot of the core typographic settings that are seen throughout the entire design.

And then as the design gets wider and wider, some more complexity gets added, the grid becomes a little bit more asymmetrical, ultimately it sort of ends up on the higher end of the resolution spectrum with some really heavily-designed assets loaded in.

So I think that's a more responsible approach to responsive web design. Starting with the lower end, starting with the mobile first concept and then scaling up from that point. But still, make sure you don't fall into that resolution fallacy that I mentioned earlier. Research your users, learn how they access our sites and plan accordingly.
Adam: Karen asks, when you're planning to build a site, do you allow a lot more time for coding and testing various resolutions?
Ethan: That's great, Karen, thanks. During the virtual seminar I talked a little bit about how we're incorporating responsive design into a project that I've been working on for the past few months. And what that's turned into has been kind of interesting. It's been kind of counter a little bit to the traditional sort of waterfall approach that a lot of creative studios use to manage their projects.

For those of you who aren't familiar with the sort of waterfall approach, it's basically taking the various tasks of a creative project from requirements gathering to design to development and sort of compartmentalizing them into separate phases I guess is the best way to put it.

What we've been finding is that it's very hard to get sign-off on a set of designs because it's not really practical for us to design all the possible views of a particular page in terms of, "Well, how is this really rich desktop layout going to look when viewed on an iPhone or on some other android phone or on a tablet?"

What we've been doing instead is kind of a hybrid design and development cycle. So we'll sort of work with a client to sort of flesh out some of the big creative problems, establish a creative direction, and sort of design the, I guess, desktop-centric view of a page.

And then we'll move into this really agile, quickly iterative design and development cycle where we'll take that page, and then we'll quickly turn it into an HTML mock-up, and then have some more interactive design reviews basically internally.

As we're building this page, we're sort of constantly resizing the browser window to kind of simulate how the design performs in resolutions. But then, we'll meet with the entire team and throw basically a pile of phones and tablets and laptops on a table and ask people to sort of really interact with the design.

And we're interacting with the design basically in browsers, in HTML and CSS, and sort of vetting some of those initial assumptions we made about the design and seeing how it feels when it's being presented with different input classes.

Is it a touch device? Is somebody going to use up/down, left/right arrow keys to sort of navigate this, or are they using a keyboard and mouse? Are links easy enough to touch at lower ends of the resolution spectrum? Can I still use this form on a device that requires me to tab through each individual field?

So this has kind of helped us get away from focusing just on getting some really immaculate Photoshop mock-ups finished to present to the client, and allows us to basically emerge from this hybrid design and development cycle with hopefully production-ready code that's been thoroughly vetted across the board.

So this is kind of a long way of saying that, to your original question, Karen, the time that we are using has been more or less equivalent to design and development phases but sort of combined into one. So we're not really spending a ton more time at the outset, but really just trying to work more quickly between the two teams to kind of get finished code in front of us.
Adam: Our good friends at EightShapes would like to know when it makes sense to design with a responsive grid versus a fixed-width grid. I guess what they're asking is, "Does it even make sense in today's environment to still design to fixed-width?"
Ethan: Hm. That's an interesting question. Well, I should probably say at the outset that I've got my own set of biases around that [laughs] . I've been a long time proponent of flexible layouts in general, and I do think that they're a really key component as we start designing beyond the desktop.

Because even if you're just designing for, say, one class of devices, say like an iPhone, for example, you're immediately designing for two different orientations -- portrait and landscape -- and a flexible layout is going to afford you, well, more flexibility as we start thinking beyond just a 960-pixel grid in a desktop browser.

So I think it's a really key component to have in your tool belt as we start entering this kind of exciting time in the Web's growth, but that said, you know your design process doesn't really need to change entirely.

I think it's really critical for me still to start with an image editor like Photoshop or Fireworks, and then start designing for one reference resolution. I still start my responsive sites with a sketch of what it's going to look like in the desktop, because that's sort of the widest view of what I'm really interested in thinking about.

But that doesn't necessarily need to impact the responsive side of things, in terms of how you actually implement it. Once you've solved those big creative problems, and your grid and your creative direction feel more or less finished, then you can move into the browser, as I said in response to Karen's question -- that you can sort of take your design and start translating it into HTML and CSS and start to experiment with how it feels at those different resolution breakpoints.

So, again, I think the hybrid approach is really a good one. When you're thinking about designing your grid, you don't need to change your approach drastically, but I think augmenting a greater process with a quick shift into code can really be helpful. But in terms of the fixed versus fluid debate, that's entirely on you [laughs] . I'm not going to jump into that chestnut.
Adam: When you are coding a flexible grid, there was a specific question. "How many decimal places can you use? Is there a limit or are you looking to round the numbers off?"
Ethan: Right. Right. That's a great question. So in the virtual seminar, I kind of walked through a little bit of the very simple math that's involved with creating a flexible grid. It's actually borrowing a formula that's used in flexible type-setting.

If you've ever sized fonts in CSS with ems or with percentages, there's a very simple formula that you use. It's looking at the target pixel value that you want to express your font size in, probably borrowed from Photoshop, and then dividing it by the context of the element that it sits in.

And flexible grid-setting works basically the same way, taking a look at the width of the column or the width of the module in relation to the context that it sits in, so expressing those widths in proportional terms.

What that does, however, when you're sort of looking at, "OK, well I have a 140-pixel module, and I need to divide it by a 960-pixel width." It leaves you with some really unappealing looking numbers in your CSS.

So basically, my theory is to give the browser as much information as they can use. So if you round off your numbers, you're sort of doing some of the browsers work for it and giving them less information to make intelligent decisions about how your design is supposed to be expressed on the front end.

What I'll usually do is basically just do a quick division in -- I use TextMate, which is a text editor for OS10, or the calculator app on your computer to basically do that work, and then I'll basically just copy and paste those unruly looking numbers into my style sheet.

Now John Resig, who's the creator of jQuery, actually had a really great article on his blog a few years back about subpixel rounding problems in CSS, because when a browser is dealing with percentage-based layouts, different browsers sort of round the numbers in different ways.

And for the most part, it's not an issue, but some browsers, like our good friend Internet Explorer, will do some interesting things with your math. I'd recommend taking a look at that article to see some of the potential challenges you might have when working with a flexible grid.

But I do have to say that -- well, John's essay was written about two or three years ago, and I kind of find it a little challenging sometimes that while it's exciting that browser makers are actually running to embrace some of the features in HTML5 and CSS3, there's still a fair amount of disagreement across modern very powerful desktop browsers in terms of how they do something as fundamental as layout.

So even today there's still some really basic disagreement in terms of how you should express a percentage-based width. For the most part, when working with flexible grids this isn't going to be a problem for you. But there are some issues available out there that you might want to pay attention to which makes it, I think, all the more important to basically just give the browser all the information you have from your calculations and don't round, basically [laughs] .
Adam: The good folks at Paychex want to know if you can resize a table or a data grid?
Ethan: Hm. That's a good question. So you can resize a table or a data grid. The longer answer is that it's a little bit complicated. So to a limited extent, we can use CSS on capable devices and browsers to change the behavior of tabled cells and rows.

For example, we could change them to block our inline elements similar to the way that we actually modify lists to create navigation menus. And that's sort of an extra level on top of a table's innate flexibility anyway.

The tricky bit is that less capable browsers and devices don't necessarily always understand this, so they might not really know how to turn a table cell into something that displays as a block level element.

And besides, if you're working with an incredibly complex or data heavy table that might not be an acceptable approach anyway.

It's entirely possible that if you're working with really complex tables you might need to do some content negotiation on the backend to sort of look at the characteristics of the device and then maybe serve up alternate HTML to those certain classes of browsers.

YIBU.com is actually a fantastically responsive layout. That's Y-I-I-B-U.com. And it's a beautiful design in its own right, but they do actually use content negotiation in a couple of places to serve alternate markup to either less capable devices in browsers or devices in browsers that just have a narrower view port and need alternate markup.

Now this is sort of a little bit of an exception to the one-web approach that we talked about earlier with serving one document up to everything, but responsive design isn't an all or nothing formula. We can start with that basic framework and then rethink it as need be to best serve the needs of our customers.

I will say that I haven't actually had to sort of serve up different markup to most of my clients that are working on responsive designs, and it might not actually be needed for most content-heavy sites. But it is actually an option, so something to keep in the back pocket.
Adam: Jennifer wants to know when you're working with flexible or liquid layouts, how do you ensure readability at different screen or window widths?
Ethan: Mm, that's a great question, Jennifer. So one of the complaints that's often lobbied against flexible layouts is that, well, at some point browser windows will get too wide and make some line lengths incredibly unpleasant to read. Nobody likes to read a line of text that's like 600 words long.

There are two different approaches to this, though. The first one that people usually resort to is placing sort of a max width on the design. So beyond a certain pixel width this design is going to stop getting wider as the browser window does. That helps ensure basically a comfortable measure for the lines so that they don't feel overlong. They don't overwhelm the eye, and the reading experience is still pleasurable.

A great example of this is actually Happy Cog's official blog, which I think is at cognition.happycog.com. Now it's a beautifully responsive layout, but they basically, decided that once they hit the desktop view of the design, they didn't want it to get much wider so there's a max width established on their design, and it becomes fixed at that point.

Now that's one option. The other option is we can actually use media queries to tune the typography at any resolution breakpoint. Whether it's mobile, whether it's a tablet, whether it's a desktop browser, whether it's wide screen display, we can adjust the typography, the font size, the leading, the margins and padding, to ensure a comfortable reading experience at any resolution breakpoint.

Now John Hicks's site that I mentioned earlier, which is online at hicksdesign.co.uk/journal, I believe -- if you resize your browser window to sort of simulate what the reading experience might be at different resolution ranges, you'll notice that John's actually done some really subtle tuning of the font size and the line height to ensure that basically the text is legible and a pleasure to read at kind of any resolution range. But he hasn't needed to constrain his design at all. It's completely fluid.

And these are basically just two different approaches that we have, whether we decide to constrain the design or tune the type to ensure that it's a comfortable read, you really have to pick the approach that feels most comfortable to you as a designer and is really going to meet the needs of your content.
Adam: All right, Ethan. Well, thank you for circling back with us to answer those questions. Before we let you go, one of the things I wanted to ask you about -- we're pretty excited about books that are coming out from A List Apart, and our understanding is that this spring they'll be publishing your effort on responsive web design. Anything you can tell our audience about that?
Ethan: Yeah. Yeah, thanks for asking, Adam. I'm pretty excited about this. I'm going to be publishing a book called, "Responsive Web Design" with A Book Apart, and their site is at books.alistapart.com.

And I don't have an official release date for my book, but it just shipped off to the editors about a week and a half ago, and I should be getting a corrected version -- hopefully shortly. But I'm thinking it's probably going to be out in the next couple of months, so keep an eye out for that. I'm really excited about that.
Adam: Excellent. So are we. Good luck with that.
Ethan: Thanks, Adam.
Adam: Well, thank you, Ethan, and thanks, everybody, for listening in.