Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, how do ya like them apples? We could not be more excited to speak with Mat Marquis, who comes to us from Bocoup, but who is also chair of the Responsive Issues Community Group. Mat, thanks for coming on the show.

Mat:

Thank you for having me, and that’s a strong Good Will Hunting reference right off the bat.

Ethan:

That is all I bring to our relationship, just topical movie references.

Mat:

Sure.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Media Temple. If you’re a web designer or developer, you need solid hosting with great customer support. Media Temple focuses on the needs of the design community, and is constantly improving their products to make hosting simple for you. That’s why they have one of the highest customer loyalty rates in the industry, with the average customer sticking around for years. If you’re looking for WordPress hosting, shared hosting, virtual private server hosting, or just want something better than a crappy $5 a month hosting plan, you want Media Temple. Go to mediatemple.net and learn about their hosting services and award winning support team. Use code RESPONSIVE to save 33% off the first three months of shared or Wordpress hosting.

Ethan:

Mat, we are really excited to have you on the show. And this is a little bit of a special episode, as you might know, because we usually frame every episode around a specific responsive redesign, but I think today we’re excited to talk to you specifically about your work as part of the Responsive Issues Community Group, which I think has some pretty wide-ranging impact for every responsive designer and developer out there today. Before we actually dive into that though, maybe you could give our audience a little bit of an introduction to Mat Marquis. Who is he? What does he do? What are his likes and dislikes?

Mat:

God, I wish I knew, ya know?

Ethan:

Yeah, how’d you get involved in this whole internet thing?

Mat:

I mean largely, if we’re being honest, I blame you.

Ethan:

Oh. Sure.

Mat:

And blame is a deliberate word choice there.

Ethan:

[laughs]

Mat:

I don’t credit you with it, surely. Well, I mean, my initial origin story of making websites is long and convoluted and can be chalked up to a lot of extraordinary luck. But I guess in terms of responsive stuff, it was largely a result of me being in the background during the initial planning of The Boston Globe project. I was kind of there because it was such an all-hands thing; I was there to pick up some of the other work that was going on at the time at Filament Group, and then I sort of weaseled my way into the Globe project itself.

Largely my role here at Bocoup is nagging, I do a lot of nagging. I occasionally storm around, you know.

Ethan:

Yeah, and, I mean, I think you’re downplaying a lot of your contributions, because I think you were a big part of getting that site launched. We’ll come back to that project in a little bit. So, tell me a little bit more about your work with Bocoup these days. I mean, since transitioning away from Filament, you’re probably overseeing a fair number of responsive projects these days. What does your role tend to be on a responsive redesign?

Mat:

Bocoup isn’t historically in the business of design, responsive web design, that sort of thing. In the past, it’s been more of a JavaScript shop—and that’s not a knock against them, they are arguably the best there is in the JavaScript business. Bocoup wrote the unit tests for JavaScript the language in JavaScript. But in terms of the “front-end” front-end, which is where my strengths are, they haven’t done a ton of work in the past. So I started here around a year and a half ago and since then I’ve been trying to build a small empire here, making this something that we specialize in, that we excel at, and I like to think we’re in pretty good shape now after a year and a half or so. We have a full design department so to speak, we’re doing a lot more accessibility work, a lot more performance work. So, largely my role here at Bocoup is nagging, I do a lot of nagging. I occasionally storm around, you know.

Enormous images scaled down visually to suit their size in the layout was tremendously wasteful, like a 2000-pixel-wide image scaled down to 300 pixels is still all the same bandwidth cost.

Ethan:

[laughs] The hallmark of a good UX designer. Nice. Well, that’s probably pretty relevant to the RICG. Could you tell us a little bit about the Responsive Issues Community Group and how it got started?

Mat:

Yeah, that actually, way down the line, evolved out of a technique we were using back on the Globe, where we realized that enormous images scaled down visually to suit their size in the layout was tremendously wasteful, like a 2000-pixel-wide image scaled down to 300 pixels is still all the same bandwidth cost as a 2000-pixel-wide image. You were there, you recall, but for everyone else, we came up with a little JavaScript that swapped a smaller image out for a larger one in larger contexts. But it wasn’t great, that initial request was still getting made, we were still serving that small image to everybody and swapping it for the larger one, which is an additional bandwidth cost here and there.

