Design Patterns: Faceted Navigation

We are pleased to present an excerpt from Chapter 4 of Search Patterns by Peter Morville and Jeffery Callender (O’Reilly, 2010). —Ed.

Faceted Navigation#section2

Also called guided navigation and faceted search, the faceted navigation model leverages metadata fields and values to provide users with visible options for clarifying and refining queries. Faceted navigation is arguably the most significant search innovation of the past decade.^[2] It features an integrated, incremental search and browse experience that lets users begin with a classic keyword search and then scan a list of results. It also serves up a custom map (usually to the left of results) that provides insights into the content and its organization and offers a variety of useful next steps. That’s where faceted navigation proves its power. In keeping with the principles of progressive disclosure and incremental construction, users can formulate the equivalent of a sophisticated Boolean query by taking a series of small, simple steps. Faceted navigation addresses the universal need to narrow. Consequently, this pattern has become nearly ubiquitous in e-commerce, given the availability of structured metadata and the clear business value of improving product findability. Faceted navigation is being deployed rapidly across an impressively wide variety of contexts and platforms. In the world of search, faceted navigation is everywhere.

Figure 4-19 illustrates a successful implementation of faceted navigation as a model for interacting with the catalogs of several academic libraries. This is a good example of a federated search in which source (roughly equivalent to location) is deemphasized relative to subject and format. The consortium’s goal is to connect students and faculty with the best materials, regardless of which university owns them. This example also hints at the design challenges. Faceted navigation is not simply a feature to check off a list. Success requires painstaking attention to detail and an appreciation for the vast array of possibilities for interaction design. For instance, the libraries run collapsible facets down the left. Only the most relevant facets (subject, format, location) are open. Most are closed by default. Each open facet reveals only the top four or five most heavily populated values. This allows for a small facet footprint that frees up plenty of space on the main stage for the results themselves. The number of matching results for each value (shown within parentheses) is a key element of the map, as is the reformulation of search terms and selected values as stacking breadcrumbs, which let users view and modify their current search parameters. This interface is the result of user research, usability testing, and iterative design. But it’s not the only way.

