When Responsive Web Design Meets the Real World

Jared Spool: Hello there, everybody. You are listening to another episode of the SpoolCast. I have with us today the amazing Jason Grigsby, who's going to be giving a fabulous workshop coming back again for, I think, a third or fourth year.

Jason Grigsby: Third year.

Jared: Third year. OK. Coming back again for the third year to teach "When Responsive Web Design Meets the Real World." He is the co-founder of Cloud Four and co-author of Head First Mobile Web. He's brilliant about this mobile stuff.

Jason, welcome. You know what, it occurs to me, I didn't say where you were giving this workshop. You're giving this workshop at the UX Immersion Conference in Salt Lake City in April, April 13-15th of 2015.

Anyway, Jason, welcome.

Jason: Thank you. Thank you. It's good to be here.

Jared: Yes, yes, it's so awesome to have you. Now, because this is your third year, you've been thinking about this stuff. You were one of the first people to really start to ask the hard questions about, what does it really mean to go responsive.

There were a lot of smart people talking about this, but, saying, "Yes, we must do this," and then jumping to, "OK, I have to get designs that will actually be turned into code that will run efficiently and effectively on a website." That was a big jump a few years back.

Jason: Yeah, I don't know that I would say that it was one of the first. I mean, it feels strange to take any credit.

Jared: OK, let me rephrase that. You were one of the first I heard who was talking about the translation from the theory to real design and dealing with constraints.

Jason: Right, right. I guess that is probably true. I mean, one of the first things I did, unfortunately, was write a blog post that called into question media queries. Because I felt like people were sort of looking it as a silver bullet for solving these problems, and that there were actually a lot of problems that they weren't seeing that were happening in those responsive designs.

That's always been my interest. I like looking at how things, sort of, how do you take the theory and apply it to the real world and what happens when you actually get into the nitty gritty of this stuff. Often times, it's, unfortunately, more complex than we think it is or than we think it should be.

Which, Ethan Marcotte, right, who coined responsive web design, he once said that when I give talks, that my talks are not the types of talks that are filled with kittens and warm fuzzy feelings. That if I ever put a kitten in it that I would then, on the next slide, put the kitten in flames, because...

I'm like, I think that the world gets boring when things are commoditized and there's not complexity, and I like to look at where things are headed and look at the challenges that we face. I guess it's true in that way. I took something that was simple and elegant, and started digging at how you would actually do it.

Jared: Listening to you over the years, I remember you were one of the first people to really point out, to me at least, that there were ways to build responsive websites that made these heavy performance footprints, that actually made the usability worse, because they were so heavy.

Then there were ways that you could clean that up dramatically, and that you had to be paying attention because if you weren't thinking about this, the idea that you would accidentally make something that performed really well was probably much slimmer than accidentally making something that performed really poorly.

Jason: I don't think it's responsive design specific. Essentially, the whole reason why this is an issue for responsive designs is that people are building sites the same way they've building them for years. I sort of famously, a few years ago, referred to the fact that we've remade the Internet in our own image, which in the United States is obese, and so we make Web pages that are just too big as a matter of fact!

It doesn't matter whether they're responsive or not. The reason why it becomes more of an issue for responsive designs is that we make them too big, and then we try to shove them down small pipes on a small screen, then the performance is really poor. I look at that and I think this is our opportunity to do it right.

This is our opportunity to learn this stuff, and to build things that are both beautiful and fast. If responsive design and Mobile gives us an opportunity to focus on that, then awesome, because it's not just important for our customers, it's also important because so much of the world doesn't have the same sort of high speed access that we do here.

We want to make sure that the things that we build are accessible to as many people as is possible.

Jared: Right, and this isn't just a developer issue, right? No matter what design you produce, the developers will figure out how to make it work. This is, as we're learning, designers and developers have to sit side-by-side to work on this stuff because understanding the designers intent, the developer can come up with solutions that actually are fast and effective, and still meet the intention.

The designer can learn what it takes to speed that process up and not deliver things that are just going to be hard to implement quickly and effectively, I would think.

Jason: Yeah, there are two pieces to it. First off, one of the really interesting things that the Yahoo performance team found when they first started looking into this, it was 80 percent of the performance issues came after the HTML document was delivered to the browser, which means that the vast majority of the performance improvements come from the things that we tend to think of as web design or related items, CSS, images, to some degree, JavaScript. These are all things that usually designers have some, at minimum, influence, if not control over.

