Jason Grigsby – Mobile-First Responsive Design
Podcast: Play in new window | Download (Duration: 18:16 — 9.7MB)
Subscribe: iTunes | Android | RSS
Speed and performance are a critical aspect of mobile design. Using media queries to design your site responsively is a great way to ensure proper display on mobile devices. But just shrinking a desktop site to work on a mobile device can affect performance.
In his virtual seminar, Mobile-First Responsive Design, Jason Grigsby shows us that it is a much better option to start with the smallest assets, then progressively enhance towards the desktop version. Simply reversing the traditional responsive web design approach allows you to optimize your users’ mobile experience.
The audience asked a ton of great questions during the live seminar. Jason joins Adam Churchill to tackle some of those questions in this podcast:
- Is there a better way to create mobile-first designs for HTML emails?
- What options are available on initial server requests to send specific information?
- If you’re loading pages while you’re practicing this mobile-first responsive web design, what are the effects on search?
- How can you handle dynamically loaded images that come from a feed or an API?
- How do you decide on good break points on a new site started from scratch?
As always, we love to hear what you’re thinking. Share your thoughts in our comments section.
Recorded: September, 2012
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Recently, Jason Grigsby, author of “Headfirst Mobile Web,” joined us for his virtual seminar, “Mobile-First Responsive Design.” In the seminar, Jason teaches you how to practice mobile-first responsive web design in your own designs by reordering your CSS, assets, and images. He also shows you how to handle retina-display images and which tools to use for mastering mobile-first.
Now, this seminar has been added to UIE’s User Experience Training Library, where, at this point, there’s over 100 great seminars, from wonderful topic experts just like Jason, giving you the tips and techniques you need to create great designs.
Hey, Jason, thanks for joining us again.
Jason Grigsby: Thank you.
Adam: For those that weren’t with us for your seminar, can you give us an overview?
Jason: Sure. The main topic of the seminar was about how to create mobile-first responsive web designs. When we talk about mobile-first responsive web designs, we’re sort of combining two things: mobile-first theory, which is something that Luke Wroblewski has written about and talked about, where designing for mobile-first creates better products; and responsive web design, which is the description Ethan Marcotte put on designing websites that respond to screen resolution and things like that.
But when we talk about mobile-first responsive web design, we’re actually talking about a very specific technical technique of starting with the smallest assets, the smallest CSS, and then progressively enhancing it from that small-screen version up to larger screens, as opposed to the way that a lot of responsive designs are done, which is to start with the desktop version and then gradually shrink it until it fits smaller screens.
A lot of what we talked about in the seminar is why this matters, why people should do mobile-first responsive web design instead of responsive web design. The main reason for it is because there are big performance implications of basically taking a site that’s designed for a desktop and just shoving it down the pipe to a mobile screen.
Things work much, much better for mobile devices and really for any device if you start with the most basic content and assets and then progressively enhance it up to the larger assets.
But when you do that, when you switch that around, what you find is that you run into challenges. Internet Explorer doesn’t understand media queries so you have to use conditional includes in order to address Internet Explorer, what do you do with the image tag which only has one source, and all these sorts of things.
The seminar was really all about how do you actually build things that are Mobile-First Responsive Web Design, why you should do it, and a little bit of the fact that what we’ve seen when we look around and take a look at the sites that are built using Responsive Web Design is that many, many of them are not actually doing Mobile-First Responsive Web Design, and why that’s a bit of a shame.
That was the thrust of the seminar, and hopefully people were to take a lot out of it and able to start building sites in that direction. I’d like to see more Mobile-First Responsive Web Designs out there.
Adam: Some great questions that were left over, we just didn’t have time to get to them. Cinnamon has a question about media queries. She says they use them in HTML emails where they can’t use external CSS or JavaScript, and while this is taking us off the path a little bit, she wonders if there’s a better way to accomplish Mobile-First design on email, too.
Jason: Actually I think that what she describes is the best way to approach email and providing email, particularly when doing HTML email, that will work across different screen resolutions. Unlike the web where we can do progressive enhancement because we can selectively apply CSS, download CSS, use JavaScript to modify that, deliver different image assets, these sorts of things, we don’t really have any of that control from an email perspective.
As she notes, you basically end up with one HTML, CSS for that email. You don’t really get to change it using JavaScript, or you can’t reliably change it using JavaScript. What you end up doing from a performance perspective is trying to make sure that the assets that you’re delivering are as small as possible, that you’re taking into consideration the fact that somebody may be viewing it on a phone.
Really, when you’re designing HTML emails, you should be considering what the design looks like before the images load anyways, because some of the more popular email clients–Outlook comes to mind–block images by default. And so, there are going to be a bunch of people who see your email without the images in it at all.
What she describes is the way that she’s using HTML to deliver for different sizes by using media queries, is the best way to do stuff, from an email perspective. And then test, test, test. Like everything we do mobile, you have to test on a bunch of different devices to see how it looks.
Adam: Chris wants to know what options are available on initial server requests that we might use to send specific information.
Jason: Yeah, this is an interesting option and something that we didn’t talk much about in the presentation. But a lot of us have been experimenting with ways to use device detection. Device detection relies on using the user-agent string of a browser to identify the browser, identify the device, and provide some information, maybe identify the screen resolution, the type of device it is, things of that nature, and use that to inform the sites that we’re building.
Now, oftentimes, people think about device detection as a “one or the other” sort of thing. Either you’re doing responsive design or you’re using device detection to route people to separate templates, and that you would choose one of those two options; you wouldn’t build something that uses both. But we’ve actually combined responsive design with server-side detection quite a bit. Luke refers to this as RESS, Responsive Design with Server-Side components.
One of the examples is we’ll do responsive design and we might use device detection to set a smart default for image sizes on that initial load and then use JavaScript to detect the screen resolutions, view-port size. And if, for some reason, the device detection got it incorrect, then correct it. Adjust that.
This technique is based on some of the stuff that Bryan and Stephanie Rieger have done for Nokia’s browser site, where they’ve got a really complex responsive design and they’re using this profiling technique to set a default profile and then adjusting it at render. They’ve got a bunch of slides. Their company’s called Yiibu, Y-I-I-B-U. Definitely, people you should follow, and their slide decks are gorgeous and you can get a lot out of what they’ve done.
Another sort of thing is, even on sites where we’re using separate templates, where we’re doing device detection to route people to different sites. We end up doing responsive design, because there is no one size for mobile, so even if we have to do a separate mobile site, we’re still going to do responsive design on that mobile site.
Back to this original question. I think there’s a lot of utility in having device detection as a tool in your tool case that you can pull out and say, “Hey, we’d like to know, on the initial load, some default information about the screen resolution of this device and other characteristics of this device so that we can send the best possible combination of HTML and CSS down to the device. Then use JavaScript to double-check that and make modifications from there.”
Adam: Jason, one of the things that you spent some time talking about was page load. If you’re loading pages while you’re practicing this mobile-first responsive web design, what are the effects on search? The example that’s given here is, for instance, pulling content in via Ajax.
Jason: This was actually something that was really unclear to us until recently. Last year, Google, in particular their mobile advertising group, had said that they were going to start weighting ads, providing higher placement for ads that were going to mobile-optimized sites versus sites that weren’t optimized for mobile.
At the time, I sent some notes to friends of mine that work at Google and asked, “How do you know? How do you know if this site is optimized for mobile or not?” Because, at the time, people were doing responsive design, and some people were doing separate sites.
I got a response back that was not definitive and wasn’t something that I could publish but basically hinted at the fact that what they were doing was looking for separate sites. And so, if you’re doing responsive design, you might actually be paying a penalty from at least a mobile-advertising perspective. It wasn’t clear what search was doing.
Thankfully, in August, Google came out with clearer statements on this and said their recommendation for people who are trying to solve device diversity is to do responsive designs. That’s what they’re looking for. They’ve got a bunch of documentation in their Webmaster Central about what to do if you’re doing responsive design and how to handle their main Google bot and their mobile bot. They also have some documentation on what to do if you’re enhancing the page using JavaScript.
Generally, what they say is that, if you’re delivering HTML and CSS and JavaScript to all the devices and then, when the JavaScript executes, it changes based on the device that’s rendering it, that they can handle that, that they’re ready to look at that, that they know how that works. I believe that if you’re using techniques like…The example that we used in the seminar was a technique that the Filament Group has documented, called Ajax Include. If you’re using that design pattern, that technique, you should be totally fine from a search-engine perspective.
I think that you’re going to get better value out of doing things like submitting your site map and monitoring things in the webmaster tools than worrying about whether Google’s going to be able to handle the JavaScript. If you’re monitoring that stuff, then you’ll make sure that that content is getting indexed properly.
Adam: Olawale asks a question about how to handle dynamically loaded images that come from a feed or an API, in particular when you don’t have control over the size and resolution of those images.
Jason: Yeah, this is a great question, and I think, in some ways, it depends on how much time you’ve got to invest in the problem.
We’ve done a couple of things like this. A few years ago, I guess it was 2008 at this point in time, we were part of the team that helped build Obama’s iPhone app, and we were pulling in stuff from Obama’s blog, campaign blog.
We had this exact same problem. We had videos and images and things that were inside the feed, embedded in the body of that RSS that were not appropriately sized for mobile. At that point in time we really couldn’t do anything about it. It was inside an app. We didn’t have a server sort of parsing the feed and then making changes to the images. We ended up using a combination of CSS and JavaScript.
We would look for things like images and video components and we would use the JavaScript to go modify the HTML and shrink it. We’d end up delivering larger assets than we needed inside it, but it worked really well and people got a great experience because of that. We actually were complimented on it by some of the users of the application.
If you’ve got a little bit more time, you could set up a site in between the feed and your feed and again look for those assets inside the feed and then do your own processing, do image manipulation, resizing, video resizing and then modify the markup before you deliver it to the device.
But if you’re consuming stuff in-feed you’re stuck until we get a new element or standard for images that will allow us to embed different sources within HTML.
Adam: Our friends at UC Berkeley, they wanted some follow-up on your advice about adding a break point when the view port doesn’t look very good and it assumes an already developed desktop-first designed site.
The questions regarding that are what if you’re developing a new site from scratch so there’s nothing that exists yet and you’re starting with this Mobile-First Responsive Web Design approach. Then, how do you decide on good break points?
Jason: First, I think that the point made in the presentation is something that I think is really critical. Most people, the first time they do a Responsive Design often times end up sort of picking break points incorrectly, in my opinion.
What happens usually is first time somebody looks at a responsive design they try and figure out how to deliver something for a mobile device and so they’re like, “Ah, awesome. What we’re going to do is we’re going to add a break point that’s at 480 pixels, we’re going to add the media query, we’re going to change the layout to 480 pixels and now we’ll have a mobile layout.”
They pick 480 pixels because that’s the longest dimension of an iPhone, and that’s the device that they have at hand. But this idea that you are picking break points based on devices is actually really problematic.
First off, even the iPhone doesn’t have set dimensions. The iPhone 5 just came out. It’s now a different set of dimensions than what we had previously. You can’t assume that those dimensions are going to stay the same. They are going to change over time, which we should expect.
Second thing is that once you go past the iPhone, you start seeing very, very different sizes. So you’ve got the Samsung Galaxy Note phone which is very large, to Blackberries with keyboards that are small. You can’t declare that anything under 480 should be a particular resolution.
At some point, you find yourself asking, “OK, how do we select what the break point should be?” What I asserted in the seminar is that what you do is you build your responsive design and then you adjust the size of the screen. When something starts looking bad, that’s when you add a break point. That’s the best way to do it.
Now the question here is about this idea that they work better from this idea of you starting from a desktop-sized design and then you’re shrinking it, you’re shrinking it, and then at some point you’ve squished it and it looks too small, and then you insert a breakpoint.
I don’t believe that during the seminar that I said that you would necessarily do that from the desktop down, as squishing it and then that would be when it would look bad. Because I think the opposite is true, too. If you start from a small screen and you make the screen wider and wider and wider, at some point it just looks odd. It just looks too wide. The text, the lines are too long, that sort of thing. There’s no reason you can’t do it the other direction.
But I would also say that the vast majority of the time when we’re working on a responsive design, even if we start with the mobile design first, we’ll have a sense of what the mobile design will look like. Then we’ll also have a sense of what the small-screen version will look like, and then we’ll have a sense of what the wide-screen version will look like. What does it look like when the screen’s bigger? We’ll design both of those endpoints.
Then we build the responsive design around those endpoints. And then, when we’re resizing, that’s when we can identify where to make changes. “This is the point when we should go from one-column to two-column to three-column.” That stuff.
And so, I guess the question that’s asking about starting from mobile-first and whether or not it makes as much sense, yes, I think that you could do that. But I doubt that you’ll ever be in a case where you’re not actually having the small-screen design and the big-screen design, those ends on the continuum, defined in some way, and then you’re resizing between those and picking breakpoints based on where things don’t look good.
That’s the way to go about it. I don’t think it makes any difference, really, from a technique perspective, whether you’ve built your HTML or whether you’re doing things mobile-first or doing things desktop first.
Adam: Very good. Well, Jason, thanks for joining us again, and look forward to you speaking to our audience again in the near future.
Jason: Thank you for having me.
Adam: To everyone listening in, thanks for your support of the UIE Virtual Seminar program. Remember that you can get all the details on upcoming seminars and fantastic recordings just like Jason’s at uievs.com.