Chapter 9

Avoiding Missing and Undesirable Results

When customers attempt to operate tiny mobile screens with a fat thumb, using only one hand, or while being jostled in the metro and eating a sandwich at the same time, mistakes are bound to happen. You must realize that those mistakes are not errors. They are a natural outcome of mobile computing, which takes place in a fast-paced, multitasking world. This makes avoiding missing and undesirable results a priority. The extent to which your app assists your customers in figuring out how to resolve the missing and undesirable results condition determines in large part their sense of satisfaction with your app, their brand loyalty, and whether they will recommend your app to their friends.

Essentially, recovery boils down to three essential elements:

• Telling the searcher that the system did not understand him
• Focusing on providing a way out
• Leveraging to the fullest extent the sensor and history information available in the mobile context of use

This seems like a straightforward strategy. Unfortunately, as you see in this chapter, most apps still struggle with relatively simple problems.

9.1 Antipattern: Ignoring Visibility of System Status

On a small mobile device with its frequent user entry errors, it is tempting to bypass telling a customer about the problem and instead just take corrective action. This is generally better avoided by simply telling the customer “I did not understand,” and thus it makes the first antipattern.

When and Where It Shows Up

This antipattern is fortunately not common. However, whenever the system takes some significant action on behalf of customers without telling them about it, this antipattern rears its ugly head.

Example

Here is an example from Yelp, an otherwise fine app, where the system takes unusual liberties in trying to guess what people are typing in. For example, in the image shown in Figure 9-1, the 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 to the extreme. The person may not even pay attention to the city marker, but instead attempt to call a restaurant to book a reservation or even try to navigate to it. Imagine the surprise! All this grief could be easily avoided if the system clearly stated that it did not understand the query rather than silently attempting to give its best guess instead.

Why Avoid It

The first strategy of the zero-results recovery pattern is to tell customers that the system did not understand them. Ignoring this fundamental strategy makes the entire system less trustworthy in the eyes of customers. If people are unaware that the app did not understand them, they might think that the app is malfunctioning or, worse still, violating the basic rules of logic and reason. Not stating that a misunderstanding occurred, violates the implicit agreement of the mental models people construct to operate complex machinery, so they get stuck. In the real world that means that customers feel frustrated but try again or—a worse scenario—move to a competitor’s site or app and never come back.

Additional Considerations

To clarify, it’s actually a great idea to try to guess what the person is trying to type in—many patterns in the chapter are devoted to doing exactly that (see the “9.4 Pattern: Did You Mean?” section). But if you are trying to guess, be sure that your customer realizes what is happening.

Related Patterns

9.2 Antipattern: Lack of Interface Efficiency

Whenever a zero-results condition occurs, avoid the temptation to show an “error” state, particularly the one that requires an extra tap to get out of. Because missing or unwanted results are not an error, Lack of Interface Effieciency is an antipattern.

When and Where It Shows Up

This antipattern is common in apps that do not spend time designing missing results recovery mechanisms, but instead “blame the user” by showing the “official” Android error, and thus requiring an extra tap.

Example

Figure 9-2 shows an example from the Target app. When the keyword query is not recognized by the system, the app pops up an alert that says, Sorry, No Results Found Matching Your Request.

This alert inconveniences the customer in two important ways:

• It requires an extra tap to acknowledge the missing results condition.
• After the tap, the system navigates away from the Search Results tab and into the Shopping Basket tab.

This is both unexpected and inconvenient because the person looking for an item most likely mistyped it, so he needs to return to the Products tab again, which requires an unnecessary additional tap. Thus to recover from a common fat-finger mistype, the system requires two additional taps. This is an antipattern.

The error dialog, plus additional tap required to get out of it, signal to the customer that he did something wrong and committed a sin…maybe even one of the unforgivable ones. If you recall that missing and unwanted results are both logical and natural outcomes of the mobile context of use on a tiny screen, it’s easy to see that the extra tap acts as a sort of punishment added to an insult. You're hitting the customer’s knuckles with a metaphorical ruler.

Additional Considerations

