Designing Faceted Search: Getting the Basics Right (Part 1)
Join the DZone community and get the full member experience.Join For Free
over the last couple of weeks we’ve looked at some of the more
advanced design issues in faceted search, including the strengths and
weaknesses of various
techniques for wayfinding and navigation
in this post, we’ll complement that material with a look at some of the
other fundamental design considerations such as layout (i.e. where to
place the faceted navigation menus) and default state (e.g. open,
closed, or a hybrid). in so doing, i’d like to acknowledge the work of
, and in particular his
tutorial on faceted search design
, which provides an excellent framework for many of the key principles outlined below.
one of the most basic issues in designing faceted search is deciding
where to locate the faceted navigation menu. (note that we use the term
“faceted search” here to describe the overall user experience, whereas
we reserve the term “faceted navigation menu” to denote the component
that displays the currently available facets). broadly speaking, there
are three main choices: vertical, horizontal, and hybrid. let’s examine
each in turn.
2.1 vertical configuration
vertical layout is by far the most common configuration, and warrants its own entry in the endeca ui pattern library (referred to as “ vertical stack ”). this configuration scales well to variations in the number of facets displayed (as discussed in our previous post on wayfinding ). in addition, a shared orientation with the search results (also listed vertically by convention) provides a visual coherence that helps reinforce the conceptual relationship between selections made and results returned. an example of this configuration (from ebay ) is shown below:
this example shows the facets placed on the left hand side, which is a common convention for navigation menus (at least for cultures where the reading direction is left to right). it also helps maintain visibility if the browser is resized. however, a number of sites have chosen to locate the facets on the right, e.g. edinburgh university’s library catalogue (as shown below):
much has been written about the merits of left vs. right hand placement for navigation menus , which we won’t repeat here. however, two caveats apply. firstly, for faceted navigation (as opposed to static navigation), the relationship between progressive refinements and the content of the search results can be quite nuanced. it could be argued that the cause and effect nature of this relationship is more readily communicated (at least, for cultures where the reading direction is left to right) when the facets are placed on the left and the results on the right. secondly, there is convention: users will arrive at any new site with their own mental models and expectations, one of which is that navigation menus are usually located on the left hand side. of course, as designers, we can choose to ignore such expectations – but if we do so, we should at least act on the basis of a principled, evidence-based rationale.
a similar conclusion, with slightly different reasoning (but perhaps stronger primary evidence), is
documented by james kalbach
moreover, the motivation for placing the facets on the right in the
above example may have been to increase visibility and adoption of the
“concept browser” control on the left – in which case, a suitable
rationale was indeed applied – albeit one not necessarily motivated
exclusively by user-centred concerns.
2.2 horizontal configuration
an alternative to the vertical configurations outlined above is to arrange the facets horizontally, usually across the top of the page as shown here on yelp :
an advantage with this configuration is that the facets now occupy a much more dominant position on the page, and present a more visible invitation for interaction. however, this configuration does not scale well beyond a small number of facets, as the maximum that can be simultaneously displayed is normally bounded by the width of the page (in this case, six facets are shown). in addition, the facet menu will disappear from view as soon as the user scrolls through the result set, compromising the visibility of the conceptual relationship between selections made and results returned.
there are also a number of variations on the basic horizontal configuration. one such example can be seen at amphenol , which adopts the design principle that all relevant facets will be displayed for any given result set, and that these should wrap across the screen where necessary. the example below shows a search for “connectors”, which returns 25 facets displayed in alphabetically ordered, scrollable containers (with the results pushed below the fold):
an advantage of this approach is that it eliminates the need for an arbitrary limit on the number of facets that can be simultaneously displayed. however, the effect on the overall query refinement experience can be quite disorienting due to the sheer number of facets displayed (with little sense of priority). a further discontinuity is created by continual changes in the location and identity of the facets as progressive refinements are applied. (of course, this issue can apply equally to vertical configurations, but the extended horizontal configuration shown here makes the effect so much more immediately tangible on each refinement action).
it’s worth mentioning that the amphenol configuration is actually a variant of the open parametric design pattern, in which the facets are laid out in a horizontal sequence and displayed in their “open” state by default (see the discussion on default states below). this pattern is primarily aimed at users accustomed to a “ parametric search ” style of interaction, which is a convention widely adopted by manufacturers and distributors of “parameterized” products such as electronic components.
2.3 hybrid configurations
most implementations of faceted search follow either the vertical or horizontal configurations outlined above. a few, however, adopt a hybrid approach, such as travelmatch (shown below):
a vertical stack is used for the majority of facets which in this case are displayed on the left hand side. however, they have chosen to display three particular facets in a horizontal configuration across the top of the page. these three may have been selected because they manipulate quantitative data and thus are well suited to a slider control (for a broader discussion on the choice of display media see below). conversely, they may have been selected for being notable exemplars of the site’s usp and brand values (i.e. the freedom for users to initiate a search using whatever criteria they deem most important). by contrast, the data fields used to initiate a search on most traditional travel sites (i.e. party size, date, etc.) are probably the least immediately visible of all the facets shown on this page.
it is also interesting to observe that an earlier incarnation of travelmatch adopted an
even more radical treatment
arranging the facets in a radial layout around the page. it appears
that feedback from user testing has encouraged a gradual migration
toward a somewhat more conventional layout.
3. default state
coupled with the issue of layout is the choice of default state for
each of the facets. again, we have three broad choices: closed by
default, open by default, or a combination of the two.
3.1 closed by default
the first option is to display all facets as closed by default, which
is the approach adopted by travelmatch in the left hand menu above. the
advantage is that screen space is minimised, and for a site with a
large number of facets (such as this), the immediate visibility of that
breadth of choice is maximised. (note that it wouldn’t make sense to
hide the three horizontal sliders in this case since little space would
be saved and it would compromise the usp discussed above). the
disadvantage is that the
offered by each facet is weaker than if they were shown in their open
state (with sample facet values clearly visible). as a result, adoption
and usage of the facets may be somewhat compromised. to help mitigate
this, the invitation or control to open (and close) each of the facets
should be clearly visible and unambiguous.
3.2 open by default
the second option is to display all facets in their open state by default. this maximises the information scent by exposing example values for each of the facets, and helps encourage adoption and usage of the faceted menu. an example of this can be seen below at job site monster :
this approach usually limits the number of facet values displayed by default to a handful, which are typically prioritised on the basis of frequency or some other measure of popularity. a suitable call to action is then required to invite the user to see further values (e.g. the use of “more <facet name>” in the monster example).
note that it is not advisable to show facets open by default if one or more of them contain multi-select values and the interaction model is two-stage . doing so can undermine the fundamental principle that the set of results and facet values should update immediately as soon as any selection is made and increase the likelihood that ‘illegal’ combinations of facet values can be selected, leading to zero results. in the example above, if we add the refinements category=”r&d/science” and industry=”internet services”, zero results are returned. for a fuller discussion of this issue, see the recent post on interaction models for faceted search .
this example also uses of
smart dead ends
to indicate facet values which don’t apply to the current result set
but might otherwise, were some refinement to be removed. these are
rendered in grey with disabled checkboxes in the example above. what
this tells the user is that although monster has jobs that are
part-time/per day/temporary etc. in its database, none of these apply to
the query “natural language processing”. smart dead ends can provide a
very effective means for helping users understand the range of
possibilities open to them beyond their current query, and thus
encourage further serendipitous exploration and discovery.
3.3 combination of open/closed
the third option for default state is a combination of open and closed. this option is becoming increasingly popular as it makes efficient use of screen space and provides a stronger information scent for the first few facets (which should ideally be sorted by priority). an example of this can be seen below at ncsu libraries:
in this example, the primary facets (subject, genre, format, call number location and library) are shown in their open state, and the secondary facets (language, region, time period and author) are shown closed. one assumes this choice reflects the dominant search strategies and mental models employed by the library’s users in searching the catalogue.
there is also a further variant on this theme. in the ncsu libraries example above, the choice of default state (open or closed) is applied at the outset, but is thereafter entirely driven by user behaviour (i.e. if i open a facet it stays open, if i close a facet it stays closed, etc.). in other words, the initiative for changing those states lies with the user as he/she progresses through a given search scenario. but for more complex search scenarios, a mixed initiative approach may be adopted. for example, a search on ebay using the query “golf” returns a query clarification dialogue as shown below:
notice how all the facets are open by default. this is particularly significant, since the primary role for the query clarification facets (e.g. “sporting goods”, “cars, motorcycles & vehicles” and “clothes, shoes & accessories”) is to guide the user in making an appropriate selection to disambiguate their query. a string information scent (provided by the example values) is thus vital.
but once a selection has been made, a different approach is adopted. for example, if we select category=” cars, motorcycles & vehicles” we are presented with a refined set of results and further facets, as shown below:
but on this occasion the default state is a combination of open and closed . like ncsu libraries, they have ordered the facets by priority to reflect the dominant search strategies and mental models employed by their users. in this case, that means showing the primary facets of model, model year, condition and price in their open state, and the secondary facets (car type, fuel type, transmission and seller) in their closed state. a subtle but effective strategy for optimising screen space, information scent and query (disambiguation) effectiveness.
note of course, that the above examples are predicated on the use of an independent control (such as a
) to communicate the current navigational state. if
are used instead, then facets must either be shown in their open state
by default or use some sort of memento to indicate the presence of
existing selections when closed by the user (like travelmatch, which
displays icons representing existing selections within closed facets).
over the last couple of weeks we’ve looked at some of the more advanced design issues in faceted search, including interaction models and techniques for wayfinding and navigation . in this post, we’ve complemented that material with a discussion of the essential design considerations of layout and default state. in a future post, we’ll look at the choices for displaying facet values (e.g. hyperlinks, checkboxes, etc.) along with some of the other key design fundamentals.
Published at DZone with permission of Tony Russell-rose, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.