The Challenges of Responsive Web Design, with Ethan Marcotte

In this episode of the Versioning Show, David and Tim are joined by Ethan Marcotte, a well-known designer who coined the term Responsive Web Design. They discuss the inspirations behind responsive design, the challenge of tailoring content to users, the advantages of responsive prototypes over static comps, and dealing with self doubt.

Show Notes

• Ethan Marcotte on Twitter: @beep
• Ethan’s RWD Twitter account
• ethanmarcotte.com
• Ethan’s colleague Karen McGrane
• media queries
• element queries
• A Dao of Web Design
• Ethan’s landmark Responsive Web Design article for A List Apart
• The Boston Globe
• Filament Group
• Ethan and Karen’s Responsive Web Design podcast
• BBC News on the Responsive Web Design podcast
• Ethan’s book Responsive Web Design
• Ethan’s book Responsive Design: Patterns & Principles
• Brad Frost on carousels
• Boba Fett
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

Basically, at the end of the day, it’s about assuming that there’s no perfect view of your design — that we can create these layouts that don’t have an ideal width and height; that no matter how small or how wide your screen happens to be, we can create these really beautiful, device-agnostic layouts for the web.

---

I started getting more requests in client contracts for building an iPhone website, which was kind of weird. That just started getting me thinking, well, what’s the next website that we’re going to have to build? At some point, some other new cool thing is going to emerge on the mobile web. This doesn’t scale especially well.

---

I met a publishing deadline, and I thought that was going to be the end of it. And folks just really ran with the idea. They started redesigning their websites, making them more responsive. I started seeing agencies going responsive, and then bringing the solution to their clients, and eventually I think that just trickled up the ladder.

---

they started talking about all the business benefits that they saw from that, and publishing those metrics and that data. And that made a lot of people in the media and publishing space sit up and take notice and that was really exciting to see.

---

the design partner never showed their client at Virgin America a static comp. Basically, from their very first meeting, they had a responsive prototype — in a very early stage, but they had a prototype that everyone could load up on different browsers, on different devices. And there’s something really transformative about that idea.

---

comps can’t tell you what, first of all, the layout is going to do. There are pictures of a website, but what happens if a browser doesn’t have support for web fonts, or what if there’s a network error and some critical asset doesn’t download, or what if the browser doesn’t understand JavaScript, or the latency is too high so it doesn’t execute — or something like that.

---

rather than building all these rats’ nests of media queries that deal with all these different layout condition cases that I have to plan for responsively, if I could just have something that’s like, OK, given the width of this container, I want to apply this design rules to this one particular module, that would be huge, and I think it would probably replace a good chunk of the media queries that I write today.

---

I feel like responsive design is just something I apologize for!

Transcript

Tim:

Hey, what’s up, everybody? This is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number 16 of the Versioning Podcast.

David:

This is a place where we get together to discuss the industry of the web from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

Today, we have with us Ethan Marcotte, who I guess invented Responsive Design (or whatever!), and so we’re going to talk to him all about that and some of the really cool contributions he’s made to the web. So let’s go ahead and get this version started.

Ethan, thanks so much for joining us today. How are you doing?

Ethan:

Yeah, Tim, good. It’s good to be here with you and David. Thanks for having me.

Tim:

Awesome. I’m very excited to meet you, and to get the show started, one of the things we like to do with each of our guests is ask a philosophical question, and your philosophical question for the day — since this is the Versioning Show — is: in your current career, what version are you, and why?

Ethan:

Man, I was expecting something on the order of like Batman versus Boba Fett, philosophy-wise.

Tim:

We’ll get to that a little bit later.

[Laughter]

Ethan:

Fair enough. I don’t know. Does anybody say that they’re not in perpetual beta? I’m in pre-release mode, let’s say that.

Tim:

Very cool, very cool. Everybody’s given a different answer, which is just amazing.

Ethan:

Ah, nice, nice.

Tim:

You are the person who invented the concept of responsive design — or at least gave it a name, right?

Ethan:

Yeah, I like to say I coined the term, because what I really did was I brought a couple different techniques, I think, under one umbrella — flexible grids, which is like the workhorse of responsive design. I think that’s the one I had more of a direct hand in actually shaping, but the other two, like flexible grids and media queries, obviously like those preceded my work. I like to think of responsive design as basically just like a rallying cry to bring us around to this idea of more flexible, more device-agnostic design.

Tim:

I think a lot of people have heard the term, and it gets thrown around and applied to a lot of things, but for people who might not be as comfortable with that concept, or who might be new to the term or not have heard it, how would you define responsive design for the typical web developer audience — web developer and designer, for that matter?

Ethan:

That’s a great question. I do a lot of consulting and workshops, some of them with Karen McGrane, a good friend and colleague of mine. When we go in-house somewhere, there’s always a lot of excitement around this term responsive design, but there’s sometimes a lot of varying definitions about what it means. So at the end of the day, in its barest form, a responsive layout is a web-based layout that uses flexible layouts — basically layouts that are defined in percentages or proportions rather than hard, inflexible pixels, and then they have images in media that are flexible themselves, that work in those flexible grids.

Then, finally, the third ingredient is media queries, which are basically like a little bit of pixie dust from CSS3 that allows us to articulate when and how those layouts need to change and adapt based on different conditions — and more commonly, those are based on the size of the viewport. You could basically have these layouts that are re-presenting information or changing their hierarchy or effectively responding to the changing shape of browser window or device’s display. Basically, at the end of the day, it’s about assuming that there’s no perfect view of your design — that we can create these layouts that don’t have an ideal width and height; that no matter how small or how wide your screen happens to be, we can create these really beautiful, device-agnostic layouts for the web.

Tim:

Excellent, excellent summary. Speaking of which, I’m wondering when you were first thinking about this concept, how did this idea just get into your head? Do you want to talk about the origin story for you in responsive design?

Ethan [3:46]:

Yeah, I can give it a shot. I mean, if we’re talking about versions of things — and I’m in perpetual beta — I think the idea of responsive design was a really long time coming. There was a single aha moment, at the end, when I was working on this talk — this first talk where I coined the term. But I’d been a huge fan of thinking about the web as a completely flexible design medium pretty much since I started. This was back in the late ’90s, early 2000s. A big inspiration on my thoughts about web design was this article called A Dao of Web Design, which was written by a man named John Allsopp all the way back in 2000.

And I speak at a lot of conferences, and I work with a lot of companies, and when I ask folks if they’ve read this article, not a lot of hands go up, because it’s more than three weeks old on the web (that’s like ancient history)! [Chuckles] I still think it’s actually one of the more like prescient and I think more relevant pieces about the web as a design medium — even today — because John’s basically talking about how our early ways of thinking about the web were basically treating it like a piece of paper. In Photoshop or Illustrator, we’d create a canvas, we’d create a document that had a fixed width and height, and then we’d try to translate that width and height onto the screen, which is completely flexible.

I mean, the screen itself has constraints, but the viewport — the actual browser window — we can’t predict its size or shape. So he was basically arguing that we should really try to treat the web as a completely unique medium, and design more flexibly for it. This being back in 2000, when 4.0 browsers were the new hotness that we could look at. We didn’t have a lot of tools to actually capitalize on what John was talking about. So I would do a lot of flexible layouts for my own projects, for my blog (back when I had updated mine), for side projects. But for most of my professional work, it was really very fixed-width layouts.

Mobile then came along and broke everything. In the early days of mobile — at least in more developed markets — we were repeating the same process. It’s like we’re going to have the desktop website because we understood the desktop web, and then we were going to have the stand alone m.dot site, this mobile website. I started getting more requests in client contracts for building an iPhone website, which was kind of weird. That just started getting me thinking, well, what’s the next website that we’re going to have to build? At some point, some other new cool thing is going to emerge on the mobile web. This doesn’t scale especially well.

