Chapter 1: Mobile Design Patterns

By Greg Nudelman & Rian van der Merwe

Ever since architect Christopher Alexander discovered in 1977 that a similar design solution could be applied over and over to different challenges, people have been using patterns to guide their thinking to success. Our minds naturally tend to think in patterns as we apply mental models that enable us to reason and navigate efficiently within the overwhelming complexity of the world around us. Patterns and pattern recognition are the key to learning and to the survival of our species.

Unfortunately for us, while patterns are a handy tool, as Alfred Korzybski so eloquently quipped, “The map is not the territory.” You can’t climb those little triangles that represent mountains, nor swim in those little blue kidney-shaped pools representing lakes. The entire process of creating and recognizing patterns in the mind involves filtering, distorting and deleting massive amounts of sensory and thought-based input. For example, in order to recognize that an object in front of us is a door pattern, we have to omit much of the input about the color and texture and generalize greatly about the shape and function. This kind of unconscious pattern recognition is extremely useful to us—it’s why we don’t have to spend an hour trying to understand what a door is (and how to go through it) every time we see one.

Mobile design patterns work in the same way, enabling us to recognize a standard solution to a common problem. However, what makes mobile design patterns unique and difficult to apply are both their novelty and their specificity. Mobile patterns are novel because, despite hundreds of thousands of iPhone apps being in Apple’s App Store alone, they are still very new, and the platform is still maturing. Far from there being “standardized” ways to approach interaction elements, such as navigation and check-out, multiple valid solutions usually exist. This makes choosing and applying “standard” design patterns difficult.

Mobile patterns are also very specific. For example, a “standard” pattern that works well on the small screens of handheld phones—such as iOS’ black menu bar across the bottom of the screen—makes for a poor design choice and a subpar experience for most iPad apps because of the device’s ergonomics.

Larger tablets such as the iPad are usually held with a hand on each side, while the bottom of the screen rests against the table, thighs or abdomen of the owner, making access to the black tab bar on the bottom quite awkward. And let’s not forget that most Android apps do not have a bottom menu bar at all, substituting it with a standard menu button that is part of the Android hardware set. Or at least that was the case prior to the new Android 4.0 release (Ice Cream Sandwich), which made the bottom menu optional and, in some instances, even moved it to the action bar at the top, as shown in the Google+ app for Android 4.0 above.

FIGURE 1.1. Menu button in the top app bar in Google+ for Android 4.0.

So, should we give up trying to identify mobile design patterns? Not at all. There is tremendous value in cataloging approaches that work. The key is not to get caught up in copying the exact implementations, but instead to observe the underlying reasons for why something works, and then implement a unique design solution with authenticity, grace and vision.

Thus, rather than listing every single mobile design pattern out there (which would be far beyond the scope of a short survey chapter like this one), we’ve attempted to collect more strategic patterns that reflect the underlying customer experience trends that are unique to the mobile environment, and then show examples of particular implementations that call out important established or emerging trends. The patterns in this chapter are organized into three general buckets known as finding, input and engagement:

Finding

•Faceted refinement and sorting options

•Parallel search architecture

•Zero results recovery

Input

•Designs that dissolve in behavior

•Tap-ahead

•Virtual assistant

Engagement

•Immersive experiences

•Tabbed views

•Reading and pagination

Incidentally, these are the exact mobile strategies that many people often have trouble both understanding and applying. Once the underlying rationale behind a pattern becomes clear, the delightful details of its exact implementation fall into place beautifully. So, without further ado, let’s dig in.

Finding

Search is a fundamental activity on the Web, even more so on mobile devices. Despite all the ways we are starting to use our phones and tablets to write, draw and create, mobile devices are still primarily used for searching and consuming information. The problem is that we have to deal with a veritable tsunami of information that can now be accessed through a mobile phone, all on a tiny screen that is easily overwhelmed. Two of the patterns in this section will help throttle all of this data to a more manageable flow and make consumption on small screens more comfortable.

The faceted refinement and sorting options pattern provides essential tools for conveniently managing the amount and type of information displayed on a screen. The parallel architecture pattern helps to create a simple view for quick, easy and local access, complemented by a full set of powerful tools that are conveniently available to power users. Last but not least, we finish the section off with the zero results pattern, which helps users recover from the mistypes that are inevitable on small mobile devices.

Pattern: Faceted Refinement and Sorting Options

The faceted refinement and sorting options design pattern provides essential tools for conveniently managing the amount and type of information displayed on a screen. To implement effectively, we must make creative use of the screen’s tiny real estate and avoid the temptation to dumb the tools down, as the following examples demonstrate.

Although refinement is an essential design strategy pattern, implementations sometimes differ one from another to a surprising degree. For example, Amazon offers very basic refinements, while eBay offers as much as—if not more than—can be found on its rich "desktop Web" faceted search interface.

The Battle for Refinement: Amazon vs. eBay

Whenever there is an option to filter and sort search results on mobile devices or tablets, there is a great temptation to dumb down the interface to only one or two options, providing a fundamentally crippled search experience that does not support the natural flow of step-wise refinement. This is a mistake. In this example, we will compare Amazon and eBay’s iOS mobile apps.

Although a successful app overall, Amazon provides a dumbed-down filtering process, which breaks down quickly for more complex queries. The iPhone app provides only two refinement options, “Amazon Prime” and “Department”:

FIGURE 1.2. Refinement options on Amazon for iPhone.

Compare this to the multitude of filters and sorting options available for the same “Nike shoes” query on the desktop:

FIGURE 1.3. Refinement options for the same query on Amazon.com.

Amazon’s mobile app is highly limited in refinement options and does not provide a single sorting option. But the real UX problem is deeper still. A typical search flow involves multiple steps of refinement and changes, with each step directly influencing what the user will do next. Because the search refinement is designed to be only a single-step operation, the interface does not support any changes to the original keyword query. In fact, any change to the query will reset the entire search:

FIGURE 1.4. Multiple searches on Amazon for iPhone.

In the sequence of steps pictured above, the searcher starts broadly, with the keyword “Nike.” Seeing only shoes, they realize that they want to view not shoes, but rather a selection of Nike clothes, so they filter by the only available option: “Clothing & Accessories.” Viewing the items in the search results, the searcher realizes that they wanted to see a specific “Nike Jordan” line of clothes, so they hit “Search” in the menu bar again, updating the keyword query to include the full query “Nike Jordan.” At this point, the searcher unexpectedly finds their category reset back to “All Departments,” so the Nike shoes once again dominate the search results. Their refinements are gone, and their finding flow interrupted.

The best mobile interfaces support multi-step refinements, allowing the users to do more, not less, than the desktop interface. For example, eBay’s mobile app does a great job of this, providing a full array of refinement options.

FIGURE 1.5. Refinement options on eBay for iPhone.

Despite the apparent complexity, this remains one of the most useful and profitable mobile apps, with several billion mobile e-commerce dollars generated as of this writing.¹ One reason for its success is that the designers refused to dumb down the experience, and instead have done an excellent job of managing complexity by providing a full-featured search experience on a tiny mobile device. They did this by using a drill-down model of refinement when necessary, with the first “Refine” screen providing a variety of facets that can be refined, while the second screen provides the actual facet values.

But eBay on mobile not only offers full-featured refinements; it does more than the desktop website. For example, it offers refinement by distance from the current location without having to enter a ZIP code, by using the phone’s built-in GPS sensor.

Another thing to note about the eBay app is that sorting and filtering go together on the same screen. Let’s drill into this implementation more in our next example.

Sorting and Filtering Go Together: Yelp

For many designers, sorting is different from filtering and needs to be housed in a separate area. We disagree. Most users understand the difference between searching and filtering dimly, if at all. Thus, separating the two makes no sense to the consumer. In fact, sorting often turns out to be a more effective refinement option because it never produces a zero results condition (which we’ll talk about later in the chapter).

