Over a million developers have joined DZone.

Designing Faceted Search: Getting the basics right (part 3)

DZone's Guide to

Designing Faceted Search: Getting the basics right (part 3)

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

1. Introduction

Faceted search offers tremendous potential for transforming the search experience. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple fact retrieval to complex exploratory search and discovery-oriented problem solving. But how do we extend such a framework to accommodate not just dozens of facet values, but thousands, or even tens of thousands? It is clearly not practical to display such lists in their entirety. So how can we provide adequate flexibility yet ensure that the user is not overwhelmed in these situations? In this post, we’ll examine the main approaches. In so doing I’d like to acknowledge the work of James Kalbach, whose previous posts on the subject may be the first attempt to document the topic in a comprehensive manner.

2. Display formats and scalability

In previous posts we reviewed a number of display formats for facets and whether their default state should be open or closed by default. A key principle to emerge from that discussion is that it is important for facets to offer an appropriate information scent, i.e. revealing their content and providing navigational cues to help users to formulate productive search strategies. In practice, this means that facets should ideally be open by default, and display a representative sample of facet values. Of course, exactly what constitutes ‘representative’ can be defined in many ways, but in effect this usually entails ordering the list of values by frequency (or some other measure of popularity) and then displaying the first half dozen or so. This raises the question: if the user does want to see the full list of values, how do we extend the display to accommodate them?

There are three main solutions to this problem:

  1. Avoid it entirely by displaying the complete list of facet values by default (although this approach is not always applicable for reasons we’ll discuss below)
  2. Use an expandable container that extends on demand to accommodate additional values.
  3. Use a secondary container to display the longer list, with an associated transition to communicate the relationship between the two.

Let’s examine each approach in turn.

3. Display all values by default

The simplest approach to the problem of showing more values is to avoid it completely by displaying the complete list of facet values by default. This is possible if a display format is used that can scale to accommodate lists of arbitrary length, such as a scrollable container. However, it also assumes that the lists of values are bounded in some way to a manageable size. Scroll bars may be infinitely scalable in principle, but in practice few users would wish to deal with lists of more than hundred items or so (and in many cases significantly fewer).

An example of displaying all items by default can be found at Carzone, which by default displays facets in a vertical stack configuration using scrollable containers for lists of greater than a dozen or so (such as Makes & Models in the example below):

Carzone displays all facet values by default

A variation on this approach can be seen at Farnell, which displays facets in the open parametric configuration. This arrangement applies the principle along both axes: the facets themselves are displayed within a horizontal scrollable panel (extending off the screen to the right) and the values within each of the facets are displayed within vertically scrollable containers. All of the scroll bars appear as required (so they are suppressed for facets with fewer than a handful of values):

Farnell displays all facet values by default

4. Expandable Containers

For many applications, however, displaying all facet values by default is not a scalable solution. Instead, a ‘by request’ approach is required. Perhaps the simplest of these approaches is to present an option to expand the facet inline, i.e. extend its dimensions to accommodate a larger set of values. An example of this approach can be found at NCSU libraries, which displays the top 5 values by default, but expands this vertically to accommodate the top 30 when the ‘Show More’ link is selected (as illustrated by the Subject facet in the image below):

NCSU Libraries expands facet values on demand

This approach is conceptually simple; few users would find the transition between states confusing or intrusive. However, one flaw in this particular execution is that there is no option to show fewer values once a facet is expanded, except by closing it completely. Consequently, once two or more facets have been expanded, it is very difficult to review the contents of the remaining facets without repeated scrolling.

A variation on this approach can be seen at Hoovers, whose option to see more values results in a vertical scroll bar appearing within each facet (as illustrated by the Location and Employees facets):

Hoover expands facet values on demand

Again, the approach is conceptually simple, with a straightforward transition between states.

5. Secondary Containers

While the first two approaches display both the collapsed and expanded set of facet values within the same container, a third approach is to display the expanded set in a new container, and communicate the relationship between the two using visual design cues and/or an appropriate transition.

Perhaps the most lightweight variation on this approach is to use a detail overlay to display the full set of facet values adjacent to the original set. Artist Rising’s ‘More Choices’ link, for example, displays the remaining facet values as a secondary list, extending the original set in a contiguous manner. One advantage of this approach is that the sort order is preserved, e.g. in the example below the complete list of Subjects is still presented in descending order of record count:

Artist Rising displays facet values in a secondary list

A variation on this approach can be seen at Food Network, which shows three values by default but presents an option to show more of any facet on request. This approach uses an overlay as before, but instead of displaying just the additional values it displays the entire list:

Food Network displays facet values in a secondary list

This has the advantage the list can now be displayed in alphabetical order (to facilitate visual scanning). Note that in this display the record counts are suppressed, possibly to reduce any confusion that may arise by displaying such counts in an apparently unsorted order (or perhaps just to reduce clutter and allow the alphabetic ordering to be more apparent).

The transition from one sort order to another may introduce something of a cognitive disconnect for some users, although this is mitigated somewhat by the minimal size of the collapsed list. Note also that the contents of the overlay in this case are limited to a maximum of 50 values, presumably to mitigate the overhead of scrolling an extended list.

A somewhat heavier approach is to use a modal overlay to display the full set of facet values. An example of this can be seen at eBay, which uses the overlay to present the complete list of values for each facet in its own pane. This design 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). In common with Food Network, this approach limits the display of expanded facets to the top 50 or so:

eBay displays facet values using a modal overlay

Both of the above approaches support the principle of minimising the disruption to the user’s mental flow by staying on the page. A more heavyweight approach is to present the list of values on their own page, which is the approach adopted by Amazon on certain sections of their site (e.g. footwear). The example below shows the use of multi-select facets displayed using checkboxes in a vertical stack configuration, with options to ‘See more’ for both Brand and Seller:

Amazon displays multi-select facets using checkboxes

However, selecting the ‘See more’ option (e.g. for Brand) loads a new page displaying the entire set values for that facet:

Amazon loads a new page to display facet values

Surprisingly, this page presents the options as hyperlinks (rather than checkboxes), which as we have seen in a previous post are better suited to single select facets. Indeed, that is exactly how they behave: selecting one value immediately returns the user to the original results page with that facet value now applied. Interestingly, it seems the list of values attempts to be exhaustive, which can produce some extremely long pages (e.g. such as the list of authors for the entire Books section).

6. Hybrid Approaches: search within facets

In the sections above we discussed the primary approaches to showing more values, such as extending the existing container or displaying a new one. What these approaches have in common is that they allow the user to browse a longer list of values to make further selections. However, an alternative approach exists, which allows the user to search for specific values rather than browse. An example of this can be seen at LinkedIn, which by default displays multi-select facets using checkboxes in a vertical stack configuration:

LinkedIn allows search within facet values

As expected, each of these facets shows the first half dozen or so values by default (ordered by record count), with an option to “Show more…” that extends the list to include the first dozen or so. But what makes this design different is the use of the text field (shown below the Current Company and Location facets). As soon as the user starts to type into this box, an autocomplete dialog appears with up to ten suggested values. In this respect, this design offers a more complete experience than the others above, since it allows the user to either search or browse to select further facet values.

7. Conclusions

Over the last few weeks we’ve looked at some of fundamental design issues in faceted search, such as layout (e.g. where to place the faceted navigation menus) and state (e.g. whether they should be open or closed by default) and display formats. In this article, we’ve complemented that with a review of the various techniques for managing long lists of facet values. This means that the complete list of articles on faceted search design now covers the following topics:

  1. Designing Faceted Search – (part 1: layout & state)
  2. Designing Faceted Search – (part 2: fundamental principles + display formats)
  3. Designing Faceted Search – (part 3: showing more values)
  4. Interaction Models for Faceted Search
  5. Wayfinding and Navigation in Faceted Search

With a subject as rich and complex as faceted search, no review can ever be complete, and there is always more to learn, explore, and debate. And we’re aware that this collection of articles still lacks a comprehensive discussion of the issues surrounding the use of record counts and smart dead ends. But we’d like to think that this article marks the final section for a forthcoming book chapter on designing faceted search.

Of course, if you think we’ve missed any topics or would like to suggest others, then we’d love to hear. Feel free to drop me a line either here or via email at tgr AT uxlabs.co.uk.

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.


Published at DZone with permission of Tony Russell-rose, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}