Tweaking Your Facets, Part I: Supporting Hierarchy with Multiple Selection

By Jaimie Sirovich

Published: May 23, 2011

“Faceted navigation is one of the most important breakthroughs in modern Web site design. It provides an almost universally positive enhancement to usability.”

Faceted navigation is one of the most important breakthroughs in modern Web site design. It provides an almost universally positive enhancement to usability. Even Google is starting to employ facets—despite the challenges involved in massive Web scale—with simple facets on products and recipes. Facets are great, and seemingly everyone is implementing them. However, there are many decisions we must make in implementing facets that influence their effectiveness. Among these is choosing between single- and multiple-selection interfaces.

Both single and multiple selection have their respective merits, and the use of multiple selection certainly forgoes at least some simplicity in exchange for flexibility. Another fundamental problem with multiple selection is that it makes supporting hierarchies more difficult—or really impossible without some sort of compromise. Let’s explore one such compromise, but first, some background.

Single Selection Versus Multiple Selection

The majority of faceted interfaces today permit only one selection per facet dimension. For example, for the facet color, a user can select only one value such as Color: Red. Single-selection interfaces convey only Boolean expressions, in the following form:

  • (color:red)
  • (size:small)
“The majority of faceted interfaces today permit only one selection per facet dimension.”

This is perfectly adequate for many tasks. However, multiple selection serves some task better—especially those that involve arbitrarily defined sets of values or subjective values that have many potential alternatives. Multiple selection also permits a retailer to worry less about perfecting and normalizing values in large bodies of metadata. In many cases, this is an enormous benefit, because users can compensate for the lack of perfectly normalized data simply by selecting multiple values. Figure 1 exemplifies the failure of a single-selection interface on J&R, because of a data normalization problem.

Figure 1—Single-selection interface on J&R

Single-selection interface on J&R

Users who want either a 2.4-inch or a 2.5-inch screen—a seemingly trivial distinction—must try both of the selections individually. Within the context of another selection that a user has made with a single-selection interface—such as brand—this would require a user to painstakingly make his selections for each of these screen sizes. In contrast, with a multiple-selection interface, a user can simply select both values—after shrugging at the perversity of J&R’s bothering to make such a distinction. To fix this problem, J&R could also have rounded off both screen sizes to half an inch. However, such cases might be different in LCD TVs and yet again for computer monitors—making for very troublesome normalization work indeed.

“Multiple-selection interfaces are making appearances on many new retailer Web sites.”

Multiple-selection interfaces are making appearances on many new retailer Web sites. Google’s recipe search also takes a multiple-selection approach for ingredients, as shown in Figure 2.

Figure 2—Multiple selection for ingredients

Multiple selection for ingredients

As a general example, a user who is searching for red or blue clothing in sizes L to XXL needs to convey this expression:

(color:red or color:blue) and (size:l or size:xl or size:xxl)

Users can do this in a straightforward manner using a multiple-selection interface, while they’d struggle with a single-selection interface. In some cases, it is possible to simulate multiple selection in situations where ranges of values are expressed as & up, as in the user interface shown in Figure 3, which I sighted at Macys.com. But this is the end of the road for single selection.

Figure 3—Simulating multiple selection on Macys.com

Simulating multiple selection on Macys.com

So multiple selection works very well for non-hierarchical facets. Unfortunately, it seems that multiple selection cannot coexist at all with hierarchical facets—or can it? Pete Bell of Endeca, in his blog post “Bring Back the Dead Ends,” says “Multi-select and hierarchy [don’t work well together], where … you get split ends.” Split ends occur when a user selects two or more values on the first level of a tree, then in turn, drills into those values. The user may also drill to differing levels within each value. At that point, the tree becomes difficult or impossible to display in an intuitive and space efficient way. You can find my comment with the original seeds of my discussion in this article on Pete’s blog, Search Facets.

“Multiple selection can work well for synthetic hierarchies—those that organize large numbers of values into arbitrary sets or ranges.”

Hierarchies have been around since at least Aristotle’s time and certainly must coexist with faceted navigation schemes. And for real hierarchies like Aristotle’s, we employ single selection. However, multiple selection can work well for synthetic hierarchies—those that organize large numbers of values into arbitrary sets or ranges. In such cases, we create a virtual hierarchy for expediency rather than to reflect an actual hierarchy. This is an efficient compromise.

A common example showing where such a synthetic hierarchy might be useful is price. To implement this compromise, it’s necessary to create a hierarchy that is limited to exactly two levels, allowing multiple price selections across parents without Pete Bell’s split ends. The benefits of using only two levels are as follows:

  • It avoids the split-end problem entirely.
  • Optionally, it also permits the conveyance of gray ends—that is, disabled, or gray, values that would lead to pages with zero results in such a hierarchy.
  • Some facets lend themselves well to this solution anyway—such as ranges of values and letter prefixes.

Two levels are easier to understand—and are adequate in many situations. This reduces the number of values you present initially. Doing this also reduces the number of clicks substantially if the divisions of the tree are sensible for the task. Figure 4 provides an example that illustrates this approach.

Figure 4—A two-level hierarchy

Two-level hierarchy

(From Salt & Pepper Shakers, Ablekitchen.com)

“When a user clicks a parent filter to select it, all of its children are also selected. … Single selection using links for drilling down; multiple selection using check boxes for filtering.”

When a user clicks a parent filter to select it, all of its children are also selected. Doing this provides the benefit of consistency, because it avoids the necessity of using a single-selection interface for some filters, but multiple selection for others—except the one for subcategory. This may even be intuitive: single selection using links for drilling down; multiple selection using check boxes for filtering.

Lastly, as Greg Nudelman mentioned in his UXmatters article “The Mystery of Filtering by Sorting,” “People chronically over-constrain their queries.” This approach also helps to prevent that problem—especially when optimized trees are formed by dynamically creating the correct number of parent ranges. In a product category with a wide range of prices—such as one for kitchen supplies for sale both as single items and in bulk quantities—dynamically creating parents in this way prevents click fatigue and reduces the number of prices customers see initially. Unlike in a traditional hierarchy, users can select child values across different parents. Using the square root of the number of values is a good starting point.

Dan Tunkelang of Endeca—who previously cooked up recipes at Google and is now at LinkedIn—has noted another problem with multiple selection. He says in a comment on the aforementioned Search Facets blog post, “The only constraint is screen real estate: gray ends only work when you can afford to keep all facet values displayed at all times.” Multiple-selection interfaces do consume more screen real estate than single-selection interfaces, and they can seem overwhelming at times when they have large sets of values.

There some approaches to mitigating this problem, which I will explore in Part II of this series of articles on facets. I’ll also explore an alternative strategy that works for non-synthetic hierarchies, but is subject to a few limitations and caveats. Most important, all of these considerations, details, and complications must be invisible to users and confined to the depths of implementation black magic.

New Book: Designing Search: UX Strategies for eCommerce Success

Mathematician Dr. S. R. Ranganathan planted the seeds of faceted navigation in the 20th century, but it has flourished in the 21st century with wide application in ecommerce.

If you want to learn more about faceted navigation and search, read Greg Nudelman’s new book Designing Search: UX Strategies for eCommerce Success. For an overview of search marketing concerns relating to faceted navigation, check out my perspective in his book, “Usability, SEO, and Faceted Navigation,” at the end of Chapter 13.

For a 40% discount on Greg’s book, purchase the paperback book or ePub on Wiley.com by June 16, 2011, using the coupon code: UXDS1.

Join the Discussion

Asterisks (*) indicate required information.