Chapter 8

Sorting and Filtering

After your customers get the information scent that lets them know they are on the right track to finding what they need, the next step is to help them winnow down the avalanche of data to the size manageable in the mobile context of use. That’s where the sorting and filtering design patterns in this chapter prove invaluable. Many of the so-called Experimental Patterns, such as Sliders with Histogram (Chapter 10, “Data Entry”) and Filter Accelerators (Chapter 11, “Forms”) can also be used for sorting and filtering, so be sure to also check out relevant sections in those chapters.

8.1 Antipattern: Crippled Refinement

Before talking about refinement patterns, let me make something very clear: Mobile web should be as good as desktop web, or better. Crippled Refinement is a fundamental UX antipattern to be avoided at all costs.

When and Where It Shows Up

Whenever there is an option to filter and sort mobile or tablet search results, there is a great temptation to “dumb down” the interface to only one or two refinement options. Additionally, mobile interfaces that limit search refinement to a single step fundamentally cripple the flow of search experience, which proceeds via multiple consecutive refinement steps.

Example

Although it is overall a highly successful and lucrative mobile app, Amazon provides the example of a dumbed-down filtering process.

Just compare the only refinement option, Department (see Figure 8-1), available in the mobile app to the multitude of filters and sort options available for the same “Harry Potter” query in a desktop browser, as shown in Figure 8-2.

The mobile app seems rather seriously deficient, doesn’t it? But the real, more insidious UX problem is deeper still. Typical search flow involves multiple steps of refinement and changes, with each step directly informing what the customer will do next. Because the Amazon mobile app refinement is designed to be only a single-step operation, the interface does not support any changes to the original keyword query. Actually, any changes to the query reset the entire search (see Figure 8-3).

Referring to the sequence of steps pictured in Figure 8-3, the searcher started the search broadly, by searching for Harry Potter. Remembering that his niece wanted a DVD, he picks a category Movies & TV. Viewing the items in the search results, the searcher realizes that he wanted to see all the buying options for the first movie, Harry Potter and the Sorcerer’s Stone, so he taps the Menu button and selects Search once more, updating the keyword query to include the full name, Harry Potter and the Sorcerer’s Stone. At this point, the searcher unexpectedly finds his category reset back to All Departments—his refinements gone, his discovery flow interrupted.

The best mobile interfaces support multistep refinements, allowing the customers to do more, not less, than the desktop interface.

Why Avoid It

Edward Tufte (the “Da Vinci of Data”) famously quipped, “Clarity and simplicity are completely opposite of simple-mindedness.” Nowhere is this adage more true than in mobile and tablet design. Mobile and tablet apps must support most if not all the desktop web filters and make available what you know to be a multistep refinement finding flow.

If you decide to provide less functionality simply because you think it is too much to handle for mobile customers, think again. Experience with crippled apps such as the early version of Facebook clearly shows that people want to do more with mobile apps, not less. Instead of dumbing down, think of the way to provide filtering and sorting functionality that works with the on-board sensors and device limitations.

The key to great mobile design is not really having customers doing more (that is more work), but getting more: more capabilities, more value out of the experience. Well-designed mobile interfaces actually enable people to do less work because you can leverage other sensor data to infer more of the customer’s context. You could say people want more or expect more from their mobile device, which means they want to do less. The key is context and real human desires, not doing more or less because of some abstract principle. Use the patterns in the rest of this chapter as a guide and be sure to test early and often with your target customers.

Related Patterns

8.2 Pattern: Refinement Page

Search results enable access to sort and filter options on a separate page or lightbox.

How It Works

When the customer wants to refine the query, he can access a dedicated page or a lightbox with filter and sort options, followed by some sort of a “go” button to re-initiate the now refined search. Optionally, the set of refinements applied to the search might be shown to the customer with a Filter Stripdesign pattern. (Filter Strip is covered next, in section 8.3.)

Example

One excellent example of a full-featured mobile refinement is the eBay app. (See Figure 8-4.)

Despite apparent complexity, this remains one of the most useful and profitable mobile apps, with several billion mobile e-commerce dollars generated as of the date of this writing. One reason for its success is that designers refused to dumb down the experience and have instead done an excellent job managing complexity: The app provides a full-featured eBay search experience in a tiny mobile device.

This app makes an excellent example because it shows off some uncommon but useful refinements, including

• Multiple select check boxes (Free Shipping, US-only) as shown in Figure 8-5