Recall that the second strategy in the missing or unwanted results recovery is focusing on providing a way out. The best way to do that is through an efficient, straightforward interface that does not treat any break down in communications with hostile dialogs. The dialogs and additional clicks they contain yank the person out of the state of flow, interrupting the search process abruptly.

Flow in search is important (read more on this later in the chapter), and it needs to be maintained at all costs. Dialogs that ask for additional taps and take the customer away from the task at hand (such as the Target app navigating to the Basket and away from the Products tab) break the flow. As Alan Cooper so eloquently said in his book About Face (2007, Wiley), dialog boxes “Stop the Proceedings with Idiocy.” So although you must signal clearly to the customer that the misunderstanding has indeed occurred, you also must do it without breaking the sense of flow of the finding process. That’s what keeps your customers going and keeps them engaged in the finding task.

Related Patterns

9.3 Antipattern: Useless Controls

All too frequently the controls provided by the interface on a zero-results screen are the same as those provided on a screen with actual results. This is an antipattern.

When and Where It Shows Up

The Useless Controls antipattern occurs on zero-results pages treated the same as those pages that have results.

Example

Unfortunately, this antipattern is quite common. Figure 9-3 is an example from TripAdvisor, where the customer accidentally fat-fingered the word "saucelito” (while trying to enter "sausalito”), and the system helpfully said, Sorry, but Nothing Matches Your Search. So far so good—the app avoids Antipattern 9.1 Ignoring Visibility of System Status. Unfortunately, the screen also displays the Filter Search Results link.

Tapping the Filter Search Results link causes a filter dialog to display so that the customer can filter results by Destinations, Hotels, and so on. When the customer taps the Hotels button, he goes back to the same zero-results screen, but now the Hotels filter is applied. Of course, filtering zero results by hotels again produces zero results.

Why Avoid It

As you know from elementary algebra, zero divided by a number always yields zero. Zero results condition renders the filtering control useless. Actually, it's worse than useless because this filtering interaction drags the customer deeper into the quagmire of the zero-results search by having him go through the motions of actually filtering a nonexisting collection of zero items. Do not underestimate the customer confusion and damage to the experience that useless controls inflict. Useless controls are a clear antipattern. The zero-results situation requires that all the available controls focus on recovery and navigating somewhere useful.

Additional Considerations

None

Related Patterns

9.4 Pattern: Did You Mean?

The simplest and arguably most powerful missing results recovery pattern is Did You Mean?—named after the Google search feature of the same name.

How It Works

When the customer types a keyword query that's not recognized by the system, the system offers a set of controlled vocabulary substitutions that are based on creative spelling of the original keyword query. The resulting list of keyword suggestions may or may not include the Did You Mean? title that Google uses, and it's not limited to a single suggestion. Given the number and creative quality of the misspellings possible on the mobile platform, the number of suggestions could also be correspondingly large.

Example

One creative implementation of the Did You Mean? pattern is done by the Booking.com app (see Figure 9-4).

Booking.com flips the entire search equation on its head by assuming from the beginning that you somehow mistyped the query. The result is a robust Did You Mean? interface that automatically suggests one or more controlled vocabulary substitutions for every keyword entry. Booking.com recognizes that the world is getting smaller, so you might just like to travel internationally, so it offers creative spelling suggestions from all over the world, as a kind of query prescreening. This is a nice example of the company branding expressed as a user interface feature.

One thing to note is that Booking.com adds the extra details (for example, Los Angeles, city in United States) which makes the extra click of the mandatory Did You Mean? query prescreening process worthwhile even for entries that are exactly correct in the initial spelling. After the city and country are positively identified, the added country meta data makes the final results for Hotels and Attractions reliable.

When and Where to Use It

At least one Did You Mean? suggestion is mandatory for any search suspected of keyword misspelling. Sometimes misspellings may be difficult to identify—a controlled vocabulary tuned to mobile-specific misspellings (such as one discussed in the “7.3 Pattern: Tap-Ahead” section) could be very helpful. Lastly, if you can’t find any helpful Did You Mean? suggestions, you probably shouldn’t suggest anything, just indicate zero results and use one of the other patterns in this chapter instead.