But the other thing is, from a responsive design perspective, that also, the responsive design process and the fact that you have to pick, you can't really comp or wireframe every single break point. Pretty much necessitates that if you want to have a say in how your design is going to adapt as screen size changes, you either need to be in the code or you need to be sitting side by side with somebody who is in the code.

Because design decisions are being made as the browser is resized, as somebody's sitting there squishing it between small screens and large screens and making decision about when things look bad. If you're a designer and you want to make sure that you participate in that process, you've got to be sitting next to that person or be that person yourself.

Jared: This fundamentally changes how a lot of organizations approach design, because there are places where the designers and developers are in separate parts of the office building, sometimes in separate buildings and sometimes in separate continents. That sort of side by side collaboration can be really hard on some teams to get used to. But as you say, I think that's the direction a lot of folks are going in and seeing great results.

Jason: Yeah, it's hard for me to envision, I guess, the way, and I have a little bit more sympathy or it's a little easier for me to put myself in the shoes of a designer. Because I started out doing print design way back in the day.

Jared: I didn't know that.

Jason: Yeah, I was a journalism major and did a lot of graphic design work, all that. I even remember typesetting machines, way, way back.

But if I were working on a project, I would want to make sure that it was the highest quality project possible. That means participating in, when it was print, everything from the paper selection to the inks to all those pieces of the process. Moving onto web, it's, how do I make sure that people get the experience, the best experience possible.

In a responsive world, if you have that goal, if you've got those aspirations, if you care about that stuff and you want to make sure that you're participating in those design decisions, then handing off a comp isn't going to be sufficient. Because that comp is going to have no relation to reality when it's actually coded up and somebody has to make a decision at 714 pixels, because text starts overlapping, how they're going to handle that text overlap.

Unless you're participating in that process, you're only doing portions of the design, you're not actually designing that full experience.

That may make sense in a lot of instances. It's just, as somebody who likes, when I do have design control, want to have complete design control, that wouldn't appeal to me.

I find myself thinking as I talk to people who are designers who have traditionally worked with handing off comps and things like that, like, if you've had trouble in the past where you hand off the comp and what you end up with at the end of the development process doesn't map to what you did in the comp. The moment you start doing responsive design, like, it's going to be even worse.

The only way to do it is to participate in it, jointly or to actually do it yourself.

Jared: I'm going to bet you were the type of guy who hung out at the press while your work was being printed.

Jason: If I had the opportunity, yeah.

Jared: Yeah, yeah, I know, I've been there.

Jason: I like the smell of stuff coming off the press, which is totally wrong, but.

Jared: No, I've been there. Dude, I have done the gang runs at two in the morning. Been there, done that. Wow, that's way back from the past.

I remember back when I was a youngling working in my first print shop, being sent off, I guess I was being annoying or something, so the owner printer sent me off to go visit another print shop to get a can of rainbow ink.

This is going to date me back in the '60s and '70s. The music posters were all these sort of rainbow color stratified things for concerts and stuff. Everybody was doing that.

He said, "Oh, yeah, we need rainbow ink to print one of those, so go find me some rainbow ink," a can of rainbow ink.

I believed him and I got in my car and drove down the road and walked in the print shop. "What do you need? What do you want?"

"My boss, he sent me over to get a can of rainbow ink."

"Oh, we were just out. You have to go up the road," and I got sent to like 15 different print shops in search of rainbow ink. That was my hazing.

It took me a while to figure out that such a thing did not exist.

Jason: That's hilarious.

Jared: The old days! Let's talk about the new days. A lot of things have changed since last year's workshop, is responsive images and what the browsers are doing about that now, right?

Jason: Yeah. We spent the last few years trying to figure out how to handle images in the browser, and it's been interesting. There's been a small group of foolish people, not select people, who have been desperately trying to figure out what would a standard be, how does it work, both browser makers and also web developers?

Outside of that group it has basically been sort of a mitigation strategy. If you're a web developer and you're doing a responsive design, you don't necessarily have to worry about what is a standard going to be because it's not baked yet. It's all off in the future. You just have to figure out what can I do right now.

What technique am I going to use? We now have responsive images specification, the picture element, the srcset attribute, sizes attribute. All of these things are available in Chrome. I can't remember if the full set is in Firefox. Sorry, I'm blanking at the moment...coming to IE.

We've actually got these items coming out. What that means is that even though over the last few years we've had...like I've said we've got this group of people who have...if you look back at it, we've had four or five different versions of this specification.