As we saw earlier, eBay provides sorting on the same screen as the filtering. This is a preferred implementation of the faceted refinement and sorting options pattern. However, this often requires a fairly complex multi-step refinement, which yanks the searcher out of the flow of looking at the search results and puts them fully into a different task: refinement. Is there another implementation of the refinement pattern that offers full-featured refinement and sorting options, while also keeping the user in the context of the search results?

The answer is, it depends—mostly, it turns out, on the size of the screen. Contrast the implementation of the refinement screen for Yelp’s mobile app on the larger Android Nexus 4.0 screen with that of Yelp’s iPhone app:

FIGURE 1.6. Yelp for Android Nexus and iPhone.

The iPhone, with its mid-range screen, is forced to move the refinement to a separate page, much like Amazon and eBay in the example above. However, Nexus, with its slightly larger screen and more compact checkboxes (the on/off buttons), has enough space to accomplish both sorting and filter refinement on a single lightbox layer.

Why this distinction between lightboxes and dedicated pages? The reason has to do with maintaining the flow of the current task.

As we will discuss in greater detail later in this chapter, immersive UIs such as the lightbox maintain the illusion of staying on the same page and on the same task, whereas separate pages appear to switch the task from interacting with the content to refining. Separate pages move the person out of the search results and place them in a different environment. If you are able to accomplish your refinement tasks using a lightbox and without sacrificing functionality, it will almost always create a better experience and a superior implementation of this pattern.

While we’re on the subject of refinement patterns, in appropriate situations, using dynamic search can save users time—by refining search results as users type their query on an active results page. This is impractical for large data sets, but for a constrained set of results, the pattern works really well, as evidenced by applications like Notational Velocity.²

FIGURE 1.7. Example: smashed.by/notational

We have access to so much content, and we are producing exponentially more of it every day. According to Google’s chairman, Eric Schmidt, every two days in 2010 we created as much information as we did in the entire time from the dawn of civilization up until 2003.³ Finding the needle you need in this vast haystack of information on a small screen can be challenging. Users need powerful tools to help them find what they want quickly, which makes faceted refinement and sorting essential to any mobile search task, such as e-commerce and social and geocentric searches.

Pattern: Parallel Search Architecture

“Simplicity is the opposite of simple-mindedness,” said Edward Tufte. On mobile, users often need a simple, basic search option that shows only local or new results, without requiring a lot of additional user input, while also making full-featured keyword search and refinement available. This need is elegantly addressed by the parallel search architecture pattern, which allows seamless and graceful access to both searching modes.

For example, a user might want to quickly find a local gas station while driving. Little input is needed for this beyond the category and location. If the car is about to run out of gas, then the searcher would care little about the price of gas or the oil company whose logo is stamped on the side of the awning. They need gas, and they need it now.

Contrast this task with that of finding a romantic restaurant to meet a significant other. The searcher might carefully select the location, cuisine, price range, parking options and so on, and take the time to look at the ratings and read at least a few reviews. However, regardless of the task, there is little reason to display both sets of results any differently. A single well-designed set of search results and refinement options should work well in both cases. The difference is only in how the searcher gets to those results: through full-featured search or through a simpler browsing process. This “dual-access” mode of search is a common challenge on mobile devices, and the parallel search architecture pattern offers an excellent solution for it.

One of the best implementations of it is ThirstyPocket’s iPhone app. The app’s search functionality consists of basic search and advanced search (labeled “More search options” in the picture below). You can see how easy it is to provide multiple levels of engagement.

From the basic search (the home screen), the searcher has several virtually effortless engagement options:

•Browse an item for sale in their neighborhood by clicking the “Nearest” button (sorted by nearest first);

•Browse newest items within a radius of 20 miles using the “Newest” button (sorted by newest first);

•Browse items by category (sorted by nearest first or newest first, depending on which search button is pushed after selecting a category);

•Combine category and keyword search (sorted by nearest first or newest first, depending on which button is pushed).

FIGURE 1.8. Parallel search on ThirstyPocket for iPhone.

By contrast, using the “More search options” button, the user can navigate to the advanced search screen, where they can engage with a dedicated page that has a variety of powerful filters, such as price, distance and searching in another geographic location based on ZIP code.

Another thing to note in this design is the addition of a clickable semi-transparent bar above the search results. The app bar includes a filter strip that reports the query and all of the refinements being applied to the search results.

Last but not least, the single back button takes the searcher back to the screen where they started. For basic searches, the back button navigates to the home page; for advanced searches with more search criteria, the back button navigates to the “More search options” screen. Although the parallel architecture pattern seems fairly straightforward, it is easy to get wrong, as the following example demonstrates.

Too Many Ways to Engage: TripAdvisor’s Android App

Parallel search architecture could create confusion if the designer tries to add yet another “search from menu” box to an application that already has basic and advanced search, which would create a completely different UI to view and refine the same data. This would be a big mistake.

One unfortunate victim of this antipattern is TripAdvisor’s app. As you can see from the screenshots below, there appears to be multiple ways to access and refine what is essentially the same content, making a simple task such as finding a local hotel unnecessarily difficult.

FIGURE 1.9. Multiple search patterns on TripAdvisor for Android.

Tapping the “Hotels” icon on the home screen takes the user to what would appear to be a basic search screen of the parallel search architecture pattern. However, the default is not local searching, as one would expect, but instead the “best matches.” To activate a local search, the searcher needs to tap the tiny checkbox, which is hard to find while navigating and is awkwardly placed.

The second way to access the same content is from the app bar’s search box—again, not a local search, which makes even the simplest query initiated from the search box, like “hotel,” fairly useless. The filter pop-up box is of no help whatsoever, offering only a few confusing options. Also unexpectedly missing on the search results page are the three tabs that can be found on top of the other set of search results. Instead, the tabs appear as options in the filter pop-up box, although they are named differently (“Restaurants” rather than “Eat.” “Things to do” rather than “See,” etc.), and the icons are different from the set in all other search results. The filter pop-up also adds a fourth option, “Locations,” adding to the general confusion.

FIGURE 1.10. Refinement on TripAdvisor for Android.

But TripAdvisor has yet another way to advise you: via the menu’s “Near me now” option. This browsing function at first glance holds the most promise, yet finding it is nearly impossible. But what’s most confusing is that, when tapped, “Near me now” unexpectedly catapults the user into the second tab on the search results page, labelled “Eat” (despite all of the previous searches being for hotels).

FIGURE 1.11. “Near me now” behavior on TripAdvisor for Android.

When designing your own implementation, be sure first of all to clearly understand the two ways that you want people to access your content—local and global, for example. Then, make sure to provide the same exact layout of search results for the two search options. Lastly, make sure that switching between the two search options (such as local and global) is simple and obvious. Parallel search architecture is a powerful design pattern, but clarity and simplicity are essential to getting it right on a tiny mobile screen.

In mobile, local search is the most frequent use of the parallel architecture pattern. Because our mobile devices move around with us, GPS-enabled local results are a frequent and important mobile use case. Whenever “simple” local results are needed, chances are there also exists an equally important yet more complex use case for search results that are not in the immediate vicinity—for example, booking a hotel room or reserving a table at a restaurant—for when the user is not physically present at the location.

Parallel architecture can be seen as a mobile microcosm of Jakob Nielsen’s flexibility and efficiency of use heuristic,⁴ whereby expert users are provided with powerful tools and options to perform advanced searches. These advanced tools would go unnoticed by the casual user who is looking for local results. Whenever a need comes up to accommodate both use cases gracefully, parallel architecture is the obvious and logical choice.

We have discussed two patterns to help your users navigate and winnow the massive amount of data they find. But what happens when they don’t find anything, perhaps due to mistyping? That’s where the zero results recovery pattern comes in.

Pattern: Zero Results Recovery