And again, I blame you, not entirely but at least in part, for some of the early conversations where we were all like, “Man, there should really be a standard around this. There should be some standardized way of doing this. I bet if we take this idea to concerned parties, they will love it and this will get built right away and shipped in browsers.” And then after about three years of mailing list arguments, it ended up happening, which is exciting.

Karen:

Mat, I did an interview with somebody awhile back where the reporter who was talking to me came in with the thesis that organizations should build an m-dot site and a t-dot site—she was a big fan of the t-dot—and then a desktop site. I think the foundation of her rather shaky argument was that it was difficult to scale images, or that different sizes of devices required different images, so that was why you needed a different website.

Mat:

I mean, I agree with the images part of that, yes.

Responsive images are a set of markup patterns that ensure more context appropriate image sources.

Karen:

[laughs] Okay, so for the benefit of all of the people out there, myself included, who don’t actually really understand the magic of responsive images, could you explain how responsive images work but explain it like you’re talking to a cat?

Mat:

[laughs] Sure… First of all, aren’t you just the cutest, you know, ‘cause cats.

So, that’s not far off. The gist is different sized viewports should be getting different image sources altogether. Not necessarily representing a different image, but rather than using one enormous image that can scale down to fit any context visually, they should all be getting ones that are more context appropriate. It should fit the size of the screen bandwidth-wise, if that makes sense. So, responsive images are a set of markup patterns that ensure more context appropriate image sources. So on a high resolution display, there’s a markup pattern that ensures you’re serving high resolution images only to displays that can take advantage of them. For lower resolution displays, it’ll use a lower resolution source. For screen width, there’s markup patterns that use media queries or some kind of convoluted syntax to determine which source is most appropriate to show for that resolution and screen size. So rather than saddling every user with an enormous image, it just means smarter delivery of image sources.

There’s a separate markup pattern that uses media queries that you can use to say above this image breakpoint, use this slightly different source, below this, use another source.

Karen:

But what happens if you need to have a different image? Like, it can’t just be a smaller version of the image, right?

Mat:

I mean in some cases, yes. Right now, there’ll be a lot of situations where we’ll just take an enormous image and scale it down visually, and there’s a markup pattern that accounts for that. But in some cases—and this is actually something that came up initially on the Globe, and this turned out to be the first proposal for a responsive images syntax—you’ll want to represent the subject of the image in a slightly different way, like different cropping or zooming or aspect ratio. And there’s a separate markup pattern that uses media queries that you can use to say above this image breakpoint, use this slightly different source, below this, use another source. It should always represent the same subject, they can’t be completely different—you know, you wouldn’t want to serve “Welcome to my phone” website as one of your sources. But it’ll serve slightly different versions of the same subject, yeah.

There’s another markup pattern altogether where you supply the browser with information about the sources and the sizes at which they’ll be displayed and you leave all the decision-making up to the browser.

Ethan:

So Mat, if I understand you correctly, basically the responsive images specification, which is a thing now, which is kind of weird and exciting, it allows us to do two things broadly: it allows us a lot of fine-grained control over which images get loaded at certain sizes of the design, but it also gives us the ability to let the browser make some of those decisions, take some of the control out of our hands, is that right?

Mat:

Yeah, absolutely. To boil it down a little bit, there’s an explicit markup pattern that says, “At this breakpoint, this source must be shown.” There’s another markup pattern altogether where you supply the browser with information about the sources and the sizes at which they’ll be displayed and you leave all the decision-making up to the browser. And it accounts for resolution, screen size, available bandwidth potentially. And that’s not even a consistent decision being made from browser to browser, browsers have the freedom to optimize in whatever way they see fit. Display-wise, the user sees no difference from one to the other, these are just scaling an identical image source that’s cut out at different sizes. In terms of the markup, we don’t know how it’s going to choose which source it displays, but ultimately it means tailored images for the user’s context.

