Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Front End Concerns When Implementing Faceted Search – Part 1

by Daniel Tunkelang
on August 6, 2009

Editor’s note: This article is an excerpt from Daniel Tunkelang’s book Faceted Search

“A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.” —Douglas Adams

Where and When to Present Facets

A faceted search system responds to a query by returning a set of
documents intended to match the search terms, and also provides a
set of facets that offer the user directions for query refinement.
This faceted search approach, however, does not specify how those
two sets (the results and the facets) should be presented to the
user. An application may choose to present both sets in the same
view or may initially present only one set, that is, the results or
the facets. Is there an optimal way to make these choices?

The short answer is no: different applications and user needs
motivate different design choices. What we can do, however, is
enumerate a few options and discuss their relative merits.

Let us consider interfaces that present both the matching documents
and the faceted refinements in the same view. There are two
conventional layouts: placing the facets in a panel to the left of
the results and placing the facets directly above the results. An
alternative approach is to place the facets directly below the
results, but this approach has the drawback that users may not even
be aware of the facets unless they scroll to the bottom of the page
if the list of results pushes the faceted section below the fold.

Placing the results in the center and the facets on the left-hand
side (as in Figure 7.1) makes it more likely that users will see
search results and thus focus on them.

digital cameras results

Figure 7.1: Results for “digital cameras” at

Users may prefer a view that brings them to the documents as quickly
as possible, particularly if they only perform faceted refinement
infrequently. For sophisticated users, this vertical layout makes
both the results and facets immediately visible. However, this
layout may be too subtle for less sophisticated users to notice the
availability of the faceted refinement options. Also, such users may
be unfamiliar with faceted refinement and may confuse the faceted
refinement links with static site navigation links that lose their
current query context.

Placing the facets above the results (as in Figure 7.2) makes it
easy for users to notice them: they stand between the search box and
the results, and they are above the fold. The downside is that
placing the facets in such prime real estate means that users may
need to make more effort to see the results. However, this effect
may have a useful consequence: users may use a faceted search system
more productively if they consider ways to elaborate their queries
before rushing to the result list for their initial queries—and this
strategy promotes the importance of the facets.

results of kittens a

Figure 7.2: Results for “kittens” at

Another, less common, option is to present results and facets in
separate views, for example, each in its own tab. The main choice in
implementing such a design is to force which particular view the
user sees first—similar to determining the layout for a view with
results and facets presented on the same page. When users cannot see
the results from their search, they are likely to make an effort to
find them—unless they are so annoyed by the extra work they have to
do that they abandon the site. Conversely, they are less likely to
make such an effort to find facets that they may not even know exist.

Yet another possibility is to make the presentation of results
facets a function of the query itself—that is, change the
presentation based on the properties of the search results. Faceted
refinement can accomplish at least one of two goals: clarification
of ambiguous queries and refinement for general ones [102]. For
ambiguous queries, it may be appropriate to present the user with a
clarification dialog as soon as possible. For example, the search
query “intelligence” on a library site might retrieve items about
mental ability or information gathering; until the system has
established the user’s intended meaning, presenting results is a
guessing game. For unambiguous queries, there is less urgency around
offering a refinement dialog because the results will at least make
sense to the user, even if they are not optimally relevant.

Organizing Facets and Facet Values

In the previous chapter, we considered the problem of information
overload from a back-end perspective: how do we prune the number of
facets or facet values that we present to users? In this section, we
consider the corresponding front-end problem: how do we organize the
information that we do present? We approach the challenge of
information overload in two steps: reducing the number of facets and
values presented (as discussed in Section 6.3) and then organizing
them as effectively as possible. There are three general strategies
for organizing facets, and these are similar to the strategies
discussed in the previous chapter:

  • Use a static order that does not change as the user navigates.
  • Dynamically rank the order of presentation of facets based on
    their estimated utility to the user.
  • Organize similar or related facets into groups. The choice of
    using a static facet order vs. ranking facets is an interesting

On one hand, a static order has the advantage or reinforcing the
user’s mental model—because the user will always see the same facets
in the same order. This strategy works best when the number of
facets is small in that all facets are visible at all times.

On the other hand, a static ordering is less effective when the
number of facets is too large to be displayed at once or when some
facets only apply to particular query contexts. For example, on an
e-commerce site that sells consumer electronics, some facets only
apply to small subsets of the product catalog, such as wattage for
audio speakers or megapixels for digital cameras. Those facets
should only be displayed when the user is looking at narrow result
sets. In general, the same kinds of utility measures used for
filtering can also be used for ranking.

Grouping related facets, as in ACM Digital Library’s grouping
related people, publications, and conferences (Figure 7.3), makes it
possible to include more facets in a single display using less space
on the page because the groups can be expanded and collapsed as
desired by the user. Rich internet applications, designed using such
technologies as AJAX (Asynchronous JavaScript and XML) or Flash,
make it easier to implement such an approach that still offers users
a highly responsive interface.

results in ACM

Figure 7.3: Results for “faceted search” in the ACM Digital Library.

Similar strategies apply for presenting the facet values:

  • Use a static order that is independent of the query context.
  • Rank facets based on a utility measure.
  • Present hierarchical facet values progressively, that is, one
    level of the hierarchy at a time. This last strategy is an option
    even when the facet is not hierarchical. We can create an artificial
    hierarchy in which no node has more than a tractable number of
    children, for example, 5 or 10.

For example, consider a facet with a large set of strings as values,
such as book authors. We can divide them up by last name, splitting
them at the top level as A–E, F–K, L–P, Q–U, and V–Z. The A–E node can be
split into A, B, C, D, and E; A split into Aa–Ae, Af–Ak, etc.; and
so forth until no node has more than five authors as (leaf )
children. The design of such an artificial hierarchy requires some
care to mitigate the trade-off between excessive depth and excessive
fan-out at each node.

We can take a similar approach to create a hierarchy of ranges for
numerical values or for facets whose values can be clustered based
on a similarity measure.

Read Part 2 of Front End Concerns when Implementing Faceted Search.

Want to hear more insights from Dan Tunkelang?

This article is an excerpt from Daniel’s new book: Faceted Search. You can get this book free, when you register for Daniel and Pete’s UIE Virtual Seminar, also called Faceted Search. Gather your team together and watch this seminar, as you’ll get some real insights into the challenges and tricks when implementing faceted search. Once you register for the virtual seminar, you’ll receive details on your free copy of the book.

Share your thoughts

Have you planned out a faceted search interface to your data? What were some of the hurdles you ran into? How did you work through them? Share your experiences with us at the
UIE Brain Sparks blog.