When humans attempt to operate tiny mobile screens with their thumbs, one-handed, while being jostled in the metro and eating a sandwich at the same time, mistakes are bound to happen. It is important to realize that such mistakes are not errors; they are the natural outcome of the conditions of the mobile environment—taking part in a fast-paced, multitasking world. Whether your mobile application provides geographic data, search results for help screens, or even target areas for interactions with game characters, have a fallback solution for when the results aren’t helpful. After all, the extent to which your app assists users in figuring out how to resolve their problem will determine in large part their sense of satisfaction with the app, their brand loyalty and whether they will recommend it to their friends.

Recovery boils down to three essential elements:

•Telling the searcher that the system did not understand them,

•Providing a way out,

•Leveraging to the fullest extent the sensor and history information available in the mobile context of use.

This seems to be a fairly straightforward strategy. Unfortunately, as the next example shows, many apps still struggle with relatively simple problems. The following are a few otherwise great apps that don’t manage to get the zero results recovery experience quite right.

Ignoring Visibility of the System’s Status

The first strategy of the zero results recovery pattern is to tell the user that the system did not understand him. Ignoring this fundamental principle makes the entire system less trustworthy in the eyes of the user. If the person is unaware that the machine did not understand him, then they might think that the machinery is malfunctioning—or, worse, that it is violating the basic rules of logic and reason. Not stating that a misunderstanding occurred violates the mental models that people construct in order to be able to operate complex machines, so they get stuck. Users then get frustrated or just move to an alternate website or app and never come back.

Below is an example from Yelp, where the system takes unusual liberties in trying to guess what people are typing. A person is looking for sushi restaurants in Cupertino, a city in the heart of California’s Silicon Valley. Unfortunately, the searcher mistypes the word “Cupertino” as “Coppertine.”

The results are sushi restaurants located in West Jordan! Needless to say, such results would be confusing in the extreme. The person might not even pay attention to the city marker, but instead try to call a restaurant to book a reservation or even try to navigate to it. Imagine the surprise! All of this grief could have been easily avoided if the system had clearly stated that it did not understand the query, while offering its best guess.

FIGURE 1.12. Search prediction on Yelp for iPhone.

Inadvertently Taking Away User Control

The iPhone’s own autocomplete feature can also offer this kind of blind guessing that apps sometimes do. Although turning off the autocomplete feature for the search box is easy, most app designers do not currently do it.

FIGURE 1.13. Autocomplete problems on Yelp for iPhone.

In this example from Yelp, the searcher entered the word “Samsung”, and iOS’ autocorrect—in its never-ending quest to protect us from ourselves and from competitors’ products—has unhelpfully substituted the word “Sanding.” For someone looking on Yelp for stores that sell Samsung products, the resulting set of destinations will prove highly unsatisfactory. Again, we have a familiar situation: there is simply no indication from the phone that any autocorrection has taken place. In fact, hitting the “Go” button substitutes the auto-corrected keyword automatically. In other words, action is required by the user to turn autocorrection off before hitting the “Go” button.

Incidentally, autocorrection is more of a problem on iPhones than on Android phones, because iOS offers only one autocorrected word (reducing the likelihood of an accurate guess), and it kicks in automatically, without the user’s explicit confirmation. Also note that the autocorrection comes up near the search box, perhaps a few hundred milliseconds after the searcher has verified that they’ve typed the word correctly. Thus, by the time the autocorrection is displayed, the searcher’s eyes are already focused on the “Go” button, so the substitution goes by unnoticed.

Fortunately, this zero results recovery anti-pattern is easy to avoid: always tell the person that you did not understand their query, and turn off the system’s autocorrection for search. Instead of the autocorrection, always use your own database of keyword suggestions, displaying them as a layer under the search box and requiring the searcher to select one before it is used so that it is not activated for search prematurely the way the iPhone’s autocorrection is.

Lack of Interface Efficiency and Useless Controls

The second part of the zero results recovery pattern is to give users a way out when they get stuck. This means that every control on the screen must help the searcher find a way out of the situation. Unfortunately, many apps neglect to remove unhelpful controls from zero results screens. As a result, we frequently encounter the situation below, which shows the Target app’s zero results screen for the query “Los sangelez”:

FIGURE 1.14. Zero results pages on Target for iPhone.

The first thing to note is that the system shows the error as an alert: “We did not find any matches for your request”; this is not optimal, as we discussed above, because it treats a simple mistyping as a biggest error, requiring an extra click of the searcher to recover. But the biggest issue here is that after the app acknowledges the error in the alert screen, it provides an unhelpful sorting control, set to “Best match” by default. Worse than that, this “Sort By” control actually drags the user deeper into the quagmire of the zero search by going through the motions of actually resorting to a non-existent collection of items. Do not underestimate the confusion and damage to the experience that such controls inflict. Useless controls are a clear anti-pattern; a zero results case requires that all available controls be focused on recovery and on navigating somewhere useful.

When implementing zero results screens, simply avoiding the anti-patterns is not enough. The best mobile experiences are “designed from zero”—that is, prevention and recovery from zero results is at the core of the way search is implemented. For example, zero results recovery could be based on the person’s search history and location, determined via built-in GPS.

Zero Results Recovery Based on History and Location: Booking.com App

With all of these anti-patterns, what does a good implementation of the zero results recovery design pattern look like? Well, a successful implementation starts with the basics: it clearly states that the system did not understand the query, and it provides no extraneous controls that would mislead the searcher deeper into the zero results condition. However, a truly excellent implementation of the recovery pattern goes the extra mile, beyond the “do no harm” stage, by leveraging to the fullest extent the device’s sensor and history data, if it is available. Although this is not technically challenging, strictly speaking, very few apps take the time to do this right.

FIGURE 1.15. Zero results recovery on Booking.com for iPhone.

One excellent example is Booking.com’s app, shown above. Booking.com puts an interesting twist on the pattern by simply treating every set of mobile search parameters as inherently approximate. Thus, the searcher can clearly see their original query and note that a zero results condition has occurred by seeing a list of autocorrected city names in the search results instead of suggested hotels. Booking.com also disables the autosuggest function, which prevents unwelcome autocorrection keyword “hitchhikers,” while at the same time allowing its own autocorrect mechanism to really shine.

But the autocorrect is not the only recovery mechanism available on Booking.com. The app takes the time to leverage both the user’s search history and current location, guessing, quite correctly, that because the user is using their mobile phone, they are most likely to be searching for a hotel near their current location. The resulting implementation of this pattern is shown on the next page.

FIGURE 1.16. Combining search history and current location on Booking.com for iPhone.

Note the two tabs: “Around me” (i.e. location-based autosuggestions) and “Recents” (i.e. history). Both tabs allow for effective re-engagement with the user’s previous search results and provide a robust location-based implementation of the zero results recovery pattern. Both of these methods are particular to mobile devices, which makes them ideal for providing superior zero results recovery strategies that are even more useful than those typically available via desktop websites.

Zero results is a key pattern in the mobile space. Every search implementation should use it, because searching on mobile is error-prone in the extreme. In fact, starting your search design from the zero results use case will often yield a much better design. The more time your team spends designing for zero results, the closer it will get to creating a truly successful finding experience.

Input

The mobile experience relies on a set of inputs that come from a combination of straightforward typing, data entry via motion, multitouch and on-board sensors such as the microphone and camera. Mobile inputs such as geolocation and ambient light can also be automatically collected from the environment by the device itself. The best input methods take full advantage of the unique capabilities of mobile devices, while at the same time being mindful of the many limitations of the mobile platform: difficulty of typing, low bandwidth, small screens and big fingers, which make precise pointing operations available on the desktop difficult to perform on mobile.

In this section we will describe three key data input patterns: designs that dissolve in behavior, tap-ahead and virtual assistant. Each of these patterns handles a different aspect of mobile input: ambient sensors, typing and complex multistep entry of massive amounts of data.

Pattern: Designs That Dissolve in Behavior