That’s where I started playing around with fluid grids for a couple of client projects, and media query support was finally getting to a point — both on desktop and the mobile — where we could actually have our cake and eat it too. We could design these flexible layouts but still introduce a slight measure of control with media queries to articulate how to make these flexible layouts look beautiful on small and large screens.

Tim:

When you were looking at this, were you coming at this more from a design perspective, more from an engineering perspective? What background were you bringing to this?

Ethan:

Oh man, I’m still trying to figure that out! [Laughs] I think it’s both, really. I mean, I’ve never really fit perfectly on either side of that equation. Depending on the role of a project, I’ll be either a front-end development lead or taking point on design. The particular project that I was hashing this stuff out on I was a design lead on this completely flexible grid-based layout, and then a little bit later on I was working on that iPhone-only website as a front-end developer, and realizing that these two things don’t necessarily need to be completely opposed. I think we can again think about one layout, and think more flexibly about it from an aesthetic standpoint, but also conserving our effort a little bit, not necessarily forking our experiences every time there’s a cool new device that hits the marketplace.

David:

It’s interesting. Not everybody can really come at a project from both a design and an engineering perspective. And I think there was confusion early on about do you call yourself a web designer, do you call yourself a web developer, is there even a difference? And of course now, that’s much, much more clearly broken down into two distinct professions, but it’s very important to be able I think for you to bridge the gap between those.

Ethan:

I think that’s true for anybody who primarily identifies as a front-end developer or front-end designer. I think that especially in any team environment, we’re getting to a point now where the number of devices and screens we’re designing for — I think those two disciplines really need to be collaborating more closely. When I’ve been a front-end lead, the best designers that I’ve worked with could maybe toss out some rough prototyping ideas in HTML and CSS. It may not necessarily be production-ready, but they could at least really effectively more clearly communicate their ideas to me.

And you know, on the other side of the spectrum from a front-end design lead, I’m working with the developer. If they understand how to make recommendations about how the typography might need to change across different breakpoints, or maybe make some recommendations about how the layout might need to shift, I think that’s pretty powerful stuff.

Tim [8:23]:

So, Ethan, one of the things that I think really contributed to the success of the responsive design movement is the ability of the industry to convince business leaders that responsive design was worth it. Do you want to speak a little bit to how that process folded out, and what, if anything, you learned throughout doing that?

Ethan:

Yeah, that’s a great question, Tim. I think for me, I can’t take credit for that transition. I think there were a lot of people contributing to that discussion — and still are, frankly. I think there was a lot of excitement about responsive design when I first published that article on A List Apart, and I’m still overwhelmed by that, frankly. I met a publishing deadline, and I thought that was going to be the end of it. And folks just really ran with the idea. They started redesigning their websites, making them more responsive. I started seeing agencies going responsive, and then bringing the solution to their clients, and eventually I think that just trickled up the ladder.

The same thing happened back in the mid 2000s, when we were really starting to argue for CSS instead of table-driven layouts. You see this discussion happening at the fringes of the community, from independent designers and developers, and then it started getting some mainstream traction. I will say that I was involved with a much larger team of people on the responsive redesign of The Boston Globe back in 2010, 2011. I think at that point we had a client — who was not a small publisher — who was super excited about this idea of going responsive, and how they saw it as a business imperative for them.

When we took that live, they started talking about all the business benefits that they saw from that, and publishing those metrics and that data. And that made a lot of people in the media and publishing space sit up and take notice and that was really exciting to see. I think that that’s a pattern that’s been repeated throughout the industry: when a company goes responsive and starts talking about all the lift they saw on mobile versus their old desktop-only website, or whatever, that makes other people in that space sit up and take notice and get more excited about going responsive.

Tim:

Responsive puts a lot more responsibility on the designers as well, and also on the people developing the content. And I know one of the things that people get a little bit confused about with responsive is the idea that you’re presenting exactly the same information to different audiences. Can you talk a little bit about that?

Ethan:

Sure. For me at least, I mean, responsive design is like — at the end of the day it’s a cheap way to design for as many devices and browsers as possible. It’s a flexible layout. It doesn’t have an ideal shape, so by default that layout is going to expand and contract across all sorts of different screen sizes. That’s the foundation. I think, anything on top of that you can then look for those opportunities to really enhance the experience a little bit more. I mentioned my colleague and friend earlier, Karen McGrane, and she’s been talking a lot about this idea of adaptive content, where looking for opportunities based on business or strategic needs to tailor the presentation of information based on certain contextual clues.

When she says context, she’s not necessarily talking about the kind of device that they are using. It’s more about, how we can adapt this information based on what we actually know about this person — independent of the device. I think that that’s where things get really powerful. If you can have that flexible responsive foundation, but then tailor the information in a way that’s meaningful to the user, regardless of what device they happen to have closest at hand, I think that’s where things get really powerful. When we start thinking that different devices need different information, that’s where things get a little bit fuzzy.

Tim:

I wanted to talk about that real quickly, because one of the things that in my work I find most difficult to translate to both stakeholders and designers is the idea that you really shouldn’t be trying to present different content based on just the width of the screen. Do you want to talk about how maybe you find those contextual clues, or what are the ways you’re really thinking about delivering that tailored information to the user?

Ethan [12:08]:

Yeah, sure. I mean, I can speak for my own experience that when I’ve been part of those discussions about how we need to maybe rethink our presentation based on the size of the screen, that’s usually an artifact of a very desktop-focused design process, or at least when I’ve encountered it. Having those discussions that, OK, this infographic or this table doesn’t necessarily fit on small screens, so maybe we need to think about how we’re going to adapt it to make it fit on mobile. I think a much more powerful approach is to actually — and it’s harder, in some cases — but you know, adopting a more mobile-focused mindset, and structuring things about really getting things onto the small screen and thinking about the needs of the small screen first, and then enhancing up from there.

Karen and I have a responsive design podcast, and this is a refrain that we’ve heard from a lot of different companies. Virgin America is maybe my favorite example of this, where they basically said that they never showed their client at Virgin America — the design partner never showed their client at Virgin America a static comp. Basically, from their very first meeting, they had a responsive prototype — in a very early stage, but they had a prototype that everyone could load up on different browsers, on different devices. And there’s something really transformative about that idea.

If you can actually get a design quite literally in somebody’s hand, I think that eliminates a lot of ambiguity about how we’re going to start thinking about mobile, because it really puts it directly in their hand. Whenever possible, I think moving into prototypes has been a really helpful way to have that discussion as early as possible, but it’s a big challenge — especially since so many of our design tools live on the desktop.

David:

I wanted to ask you actually about that, because the conversation between designers and developers about how to build these things becomes much more complex when you’re talking about responsive situation. How do you recommend designers and developers work together on these things?

Ethan:

That’s a great question, and I think that — at least in my experience — I think a large part of the solution really comes down to constant, frequent communication. I think the old, very waterfall-driven approach to design and development, is really like, OK, we’re going to finish the comps. We’re going to get them signed off, and we’re going to hand them off to the front-end developers — which is quite literally what happened for us on The Boston Globe redesigned. Basically, The Boston Globe signed off on this beautiful array of comps that have been designed in InDesign. Then myself and Filament Group — who’s an interaction design firm based here in Boston — we were brought on board to make this thing responsive.

One of the first meetings we had with The Globe at that point was like, The design isn’t finished at this point. These comps are a catalog of assumptions, and they are very good, well-researched and beautifully executed assumptions, but comps can’t tell you what, first of all, the layout is going to do. There are pictures of a website, but what happens if a browser doesn’t have support for web fonts, or what if there’s a network error and some critical asset doesn’t download, or what if the browser doesn’t understand JavaScript, or the latency is too high so it doesn’t execute — or something like that. We basically need to continue the design process in the prototyping phase, and vet these assumptions in actual live web design, in an actual web-ready document.

