Faceted search enables users to intuitively explore complex information spaces by progressively refining their choices in each dimension. When combined with keyword search, this approach becomes incredibly powerful: so much so that faceted search is now the dominant interaction paradigm for most eCommerce sites and is being applied to an increasingly diverse range of search and discovery applications.
However, with this power comes a challenge: given the ease with which information spaces can be explored, what techniques should be employed to communicate the user’s current location and navigation options within that space? And how should these mechanisms be extended to facilitate further exploration of that space? This post looks at some of the main techniques and reviews their strengths and weaknesses.
One of the simplest techniques by which navigational state is communicated is through the use of breadcrumbs. Breadcrumbs have a long history in the development of the web (and hypertext systems in general), and have been the subject of many previous research studies. In their simplest form they are rendered as a trail which indicates the user’s current position in an information hierarchy (or taxonomy), e.g.
Home page > Section page > Subsection page
But the whole point of faceted search is to allow navigation along several independent dimensions, rather than just one. So in this case, we need a mechanism that will scale to accommodate multiple dimensions.
Perhaps the simplest example of a technique to accommodate multiple simultaneous dimensions is the use of multiple ‘inline breadcrumbs’, as shown here on Amazon:
Looking closely at the faceted navigation menus, we can see that each one contains the current selection (e.g. Format=paperback, language=English etc.) and the means by which the user may remove the current selection for any given facet (e.g. Any Format, Any Language, etc.). Note the subtle use of bolding to indicate the currently selected facet value, the use of indentation to indicate hierarchy, and the use of chevrons to imply going “back” to a previous state.
However, there are two shortcomings with this design. First, it doesn’t scale well to results that possess a large number of facets whose combined vertical height extends beyond the current screen height. In such cases, a proportion of the facet menus (and their currently selected values) will be hidden below the fold or otherwise out of view, and therefore not concurrently visible (without vertical scrolling). To a degree, this is mitigated by the presence of the conventional breadcrumb trail displayed immediately above the search results, but the visibility of this is questionable, and the lack of inherent structure makes its informational content relatively difficult to parse or comprehend.
Secondly, and more importantly, is how this approach would scale to accommodate multi-select facets. In other words, how would conjunctive (AND) or disjunctive (OR) facet values be rendered and selected? Despite the evident elegance of the current design, it is hard to see an immediate solution to this issue that would not involve some degree of deviation from the simple inline approach.
An extension to the above approach is to maintain the principle of displaying current facet selections inline (i.e. within the facet menu itself), but allow the facet values to be multi-selectable. An example of this can be seen at eBay:
In this example, we can select multiple models (e.g. Golf OR Jetta) and multiple model years (2009 OR 2008 OR 2007) and these choices are displayed inline as selected checkboxes. Interestingly, the mechanism by which multiple values may be selected involves the use of a dialog overlay (see below), which presents all the facet values as an extended list of checkboxes:
Note how this overlay allows only one facet to be visible at any one time (in keeping with the principles we discussed in the previous post on Interaction Models for Faceted Search). Like Amazon, eBay also includes a conventional breadcrumb trail above the result, with what appears to be an even less structured treatment (bare facet values delimited by commas). Interestingly, eBay allows the user to close individual facets (presumably to optimise vertical screen space) but only if they have no current value selected. So in the above example, the user can only close the Fuel Type facet and the ones immediately below it. This principle, one suspects, may be specifically to minimise the likelihood of inadvertently hiding selected refinements from view.
Despite these useful modifications, the design still suffers from the same fundamental shortcoming as Amazon: in cases where a given result set possesses a large number of facets, their combined height may extend beyond the current screen height, making the overall navigation state difficult (if not impossible) to comprehend without repeated vertical scrolling.
For relatively simple B2C applications, such as the eCommerce examples above, perhaps this is a suitable compromise to make. In such cases, the principles of elegance and simplicity are likely to outweigh any requirement for scalability and visibility of navigational state. However, as mentioned earlier, the applications of faceted search are being extended to a growing range of information discovery challenges, including more complex applications in business intelligence and analytics. In such cases, the need for a more scalable approach that more effectively communicates navigational state becomes more significant. In the next section, we’ll look at some of the alternative solutions for addressing this.
The fundamental principle of the above designs is that they display the selected refinements in situ, i.e. inline within the facets themselves. And as we have seen, there are strengths and weaknesses with this approach. An alternative is to display all currently selected facet values in their own dedicated location or container. In the context of faceted search, this container is often referred to as a breadbox. An example of such a device can be seen at Food Network, in the container labelled “Your Selections”:
The advantage with this approach is that all of the currently selected refinements are shown grouped together in a single place, which remains visible in the same location no matter how many facets are present. The overall navigational context is therefore immediately visible without vertical scrolling. However, one consequence of this approach is that a different shortcoming now becomes apparent: what facets do these particular values apply to? For example, what facet led to the selection “recipe” or “main dish”? Since these values are no longer displayed in context, the user must either recall which facet was associated with each selected value or attempt to infer that from the labels themselves.
Again, for relatively simple eCommerce applications, this may be a minor issue: after all, most users could reasonably interpret the values in the breadbox above, even if the precise facets that gave rise to them are now absent. There are, however, other ways to address this issue. The example below from NCSU Libraries illustrates one such approach:
In this case, we see that the Breadbox contains not just the facet values, but the facet names too, i.e. Format=’online’, Subject=’natural language processing’ etc. The word wrapping in this particular example is somewhat unfortunate in that the controls to remove each refinement have wrapped as orphans in two cases, but the principle is clear: each facet value is unambiguously associated with its parent facet. Note also that this design scales easily to support multi-select facets (one of the key shortcomings of the inline breadcrumb design): the multiple selections for the ‘Subject’ facet are clearly visible and comprehensible in the above design.
In both the above examples, the breadbox is laid out vertically. But there are variations on this: in the example below, from University of Toronto Libraries, we see a similar navigational state laid out in a horizontal arrangement:
In this example, we see seven separate refinements laid out in sequence, complete with facet labels and removal controls. However, the comparison with the vertical breadbox makes one shortcoming of this approach quite evident: the content of the breadbox is much harder to comprehend, as the structural relationship between the facet/value pairs is now much less apparent.
Note, however, that in all the above examples we’ve assumed that the facets themselves are laid out using the vertical stack pattern. There are, of course, other configurations: notably open parametric, in which the facets are laid out in a consistent horizontal orientation, and displayed in their open state by default. In this configuration, the currently selected facet values are much more immediately visible, to the extent that a separate breadbox may not always be required.
In our discussion above, we have outlined two contrasting approaches to wayfinding in faceted search: breadcrumbs (in particular the inline version) and breadboxes. There are of course other variants, notably Greg Nudelman’s Integrated Faceted Breadcrumb. At first blush, Greg’s design seems quite radical, with the breadcrumb transformed into a flexible container that provides direct support for key navigational functions, such as updating facet values in situ; selecting a “See All” option to remove a refinement; etc. Greg also uses the IFB to argue in support of some key navigational principles such as explicit labelling of the facets (as discussed above), retention of the navigational context wherever possible; and so on.
But on closer analysis, it could be argued that many of these actions and principles are precisely those for which the inline breadcrumb approach has already been shown to work well, particularly the eBay incarnation with its support for complex navigational options such as multi-select AND and OR. So it remains to be seen whether the integrated faceted breadcrumb is the first of a new set of wayfinding techniques in faceted search, or whether it is essentially an exploration in the re-allocation of navigational functionality from one component (in this case, the facets) to another (the breadcrumb).
One of the great strengths of faceted search is the way it allows users to explore complex information spaces in a seamless and intuitive manner. But with that strength comes a challenge: what mechanisms should be employed to communicate the user’s current location and navigation options within that space? In this post we’ve examined some of the main techniques and reviewed their strengths and weaknesses.
For most simple eCommerce applications, the elegance & simplicity of inline breadcrumbs may be more than adequate. But for more complex information discovery applications, a more scalable approach may be required which consistently displays the current navigational state in a dedicated container. In cases such as these, the breadbox may be the more scalable approach.
In a future post, we’ll complement the ‘advanced’ material above with a look at some of the more basic issues in faceted search design, such as facet types, layout and other display considerations.