The best mobile designs make you feel as though you’ve somehow become Iron Man and donned the magical suit of red and gold cybernetic armor. It’s like an intelligent exoskeleton that surrounds you, comforting you with essential information at every step, somehow understanding your every wish, and performing miraculous feats to pull your butt out of the fire no matter how dire the situation—all by requiring you to do no more than you would normally do. This is the digital magic of designs that dissolve in behavior.

As Stephanie Rieger reminded us, mobile phones come equipped with a variety of sensors: camera, accelerometer, light sensor, microphone, multitouch screen, near field communication (NFC), global positioning system (GPS) and more. At the same time, accomplishing typical desktop computer tasks—such as typing, entering data, pointing precisely and operating multiple windows—are difficult on a tiny touch screen. Rather than blindly copying existing desktop computer functionality, the best mobile designs strive to replace heavy data entry and precise pointing with creative, delightful workarounds that use the sensors and capabilities that are available only on mobile devices. The best workarounds take advantage of people’s natural behavior in performing a task. For example, as Peter Morville explains in his book "Search Patterns", when you stick your soapy hands under the faucet to make the water flow, all you’re doing is telling the machine that you are ready for the water by doing what you would naturally do if the water was already flowing—then, the machine will turn on the water to match your expectations. This is a design that dissolves in behavior.

When you first open the Google app, you get a cute introductory cartoon that says: no need to push any buttons—just swing your phone up to your ear as you would naturally do to speak, say your search query—the Google app will interpret the voice command as a keyword query and execute the search.

FIGURE 1.17. Voice search on Google for iPhone.

In fact, the Google app gives you one additional clue: a fun little monkey hoot sounds out when the phone is swung up to your ear to let you know that it’s ready to listen to your voice command. Then, swinging the phone back down—again, a natural movement that one would use to look at the search results—activates the function that sends the query to the server.

The desktop equivalent of this interaction is typing a query in a text box, pressing the search button and then looking at the results. On a mobile phone, using the designs that dissolve in behavior pattern, the entire sequence of steps necessary to execute a query dissolves into the most natural sequence of movements imaginable, akin to calling a good friend who then sends you exactly what you’ve asked for. Using this pattern, transforming even the most mundane and trivial of tasks into a pleasurable personal experience becomes possible.

Unlocking the Phone via Facial Recognition: Android 4.0

One of the first principles of creating magical moments is to transform the trivial. Let’s start at the beginning: what is the most mundane activity one can do on a phone? For many us, it is unlocking the home screen.

Although no study has been done on how frequently people unlock their home screen, we can make some educated guesses. According to the Pew Research Center, one in three teens sends more than 100 text messages a day. We can imagine that they’d have to unlock the phone at least once every 5 to 10 messages, which means that teens unlock their home screen about 10 to 20 times a day, a conservative estimate. To do this on the iPhone, you have to enter four numbers using the numeric keypad.

FIGURE 1.18. Device unlocking on iPhone.

Notice the following:

•When it comes to inputting data, the experience is extremely left-brained. This is definitely a user-driven interaction, one in which the user has to do all of the work, having to memorize and then enter four digits.

•The entire interaction is performed using the numeric keypad.

•This experience is very personal (rather than social) and tied strongly to your personal identity: only you know the code to unlock your phone (or so you hope, as you use your phone in the metro and other public places).

•This experience delays the task you intend to do—you certainly did not pick up the phone only to unlock it! But you do have to unlock it before you can proceed with your goal of sending a text.

Unlocking the phone’s home screen definitely ranks low on the list of life’s inconveniences. However, with a bit of awareness and compassion and the addition of some cutting-edge technology, even this mundane experience can be transformed into a magical moment that dissolves in behavior.

Android’s 4.0 OS (Ice Cream Sandwich) includes an Easter egg functionality: the ability to unlock the phone using facial-recognition technology. First, there is a short set-up process, where you “train” the phone to recognize you in different lighting conditions (it takes no longer than entering a personal four-digit code). After your phone is set up to recognize you, the experience of unlocking the home screen becomes a purely magical moment. When the phone is turned on, it automatically activates the built-in front-facing camera, which starts shooting video of your face. While the video feed is active, the facial-recognition software compares the images in the video to the stored copy of your face. As soon as the software recognizes you as the owner, the phone automatically unlocks.

The entire experience is natural, seamless and personal. Most importantly, you remain in the flow of the task, focused on the goal that made you turn on the phone in the first place.

FIGURE 1.19. Device unlocking through facial recognition on Android 4.0

Note that the ergonomics of the power button play a large part in creating this magical moment. The Nexus phone’s power button is at the top-right of the phone, so most people will naturally hold the device in front of them in their right hand to turn it on, in preparation for whatever activity they will be doing. This puts the device at the perfect angle for the front-facing camera to start shooting video of their face.

Here are some things to keep in mind when applying a pattern like this:

•Facial-recognition software makes heavy use of typing alternatives—in this case, the device makes heavy use of the camera sensor.

•Because the user simply does what he would normally do, reflexively do in preparation for a task (i.e. hold the phone in front of them), the method of entry completely dissolves in behavior.

•The experience is even more personal than inputting digits. The phone recognizes the user “magically,” without exposing the secret password to the public (unlike a four-digit code, which could be stolen with a casual glance in a crowded environment such as the metro).

•Last but not least, unlocking a phone does not delay the task that the person has set out to do (for example, send a text) because it requires no thinking and little if any action on the part of the user. The design maintains the flow of the task and keeps the user focused on their original goal.

The final effect is a much more natural, flowing, right-brain process. Thus, at first glance, designing experiences that dissolve in behavior simply entails transforming all of the left-brain elements of the experience into their right-brain counterparts. Although that is a great starting point, this type of design runs deeper than that.

Transforming trivial activities into magical moments demands Zen-like awareness and compassion, as well as incredible technical prowess. It is about focusing on meaning as well as on technology.

Today’s mobile devices come with more sensors than we know what to do with. So, whenever data entry is required, consider replacing the tried and true mouse and keyboard controls with their more effective and better-performing mobile counterparts, which use accelerometer gestures, multitouch controls and voice recognition to facilitate data entry. Don’t forget: an on-board camera can also be used to read barcodes, including QR codes, and the emerging NFC (near field communication) capabilities will soon enable mobile devices to read and interact with RFID (radio frequency ID tags) to process anything from check-ins to payments. The best implementations of the designs that dissolve in behavior pattern combine two or more on-board sensors and mobile capabilities in ways that mimic our existing behavior. Whenever data entry is required, consider it an opportunity to redesign the entire process as a mobile-first experience.

Tap-Ahead Pattern: Autosuggest on Steroids

The tap-ahead pattern uses continuous refinement to create an intuitive, authentically mobile autosuggest solution.⁵ Instead of guessing the entire query that the user is typing in and offering the best one-shot replacement, the tap-ahead design pattern guides the autosuggest interface through the guessing process one word at a time. This is a much more natural, flexible and robust autosuggest method, optimized to solve the low bandwidth and big finger issues that people experience on mobile devices. It reduces the amount of typing needed and uses the lower bandwidth on mobile in the most efficient way. With this novel pattern, users can quickly access thousands of popular search term combinations by typing just a few characters.

Here is how the step-wise refinement of a tap-ahead interface works. Suppose two users, Anna and Ben, are both searching for “Harry Connick Jr.” Anna is using a one-shot autosuggest flow for this query, shown on the next page. Ben is using the new step-wise tap-ahead refinement alternative, as shown underneath the first figure.

When Anna types in “ha”, the interface suggests “harry potter,” “hard drive,” “halo reach,” “harry potter and the deathly” and the rather redundant “harry potter and the deathly…,” as shown in FIGURE 1.20.

FIGURE 1.20. Autocomplete search example.

Ben, who is using a step-wise refinement, sees a much more modest list of top 10 suggestions, all one word, such as “harry,” “hard,” “halo,” “hair” and “hat,” as shown in FIGURE 1.21.

