umatchedstyle
Jan 23 2012

Ethan Marcotte

Posted on by

7 comments

Play the Show

Download the Show

Ethan_Marcotte.mp3 (43.3 MB)

Subscribe to the Show

iTunes
RSS feed

Our guest for our inaugural episode is Ethan Marcotte.

Ethan Marcotte Biography

Ethan is a web designer & developer who lives in Cambridge, Massachusetts.

He’s also the author several web design books including Responsive Web Design, a book that’s helped revolutionize the way websites are built.

He frequently speaks on web standards and responsive web design at conferences and tweets about it @beep and @rwd.

SHOW Links & Notes

ETHAN MARCOTTE SHOW TRANSCRIPT

[intro music]

Chris:

[0:09] Hello and welcome to Non-Breaking Space. Non-Breaking Space is a show where we’ll seek out the best, brightest, and smartest people on the web and talk to them about how and why they do what they do. Your hosts are Christopher Schmitt and Dave McFarland, two web designers, authors, and trainers, who have a passion for sharing knowledge about the web.
[0:24] I’m Chris from Canada, a web designer and podcaster. Christopher and Dave have been invited along to push the record button and keep everyone on track here on Non-Breaking Space.

[0:33] Our guest for our first episode is Ethan Marcotte. Ethan is a web designer and developer, who lives in Cambridge, Massachusetts. He’s also the author of Responsive Web Design, a book that’s helped revolutionize the way websites are built. He frequently speaks on responsive web design at conferences and tweets about it @beep.

[0:51] I’ll leave it at that and turn it over to Christopher and Dave and their conversation with Ethan.

Christopher Schmitt:

[0:56] Hey, Dave. How’s it going, man?

David McFarland:

[0:57] Hi, Christopher. Things are going well. I’m really excited about talking to Ethan today.

Chris:

[0:59] Yeah. It’ll be great. I’m really glad that we’re able to do that. If you don’t know, the Internet was blacked out yesterday.

Dave:

[1:10] Yeah, I know.

Chris:

[1:11] We’re recording this after the great "SOPA Battle of 2012". Everything was blacked out yesterday.

Dave:

[1:20] Yes, and there are millions of college students busily finishing the papers that were due yesterday. "Oh, thank God! Wikipedia’s back online."

Chris:

[1:28] Actually, there was a trick. I think if you loaded Wikipedia and hit escape it’ll actually load Wikipedia or something.

Dave:

[1:35] It actually worked on mobile. I could just look at it on my iPhone. It was fine.

Chris:

[1:40] OK, well, that’s good. I’m really glad that we defeated SOPA. Was that the outcome I guess? We’re good to go, now.

Dave:

[1:51] Well, there’s PIPA still.

Chris:

[1:53] There’s PIPA still? Oh, man, is that the son of SOPA?

Dave:

[laughs] [1:56] The son. The bastard child of SOPA is PIPA.

Chris:

[2:02] I just know after Al Gore left, Congress has no idea what the Internet is.

Dave:

[2:08] It’s true. Have you seen this CSS1K site?

Chris:

[2:12] No. Tell me about it.

Dave:

[2:13] I just found out about it. It’s basically rebooting a CSS Zen Garden with a twist. It’s css1k.com and it’s just like Dave Shea’s CSS Zen garden with the caveat that your CSS file has to be 1K in a file.

Chris:

[2:36] Zen garden was, I guess, the main thrust was about designing across different browsers, including IE and then, if I’m wrong about that, but it’s been a while. Now the limitation here is the 1K?

Dave:

[2:52] Is 1K, yeah, which doesn’t include vendor prefixes. They add that separate.

Chris:

[2:58] That’s the rub right there. That’s a pass. Whatever.

Dave:

[3:04] It’s sweet. They’re not really concerned too much about making it work across all the web browsers. There’s CSS transitions and transforms and really cool looking stuff.

Chris:

[3:18] That’s going to be kind of interesting to see what people come up with because that’s a good trade off to do. Do you focus on animations and stuff like that? What kind of cool thing can you do? It’s almost like you need to have object-oriented CSS, in order to really be efficient with that type of contest entry. I don’t know. Great, now you have me talking about that.
[3:45] We have a great guest in to talk today, Dave. Ethan Marcotte. Ethan, are you here?

Ethan Marcotte:

[3:53] Hey, Christopher. What’s going on?

Chris:

[3:54] Hey! I could talk all day probably about CSS1K already, but I wanted to bring you in early before I go down that path. How have you been?

Ethan:

[4:06] Good. Good. As a rule, I try not to author CSS that’s under a meg.
[laughter]

Dave:

[4:12] That’s responsible web design. That’s very good. Very good.

Ethan:

[4:15] I strongly disagree with this growing trend of miniaturization.

Chris:

[4:22] It’s amazing. You joke about one meg, but I’m actually working on a project with Amazon’s A store where you can actually add custom CSS on top of their CSS for their affiliated program. They limit you the number of characters. I think it was 8,000 characters of your custom CSS. You don’t get that pass of vendor prefixes are free or whatever. It adds up pretty fast when you want to try to do something.
[4:57] A meg is a little too much.

Ethan:

[5:00] Yeah. I read an article maybe two weeks ago or something like that that was just polling an average of, I don’t know, it was probably the Alexa Top 500. The average web page weight is hovering around a meg right now. That’s everything. That’s styles, JavaScript, content, images.
[5:21] I definitely think there’s a real need to refocus things a little bit. I haven’t actually checked out the 1K contest at all, but it sounds pretty interesting.

Dave:

[5:31] Some developer had this profiling site. I don’t know if it was Suitors. It was a performance guide, where you could type in a URL and basically, get an overall performance, page weight, and CSS weight. Does that sound familiar to you guys?

Chris:

[5:52] You mean like a web page analyzer or something like that?

Dave:

[5:55] Yeah. I forget what it was. I don’t know if it was about Steve Suitors or somebody like that.
[6:01] I checked it out once. I checked out Pearson Education. Their CSS was 1.4 megabytes. That’s not images downloading, or anything, that’s just CSS.

Chris:

[6:15] Well, that gets into optimization, Nicole Sullivan talks about one thing she’s done. She went to Facebook and she actually found out that for, was it H2? They had restyled or redefined like eighty times. [laughter] . So she got it down on her thing.
[6:38] Yeah. It’s pretty crazy how the web is. We used to be so concerned about little file sizes, and now, people just don’t seem to care about it that much. But that’s back in the day, so that’s how the web has grown. So Ethan, can you tell us a little bit about how you got into web design and how you got to this point to where you are today?

Ethan:

[7:07] Yeah.

Chris:

[7:08] Yeah, open-ended question, I know.

Ethan:

[7:10] We only have an hour? [laughing]
[7:14] I don’t know, I guess the last decade or so can be characterized as just a series of complete accidents. I really took my first web job, well heck, I kind of fell into web design during college – just doing some random design work for various organizations and groups I was a part of. Then got my first job with the intention of taking a couple years off before grad school because I had delusions of being an English professor at some point.

Chris:

[7:44] Oh, nice!

Ethan:

[7:45] Yeah. Unfortunately, I’m in year twelve of taking a couple years off before grad school.

Dave:

[laughing] [7:51]

Ethan:

[7:55] Yeah, that’s really kind of it. I kind of fell into it by accident. I was a literature major in college, and when I got my hands on Photoshop, there was something just really gratifying about web design being concept and execution, kind of all up tied up together in this really nasty mess. You could get this idea down on a page and then it’s immediately available. I’ve always found that really appealing, so every job I’ve had, has kind of bounced back and forth between front end design and front end development, really tied up closely together.
[8:36] Every job I’ve had has been kind of like that. I’ve worked various studios in the New York and Boston area right out of school, and then worked at Harvard for a few years, when the economy got a little rocky. Went independent, and then joined up with Airbag, which became Happy Cog, and as of about a year and a half ago went independent again. I’ve been going solo ever since.

Chris:

[9:01] Those are two great studios to work for, Airbag, and then Airbag became part of Happy Cog. Those are two awesome studios to work with, but they’re founded on web standards development. You started out with Photoshop – you got into that. How did you fall into… How did you learn about web standards?

Ethan:

[9:21] It was completely by accident. At the time, I was working my first studio job as kind of like a front end developer mainly, with occasional design stuff. But you know, this is back in the day of Netscape4 and IE3, so we were coding everything twice for the two major browsers. I ended up finding, I started reading about Scott Andrew LePera’s blog, which used to be at scottandrew.com. I think it’s still there, but I think he’s more focused on the music online.
[9:53] He used to be writing about some serious JavaScript stuff that was pretty relevant to my day-to-day. He was also a really fantastic writer. It was through him I found Jeffrey Zeldman’s site, when he linked to I think it was one of Jeffrey’s travel logs for when he went and spoke in Istanbul. It was some of the best writing I’d seen, ever, and definitely some of the best writing I’d ever seen online, having only been online for a couple years. It was kind of breathtaking.

[10:27] Finding these two people I respected, as writers first, and designers and technologists second, made web standards just really compelling to me – that these people were writing for this medium, that really cared about preserving their ability to build good things for this medium. When Jeffrey starts talking about web standards, you can see he has something really deeply vested in that. I found that just crazy compelling. I bought a copy of "The Orange Book" as soon as it came out. But I’d been sold on the idea since before then. Reading "A List Apart" and zeldman.com is really what kind of got me started.

Dave:

[11:08] Speaking of "A List Apart," you’ve written for them for years, but I think probably nothing has been as influential in your writing, as that 2010 List Apart article on responsive web design, which really, given all the excitement around responsive web design today, that’s kind of watershed moment. That particular article laid out a whole new approach to design and helped us build websites for an ever growing list of browser devices, phones, tablets, desktop. Since then, you’ve been speaking about it, you wrote a book about it, you’ve been practicing responsive web design. I guess my first question is, are you just completely sick of talking about responsive web design?

Ethan:

[laughs] [11:54] No, I still find myself weirdly passionate about it. The first thing I say is, responsive design, I feel like is kind of a new name for some really old thinking. In some ways, I think of it as a spiritual sequel to John Allsopp’s, "A Dao of Web Design," which is one of my favorite pieces of writing about the web in general. I’m always kind of surprised that more people haven’t read it, because he was anticipating this device explosion all the way back in 2000.

Chris:

[12:26] Right.

Ethan:

[12:27] That we were really trying to, especially at the time, and I think even still today, try to recreate what we can do in print on the web. We’re now being forced to move out of that model because of everything we’re trying to design for and support outside the desktop. I feel like we’ve just now gotten the technology to capitalize on what he was talking about back then, that we can design for the flexibility inherent in the medium. Web responsive design is just something that feels right to me, and feels right for the projects that I’m working on for the clients that I’m working with. At least right now, I’m still finding stuff that’s really challenging, especially as I try to adopt it into my own work, and it still keeps me kind of excited right now.

Dave:

[13:19] That’s great. We don’t want to spend a ton of stuff on the basics of responsive web design, because I think it’s covered a lot, and you’ve spoken about it quite a bit in other podcasts and written about it. Maybe we can just start with a short overview for maybe some of the listeners, who are not completely familiar about what responsive web design is, and maybe a little bit about how you implement it and what problems it solves. Then we can probably dive a little bit deeper into some of the some of the thornier questions about implementing responsive web design. Does that sound good?

Ethan:

[13:53] Yeah, that sounds great, Dave. I guess at the really highest, most baseline level — well, I’m just going to go in two opposite directions with that sentence.
[laughter]

Ethan:

[14:08] I haven’t had enough coffee or sleep, apparently.
[14:11] Responsive design has three core components. It has a flexible grid-based layout, with images and media that work in that context, that are themselves flexible. Then finally, media queries from the CSS3 specification that allows us to establish areas in our design that add break points in our design, at which they might they re-present themselves for differently-sized viewports or devices, that allow us to just change the way in which that information is presented to people.

[14:44] I guess maybe on a more philosophical level, it is about adapting that more flexible nature of the medium. It’s not just about porting your desktop site down to mobile, although that’s something you definitely do. It’s more about thinking across this ever-widening chasm of devices that just seems to be yawning in front of us.

[15:05] It’s absolutely phones and tablets, but TV-based browsing is poised to explode this year. So we really do have to start thinking in, I guess, all these directions at once. I kind of feel like responsive design is one way, it’s not the only way, but one way to manage that complexity.

Dave:

[15:23] Yeah, for me it feels like responsive web design is sort of an evolution of an older concept of, we talked about liquid layouts years ago, those ones that would just grow or shrink depending on your browser width. But now we’re enabled with a few other technologies and tricks, like media queries, to really alter the layout for different devices. Some of these image tricks that you also helped pioneer. You wrote an article on, "A List Apart," about that, making scalable images that can also adapt to our devices.

Ethan:

[15:54] Yeah. I think that’s right. Well, most of the credit for the flexible images stuff goes to Richard Rudder, who’s a designer at Clearleft and one of the founders of Fontdeck. He did some stuff back in like 2004 on this stuff. My article was really around how to, I guess, not mess up the scaling in Internet Explorer.
[16:18] Yeah, but it’s really just about establishing that more flexible baseline, because the web, it doesn’t have these ideas of width and height natively. These are something that we brought to the table because we needed that control as designers. Yeah, we can’t just line up text and have it fill out to a 2,000 pixel-wide screen. I think media queries allow us that controlled, fall on to flexibility. They give us that nice middle ground, so we can have a flexible, grid-based layout, but establish break points, where it makes the most sense for our content.

Dave:

[16:59] Let’s talk a little bit about media queries, and break points too, because I’ve been seeing a lot of discussion about break points and what break points should people use? Then recently, like last week, there was a blog post, "Oh, break points are ridiculous, because there’s so many different devices. And it’s not just iPhone, blah, blah, blah." What’s your take on break points, and which ones do you use?

Chris:

[17:22] Well, you can explain what break points are, just for our listeners, who don’t know.

Ethan:

[17:26] Oh, yeah, sure. A media query basically allows us to put a little test in front of a browser that’s trying to render our design. It’s like a little conditional logic inside of our style sheets. A media query might say, is your browser window at least 400 pixels wide? Or is it lower, or is it narrower than 600 pixels wide? The browser’s going to see that media query. If it passes the test, if it’s wider than 400 or narrower than 600, then it’ll apply the CSS that’s enclosed inside the media query.
[18:02] So those break points are really kind of the areas in which our design changes based on the logic that’s set in our style sheets, or in our media queries, specifically. There’s always been a lot of question about, you know, "What break points should I use for my design?"

[18:20] I worked on, "The Boston Globe," for the better part of the last year and we used some very device-centric break points. So, like, 320, 480, 600, 768, stuff like that, you know, to correspond to most of the devices that we were kind of supporting at the time. You know, from iPhones and Android phones and tablets to Kindle, 7-inch tablets and stuff like that. We tried to choose break points that made the most sense for the content that we were designing. I think we maybe ended up with six or seven break points for the Globe.

[18:57] Not all of them were major layout shifts, some of them were really just more "tweaky" things around the edges or maybe tuning the typography of a certain range. They were really about tailoring the break points, not just to the devices, but to the content.

[19:12] Today, and for most of my work, I’ve been trying to get away from setting the break points according to devices at all and really just focusing on the needs of my content. I do a lot of resizing browser windows in a responsive design and just trying to figure out, like, "OK. So if the line feels a little too long or too narrow, or, the column feels a little too wide or too narrow, maybe I need to introduce a break point at that resolution." Maybe it’s something that feels appropriate at, let’s say, 640 pixels.

[19:44] Even more recently, some guys have been doing really great work about em-based media queries, so you can actually tie the media query to the optimum length of the line, and say that, "OK, well, once the viewport’s at least this many characters wide, we need to introduce another break point."

Chris:

[20:03] Oh, that sounds great, that sounds like an awesome solution.

Ethan:

[20:05] Yeah, yeah. The guys at Design By Front, they’re Northern Ireland, wrote about this over a year ago, called it the Goldilocks Approach.

Chris:

[20:15] Oh, wow.

Ethan:

[20:15] They were actually doing a bit more of a fix width approach, so it’s an em-based grid with em-based break points. But, Paul Robert Lloyd, who’s a designer at Clearleft, redid his site last year that’s completely responsive using em-based media queries and it’s beautiful. What I found, we did something like this, we helped launch "Contents" magazine last year. We used em-based media queries there.
[20:43] I think when you tie your media queries to the length of the content you’re actually designing, it creates this – Mark Boulton talks about this sense of connectiveness, that you know you’ve got these elements of the design that are just sort of intertwined together. It just feels much more pleasing, I think, when you’re not just thinking about, "OK well I need to support the iPhone in portrait and landscape. I need to support 7-inch tablets in portrait and landscape."

[21:09] It’s really about sort of about stepping back from that and just focusing on what’s the most appropriate way to read my content at any resolution. It’s a bit of a shift, but I don’t think it’s a big one. It’s actually been a lot of fun to experiment with.

Dave:

[21:26] So, these em-based queries… For example, if you were doing just a media query with pixels, you’d say something like "at media screen and min-width 1024 px or max width 1000 px." How does that work with ems? Is it similar? You would say min width equals 100 em?

Ethan:

[21:48] Yeah. So, if we were going to take your 1024 example, what you’re trying to do is convert some sort of pixel count, whether it’s the length of the line or whatever, to the base font size. Most browsers ship with a default font size of 16 em. That’s actually kind of your reference point. I think 1024 would be something like 64 ems or something.
[22:20] If you’re kind of looking at, let’s say, two columns of text, and the ideal length for any one of them is, let’s say 33 ems, at whatever font size they’re currently set at. Maybe they’re stacked by default below 33 ems, but above that point we could start thinking about a two column split – something like that.

Dave:

[22:48] Say you’re worried about the iPhone. How do you measure? You want it to break down to a single column, when it’s about the width of an iPhone or another mobile device like that. What em would you pick to say, "OK, now we’re going down to one column?"

Ethan:

[23:06] Yeah. So what I’ve been doing, and there are probably better ways to do this… Again, I do a lot of prototyping with resizing my browser window, which is just a really kind of a quick and dirty way to evaluate what it’s going to look like at narrower or wider window widths.
[23:23] The more testing you can do in actual devices and browsers, the better off you’re going to be. I can just eyeball the width of a column in pixels, and then convert that by dividing it by, say, 16. You know, to get an em count.

Dave:

[23:40] Mm-hmm, right.

Ethan:

[23:41] If you built the grid, and Mark Boulton’s actually been doing a lot of really interesting writing about this, about building your grid from the content out. What you’re going to hopefully find is, if your grid is founded on some basic typographic measure, some basic typographic unit from the outset anyway, then your columns are essentially going to correspond to certain known em widths, so you won’t have to do a lot of retroactive guessing.

Dave:

[24:09] Is he writing about this on his website, on markboulton.co.uk, or does he have another blog?

Ethan:

[24:14] Yeah, he’s been writing about it on his blog a bit and on Twitter, he’s @markboulton there, and I know he’s got a book coming out about designing grids for Five Simple Steps, which is his publishing house. Yeah, I can’t wait to read it. Pretty much anything that I’ve learned about grids is kind of directly attributable to Mark and to Khoi Vinh.

Dave:

[24:35] Right, yeah.

Ethan:

[24:37] Ordering Disorder book is just fantastic. Yeah, they’re much smarter than I am.
[laughter]

Dave:

[24:44] So, with media queries, device-width is one way that you can measure, right? Device-width, which is how wide the device is, and that’s something that dictates about how big the monitor is or how big the screen on your iPhone is. Then there’s just the width values, which use min and max width. Do you ever use device-width, or do you just stick with width values for media queries?

Ethan:

[25:09] I don’t use device-width all that much, really, just because again those feel so temporary to me. Like, in a year’s time, is 480 really going to be prevalent enough to be thinking about? For the most part, really since I’m setting the viewport equal to the width of the screen anyway, setting min and max width queries has really been pretty robust enough for me. Then, you’ve got the added benefit of that applying to browsers that actually can be resized.

Dave:

[25:45] Right.

Chris:

[25:46] It’s sort of like you realize that there are other mobile devices out there, but you don’t want to play favorites. You know, like, "I believe in a god, but I don’t have a particular god I praise."

Ethan:

[laughs] [26:00] Yeah, it’s all about being agnostic, I guess in some way.

Chris:

[26:07] Mobile agnostic. I’m coining it, right now. I’m trademarking "mobile agnostic."
[laughter]

Dave:

[26:13] Awesome! I’m looking forward to your "A List Apart" article, Christopher.

Chris:

[26:17] Well, it’s all going to be cite. You know, just sourcing out, copying and pasting from Ethan’s articles.

Ethan:

[26:24] I see what this is. This is advanced research.

Chris:

[26:25] Pretty much, yeah.
[laughter]

Chris:

[26:30] So, the thing about widths – I’m not great with… Well, I’m not awesome with math… My mom was a math teacher, so she’ll be turning in her grave, if I said I wasn’t good at math — is that with the rumors of iPad 3 coming out and doubling down the resolution even more, how does that play with media queries? Does it at all play with your issues with media queries?

Ethan:

[27:01] I haven’t really been as up on reading about the iPad 3 as I probably should be. For most browsers and devices that are out there, there is always this sort of intermediary pixel layer and PK has been writing a lot about this on quirksmode.org. He had this great essay about a pixel is not a pixel is not a pixel. Talking about this distinction between device specific resolution pixels, and then, this sort of what he calls "CSS Pixels."
[27:33] When I set an element in 300 pixels in my CSS, regardless of the device’s zoom level or the actual pixel density of the display, that 300 pixels is a concrete, discreet, thing. The physical size might be different from different pixel density displays, from one or the other. In theory, the iPad 3, I would imagine, is going to report the same internal browser resolution as the previous iPads do.

Dave:

[28:06] Right.

Ethan:

[28:07] If I’m setting the view port equal to the device width, it’s going to think that in horizontal mode it’s going to be 1024 pixels wide.

Chris:

[28:16] OK.

Ethan:

[28:18] Images is where things get weird, because then we have to start thinking about a level above current retina displays and bring things in there. From a layout standpoint, I believe it’s going to be basically identical.
[28:33] I look forward to your comments telling me that I really should be researching the iPad three and I am completely wrong about everything.

[laughter]

Chris:

[28:42] So you’ll just have to come back again when the iPad three comes out and we’ll talk more about it.

Ethan:

[28:45] I can’t wait.

Dave:

[28:46] So with the iPhone in CSS. if you say make this 16 pixels, is it 16 pixels or is it 32 pixels? Does the iPhone double that to compensate for the retina display.

Ethan:

[28:56] It’s 16 pixels basically. But again, there’s a distinction between the device display and the actual CSS pixels. If I use the meta viewport tag and on that page I have set the viewport equal to the device width and I just draw a blue square in CSS that’s just 16 pixels square. It’s going to look identical on an iPad 3G and an iPhone 4.

Dave:

[29:27] OK, so the iPhone 4 will essentially use 32 pixels square to draw them. Right? Are you saying they look identical in size? Or they look identical…

Ethan:

[29:39] There’s more device pixels. They’re going to look identical in size. There is definitely more hardware pixels crammed into that space, but to your eye and mine, they are going to look to be the same size.

