Designing Faceted Search: Getting the basics right (Pt 1)

Faceted search offers tremendous potential for transforming search experiences. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple lookup and fact retrieval to complex exploratory search and discovery scenarios.  In this article, we begin with a look at some of the fundamental design considerations such as layout (i.e. where to place the faceted navigation menus) and default state (e.g. open, closed, or a hybrid).

Layout

One of the most basic issues in designing faceted search is deciding where to locate the faceted navigation menu. (Note that we use the term “faceted search” here to describe the overall user experience, whereas we reserve the term “faceted navigation menu” to denote the component that displays the currently available facets). Broadly speaking, there are three main choices: vertical, horizontal, and hybrid. Let’s examine each in turn.

Vertical configuration

Vertical layout is by far the most common configuration, and warrants its own entry in the Endeca UI Pattern Library (referred to as “Vertical Stack”). This configuration scales well to variations in the number of facets displayed (as discussed in our previous post on wayfinding). In addition, a shared orientation with the search results (also listed vertically by convention) provides a visual coherence that helps reinforce the conceptual relationship between selections made and results returned. An example of this configuration (from eBay) is shown below:

This example shows the facets placed on the left hand side, which is a common convention for navigation menus (at least for cultures where the reading direction is left to right). It also helps maintain visibility if the browser is resized. However, a number of sites have chosen to locate the facets on the right, e.g. Edinburgh University’s library catalogue (as shown below):

Much has been written about the merits of left vs. right hand placement for navigation menus, which we won’t repeat here. However, two caveats apply. Firstly, for faceted navigation (as opposed to static navigation), the relationship between progressive refinements and the content of the search results can be quite nuanced. It could be argued that the cause and effect nature of this relationship is more readily communicated (at least, for cultures where the reading direction is left to right) when the facets are placed on the left and the results on the right. Secondly, there is convention: users will arrive at any new site with their own mental models and expectations, one of which is that navigation menus are usually located on the left hand side. Of course, as designers, we can choose to ignore such expectations – but if we do so, we should at least act on the basis of a principled, evidence-based rationale.

A similar conclusion, with slightly different reasoning (but perhaps stronger primary evidence), is documented by James Kalbach. Moreover, the motivation for placing the facets on the right in the above example may have been to increase visibility and adoption of the “concept browser” control on the left – in which case, a suitable rationale was indeed applied – albeit one not necessarily motivated exclusively by user-centred concerns.

Horizontal configuration

An alternative to the vertical configurations outlined above is to arrange the facets horizontally, usually across the top of the page as shown here on Yelp:

An advantage with this configuration is that the facets now occupy a much more dominant position on the page, and present a more visible invitation for interaction. However, this configuration does not scale well beyond a small number of facets, as the maximum that can be simultaneously displayed is normally bounded by the width of the page (in this case, six facets are shown). In addition, the facet menu will disappear from view as soon as the user scrolls through the result set, compromising the visibility of the conceptual relationship between selections made and results returned.

There are also a number of variations on the basic horizontal configuration. One such example can be seen at Amphenol, which adopts the design principle that all relevant facets will be displayed for any given result set, and that these should wrap across the screen where necessary. The example below shows a search for “connectors”, which returns 25 facets displayed in alphabetically ordered, scrollable containers (with the results pushed below the fold):

An advantage of this approach is that it eliminates the need for an arbitrary limit on the number of facets that can be simultaneously displayed. However, the effect on the overall query refinement experience can be quite disorienting due to the sheer number of facets displayed (with little sense of priority). A further discontinuity is created by continual changes in the location and identity of the facets as progressive refinements are applied. (Of course, this issue can apply equally to vertical configurations, but the extended horizontal configuration shown here makes the effect so much more immediately tangible on each refinement action).

It’s worth mentioning that the Amphenol configuration is actually a variant of the Open Parametric design pattern, in which the facets are laid out in a horizontal sequence and displayed in their “open” state by default (see the discussion on default states below). This pattern is primarily aimed at users accustomed to a “parametric search” style of interaction, which is a convention widely adopted by manufacturers and distributors of “parameterized” products such as electronic components.

Hybrid configurations

Most implementations of faceted search follow either the vertical or horizontal configurations outlined above. A few, however, adopt a hybrid approach, such as TravelMatch (shown below):

A vertical stack is used for the majority of facets which in this case are displayed on the left hand side. However, they have chosen to display three particular facets in a horizontal configuration across the top of the page. These three may have been selected because they manipulate quantitative data and thus are well suited to a slider control (for a broader discussion on the choice of display media see below). Conversely, they may have been selected for being notable exemplars of the site’s USP and brand values (i.e. the freedom for users to initiate a search using whatever criteria they deem most important). By contrast, the data fields used to initiate a search on most traditional travel sites (i.e. party size, date, etc.) are probably the least immediately visible of all the facets shown on this page.