FIGURE 1.21. Tap-ahead search example.

Because none of the terms exactly match the desired query (“harry connick jr.”), Anna, who is using the traditional one-shot interface, is forced to continue typing the word “harry.” Ben, however, can tap the blue circle with the arrow next to the suggestion “harry,” filling in the entire keyword with one tap.

Once both users enter the keyword “harry,” Anna again sees one-shot autosuggestions that include “harry potter,” several variations of “harry potter and the deathly…,” “harry potter dvd,” “harry potter wand” and many other “harry potter” variations, as shown in FIGURE 1.20.B. Unfortunately, the set does not include a suggestion of “harry connick jr.,” so Anna is again forced to type “c” in order to get the full one-shot autosuggestion of “harry connick jr.,” as shown in FIGURE 1.20.C.

By contrast, Ben receives only single keyword suggestions, so his second set of suggestions includes only a single instance of the keyword “potter,” which effectively covers all variations of the query “harry potter”—variations that were listed individually in Anna’s one-shot interface. Thus, instead of 10 variations of the “harry potter” query, Ben’s single-word autosuggestions include a rich set of 10 one-word complements of “harry”: “potter,” “connick,” etc., as shown in FIGURE 1.20. A one-tap selection selects “connick,” which yields the query “harry connick,” which is sufficiently close to the desired query “harry connick jr.” Note that, while it was not needed in this case, the addition of “jr.” could be easily accomplished with one more tap on the blue narrow down arrow.

To summarize, after both Anna and Ben had typed in the initial “ha,” Ben was able to finish entering the entire query in only two easy keystrokes—by selecting two successive autosuggestions—whereas Anna had to type in the additional “rry c” and select one autosuggestion—a total of six keystrokes. In this quick example, the tap-ahead interface has provided a huge improvement, considering how hard and error-prone typing is on mobile devices.

Whenever users need to input text, consider using tap-ahead. The advantage of this step-wise refinement is that suggested keywords can be loaded asynchronously for each of the 10 autosuggestions, even while the user is selecting the first keyword. Given that most queries are between two and three keywords long, and each successive autosuggest layer offers 10 additional keyword suggestions, tap-ahead with step-wise refinement enables users to reach between 100 (i.e. 10 × 10) and 1,000 (i.e. 10 × 10 × 10) of the top keywords by typing only a few initial characters, and without losing anything offered by the traditional autosuggest interface. The pattern maintains the flow and increases speed and responsiveness on tiny screens in a way that is simply not possible with the traditional one-shot autosuggestion interface.

Pattern: Virtual Assistant

As we’ve discussed, typing errors are common. Add to this the fact that many mobile users like to multitask and also frequently move from place to place, and you will find that accomplishing even the simplest of tasks, such as finding directions to a restaurant where you are meeting a friend, become challenging. Moreover, we often interact with our digital devices in situations where typing is not advisable (to put it mildly), such as while driving. Yet, even in those situations, people still may wish to accomplish basic tasks, such as jotting a note, getting directions, calling someone or setting a reminder.

In situations such as these, and to ease the burden of interacting with technology that requires an unusually precise set of instructions and combination of movements (such as typing), a virtual assistant can help. This is especially important for people who use a phone or tablet as their only means of Internet connectivity, both at home and at work.

But considering these simple tasks merely scratches the surface. The true aim of the virtual assistant pattern is to make the mobile interface increasingly similar to a natural human conversation, able to accept a great range of inputs flexibly and to recover from errors gracefully by requesting additional information.

Unfortunately, most artificial intelligence (AI) is not quite up to par. But to speed up the evolution of how we communicate with machines, we can use human-augmented virtual assistant services, such as Amazon’s Mechanical Turk (whereby one or more human assistants help a machine with complex tasks that require human senses and reasoning).

In this section we will discuss two examples of the virtual assistant pattern: a truly intelligent agent, the AI powerhouse Siri; and CardMunch, which works its magic by means of a human-computer hybrid service.

Apple’s Siri: Voice-Activated Intelligent Agent

The release of Siri for the iPhone 4S has kicked into high gear a long-standing race to create an all-in-one voice-activated virtual assistant based on AI. Prior to Siri, Google had long been leading the race with Google Search, the federated search app that searches across a phone’s apps and contacts and the Web at large. Vlingo and many other apps took the voice search pattern a step further by offering voice-recognition features that enable the user to send text messages and emails and perform other tasks, simply by speaking the tasks into the phone.

However, none of these apps have come close to the importance and popularity of Siri. Why? There are many reasons, including the mature interactive talk-back feature that allows voice-driven question and answer interactivity, including the amazing ability to handle X-rated and gray-area questions with poise and humor. Siri can even respond to somewhat ambiguous queries, such as “Where can I hide a body?”

FIGURE 1.22. Siri on iPhone as virtual assistant.

Perhaps the single most important feature is the dedicated hardware button for Siri (on iPhone 4S, you push and hold the home button to talk to Siri), which enables one-touch interaction with the virtual assistant. This one-touch access (and the resulting seamless experience), more than any other reason, is responsible for Siri’s meteoric rise in popularity.

Although pure speculation at this point, one of the applications of Google’s current voice-recognition technology could serve as the same sort of virtual assistant for your phone or tablet, activated by pressing (or holding) one of the hardware buttons (the home button would be a good choice); this could be made available in a future version of the Android OS. Added security for seamless device unlocking could be achieved via voice-print pattern recognition. Voice-recognition technology could also help distinguish a user’s voice patterns from those of other people in loud crowded places, thereby further increasing the personalization of the device and making it even more indispensable (if that is even possible at this point!).

But you might say, “Sure, Siri is great, but I don’t need to build one any time soon.” True, but that does not mean you can’t take advantage of voice-parsing technology to enable simple voice commands for your app. In Android 4.0, Google allowed app makers to license their voice-recognition technology, so pretty much any app can use a virtual-assistant pattern. For example, the current release of Yelp, shown on the next page, does not include the voice search feature, but it could be easily augmented with a microphone icon, as shown in my suggested wireframe on the next page.

FIGURE 1.23. How Yelp for Android 4.0 could include virtual assistant technology.

Yelp is often used on the go (say, while the user is walking around with friends, talking about where to go next). In this case, augmentation with simple voice entry makes perfect sense: the user would speak the query into the search box (quite a natural behavior, in keeping with the human-to-human conversation currently taking place in our scenario) and then share the results with their friends by showing it on the phone. Then, once the group has made its decision, the user would tap “Directions” and use the map to navigate to the place of interest.

Driving is another ideal activity for voice input, because the environment is fairly quiet, and the driver’s attention is focused on a different task, so hands-on use of the device is generally undesirable. Simple voice commands such as “zoom,” “pan left,” “pan right” and “directions” (which can be assumed to originate from the current location) can also be easily implemented, so that the driver does not need to take their hands off the wheel. And if you are able to use GPS to detect the direction that the car is traveling in and support voice commands like “directions to nearest gas station” and “show restaurants at the next exit,” then the experience will feel truly magical. Despite the universality of this task everywhere from US highways to the Autobahn, no app on the market currently performs these functions well.

Thus, the real power of Siri is not in what it can do, but in showing us the way forward for technology interaction: using our whole bodies—voice, motion and multitouch, in combination with on-board sensors (microphone, camera, GPS)—to produce an interactive, natural question and answer experience that brings the physical and digital worlds ever closer together. Speaking of on-board cameras, the next section shows how a virtual assistant can augment the camera input with a softer “human” side.

LinkedIn’s CardMunch: The Human-Augmented Virtual Assistant

As innovative and inspiring as Siri is, there are some things even she cannot do—reading business cards, for example. Business cards are a hassle. They’re easy to collect at networking events but take hours to enter into social networking databases. One service, CardMunch, solves this problem elegantly using the virtual assistant pattern.

