Wednesday, June 4, 2008

User Interface Implementations of Faceted Browsing

Just as it is important to choose the proper knife when slicing-n-dicing vegetables, it is critical to prescribe a suitable user interface to support faceted filtering. Faceted filtering allows you to narrow down a large list of objects to a manageable size by applying flexible combinations of attribute filters in any order. Rather than forcing you down fixed paths within a website’s information architecture, faceted filtering allows you to multi-dimensionally slice-n-dice the information in a manner that best accommodates your specific needs. A user interface that optimally supports faceted filtering must expose its robust functionality in a way that expresses affordances, controls complexity, and follows existing standards that have been pre-established across the web.

You Know What You Want

"More recently, with the advent of enhanced asynchronous interactions of Ajax and Flash, you can apply filter criteria individually and see how the resulting list updates. By doing so, you can progressively see the cause and effect of applying individual filters."

Traditional static information architecture (IA) makes up most of the fundamental structure of the web. Information architects responsible for individual websites supposedly reconciled user tasks with their respective information space (document and object relationships) to define how web pages should link to one another. This process presumes that users can be accurately represented as a single group and that the acting information architect optimally mapped the collective group’s needs to the information space to best prescribe the static information architecture. As anyone who has chosen to use a website’s search rather than browsing across its information architecture can tell you, this process is not always successful.

Along came faceted filtering to the rescue. If we define groups of adjectives (facets) that describe objects and allow users to filter with them, we could empower users to manipulate the information space themselves rather than oppressively imposing a fixed structure upon them. Users could flexibly select values across all facets, in any order, to view only those objects that could be described as such.

A few facet fundamentals to get us grounded. First, there are facets and facet values. A group of facet values make up a facet. For example, a facet could be color with facet values of red, white, and blue. When filtering, there are usually multiple facets each with multiple values. Balancing the user needs with the potential complexity of inter-facet and intra-facet selection is important in controlling the user interface complexity

Filtering Sequence

There are two primary methods for applying faceted filters:

  • En masse—traditional form submission where multiple criteria are submitted at once
  • On selection—Ajax-like technique where filtering criteria are submitted individually, sequentially upon each selection

Traditional object filtering has been done with full form submission—choose your criteria by filling out a form and submit. Yahoo’s stock screener is an example. The main drawback is you often end up with “No results found” and you are unsure which criteria or combination of criteria resulted in the null set.

More recently, with the advent of enhanced asynchronous interactions of Ajax and Flash, you can apply filter criteria individually and see how the resulting list updates. By doing so, you can progressively see the cause and effect of applying individual filters. This is more usable because it abets your browsing behavior by allowing you to actively whittle down your information space and process information along the way. It also opens up the possibility to use links instead of traditional form elements for filter selection. The functionality that progressive filtering affords is best exposed with a well planned UI.

Rich & Complex or Basic & Simple

If you were filtering on a website that sells shoes, you may want to filter by facets including color, size, cost, brand, and sport. When selecting filters across facets, you are basically creating an “AND” conditional statement. Show me all “shoes” that are for “running” AND are “size 11” AND are “under $80” AND are brand “Nike”. That’s pretty straightforward.

Things can get a bit tricky when selecting multiple values within a facet and across facets. If you select “black” and “white” within the color facet and “size 11” within the size facet, you are creating a complex AND/OR conditional statement—show me all “shoes” that are “black” and “size 11” or “white” and “size 11”. As multiple values are selected across multiple facets, this can get muddled quickly.

The guided nature of faceted filtering with single-select elements restricts the total combination of filters that can be applied. A user cannot select multiple values from an attribute set (“OR” conditional). For example, a user could not request shoes that are “running” OR “walking” and “white” and “Nike” and “under $100”. Instead a user would apply the “running” filter, remove it, and apply the “walking” filter.

Choosing between offering users single-select or multi-select values within a facet boils down to the need for fine filtering. The need for fine filtering is related to how quickly the initial list can be filtered down to a manageable size. Considerations include:

  • Total number of objects filtered
  • Total number of facets
  • Total number of facet values in a given facet
  • Frequency with which users apply filters across facets
  • Context in which users arrive at the filtering functionality (have they performed an initial search or filter)
  • Table sorting/grouping functionality
  • User mode—browse or find
  • Discreteness of the facet values as mapped to the users filtering needs (e.g. you wouldn’t need to select “under $100” and “under $75” and “under $50”).

These factors all influence how quickly a list can be reduced to a meaningful and manageable size (~50 objects) where sorting and visual scanning takes over. If a filter selection, on average, reduces the total list size by a very small percentage, multi-select filtering should be considered.

No Such Thing as a Free Lunch

The need for fine filtering has to be considered in light of the complexity that it introduces both logically and visually. The advanced functionality of selecting multiple values within a facet is often not easily understood by users. Multi-selected values within a set are joined by “ORs” and multiple selected attributes across sets are joined by “ANDs”. While this provides finer manipulation of the object set, it can also result in no results found.

Fine filtering is also often accompanied by significant UI complexity because all facet values must persist, thereby cluttering the UI. If users can only select one value per facet, you can manage the complexity of the UI by removing the non-selected facet values. This can significantly clean up the UI especially when there are multiple faceted filters, each with many values (figure 1).

While you could choose to allow multi-select elements for some facets and single select elements for others, the drawbacks of the inconsistent behavior may outweigh any functional benefit.

UI Design for Faceted filtering

After addressing the conceptual design decision regarding whether to use multi-select or single select elements in a facet, we need to decide what UI controls to use for value selection. Single-select elements include radio buttons, dropdown lists and oftentimes links. Multi-select elements include checkboxes, listboxes, and sliders.