• Multistep drill-down refinement (Refine > Category > Sporting Goods) with additional subcategories (see Figure 8-6)

• Sort on the same refinement page as search (Best Match and so on) as shown in Figure 8-4

But the eBay app not only offers full-featured refinements, but also actually does more than the desktop web version—for example, offering refinement by distance from the current location without having to enter the ZIP code (see Figure 8-8).

When and Where to Use It

Any time you have a faceted search or there is a use case for changing the sort order, the Refinement Page pattern is an excellent tool for the job.

Why Use It

Refinement is an essential part of search, especially on the mobile device where typing avoidance generally gives rise to shorter, more general queries, which need to be refined quickly and efficiently.

Other Uses

Some of the best implementations of the Refinement Pagepattern are not pages at all. They are Refinement Page lightboxes (also somewhat loosely called pop-ups). Early Android phones simply did not have sufficient real estate to implement refinement in a lightbox that could still be operated with fat fingers, and the iPhone’s smaller size still prevents iOS designers from doing this effectively in most cases. However, today’s higher-end Android devices have a decent-size screen, which means multiple refinement options can be displayed in a lightbox, as shown in Figure 8-9, demonstrating the excellent Yelp refinement example.

Why is there a distinction between lightboxes and dedicated pages? The reason has to do with maintaining flow within the current task. As discussed in greater detail in Chapter 13, “Navigation,”immersive UIs (of which Refinement Page Lightbox is a good example) maintain the illusion of staying on the same page and within the same task, whereas separate pages appear to switch the task from one interacting with the content to that of refinement. Separate pages yank the person out of the search results and place her in a different environment. If you can accomplish your refinement tasks using a lightbox without sacrificing functionality, it almost always creates a better experience.

Pet Shop Application

Either the dedicated refinement page or lightbox refinement could be usable for the faceted refinement and sorting in the Pet Shop app. What makes the design of the refinement functionality even better is the addition of the Filter Strip pattern. In the next section, the entire package is wireframed together using the agile sticky notes methodology.

Tablet Apps

Refinements are important for tablets. Tablets have more surface area, which exposes more inventory to the customer and presumably causes them to make the decision to refine even sooner. Tablet owners also presumably care more about flow than the mobile users, and tablet search tasks last on average longer than similarly structured mobile tasks. Together these factors clearly dictate that the tablet refinements need to be as full-featured as web refinements, plus provide the refinements that are only available on touch devices (such as using the GPS locator feature for distance filtering).

Because tablets have more surface area, most refinements should be done via lightboxes, not dedicated refinement pages. Remember to place the lightbox in the correct ergonomic position where the controls can be manipulated easily in both portrait and landscape orientations. In the absence of specific use information, the best place is typically on the top-right corner of the screen, where inputs in the lightbox can be manipulated with the right thumb without the user having to let go of the device completely or while using a typical two-handed grip with the bottom of the tablet resting on the user’s lap or a table (see Chapter 3, “Android Fragmentation”).

Caution

With the increase in screen size, there is a strong trend in many apps, such as Kayak, to have separate filtering and searching controls (large buttons on the bottom of the screen), as shown in Figure 8-10.

This is a mistake. As described in Designing Search: UX Strategies for Ecommerce Success (Wiley, 2011, ISBN: 978-0-470-94223-9), my original research shows that most people have trouble differentiating sorting from filtering. Furthermore, this distinction is not nearly as important as most designers and engineers think. Consider that most people will never see more than the first 100 to 300 items of a typical result set, especially on a mobile device. In other words, people can never hope to view anything but a tiny fraction of today’s typical high-volume result set numbering in the thousands. The result is The Mystery of Filtering by Sorting. In many people’s minds they filter out high-price items when they sort by Price: Lowest First, because they can never go through the entire result set to view the high-price items at the bottom of the list. Thus the action of sorting creates an inherent filtering effect due the large number of items in the set.

On mobile devices with limited screen real estate, filtering and sorting options are often placed on the same refinement page or lightbox. (Both the Yelp and eBay apps do this.) This is a great trend that should be encouraged because it matches well with the user’s mental model of these controls, which are both seen by customers as types of “refinement.” Furthermore, as I explain in my first book, sorting controls should often be shown first and called out especially because sorting often creates a much better refinement of the result set: It never causes zero results; its outcome is predictable; and it’s hard to screw it up. So, in short, you should consider combining filtering and sorting under a single Refine Area, unless there is a good reason to do otherwise, and make refinement as much of an integral part of finding, in general, as possible