Dave:

[29:52] Maybe we should talk a little bit about media queries and how to stack them and use them because I’ve seen some people talk about how they use a base style sheet and that’s kind of the overall look for the whole site. Then, they institute media queries that target progressively smaller devices in terms of width. Then, they sort of strip out stuff, linearize the layout. So that’s one approach.
[30:17] Then I’ve seen the approach where people say, "We’ll start with the mobile look, " and it’s one column. Then we institute media queries that build up and add layout as you get bigger. What’s your thought on that?

Ethan:

[30:32] Technically you can do either. There’s some drawbacks to doing the first approach and that approach is actually the one that I used in my first article, where I produced kind of a desktop centric fluid grid and miniaturized it down with media queries. Every media query was progressively smaller, but there was a significant amount of code at the start of each media query to override all the higher resolution rules I’d set in place.
[31:03] The more responsible approach is, I think, the second one which is where, outside of the media queries there aren’t really a lot of layout rules assumed. It’s very small screen friendly, its linear by default and your scaling up through the resolution spectrum with the media queries; 20 em, 40 em, 60 em, or if you’re using device pixel its like 320, 480, 600, sort of get wider and wider over time.

[31:34] The reason that’s a better approach is because that’s a more progressive enhancement-minded approach. Media query support’s incredibly broad right now, but its far from universal, so chances are your site is going to be accessed by browsers and devices that don’t understand media queries natively. There are some really great Java script polyfills for that. Respond.js is the one that I highly recommend. But if you’re on a device that doesn’t understand JavaScript or has an incredibly slow JavaScript parser, you shouldn’t be penalized with a desktop specific layout, if you can’t patch for media queries.

[32:21] If you’re on a JavaScript-free device that accesses the example in my "A List Apart" article, you’re going to get a desktop grid scrunched down for your screen.

Dave:

[32:34] Right, right.

Ethan:

[32:37] It’s definitely a bit of a shift thinking about that mobile-first approach, but it’s universally more – it’s ridiculously more accessible.
[32:50] When I’m building it, I’ll usually just produce the desktop design first.

Dave:

[32:55] Mm-hmm.

Ethan:

[32:56] Then go back up to the top and start doing a CSS audit, and quarantine any higher resolution rules — anything that has got anything to do with floats or widths or anything like that and media queries is kind of in lines. If I’ve got a two column layout, right after that chunk of CSS I’ll drop in a media query.

Dave:

[33:19] Right, right.

Ethan:

[33:20] These properties are only accessible above a certain range. I’ll just sort of work my way down to the bottom of the style sheet, and then, go back up to the top and consolidate all of the media queries down at the bottom. That’s kind of the way that I produce a mobile-first style sheet, even if you’re thinking about mobile-first from a content design standpoint. From a production standpoint, I found that it’s a little bit easier to just start from the other end and work down at least to get a framework in place. Then, you extend it from there.

Dave:

[33:54] Yeah, that sounds great. That seems to be more in line with the stuff I’m reading today. The stuff that people are writing about in the past few weeks where really it’s so much mobile-first stuff. That lesson, I think, is finally hitting pretty much every web developer’s brain, and they’re all starting to say, "Oh, yeah, let’s do that. Let’s start with that and then move on up." I’m wondering…You did this big design. You worked with the Filament Group right? On the Boston Globe? Is that right?

Ethan:

[34:31] Yeah, The Boston…

Dave:

[34:33] You probably did a bunch of testing around performance. That’s one of the criticisms I’ve heard of responsive web design is these worries like phones downloading giant images that they are resized to be small.

Ethan:

[34:46] Mm-hmm.

Dave:

[34:47] Maybe we could talk a little bit about performance and what you’ve learned about making optimal performance or squeezing as much performance out of responsive web design as possible. Maybe we could start with images.

Ethan:

[35:00] Yeah, well, images are definitely one of the things that are kind of an open question right now. For the Globe, really early on, we identified it as something we wanted to tackle because especially, there were some sections in the magazine, there’s some really big beautiful artwork that showed off, but these are 1200 pixel wide photos.

Chris:

[35:24] Mm-hmm.

Ethan:

[35:24] While it’s possible to shrink those down in CSS, we realized that it was going to be irresponsible. As kind of a sidebar, it’s worth pointing out that we can’t draw a correlation between the size of the screen and the amount of bandwidth available to it.

Dave:

[35:42] Mm-hmm.

Ethan:

[35:42] It’s still one of our blind spots. But, that said, smaller screens do have a tendency to be on lower bandwidth and wider screens may have a tendency to be on wider ones.

Chris:

[35:53] Right.

Ethan:

[35:54] It’s definitely far from one-to-one, but this is our assumption. The guys at the Filament Group and Scott Jehl in particular came up with this responsive images script that was kind of a gating mechanism, so that…

Dave:

[36:11] This is a server-side script you’re talking about, right?

Ethan:

[36:13] Both, actually. It was a client-side script, but it relied on a simple little rewrite rule in the CSS, to temporarily intercept any requests for images that had a certain flag in their file name. The flag in the file name wasn’t necessarily there in the file system, but it was just something in the HTML that we could intercept, kind of key off of.
[36:41] The script would basically say, "OK, well you’re above I think it was 480 pixels by default, so as a result, we’re going to serve up this wider image to you." Anything below that resolution would just get the small screen-friendly image, which was specified by default in the source anyway. We tried to conditionally enhance up, again using that really fuzzy correlation between screen size and bandwidth, but it was really the best we could do at the time.

[37:11] So, that technique was working great…

[laughter]

Chris:

[37:14] Pretty much.

Ethan:

[37:15] … Until about three weeks before launch, when a couple browsers decided to change the way that their preloaders worked.
[laughter]

Chris:

[37:22] Oh yeah, that’s right. Oh.

Ethan:

[sarcastically] [37:24] Yeah, so it was great.
[37:25] There was a chance that on certain desktop browsers, the image request would go out before the script could actually run, which meant that — and actually you can still see this on the Globe on certain pages — on certain desktop browsers, there will be a brief flash of the smaller image. Then, the larger image will pop into place. So the stated goal of basically only having one request ever be sent out from the client kind of got broken.

Chris:

[37:57] Mm-hmm.

Dave:

[37:57] Wow.

Ethan:

[37:58] Jason Grigsby, who writes at cloudfour.com, has been doing a lot of the great research into a lot of the techniques that have come up since Filament Group came up with their script.

Chris:

[38:06] Mm-hmm.

Ethan:

[38:08] Most of them, not all of them, have that kind of race condition in place right now, because there’s no standard behavior right now for browser preloaders, which is scary.
[laughter]

[38:21] I mean, it’s good that they’re trying to innovate on page speed and trying to deliver as fast an experience as possible to everyone, but it’s really hairy at the moment.

Chris:

[38:32] Right.

Ethan:

[38:34] I don’t know, his recommendation, at least right now, is that some sort of back end negotiation is probably required. I think he’s probably right. There are some, like adaptive-images.com — it’s a responsive images script that uses PHP, I think, on the back end to serve up images conditionally. But if it falls afoul of those preloader issues, then you just get the small image by default. It still only serves up that one request, so the design might not be ideal, but the result’s not bad, I guess.
[39:09] There were some back end technologies out there, but most of them rely on UA sniffing. I think that there’s a lot of work that still needs to happen there, especially if we want to solve this on the client’s side. Some people are proposing some alternate mark-up structures that would be a little bit more robust, so that you could say have some sort of picture element or whatever it’s called, with multiple sources that are served up depending on media queries.

Dave:

[39:38] I was reading on article on the Opera Developers channel today, and they said that the HTML five spec has changed to an add a media attribute to the video source tab. That’s basically what they’re doing, what they hope to do with video is basically, there’s a media query embedded in there and then you hand out a different video depending on the resolution of the device.

Ethan:

[40:02] Yeah, exactly. It’s the same sort of spirit. Again, all this, at least from the images side again, making those decisions based on screen size is just really, I guess a temporary hack. It’s the best we can do in the absence of the browser saying, "Well, this is the amount of bandwidth I have available."
[40:25] One of the things I’m kind of curious about, maybe at least in the short term, we just need to accept that there are some things we can’t fix with code. We need to ask the reader, "Would you prefer to enhance up to a higher bandwidth experience?" We want to talk about designs that are truly responsive, why not invite the reader in to actually tell us what they want? I don’t know, there’s a lot of ways to sort of solve the problem, and a lot of people much smarter than I am are thinking about it.

Chris:

[40:53] Well, I know Google Android has support for bandwidth checking, but it’s kind of, "Hey, am I on 3G? Am I on something faster?" And so, you can actually check for that. It’s not a standard, by any stretch of imagination, but I did hear that it’s… I did look into it a little bit and they said that WebKit is going to introduce it, so maybe it’ll be in the iPhone or Opera, too.
[41:25] I must throw in my two cents and say, "Hey." With Mark Grabanski, I’ve kind of hacked together an adaptive image script, where we actually check. It uses a little piece of JavaScript that says, "Hey, are you on 3G or less?" And then, we’ll just say, "Hey." The idea is that you actually just put in your mobile friendly images first, and then, if we check that you’re at a faster speed at a different resolution or whatever you have, then we come in with a higher resolution image.

[41:57] It’s kind like a play on lowsrc, we dropped that in ’97. But, basically bring it back and just saying, "Hey, well, we should flip it," and just be mobile-first.

[42:10] What I’m really interested in is the solving that bandwidth issue. That’s what really got me excited after all this work I’m trying to do with the plug-in. The browser can tell us what speed they’re coming in as, so we don’t have to do the whole asking the user to click a button and say, "Hey, you want a faster download?" We can just say, "We assume that your browser’s telling us the truth, and therefore you’re at this type of speed level. We’ll give you an experience to that, but you can always opt out of it if you want to."

Ethan:

[42:46] That’s interesting. I think that, I know there’s that navigator dot broadband, or navigator dot bandwidth string thing. Last time I looked at it, or maybe it’s changed, but I think those- I’ve always been leery of the navigator object anyway. That’s something that’s spoofed pretty easily. I think the other challenge, is that the values for that string are kind of broad.
[43:13] Well, gee, f there’s some way that we could get a much more accurate feed, whether it’s an extra header that’s sent along the server, that will be awesome. I’m with you on the preferences thing. That’s something, it feels like designers in general, and I’m definitely putting myself in this camp, feel a little allergic to that. We’ve also been doing that for a number of years. The mobile versus desktop links that have been popping up on the web for a while.

[43:47] We’ve been asking our readers to make some pretty seismic decisions about how content’s displayed to them and I’m thinking more along the lines of… I don’t know if you guys saw, Craig Mod had this really great "A List Apart" article a couple years ago about, I think he called it bibliography, these iPad templates for reading. He basically was talking a little bit about, you know, at the end of the day we don’t know how far a given device is from the reader’s eyes.

[44:16] That’s going to determine a lot of things from a typographic standpoint, like how long the length of the lines should be, what the measure should be. He called these three different reading lengths in the article, bed, knee, and breakfast – sitting in bed with a display right next to you, it’s on your knee while you’re reading on the couch, or it’s on the table sort of sitting across from you as you’re having coffee or whatever.

Dave:

[44:41] Or as you were mentioning earlier or it’s on the TV screen across the room.

Ethan:

[44:47] That’s another big blind spot for us. We don’t know how far the reader is from the screen. With a phone, it’s a fair guess that we know what’s going on. Maybe this is a point where we let the reader in a little bit, helping shape the experience. It’s not necessarily like massive style sheet changes or something. But you know maybe we need to rethink like, "OK, maybe I’ll get you a slightly wider measure," or something like that, if you’re this far away from the screen.
[45:20] I don’t know. It’s early days yet. We’re still trying to figure this stuff out, but that’s where my head’s been at a little bit lately.