It is also interesting to observe that an earlier incarnation of TravelMatch adopted an even more radical treatment, arranging the facets in a radial layout around the page. It appears that feedback from user testing has encouraged a gradual migration toward a somewhat more conventional layout.

Default state

Coupled with the issue of layout is the choice of default state for each of the facets. Again, we have three broad choices: closed by default, open by default, or a combination of the two.

Closed by default

The first option is to display all facets as closed by default, which is the approach adopted by TravelMatch in the left hand menu above. The advantage is that screen space is minimised, and for a site with a large number of facets (such as this), the immediate visibility of that breadth of choice is maximised. (Note that it wouldn’t make sense to hide the three horizontal sliders in this case since little space would be saved and it would compromise the USP discussed above). The disadvantage is that the information scent offered by each facet is weaker than if they were shown in their open state (with sample facet values clearly visible). As a result, adoption and usage of the facets may be somewhat compromised. To help mitigate this, the invitation or control to open (and close) each of the facets should be clearly visible and unambiguous.

Open by default

The second option is to display all facets in their open state by default. This maximises the information scent by exposing example values for each of the facets, and helps encourage adoption and usage of the faceted menu. An example of this can be seen below at job site Monster:

This approach usually limits the number of facet values displayed by default to a handful, which are typically prioritised on the basis of frequency or some other measure of popularity. A suitable call to action is then required to invite the user to see further values (e.g. the use of “More <facet name>” in the Monster example).

Note that it is not advisable to show facets open by default if one or more of them contain multi-select values and the interaction model is two-stage. Doing so can undermine the fundamental principle that the set of results and facet values should update immediately as soon as any selection is made and increase the likelihood that ‘illegal’ combinations of facet values can be selected, leading to zero results. In the example above, if we add the refinements Category=”R&D/Science” and Industry=”Internet Services”, zero results are returned. For a fuller discussion of this issue, see the recent post on Interaction Models for Faceted Search.

This example also uses of smart dead ends to indicate facet values which don’t apply to the current result set but might otherwise, were some refinement to be removed. These are rendered in grey with disabled checkboxes in the example above. What this tells the user is that although Monster has jobs that are part-time/per day/temporary etc. in its database, none of these apply to the query “natural language processing”. Smart dead ends can provide a very effective means for helping users understand the range of possibilities open to them beyond their current query, and thus encourage further serendipitous exploration and discovery.

Combination of open/closed

The third option for default state is a combination of open and closed. This option is becoming increasingly popular as it makes efficient use of screen space and provides a stronger information scent for the first few facets (which should ideally be sorted by priority). An example of this can be seen below at NCSU Libraries:

In this example, the primary facets (Subject, Genre, Format, Call Number Location and Library) are shown in their open state, and the secondary facets (Language, Region, Time Period and Author) are shown closed. One assumes this choice reflects the dominant search strategies and mental models employed by the library’s users in searching the catalogue.

There is also a further variant on this theme. In the NCSU Libraries example above, the choice of default state (open or closed) is applied at the outset, but is thereafter entirely driven by user behaviour (i.e. if I open a facet it stays open, if I close a facet it stays closed, etc.). In other words, the initiative for changing those states lies with the user as he/she progresses through a given search scenario.  But for more complex search scenarios, a mixed initiative approach may be adopted. For example, a search on eBay using the query “golf” returns a query clarification dialogue as shown below:

Notice how all the facets are open by default. This is particularly significant, since the primary role for the query clarification facets (e.g. “Sporting Goods”, “Cars, Motorcycles & Vehicles” and “Clothes, Shoes & Accessories”) is to guide the user in making an appropriate selection to disambiguate their query. A string information scent (provided by the example values) is thus vital.

But once a selection has been made, a different approach is adopted. For example, if we select Category=” Cars, Motorcycles & Vehicles” we are presented with a refined set of results and further facets, as shown below:

But on this occasion the default state is a combination of open and closed. Like NCSU libraries, they have ordered the facets by priority to reflect the dominant search strategies and mental models employed by their users. In this case, that means showing the primary facets of Model, Model Year, Condition and Price in their open state, and the secondary facets (Car Type, Fuel Type, Transmission and Seller) in their closed state. A subtle but effective strategy for optimising screen space, information scent and query (disambiguation) effectiveness.

Note of course, that the above examples are predicated on the use of an independent control (such as a breadbox) to communicate the current navigational state. If inline breadcrumbs are used instead, then facets must either be shown in their open state by default or use some sort of memento to indicate the presence of existing selections when closed by the user (like TravelMatch, which displays icons representing existing selections within closed facets).

Conclusion

Faceted search provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple lookup and fact retrieval to complex exploratory search and discovery. In this post, we’ve looked at the design issues of layout and default state. In the next post, we’ll continue with our review of the fundamentals by examining various methods for displaying facet values (e.g. hyperlinks, checkboxes, and so on) along with other key design principles.