March 11th, 2013
The proliferation of mobile devices has made it necessary to rethink your web experiences. The mobile phone and tablet, along with retina displays, have substantially changed how a user experiences your design. Responsive web design has emerged as a solution in some cases, but even though connection speeds on mobile networks are increasing, performance remains an issue.
Luke Wroblewski has a wealth of experience with the mobile web. He suggests that the definition of “mobile” itself is blurring as devices continue to evolve. Rather than designing for device specifications, Luke says it’s more important to think about the context in which these devices are being used.
During his virtual seminar, Organizing Mobile Web Experiences, the audience asked some great questions. Luke joins Adam Churchill to cover some of those questions in this podcast.
- When you talk about “mobile”, does that include both phone and tablet?
- Is it better to use responsive web design than a separate mobile site?
- What are the benefits of native mobile applications vs. responsive UIs?
- How do account for different use cases when employing responsive web design?
- Does quality become an issue with the code base increasing to make sites adaptive?
- Should you make decisions on breakpoints based on content or device?
- Should you design differently for small screens and small windows?
Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Recently, Luke Wroblewski presented a virtual seminar called “Organizing Mobile Web Experiences.” Luke’s seminar, along with over 100 others that teach the tools and techniques you need to create a great design, is now part of the UIE User Experience Training Library.
In this particular seminar, Luke detailed the latest in mobile-design thinking and offered up solutions that will help you organize your websites and applications. He also showed what’s coming next and, best of all, how to help your designs remain future-friendly.
Hey, Luke. Thanks for joining us again.
Luke Wroblewski: My pleasure. Happy to be here.
Adam: Hey, for those that weren’t with us that day, can you give us an overview of what you talked about?
Luke: Sure. We focused on the art of organizing all your content and activities and structure of websites and applications in an ever-increasing, multi-device Web. We talked about a number of things, but we started out by outlining what are some of the things that mobile devices and the proliferation and heavy use of mobile that’s going on today, what are the sorts of things that that influences when we start to think about traditional website navigation, menu systems, organizational structures.
Once we nailed down where mobile takes us, we then built up from that mobile foundation to really create adaptive navigation and organizational experiences that support a whole range of devices.
It’s a pretty exciting space, I think, because, while we focused on organization and navigation, the techniques that we outlined can really apply to just about any component on the Web, We talked about nav and menus, but forms, content layout, any kind of interactive components, all these things can have the mobile-optimized perspective, and then use that mobile foundation to extend out to a wide range of devices.
Adam: One of the things that came up early on in the seminar is, there was a lot of talk about devices. Some folks were asking, “Does that mean specifically mobile? Does mobile equal phone? Does it include tablets?” Can you speak to that a bit? One of the questions that we didn’t get answered during the seminar asked about interpreting the device-usage graph based upon the answer there.
Luke: Yep, and boy, is it getting blurrier and hairier as we go here. In that short little overview, I think this sort of outlines where we’re going. It’s very difficult now to clearly outline exactly what’s a mobile device. It was a lot easier back when we had feature phones. And then out came the iPhone. It was really the first mobile computer on which you could browse the full Web. That was easy to grok. It was this 3.5 inch screen. It was pretty much the only thing out there.
Since then, what we’ve seen is mobile devices spanning the range from 2 inch screens all the way up to almost 7 inch screens. When you start getting towards the 7 inch screens, there’s 6.8 inch “phoblets” or “phabtops” or whatever. I don’t even know what you want to call them these days. They’re combination smartphones and tablets.
From that 6 inch range, they come down to 5.5 inch screens, things like the Galaxy Note. It’s not uncommon to have 4.5 inch screens. In fact, 30 percent of new Android devices sold in the past, I think, four to five months were 4.5 inches or higher.
Our traditional definition of what a smartphone is — this 3.5 inch screen — is really blurring. As tablets continue to blur as well, into smartphones and into laptops, it’s this really muddled space.
Which is why I think we need to think about adaptive, multi-device designs. It’s very hard now to quadrant things off. We have to make sure that we work on a full range of screens, regardless of what people may label them. As I alluded to some of these terms, like “phonblet” or “tabtop” or whatever people are calling them, it’s becoming silly to a certain extent.
To go back to the question with that context in mind, when people say, “Does phone equal phone or tablet, or both?” the way I like to think about mobile is, what enables mobility? That is, what size screen and computer can you conveniently carry with you, can you interact with with the palm of your hand anywhere and everywhere? For different people, that cutoff is a different size, depending on your sort of human ergonomics, but it definitely isn’t a single point in the spectrum. It’s a wider point in the spectrum.
When we look at studies of how people use traditional iPad-sized tablets — which is about a 9.7-inch screen, about a 10-inch screen — for those, only six percent of iPad sessions are actually on cellular networks, whereas for an Android or iPhone smartphone, it’s in the high 40 percents. 45, 42 percent of all network connections are on cellular networks. Which means that smartphones are definitely getting out there on mobile networks a lot more than the 10 inch tablets are.
Also, I believe 30 percent of time spent on the iPad is on the couch, and 20 percent is spent in the bedroom. It’s really, by those factors, more of a “mobile in the home” device. As you start to get to smaller and smaller tablet sizes — that is, you start getting down to more of the 7 inch range — all of a sudden these things start to become a lot more portable and thereby mobile.
I don’t think you can say “mobile equals tablet” because there’s this wide range of tablets. And I don’t think you can necessarily “mobile equals smartphone” because there’s a wide range of smartphones. I think you have to look a lot more at the modes of use and are they really mobility-driven. Are these things that people are taking with them anywhere and everywhere using them as a mobile device as opposed to the industry term for these devices.
Adam: Luke, what are your thoughts on the responsive-design experience versus the m-dot experience?
Luke: This is a very good follow-on question to what we were just talking about. Because of this continuous range of screen sizes, and variants and differences between mobile devices bleeding into tablets bleeding into laptops, it’s really, really hard, as I was saying earlier, to draw lines between things.
What responsive design allows you to do is build an adaptive layout that if a 5.5 inch screen or a 6 inch screen hits my website, it really doesn’t matter to me. The layout’s going to work well in both. If a 10 inch tablet or an 8 inch tablet hits it, it doesn’t really matter. It’s going to lay out really nicely.
When people talk about that sort of adaptive interface versus an m-dot experience, with the m-dot experience, unless you’re building your m-dot experience responsively, you’re missing out on a lot of that fluidity, that adaptiveness, and that possibility for your web service to work on a wide range of devices that’s ever increasing.
I personally think the benefits of that fluidity and flexibility outweigh some of the benefits of a separate m-dot experience today. It used to be a little bit different. All you had to contend with, as I was saying earlier, was the 3.5 up to 4 inch smartphone size as mobile. Now that mobile’s definition is totally blurring because of what we’ve [laughs] been talking about, I don’t think you can really get away with isolating things that concretely.
Adam: Say a bit about the pros and cons of mobile applications versus responsive UIs.
Luke: Yup. Here where I’m going to interpret mobile application, I’m going to interpret it in two ways. I’ll answer this question twice, depending on how people view mobile app. The first one, I’ll just say, an m-dot experience as we were talking about previously. That is, a website or application on the web designed specifically just for this assumed definition of mobile, which is probably just the smartphone thing, versus a more adaptive responsive UI.
When you compare and contrast those two things, I like to use a travel analogy, which is if you’re going on a trip. Frankly, you don’t know what the weather’s going to be like. You don’t know if it’s going to be really sunny. You don’t know if it’s going to be really cold. You really don’t know. When you pack, you bring stuff that you can be warm in. You bring stuff that is comfortable if it’s hot out.
That’s how responsive designs work. They come with a bunch of stuff that prepares them for any situation. In today’s device ecosystem, that’s usually a very, very good thing.
But if you know specifically where you’re going when you’re traveling — you’re going to the beach; it’s going to be 72 and sunny for a week — you can optimize how you pack and just bring the stuff you need, which is what a mobile-specific website allows you to do.
I think that’s where these separate mobile web experiences still have a bit of an edge over responsive designs. They, by their nature, are just simpler and smaller because they’re only targeting a certain class of device, whereas the responsive designs are by their nature more robust because they’re targeting every single kind of device.
There’s definitely a lot that you can do to make responsive sites more performant and get some of that optimization, but it doesn’t come “for free” like it does with a separate set of templates in-site. That’s going to answer one if we interpret mobile app as something on the web.
If we interpret mobile app as something that’s native to an operating system — that is, a native mobile application not running on the web but running on a particular platform like iOS or Android — then the pros and cons list is a little bit different. The way you then think about the benefits of these native applications is you look at it as richness.
What can I use to create a richer, better experience that comes from that native platform? You’ll be able to get closer to the metal. You’ll be able to use hardware more. Different aspects of the software will be more performant because they’re compiled and running natively.
The benefits of a responsive design, then, instead of richness are really around reach, which means every modern device platform these days comes with a really good browser, a way better browser than we’ve ever had before. So when you build something for the web, you’re building something for every single platform, which gives you way more reach than an application you build only for a single platform.
I think that’s the simplest way I can classify the native-versus-web argument for mobile devices and beyond. It’s about richness, and responsive web designs are all about reach. There are good reasons for doing both. It’s not really a this-versus-that. It’s really understanding your goals and determining what makes the most sense for what you’re trying to accomplish.
Adam: Luke, in a responsive web design, aren’t we giving everyone the same site? How do you account for different use cases on different devices?
Luke: That’s a very good question. The assumption is, since I’m serving the same HTML markups, CSS, and images everywhere, every single device, whether it’s a smartphone, tablet, desktop, or laptop is going to get the exact same website and content.
The counterargument to this often is, “Well, don’t people use desktops and laptops differently? Aren’t smartphones and tablets used in different ways?” The answer is yeah, absolutely. They are used in different ways, but the fundamentals of what makes your site or application valuable to people doesn’t change because the screen size changes.
Let me give an example for this. I was on a panel a while back at this mobile conference. There were a couple folks representing the airline industry. They were making the argument that, “Our mobile experiences are really different. What people do on airline sites on mobile is, they spend a lot of time booking last-minute travel. That is, they book flights that are within 48 hours of departure. We really don’t see that much of that on the desktop.”
My counterargument to this was, “That’s awesome. You have that data and you understand this difference, but what are they doing on the desktop?”
“Well, they’re booking flights.” Fundamentally, they’re booking flights in both places. In mobile, they may be more in a rush, so they may want a more streamlined, more focused, faster flow. You may want to limit options and things like this.
But underneath the surface, the value you’re providing people across all those screens is around booking flights. This is where an adaptive design can actually help, because what you can do in the smaller screen experience is reprioritize and rearrange some of the elements to take into account these different use cases. When you shift up to larger screen size, you can reshuffle that priority and move things around a little bit more.
It doesn’t necessarily mean you have a totally different website. All you’re doing is taking this core use case of booking flights and adjusting it a bit to what makes the most sense on each device, essentially optimizing it through adaptive design for different use cases. I actually think a responsive and an adaptive interface is a benefit in these kinds of differing use cases, as opposed to a con.
One other example, just to drive this home. I know this gets discussed a lot, so it’s worth drilling into a bit.
Another common example of where people cite mobile behavior as different from desktop and laptop behavior is if somebody has a physical location, like a museum. It’s not uncommon for them to see in their logs that people on mobile tend to go to the visiting hours, driving directions, and parking information type pages. There’s a higher mode of use of those sorts of pages and information on mobile then there is on, say, desktop or laptop.
But that doesn’t mean that somebody on a laptop or a tablet doesn’t want to see driving directions or hours. That doesn’t mean that somebody on a smartphone doesn’t want to see pictures of the exhibit or the calendar of events. It just means that the relative priority of content is a little bit different.
What you could do with an adaptive layout is make the “Driving Directions” and “Hours” button big on a small screen view, and then make it a little bit smaller as you adapt your layout to a big screen view. Again, you account for these different priorities of content, but at the same time you’re not excluding any content from anybody just because of their screen size or device type.
Adam: Luke, as the requirements for making sites more adaptive and doing so for more devices and differing devices, will we reach a point where the code and infrastructure needed to support this decreases the site responsiveness to undesirable levels, and quality becomes an issue and usability becomes an issue?
Luke: This goes right back to the analogy I made at the beginning, of packing everything you need because you don’t know what you’ll find on the other end. When you do that, naturally you’re bringing more stuff. The suitcase is heavier. It takes a little bit more effort to lug it through the airport and those kinds of things.
If you pack way too excessively, then you might not even be able to get your suitcase into the airport. Or to really stretch the metaphor, they might not even put it on the plane because it’s too heavy.
When these adaptive and responsive methodologies first came out — I hate to say this almost — it was really around the cool factor of being able to adjust the layout and have a different layout on a different screen size, which is very useful. You can use that to optimize the interaction and visual design of things, but oftentimes it was a net negative for performance.
Over and over again we see, the faster you can make websites and web applications, the better your metrics skew. Reducing 100 milliseconds of load time can lead to more conversion, more revenue, more engagement, more page views, all that good stuff. The very strong concern here is, if I start to do responsive stuff, am I negating all those performance values because I’m bringing on all this additional stuff?
While these responsive methodologies started with these layout examples, the conversation these days and increasingly over the past year is all about performance. How can we make sure that we are in fact delivering the right level of file size, not bringing over unused assets, being judicious about how we load assets, and those sorts of things?
There’s a lot of patterns of things like Ajax-include, which picks which content to load on which screen, defers loading on content, or just more smartly loads content, that are bringing the conversation to making site responsiveness more and more desirable, to use the language of the question.
When you do this sort of methodology, you’ve got to keep your eye on the performance prize. You can’t ignore optimization, speed, download, and all those things that we’ve been focused on a lot on the Web. That doesn’t go away just because you have a responsive design. You may, in fact, have to learn new techniques for getting there. It may be a little daunting, but got to be done.
Adam: Luke, my recollection is that there were a bunch of people who were looking for some advice on media query breakpoints. One in particular, I thought, was a really good one. Do you make those decisions based on content or the devices?
Luke: Just to bring everybody to speed up on what we mean by media query breakpoints. In an adaptive design or responsive design, when do you decide to change your layout? You hit some threshold of screen size.
The way a lot of people used to do this was, they would say, “At 320 pixels, because that’s an iPhone, I’ll have a different layout. At 1024 pixels, because that’s an iPad, I’ll have a different layout.” They made these adjustments based on the current dimensions of popular devices. That’s why I used the iPhone and the iPad as an example there.
But if you go back to the very beginning, when we were talking about how all these different form factors and size of devices are coming out and more and more of them are emerging every single day, that doesn’t really become a long-term sustainable model.
Let’s say the next iPhone is 360 pixels, or the Galaxy Note takes off and it’s 720 pixels. You find yourself in this rat race with the device market of what’s popular and what’s not, trying to tie what your design is doing to a series of manufacturer specifications.
What you can do instead of trying to look at these breakpoints at where the popular device screen sizes are, you can look at them as, “Where does my design actually break?” It doesn’t really matter what screen size it’s on. It’s just, as I’m gradually looking at it on different viewports, when it hits a point where something becomes unreadable, something becomes, how shall I say, overly ugly…
Luke: …I guess, looks wrong. That’s a place where your layout is broken. You can take this term “breakpoint” literally and say, “Look, people can’t read this. It’s broken. This is just ugly. It’s broken.” That’s where I need to insert a breakpoint.
You use those breakpoints as content-driven. Where my layout or my content fails to work, it’s a breakpoint, and I need to make an adjustment to my layout so it works better. I think that’s a lot more future-friendly than sticking to the current landscape of device sizes when you think about this.
Adam: One of our attendees made the point that small windows are different than small screens, and wondered if you make different design choices for those different experiences.
Luke: I think this is actually a real nice question to wrap everything up that we’ve been talking about so far. As we’ve been talking about, small screens and different kinds of screens can actually have different use cases. Adapting our layouts based on those use cases and re-prioritizing and reorganizing information can help address the small-screen problem, if you will.
The adaptive designs and adaptive layouts of responsive web design, as we were just talking about a second ago around basing these off of content, can address the small-windows principle. That is, whatever size window you happen to encounter, you can adapt your layout to it.
I don’t think these two things are mutually exclusive. In fact, I think, together they form a really great methodology for dealing with multiple-device design.
You’re not just looking at screen size. You’re also looking at how people actually use these devices. At the same time, you’re making sure that it works on every single screen size. It’s a win-win on both sides. For that reason, I’m really excited about where this stuff is going and how it can reshape what we’ve been doing on the Web over all these years.
Adam: Very cool. Awesome stuff, Luke. Thanks for coming back to join us for a bit to talk a little bit more about this.
Luke: My pleasure. Hope it has been useful for everyone.
Adam: To our audience, if there’s a need for mobile design resources and information, you would be doing yourselves a great favor by going to Luke’s site, LukeW.com. It’s loaded with Luke’s thinking, lots of great statistics, and all kinds of stuff in this fast-moving, fast-changing environment, so go check that out.
Thanks for listening, and thanks for your support of the UIE Virtual Seminar Program. Goodbye for now.