To my mind, that's the easy part because all that stuff really was just those foolish people, like myself who were spending a bunch of time trying to figure out what we should be doing from a browser level to solve images. Now, we all have the problem of figuring out when does it make sense to use the picture element?

When shouldn't we use a picture element? How should we use srcset? How many image sources should we have? How many image breakpoints should we have? When do we use SVG? When do we use PNGs? When do we use CSS backgrounds? I've been working on a flowchart, which will be one of the things that I'm talking about during the workshop.

I'm working on this flowchart that's basically all of the different decision points that you have to try to figure out what implementation you're going to use, and when it makes sense to use these different things. Every project will be different, but I think that we can get to the point where it's in the same way in which most of us know when to use PNG and GIFs versus when to use JPEG.

I think we can get to a similar sense of when does it make sense to use srcset? When does it make sense to use picture, these sorts of things. It's going to take us a little bit to get used to these new tools, and to decide when they're appropriate and when they're not appropriate.

I think even though responsive images is something that we've been talking about for quite some time, that really 2015 is going to be the year that web developers as a whole now are going to be, "Now we've got the tools. How do we use them?" I've been spending a lot of time trying to think through what that looks like and how to make those decisions.

Jared: Again, is this a developer-specific thing, or are things designers do or don't do going to make the developer's life easier or harder?

Jason: I think that it's both. Also, I would say that in my world the lines between designers and developers are so blurred that it's kind of hard for me to tell what is a designer issue and what is a developer issue. We're hiring right now for a position that we're calling a Front End Designer, because we're specifically saying we want designers who can code, and that's what our organization does.

It's tough for me to figure out where those lines are. What I can say is that if a designer only has to worry about image preparation, it still makes a difference because you have to decide what image format makes sense. I'll give you an example of something that's challenging to figure out from a responsive images perspective, hero images.

Hero image. We're working with an organization that hero images on their home page, like a lot of organizations do, we're trying to figure out how to help them figure out how to do this responsively. We knew because hero images included text in the image, but they couldn't simply just shrink down the image, or provide different sizes of the image.

They really needed to create different source images. They needed to change the text, and change the layout of the images as they got smaller in order for it to fit, but how do you decide how many of them? Do you have three different images, or four different images? What's maintainable? Do you support retina versions of them?

That's even before you get to the point of asking is this going to be the picture element, or srcset, or any of these different technical pieces. In that particular case, what we ended up doing was we actually ended up looking at the typeface being used in the images, displaying that typeface in different type sizes, and then resizing it down until the type wasn't readable, and then deciding that that was where we needed a breakpoint.

Then, we just did that through the different spectrum, the continuum of that responsive design, and ended up with three breakpoints, so long as they didn't use anything smaller than 18 points, but the moment they use 16 point we needed four image breakpoints.

I think that you end up with a combination of what are design-related questions and development-related questions, and where the lines are between those two I no longer know. All I know is that nearly every site that we work on we have to have a discussion about images.

We have to figure out what our strategy is going to be for them. We have to categorize some of the images that we can just deal with by doing resolution switching and changing the size of them, which ones of them we need to treat specially in some way, which ones we can convert to SVG, all of those sorts of things.

Jared, you and I were talking briefly before the podcast started, about how Lynda Weinman back in the day of Lynda dot com, she had five or six books on images.

Jared: I remember devouring those.

Jason: They were best-selling books, because when we first started working on the Web I had a poster of web safe colors. The reality is that we are back at a point right now where making decisions about images is again complex. Five years from now it may be very much like it was four years ago, when most of the stuff was automated and we didn't have to think about it.

We could pretty safely use images without needing books to teach us how to do it, right? Where we are right at the moment is that there's enough change happening in this space, and enough complexity, and it has such a big, big impact on the performance of web pages, it's 60 percent of the average web page or something like that, that we have to spend the time to really understand this stuff.

That's why I've been working on a lot of material related to really showing this as flowcharts and decision trees, so that people don't have to go read up on all this stuff.

They can just go through that flowchart and ask themselves a series of questions, and hopefully come to some conclusion about what makes sense for the images on their site, or their project.

Jared: That sounds really useful.

Jason: I hope so.

Jared: You will be given a statue for that document.

Jason: Yeah, well, wait till I'm done.

I mean, one of the things that I'm learning is that, there is a real appeal and a lot of, I mean, even within our company. Like, this is too complex, like, this can't be the long term solution. I think that there's some resistance to the picture specification, the srcset and sort of the complexity that's coming.