Why Use It

Misspellings caused by fat-fingering of the mobile device's tiny touch keyboard are common. Yet keyword queries are by far the most popular search methodology. This makes it imperative to implement the keyword query correction as a first line of defense against missing or unwanted results.

Other Uses

Did You Mean? is basically an Auto-Suggest pattern (refer to Chapter 7, “Search”) that was implemented after the search has taken place. Given the tight bandwidth of most mobile devices, Did You Mean? is currently the more common pattern of the two. However, don't forget that almost anything that can be done after the search query is run can potentially also be implemented using Ajax on the front end before the query is run. Sometimes, Auto-Suggest is clearly superior to Did You Mean?, particularly in multi-field parametric queries, such as booking a flight. The name of the airport can be quite challenging to remember or guess, so a lookup with the Auto-Suggest based on the city name or airport code is essential. Ideally, at some point in the near future, as networks become faster, the entire process of two Auto-Suggest lookups (from and to airports) and the Did You Mean? feature in the results set (to suggest alternative departure times) becomes virtually seamless. In other words, the distinction we now draw between Auto-Suggest and Did You Mean? patterns will become even more blurred and eventually disappears entirely as you get instant feedback and suggestions for your query even as you view the results, much like Google Search now does on the web. Patterns such as Tap-Ahead (refer to Chapter 7) help show the way.

A related approach is to cache controlled vocabulary substitutions on the mobile device itself, much like the high-end paid language translation apps do currently. Mobile devices are actually full-featured computers. For specialized terms (like Pets or Airports) you can cache on the order of 100,000 or more Did You Mean? substitution terms locally and use the mobile device itself to run sophisticated regular-expression matching algorithms against this collection locally, instead of sending anything to the server. If you decide on using this approach, consider storing queries that cause the Did You Mean? function to activate in a log stored locally on the device, and periodically upload that log to the server, where it can be analyzed and used to improve suggestions in the future.

Pet Shop Application

Given the complex spelling of various pet breeds, it’s easy to see how a Did You Mean? pattern can be useful in a Pet Shop app. However, it is tricky to see how to integrate Did You Mean? with various other refinement strategies. See "9.6 Pattern: Local Results" later in this chapter to see all the various missing and unwanted result strategies working together.

Tablet Apps

This pattern works the same way for tablets as it does for the smaller mobile phones.

Caution

Did You Mean? is also sometimes called controlled vocabulary substitution. This means exactly what it says: The keywords suggested to the customer as part of the Did You Mean? recovery pattern come from some table in the database that contains the “good” or “allowed” keywords that form the controlled vocabulary. The quality of the substitution depends greatly on the quality of the controlled vocabulary, which, as discussed in Tap-Ahead (refer to Chapter 7) could be quite different on the mobile from its web counterpart. Not only can the queries be different, but the misspellings can also be different driven in part by the mobile keyboards. To make things even more interesting, there is anecdotal evidence that these misspellings depend in large part on ergonomics of the keyboard on a particular device. Therefore, iPhones, Android mobile phones with touch keyboards, Android devices with physical keyboards, Android tablets, and Blackberry phones may all give rise to different misspellings depending on the keyboard ergonomics of a particular device.

One idea might be to keep a specific database of the mobile-only misspellings and Did You Mean? suggestions. This enables you to better tailor the experience for mobile customers, without polluting the Did You Mean? database on the desktop web, which might include different misspellings. Whether you choose the approach with two split databases over the combined database depends wholly on your specific use case.

Related Patterns

9.5 Pattern: Partial Match

The second most important recovery strategy for missing results is Partial Match, which lets you recover from the missing results condition by omitting some search terms from the query.

How It Works

For queries with multiple keywords that return zero results, it is not always clear which keyword created the missing results condition. In this case, Partial Match Pattern can be used to recover. Partial Match reruns the query that consists of matching fewer keywords than were entered by the customer—that is, the system removes one or more of the keywords.

Example

