In his book Mobile Design and Development (O’Reilly, http://oreilly.com/catalog/9780596155452/), Brian Fling tells a difficult truth: “Great mobile products are created, never ported. Start by understanding your users and the benefits the medium has to offer.”

If you’re simply trying to take a site’s usual content and cram it into a 320 x 480 window, stop. Take a big step back and look at the whole picture.

2. Strip the site or app down to its essence

Don’t be afraid to take away all that other stuff—the extra content, eye-catching features, sidebars, pull quotes, ads, images, site maps, social links, and so on. Focus tightly on the few tasks that mobile users will need from your site, use minimal branding, and chuck the rest.

In fact, make sure that even on the home page (for a website) or the first working page of an app, relevant content appears high on the screen. That means getting rid of the “layer cake effect” of logos, ads, tabs, and headers that stack up on the screen. See Figure 10-1 for a poor example; the only piece of content that a user really cares about is the score at the bottom of the screen! (If the user rotated the phone sideways, the score wouldn’t even be visible above the fold.)

Figure 10-1. NBA.com, where the only information the user cares about is at the bottom

Having reduced the site to its minimal form, you should then make sure that a user who really needs the full nonmobile site can get it. Put a link to the full site in an obvious place. Remember that many of the world’s people can get web access only through their phones, so you can’t count on them just going to the full site on their large screen—they may not have one.

Alternatively, you might create the two “separate and parallel” designs mentioned earlier, in which all the site’s functions and information are presented in the mobile site (meaning the user never has to go to the full nonmobile site). You may still need to strip down the home page or main screen. Instead of having a flat and broad navigational hierarchy in which the home page has a zillion links directly to other pages, you may need to reorganize the site so that the hierarchy is somewhat narrower and deeper. This lets you put fewer options on the home page, which means less clutter on a small screen. (Of course, you’ll have to balance that against the time it takes for a user to jump from page to page!)

Here are some mobile versions of home pages that manage to meet most of the design constraints listed in the preceding section, while retaining the branding and personality of each site. Figure 10-2 shows examples of each.

Figure 10-2. Good examples of mobile sites: JetBlue, Ruth’s Chris, Boston.com, and Fidelity

Order the mobile page’s content in a vertical column, with little or no use of side-by-side elements. Let text elements line-wrap, and let the page scroll down past the bottom of most device screens.

Most mobile web pages that must work on devices of different sizes should use this pattern, especially if they contain text-based content and forms. (Immersive content, such as a full-screen video or game, won’t generally use this because it doesn’t usually scroll like a text-based page does.)

When going from one page to another is expensive—as is the case with web pages, which take time to download—this pattern is applicable. On the other hand, an app that resides on the device can go from page to page almost instantly, since the content doesn’t have to be downloaded. For these, it makes more sense to structure the content into single screenfuls so that the user never has to scroll vertically—she can just tap or swipe. But vertical scrolling of a long page is preferable to interminable waits for downloads.

Devices come in different widths. You can’t always anticipate what the actual width in pixels will be, unless you detect the screen width at runtime or build apps for particular devices. (You can create optimized designs for single devices or standard device-specific widths, but not everyone has the resources to do so.)

A fixed-width design that’s too big for the physical device can scroll sideways or be zoomed, but these designs are never as usable as those that let the user simply scroll down.

Font sizes may also change unbeknownst to you, and as in the Liquid Layout pattern, a Vertical Stack with line-wrapped text elements will adjust gracefully when this happens.

Lay out the page’s content in a scrolling vertical column. Put the most important items on top and less important items farther down so that most users can see the important stuff.

Useful content—from the user’s perspective, that is—should show up in the first 100 pixels (or less) of this Vertical Stack. This top part of the screen is precious real estate. Don’t waste it with too-tall logos, ads, or endless toolbars all stacked up into a “layer cake” that pushes all the useful content off the bottom of the page! That annoys users to no end.

Put form labels above their controls, not next to them, to save horizontal space. You will need all the space you can get to show text fields and choice controls with adequate width.

Put buttons side by side only if you’re really sure their total width will never be wider than the visible screen. If the buttons contain long text that might be subject to localization or font enlargements, forget it.

Thumbnail images can fit beside text fairly easily, and it’s common to do this in lists of articles, contacts, books, and so on—see the Thumbnail-and-Text List pattern. Make sure the design degrades well when the screen width is reduced to 128 pixels (or whatever the realistic minimum happens to be when you create your design).

The sites for ESPN, the Washington Post, and REI (Figure 10-4) demonstrate three styles of using a Vertical Stack. ESPN places only the most immediately relevant content on the home page, preferring to put the rest behind menu items on the bottom of the page. The Washington Post puts it all out there; the stack shown in the figure is just a small fragment of the entire page! REI simply shows a menu of all the available places and ways to shop, with no ads or teasers on its home page.

Figure 10-4. Vertical Stacks on the mobile sites for ESPN, the Washington Post, and REI

Arrange top-level pages side by side, and let the user swipe them back and forth to view them one at a time.

You have pages of content that are conceptually parallel, such as the weather in different cities or the scores in different sports. Users won’t mind swiping through these pages, going through several before reaching the one they’re looking for, because they are all potentially interesting.

This pattern can sometimes be a viable alternative to other navigation schemes for mobile apps, such as toolbars, tabs, or full-page menus.

Each item to be displayed can occupy the entire screen; no space needs to be used for tabs or other navigation.

Since the user can’t jump straight to a desired screen—he has to swipe through others to get there—this pattern encourages browsing and serendipity.

Swiping seems to be a very satisfying gesture for some users.

A disadvantage of this pattern is that it doesn’t scale very well; you can’t use too many top-level pages, or users might get irritated at having to swipe too many times to get to a desired page. Another disadvantage is lack of transparency. A new user, just seeing your app for the first time, cannot easily see that swiping is how he gets from one page to another.

Essentially, a Filmstrip is like a Carousel (see Chapter 5) for a mobile application’s main pages. One difference is that a Carousel usually shows metadata—information about the item or page—and context, such as fragments of the previous and next pages. Mobile apps that use Filmstrip as a top-level organizing device don’t generally do that.

If you want to give the user a clue that multiple top-level pages exist, and that he can swipe between them, use a dot indicator like the Weather app uses at the bottom of its screen.

The iPhone’s built-in Weather app (shown in Figure 10-5, at the top of the pattern) uses a Filmstrip to show the weather in the various geographic locations that the user chooses.

Likewise, ESPN’s iPhone app structures its main pages as a Filmstrip. The user swipes back and forth between football, baseball, basketball, and other sports scores (see Figure 10-6).

Figure 10-6. ESPN application

Show tools only in response to a touch or key press, and put them in a small, dynamic overlay atop the content.

You are designing an immersive or full-screen experience, such as videos, photos, games, maps, or books. To manage that experience, the user will sometimes need controls—navigation tools, media player tools, information about the content, and so forth. The tools require significant space, but are only needed sometimes.

The content is allowed to dominate the experience most of the time. The user isn’t distracted by controls taking space and attention away from the content. Remember that in a mobile context, space and attention are even more precious resources than usual.

The user controls the experience by choosing when to show the tools.

Show the unadorned content using the full screen. When the user touches the device’s screen or presses a particular key or softkey, show the tools.

Many apps only show Touch Tools when the user touches a certain region of the screen. This way, the user doesn’t accidentally bring up the tools just by ordinary handling of the device. Also, you can bring up different tools when different regions of the screen are touched—the Stanza book reader does this, for instance. See the example in Figure 10-9.

Show the tools in a small, translucent area that appears to float above the content. The translucency makes the tools look ephemeral (which they are).

Remove the tools after a few seconds of nonuse, or immediately if the user taps the screen outside the bounds of the tools. It can be annoying to wait for the tools to go away by themselves.

The video player on the iPhone shows Touch Tools when the user taps the indicated area of the screen (see Figure 10-8). They go away again after about five seconds of nonuse.

Figure 10-8. YouTube for iPhone Touch Tools

Stanza, one of the many ebook readers on smartphones and other touch screen devices, also uses Touch Tools. Most of the time, the full screen is used to show book text. But when the user taps the center of the screen, extra information and controls appear—book title, author, chapter and page, settings, search, viewing mode, and a menu of yet more tools. To explain this and the page-turning gestures, a first-time reader is shown an explanatory dialog. See Figure 10-9.

Figure 10-9. The Stanza book reader: default page, with Touch Tools, and an explanatory dialog

Place global navigation at the bottom of the page, below the fold.

A mobile website needs to show some global navigation links, but these links represent low-priority paths through the interface for many users.

Your highest priority on the site’s front page is to show fresh, interesting content.

The top of a mobile home page is precious real estate. You should generally put only the two or three most important navigation links there—if any at all—and devote the rest of the front page to content that will interest most users.

A user looking for navigational links can easily scroll to the bottom of a page, even when those links are far below the fold.

Create a set of vertically arranged menu items on the bottom of the page. Make them easy to tap with a finger on touch screens—stretch them across the full width of the mobile page, and make the text large and readable.

This pattern is closely related to the Sitemap Footer pattern in Chapter 3. In a mobile application, you probably aren’t trying to fit an entire site map into the footer—you only have room for a few well-chosen links. But the idea is similar: instead of taking up too much top-of-page space for navigation, you can push it to the bottom of the page, where real estate is less valuable.

NPR puts an extensive footer across the bottom of each of its pages (see Figure 10-11). It includes standard navigational links, a search box, the full-size site, a link to download an app, and a font size control.

Amazon uses a simpler, shorter Bottom Navigation system. See the screenshot in Figure 10-10 at the top of the pattern.

In contrast, Google uses a more web-like footer on many of its mobile properties (see Figure 10-12). These links are smaller and look more like the brand, but they are far harder to hit with clumsy fingertips.

Figure 10-11. NPR’s Bottom Navigation

Figure 10-12. Google Images footer

Present a selectable list of items, with each item containing a thumbnail image, some text, and possibly smaller text as well. If appropriate, use bold colors, icons, and other visual differentiators.

You need to show lists of articles, blog entries, videos, applications, or other complex content. Many or all of these have associated images. You want to invite the user to click on these items and view them.

Thumbnail images improve text-only lists because they look appealing, help identify items, and establish a generous height for the list items.

Reading conditions on mobile devices are rarely ideal. By adding colorful images, you can improve the visual differentiation among items, which helps people scan and parse the list quickly.

Many news and blog websites have converged on this design pattern as a way to show links to their articles. They look more appealing, and more “finished,” than similar sites that only list article titles or text fragments.

Place a thumbnail image next to the text of the item. Most sites and apps put the thumbnail on the left.

In addition to picture thumbnails, you can include other visual markers, such as five-star ratings or icons representing people’s social presence.

Don’t be afraid to use bright or saturated colors. You probably wouldn’t design so much visual stimulation in a desktop context, but in a mobile context, it works. Even if the colors seem garish, don’t worry—small screens can handle strong colors better than large screens can!

Many news sites use this pattern to show their articles. Yahoo! News and Boston.com offer good examples. Special-interest journalism sites such as Mashable also use Thumbnail-and-Text List effectively for their feature articles. See Figure 10-14.

Figure 10-14. Yahoo! News, Boston.com, and Mashable

Videos and other media fit this pattern naturally. As shown in Figure 10-15, YouTube, IMDb, and Kobo show thumbnails representing their videos, movies, and books. Note the rating stars on the YouTube and Kobo listings (and on the iPhone app store, in Figure 10-13 at the top of the pattern). These help a user scan down a list and pick out items with more stars.

IMDb also shows user ratings, but it eschews stars in favor of plain text, and it doesn’t draw the eye—it just blends in with the rest of the text. Note also that the subdued and tasteful colors of the Kobo book reader look beautiful, but don’t help differentiate items as strongly as the bolder colors used by YouTube or the app store.

Figure 10-15. YouTube, IMDb, and Kobo apps

Finally, many apps show Thumbnail-and-Text List of other, diverse kinds of items: birds (from iBird Explorer), products (the Google iPhone app), and menu items in a complex information architecture (Buzz Aldrin’s Portal to Science and Space Exploration); see Figure 10-16.

Figure 10-16. iBird, Google, and Buzz Aldrin

At the bottom of a long list, put a button that loads and appends more items to the list.

You need to show long lists of email messages, search results, an archive of articles or blog posts, or anything else that is effectively “bottomless.”

Users are likely to find desired items near the top, but they sometimes need to search further.

The initial loading of a screenful or two of items is fast, and the user doesn’t get stuck waiting for a very long initial page load before she sees anything useful.

Each subsequent loading of a new chunk of items is also fast, and it’s under user control—the user decides when (and whether) she needs to load more items.

Since the new items are just appended to the current page, the user never has to context-shift by going to a new page to see new items, as she would with paginated search results.

When the page or list is initially sent to the mobile device, truncate the list at a reasonable length. That length will vary greatly with item size, download time, and the user’s goal—is she reading everything (as with Facebook), or just scanning a large number of items to find the one she wants (as with search results)?

At the bottom of the scrolled page, put a button that lets the user load and show more items. Let the user know how many more will be loaded.

Alternatively, you could use no button at all. After the user has loaded and can view the first chunk of items, silently start loading the next chunk. Append them to the visible list when they’re ready, and the user has scrolled down to the end of the original list. (This is your clue that the user may want to see more. If the user doesn’t scroll down, don’t bother getting more items.)

In software engineering, this well-known approach to managing lists of undefined length is often called lazy loading.

Several iPhone applications use Infinite List, including Mail (Figure 10-17), as well as iTunes and third-party apps such as Facebook (Figure 10-18). The iTunes button only loads 10 more items, which seems like too small a number for an eager music listener, but the Mail app loads many screenfuls of new messages; it seems to balance download time and quantity fairly well. The Facebook app, like the full-size Facebook page, loads up the first several pages of updates and then lets the user load more.

Figure 10-18. Facebook and iTunes

You can also do this with a web page. Gmail Buzz loads a few screenfuls of updates and then offers a “Load more” button; so does Mashable (see Figure 10-19).

Figure 10-19. Buzz and Mashable

On devices with touch screens, put large margins and whitespace around buttons, links, and any other tappable control.

You need to use buttons with text labels, or a list of items, or ordinary text-based links—in short, any touch target that isn’t already large on the screen.

Touch targets must be large enough for clumsy fingers to hit successfully. In particular, they need to be tall enough, which is challenging for buttons and links that consist only of text.

Surround each touch target with enough inner margin, border, and surrounding whitespace to make a sufficiently large hit target for fingertips.

One trick is to make the whitespace immediately surrounding a target tappable. The button will look the same size, thus fitting into your visual design as expected, but you gain a few pixels of sensitivity in each direction around the button. Dan Saffer, in Designing Gestural Interfaces, uses the term iceberg tips for controls such as these—they are bigger than they appear.

Exactly how big to make these targets is a very good question. Ideally, you want a size that ends up large enough on the physical device to be manipulated by most people—many of whom will have large fingers. Some others will not have great control over their fingertips. Yet others will be using their mobile devices in challenging conditions: bad light, moving vehicles, little attention to spare.

So ultimately, how big should you make your targets? It depends on whom you ask. There’s no consensus on minimum target size, but different references make these claims:

And there’s more. See Luke Wroblewski’s discussion at http://www.lukew.com/ff/entry.asp?1085 for even more information.

The IMDb application for the iPhone reliably puts plenty of margin space around its touch targets. The whole application has a relaxed, uncramped feeling, as shown in Figure 10-21.

Figure 10-21. Screens from the IMDb app

The Epicurious app is similar, though its visual styling is quite different. The buttons for key actions—“find a recipe,” “view recipe”—are quite large and distinctive, as shown in Figure 10-22.

Figure 10-22. Screens from the Epicurious app

Clear a text field with one button press.

Whenever a text field is needed in the mobile interface, consider using a Text Clear Button. It is especially valuable for fields that hold long strings of text, such as search strings, URLs, and multiline text.

Erasing long strings of text letter by letter is slow and error-prone. Don’t force your users to do this.

Some mobile platforms have no facility for cut, copy, and paste. A cut operation may suffice for erasing text—so would the selection of all of a text field’s contents—but even if those exist it’s easier just to tap a single target to erase the field.

Put a simple “X” or “Clear” button into the text field. A button beside the text field can also work, though you’d want to usability-test it to find out whether users see it or not—they may see it as a “Go” or “Search” button instead.

If the platform offers a “Clear” button as a built-in feature for text fields, use it. I have watched users struggle to clear text fields when this feature was not provided, on early versions of Android—it’s painful to watch people erase a long search field letter by letter by letter. I’ve also watched people use iPhone apps that didn’t use its standard clear button; these users had a strong expectation that the “X” button would appear in text fields, and were unhappy when it wasn’t provided.

There aren’t many varied examples of this pattern to show as of this writing. Figure 10-24 shows the websites of two large search engines that insert a Text Clear Button into their search fields.

Figure 10-24. Clear buttons as used by Google and Bing

While a page or page section is loading, show a progress indicator in the place where it will be (or where the user tapped or clicked).

The user has to wait for content to load, especially in a page that changes dynamically in response to user interaction.

Loading new content can be slow and erratic over mobile connections.

You should always show as much of a partially loaded page as you can, so the user can actually see something useful.

In general, progress indicators make loading times appear faster to a user. She is reassured that something is actually happening in response to a gesture, especially when that indicator appears where the gesture occurred.

Show as much of the page as can be loaded quickly, but if part of it takes a long time, such as a graphic or video, show a lightweight animated progress indicator where the graphic will appear. (The mobile platform may supply a default indicator.)

When the user initiates an action that causes part of the page to be reloaded—or loads a whole new page—show a progress indicator in situ on the page.

Flickr’s mobile website uses loading indicators very skillfully. When the user taps a picture thumbnail to see the whole picture, the thumbnail is overlaid by a Flickr logo that moves until the new image is ready to show (see Figure 10-26).

Figure 10-26. Flickr’s animated loading indicator

When an iPhone installs a new app, the app’s icon literally shows a miniature progress bar to show how far it’s gotten with the download (see Figure 10-27). It’s cute, and its meaning is unmistakable.

Figure 10-27. iPhone’s app installation progress bar

Inside your mobile app put direct links to other apps, such as the phone dialer, map, or browser. “Prefill” them with data from the user’s current context.

The mobile app shows data that is “connectable” in obvious ways, such as phone numbers and hyperlinks.

More subtly, your app may offer ways to capture images (via the device camera), sound, or video. It may even be aware of social networking conventions, such as Facebook or Twitter usernames. In all cases, your app might direct the user to another app to perform these device-based functions.

A user can only see one mobile app at a time, even when multiple apps are being used at once, and it’s annoying to switch between them by hand.

Mobile devices often have enough context and available functionality to offer intelligent paths between apps.

As of this writing, mobile devices have no good way to arbitrarily shuffle small amounts of information from one application to another. On the desktop, you can type easily, or use copy and paste, or even use the filesystem. You don’t have those options on a mobile platform. So, you need to support moving that data automatically.

In your app, keep track of data that might be closely associated with other apps or services. When the user taps or selects that data, or uses special affordances that you provide, open another app and handle the data there.

Here are some examples. Consider all the ways that data in your app can connect directly to other mobile functions.

In addition, you might be able to do such things as take a picture, or use a map, entirely within the context of your application.

You can do some of this on a desktop, but the walled-garden nature of many mobile devices makes it easier to launch the “right” app for certain kinds of data. You don’t have to decide which email reader to use, or which address or contact management system, and so on. Plus, many mobile devices supply a phone dialer, a camera, and geographic location services.

The Freedom Trail application for the iPhone, shown in Figure 10-28, explicitly illustrates its links to other apps. The user chooses whether to follow them for more information, or just to stay within the app; this transparency is useful and refreshing.

The Facebook app for iPhone connects to the camera on the device (see Figure 10-29). The integration is close; users can take a picture and immediately post it to Facebook, without ever seeming to leave the Facebook app. Facebook can also reach the preexisting photos on the iPhone.

Figure 10-29. Facebook’s integration with the camera

The iPhone’s map application (Figure 10-30) connects to the contacts app to add a person’s address to her contact info, and to email and MMS for sharing a location. (Of course, many other applications, both mobile and otherwise, also have “Email this” or “Share this” features. See the Sharing Widget pattern in Chapter 9, for example.)

Figure 10-30. The iPhone map application connecting to contacts, mail, and MMS

Use your organization’s logo, colors, and other brand elements on the mobile site or app, but keep them small on the screen and fast to load.

All mobile apps or sites that are associated with a company or organization should use this.

Users need to be able to identify your app or site as yours. In usability testing, people respond well to reliable, familiar branding, especially when the brand is already known outside of the mobile context.

Mobile screens don’t have much space to spare for elements that aren’t actual content.

Mobile network connections can be slow, and heavyweight images don’t download fast enough.

Create a small version of your logo, no taller than around 50 pixels, so that it takes up as little vertical space as you can get away with. If you’re creating different designs for different screen sizes or platforms, consider making different versions of the logo for each.

Apply your brand’s colors and font families in the mobile design. A basic text interface may function well enough, but it won’t look professional or polished.

Avoid using very large and complex images as stylistic elements. Download time is as important in a mobile context as on the desktop (and often more so). If you’re working in HTML, depend on stylesheets when you can, rather than handcrafted images.

Strong contrast and large, readable text will help people use your mobile site when the conditions are poor (bright light, motion, distraction). Even if your brand calls for visual subtlety and small, tasteful text, do what needs to be done for the sake of usability—adapt the brand look to the platform.

There are good examples of this pattern all over the mobile web. Going back to the first example given in this chapter, JetBlue pares down its branding to a look that is polished and recognizable, but works well on even a tiny mobile device (see Figure 10-32).

Figure 10-32. JetBlue’s mobile branding

Fandango’s mobile site also takes a minimalist approach (see Figure 10-33). Like JetBlue, Fandango uses a polished-looking logo and style, but the site loads fast and can be used on tiny screens. None of the bandwidth-hogging images, ads, or video is loaded onto the mobile device.

Figure 10-33. Fandango’s mobile branding

Whole Foods maintains a very consistent brand look across its full-page and mobile sites. But its mobile site consumes more above-the-fold space than necessary with top navigation, and it downloads several large images, making it slower than it could be (see Figure 10-34).

Figure 10-34. Whole Foods’ mobile branding

Chipotle’s mobile website shows how not to do mobile branding (see Figure 10-35). The brand is strong enough on the main site, but none of it shows up on the mobile site except for a too-small version of the logo! The site uses only a neutral font and colors. (To be fair, the site does supply an iPhone app that has stronger branding, but it’s not likely that a very occasional customer will bother with the hassle of downloading it if the website fills her needs.)

Figure 10-35. Chipotle’s mobile branding (or lack thereof)