Reimagining the Way Websites are Built
Developer and author Brad Frost on responsive web design and a culture of performance.
Responsive Web design is a lot more than the latest development technique for websites. It’s a dramatically different way of conceiving, strategizing, designing and developing websites. Implemented to its full extent, it redefines both the way teams interact and the workflow of the project. And it’s an approach that needs to have performance baked into the process. Brad Frost is one of the industry’s leading thinkers, speakers, and authors on the topic of responsive Web design. Benchmark recently caught up with Brad to get his views on the state of responsive Web design and what it means for performance.
Benchmark: What are the major strengths and weaknesses of responsive design?
Brad Frost: As far as the major strengths of responsive Web design, it's getting harder and harder to keep up with all the different devices that are coming out. You turn your head for a second, and the next thing you know there's five new smartphones on the market, three new tablets, and four new phablets. It seems like every day, more and more things are getting connected, more and more things have screens on them, and more and more things are accessed from the Web. As a result, it's getting really overwhelming for people creating for the Web to create a catered experience, or even acknowledge all these different connected devices.
It's a losing battle to try and keep up with all this stuff individually. We're now entering an era where, instead of chasing every device in every direction, we need to get smarter about how we construct our Web experiences and make them so that they are able to flex and adapt to whatever device the browser [user] happens to be viewing. That's why responsive Web design really matters. It's not about creating squishy Websites for the fun of it. It's about acknowledging the fact that the Web landscape is more diverse than ever. We don't know what devices, what gizmos are going to be under the Christmas tree two years from now. But that's the sort of stuff that we need to be designing for today.
Responsive Web design is basically being able to create a singular experience that adapts and modifies itself based on the device's capabilities. We're able to exploit the unique capabilities of a particular device. For example, your user is on an iPad with a touch screen, and you might have an image gallery to show — you can introduce touch events to exploit the touch capabilities of that device. So you can swipe through the photos. But if you're on the laptop without touch capabilities, you go through it the old fashioned way, with 'previous' and 'next' buttons, or what have you.
Responsive Web design creates a flexible container for this stuff to happen, but what we're really talking about is an extension of the broader progressive enhancement strategy. We assume less up front, and introduce certain bits of functionality based on the device's capabilities.
As far as the downside of responsive Web design goes, it's really challenging to create design systems that scale fairly well across all these different screen sizes and contexts. Ergonomics, for example — how people are holding their devices — those conventions can change as you go from a hand-held experience to a tablet experience. You'll have your thumbs sitting on the edges of your devices, so you have to think about where to put things. Then you have the more traditional computers which have their own interface conventions. It's like marrying all those things together. It's not impossible, but it's certainly pretty tricky to create interfaces that work really well.
The hot topic now, and something that I've been talking quite a bit about, is performance. A recent article I read talked about how slow responsive Web design is. Well, not really! It's not inherently bad for performance. It's very much about the implementation of it. A lot of responsive Web designs right now are taking a very shallow definition of responsive Web design — they're more or less just squeezing down desktop-size sites to small mobile screens, which isn't very good from a user experience and performance standpoint.
Everyone's site is having a hard time with performance. Websites keep growing fatter and fatter and fatter, whether it's a desktop-only site, a mobile-specific site, a responsive site — it's a really big problem across the board. I think it's false to put bad performance on responsive Web design. We need to really elevate the conversation around performance as a priority, instead of treating it as an afterthought.
Certainly, there are specific techniques and things you need to consider a bit more, in order to deliver an experience that's really lightweight, in a constrained environment, on an Edge or 3G network phone, versus somebody that's on a MacBook Pro, on a FIOS network. There are ways to balance that to address constraints but still optimize for more capable devices — devices on fast networks, devices that have Retina displays, etcetera. Again, it's about starting with the constraints up front, and then gradually introducing larger images, and more advanced functionality only whenever it starts making sense to introduce it.
Benchmark: You wrote about an article by Guy Podjarny, where he analyzed a number of responsive sites and found out that their mobile performance was not great. The sites were being optimized to display on mobile, the layouts and navigation were adjusting, but behind the scenes, the entire site was loading down to mobile. Given all the challenges inherent in mobile connections, it was creating really poor performance.
Brad Frost: I really appreciate Guy bringing this to the forefront and saying this is a problem, but again, it's Web pages in general, right? What he's looking at is, does the small-screen view weigh roughly the same as the large-screen view, and he found out in most instances, it does. I'm not saying that's a bad metric, but for example, my site is pretty much only text, so my homepage I think weighs something like 30K; it's just really tiny. It weighs the same thing on small screens as it does on large screens, but that's actually not a bad thing because it's light across the board.
That's what I'm trying to get at — it's not just mobile users that appreciate faster performance, it's everybody. Everybody wants to get things done, so we have to make that happen.
Benchmark: Typically, the desktop experience is just more forgiving from a performance perspective. People are likely to be on a better connection. Plus you don’t have the latency problem with desktops.
Brad Frost: If you’ve ever been in a Starbucks or in a hotel with lousy WiFi, you feel the pain of that real quickly, right? Part of what I’ve been talking about a lot is treating performance as a design feature and not just a development best practice. It’s to get more people onboard with the fact that performance matters. It’s about making sure that whoever is running the project is prioritizing performance. I point to Facebook’s recent app debacle, where they had to totally redo their entire mobile app. They did that solely because the experience was so slow. They had to redesign the entire thing solely because of performance. I bring that up, especially with managers, especially with other designers, who think that this is just something that developers need to deal with. No, everybody needs to be onboard with making performance a priority.
Benchmark: Right. Because users just aren’t patient. They expect mobile performance to be every bit as snappy as when they’re on their fast FIOS connection.
Brad Frost: Yes, and they don’t care that they’re on a 3G connection, or that their processors are slower, or whatever. They requested something and they want it immediately.
Benchmark: One of the things that you’ve talked about in various places is the notion of “mobile first.” I wonder if you can comment on that a little bit. Is there a danger of watering down or compromising the desktop experience if you have such an intense focus on making things lean? Or do you think you can still make a genuinely rich experience on all the devices?
Brad Frost: I challenge anyone to go on their current site and not find something that they can just remove and nobody's going to notice. It's not about watering down any experience. Whenever you have this giant canvas to put stuff on, we fill up the space — it's like 'Hoarders.' We have all this extra space, let's just start putting stuff there.
That's one of the core aspects of mobile first, is to use mobile as an 'excuse' to focus on what really matters. What really matters to you as a business. What matters to your users. What matters for your goals. That's really what it comes down to.
Again, the challenge is that we have insinuated so much stuff onto our websites over the last 15-17 years. Screen sizes have been getting bigger, pipes have been getting faster, so we have gotten lazy. Now, here comes all these less-capable smartphones that are really forcing us to go back to basics and focus on what really matters. I'm really excited about it, to be honest, because I do think that people have gotten lazy.
You look at something like navigation. I write a lot about responsive Web design navigation patterns. So people will get in touch with me and say, 'Well, Brad, this is all well and good, but I have a site with ten layers of navigation.' I say, 'Well, don't have ten layers of navigation.' It's one of those things that mobile forces us to look at. It's a great excuse to just revisit and say, 'What are the things that people are really clicking on? What are the things that people are doing? Is there a lot of dead weight in here? Are there opportunities to consolidate or remove entire sections?' In doing that, you're creating a more focused experience, but you're also setting yourself up for long-term success because you're more agile. You have less stuff that you need to put in front of everybody.
Benchmark: The discipline that’s required there could be a good thing.
Brad Frost: Yes, absolutely. I really welcome all of these little mobile handsets coming out. Again, it’s just a conversation starter. People have historically done things a very specific way. Tucking things away in hover states, and all sorts of stuff. I’m not bashing these techniques as inherently wrong, but they get abused.
Benchmark: In deference to the guy that’s got ten layers of navigation, are there certain criteria or characteristics you think that make a particular site a good candidate for responsive, or are there any kind of sites that you would just say no, you shouldn’t go responsive with that?
Brad Frost: I recently wrote a post called, 'It Doesn't Matter,' because so much of the conversation that I see around responsive Web design is, 'Well, yeah, it makes sense if you're a blog, or you're a newspaper site, or a magazine. But my e-commerce, my B2B, my portal, my blah, blah, blah, isn't a good candidate, and here's why.'
It doesn't matter, because we're not in the e-commerce business. We're not in the B2B industry, the travel industry, whatever. We're in the interface business. Our job is to create interfaces. I've been spending a lot of my time and energy on basically creating abstract interface patterns for responsive Web design. Your ten-layer navigation is just a ten-layer navigation. It doesn't matter what's inside of it. It could be apples, oranges, pears, bananas, whatever. Or it could be book-a-flight, book-a-hotel — it doesn't matter. It's navigation.
I do think that it is easier to transfer over something that's primarily text and images to a responsive format. There's less moving parts, and it's easier to accomplish. I think that's why you're seeing so many journalism sites and similar sites go over sooner than others. But you're starting to see it happen with e-commerce, and some of the more 'appy' experiences.
That's not to say that there aren't legitimately tough interface problems to solve. I've talked to people whose entire business model is something like Google StreetView, where you have a 360-degree panoramic experience; or a whole business is built around these really robust sortable, draggable, droppable status tables, or other complex interactions like that. Those are really hard things to translate across a bunch of different screens. I can totally appreciate the fact that they might not be able to do that all under one roof.
At the same time I don't think that there are that many use cases like that out there. I think that it's in the minority, not the majority. I think that most sites could be made responsive pretty easily. I've been talking to some financial companies about lots of tabs, lots of graphs, lots of charts, and content like that. It's possible. It really is.
I've talked a lot about basically setting up really strong design systems, breaking your entire interface down into its individual components. In doing that, you're able to see what's going to be more challenging to make responsive, and what's going to be easy.
Benchmark: What are the biggest or most common mistakes that you see developers making when they’re starting to build responsive sites?
Brad Frost: I definitely think that taking too literal a definition of responsive design is something that I see a lot of people doing. Ethan Marcotte, who created responsive Web design, did a really great job defining it. He defined it as three ingredients — fluid grids, flexible media, and media queries — that allow you to apply different layout rules whenever certain conditions are present.
It's great, but Ethan's a really smart guy, and he knows that there's a lot more to creating robust Web experiences than those three ingredients. One of the biggest mistakes I see is people taking those three ingredients, slapping them on a site, and then saying, 'Oh look, I'm responsive. I'm mobile-friendly.' There's a lot more to it than that. Again, that leads them to poor performance. That's another mistake. I think people are just starting to get a taste of it, they're starting to experiment with it. These are still early days.
Also, some are treating it all as a one-size-fits-all experience, and this is another big mistake I see a lot of. Again, not taking advantage of unique device capabilities. Something as simple as clicking a phone number from your mobile device to initiate a phone call — it's incredible that you don't see too many people really taking advantage of that. Again, it's about thinking beyond just layout. Thinking, 'How can I enhance the experience based on what the device is capable of doing?' Too many responsive design conversations I hear are about taking just one thing and making it fluid, and that's that.
Benchmark: On the flip side of that, what are the top three things you would say to a marketer who’s about to pursue responsive for the first time?
Brad Frost: Again, when you're starting to lay things out and figure out what you're trying to accomplish with it, whatever site you're undertaking, start with the small screen first. What's great about these narrow screens is that you're not tempted to clutter up the interface with a bunch of unnecessary stuff. It's a narrow column, so you have to figure out what goes on top of what. It's a lot easier to establish hierarchy. What's really important? Does this read in a very linear way? That sort of stuff is really crucial, even in the planning — what is it that we're actually making? — even before you get into really designing the experience, think about what it is that you're doing.
It must seem like commonsense, but I've been on enough projects where marketers especially, are just so excited to get started that they forget to answer the hard questions like, 'Why would anybody care about this?' So I would say to start there.
The other thing is to educate the entire organization, the entire team. Whoever is involved in the process needs to be onboard with it. They need to know what it is, why it's important, how we're trying to go about accomplishing this. Again, the original definition of responsive is just a couple of development techniques, but it's not just something that concerns developers. It really shakes the foundation of how we're used to doing things in a very real way.
That requires everybody's attention. That requires change on everybody's part. It requires change in process. Who's collaborating with whom? It means involving developers much earlier in the process. I historically come from this waterfall process, where the people involved early in the process just throw something at me and say, 'here, build this.' That's not how things work anymore. People need to understand what that means and what the implications of that are.
Lastly, another fundamental change is the idea of, instead of throw-away pages or micro-sites, whatever, we're really trying to build systems, design systems that are built for longevity, not just a short, one-off campaign or something like that, not some marketing piece. We're really trying to build long-term value. Again, design systems — something to build on, something to evolve, something to iterate on. That's certainly a lot different than the way, in my experience, that things have historically been done. It has physically just been one giant redesign after the other. We're now getting to a point where that makes less and less sense. We need to smartly iterate all our designs so that they gradually evolve. We need to listen to your feedback, listen to your analytics, listen to your customers, and tweak things and evolve them.
Benchmark: There still seems to be a lot of ‘get it built and we’re done’ approach to websites out there.
Brad Frost: Historically that’s been the story of my career, more or less. We’ll build you a site and then we go away, sometimes forever, or we’ll come back a year or two later and do it over again. That’s just amazing.
Benchmark: Do you have any best practices or any philosophy that you use in approaching mobile performance?
Brad Frost: A big part of what I try to do is change the conversation, to go beyond the idea that performance only concerns developers. Often it's a low priority even for developers. It's like, 'Okay, well, let's just get the site up. We can go back and clean up all the performance stuff later — if we have time.' That's a problem in general, but again, it's still on the developer's shoulders. I think that everyone needs to be concerned about it. Anybody working in Photoshop making really big, splashy, graphical images, they need to understand what that means for performance. They need to understand that including 17 fonts is going to bloat-up the Web page. The people running the show need to make performance a priority.
[Web developer and consultant] Tim Kadlec recently wrote about setting a performance budget. You basically set a cap, whether it's a time or a file size; you'd say something like, 'Our site's going to load in three seconds or less, period.' Then every design decision, every content decision, needs to pass that test. If you put three fonts in there, you might have to lose some images or something else. I really like branding everything in that lens, or at least considering it throughout.'
Another big mistake I see is people shrinking their viewport and then concluding, 'Okay, my site's working really well on these phones,' when actually, you need to test on real devices early and often. That's really the only way you can truly see the performance of things.
Even something like testing some of the glitzy CSS3 features like drop shadows. On paper or in a desktop browser it looks great. Then you fire it up on an Android phone and it just crawls. It grinds the entire thing to a halt, and it's because these processors are limited. You don't know that though, until you actually fire it up on a real site.
Benchmark: What do you think the development environment’s going to look like a year from now? What’s going to change? What new things are going to affect the way you approach your work?
Brad Frost: That's really, really tough. It's more true here than it is almost anywhere else: Change is the only constant. Not even the best and the brightest in the world — the people that are paid to think about this stuff — get everything right. They don't know exactly where we're going to be a year from now.
I'm part of helping shape a manifesto for the future — a future-friendly manifesto. It's about acknowledging and embracing change. It's really accepting the fact that things aren't going to stand still for very long, and that's a good thing. Again, focusing on what really matters to you as a business; getting your ducks in a row. Don't just chase every device that comes out — you're going to get exhausted really quickly. Build long-term strategies instead of just another redesign — that's something I'd really like to see happen over the next year.
It's about restructuring your content, your workflow, your organization, everything. So yes, a crystal ball — I have no idea what devices are going to be out next year, but you want to get to a point where you don't have to pull your hair out every time that Apple has a keynote.
That's definitely my general philosophy. I would love to see more people embracing that. Spending the time to do it right instead of just turning another tight redesign out the door.
About Brad Frost
Wired magazine calls Brad Frost a “responsive design guru.” He speaks and consults on responsive design and other development topics across Europe and North America, and he has contributed to several books, most recentlySmashing magazine’s The Mobile Book. Brad puts what he preaches into practice as a developer for a number of blue-chip clients including Nike, MasterCard, L’Oreal, and Capital One.