Last but not least, faceted filtering cannot strictly be considered being faceted without letting the customer know the numbers of items that will result when the facets or filters are applied. Numbers of items associated with refinements let customers know how to proceed. Unfortunately, knowing numbers of items is particularly hard to do with multiple refinements being applied in a single shot using check boxes, as they are in the eBay and Yelp apps. By default, this creates a refinement experience that is inferior to that of using a desktop web browser. In your apps, if at all possible, try to indicate the outcomes of user refinement actions, including how many items will be left over after the filter is applied in order to avoid zero-results outcomes.

Related Patterns

8.3 Pattern: Filter Strip

A small horizontal section of the screen shows the keyword query and the filters applied.

How It Works

After the search is run, the entire contents of the query are shown to the searcher in a thin Filter Strip. Any changes to the query (such as filters applied, sort order, and so on) are continuously reflected in the Filter Strip that acts as an informational display to show the searcher the details of the exact query he applied to his search.

Example

Yelp is a good example of this pattern. Because the Yelp app is an example of the Dedicated Search pattern (read more in Chapter 7, “Search”), showing the keyword query again is not necessary. Instead, Filter Strip (see Figure 8-11) shows up only when additional refinements (filters and sort order) are applied to the search.

Note that the Filter Striptext is small and that it wraps around in the rare cases in which this is warranted by the number of refinements applied.

When and Where to Use It

Any time a set of filters or sort refinements can be applied to a query, consideration of the Filter Strip pattern is warranted, regardless of whether the search box is a dedicated one (as it is in Yelp) or if search is initiated in some different manner as discussed in Chapter 7.

Why Use It

Knowing “where you are” is a continuous challenge in mobile space with its small screen and constant interruptions. Having a solid reliable way to communicate all the search parameters to the searcher enables him to adjust search parameters, sort order, and refinements until the query results are satisfactory. The Filter Strip pattern enables designers to effectively accomplish this in an unobtrusive way that takes up only a fraction of the screen real estate.

Other Uses

Filter Stripin its best implementation is semi-transparent, as shown in the iOS Yelp app in Figure 8-12.

In contrast, the majority of Android implementations of the Filter Strip are solid. This is a mistake. Making the Filter Strip semi-transparent enables the searcher to read the search results while also seeing the query clearly, especially while scrolling the page. If the Filter Strip is semi-transparent, the focus shifts from the process of search and refining to what is most important to the searcher: search results content. Furthermore, the screen space is used efficiently—not a pixel is wasted. This is important for immersion as discussed in more detail in Chapter 13. For now, suffice it to say that successful games such as Angry Birds use semi-transparent controls frequently, and you should consider the lessons from the games to improve the effectiveness of the search experience in your own app, while balancing immersion with competing UX concern of legibility and perceptual noise.

Pet Shop Application

Filter Strip is perfect for the Pet Shop search because of the many refinements that can be applied. The example of the complete search refinement and filter strip package (first introduced in the discussion of the Refinement Page pattern earlier in this chapter) is wireframed, as shown in Figure 8-13, including a semi-transparent Filter Stripthat appears after the refinements have been applied.

Several unusual refinements are used, such as a dual slider with histogram to filter by price. To learn more about this Slider experimental design pattern, head over to section 10.1. Also note that the lightbox comes out of and is connected to the Filter button—this is deliberate because it projects a strong perception of the app’s Information Architecture (IA) through intuitive visual means. Maintaining this connection clearly states, “This lightbox is the contents of the Filter expanded.” Having the lightbox connected with the element from which it originated also dispenses with the need for a dual Go and Cancel button arrangement in the lightbox, as shown in Yelp. Instead, to exit the lightbox, the searcher needs to tap only the Filter button again to collapse the lightbox. This design greatly decreases any accidental fat-finger taps on the Cancel button and increases “fool-proofness” and satisfaction. Use the custom Expand and Collapse animation effect (where the lightbox literally “grows out” of the Filter button) for the open lightbox transition to further support the sense of place and provide added visual slickness.

Last, but not least, note that the Filter Strip reports that the price has been applied as “around $100”; this is deliberate. The additional precision that is so important for computers carries little meaning for human beings, so it pays to shorten the numeric filter settings to human-scale formats such as “around $100,” especially on mobile devices and tablets. For more on this, see Chapter 8 of my book Designing Search: UX Strategies for Ecommerce Success (Wiley, 2011, ISBN: 978-0-470-94223-9)