They were super receptive to that, which was surprising, and kind of exciting. [Chuckles] They were fantastically supportive about that, but that was also really helpful for getting a model in place where the design partners who headed up the design up until that point were actually collaborating with us. So we would get things in the responsive prototype and see where things maybe didn’t necessary work well in a flexible context. And then they could sort of decamp, and maybe take a part of that particular piece of the design, and work just on that particular pattern, and then come back and make some recommendations about how it could potentially adapt, and then we’d fold that back into the prototype.

I think, generally speaking, this is a refrain I’ve heard from a lot of organizations — that integrated design and development efforts always result in a much, much stronger product. Even the BBC (who we had on the podcast last year talking about their global news redesign), they basically said the same thing — that thinking about UX and design as a separate practice from engineering and development, it actually slows down your velocity. You should be able to take design and learn from it once it’s actually being implemented, seeing what works and what doesn’t and then folding it back into the design process. Bringing those two camps closer together I think is absolutely critical, but that’s also a big shift for a lot of companies.

Tim [16:28]:

Speaking about big shift for a lot of companies, in your mind, do you see the push for responsive design as something that is over, or no longer needed to really fight for, like it’s just an accepted practice now?

Ethan:

O, well — if it is, I’m still hearing a lot of questions from a lot of companies about whether or not it’s right approach for them. So at least in my tiny little purview, there’s still a lot of questions about it.

I will say that at least it’s something that’s being considered more often from the outside, on most projects. So even if it’s not necessarily like seen as the default approach, or maybe seen as question-free, it’s not something that we have to justify from the outset. There’s an ample amount of data when I’m talking to a large media company. They can look at Disney.com, for example, or Virgin America, and see the work that they’ve done, and then they can start having a conversation about whether or not it’s the right one for them.

David:

One of the things that I’ve noticed about the way that you’ve worked, you came up with this — you recognized the need for it — and the community really seems to have been a very important part about getting this spread out to people. I’m curious about how you became engaged in the community, and how you started publishing your information.

Ethan:

That’s a great question. One of the first things I try to tell anyone is like I don’t feel like I own this discussion anymore than anybody else who’s contributing to it right now. I have an RWD Twitter account, where I publish links to things that I’ve written, or to our podcast. But it’s also I think — for me, at least, as somebody who’s watching responsive design develop and change over time — I’m trying to promote as many different voices as possible.

I would say Twitter is maybe the primary way that I figure out new layout techniques, new design considerations, new questions and criticisms that are coming up around responsive design. And then I try to make sure that as many folks are aware of those other discussions as possible. That’s important for me, because I really feel like I’m a working designer and developer who’s learning about responsive design along with everyone else. I really like sharing that platform with as many people as possible.

David:

And I noticed you followed up your original book with another book, on patterns and principles, which I haven’t read yet. But I’m curious about why you felt the need to do a follow-up book?

Ethan:

Yeah, I’m still trying to figure that out! [Laughter] Never write a book, kids: it’s terrible. It’s a wonderful, horrible experience.

No, I mean, working on both of those books was actually a really rewarding experience, but I think any writing project is really difficult for me — especially in the middle of it. I like to say that a writing project is the best way to get as much self doubt as possible over the longest period of time possible, and that’s definitely true for those two books.

But I’m really proud of them. The second one that you asked about was about patterns — little reusable parts of design. And the book was really driven by the fact that most of the questions that I get either on Twitter or through my website aren’t really about, OK, how do we build responsive page layouts anymore?

The top-level grid thing I think a lot of folks are pretty comfortable with. But questions about, How do I manage fixed-width display advertising in a responsive design, or other kinds of third party content? Or What are some different approaches for managing response navigation systems? It’s really like moved down a level, especially as we’ve started embracing more talk about pattern libraries, or style guides (or whatever your team happens to call them), and really looking at these as small, responsive layout systems themselves that have their own breakpoints and their own needs for change.

So, that’s really where the second book came from. It’s structured in a way to look at some of those specific design challenges, but also talk about why they may or may not be successful for certain kinds of context of use, or why that team may have chosen that approach.