FIGURE 1.24. Cardmunch for iPhone.

All you have to do is take a picture of the business card. Optical character recognition (OCR) software on the server reads the business card, and real human beings verify and correct the information as needed. It is not difficult to imagine that the information that the human readers provide not only makes the character recognition more accurate for the end user in the short term, but also provides further learning for the OCR AI that reads the cards, thus improving accuracy over time.

The CardMunch app is but a small example of what promises to be a powerful movement for mobile devices and touch tablets: complete virtual assistant (or “digital concierge”) services that replace tedious, error-prone or complex tasks that are not appropriate for mobile devices. Human assistants, perhaps even people with a unique sense of style and specialized subject knowledge, can work behind the scenes, in tandem with powerful learning technology, to provide a high-value service to people on the move.

Virtual assistant services are fantastic for any high-touch interaction or tasks that are difficult to accomplish on a small mobile screen. Tax preparation, high-end personalized shopping, travel booking, emergency situations and even simple finding tasks while driving or multitasking—the possibilities for improving the current mobile touch experience with a virtual assistant pattern are endless.

To apply this pattern, start by looking for complex data-entry tasks that most people would do anything to avoid. Then, see if those tasks can be replaced with an alternative method of input that is better suited to mobile devices. For example, instead of providing form fields for the user to enter data from a business receipt, allow the user to take a picture of the receipt instead. Then send the picture to a back-end human team that can read the receipt and enter all of its key data into a database that is accessible to the mobile user.

Engagement

The limited real estate on a mobile screen poses a unique challenge to users when navigating, browsing and reading. The immersive experience pattern balances the need to make navigation usable with the desire to allow content to shine. The tabbed views pattern addresses the frequent need to see the same information in various views, such as maps, lists and virtual-reality overlays. Last but not least is the need to support reading: a key activity on mobile devices. The reading and pagination pattern addresses how both the gestures we use to paginate and the pagination transitions depend on the size of the touch device.

Pattern: Immersive Experience

A typical iPhone app is quite different from a mobile game. The reason is simple: navigation. An e-commerce or social networking app can devote 30% or more of the screen’s real estate to navigation. As shown below, Amazon’s iPhone app is typical, showing the phone’s system bar, the tab bar and the menu bar. All of these controls come at a cost: in fact, these controls and indicators take up over 25% of the already tiny screen.

This unbalanced use of space is mainly due to the fact that people operating the app need to have sufficient real estate to be able to tap a control reliably. Thus, more space is devoted to controls and less to content. Amazon’s app is actually very decent compared to some others. Greg recently worked with a leading supermarket chain in the US to redesign its mobile website, which used over 55% of the screen’s real estate for navigation.

FIGURE 1.25. Navigation real estate on Amazon for iPhone.

Contrast this typical navigation-forward e-commerce and social networking experience with a game like Angry Birds.

Angry Birds devotedly sets aside 100% of the screen to the exciting and challenging venture of crushing egg-thieving pigs, while providing only a single pause button, which does not take up space because it is semi-transparent, allowing the game play to be viewed right through it. Tapping the pause button brings up the custom menu overlay, styled as a window shade (also known as “Roman shade” in the US) that takes up only a portion of the screen (darkening the rest), thus keeping the player in the context of the game. This menu overlay is a separate function that enables the rest of the game to be a highly immersive, addictive experience.

FIGURE 1.26. Full-screen experience on Angry Birds.

With the navigation removed and the focus entirely on the multi-touch gaming experience, the player remains fully immersed in the story. Would this immersive effect have been greatly reduced had 25% of the screen been devoted to navigation? You bet.

Taking up space with a menu and reducing the area available to content is only part of the problem. An even bigger issue is the awkwardness of the interaction this introduces. Let’s take the simple example of search results, a feature typical of e-commerce websites and one that people spend a large chung of their time with. A common gesture for viewing the content on a search results screen is to flick upward, which results in an accelerated page scroll that allows the searcher to quickly see more results below the fold. If the screen includes a tab bar at the bottom, then the area available for flicking is reduced—to the point that the user’s flick of the content pane occasionally runs into the buttons on the tab bar, causing an accidental tap. The smaller the space devoted to content, the more awkward the flick motion becomes. This is felt especially strongly when an app is used one-handed, while multitasking or during a bumpy commute (so, don’t look for confirmation of this design issue in a usability lab.)

Another powerful reason to move navigation to a separate overlay while creating a more immersive content view is that navigation is growing. That’s right: many mobile apps are offering more and more features, to the extent that the four-buttons-or-more model offered by the iOS tab bar or the five-buttons-or-more model offered by Android are bursting at the seams. Today, as people learn to rely more and more on their mobile device for virtually all of their computing and communication needs, apps often grow in features, exacerbating the ongoing problems of navigation-heavy interfaces. Some app designers are bucking the trend by using the immersive experiences pattern, making their apps more immersive and returning content to its rightful place as sovereign ruler of the mobile screen. As if this was not enough, another huge benefit of the immersive experience pattern is that menus can be made richer with custom graphics, easier to tap and more full-featured. Designers are pulling this off by moving heavy navigation to window shade menu overlays or rollaway dashboard menus and to popovers.

Window Shade Menu: Redesigned Target App

Target recently redesigned its flagship iOS apps to introduce a window shade menu, not unlike that of Angry Birds. It represents a conscious departure from the standard black iOS tab bar, replaced by the small “handle” of the custom menu” layer that rolls up from the bottom and over the shadowed content. The effect of the transition is to keep the searcher in the context of the results while also allowing for navigation to one of six destinations.

FIGURE 1.27. Window shade menu on Target for iPhone.

Contrast this implementation of the immersive experience pattern with the standard iOS tab bar. The standard bar allows a maximum of only five choices, which means that the six choices in this menu would have been effectively reduced to four visible choices (i.e. four gray-on-black icons, plus a “More” button to navigate to the remaining two options on a separate screen). This would have resulted in trading in about 15% of the screen’s real estate! The window shade menu allows for all six options to be shown, all with richly colored custom icons, and all given the signature flaming red menu of Target’s brand. Best of all, the real estate that is reclaimed by hiding the tab bar (and increasing the product viewing area by 25%) allows Target to show one more item in its entirety, making for a more immersive experience.

Interestingly, this design has another fringe benefit: it works just as well for Android. (Put differently, Target offends the sensibilities of Android’s standards team just as much as it does iOS’ standards team.) Target is a prime example of an equal-opportunity offender by offering an excellent implementation of the immersive experience pattern with its window shade menu overlay.

Rollaway Dashboard Menu and Popovers: Facebook App

If you’ve stuck with us this far, your patience will now be rewarded. We’ve left the best for last: the immersive experience pattern implementation provided by Facebook in its recently redesigned app. Facebook’s is an interesting app; among the many areas of interest in its interface, the most important and frequently visited remains the updates. To make the updates page more immersive, with a minimum of distractions and “chartjunk,”⁶ while having it conveniently house all of Facebook’s many features, the app implements a rollaway dashboard menu as part of the immersive experience pattern as shown below:

FIGURE 1.28. Rollaway dashboard menu on Facebook for iPhone.

Unlike the window shade menu overlay, which obscures part of the content, Facebook’s menu slides content over to the right, showing only a vertical slider (a teaser) of content to retain immersion, while devoting most of the screen space to the menu. This design affords an amazing luxury: Facebook is able to show eight and a half menu options, and also indicate that the menu is scrollable—a major departure from the window shade menu implementation. This increased real estate allows Facebook to group the features into sections, making interaction with perennial favorites easier, and enabling the service to conveniently introduce new features to test adoption.

Another way the Facebook app implements the immersive experience pattern is by displaying key alerts via popovers.

Like the teaser menu and window shade menu overlay, the popovers serve to keep the user in the context of the current view, thus preserving the immersive experience.