Tablet Apps

Filter strip is just as important for tablets. You do not need to use as small a font as is typical for the mobile devices because tablets have more space and are meant to be read comfortably at a longer distance from the eye. Transparency of the Filter Strip element is also less of an issue; although it's still recommended, especially if the search results are more visual in nature, such as large pictures. You want as little as possible to detract from the content, and semi-transparency of the filter strip helps it “disappear,” which encourages immersive flow interaction with the content.

Caution

Use text that is as small as possible, but don't lose legibility. To do this effectively, avoid temptation to use the Filter Strip as a clickable object or button, unless it is at the very top or very bottom of the screen. The main purpose of the Filter Strip in most cases is to provide information while remaining unobtrusive; it's not to be clicked.

Related Patterns

8.4 Pattern: Parallel Architecture

“Basic” and “advanced” search screens form two parallel tracks to search results.

How It Works

Results can be accessed in two ways: via simple search and via advanced “more options” search. Tapping the back button navigates to the original search starting screen and enables searchers to switch mode. There may also be a separate “refine” button on the search results screen that enables the searcher to enter the advanced mode.

Example

Yelp forms an excellent example of this pattern. If the searcher is simply looking for a place to grab a cup of coffee, she can easily tap “Coffee” on the home screen and see the nearest places to get caffeinated. However, if the searcher is adamant that she wants the best, she can take the time to type in “Peet’s Coffee” into the search bar, mixing a few more constraints into her coffee cup (see Figure 8-14).

When and Where to Use It

Use the Parallel Architecture pattern whenever search conditions might be served better through minimal search input or browsing, while at the same time there exists a common use case for more advanced, full-featured search.

Why Use It

The classic mobile use case for this pattern is local. Whenever there is a strong local component, consider using this powerful and intuitive “mobile-first” pattern. Using this pattern requires little mastery of the app or subject matter and makes it easy to engage with your content right away, while providing people who want something specific with a powerful set of tools to refine and customize their queries.

Other Uses

Local is not the only use case for basic versus advanced search. You can argue that apps such as Facebook and Twitter also follow this pattern with the recent updates you can browse without typing, while also providing a feature to search the updates. However, one important requirement for this pattern is to present both basic and advanced search results in mostly the same way (maybe with additional keyword highlighting for the keyword search versus browse). Otherwise, you have a separate search functionality.

Pet Shop Application

Simple browsing is not the only way to start basic search. Using the ThirstyPocket Labs iPhone app as a model, you can see how easy it would be to provide multiple levels of engagement in the Pet Shop app. The wireframes in Figure 8-15 provide two screens: Home and Advanced Search, which I took the liberty of renaming to More Search Options because my research showed that label to be less intimidating.

From the home screen, the searcher has several simple engagement options:

• Browse pets for sale in her neighborhood by tapping the Nearest Pets button (sorted by nearest first).
• Browse the newest pets on the market in a reasonable driving radius of 50 miles using the Newest Pets button (sorted by newest first).
• Browse pets by category (sorted by nearest first or newest first, depending on which search button is tapped).
• Combine category and keyword search (sorted by nearest first or newest first, depending on which button is tapped).

And by tapping More Search Options, the customer can engage with a dedicated page that has a variety of additional filters such as price and distance, for those customers that use their mobile device to search for pets from a different location than their home (while they are at work, for example) or have special needs and budget constraints not covered by the “basic” home search screen.

Another thing to note in the design in Figure 8-15 is the addition of a tappable semi-transparent action bar above the search results. The action bar includes Filter Stripreporting functionality, yet also provides a single-function back button. Because this action bar is semi-transparent, it does not take any screen space away from the search results, which occupy 100% of the screen. More discussion on screen real estate use in games and other immersive experiences is in Chapter 13.

Tablet Apps

Although local is not as big a deal for tablets as it is on smaller mobile devices, simple “browse” engagement that enables people to dive straight into the featured content without having to enter anything is arguably even more important for tablet than it is on mobile. This means that the Parallel Architecture pattern is an excellent option for tablets. Consider just one simple example of reading News: In the “basic” view the person can explore the latest news or news by topic. In the "advanced" view, she can search by keyword, category, publication, and date range to drill down further into a particular topic of interest.