Ethan:

So, let’s say you’re talking to me and I’m a designer and I like knowing what my design is going to be doing. What you’re describing to me in the second case where the browser is making a lot of decisions for me, that sounds kind of scary and terrifying. Why is that a good thing?

Mat:

Each image source is going to represent the subject the same way, just at a different size. The aspect ratio will be the same, you won’t be zooming in on part of the image. It’s really a developer-level concern. If there’s this very large image at this set aspect ratio and that gets scaled down to suit a smaller viewport, that still holds true using this markup. Visually, it’s exactly the same as scaling a large image down. Behind the scenes, in terms of the actual data transfer, it’s tailored to the user, so there’s really not much you have to sell. Say you’ve been given a set of comps that shows an image scaled down with the same aspect ratio across a couple of breakpoints. You’d just say, “Yeah, absolutely, I can do that.” You’ll add this markup and it’ll do it in a smarter way, but there’ll be no different on the design side.

Ethan:

Okay, so basically it’s ultimately like less work for the designer, the developer, but the net result is going to be a more appropriate image that’s going to be served to the end-user. Is that roughly correct?

Mat:

Yeah, that’s about right, with that markup pattern. If there’s a situation where you want to change the aspect ratio or something along those lines, that’s where the other markup pattern comes into play.

Ethan:

Yeah, okay, that makes sense, I like that. So, I know the advocacy that the RICG did to get a responsive images specification, let’s say it was kind of an involved process. [laughs]

Mat:

A lot of cursing, yeah.

When we say I’m the chair, I’m sort of the figurehead. I am the chief noisemaker, mostly because I am the loudest.

Ethan:

Sure, cursing, some tears, like all good things. Can you tell me a little bit about who’s in the RICG and how it functions? Who are you actually talking to? What kind of work is the organization actually doing to introduce new responsive issues and solve them?

Mat:

The RICG is very, very nebulous by design. To preface all of this, when we say I’m the chair, I’m sort of the figurehead. I don’t have any say, I don’t have veto rights over the things that the group is proposing or trying to push down the standards track. I am the chief noisemaker, mostly because I am the loudest. In terms of the organization, in terms of members of the RICG, there’s really no clear line. I mean technically there is a W3C community group that you can go and sign up for and join the mailing list and everything, but a lot of the RICG’s work takes place across IRC channels and in emails, and there’s a Slack channel for some of the Picturefill work, a polyfill for all of these markup patterns now. As far as the official group, I think we’re the largest of the W3C’s community groups. But a lot of people in the RICG aren’t formally in the RICG, a lot of this is people helping spread the word by way of Twitter, or people signed up for the RICG newsletter that are just tuning in and getting involved in some of the ongoing discussions.

It’s not people with a lot of standards experience, it’s not people representing a browser. It’s people who want things solved for their day-to-day work.

Ethan:

So it’s very much a community-driven organization, right? A lot of the groups at the W3C and the folks actually writing the standards tend to, in many cases, be actually working for browser vendors, actually writing specs that can be implemented? And it seems like the RICG is kind of like a designer/developer-led answer to that. Is that roughly accurate?

Mat:

I mean, we have a handful of browser reps too as time went on. But originally it was five, ten of us and an Etherpad, all just full-time web developers and designers hashing out some ideas for how some of this markup might work. And since then, it’s evolved into we have full-time web standards representatives, we have browser representatives involved; we have companies involved in the RICG, like Apple and Disney were signed up at one stage, I’m not sure if they’re still in there because, again, nebulous organization. But it has grown significantly, but primarily it’s made up of developers. It’s not people with a lot of standards experience, it’s not people representing a browser. It’s people who want things solved for their day-to-day work.

Ethan:

That’s interesting, because it sounds like almost like the RICG was sort of outside, to a certain extent, the standards process and it seems like you’ve moved a little bit closer to how these standards get implemented over time as people have come in a bit more. Has that changed the way that the RICG functions?

Mat:

I wouldn’t say so. I mean, we are pretty squarely outside of the usual standards process. I can share this with you since I feel like you two can keep a secret pretty well…

Ethan:

[laughs]

Mat:

…We’ve published what passes for specifications without technically the right to publish specifications, and shopped them around to the W3C and said, “Hey, take these and make these real,” which is not really a thing that the community groups are supposed to be doing, it’s more a place for discussion so that the standards bodies concerned can go on and write the spec. But even further than that, like as a community group, we have built a lot of these features into browsers, we’ve written the code that makes these things actually happen, which is way outside of the normal purview of even a full-fledged standards group. So, we’re kind of Pirate Radio a little bit. We’ve formalized some since, but not 100%.

We have broadened our sights somewhat, but it’s still pretty focused on issues specific to responsive web design that are troubling developers and designers day-to-day.

Ethan:

So, the RICG started as the Responsive Images Community Group. Once you actually shipped a responsive images specification and it actually got implemented in most browsers, the focus shifted, right? I mean, it’s no longer the responsive images community group, it’s the responsive issues community group. It sounds like the scope has broadened a little bit. Can you tell me about what the group is working on and how that transition is going?

Mat:

Sure. There is still a lot of maintenance with the images stuff. We’re largely not making any updates to the specs or anything, those are pretty much set. But we are still maintaining polyfills, we’re still tracking bugs on native implementations, and a few of us are shipping native code still, working on some of these issues. But for the most part, after a handful of native implementations were out the door, there was kind of a lull where we could largely consider images to be settled, we accomplished the thing that we wanted to accomplish. But at that point, we’d gained some clout in web standards. You know, we were a relatively large organization, we had people who were dedicated to updating specs and updating native browser code, and it seemed at that point like a shame to just pack up and walk away, like, “Okay, cool, we’re done with images, have a good one, everybody.”

So we have broadened our sights somewhat, but it’s still pretty focused on issues specific to responsive web design that are troubling developers and designers day-to-day. We don’t want to branch out too far from that original purpose because, again, we are largely a set of designers and developers ourselves and it feels like we’re in a good position to determine what some of those bigger issues are.

Ethan:

Can you give me an example of one of them?

Mat:

I sure can, Ethan. We’re currently sort of dancing around the issue of container queries, which I wrote about a little bit for A List Apart a while back. To simplify it some, it’s media queries for individual elements within a page. So you can say if the parent of this element is below or above this size, change the styles accordingly.

Ethan:

That sounds cool. Why would I want that?

Mat:

Hm… I should have really prepared for this more.

Ethan:

[laughs] One of the things we’ve been talking a lot about in the podcast with folks, everyone from Capital One on up to Fidelity and a few other guests—Virgin America is another good example—is they’ve really been moving toward more of a module-based view of their design systems, right? We’re not really think about pages anymore, we’re thinking about how these individual components can be kind of reused. Would you say that’s been part of the process or driving the need for element queries or container queries, whatever they happened to be called?

Mat:

I think most of this arose out of the browser viewport being insufficient to make styling decisions for individual modules. For the larger page layout, sizing things according to the viewport makes perfect sense. For an individual module within that page-level layout, you may want to drag something from a larger content area over into a sidebar and have that respond to the width of the sidebar rather than the width of the viewport. Not being able to do that seems like a pretty big failing in terms of CSS.

Karen:

Let me ask you a general question, Mat, about how does this work that you’re doing with the RICG, how does that intersect with some of the client work that you do? What kind of client engagements do you work on and what do you do when you’re working on them?

Mat:

I’m a very performance-focused developer, so it’s a lot of bragging rights. If I can go in and say, “Hey, I can make a very lean, very fast website”… A big part of that is images. Images make up—I forget what the statistic is now, but I feel like it’s something like 80% of the average website in terms of transfer size. So that’s very low-hanging fruit in terms of making a site more performant, lowering a transfer over the wire. It’s nice to be able to go into a client engagement and say, “Hey, I was involved in writing that spec. I know exactly what it is you’re trying to accomplish because we’ve spoken with hundreds, maybe thousands of developers and organizations that have this same problem. We’re able to help with that now thanks to this standard.”