So, rather than thinking about it as a copy-and-paste pattern book, it’s really trying to look at the underlying design principles that made that team decide whether or not that was the right approach for them. Because I think the principles thing has become such a bigger part of my practice lately. It’s like, we can make pretty much anything fit in a responsive canvas, but it’s having the tools and the principles in place to know why something is a good solution, or to identify what are the tradeoffs to this particular approach.

Tim [20:30]:

So, speaking of problem solving for the web, you’ve invented responsive design and solved a host of problems that exist around that medium, as well as your focus on content. Is there another problem that you have your eyes on solving? [Laughter] You know — inventing a giant solution that takes over the globe.

Ethan:

Right, right, yeah. I don’t know, I feel like responsive design is just something I apologize for! [Laughs] Sorry folks, this stuff was easy before: we designed our 1024 websites, and could go home at the end of the day. But I think the biggest thing — both from a design and from an engineering standpoint that I’m really excited about — is this idea of element queries (or container queries). I feel like that’s the next … I would love to see some traction on that — from either the CSS Working Group, or from a couple of browser vendors about tackling that problem.

I fully admit it’s a big problem, but as my work has gotten so much more modular and looking at little tiny reusable pieces of design that could live potentially anywhere in a layout at different breakpoints, something like that would be an amazing tool. So rather than building all these rats’ nests of media queries that deal with all these different layout condition cases that I have to plan for responsively, if I could just have something that’s like, OK, given the width of this container, I want to apply this design rules to this one particular module, that would be huge, and I think it would probably replace a good chunk of the media queries that I write today.

David:

Interesting. It’s constantly evolving, because once that’s around, maybe you’ll can find something else, and new media that we need to support, and it will just become another more complex problem.

Ethan:

Yeah, no kidding. This is the best and worst thing about this job, right? The web never stops changing!

David:

I’m going to consider it the best.

Ethan:

Yeah.

David:

So, while the web is continuing to change, how can our listeners find out more about you and what you’ve been writing about.

Ethan:

Thanks for asking. My name is Ethan Marcotte. You can find me on my website, ethanmarcotte.com which is woefully out of date, but hopefully getting changed soon. Otherwise, Twitter is probably the best way to contact me — @beep on Twitter, or @RWD for responsive web design — although I keep thinking of rear-wheel drive whenever I see that acronym. Those are the best places to find me.

Tim:

Beep is the best Twitter handle ever.

[Laughter]

Tim:

Also, out of all the people who post GIFs on Twitter, Ethan, I think you have the trophy for all time best GIF user of Twitter — in the history of Twitter.

Ethan:

[Laughs] You are both very kind. I stand on the shoulder of GIF giants. Beep is a place where I have fun, and then RWD is a place where I talk about what’s next with responsive.

Tim:

Awesome. It’s been really fun chatting with you today. Thank you so much for joining us and sharing all your wisdom with our listeners.

Ethan:

It has been a real honor. Thank you so much to both of you for having me.

[Musical interlude]

Tim:

It’s not every day you get to have someone on the show who invented a part of our careers that we use every single day.

David:

Something so elemental to the work that we’re all doing constantly.

Tim:

Yeah — he’s so humble about it, too.

David:

It sounds like it struck him because it was something he needed in his own work, and he recognized that it was not only something he was going to need, but it was something that the rest of the web is going to benefit from as well. We can just be so grateful that he was willing to share that insight right from the very start.

Tim:

It really speaks to the strength of the community, and this industry. Because without that, you can’t really say that responsive design really would have taken off. It’s a genius concept, and it solves so many problems. But you really need a large voice to get behind this idea and run with it.

That, I think, is the most fascinating thing about the responsive movement to me — that it works to convince the people who essentially had the money and employed the teams to do all of this work. The Boston Globe was convinced to go ahead with responsive design, and it worked. Without those sorts of victories, it might just be another one of those things that we’re like, Yeah, we can do this thing, but we can’t convince everybody else that it’s important.

David [24:34]:

It has such a broad implications for the work that people are doing. There’s a real financial investment that a company needs to make in shifting that mindset. It’s not even just the money; it’s also getting that philosophy all the way up the chain, up to the executives who have to approve these things and make sure that everything that is going out meets their expectations. If they’re not thinking about why does this needs to be responsive, why do I need to reach this different audience, how is this different audience going to think about this content differently, and why does it need to be presented differently? — that’s an education process that has to happen inside of an organization. It wouldn’t be possible, I don’t think, without a core term like responsive design that people can center around.

Tim:

Yeah, the name was perfect. And speaking about the philosophy, it really is a hard shift to make, especially if you came into this industry making fixed-width designs. I mean, you’re coming from this medium of you just translate exactly what you’re seeing onto another medium, and it stays that way. That’s really not the case. I mean, essentially, when you make a design in your responsive mental model, the design you make is your best-case scenario: then there are just thousands of use cases around that.

It’s not necessarily the design; it’s the content that you really need to focus on. And the content somehow moves — which moving stuff is suddenly this thing that you’ve never really had to ever consider before. It really is this difficult mental model to wrap your head around, and I’m still running into things that — I’ll approach a new project, and like, Oh my goodness, I never thought of how this thing could move, or how this small constraint could happen. It really is a tough thing to introduce to a host of people, both technical and non-technical.

David:

It’s true. I mean, I’m old enough that I remember when I was developing content to be printed on dead trees. Remember that? [Laughter]

Tim:

Oh man.

David:

There was this philosophy about article writings. I was doing internal communications. We were producing a newsletter, and that newsletter was printed, on paper, and distributed to thousands of employees all around the world. The concept was, you write your articles as an inverted funnel, so that you put the most important things at the top, and then as you go, you get to the less and less and less important things — and that way, when the person who’s doing the layout, to fit into the box that will be available on the piece of paper that will be distributed, has to edit what you have, they can chop the last couple of paragraphs off and not lose anything valuable. It’s a completely different philosophy, just from a content perspective. Responsive design brings together that concept of the design has to adapt, the content has to adapt, to these different platforms.

Tim:

I really like how the idea of responsive design gave birth to other movements. I mean, if you think about it, responsive design was this renaissance period of thinking about the user. Right? At first we were just like, Here’s the thing, and here’s how you get to view it. And then suddenly we started to say, Wait, how do you best want to view it, based off of what you have available to you? Then we started thinking about, All right, we got that part: it squishes into whatever you’re trying to view the thing from. But then we started to think about, How does that thing work for you? Does it require too much from the device that you’re trying to view it from?

You see this very smooth transition from responsive design into the idea of performant web design, or designing for performance. It’s really interesting to see how that takes shape. I mean, the performance movement is newer still, and there’s still so many things — I mean, we spoke about it in the last episode, in terms of progressive enhancement and JavaScripty stuff. It’s really interesting to see all of this come about, but responsive design being the thing that birthed this whole movement.

David [28:20]:

I think progressive enhancement and responsive design, they are cousins in this context, because they really have so much to do with each other. And I don’t feel like either one lives exclusively within the purview of the engineers, because they require so much involvement from everybody in the community — everybody who’s doing the development — and, honestly, even from the users. You need that feedback, you need that pattern of instrumentation where you can find out how people have actually interacted with your content — in order to understand whether or not you need a breakpoint here; whether you’ve missed something here; or whether you’re overloading the devices, and so people are not going to that next link, or going to the next page on your web page or whatever, because things are just too heavy for them. All of these things are playing together. And for me, I guess, the concept of responsive design just brought it all together for people, and gave them something to focus on.

Tim:

You can even see how things like user experience and accessibility were strengthened by this idea. That’s why I think it’s so important for us to continue to fight for the philosophy of responsive design, because to me, it really is a renaissance or a rebirth of the web and how things are built to fit inside of it. I think that I live in this bubble wherein I work on a product that is already responsive, and I continue to build responsive components. I’m not necessarily waking up everyday and trying to push the line a little bit more forward — to where, when someone says I want a website, the idea that being responsive is inherent, like all parties just accept that’s going to happen.

