Appropriate adaptations of how we think about organization, actions, and input on the desktop take what we know about web design and make it usable on mobile. But how do we ensure it’s also usable across the wide range of mobile devices available now and in the coming months—not to mention years?
During the time I’ve been thinking about and writing this book, the mobile industry has changed dramatically several times. Mobile platform leaders have been unseated. Devices with new capabilities and constraints have been released. New partnerships between device manufacturers, mobile platform vendors, and network carriers have been announced.
Welcome to mobile where the only thing you can count on is change. Because things are currently in a continuous state of flux, I’ve focused this book on design principles for mobile device trends that have been holding steady for quite a while: more powerful processors, faster networks, touch-screen interfaces, and better web browsers. Despite my best attempts to give you mobile design principles that will endure, change is coming.
So what’s a web designer to do—get swept up in a sea of constant instability? Quite the opposite. Because things continue to be so Wild West out there, you need to be a cowboy. Take risks, try new things, and accept that not all the boundary lines between devices, browsers, and the web have been drawn yet.
With that in mind, let’s saddle up and talk about how to round up the diversity of devices out there with mobile layout skills. (And I promise that’s it for the Old West analogy.)
Perhaps the most important thing we can do to create effective mobile layouts is to let mobile web browsers know we’ve taken the time to design for them. While I promised not to get into code, knowing about the meta viewport tag is really useful for designing mobile web experiences.
<meta name="viewport" content="width=device-width">
To quote Peter-Paul Koch, who has written about viewports and mobile development extensively:
Normally the layout viewport takes a width that the vendor has decided is optimal for viewing desktop sites. By setting the meta viewport to device-width you’re sure that your site’s width is optimized for the device it’s being viewed on.
Viewports can also help manage differences in pixel density. Pixel density (or ppi) measures the resolution of a screen by looking at the total number of pixels available horizontally and vertically within specific physical dimensions. Apple’s original iPhone had 320×480 pixels available on a 3.5in screen, which meant it had a pixel density of 164ppi. The Google Nexus One had 480×800 pixels available on a 3.7in screen, which meant it had 252ppi. Why does this make a difference?
Pixel density impacts how physically big or small elements appear on a screen. A higher pixel density means each pixel is physically smaller. Consider a set of buttons viewed on an Apple Cinema Display, which has a ppi common to many desktop computers of about 94ppi. View the same pixels on a Nokia N900, which has a pixel density of 266ppi, and you can clearly see the difference. What was large and legible is now tiny and invisible (fig 7.1).
Fig 7.1: A big difference in pixels per inch (ppi) can adjust the visual size of images dramatically. Above, Apple Cinema Display (94ppi); below Nokia N900 (266ppi).
When you design for devices with different pixel densities, these differences can become a problem. On the web, however, the viewport width that mobile browsers use can help us manage this issue. As Peter-Paul Koch pointed out, Apple’s first set of iPhones (164ppi), Google’s Nexus One (252ppi), and the iPhone 4 (329ppi) all used the same device-width of 320 pixels.
This provides some much needed layout consistency across the various pixel density devices out there. Where we still need to do some work, though, is with high-resolution images. Unlike browser-rendered controls, text, and visual elements, image files won’t automatically adjust to higher pixel density screens. They’ll render at the correct size but lack crispness and definition when pixel density is high (fig 7.2).
Fig 7.2: When ppi is doubled, the edges of Yahoo!’s logo image appear jagged and blurry.
To account for this, you’ll need two sets of images: one large (twice the resolution) and one at standard resolution. You can then tell web browsers (using CSS3 media queries, JavaScript, or a server-side script) to only include the higher resolution graphics on devices with a high-resolution display.
If you’re not interested in maintaining two sets of images (and who would be?), lean more heavily on CSS for your mobile web experience’s visual design. The gradients and rounded corners in Yahoo!’s design (fig 7.2) are rendered using CSS3 and look great on both high and low resolution screens, saving you the need to manage multiple images and your customers the need to download them.
Mobile browsers that don’t support CSS3 properties like gradient and rounded corners can simply default to a solid background and square corners. No harm done.
Be aware though that too many CSS3 effects could diminish performance, as excessive shadows and gradients can slow down rendering on some devices. This is being addressed with faster rendering engines so it probably won’t be much of an issue soon. But you’ve been warned nonetheless!
Despite the fact that some mobile devices with different pixel densities will use common viewport widths, we can’t count on a single width for our mobile web experiences. For starters, even if every mobile device used 320 pixels for its device-width, we’d still have different widths when one of these devices changed its orientation.
To cope with this and whatever new device widths may come our way, we need to be highly elastic in our layouts. Whether you call them fluid, liquid, or flexible, designs that expand and contract based on available screen space are a must. In a fluid layout, interface elements (like the search box and menu items in the Google Places, fig 7.3) are designed to adapt to the space available to them.
Fig 7.3: The Google Places mobile web experience uses a fluid layout to adapt to various screen widths.
While fluid layouts are essential, they’re really just the start.
When the differences between screen sizes grow, flexible layouts can be stretched to their limits. Consider the layout possibilities on a 768 pixel device-width versus a 320 pixel device-width. Surely we can do more than just stretch the interface to fit? After all, a 768px device-width has two-and-a-half times more space! Enter responsive web design.
Through the application of fluid layouts, flexible media, CSS3 media queries, and (sometimes) a bit of JavaScript, responsive web design allows you to adapt to devices more significantly. With responsive web design, you can set a baseline (mobile) experience first, then progressively enhance or adapt your layout as device capabilities change.
This is accomplished by setting resolution “break points” and applying a different set of layout rules and media assets to each. A break point can be thought of as a conditional statement that determines if a device meets specific criteria like a minimum width of 600 pixels. If that condition is true, then the browser applies a different set of layout rules, usually through CSS, though sometimes with a little JavaScript as well. (You can get all the details in Ethan Marcotte’s awesome book on the subject.)
These layout rules can include repositioning elements, increasing image sizes, or removing elements altogether. They don’t have to be dramatic, but they don’t have to be subtle either (fig 7.4). As a different resolution break point is passed, the layout adapts to make the best use of the space available to it.
So a single web page can adapt to a large variety of screen sizes using responsive web design. But screen size isn’t the only difference between devices.
Fig 7.4: Responsive web design in action on the 3200 Tigres and Yiibu sites.
Devices are different not just because they have different technical capabilities and limitations, but because people use them differently as well. Consider the differences between connected TVs, desktops/laptops, tablets, smartphones, and feature phones. Each of these device experiences has a unique:
The combination of these differences is often significant enough to “define” a device experience. And different device experiences may require different user interface design solutions. The relative importance of primary tasks can differ between device experiences (because of user posture), as can the layout and interaction design needed to accommodate different input modes and average display sizes.
As a result, many web applications take the time to design and develop unique solutions for distinct device experiences. For example, the movie streaming service Netflix has distinct HTML5 solutions for connected TVs, tablets, desktop web browsers, and mobile devices (fig 7.5). While this requires them to maintain a number of different interfaces, each of these interfaces is optimized for the user posture, input method, and average display size of a distinct device class.
Fig 7.5: Though the Netflix experiences on the Playstation3, iPhone, and iPad are built using the same web technologies, the user interface is designed for each unique device experience.
While it’s possible to have a single user interface work across more than one device experience, developing a single interface that works across all device experiences may result in compromises or bare-bones features that don’t take advantage of what makes each device experience excel (or, conversely, in rich solutions that fail to work on lower-end devices).
So while a connected TV could browse a text list optimized for feature phones, it is unlikely anyone would want to use it that way. On the other hand, a tablet-optimized web application might feel simpler to use on a desktop web browser because the number of actions has been reduced to work on a smaller display size, and the size of the actions has been increased to accommodate touch interactions. While this interface wouldn’t be optimized for a desktop computer’s user posture, input methods, or display sizes, it would still be really functional.
Device experiences can also be useful for thinking through how each break point in a responsive web design solution should not only look but act as well. Layout and media assets can be adjusted to make the best use of available screen space and to optimize for specific input capabilities (such as appropriately sized touch targets).
The right combination of device experience-specific designs, responsive web design, and fluid interfaces can ensure your mobile web experiences work on today’s mobile devices and beyond.
But there’s still one more thing.
Just in case it hasn’t been made abundantly clear in this book, I want to remind you that reduction is the best layout approach available to you on mobile. Appropriately sized touch targets need room to respond to our imprecise fingers. Responsive web designs need to adapt to a variety of screen sizes and resolutions. Distinct device experience solutions need to be maintained as content and features change and grow.
All of these factors push us toward less on our screens—fewer variations to manage and fewer options for people to consider and select without making errors. Across all your mobile layouts, aim for the minimum amount necessary to help people meet their needs whether they’re looking up or finding information, exploring and playing, checking in on important updates, or editing and creating content.
Not only will reduction make putting mobile layouts together easier, it will also give people focused ways to get things done. If you start to hear customers asking for your desktop web experience to be more like the simple, easy-to-use mobile one—you’re doing it right.
As the mobile landscape continues to change, we have to be ready with layouts that adapt to the task at hand—from big differences between device experiences to filling in the small gaps between device screen sizes and orientations.
Though we’ve covered a number of techniques for managing our layouts across an ever-increasing number of devices, there’s more to come. As mobile continues to grow and the definition of what a “mobile” device is continues to blur, expect new techniques for managing layout to emerge. In other words, watch this space.