Caution

Although the Parallel Architecturepattern appears to be simple and versatile, apparently there exists nearly endless opportunities to mess it up. One popular way to use Parallel Architecture is to add another Search from the Menu search box to the application that already has a basic and advanced search, creating a completely different UI for viewing and refining the same data. One unfortunate victim of this is the TripAdvisor app, which appears to be confused about the goals of its customers and its IA.

As you can see from Figure 8-16, there appear to be multiple ways to access and refine essentially the same content, which makes a simple task of finding a local hotel a Herculean Labor comparable to cleaning the famous Augean Stables.

Problems begin on the home screen. Tapping a hotels icon takes the searcher to what would appear to be a “basic” search screen of the Parallel Architecture pattern. However, instead of making the local search a default (as they should almost always be in any mobile travel app) TripAdvisor has added the Local Search option as a small check box. The check box control is both hard to find and hard to tap with the finger.

The second way to access the same content is with a Search from action bar search icon. (See Figure 8-17.) This search appears to be tacked on as an afterthought, making the results of even the simplest queries like “Hotel” initiated from the search box perfectly useless. The filter pop-up is not designed to be of any help, offering only a few meager and confusing options (which do not even appear to be working as of the date of this writing). Also unexpectedly missing on the resulting search results page are the three tabs on top of the other set of search results. Instead the tabs appear as options in the filter pop-up; although they are named differently (Restaurants” versus “Eat”, “Things to do” versus “See”, and so on) and sport icons visually distinct from the set seen in all other search results. The filter pop-up also adds the fourth option, “Locations,” adding to the general confusion.

But that’s not all. There exists yet another way to access content: via the menu’s Near Me Now option. (See Figure 8-18.) This browse function at first glance holds the most promise, yet it is nearly impossible to find. When tapped, Near Me Now unexpectedly catapults the searcher into the second search results tab called “Eat” (regardless of the previous searches that were all for hotels.)

The designers of the TripAdvisor app probably didn’t aim to create this gargantuan mess. The confusing IA may have come about as a result of responding to the criticism of “people can’t find our stuff” via a knee-jerk reaction of adding multiple, and ultimately confusing, ways to find the same content.

In your own app design, use the patterns in this book as a guide, but realize you will never please everyone. When the inevitable criticism comes in, rather than adding more features, maintain a clear vision of supporting your primary use cases while continuously doing field research to figure out where your best customers are getting stuck. Knowing the facts on the ground will give you ammunition to defend your design decisions and confidence to stick to your vision.

Related Patterns

8.5 Pattern: Tabs

Tabs on top of the page enable customers to switch views or apply popular sort and filter options.

How It Works

When the search results are shown to the customer, the results are further segregated into two or more views shown as tabs on top of the page. The first tab is usually the default result. Tapping one of the other tabs switches to a different view of the data. For example, tabs can be used to toggle between list, gallery, and map views of the same set of results.

Example

Wikitude is an app that uses the tabs design pattern to switch between views. Wikitude recently redesigned the app for Android 4.0 OS (see Figure 8-19).

Tabs are shown as miniature icons. The tabs look considerably more sophisticated and visually polished than the older version (shown in Figure 8-20) and 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 understand what they mean. As you can see the 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 more useful List and Map views.

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

Interestingly, the older version of the Wikitude app used tabs that looked very different. The difference between this new version of Wikitude and the older version of the app shown in Figure 8-20 is germane to this discussion.

You can probably agree that the new visual design of the Wikitude app is an improvement over the previous version because it features slicker graphics. Tabs in the older version featured clunky icons and non-English text, and it took up a great deal of screen real estate. However, the older version was superior from the standpoint of learnability and usability. The default tab was List, followed by Map, and finally the Camera or AR tabs. This likely matches the typical use pattern of the tabs, which is an important plus. Another huge plus is that the active tab was visible and highlighted. This made understanding the app’s IA a trivial task that could be taken for granted.

With plenty of space available for all three miniature icons, the designers could have easily incorporated the active tab and shown it next to two other tabs using a variation of the Android’s “underline” treatment, as shown in the proposed wireframe in Figure 8-21.

You’ll probably agree that starting with the list view and using the blue underline treatment to make the “you are here” tab obvious makes the app useful and usable.

When and Where to Use It

Tabs are appropriate when the same data can be viewed in different ways, most commonly in a list or map, and the viewer needs to switch rapidly between the different views.

