Episode #195 Jason Grigsby - When Responsive Design Meets the Real World
Responsive web design allows the notion of “one web” to be a reality. Designers are increasingly able to sell to their organization the idea of delivering content to multiple platforms. Putting it into practice is another story.
Responsive web design allows the notion of “one web” to be a reality. Designers are increasingly able to sell to their organization the idea of delivering content to multiple platforms. Putting it into practice is another story.
Jason Grigsby, co-founder of Cloud Four, says that it is easier to sell the idea of responsive web design than to do it well. Simply shifting the layout of your design to fit different screen widths is only half of the battle. Page weight is another consideration.
A huge part of mobile experience is performance. Though connectivity speeds are increasing on mobile, shrinking your desktop site to fit on a mobile screen isn’t the best option. Jason says that this is an often overlooked aspect of responsive design. Most of the concern is around how a site renders on various devices, but the importance should fall on the entire experience.
Jared Spool: Hello, everybody. Welcome to yet another episode of the SpoolCast. I know you're going to be very excited today. I know I'm very excited. If I'm excited, I'm thinking you're excited because we've got the amazing Jason Grigsby here.
Jason co-founded Cloud Four, which is the fabulous mobile design and development agency and has sort of become the center of the "How do the hell do you get this responsive design thing done?" world. He is speaking for us at the upcoming UX Immersion conference, which is going to be in Seattle April 22nd through 24th.
I'm very excited that we have a chance here, right now, at this very moment, to talk to Jason about just this stuff. Jason, how the hell are you?
Jason Grigsby: I'm doing well, Jared. How are you?
Jared: I am doing fabulous.
Here's the deal. I'm seeing everywhere people are buying into this responsive design thing. It's like the Gangnam Style of the web. Everybody is buying into this thing. They are selling it to their boss. They sell it and they sell it and they sell it and the boss finally goes, "OK. I get it. We have to make everything work on all these different devices. Everything's got to get big and small and do all this stuff."
The boss says, "I've got it. Give me something in five months. Go."
And then all these people go, "Oh my God. What the hell did I just get myself into?" Because, as I understand it, it's easier to sell responsive design than do responsive design. Have I got that right?
Jason: I think that it's easier to sell than to do it well is the way that I would describe it.
Jared: What does not doing it well look like?
Jason: There's a few different ways. I think the most prominent way is when I did a survey in 2010, I went to the Media Queries gallery, which is a bunch of responsive designs and looked at them. I found over 80 percent of the sites were built in a fashion that the mobile version of the site, essentially what you would see, or mobile screen size of the responsive design, was the same size or larger in total page weight as the desktop version.
The same thing was true of a study that Guy Podjarny did this year. He looked at 347 sites and he found that only three percent of them were significantly smaller on small screens. You would expect it to be much smaller.
What's happening is, is that people are basically just taking their desktop site, adding some media queries to it, and shoving it onto the small screen. What you end up with is something that looks OK for mobile but is...
For example, Disney just did a responsive design. Their responsive design looks great. It's 4.5 MB on an iPhone, which is far, far too big, even if somebody's on WiFi. It's just way, way too big. And it doesn't need to be that big. If it was built properly, it would be much smaller.
I think that's the part about doing it well that people really miss. We know statistically that they miss it, because the vast majority of sites are built that way.
Then there's a bunch of stuff that gets hard with infrastructure and decisions and changing your process. I think that there are pieces of it that are hard, just generally doing a responsive design and bringing responsive design into an organization.
Then I think that there's a whole area of responsive design that most people aren't focused on, but that is actually critical if you're going to actually build something that is fast and responsible and people have a good experience. It doesn't just look good, but it actually feels good.
Jared: This is shocking to me because the whole idea of getting stuff for mobile was to get it so it works well on mobile. If the performance is slow because the page sizes are too big, that's a step backwards.
Jason: That's an interesting...Is it really a step backwards? I think...I read a blog post a little while ago that said that number one thing that you could do to make your site optimized for mobile is to make it faster. The point that I was making was that most of the modern smartphones actually have really good capabilities for displaying a desktop site and allowing somebody to tap in to read text or pinch and zoom to zoom in to read areas of the page.
It's not as nice as if the page is designed correctly for mobile but you can get around on a desktop site without too much trouble. There are gestures to support being able to read desktop content on a mobile phone. There's no gesture that any user can do that will make the thing load faster. The only gesture they're going to give you is a single finger up in the air as they run away from your site.
The whole idea of building something that looks good but actually takes too long to load and so nobody actually bothers to visit it is, I think, really problematic. I don't know whether it's a step back because these sites are too slow now. They're slow but they look good on the sites on the phone so it's, I guess, a little bit of a step forward but it's not doing it well. I think we could all agree on that.
Jared: Yeah. Is the strategy, you think, to get a slow responsive site first and then make it fast or should we be thinking about speed up front?
There's an old saying in the programming world which is you don't optimize code that doesn't work yet. But are there things we understand how to do to get faster code sooner? Does that make sense?
Jason: Yeah. I would say that it's not that doing things in a way that implementing it is incredibly difficult. It's just not what most people first do when they start doing responsive design.
The primary way to actually make things fast on responsive is to do mobile first responsive web design, which means...Luke Wroblewski has taught about mobile first from a design perspective. In that, he's talking about the constraints of small screens enabling better design.
What I'm talking about isn't that, although it borrows that name. What I'm talking about is actually technical implementation. It means reordering your style sheets so that the styles are based on the screen size and go from small to large. You can use the cascade of CSS to progressively enhance the page from the small screen to the large screen.
When you do that, you run into some challenges that you don't run into if you just throw media queries at the end of your style sheet to make things look mobile. That's where some of the tricks come in and where people start running into problems with, say, responsive images or retina displays or IE before 9, because IE before nine didn't support media queries.
These are all things that I guess, with the exception of responsive images, which we're actively working on with the W3C and the web WG. The rest of them are sort of known solutions, they're best practices on how to solve these things. It's just that overall awareness of them is lower than I think they need to be, or than it should be.
Jared: This is good news then. There are things we know how to do to get the page size down and be able to get these responsive sites to literally be more responsive, because they're faster, because they load faster and people can work with them.
Jason: Correct, correct. Yeah, a couple years ago, when Ethan wrote his piece on responsive design, I was looking at the problem and basically nobody had really worked out how to do this stuff. At the time, it was like, yeah, responsive design may make sense in some cases, but you should be really, really hesitant of it because of these issues.
Fundamentally, if you have a site that looks good but it's so slow that nobody visits it, you're not going to accomplish your goals, you're not going to solve things. I mean, every single study we've ever seen says that performance matters in major ways to conversion in UX and perception and all of these different things.
In the last, I would say that since that time, two years from now, we've reached a point where we view responsive design as the default approach in our project. We basically looking for reasons why we might not be able to do it.
We hope we don't bump into them, but sometimes there are organizational issues. Maybe the current system is too complicated to do responsive design and so they're going to do device detection and do responsive design on the mobile version of their site and hopefully eventually replace their desktop version with that mobile version. By mobile, they're doing responsive design on that.
Those are cases where responsive design can't be done or can only be done in conjunction with device detection. Other than those times, we start from the premise of, we can do responsive design and we can do it in a way that's fast and looks great. Then only use these other tools if we need to use them.
We've come a long ways in that two-year period.
Jared: How did you get started in all this? What sort of got you in the center of this world?
Jason: We'd been doing a lot of mobile related stuff and had been, like everybody who did mobile web, responsive design before media queries became popular, we had been doing them using device detection.
The first time I saw a site that was doing responsive design was before Ethan had coined that term. Somebody brought it to us because it was really slow on mobile. Basically, what I found was that there were Google maps embedded in the site that didn't show up on mobile. But that Google maps code resulted in, I don't know, it was somewhere like 40 to 60 different files getting downloaded.
Jared: Oh, wow.
Jason: Yeah, all these images. I mean, it completely bloated the page. But it didn't even show up. That sort of alerted me to this issue.
Then, last year, my co-founder, Lyza and I, we wrote "Head First Mobile Web." When I had published my article talking about the performance issues with media queries, the response that everybody said was, OK, Jason's right. This is a big problem. But all we need to do is do mobile first responsive design.
So, when we were outlining the book, we said, OK, well, chapter one will be responsive design and chapter two will be mobile first responsive design. We'll go figure out what people are doing for mobile first responsive design and we'll just write it up, right? Easy enough.
Then, we found out that nobody was doing it. [laughter] Which meant, essentially, that we ended up having to plow through a bunch of research. Everything from responsive images to techniques for doing progressive enhancement from small screens up to large screens in order to be able to complete the outline that we had committed to.
And I'm really glad we did. I think that that research, particularly the research on images has turned out to be pivotal to the work that's being done now by others to redefine HTML to support responsive images. But it was sort of inadvertent. We just didn't know what we were getting ourselves into is really what it amounts to.
Jared: Yeah, that's a common story that we hear. That people just suddenly that they're in the middle of this stuff and they sort of back into it, not knowing. So I'm really interested in what's going on with responsive images. Help me understand the problem. So the problem started with the fact that different screens have different resolutions, right? And now with things like retina displays the resolutions could be wildly different, right?
So that means an image that has got a small number of pixels in it might look good on a small screen with a small resolution, but you then blow it up on a big screen and it looks like crap. And similarly, an image with a lot of resolution looks great on that big screen or that high resolution retina display, but suddenly I'm now downloading all of this weight and then have the local processor shop most those pixels out to be able to display that image.
Jason: Correct. Yeah.
Jared: So how is this possibly solvable? I mean, either I've got high res, or I've got low res. I mean, what's the ideal future for this? That somehow or another the image is smart? Or that the server technology knows what it's talking to? Or is this handled all on the client but with some sort of wacky ass compression?
Jason: [laughs] So when it comes to CSS, we're in a reasonably good spot. So CSS background images, you can define different sizes for everything based on screen resolution, screen width, or pixel density, or any of those sorts of things. So on the CSS side, we're actually in really good shape. It's actually just in HTML that we have the big issue, which is we've got an image tag that only has one source. And there's really no way around that. So the long-term picture is we either need changes to the mark up in some fashion, or we need a new image format. People point to something like JPEG2000 which allows progressive downloads.
So the same file could be used and the client would only grab what's necessary. So a phone might grab the first 30K of an image and that's all it needs to display this image on its device. But a large retina screen, iMac, might grab might be grab 200K or something like that. Those file formats are theoretically possible. From a practical perspective, there are a lot of reasons why that doesn't seem to be where we're headed.
The cynical version of this is that there are patents involved and nobody seems to be able to agree on a format. And that's essentially problematic. It's great to say that we should have this magical format that works this way and that everybody should adopt it, but if there's no political will to do so from the browser makers then it doesn't really matter. The second issue is that the big problem that we have, and this is going to be a little technical, probably even a little bit more technical than I might talk about in a workshop or something like that.
But the big conflict between the image and the browser is that the browser wants to do what they call the look ahead prefecture, which is it will start downloading assets in the web page before it's figured out what the layout is going to be. And the problem is that even if we had this magical image format, in my dream world what we'd have is this magical image format and I would upload the highest resolution version of the image that I have.
Because I don't know in the future if I might use it at a larger resolution or something like that. So I'm going to upload the highest resolution I have. Now, what could happen is say it's a small image being used on a large screen. What the browser wants to do is it wants to use the size of the screen, the size of the view port really, as indicative of how much of the image it should download because it doesn't know at the time it starts downloading images what size the image is actually used on the page.
And so what you could end up with is a really, really large download for an image that's being used as a small piece of the page. So we run into what I think of as the conflict between the person who likes to travel and schedule everything. I know exactly where we're going to be and what we're going to do, versus the person who goes on that trip that's like, yeah, I don't want to have anything planned. It's that fundamental conflict between the web developers who really want to be able to define what this experience is going to be and what size file and all this stuff and the browser that's like, I'll deal with that later. I'm just going to start grabbing stuff.
Jared: I know exactly what you mean. I used to travel with this coworker and we'd go on these three or four day trips. And she couldn't decide what clothes she wanted to wear in advance, so she would bring her entire wardrobe. So I'd have this tiny little bag that the exact number of shirts and pants and maybe one extra of everything and she would bring two bags of suitcases because she'd just basically take everything with her. And then she would decide and she would wear one tenth of it. And so it would take her forever to unpack and pack. It was crazy to travel with her.
Jason: [laughs] Yeah. So we've got this fundamental conflict. Whenever people propose solutions to the problem, they end up bumping up against that. And I don't know what the end solution is going to be. What we do and what we're recommending for others is there's some techniques that avoid these problems and allow you to define different size images for different size view ports.
And we basically say, hey, this is what you should use now. This works. It'll allow you to have a web page that performs well. And you should make sure that whatever you do, however you solve this problem, and there are a couple of different techniques to do this, that you've built it in a way that you can replace it two years from now. Because I don't know what the solution is going to be, but I know that whatever you're implementing now is not what's going to be there two years from now.
And so if we know that that's the case, we should plan for the fact that it's going to be deprecated and then plan around it. And I think these are the sorts of challenges that happen when responsive design hits the real world. It's the same sort of thing when organizations realize, hey, our existing content management system is really problematic for us. Or our waterfall design process isn't going to work in a world in which we need to make multiple design decisions as we're adjusting to screen resolution as we're resizing our browser.
The designers aren't going to design the entire design across that whole continuum. They need to be working together with developers, and that means a change in our process. And these are the sorts of challenges that people run into when they actually get to that point where the boss is like, "Yes! You must have this site up in five months."
Jared: Right. The other thing that somebody asked me about the other day, and I didn't know where we were with this. Is responsive design still really only good for content sites? Or can we start to get into web-based applications and make it work there?
Jason: I've got a blog post coming on this, Jared. It's been permeating like all my mind for two or three months now. And I just need to sit down at some point and write it down. So I'll give you the short version of this. We had a client who asked us to help with sort of taking their whole infrastructure and making the transition to responsive design. Part of it was that they had some applications and those applications were using UI frameworks, Kendo UI and a precursor to that.
The thing that they had, though, is they basically had these desktop apps. I'm like, we need to figure out how to make this work. I spent a couple hours looking at this and trying to figure out how to take their desktop application and make it work responsively.
After sort of banging my head on the desk for a couple hours, I stopped and said, "OK, forget this, I'm just going to figure out what it would look like if I did mobile." Once I did that, it became really apparent how the responsive design would work up to desktop.
The other piece that this process made me realize was, the Kendo UI folks have this interesting blog post where they talk about how they feel like tablet UI is so fundamentally different than phone UI that you can't just do a phone UI and have it work for tablet or vice versa.
I read the post and that line really struck me because the Samsung Galaxy Note II is a five-inch display device. That's a phone. We have tablets that are seven-inch devices. Is there really that much difference between a five-inch phone and a seven-inch tablet? Does anyone think that across the continuum of things that we're not going to get a six-inch tablet or a six-inch phone? That we're going to continue to have this gap there?
The whole idea, then, that somehow a tablet design is fundamentally different between seven inches and five inches is crazy.
If you take that and you start extrapolating from that, then you start looking at the fact that tablets are now going from seven inches to 13 inches. We've got these Windows eight devices that have touch in the laptops and have detachable keyboards. They're like tablets/laptops. Where does the continuum stop?
If you're building a desktop app, and you're doing a web-based version of it, it could be used on a Microsoft Surface device, which is touch enabled and becomes a tablet. If you're not building it responsively, how in the world are you making a decision about what is desktop and what is tablet, or what is tablet and what is phone? There are no lines anymore.
When people are building applications, yeah, it's harder to do responsive than it is to do segmented versions of it. I just don't believe that, I believe that you're going to have an unsolvable problem of segmenting device classes.
If that becomes true, then given the choice between the impossible task, like just mathematically proof impossible task of defining differences between these device classes and building something that's responsive. I'm going to take the challenge of building it responsively versus trying to prove a negative sort of math level, not possible, where do these lines end up?
Jared: I mean, because you have to draw the lines in so many different places, right? Because there's definitely, if you're working on an 11 inch tablet, the larger iPad, for example. The ergonomics of typing are very different than typing on an iPhone and very different than typing on a desktop with a keyboard. I haven't tried the Surface yet, so I don't know what that typing experience is like.
You've got some fundamental ergonomics for just typing right there. I would think that because an iPhone in portrait has such a restrictive width and an iPad in landscape, particularly with Retina, has such a broad width that there are things in layout and things you can do in design that you can't get away with the same in both places, right? You've got more to work with in one and a more constrained resource in the other.
Then the question becomes, I think, if I'm hearing you right, what you're saying is you have to look at this on an app by app basis and say, "At what point does it make sense to start interacting differently based on what your data and what your app needs and less about what the physical device is?"
Jason: I think what you touched on is actually the key, which is a lot of what people talk about in the differences, and they talk about, "Hey, we're going to do something that's for desktop because somebody sitting at a keyboard and mouse is doing input differently."
The first piece is that that is no longer true. Somebody sitting at a laptop that's a Windows eight laptop has a touch screen. They may be trying to hit those targets that you've defined and were thinking of somebody hitting with this really tiny pointer with their fat finger. This was something that Josh Clark has written about and that Luke has been talking about. They're right on. Touch is the baseline experience because touch goes across all the device classes.
If you build something with touch in mind where the targets are larger and it's easier to hit, because Fitts's law, it's going to be easier to hit with a mouse, too.
From a design perspective, I think that that informs us to say, "Hey. It's not that we're going to be designing differently for one category of devices versus another. We are going to be designing differently, but we should be designing for touch across that whole spectrum," which is a change.
Then I think that the big challenge, and particularly for web developers, is to try to start thinking about input as progressive enhancement in that the presence of a physical keyboard, how do we support that keyboard in a better fashion if it's present? Or how do we support input with the Kinect on Xbox, which now has Internet Explorer? Or a remote control when it comes to TV.
This is something Luke has been talking about for a while. His company's all input factory and everything. I think that input is a bigger determinant of what we need to do with the interaction design of the things that we're building than anything that we're making decisions on based on form factors or screen size. I would state that it's not solved by any extraction of the imagination.
But I do think that where we're headed, clearly, is that even for applications, that responsive design is going to make sense because the ability of an individual application to predetermine what classes of devices are going to interact with it is just gone, fundamentally. Particularly from a web based perspective.
If you're doing stuff natively, you probably have better control but web perspective, you cannot.
Jared: Yeah, my mind's about to explode.
Jason: I'm sorry. I ranted on that.
Jared: No, but I think you're absolutely right. This is just so complicated because I'm thinking of even little specific use cases. If I'm sitting at a desktop and I have a mouse and I select text, the browsers on the Mac, for example, can interact with that text. I can put a bold button in and it can then react to the selected text and bold it.
But on the iPhone, getting that selected region back to the app is actually really hard to do. Right? And so, now I can't implement a bold function for selected text inside a paragraph. And, in fact, just the act of selecting text with a finger is ergonomically far more complicated than selecting text with a mouse.
Jason: But the thing is with selecting text, the thing that allows you to do that is...I hope that I'm remembering this correctly, but it's content editable, is the...
Jared: The attribute.
Jason: Yeah. And you can client side test for content editable. If that's a key piece then you need to be testing for the existence of that and either your baseline experience doesn't assume that that exists and you've got other ways to get things done like type in the bold tag or sometimes maybe your baseline experience just absolutely requires it. You've built something using WebGL or something and you're doing a game, in which case you progressively enhance from a web page that says, "Sorry, you need WebGL," and then you feature attack for WebGL and then you build the whole thing.
I think that the reality is is that this stuff has always been out there. It's always been a bit of an issue but the percentage of diversity was low enough that we thought that we could ignore these issues. Now it's just...The diversity is right there staring us in the face and we just have to start building it in a way that...
I think that the big thing that Ethan did, even more so than defining the ways in which people do responsive design, was actually defining the mindset that we need to have as designers and developers to be responsive to the environment in which the user is interacting with what we've provided them. I think that that's going to be true for apps and for content-based sites.
Jared: Yeah, I would agree with that. I think that responsive design is one of the biggest things to happen to UX in the last...In that it creates all of these questions and issues that we still are struggling to get good answers to but it is definitely the path of the future, I think.
Hey, Jason. Thank you so much for taking time today to blow up my brain in this new and novel way.
Jason: Well, one of these days I'll actually get that blog post written and then, I'll think, more clearly articulate what I'm trying to say here.
Jared: Well, good. We'll have a nice transcript of this discussion for you to start with.
Jared: Thanks. It's been wonderful.
Jason: Thank you.
Jared: I want to thank you, our lovely listener. Yes, you. The one sitting there with the headset on. Yep, that's you. I want to thank you for taking the time today to listen to Jason and suffer through my silly questions as he gave brilliant answers.
If you have a moment and you listened to us by downloading the podcast from iTunes could you go to the iTunes and give us a rating and tell us how we're doing? Because that really helps us. I would appreciate that.
Thank you again for encouraging our behavior and we'll talk to you soon. Take care.