FIGURE 1.29. Popover alerts on Facebook for iPhone.

Immersive designs should be used whenever navigation and menu controls threaten to overwhelm the content. If you find yourself adding yet another navigation bar above or below the content, then consider moving the navigation off screen. The pattern is an opportunity to make navigation controls a beautiful and integral part of the whole experience; rather than slapping buttons onto the design at the end of the process, you are redesigning the entire experience around custom navigation. As the delightful example of Flipboard’s app demonstrates, immersive experiences take mobile sophistication to the next level, beyond the standard controls of iPhone’s tab bar:

FIGURE 1.30. Window shade overlay menu on Flipboard for iPhone.

Like Target’s app, the designers of Flipboard discovered that the standard iPhone tab bar does not provide enough choices and is not customizable enough, so they created a window shade menu overlay that houses custom options selected by the user when they are configuring the app. The result is a custom, fully immersive experience centered on the core window shade menu functionality.

The iOS writing app iA Writer is another great example of the immersive experience pattern. Once a user starts writing, all of the menu bars fade away, leaving the user with only the words on the page and the keyboard that they need to get their novel into the world:

FIGURE 1.31. Immersive writing experience on iA Writer for iPhone.

The iPhone’s tab bar is basically a set of training wheels: it gave us a simple framework for designing and using apps, which enabled Apple to quickly dominate the marketplace with hundreds of thousands of apps. However, the tab bar and its associated design language shouldn’t become a crutch. Highly successful, delightful apps such as Flipboard and iA Writer—not to mention most successful games—freely violate both Apple and Android’s mandates with designs that are thoughtfully implemented for the task at hand. The next step in evolution of mobile apps is to offer truly immersive user interfaces designed specifically for the intended purpose.

Pattern: Tabbed Views

Tabs at the top of mobile pages allow users to switch between different presentations of the same content. For example, tabs can be used to toggle between list, gallery and map views of the same set of search results. Tabs are easy to discover and intuitive to use. They borrow freely from the mental model of the desktop Web and represent an easy way to understand the available viewing options. Wikitude is an app that uses the tabs design pattern to switch between views. Wikitude recently redesigned its app for Android 4.0 OS:

FIGURE 1.32. Tabbed views on Wikitude for Android 4.0.

The menu options in the tabs are shown as miniature icons. The icons look considerably more sophisticated and polished than the older versions (shown below), and they take up little screen space. The default setting displays the search results in an artificial reality (AR), or “camera,” view by default. This is a risky choice, especially coupled with the smaller icons, because a casual viewer might not notice the other icons or might not understand what they mean. As you can see, the user’s first casual AR experience is not particularly satisfying or useful (the labels block each other and are almost impossible to read), so the person might abandon the app after just one use and never discover the much more useful list and map views.

Also significant is that the active camera tab is not shown to the user, exacerbating the discovery issue. Not having the active tab shown makes it difficult to understand the relationship between the different views.

Interestingly, the older version of the Wikitude app had tabs that looked very different. The difference between this new version of Wikitude and the older version shown on the next page is relevant to our discussion:

FIGURE 1.33. Previous version of Wikitude for Android.

It’s hard not to argue that the new design of the Wikitude app, featuring the slicker graphics, is an improvement on the previous version. Tabs in the older version featured clunky icons and non-English text and took up a great deal of the screen. However, the older version was in many ways superior in learnability and usability. The default tab was the list, followed by the map, and finally the camera (or AR) tabs. This likely matches the typical sequence of use of the tabs—an important plus. Another huge plus is that the active tab was visible and highlighted, making it easy to understand the app’s information architecture (IA).

With plenty of space available for all three miniature icons, the designers could have easily incorporated the active tab and shown it next to the two other tabs using Android’s “underlining” treatment:

FIGURE 1.34. Proposed design changes to Wikitude for Android.

Starting with the list view and using the blue underlining treatment for the “You are here” tab would make the app much more usable.

Keep in mind that these tabbed “views” do not necessarily refer to different representations of the data. They could also be used to apply sophisticated combinations of filtering and sorting parameters to a set of data and provide convenient entry points into vast, complex collections of items that cannot be easily searched. The classic example of this application comes from the Google Play store:

FIGURE 1.35. Tabbed views in Android Play.

Here, tabs are used to switch between “Categories,” “Featured,” “Top Paid,” “Top Free,” etc. In the Google Play store, tabs provide convenient, self-explanatory entry points into a vast collection of apps by reducing the complexity into an interesting and quite manageable list of three categories of top results. These three lists are updated often and provide intrinsic entertainment value (think of water-cooler gossip such as, “Guess which free app is most popular today?”), which make these tabs one of the most popular destinations on the Android platform. Note that Play implements an instance of scrolling tabs, allowing the user to browse more than just the four to five options that are visible on the screen at one time, by tapping on the partially hidden tab via horizontal swiping. While this method reveals more than can be seen in a single view, it is also limited to a manageable number of eight to ten tabs—any more and swiping fatigue sets in, and discovering all of the various options becomes harder.

When using the tabbed view pattern, ask yourself, Does the user really need all of those views on the same IA level? Contrast Yelp with Wikitude: although Yelp also has the AR function (Yelp Monocle) and was, in fact, the first app to introduce this feature, Yelp Monocle’s AR view is deliberately kept separate from the list and map views, setting it off as an experimental “fun” feature, separate from the “working” views of the list and map. If you have only two tabs or if users would not switch tabs often, then a good alternative that saves precious space would be a dedicated button to switch views. A good example of this is the dedicated map button for switching views in Yelp Android app:

FIGURE 1.36. Switching views on Yelp for Android.

By providing a map button instead of a tabbed view like Wikitude, Yelp eliminates the need for an additional tab bar and is free to devote the full screen to the map view, without having to pollute the view with tabs, which greatly improves the map view’s functionality and creates a more immersive experience.

Consider the tabbed view pattern if your app needs to communicate a large amount of related information (such as the details of a product in an e-commerce app) or if different views are needed for the same information (such as numbers versus a visual representation of data). Tabs have been in use for a long time on desktop applications and websites, so most users have no trouble applying their existing mental model to mobile applications. But, as explained in this section, make sure that the amount of information remains manageable to users. The tabbed view pattern certainly isn’t an excuse not to conduct a proper IA assessment.

Pattern: Reading and Pagination

In addition to the simple scrolling that dominates desktop applications, mobile devices and tablets present unique opportunities to create reading experiences. The very form factor of the devices and the way they fit into our hands remind us of books and magazines. These devices are used to display information for easy consumption, much like books and magazines do.

Back in 1999 (and revised slightly in 2005), Jeffrey Zeldman said this:⁷

Most of all, I worry about Web users. Because, after ten-plus years of commercial Web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the Web which is what most of them do when they’re online.

Those words still ring true today, but with the rise of mobile reading, we do seem to have learned the lessons of the past. There is a wonderful renewed focus on clean reading experiences and good typography. In fact, when it comes to reading on mobile devices, any good pattern will adhere to two core principles: focus on the words, and make the words pleasantly legible. This is as true for the desktop as for the mobile experience, but in this section we’ll focus on mobile.

The best way to help users focus on the words is to get rid of distractions. If it’s possible to remove chrome while the user is reading, do it. Instapaper is great at this, sliding the top and bottom navigation out of the way automatically as the reader gets into the article. Instapaper also makes some smart guesses as to when the navigation should reappear—such as towards the end of the article, and when the user taps in the middle of the page. This is an essential part of the pattern—nothing is more frustrating than furiously tapping around to make the navigation reappear so that you can get back to the main menu.

FIGURE 1.37. Reading experiences on Reeder, Flipboard, and Instapaper for iPhone.