Tabs are also appropriate when the inventory can be segmented into various sort and filter buckets.

Why Use It

Tabs are easy to discover and are intuitive to use. Tabs borrow freely from the real world metaphor and represent an easy way to understand the contents of a collection or available view options.

Other Uses

Views do not necessarily refer to different representations of the data. Tabbed views can also be used to apply sophisticated combinations of filtering and sorting parameters to the same set of data and provide convenient entry points into vast, complex collections of items that cannot be searched easily. The classic example of this application of the Tabs pattern comes from the Google Play app (see Figure 8-22).

Here the customer uses tabs to switch between Categories, Featured, Top Paid, Top Free, and so on. In the Play Store, tabsprovide convenient self-explanatory entry points into a vast collection of apps by reducing the complexity into an interesting and quite manageable list of three visible categories of top results. These three lists are updated quite often and provide intrinsic entertainment value (think water cooler gossip such as “Guess what free app is most popular today?”), which make these tabs one of the most popular destinations on the Android platform. Google Play app offers an example of the scrolling tabs: allowing the customer to browse more than just the three tabs that can be seen on the screen at one time, by tapping on the partially hidden tab or via horizontal swiping. Although this method can show more than can be seen in the single screen view, this kind of display is also limited to a manageable size of 8 to 10 tabs; otherwise, swiping fatigue sets in and it becomes hard to discover all the various tab options.

Pet Shop Application

Tabs are versatile. In the Pet Shop app, you can use tabs to show different views of the search results—for example, List, Gallery, and Map views. (See Figure 8-23.)

But you can also use tabs to show two different ways to sort the results: Nearest, Newest, and Cheapest (see Figure 8-24).

Which one should you use? As with any other design pattern, the answer is “It depends.” That is, it depends on what fits best with what your customers are trying to do and what brings in the most business.

Tablet Apps

Tabs are fantastic for tablets and are vastly underused. Tablets have a lot more real estate, so the limit of only three tabs across the screen does not apply. Also, side-swiping the active tab to get to different views does not make sense. Instead, all 8 to 10 tabs can be freely shown to the viewer at the same time, as they are in the desktop web model.

You can even envision an effective Responsive Design of tabs: On larger tablets, the viewer sees all the 8 or 10 tabs. On mid-size tablets, the viewer sees 4 or 5 tabs, which can be scrolled left to right independently of the content. Finally, on mobile phones with the smallest screens, only three tabs are shown (that is the active tab is displayed fully with the other tabs shown as partially fading from view—refer to Figure 8-22 to see the tabs in the Google Play app).

Caution

On small mobile devices, tabs take up precious screen real estate and therefore must be used with caution. Tabs don’t need to have heavy visual elements, but reducing text into icons places the additional discovery burden on the customer. (Remember the Wikitude example from earlier in the chapter.) Typically, make tabs only as tall as needed to place the labeling text or small icon and enable accurate taps. However, no matter how small you make the tabs, they still need to be large enough to be tapped accurately. This means that even on the larger mobile phones, you can place only a maximum of four or five tabs across the row.

If you decide to use custom tabs, be sure to test them for usability with your target customers. The biggest issue is that people often do not understand which tab is “on.” (This is a common problem when there are only two tabs but usually not a problem when there are three or more tabs.)

If there are only two tabs, or if viewers do not switch tabs often, a good alternative is a dedicated button to switch to a different view. A good example of this pattern is the Yelp app shown in Figure 8-25.

By providing a Map button instead of a tabbed view like Wikitude, Yelp removes the need to provide the tab bar and is free to devote full-screen real estate to the map view, which greatly improves the map view functionality and helps to create a more immersive experience (more on immersive UX in Chapter 13).

Does your customer actually need all those views on the same IA level? Maybe. Contrast Yelp with Wikitude: Although Yelp also has the AR function (called Yelp Monocle) and was the first app to introduce this feature, the Yelp Monocle AR view is deliberately separated from the List and Map views (see Figure 8-26).

This is a clear signal that Yelp’s designers do not place Monocle on the same IA level as the List and Map views, but instead invite the customer to engage with AR as an experiment or a diversion. In other words, AR is placed in a class by itself, away from the “working” List and Map views. Yelp offers a much more realistic and therefore more usable and less complicated implementation than the current Wikitude design that practically forces the viewer to engage with the AR as the first tab.

Related Patterns