Front End Concerns When Implementing Faceted Search – Part 1

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.

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.

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 trade-off.

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.

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.