I feel like it's unavoidable, that complexity, and I also feel like it's no different than the complexity we had in the early days and that we just eventually learned it well enough and our tools got better, so we didn't have to worry about it as much.

But yeah, like, I don't think that it's, all the time when you sort of provide examples of the complexity, that it's the most welcome thing in the world. Like, no, I don't want this. Can't I go back to the way it was two years ago when I didn't have to think about it?

Jared: Is this something where Adobe or the people behind Sketch or something could come up with smart image editing tools that make the decision process for you? Or is this right now something that machine intelligence isn't going to be able to help us solve, we have to have humans in the process?

Jason: Yeah, I don't know. I don't know the answer to that. I hope, I wrote a blog post a couple years ago on sensible jumps in image breakpoints, in which I sort of put together an academic argument for how you could make decisions about image breakpoints based on performance budgets.

Earlier this year, Paul Irish of the Google Chrome team sent me a note saying, "Hey, when are you going to build that tool that the web needs?" Referring to the idea that this is really something that should be automated and that we should sort of build something. Maybe I'll get around to it at some point.

Jared: Why don't you just invoice them?

Jason: Yeah, I'm hopeful that somebody else does it. But the thing is is that even if I did that one...

Jared: I mean, he works for the Google. The Google has a lot of money.

Jason: I know, exactly.

Jared: I mean, they're building giant balloons that have Internet in them. They easily could fund this.

Jason: Well, they should contact us.

Jared: Seriously, I would just send them and invoice.

Jason: Yeah. Even if we did that, though, like, that just solves one of the sort of areas. It doesn't solve making decisions about what you would do with a hero image, for example.

I think humans are going to be involved for a while. But I think that there's enough people who are going to have some more problems that the tooling will get better. I'm just not sure what it'll look like.

Jared: Let's talk about the other thing that sort of, I think, has come on the horizon much bigger than we've had in previous year. Which is, the emergence of patterns and focusing on design in terms of a design system in a pattern library versus thinking about pages as entire comps. That's picked up steam, I think.

Jason: Yeah, it's exciting to me, because, again, going back to that, way, way back with the print background, a lot of the earlier print projects that I was doing were larger and lengthier publications. Where it became really important to establish right up front a style guide and templates and things of that nature, so that you didn't end up with a book that was 200 pages long or a catalogue that was 400 pages long that looked different on different pages.

I feel like that was something that we were doing from a print perspective for years, but that we didn't really translate that into web. Or at least we weren't doing it in a consistent manner.

Responsive design brings that back to the fore, because really, what we need are, we need systems of components that are responsive. We need to be able to make decisions.

One of the examples, I think sort of the clearest example I have is from the Boston Globe site, where the film group decided that the header, which contained weather information, that the weather information would change based on the size that it had available to it. That's not a page level decision, that's sort of a weather widget level decision being made.

That's also the reason why the responsive images community group is moving on to work on element queries as potentially a way for us to create more of those sort of component level decisions.

But when we're doing designs now at Cloud Four, we're almost always working from patterns. We're going through design sprints and we're working with the client to figure out, OK, in this sprint, what pieces of an interface are we going to be working on.

We might decide, like, in this sprint, we'll tackle product tiles and category tiles and, I don't know, a couple other things depending on the number of people on the project and the length of the sprint. Then we'll spend that sprint sketching and iterating and prototyping those particular pieces of the interface. The next sprint, we might take cart or we might take like the sign out form.

We pick these pieces and then, as we get through them, towards the end, all the pieces come together into pages. But we really have found that we move much quicker and much faster when we're dealing with the pieces of the design.

Because it becomes very, very difficult, if you're not dealing with things at sort of that component level, to look at one page and think about all of the different ways in which the pieces on that page might be used on like other pages and design it.

If you're looking at a page as a whole, and it has a product tile on it or something like that, but you don't know that that product tile is also used in the cart and it's also used in these other contexts, then you might make a bunch of responsive design decisions about how you want to support that at different screen sizes. That's only dependent on the page that you're looking at right at the moment as opposed to...

I feel like the components themselves, they tell you how they should look at different screen sizes. Like, if you just design them specifically, then they have intrinsic pieces. Really, what you're doing is, you're learning from the content of that particular pattern or interface how it should look at different sizes. Then once you've made those decisions, then you can bring it into larger components or pages and build from there.