Dave:

[45:27] So how about performance around CSS and these media queries? Do you have strategies, or are there techniques to prevent a mobile device from downloading CSS that doesn’t apply to it? Or background images that it won’t use? Are there techniques for scaling background images effectively, similar to the technique you used for scaling the image tag?

Ethan:

[45:51] Those are a lot of great questions. So background images. Aaron – and I’m going to completely butcher his last name, because I now realize I’ve never heard it said out loud – Aaron Mentele, I think. He is a fantastic web designer-developer. He’s been blogging a little bit about that.
[46:10] He did some tests on downloading background images and gating them with media queries. He found, for the most part, they behave as expected. That if you override the background image value in a media query, like in a later media query, that background image isn’t going to get applied.

[46:30] For the most part, I feel like it’s a problem that can be mitigated through some planning. Like if you do have that mobile-first approach and you start at the low end and then scale up, in theory. something that’s in a media query that’s like say above 768 pixels, that background image isn’t going to get applied to smaller screens.

[46:52] That said, this is something that needs to be tested thoroughly. Some browsers and devices may not necessarily queue to that. Again, behavior may not be super consistent, but that was something we really tried to adhere to. Think about it as like a layering approach. By default, your style sheet is very small-screen friendly, but then making more complex assets available at the higher end.

[47:18] For the Globe, just from a general preservation standpoint, we tried to have like a base experience that was, I guess, accessible kind of across the board. Pretty much all of our work was module driven. Just because of the number of people we had working, there were style sheets for specific sections of the site.

[47:46] On top of that base experience that was applied, we would conditionally enhance up to some other… Bring in those modules kind of conditionally via JavaScript. So that they weren’t necessarily critical, but if there were some enhancements that were in in place, at the top of every page we’d kind of assemble a unique concatenated string of CSS modules that were appropriate for that section, which were cached on the back end.

[48:13] It was really all about thinking what is the minimal amount of code that needs to be delivered to the reader, then enhance up from there.

[48:22] In terms of scaling background images, there were some CSS tricks. Well, tricks makes it sound somewhat suspect. It’s a module like background size and background cover look. Those are two.

Chris:

[48:33] Yeah, those are great.

Ethan:

[48:35] Yeah, they’re fantastic. Support’s not where we need them to be. For the most part, I haven’t had to work on too many responsive projects where that was a challenge.
[48:51] On the wider end of the resolution spectrum, there were some decent polyfills out there for those properties. Maybe that’s something you could conditionally include above a certain range. For something on the smaller end, I haven’t really encountered any elements that needed a scalable background image, again on smaller displays.

Dave:

[49:12] Mm-hmm. Right.

Ethan:

[49:13] I could totally see that being something that might be valuable. Yeah. Don’t know.
[49:20] There’s a lot of great people thinking about this right now and I think that there are tools out there. I think that we are just generally starting to talk about how responsive design works and we don’t have any of these "best practice" things yet.

Chris:

[49:36] It’s like frontier web design all over again.
[laughter]

Dave:

[49:41] Like last year, you mean? And the year before that?

Chris:

[49:47] Well, gee, I’m so old now. It’s like when I first started out just trying new things and when CSS came out. We were just trying to figure out what works and what doesn’t.
[49:58] It’s been great. Sorry, didn’t mean to cut you off. What were you going to say?

Ethan:

[50:04] There are some things that do work incredibly well, which is just generally thinking about progressive enhancement, like making no assumptions about the capabilities of your device. For us, especially on the Globe, it really helped define a strategy for building up the site that we were happy with. Thinking about, what’s the baseline experience going to be? What’s the base level of access to this content going to be? And then how can we enhance up intelligently from there?
[50:32] There are like 100 million new "feature" phones entering the market this year, I saw some really great articles about that recently, that aren’t iPhones. They aren’t the latest Android build. They’re still fantastic devices and browsers, but we can’t count on everyone having the latest and greatest all the time, so thinking intelligently about how to enhance, but starting with that baseline level of universal access, is pretty powerful stuff, I think.

Chris:

[51:00] Right. Josh Clark talks about this. He’s the author of Tapworthy, but he also talks about mobile design, and says there’s more feature phones out there than there are smartphones, even though smartphones are gaining ground and everything like that.
[51:14] But most people will have feature phones, I think just mostly for texting, and of course for phone calls too, but they also have this really basic browser experience, that we had before the iPhone. He makes that point that how would you design for those people who don’t have the latest and greatest mobile Safari experience that they have out there?

Ethan:

[51:44] Yeah.

Dave:

[51:45] Yeah, that’s jQuery Mobile, that was one of their foundational things when they were working on it, is basically, they weren’t going to just target Android and iPhone; that they realized that looking at the worldwide statistics, those are very small in the overall space of mobile devices in the world. They took on the ambitious challenge of trying to cater to hundreds of different devices, finding emulators and hardware and all this stuff and putting together a testing suite. The Filament Group, right, is involved with that. Isn’t that…?

Ethan:

[52:20] Yeah, yeah, they’re the leads on the jQuery Mobile project. Yeah, their DNA is all over how that library is built. They do fantastic work.

Chris:

[52:29] Yeah. I saw in your Flickr account that you have photos of their mobile devices and…

Ethan:

[52:36] Yeah.

Chris:

[52:37] How many do they have? I saw just tables just filled with mobile devices from all sorts of…

Ethan:

[52:43] Yeah. They counted it up. I think it was something like 55 unique devices.

Dave:

[52:48] Oh my God! Bring on the interns. OK, intern. You’re testing today.

Ethan:

[52:57] That was such a crazy, amazing resource to have on-hand, when we were working on the Globe. I think device access is such a huge challenge for us. We kind of build to what we have on hand, regardless of whether it’s desktop browsers or devices. Being able to actually bring up a design on a BlackBerry 4 device from five years ago, it’s humbling, but it’s like, people are trying to access our content on these devices whether or not we’re thinking about it.
[53:28] So it really helps inform the design process, and yeah, it was really educational. It was fantastic.

Dave:

[53:36] So maybe we can just start to wrap up and talk a little bit about, what do you think the future of responsive web design is? Obviously, it seems like it’s wide open, but do you see any areas where a lot of growth is going to happen, or where you think it’s headed?

Chris:

[53:56] I think you should sell stock right now if you own responsive web design…
[laughter]

Ethan:

[laughs] [54:01] Yeah, I’ll issue some immediately.

Chris:

[laughs] [54:04]

Ethan:

[54:06] I might be on napkins, and it might be handled by my cat, but the…

Chris:

[54:10] Your cat’s going to be rich.

Ethan:

[54:11] Yeah, I don’t know, that’s a great question. I think that, just generally speaking, I’ve always been kind of amazed by, just to sort of see what people are doing with responsive design. Even a couple of months after the article came out, designers far better than me just really took to the idea, so I’m always kind of excited to see the next cool responsive approach.
[54:35] I think that there’s some technical challenges that are still going to be overcome. Images are one, advertising is another, but those feel like, those are going to get solved in time. I think that, the other thing I’m really interested in seeing is like, the tools that we use to design for the web aren’t remotely flexible right now. I’d be interested to see how that changes, I think, and how that kind of informs the design process.

[55:03] Because right now, I’ve had to get things to a good enough state in Photoshop or in Illustrator, or what have you. Then I really need to start, I’ve started incorporating HTML and CSS in on my design process a lot more, and you know, what would a design tool look like that could maybe, I guess, build in that flexibility from the outset. That doesn’t make assumptions based on a canvas size. That you know, can reshape my design as I resize the window that I’m working in. I don’t know, it feels a little science fiction-y to me, as someone who’s been working in Photoshop since ’97, but I’d love to see what happens there.

Dave:

[55:42] Yeah I know, I think that’s great. I was actually just thinking about that this morning about this push to design in the browser makes a lot of sense. Because trying to take Photoshop to emulate CSS3 properties is like, "what a pain in the butt," when you can just be like "I’ll just apply text shadow here, instead of trying to emulate that same thing in Photoshop, I’ll just do it in my text editor and see how it looks."
[56:10] I think one problem with that approach, I think a lot of people do it, and I’m seeing lots of websites that look exactly alike. They really look boxy like they were created in a text editor, as opposed to the fluidity and the ease of experimentation that’s in like Photoshop or Fireworks brands, where you can drag stuff around and really sort of push your imagination, and then force yourself to say, "OK, how do I make that work in HTML and CSS?"

[56:39] Having some tool that could help with that whole visualization process and give us the freedom that Photoshop does, to explore, would be again, science fiction. I don’t know what it would be, but wow, that would be awesome.

Ethan:

[56:52] Yeah, no kidding. I think that, I got to imagine that folks like Adobe are thinking about designing for different devices. Obviously, the iPad’s kind of changed the way they think about designing for the web. But yeah, it would be interesting to see what comes to that whole process. Maybe, there will be some young upstart that comes up with something cool, but who knows?

Dave:

[57:17] So are you working on anything now? Any big projects, books, or top secret things that you can’t discuss? [laughter] You could just say, "yes," or "I cannot reply either in the affirmative or the negative." That works, too.

Ethan:

[57:30] The only thing I can talk about right now that I’m working on right now is just frantic keynoting. I’ve got a lot of conference travel next month, and just trying to pull some stuff together for that. But, I do have some things that I’m really excited about that might be kicking off in March, so hopefully there will be more to talk about then.

Dave:

[57:50] And how can people follow you?

Ethan:

[57:52] So I’m @beep on Twitter, and I also have a responsive design specific account on @rwd. I really have embraced the acronym, even though I don’t like it, I keep seeing real wheel drive [laughter] . My websites are ethanmarcotte.com and unstoppablerobotninja.com.

Chris:

[58:18] Awesome. Well, I think one of the key things – we can learn a lot from this past hour is that mobile web design is really just that focus on content. You start out as a literary major, and we love that what got you attracted to web standards was great writing, and the core is just great writing.
[58:43] What is writing is just being able to communicate and I think you’re doing a great job with communicating about how awesome the web is. But also, the responsive web design, so I’m really glad that you’re here to talk to us today about these great issues.

Ethan:

[58:57] Christopher, thank you so much for having me. It was really great to be part of this new podcast with the awesomest name ever.
[laughter]

Chris:

[59:06] Oh, why thank you. [Laughter]

Dave:

[59:09] All right, thanks a lot Ethan, we’ll talk to you later.

Ethan:

[59:11] All right, you guys have a great day.

Dave:

[59:12] You, too. Bye.
[background music]

Chris:

[59:17] Thanks to Ethan Marcotte for joining us on Non-Breaking Space. You can check out the show notes for this episode at nonbreakingspace.tv, where we’ll have all the links and notes from this episode. Be sure to watch for the next episode of Non-Breaking Space, where you’ll be able to hear Paul Irish say, "Yeah, I just have an extra Paul hanging out at home hacking nonstop and I’m busy traveling all over the place."
[Background music gets louder]

[59:39]

Advertisement

  • In Control Conference Orlando 2013 Mobile + Web Design Conference

The Non-Breaking Space Show is Made of People

Christopher Schmitt
Christopher Schmitt
@teleject

Web design specialist, author, speaker, conference organizer

Dave McFarland
Dave McFarland
@davemcfarland

Web developer, teacher, author of CSS: The Missing Manual, JavaScript & jQuery: The Missing Manual, and Dreamweaver: The Missing Manual

Chris Enns
Chris Enns
@ichris

A caricature of a man. Podcaster @ssktn, web nerd @lemonproduction, blogger @chrisenns.