Because we do this day in, day out, because we’re good at performance, this is just sort of the way we work, this is the way we’re tuned to do this stuff.

Ethan:

How do you find you’re usually talking to clients about performance?

Karen:

Yeah, how do you convince people that performance is important? When clients come and talk to you and they’re like, “Hey, we want our website to be faster,” what are the problems you run into?

Mat:

I would say usually it doesn’t take a lot of convincing. When we have a client engagement where a line item isn’t, “Hey, make the website fast,” it doesn’t take much doing to stress the importance of, “Hey, your website should be fast.” There’s no shortage of statistics proving a faster website is a better website in terms of user engagement, in terms of conversion if you’re selling things. That’s usually pretty open and shut.

The bigger sell there is saying we don’t need to turn this into a separate line item, we don’t need to say, “Hey, tack on four weeks at the end of the project for performance so we can retrofit this with fastness.” The tougher part is saying, “Because we do this day in, day out, because we’re good at performance, this is just sort of the way we work, this is the way we’re tuned to do this stuff.” When we’re writing a template, we don’t use an enormous image and then remember to go back after the fact and replace it with the responsive images markup. Because this is so second nature, this is something that we just do. This is baked right into the browser, this is just how images are done now on the web, which is exciting. I mean anywhere we can sneak in performance without turning it into a whole, “We need to write a separate script, we need to come up with a loading pattern, we need to override the way the browser does this thing,” anywhere we can say, “Hey, this is just how the web works, this is new technology, it’s native to browsers and it’s faster” usually goes over pretty well with clients.

Karen:

I’ve worked with lots of clients, and I’ve talked to some people this weekend that said a lot of organizations are really hot on the idea of having a faster website until it comes to the place where they’ve got to make tough choices, like they’ve got to not put so many fonts on the page or they’ve got to not have those giant images. How do you manage that as you go through the whole process? How do you keep them focused on performance?

Mat:

I try not to impose a lot of limitations along those lines. I try not to say, “You’re only allowed one big image per page” mostly because I find those rules are doomed to fail as soon as I disappear from a project. Eventually someone is going to prioritize “We need this second big image, we need this carousel, we need this mission critical Flash intro” while I’m not around anymore, and that is now how the website works.

I think it’s on us as developers to come up with smart ways of mitigating those issues as much as possible. And that’s largely how this responsive images markup came about, is that we wanted to make this seamless, we wanted to make this something that you could automate in your CMS. So when you upload an enormous image, even if there’s three, four on a page, the CMS knows to output this markup and to create different crops of the images behind the scenes. So even though we can’t say, “Make sure there’s only one image and make the page as small as possible,” we can still mitigate the damage that would be done by adding a lot of things, you know what I mean?

Ethan:

That makes sense. Well Mat, I’ve got to say, it’s been great having you on the show, but just before we let you go, I’d really love to know, do you have any advice for either designers or developers or maybe large organizations who might be going responsive? What’s the one thing that you try to keep front in mind when you are working on a new responsive project? You can be as deep in the weeds as you want, but I’d just love to hear how you start thinking about this stuff.

Mat:

I don’t want to go too philosophical on ya here…

Ethan:

[laughs] Bring it on.

Mat:

I’m a very firm believer in the idea that the web is pretty good. And by that, I mean it’s pretty flexible until we start messing with it; it’s pretty accessible until we break that; it’s fast until we make it slow. I am a big advocate, no matter what the project is, no matter how big the organization is, no matter how complex the website might be, I am a big fan of keeping things as simple as possible. Anything solvable at the browser level, that’s the best place to do it.

Karen:

Mat, it’s been great having you on the show. We think you’re fantastic.

Mat:

: I think you guys are fantastic, too. Thank you for having me.

Karen:

: We think you’re better.

Mat:

Is that true?

Karen:

It is.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Media Temple. Go to mediatemple.net for easy to use hosting and 24/7 customer support.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.