[2] Marti Hearst and her Flamenco project collaborators at UC Berkeley deserve credit for their pioneering research in faceted navigation (http://flamenco.berkeley.edu/).

Fig. 4.19 Faceted navigation at the Triangle Research Libraries

For instance, applications rely on a mix of scented widgets for viewing and interacting with facet values, and some shift facet selectors to the top or right rather than the left.

Fig. 4.20 A variety of scented widgets

Presenting facets along the top draws added attention to the narrowing facility. Given massive result sets, this is an effective way to highlight the data structure and draw users into filtering. Top placement may sometimes obscure results and cause clutter, but can work well with image collections like Artist Rising (Figure 4-21) or when only a few facets are needed. It’s often useful to allow for flexibility in the number of facets displayed. As shown in Figure 4-22, adaptive facets let controls conform to the content as users shift between categories and drill down within collections. This may be a reason to avoid facets on top. While less visible, facets on the right can work, too, assuming they appear to be controls rather than ads and don’t get cut off by narrow browsers. When in doubt, lean toward the de facto standard (left side) and subject different designs to user research and testing.

Fig. 4.21 Faceted navigation puts metadata on the map

Fig. 4.22 Amazon’s adaptive facets

In contrast to the relatively mature design space of the desktop Web, mobile is a platform where standards for faceted navigation have yet to emerge. A few research projects such as FaThumb^[3] have explored the challenges and possibilities of facet-based interfaces for mobile search. Clearly, tiny screens preclude the established model. There’s insufficient space to present facets and values alongside results. Ever the pioneer, Amazon is among the first to design a mainstream application that adds faceted navigation to mobile search. As Figure 4-23 shows, it features an iterative model that requires more steps than ideal, but it’s a move in the right direction. As mobile search crosses the chasm, users will expect the features and functions to which they’ve become accustomed on the desktop, and first and foremost outside of the box, they will absolutely, positively need to narrow.

[3] A facet-based interface for mobile search. Available at http://research.microsoft.com/apps/pubs/default.aspx?id=64303.

Fig. 4.23 Faceted navigation on Amazon mobile

Across all platforms, there are some qualifications and questions worth review. First, we’ve been using the term “faceted navigation” rather loosely. Formal definitions of facets may exclude simple fields and filters, but discrimination is unwarranted in practice, provided that filters operate independently and users can add or remove them in arbitrary order in concert with the updating of results.

On the other hand, the distinction between faceted navigation and parametric search is relevant. In parametric search applications, users specify their search parameters up front using a variety of controls such as checkboxes, pull-downs, and sliders to construct what effectively is an advanced Boolean query. Unfortunately, it’s hard for users to set several parameters at once, especially since many combinations will produce zero results.

Today, it’s rare to see pure parametric search, but many applications lean closer to that end of the spectrum than they should. For example, Snooth fails to indicate the number of matching results until after users execute a refined search. The widgets are decidedly unscented and the interface encourages users to modify multiple parameters before query execution. It’s a solution that’s hard on people but soft on hardware. In other words, it’s an unfortunate compromise that sacrifices immediate response to reduce the server load.

Fig. 4.24 Parametric problems at Snooth

At the other extreme, live search applications like Volkswagen UK (Figure 4-25) and Kayak (Figure 4-26) update results dynamically with no submit button and no page refresh. There are some real advantages to this dynamic model, which allows for immediate response, minimal disruption, and elegant transitions. But there are also costs. The Volkswagen UK application takes time to load, and Kayak must use a conspicuous (and somewhat awkward) overlay to call attention to the updated results. Live search applications are like dangerously quiet hybrid vehicles. When the noise disappears, we find it had value. Elegant transitions can reintroduce some useful disruption, but in cases where both results and facets change simultaneously, this becomes a bit tricky.

Fig. 4.25 Immediate response at Volkswagen UK

Fig. 4.26 Live search at Kayak

Of course, as design and technology evolve in concert, we will solve these problems even as new challenges arise. Processors grow faster; people don’t. So, we’ll need to carefully manage transitions. Meanwhile, faceted navigation will surely adapt to every context and platform because the need to narrow exists at the crossroads of behavior and the box.

Faceted Navigation#section3

Fig. 4.27 The faceted navigation design pattern

Faceted navigation is a master pattern. Its deployment impacts all other search patterns and the information architecture as a whole. To oversimplify, there’s the Google model and the faceted navigation model. Choosing between these two is a major strategic decision. Determining whether or not faceted navigation is sensible and feasible is among the earliest steps in design. The infrastructure for faceted navigation can enable a tighter relationship between search and browse. It can shape the structure and navigation of the entire site or application. It also changes how we think about autocomplete and best first. It offers a familiar framework for managing the sources of federated search. Plus, its discriminatory power to clarify intent and refine results may offset the need for personalization and advanced search. That said, faceted navigation won’t work everywhere. For starters, it’s an expensive proposition. The demands on search software and servers are substantial. Also, the metadata infrastructure involves both initial investment and ongoing expense. For these reasons and more, a simpler search model is sometimes better, but it must often be supplemented by advanced search.

Fig. 4.28 Advanced search at Genentech

Advanced Search #section4

A relative concept, advanced search includes whatever simple search doesn’t. It’s a pattern that many of us love to hate. Often, advanced search is a clumsy add-on that’s rarely used, and it lets engineers and designers take the easy way out. Valuable features that are difficult to integrate into the main interface can be relocated to the ghetto and forgotten. Plus, there’s confusion about its purpose. Is it a user-friendly query builder for novices or a power tool for experts? Many interfaces try (and fail) to be both. For instance, isn’t it fair to assume that users who understand what “exact phrase” means also know to use quotation marks to specify such a search? The main problem with Boolean isn’t the syntax, it’s the logic. And even the plain language shown in Figure 4-28 is unlikely to help the few novices who brave the intimidating realm of advanced search.