One of the best examples in the industry comes from Amazon.com’s mobile website (see Figure 9-5), which mimics the desktop in important respects.

The query Nike Ruskie Red produces zero results. The website clearly massages the condition. As part of the recovery strategy, Amazon.com helpfully does the search without the problem word “Ruskie” so that a results “appetizer” can be presented to the customer, which says in effect, “If you remove the problem keyword, you see more items like these.” Strikeout coupled with the contrasting font color used for the problem keyword “Ruskie” creates a highly effective visual treatment that communicates how the Partial Match works.

Unfortunately the same cannot be said for the Amazon.com app. Although the mobile website works extremely well, the app does not provide any Partial Match recovery; it merely states that zero results have been found, as shown in Figure 9-6.

This forms an effective demonstration of the value of the Partial Match as a missing results recovery strategy.

When and Where to Use It

Partial Match is somewhat less important for mobile than it is for the desktop web. This is, of course, due to the difficulty of typing on the mobile, which results in slightly fewer average words per query. However, for some applications, e-commerce, and business apps, for example, the number of keywords entered on the mobile is quite close to that on the desktop. For those applications that employ long queries with multiple keywords, Partial Match forms the second most important recovery strategy after the Did You Mean? pattern discussed in the previous section.

Why Use It

Human beings are subject to a strong psychological effect called anchoring. Anchoring is a cognitive bias that refers to relying too heavily on one piece of information—in this instance, one query keyword. My book Designing Search: UX Strategies for Ecommerce Success (Wiley, 2011, ISBN: 978-0-470-94223-9) describes a situation in which the test participant was so convinced that the book she was looking for was titled Harry Potter and The Sleepy Hollows that she kept adding more and more information to the query (including misspelled author’s name as “JK Rolins”) over and over again, while the query kept returning zero results. The person in question anchored on the erroneous word “Sleepy” and no amount of failure would get her unstuck. She was so anchored on that term that at the end of the test, she erroneously concluded, “The store must not carry any Harry Potter books.”

Her search behavior while on the system could be characterized as churning, what Peter Morville and Jeffrey Callender describe in their book Search Patterns (O’Reilly, 2011, ISBN: 978-0-596-80227-1) as running similar queries over and over while getting the same missing or unwanted results. The Partial Match pattern stops churning and anchoring behavioral antipatterns by showing clearly which keyword of the bunch caused the problem. The best implementations of Partial Match also return a sample “appetizer” (or the full search result) of the query without the extra keyword present to demonstrate the outcome of the query. Such implementations usually break the anchoring most effectively.

Other Uses

Sometimes it’s hard to tell which keyword is an issue. In this case, Partial Match may provide multiple keyword combinations, with one or two keywords removed, each showing a small sample of items that would result from dropping the keyword(s). Usually these groups of results are sorted by the number of results retrieved from the query, highest first.

On a mobile device, Partial Match can also be effectively combined with the Local Results pattern, as shown in the "Pet Shop Application" section of "9.6 Pattern: Local Results."

Pet Shop Application

The complete implementation with the Local Results pattern is described in the "Pet Shop Application" section of "9.6 Pattern: Local Results."

Tablet Apps

Partial Match applies to tablets the same way as it does to mobile apps. Tablets have larger keyboards, thus the number of keywords per query is anecdotally similar to the number of keywords in desktop web applications. Therefore, the importance of Partial Match as a recovery mechanism is much higher. Simply showing a No Results Found message, as the Amazon.com app does (refer to Figure 9-6) is not resourceful. Besides, the No Results Found words would look so lonely on a giant tablet screen! Be sure to augment your tablet zero-results screen with one or more recovery strategies in this chapter.

Caution

None

Related Patterns

9.6 Pattern: Local Results

When implementing missing results recovery on the mobile, take advantage of the local inventory of the results that can be retrieved using the on-board GPS.

How It Works

When a zero-results condition occurs, the system delivers some local results based on a partial match query or by providing a set of featured local results.

Example