Form elements commonly support multi-select filtering within a facet whereas links are predominantly used for single-select filtering. While you could use dropdown elements or radio buttons for single-selection, links are much more commonly used today on the web and with good reason. Links offer utter simplicity – click a link to see what you want (the applied filter). While links are a scaled-back UI, they are correspondingly simple and are the ubiquitous UI element of the web.

Form elements, on the other hand, each have different behaviors and manipulation mechanisms but offer more control. They present a more advanced UI to support more advanced functionality, but at the expense of complexity to the user because of their visual and behavioral load. This is especially true when multiple facets use different types of controls (e.g. checkboxes, sliders, and listboxes), but can be limited by using the same type of control across all facets (e.g. all checkboxes). This complexity is magnified when all facet values must persist, thereby cluttering the UI. And while a basic form element such as checkbox may be perceived as simple (and indeed, users like them), users are easily confused by them.

Choosing a UI element to support filtering should be primarily driven by the users needs. As an example, a more advanced control such as a dual slider may seem necessary based on the underlying data that it supports. For instance, you could use a dual slider for choosing a range amongst a broad spectrum of values for stock risk. It would allow users to nearly infinitely select any sub-spectrum of risk.

But, rather than blindly prescribe the UI control based on the underlying data, take a step back to reflect on users’ actual needs. Do users really need the fine control of a dual slider to select a risk spectrum, or do they simply consider risk in three primary bands – high, medium, low – for which a single-selection UI element would suffice. How often do users need to see both high and medium or medium and low? By intelligently limiting choices, you can guide the user and reduce the burden that the UI imposes. More UI functionality is nearly always accompanied by additional complexity. The benefit of the additional functionality should outweigh the drawback of the resulting complexity. You can see the considerations of selecting the appropriate filtering UI mechanism in this decision tree (PDF, 604KB).

Finally, there are a handful of ancillary considerations.

  • Progressive filtering affords the ability to provide users feedback about how many items remain per facet value. Placing an item count after each facet value effectively gives users future insight without requiring additional interaction (figure 2)
  • Filters are usually placed along the left column or top row relative to the results set. Research has shown that users are more likely to see filters placed along the top row, although this may provide layout challenges when many filters with many values are used.
  • Collapsible filters can save space for multi-select filters, but can mislead the users when applied filters are hidden.
  • The filtering metaphor should reflect its physical metaphor. You start off with a pile of stuff and progressively apply filters. While it is logically correct to show that all results display when all filters are applied, it is counterintuitive and should be avoided. In other words, you usually do not want to show all checkbox filters checked, Doing so forces users to deselect facet values—essentially click on what you don’t want. This is the opposite of ubiquitous web behavior—click what you want. Expceptions exist when users usually want to see everything “except”, in which case all the values in a facet could be selected and users can deselect the few values that relate to the stuff they don’t want to see.

What’s Happening on the Web

Faceted filtering has been embraced on the web in the past few years. It’s been leveraged as a useful utility across the web when users are reviewing products to buy such as electronics, clothing, books, and cars. Single-select filtering, specifically link filters have emerged as the common UI element for faceted filtering and has accordingly become the standard UI for faceted filtering across the web.

Most of the top e-commerce sites that use faceted filtering do so with links, including Amazon, Nike, HP, IBM, Zales, Toys-r-Us, QVC, My Simon, Overstock, Lowes, Home Depot, Target, Circuit City, Best Buy, Radio Shack, Office Max, HSN,,, CarsDirect,, and Edmunds.

Some websites use faceted filtering with multi-select within facets and provide complex conditional faceted filtering. Dell, AT&T,, Ford, Maytag, Blue Nile, Kayak, and eBay (eBay uses both links and checkboxes) feature such a UI. Faceted filtering with multi-select elements provides the most flexibility but is accompanied with increased visual density and logical complexity.

Some websites incorporate a hybrid design that offers a bit of both. Ebay Express offers single-select faceted filtering with links as its primary mechanism. But they subtly add a “more choices” link within each facet that allows you to multi-select. Yahoo Autos Carfinder has mutli-select elements with item counts. While logically it is somewhat complex how the item counts are calculated, it seems to fall in line with users’ expectations when actually trying to find a car.

The adoption of faceted filtering with links across the web is compelling. It indicates a widespread endorsement of the design and users have built a familiarity with it. While faceted filtering with checkboxes and other form controls can provide finer results, it is accompanied by significant UI complexities. You can see various implementations of faceted filtering in this Flickr screenshot colllection.

Slice-n-Dice or Puree?

Faceted filtering helps users manage large amounts of information. Do you need to slice-n-dice or puree? If you can only filter by selecting one value per facet (slice-n-dice), can you efficiently accomplish your ultimate task or do you need to select multiple values per facet, across facets (puree). The former can be done simply with links while the latter may require a complex combination of form controls with all facets values always persistent.

The potential benefit of finer filtering has to offset the drawbacks of the more taxing UI required to support it. Even if a segment of users requires such advanced functionality, you should consider the difficulty that will be imposed across all users, across all tasks. And as with any UI design, designing for the exception at the expense of the majority is a mistake. Sure a user may have to filter by some by some cryptic, complex combination occasionally, but do you really want to subject all users to the design overhead that would be required to support that user’s minority need? By understanding the users’ needs and the information space, you can best design a UI that optimally supports faceted filtering.


Post a Comment

Subscribe to Post Comments [Atom]

<< Home