I think that’s something that we still need to keep fighting for, because, as we’ve realized, performance and user experience and accessibility — all of those things alongside of responsive design strengthen each other, because it’s suddenly all about the user using the thing, which in turn leads to more consumption of the web. And that’s really good for everybody. I think it’s something good to keep in mind, and excellent to continue to fight for every day in our careers.

David:

And it continues to make everything that we’re working on more abstract. I spent a few years working at a company that specialized in taking big, static, browser-based websites and creating mobile-optimized versions of them that were dynamically generated on the fly from the desktop version — which was an amazing business model. But one of the things that working there brought to mind was the philosophy of what is the core essence of what we’re talking about? And ultimately, is it just an API of content that then needs to be funneled into this presentation, versus this presentation for this audience, that audience, and it all gets customized?

Now we’re starting to get to the place where we have the tools, and we have the technologies available to us to provide individual users with incredibly customized experiences, based on what tool they are using, how long they’ve been there. We can read all sorts of information about where they’ve been before, and what they’re interested in, and present a bespoke responsive presentation of our content to each user depending on what they need.

Tim [31:22]:

Yeah, one of the things that Ethan briefly touched on — he and Karen McGrane do a lot of responsive workshops, and one of the things that they always talk about is content strategy, because most of this does really come down to the content. You see a lot of times people who design for a really large screen, or design for the absolutely perfect medium, and then try to cram that medium into all of their use cases.

It does become that reverse funnel system, because suddenly someone says, Oh, we have a much smaller screen, so we have to get rid of some of this stuff at the bottom.

Then someone mentions a fold, as if we’re working on newspapers. We need other content to be at the top, and suddenly the focus on the content is dissipated, and it’s suddenly focusing about just cramming what you have into a smaller-sized screen. That then brings up the idea of, Oh, maybe we can just tailor this experience, because a user with a screen that’s smaller, we just want them to be on the go, and that justifies our ability to just get rid of some stuff here. I mean, in my own small pain of existence, my experience with that is usually when I am on a mobile site, like sitting in front of my TV trying to do something trivial like pay a bill most often, right?

I can’t see something that I need, because someone has decided because I’m on a smaller screen, I don’t need to get to that certain part of their application. That’s always something that I think presents this huge challenge, and goes contrary to the idea of responsive design. That being said, I think a good model that I try to bring about when thinking about designing for responsive applications, is to protect the content. Always protect the content. Don’t punish the content for the restriction that the medium provides.

David:

That is a really important point, and when it comes to things missing on the mobile platform — I’m speaking to you, YouTube Live. That’s today, but I’ll tell you, one of the things that I noticed about this is it ends up being a very political discussion. People fight for the politics of I need to have this real estate on this web page, and that’s one of the reasons why they think in terms of their web page. My department must be presented in this area on this web page.

Honestly, when my company was doing these conversions of websites, one of the most valuable things that we were able to provide for the tablet platform, and for the mobile platform, was that we bypassed that discussion, and we were able to say, OK, the mobile audience doesn’t need all of these things. They just need this.

We were able to put in only the things that a user actually wants to see on the page. Bypassing the politics of that discussion actually helped provide much more optimized experiences — not simply because the experiences were tailored to the device, but also because the experiences were tailored to what the users actually needed and wanted to interact with, not the politics of who has to be represented in what section and for how many pixels of screen real estate.

Those discussions happen, and being aware of them as we start looking at responsive design, it brings that more to the surface. It brings it more to the top of mind. It makes people realize that this is not something that we’re doing for our political motivations in terms of our departments and our policies. This is something that we’re doing for the users and for what the user needs to experience.

Tim:

I think it’s Brad Frost who says that carousels only exist to prevent business stakeholders from killing each other.

David:

[Laughing] I like that! I may steal that.

Tim:

Yeah, really good. Cool.

David:

This has been an amazing episode. I’m so glad you reached out to Ethan, and I’m glad that Matt was able to connect us with him.

Tim:

Yeah, everything seemed to work out very perfectly.

[Musical interlude]

Well, thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes. Let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.

Frequently Asked Questions about Responsive Web Design