Whether it's Brad Frost's Atomic Design ideas or whether we're talking about just this sort of components and patterns of pattern libraries. I mean, there are a ton of people talking about and looking at this problem.

Anna Debenham has a bunch of information about pattern libraries and style guides. Susan Robertson, who we've have the great fortune to work with on a couple project recently, has written for ALA on style guides and just gave a talk at Smashing Conference on maintaining style guides.

I think what we're seeing is that as responsive grows, there's increased need to think about design as a system of patterns where the pieces are responsive in themselves. There's great power that comes from that. But it really does change your process and change the way that you design.

Jared: This is not a new idea. I mean, Robert Hookman and I wrote a book on this years ago about the difference between what we called frameworks and patterns and components. Sort of looking at this, the idea of collections of patterns in the notion of a framework, so all the things you need for a login screen, all the things you need for order entry. It's very similar to what Brad's talking about with Atomic Design and stuff.

It's neat that this conversation is really coming around and people are building these things out. They're finding that this is actually the path of least resistance, to go down this road, versus, wow, building out this pattern library is going to be a much harder, much more difficult thing than if we just slapped this stuff together and get it out there right now.

Jason: Yeah, yeah. Two thoughts. One is that you should charge Brad some sort of royalties.

Jared: I'll invoice him.

Jason: Yes, exactly. Second thing is that I think the next challenge for us, I mean, we're not even through figuring out how to do this and everybody's sort of adapting to thinking about designs as a series of components.

But it's really, really clear that, once you've done that, that suddenly you realize, how do we maintain this? How do we make sure that we don't get out of sync?

If we fix something, like, say, and this is just a stupid, stupid example. But say we have an input for a phone number that's defined in the style guide. Then we realize, oh, if we actually add an attribute with regex in it on mobile phones, we can actually trigger the dial pad. This is a real thing, like, you can actually trigger the sort of like big numbers as opposed to the keyboard with numbers. If we do this, it'll make input easier.

We're going to make this change. How do we make sure that we make this change and then it flows into all of the different places where that particular component is being used, where that field is being used throughout the multiple systems that we have in our organization? Especially large organizations that often times have multiple systems sort of duct taped together.

Realistically, I know of two organizations that do this well. The Financial Times has written a bit about their system called Origami. Lonely Planet wrote about, Ian Feather wrote this great blog post called, "Maintainable Style Guides," where they talked about, at Lonely Planet, how they're basically tying their style guide into their code repository in their development environments.

But otherwise, I mean, I talked to folks at Twitter and they're trying to figure out how to do this. But there's another organization that's very well known for its style guide and they're trying to figure out what to do, and they're redoing their style guide, because of these sorts of issues.

I think once we get to the point where we've got these pattern libraries established and more and more people are doing it, sooner or later, we're going to have to start trying to figure out how to make sure that they're not just abandoned artifacts but they're actually something that has living and breathing purpose.

With style guides, I don't know that it mattered that much, because most style guides didn't have the actual markup and CSS that was being used in them.

But as we're moving to pattern libraries, where pattern libraries could define not only HTML, CSS, but also JavaScript, if they're defining behavior for that particular widget or component. Then you kind of want to make sure that as you make changes to that, that those changes get reflected in all the places where that component is being used.

We haven't solved that, so hopefully, somebody in this podcast takes it up and fixes it and then invoices Google.

Jared: Yeah, yeah. I think that the direction we're heading in here is the right direction.

Jason: Absolutely.

Jared: We've always talked about having style guides and things be living documents and environments, and we're seeing pushes in that direction. I think that that's a good thing.

Well, this has been completely enlightening, as every conversation with you tends to be. I thank you. If people want to really get into this stuff deep and really know how to create incredibly great designs that work on every possible device out there efficiently and effectively, then they need to spend a full day here with you, I think.

You're going to be teaching the "When Responsive Web Design Meets the Real World" at the UX Immersion Conference in Salt Lake City in April, April 13-15th. People can find out more about that at uxim.co. I bet you didn't know that.

Jason: Actually, I didn't know that it had a uxim.co domain. You jest, but you did give me new information there.

Jared: There you go. There you go. You can go and tell me how it's not as responsive as it should be.

Jason: OK, excellent. Well, thank you very much.

Jared: Thank you. It was awesome. Thank you so much.

I want to thank our audience for listening, and as always, for encouraging our behavior. We'll talk to you soon. Take care.