The Target app store finder provides a simple example of the Local Results pattern. When the app first loads, it takes into account the customer’s location via the on-board GPS. This location is used to display a map of nearby store locations even before the customer enters anything. This is a logical implementation because it is a safe assumption that 90 percent or more of use cases would find a local store. However, the app also provides a keyword search (presumably based on city name).

If the keyword entry cannot be successfully resolved into a city name, the app pops up an alert that requires tapping OK to dismiss it, which is an antipattern (refer to "9.2 Antipattern: Lack of Interface Efficiency"). However, after the dialog is dismissed, the apparent missing results “recovery” works well; the customer sees the local store results loaded in the previous step (see Figure 9-7).

When and Where to Use It

Mobile queries tend to be local. That’s not the only use case, of course, but it’s a common one. In the absence of clues from the customer as to the records the system needs to look for, or when executing a Partial Match pattern (refer to "9.5 Pattern: Partial Match") local results make an excellent bet.

Why Use It

When implementing zero-results screens, it is not enough to just avoid the antipatterns. The best mobile experiences are “designed from zero”—that is, the prevention and recovery from zero results goes to the core of the way the search is implemented. Zero-results recovery based on the person’s location determined via the built-in GPS is a true mobile feature not available on the desktop. Thus it constitutes a pure case of mobile-first advantage.

Other Uses

Local Results constitutes the “basic view” of the Parallel Architecture pattern (read more in Chapter 8, “Sorting and Filtering”) and is the default search for most travel, reviews, and local shopping apps. Many of the excellent travel apps like Booking.com (see Figure 9-8) offer local results as a default browse tab—this one is labeled Around Me.

Pet Shop Application

This is the moment you’ve been waiting for: Figure 9-9 shows all the missing and unwanted results recovery patterns (Did You Mean?, Partial Match, and Local Results) in one example running a query for “Russian Mastiff.”

First on the page is the clear indicator that zero results have been found. Next are several Did You Mean? suggestions, derived from the popular keywords available on the site. Finally, because one of the keywords is correct and recognizable (“Mastiff”), the system performs a partial match, removing the problem keyword (“Russian”) and redoing the search with the additional local component. This is a safe, useful, and resourceful assumption; most people like to buy their pets locally.

Sure enough, there are seven local “Mastiff” results to choose from, and a small sample displays on the screen so the customer has a good idea what these dogs actually look like. The customer can scan the results using the carousel or tap the 7 Matches Near You For link to redo the search with the keyword “Mastiff” and the location set to within a reasonable radius around the current GPS coordinates of the mobile device. With all three strategies working together, an excellent missing results recovery screen was created to rival that of the mighty Amazon.com mobile site! Recall how important this screen is to the success of people using your app, and spend a little extra time and care to make it work well for your customers.

Last but not least, I used a little Pet Shop humor (“Bow-wow!”) to indicate zero results. This is highly recommended for most apps (other than Financials—refer to Chapter 12) as long as it is not the same funny line repeated over and over—that gets obnoxious in a hurry. (Recall the timeless scene from the first Jurassic Park in which the security system keeps saying “Uh uh uh! You didn’t say the magic word!” over and over) Instead, have a few different well-chosen “wisecracks” picked at random to facilitate the missing results recovery.

Wisecracks are something at which Apple’s Siri excels. Unfortunately, humor is where Android apps often come up short. Most Android apps still treat missing results as errors. Recall earlier in this chapter that mangled input is a natural and expected outcome of using a mobile device. Humor can be a wonderful tool to keep the search conversation going, despite momentary hiccups in human-mobile communication. And that’s the important thing!

Tablet Apps

Although G3 and G4 tablets can both get a precise location, many tablets are purchased to run on Wi-Fi only and have no wireless connectivity. This makes obtaining a precise location of the device a problem. Tablets, especially large ones, are also less likely to be used in a local context (for example, navigating to a local Target store). Keep that in mind and rely on other recovery mechanisms such as Did You Mean? and Partial Match for tablets making local results available only if they can be obtained and make sense in the context of your app.

Caution

See the preceding “Tablet Apps” section for this pattern.

Related Patterns