We can’t talk about getting rid of distractions in a mobile reading environment without talking about advertising. And while it’s beyond the scope of this chapter to argue for or against advertising, in the context of mobile reading patterns, it’s safe to say that advertising should be kept to an absolute minimum, and that the reading flow should never be interrupted. Avoid slide-over screens that need to be dismissed before an article can be viewed, and place advertising at the top or bottom of an article. Because of the small size of mobile devices, readers have even less tolerance for ads than on desktops—ignoring an ad is much harder if it takes up between 50% and 100% of the screen.

Referring to his landmark and controversial article from 2006,⁸ Oliver Reichenstein argues that even those who disagreed with him at the time are starting to come around to this idea. As Oliver points out in his article, “Optimizing typography is optimizing readability, accessibility, usability(!), overall graphic balance.”

In a recent interview with Smashing Magazine, Codex creator John Boardley said the following:

Type matters because words matter—whether they are words that inspire (in prose or poetry), words that guide us (wayfinding), beseech, implore, persuade (advertising)—they all matter. Beyond the fundamentals of legibility and readability, the choice of typeface and the typography, the mise en page, imbue those words with a voice beyond words, with a personality that sets the scene. The choice of typefaces is analogous to the music score for a movie—the very same scene made more sober, more exuberant, more frightening, more comical, more beautiful, more inspiring, simply through the accompanying music score.

With the rise of Typekit, Google Web Fonts and other independent foundries, most excuses for not using good typography for reading experiences are melting away. The pattern here is simply stated but hard to implement because it will vary depending on the nature of the content: One must use typography that not only improves readability, but embodies the emotion of the words.

Applications that do this well—i.e. low-distraction reading experiences that have good typography—include Reeder for iPhone, Instapaper and Flipboard. Their designers have all put a great deal of work into choosing typefaces that fit the purpose of the application.

Mobile devices are highly suited to being read one page at a time, with the text fixed in place. The need to resume reading comfortably at the precise place one left off before being interrupted is another important factor that has been made easier historically with the addition of pages and page numbers. Thus, it is only to be expected that the pagination metaphor has entered the mobile context so strongly.

Should we continue to use the page flip animation and the book “skin” metaphor to make mobile devices resemble their physical book and magazine counterparts? The answer depends strongly on the size of the device, which is why the reading and pagination pattern is so important in our discussion. The bottom line is balance: the reading and pagination pattern should be applied according to the size of the screen and the nature of the hardware.

Pagination for iPhone and iPad: Amazon Kindle App vs. iBooks App

Page flip is a spectacular transition: it’s classy, and it works well for browsing magazines, reading books and consuming other media because it mimics the real world so well. For example, iBooks offers a beautiful and well-executed page flip for the large iPad, which can accommodate larger multitouch gestures comfortably.

FIGURE 1.38. Pagination on iBooks for iPad.

However, on smaller devices, such as iPhone, the page flip never really took off. The screen’s size is simply too small to comfortably accommodate the swiping gesture that is needed to convey the magic and physicality of a digital device acting as a magazine or book. Instead, people quickly learned to simply tap the corner of the screen as a shortcut to go to the next page, losing the charm and physicality of the flip in the process. The whole page-flipping transition quickly became tedious when reading lengthy documents. Pages on the iPhone are very short, and the overly frequent animation quickly becomes distracting, and the cumulative effect of having so many transitions in a single reading session feels rather time-consuming (or at least is perceived to be).

Simply scrolling down (as in the Safari app) or sliding (as in the Kindle app) to navigate pages is much more efficient and less disorienting.

In addition, putting the two apps side by side, the Kindle app clearly devotes more of the screen to the book’s content. In fact, it devotes all of it, without the book binding and edge artifacts that command such prominent space in the iBooks app. While these artifacts look great and seem appropriate to larger devices such as the iPad, on the smaller screen, this physicality seems forced and becomes chartjunk.

Note that the Kindle app enables navigation using a special version of the immersive design pattern—the screen overlay—a simple and elegant solution.

FIGURES 1.39–1.40. iBooks for iPhone (left). Large font setting on Kindle for iPhone (right).

An application that strikes a good balance with device-specific pagination is Instapaper. The iPad app has a smooth and realistic page-turning animation as shown above.

The animation is optional, though; users can turn it off, in which case the page-turning happens instantly, without an animation.

There is a similar option in Instapaper’s iPhone app, but it goes beyond page-turning animations. With “tilt scrolling” turned on, an article will scroll slower or faster based on the angle of the phone. If tilt scrolling is turned off, a regular tap advances to the next page.

Reading and pagination patterns are needed for all kinds of information consumption on touch devices: magazines, books, newspapers, etc. Implementing the reading and pagination pattern calls for balance: on large devices such as the iPad, it’s best implemented with a certain amount of “physicality”—background graphics, page-flip animations, etc.—visual design elements that mimic the attributes and behavior of a physical artifact. Small mobile devices, on the other hand, call for minimalist implementations, including a full-screen display, simple sliding transitions and overlay menus. And we mentioned typography, right?

Conclusion

Never before in the history of the human race have we had access to technology at once so capable and so ubiquitous. Mobile design has virtually unlimited potential to reach almost every person on the planet. Yet mobile is also very young and currently in Wild West mode, and many basic ideas and design patterns are only just beginning to emerge.

Well-executed mobile design is deceptively simple. Yet it is also highly sophisticated. When mobile and tablet design is executed well, the device feels like an extension of our body because the interface is able to respond even before we consciously give it a command. We feel empowered, as though we were wearing Iron Man’s suit or Batman’s utility belt. Right now, this kind of experience is still fairly rare, because on a tiny screen every little thing is important, and getting everything right the first time is hard, making both creative approaches and rigorous user testing essential.

It is now up to us to use this amazing technology to help us shape the future of our world. The patterns in this chapter should help you to nurture and develop your own unique ideas so that they blossom into amazing mobile experiences that your users will rave about. So, get going already!

Footnotes

¹ eBay’s mobile apps have been downloaded more than 65m times across various platforms. eBay’s PayPal subsidiary expects to do $7bn in mobile payments this year, up from $4bn in 2011. smashed.by/mobile-sales

² More excellent mobile search patterns are in the Smashing Magazine article “UI Patterns for Mobile Apps: Search, Sort and Filter”: smashed.by/searchsort

³ “Eric Schmidt: Every 2 Days We Create as Much Information as We Did Up to 2003,” TechCrunch: smashed.by/ericschmidt

⁴ “Ten Usability Heuristics,” Jakob Nielsen: smashed.by/heuristics

⁵ For more, see “Mobile Auto-Suggest on Steroids: Tap-Ahead Design Pattern,” Smashing Magazine.

⁶ smashed.by/hartjunk

⁷ smashed.by/stylevsdesign

⁸ “Web Design is 95% Typography”: smashed.by/web-typo

About the Authors

Greg Nudelman is the founder of UX design consultancy DesignCaffeine, Inc. based in the San Francisco Bay area. He believes in “designing what works”. His first experience with designing for mobile came when he joined the SkunkWorks team that created the original eBay mobile app that today generated over 5 Billion dollars in revenue.

In his now more than 15 years of experience Greg has worked with some of the most remarkable companies and agencies, including Cisco, eBay, Wells Fargo, Groupon, Associate Press and many others.

Greg is the author of Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) and Designing Search: UX Strategies for eCommerce Success (Wiley, 2011) and a contributor to half a dozen published books.

Internationally acclaimed speaker, Greg made repeated appearances and sold-out workshops at leading industry events like Adaptive Path’s UXWeek, SXSW, MobX, IA Summit, WebVisions, Design4Mobile etc.

Greg blogs at AndroidDesignBook.com.

Rian van der Merwe (1977) was born in Cape Town, South Africa, and currently lives at the foot of the Table Mountain. He is a director at a small user experience design agency called Flow Interactive that specializes in user-centered design as well as interaction and visual design. Rian loves working with such a diverse group of clients and helping them shape their services. He lives and works by the motto “Design like you’re right; listen like you’re wrong.”