Posts Tagged ‘Facets’

The conference season is indeed in full swing: two weeks ago we had HCIR in California and last week we had Enterprise Search Europe in London closely followed by the Industry Day at CIKM in Glasgow. So much to report back on! I wasn’t able to attend HCIR in person this year (it’s a long way to go for one day), but ex-Endeca colleagues Joe Lamantia, Mark Burrell and I had a poster accepted, which is included as part of the proceedings. The paper describes a revised version of the study we presented at EuroHCIR 2011, updated following very useful feedback from the reviewers (there’s actually a longer story to that which I’ll cover in a future post).

I’ve included the paper below in its entirety. It’s also available in pdf form from the HCIR website.


Classic IR (information retrieval) is predicated on the notion of users searching for information in order to satisfy a particular “information need”. However, it is now accepted that much of what we recognize as search behaviour is often not informational per se. Broder (2002) has shown that the need underlying a given web search could in fact be navigational (e.g. to find a particular site) or transactional (e.g. through online shopping, social media, etc.). Similarly, Rose & Levinson (2004) have identified the consumption of online resources as a further common category of search behaviour.

In this paper, we extend this work to the enterprise context, examining the needs and behaviours of individuals across a range of search and discovery scenarios within various types of enterprise. We present an initial taxonomy of “discovery modes”, and discuss some initial implications for the design of more effective search and discovery platforms and tools.


Read Full Post »

Last week I announced the line-up for Search Solutions 2011, to be held at BCS London on Weds November 16. But this year, for the first time, we’re also offering a Tutorial Programme, which will run the day before (November 15). This year’s programme consists of two half day-tutorials:

You can register for either or both tutorials, and there is a discount available if you register for Search Solutions at the same time. Jun Wang will be providing further details of the first tutorial on his blog, and I’ve appended further details of mine below. Full details of pricing and registration are available on the Search Solutions website. Hope to see you there!


This tutorial explores the fundamental concepts and principles of User-Centred Design for information search and discovery and demonstrates how to apply them in a range of practical contexts. Participants will learn how to differentiate between various types of search behaviour, develop an understanding of the key dimensions within the search user experience, and discover how to apply UI design patterns to commercial search applications. The session concludes with a group exercise applying these skills to a range of practical design challenges.


The aim of this tutorial is to deliver a learning experience grounded in good scholarship, integrating the latest research findings with insights derived from the practical experience of designing and optimizing an extensive range of commercial search applications.  It focuses on the development of transferable, practical skills that can be learnt and practiced within a half-day session.


Participants in this tutorial will:

  • Explore the fundamental concepts and principles of Human-Centred Design for information search and discovery
  • Study models of human information-seeking behavior and how to apply interaction design principles based on those models
  • Learn how to differentiate between various types of search behaviour: known-item, exploratory, lookup, learning, investigation, etc. and understand how they may be combined to form composite search strategies and patterns
  • Develop an understanding of the key dimensions of user type, goal, context and mode of interaction, and how to apply these dimensions when designing for different user contexts
  • Understand the role of design patterns, and how to apply UI design principles and patterns from various libraries in designing search user interfaces
  • Gain an awareness of the key design resources available within the HCIR community and how to apply these to practical design challenges


  • Information architects and user experience designers
  • Developers and managers of search projects
  • IR researchers and other search specialists interested in the designing more effective user experiences for information retrieval and discovery


This half-day tutorial is structured as follows:

  1. Introductions and objectives
  2. Understanding Search & Discovery Behaviour
  3. Varied Solutions for Varied Contexts
  4. Faceted Navigation & Search
  5. UI Design Pattern Libraries
  6. Group Exercise: UX Review
  7. Group Exercise: UX Review (Feedback & Presentations)
  8. Conclusions & Wrap-up

NOTE: to get the best out of this tutorial, participants should bring an Internet-enabled laptop.


Tony Russell-Rose is founder and director of UXLabs, a consultancy specialising in user experience research, design and analytics. Before founding UXLabs he was Manager of User Experience at Endeca and editor of the Endeca UI Design Pattern Library, a resource dedicated to best practice in the design of search and discovery experiences. Prior to this he was technical lead at Reuters, specialising in advanced user interfaces for information access and search. And before Reuters he was Group Manager at Canon Research Centre Europe, where he led a team developing next generation information access products and services. Earlier professional experience includes a Royal Academy of Engineering fellowship at HP Labs and a Short-term Research Fellowship at BT Labs.

His academic qualifications include a PhD in human-computer interaction, an MSc in cognitive psychology and a first degree in engineering, majoring in human factors. He also holds the position of Honorary Visiting Fellow at the Centre for Interactive Systems Research, City University, London. He is currently vice-chair of the BCS Information Retrieval group and chair of the IEHF Human-Computer Interaction group.

Related Posts:

  1. Search Solutions 2011: lineup announced!
  2. Search Solutions 2010: Reactions & Reflections
  3. Designing the Search Experience (tutorial at ECIR 2010)
  4. ECIR Industry Day – lineup announced
  5. Search Solutions 2010: Topics & Titles

Read Full Post »

1. Introduction

Faceted search offers tremendous potential for transforming the search experience. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple fact retrieval to complex exploratory search and discovery-oriented problem solving. But how do we extend such a framework to accommodate not just dozens of facet values, but thousands, or even tens of thousands? It is clearly not practical to display such lists in their entirety. So how can we provide adequate flexibility yet ensure that the user is not overwhelmed in these situations? In this post, we’ll examine the main approaches. In so doing I’d like to acknowledge the work of James Kalbach, whose previous posts on the subject may be the first attempt to document the topic in a comprehensive manner.

2. Display formats and scalability

In previous posts we reviewed a number of display formats for facets and whether their default state should be open or closed by default. A key principle to emerge from that discussion is that it is important for facets to offer an appropriate information scent, i.e. revealing their content and providing navigational cues to help users to formulate productive search strategies. In practice, this means that facets should ideally be open by default, and display a representative sample of facet values. Of course, exactly what constitutes ‘representative’ can be defined in many ways, but in effect this usually entails ordering the list of values by frequency (or some other measure of popularity) and then displaying the first half dozen or so. This raises the question: if the user does want to see the full list of values, how do we extend the display to accommodate them?

There are three main solutions to this problem:

  1. Avoid it entirely by displaying the complete list of facet values by default (although this approach is not always applicable for reasons we’ll discuss below)
  2. Use an expandable container that extends on demand to accommodate additional values.
  3. Use a secondary container to display the longer list, with an associated transition to communicate the relationship between the two.

Let’s examine each approach in turn.

3. Display all values by default

The simplest approach to the problem of showing more values is to avoid it completely by displaying the complete list of facet values by default. This is possible if a display format is used that can scale to accommodate lists of arbitrary length, such as a scrollable container. However, it also assumes that the lists of values are bounded in some way to a manageable size. Scroll bars may be infinitely scalable in principle, but in practice few users would wish to deal with lists of more than hundred items or so (and in many cases significantly fewer).

An example of displaying all items by default can be found at Carzone, which by default displays facets in a vertical stack configuration using scrollable containers for lists of greater than a dozen or so (such as Makes & Models in the example below):

Carzone displays all facet values by default

A variation on this approach can be seen at Farnell, which displays facets in the open parametric configuration. This arrangement applies the principle along both axes: the facets themselves are displayed within a horizontal scrollable panel (extending off the screen to the right) and the values within each of the facets are displayed within vertically scrollable containers. All of the scroll bars appear as required (so they are suppressed for facets with fewer than a handful of values):

Farnell displays all facet values by default

4. Expandable Containers

For many applications, however, displaying all facet values by default is not a scalable solution. Instead, a ‘by request’ approach is required. Perhaps the simplest of these approaches is to present an option to expand the facet inline, i.e. extend its dimensions to accommodate a larger set of values. An example of this approach can be found at NCSU libraries, which displays the top 5 values by default, but expands this vertically to accommodate the top 30 when the ‘Show More’ link is selected (as illustrated by the Subject facet in the image below):

NCSU Libraries expands facet values on demand

This approach is conceptually simple; few users would find the transition between states confusing or intrusive. However, one flaw in this particular execution is that there is no option to show fewer values once a facet is expanded, except by closing it completely. Consequently, once two or more facets have been expanded, it is very difficult to review the contents of the remaining facets without repeated scrolling.

A variation on this approach can be seen at Hoovers, whose option to see more values results in a vertical scroll bar appearing within each facet (as illustrated by the Location and Employees facets):

Hoover expands facet values on demand

Again, the approach is conceptually simple, with a straightforward transition between states.

5. Secondary Containers

While the first two approaches display both the collapsed and expanded set of facet values within the same container, a third approach is to display the expanded set in a new container, and communicate the relationship between the two using visual design cues and/or an appropriate transition.

Perhaps the most lightweight variation on this approach is to use a detail overlay to display the full set of facet values adjacent to the original set. Artist Rising’s ‘More Choices’ link, for example, displays the remaining facet values as a secondary list, extending the original set in a contiguous manner. One advantage of this approach is that the sort order is preserved, e.g. in the example below the complete list of Subjects is still presented in descending order of record count:

Artist Rising displays facet values in a secondary list

A variation on this approach can be seen at Food Network, which shows three values by default but presents an option to show more of any facet on request. This approach uses an overlay as before, but instead of displaying just the additional values it displays the entire list:

Food Network displays facet values in a secondary list

This has the advantage the list can now be displayed in alphabetical order (to facilitate visual scanning). Note that in this display the record counts are suppressed, possibly to reduce any confusion that may arise by displaying such counts in an apparently unsorted order (or perhaps just to reduce clutter and allow the alphabetic ordering to be more apparent).

The transition from one sort order to another may introduce something of a cognitive disconnect for some users, although this is mitigated somewhat by the minimal size of the collapsed list. Note also that the contents of the overlay in this case are limited to a maximum of 50 values, presumably to mitigate the overhead of scrolling an extended list.

A somewhat heavier approach is to use a modal overlay to display the full set of facet values. An example of this can be seen at eBay, which uses the overlay to present the complete list of values for each facet in its own pane. This design allows only one facet to be visible at any one time (in keeping with the principles we discussed in the previous post on Interaction Models for Faceted Search). In common with Food Network, this approach limits the display of expanded facets to the top 50 or so:

eBay displays facet values using a modal overlay

Both of the above approaches support the principle of minimising the disruption to the user’s mental flow by staying on the page. A more heavyweight approach is to present the list of values on their own page, which is the approach adopted by Amazon on certain sections of their site (e.g. footwear). The example below shows the use of multi-select facets displayed using checkboxes in a vertical stack configuration, with options to ‘See more’ for both Brand and Seller:

Amazon displays multi-select facets using checkboxes

However, selecting the ‘See more’ option (e.g. for Brand) loads a new page displaying the entire set values for that facet:

Amazon loads a new page to display facet values

Surprisingly, this page presents the options as hyperlinks (rather than checkboxes), which as we have seen in a previous post are better suited to single select facets. Indeed, that is exactly how they behave: selecting one value immediately returns the user to the original results page with that facet value now applied. Interestingly, it seems the list of values attempts to be exhaustive, which can produce some extremely long pages (e.g. such as the list of authors for the entire Books section).

6. Hybrid Approaches: search within facets

In the sections above we discussed the primary approaches to showing more values, such as extending the existing container or displaying a new one. What these approaches have in common is that they allow the user to browse a longer list of values to make further selections. However, an alternative approach exists, which allows the user to search for specific values rather than browse. An example of this can be seen at LinkedIn, which by default displays multi-select facets using checkboxes in a vertical stack configuration:

LinkedIn allows search within facet values

As expected, each of these facets shows the first half dozen or so values by default (ordered by record count), with an option to “Show more…” that extends the list to include the first dozen or so. But what makes this design different is the use of the text field (shown below the Current Company and Location facets). As soon as the user starts to type into this box, an autocomplete dialog appears with up to ten suggested values. In this respect, this design offers a more complete experience than the others above, since it allows the user to either search or browse to select further facet values.

7. Conclusions

Over the last few weeks we’ve looked at some of fundamental design issues in faceted search, such as layout (e.g. where to place the faceted navigation menus) and state (e.g. whether they should be open or closed by default) and display formats. In this article, we’ve complemented that with a review of the various techniques for managing long lists of facet values. This means that the complete list of articles on faceted search design now covers the following topics:

  1. Designing Faceted Search – (part 1: layout & state)
  2. Designing Faceted Search – (part 2: fundamental principles + display formats)
  3. Designing Faceted Search – (part 3: showing more values)
  4. Interaction Models for Faceted Search
  5. Wayfinding and Navigation in Faceted Search

With a subject as rich and complex as faceted search, no review can ever be complete, and there is always more to learn, explore, and debate. And we’re aware that this collection of articles still lacks a comprehensive discussion of the issues surrounding the use of record counts and smart dead ends. But we’d like to think that this article marks the final section for a forthcoming book chapter on designing faceted search.

Of course, if you think we’ve missed any topics or would like to suggest others, then we’d love to hear. Feel free to drop me a line either here or via email at tgr AT uxlabs.co.uk.

Related Posts:

  1. Designing Faceted Search: Getting the basics right (part 2)
  2. A taxonomy of search strategies and their design implications
  3. Designing Faceted Search: Getting the basics right (part 1)
  4. Where am I? Techniques for wayfinding and navigation in faceted search
  5. Interaction Models for Faceted Search

Read Full Post »

Last week I gave a talk at EuroHCIR on “A Taxonomy of Enterprise Search”. Here is the abstract from that talk:

Classic IR (information retrieval) is predicated on the notion of users searching for information in order to satisfy a particular “information need”. However, it is now accepted that much of what we recognize as search behaviour is often not informational per se. For example, Broder (2002) has shown that the need underlying a given web search could in fact be navigational (e.g. to find a particular site or known item) or transactional (e.g. to find sites through which the user can transact, e.g. through online shopping, social media, etc.). Similarly, Rose & Levinson (2004) have identified consumption of online resources as a further category of search behaviour and query intent.

In this paper, we extend this work to the enterprise context, examining the needs and behaviours of individuals across a range of search and discovery scenarios within various types of enterprise. We present an initial taxonomy of “discovery modes”, and discuss some initial implications for the design of more effective search and discovery platforms and tools.

I hope to make the slides available shortly, but if you’d like to see further details in the meantime, then read on. If you prefer, you can download the paper as a pdf. Note that this paper was co-authored with my Endeca colleagues Joe Lamantia and Mark Burrell.


To design better search and discovery experiences we must understand the complexities of the human-information seeking process. Numerous theoretical frameworks have been proposed to characterize this complex process, notably the standard model (Sutcliffe & Ennis 1998), the cognitive model (Norman 1998) and the dynamic model (Bates, 1989). In addition, others have investigated search as a strategic process, examining the various problem solving strategies and tactics that information seekers employ over extended periods of time (e.g. Kuhlthau, 1991).

In this paper, we examine the needs and behaviours of varied individuals across a range of search and discovery scenarios within various types of enterprise. These are based on an analysis of the scenarios derived from numerous engagements involving the development of search and business intelligence solutions utilizing the Endeca Latitude software platform. In so doing, we extend the classic IR concept of information-seeking to a broader notion of discovery-oriented problem solving, accommodating the much wider range of behaviours required to fulfil the typical goals and objectives of enterprise knowledge workers.

Our approach to enterprise discovery is an activity-centred model inspired by Don Norman’s Activity Centred Design, which “organizes according to usage” whereas “…traditional human centred design organizes according to topic, in isolation, outside the context of real, everyday use.” (Norman 2006). This approach is an extension of previous activity-centred modelling efforts which focused on a “captur[ing] a systematic and holistic view of what users need to accomplish when undertaking information retrieval tasks more complex than searching” (Lamantia 2006), employing Grounded Theory to provide methodological structure (Glaser 1967).

In this context, we present an alternative model focused on information discovery rather than information seeking per se, which has at its core an initial taxonomy of the “modes of discovery” that knowledge workers employ to satisfy their information search and discovery goals. We then discuss some initial implications of this model for the design of more effective search and discovery platforms and tools.


The classic model of IR assumes an interaction cycle consisting of four main activities: the identification an information need, the specification of an appropriate query, the examination of retrieval results, and reformulation (where necessary) of the original query. This cycle is then repeated until a suitable result set is found (Salton 1989).

In both the above models, the user’s information need is assumed to be static. However, it is now acknowledged that information seekers’ needs often change as they interact with a search system. In recognition of this, alternative models of information seeking have been proposed. For example, Bates (1989) proposed the dynamic “berry-picking” model of information seeking, in which the information need (and consequently the query) changes throughout the search process This model also recognises that information needs are not satisfied by a single, final result set, but by the aggregation of results, insights and interactions along the way.

Bates’ work is particularly interesting as it explores the connections between the dynamic model and the search strategies and tactics that professional information-seekers employ. In particular, Bates identifies a set of 29 individual tactics, organised into four broad categories (Bates, 1979). Likewise, O’Day & Jeffries (1993) examined the use of information search results by clients of professional information intermediaries and identified three distinct “search modes” or major categories of search behaviour:

  1. Monitoring a known topic or set of variables over time;
  2. Following a specific plan for information gathering;
  3. Exploring a topic in an undirected fashion.

O’Day and Jeffries also observed that a given search would often evolve over time into a series of interconnected searches, delimited by certain triggers and stop conditions that indicate the transitions between modes or individual searches executed as part of an overall enquiry or scenario. Moreover, O’Day & Jeffries also attempted to characterise the analysis techniques employed by the clients in interpreting the search results, identifying the following six primary categories:

  1. Looking for trends or correlations;
  2. Making comparisons;
  3. Experimenting with different aggregations/scaling;
  4. Identifying critical subsets;
  5. Making assessments;
  6. Interpreting data to find meaning.

More recent investigations into the relationship between information needs and search activities include that of Marchionini (2005), who identifies three major categories of search activity, namely “Lookup”, “Learn” and “Investigate”.


The primary source of data in this study is a set of user scenarios captured during numerous engagements involving the development of search and business intelligence solutions utilizing the Endeca Latitude software platform. These scenarios take the form of a simple narrative that illustrates the user’s end goal and the primary task or action they take to complete it, followed by a brief description of their job function or role, for example:

  • “I need to understand a portfolio’s exposures to assess portfolio-level investment mix” (Portfolio Manager)
  • “I need to understand the quality performance of a part and module set in manufacturing and the field so that I can determine if I should replace that part” (Engineering)

These scenarios were manually analyzed to identify themes or modes that appeared consistently throughout the set. For example, in each of the scenarios above there is an articulation of the need to develop an understanding or comprehension of some aspect of the data, implying that “comprehending” may constitute one such discovery mode. Inevitably, this analysis process was somewhat iterative and subjective, echoing the observations made by Bates (1979) in the identification of her search tactics:

While our goal over the long term may be a parsimonious few, highly effective tactics, our goal in the short term should be to uncover as many as we can, as being of potential assistance. Then we can test the tactics and select the good ones. If we go for closure too soon, i.e., seek that parsimonious few prematurely, then we may miss some valuable tactics.”

There are however some guiding principles that we can apply to facilitate convergence on a stable set. For example, an ideal set of modes would exhibit properties such as: Consistency (they represent approximately the same level of abstraction); Orthogonality (they operate independently to each other); and Comprehensiveness (they address the full range of discovery scenarios).

The initial set of discovery modes to emerge from this analysis consists of a set of nine, arranged into three top-level categories consistent with those of Marchionini (2005). The nine modes are as follows, each shown with a brief definition:

1. Lookup

  • Locating: To find a specific (possibly known) item
  • Verifying: To confirm or substantiate that an item or set of items meets some specific criterion
  • Monitoring: To maintain awareness of the status of an item or data set for purposes of management or control.

2. Learn

  • Comparing: To examine two or more items to identify similarities & differences;
  • Comprehending: To generate insight by understanding the nature or meaning of an item or data set;
  • Exploring: To proactively investigate or examine an item or data set for the purpose of serendipitous knowledge discovery.

3. Investigate

  • Analyzing: To critically examine the detail of an item or data set to identify patterns & relationships;
  • Evaluating: To use judgment to determine the significance or value of an item or data set with respect to a specific benchmark or model;
  • Synthesizing: To generate or communicate insight by integrating diverse inputs to create a novel artefact or composite view.

Evidently, the output of this process has been optimized for the current data set and in that respect represents an initial interpretation that will need to evolve further. For example, “monitoring” may appear to be a lookup activity when considered in the context of a simple alert message, but when viewed as a strategic activity performed by an executive in the context of an organisational dashboard, a much greater degree of interaction and complexity is implied. Conversely, “exploring” is a concept whose level of abstraction may prove somewhat higher than the others, thus breaking the consistency principle suggested above.

However, the true value of the modes will be realised not by their conceptual purity or elegance but by their utility as a design resource. In this respect, they should be judged by the extent to which they facilitate the design process in capturing important characteristics common to enterprise search and discovery experiences, whilst flexibly accommodating arbitrary variations in domain, information resources, etc.


A further interesting observation arising from the above analysis is that the mapping between scenarios and modes is not one-to–one. Instead, some scenarios are seen to involve a number of modes, sometimes with a primary or dominant mode, and often with an implied linear sequence. Moreover, certain sequences of modes tend to re-occur more frequently than others, forming specific “mode chains” or patterns, analogous to higher-level syntactic units. These patterns provide a framework for understanding the transitions between modes (echoing the triggers identified by O’Day & Jeffries), and allude to the existence of natural seams that can be used be used to provide further insight into information enterprise search and discovery behaviour.

These mode chains echo the above-mentioned efforts to create goal-based information retrieval models, which yielded modes and a set of broadly applicable “information retrieval patterns that describe the ways users combine and switch modes to meet goals: Each pattern is assembled from combinations of the same four [elemental] modes” (Lamantia 2006).

Figure 1. Discovery mode network

The five most frequent mode patterns are listed below. These have been assigned descriptive (if somewhat informal) labels to aid their characterisation, along with the sequence of modes they represent and an associated example scenario:

  1. Comparison-driven optimization: (Analyze-Compare- Evaluate) e.g. “Replace a problematic part with an equivalent or better part without compromising quality and cost
  2. Exploration-driven optimization: (Explore-Analyze-Evaluate) e.g. “Identify opportunities to optimize use of tooling capacity for my commodity/parts
  3. Strategic Insight (Analyze-Comprehend-Evaluate) e.g. “Understand a lead’s underlying positions so that I can assess the quality of the investment opportunity
  4. Strategic Oversight (Monitor-Analyze-Evaluate) e.g. “Monitor & assess commodity status against strategy/plan/target
  5. Comparison-driven Synthesis (Analyze-Compare-Synthesize) e.g. “Analyze and understand consumer-customer-market trends to inform brand strategy & communications plan

Further insight may be derived by examining how the mode patterns combine across all the scenarios to the form of a “mode network”, as shown in Figure 1. Evidently, some modes act as “terminal” nodes, i.e. entry points or exit points to a discovery scenario. For example, Monitor and Explore feature only as entry points at the initiation of a scenario, whilst Synthesize and Evaluate feature only as exit points to a scenario.


The modes establish a ‘taskonomy’ or collection of defined discovery activities which are structurally consistent, domain and scale independent, orthogonal, semantically distinct, conceptually connected, and flexibly sequenceable.  Such a profile — analogous to notes in the musical scale, or the words and phrases we assemble into sentences — should allow the modes to serve as a language for the design of variable scale activity-centered discovery solutions through common constructive mechanisms such as concatenation, combination and nesting. And if the modes do act as an elementary grammar for discovery, then sustained use as a functional and interaction design language should result in the creation of larger and more complex units of meaning which offer cumulative value.

Professional experience with employing the modes as both an analytical framework for understanding discovery needs and as a design grammar for the definition of discovery solutions suggests that both implications are valid.  Further, our observations of using the modes suggest the existence of recognizable patterns in the design of discovery solutions. We will briefly discuss some of the patterns observed, doing so at three common levels of solution scale: on the level of a single functional or interface element, for whole screens or interfaces composed of multiple functional elements, and for applications comprising multiple screens.

5.1 Single element patterns

5.1.1 Comparison Views

One of the most common design patterns is to support the need for the Compare mode by creating A/B type comparison views that present two display panes – each containing data display charts or tables; or single items or groups of items – side by side to emphasize similarities and differences.

5.1.2 Contextual Views

Another common design pattern supports the Analysis mode by allowing a fore-grounded view of a single chart, table, item, or list, accompanied by its contextual ‘halo’ – the full body of information available about the element such as status, origin, format, relationships to other elements; annotations; etc.

5.2 Whole screen patterns

5.2.1 Dashboard

One of the most common screen-level design patterns is to support the Monitoring and Synthesis modes by presenting a collection of metrics which in aggregate provide the status of independent processes, groups, or progress versus goals in a ‘dashboard’ style screen.

5.2.2 Visual Discovery Screen: 4-Dimensions

A second common screen-level design pattern for discovery experiences is the visual discovery screen, which supports modes such Exploration, Evaluation, and Verification by layering views that present visualizations of several dimensions of a single axis of focus such as a core process, organizational unit, or KPI. When switching between layered views, the axis in focus remains the same, but the data and presentation in the dimensions adjusts to match the preferred discovery mode.

5.3 Application-level patterns

5.3.1 Differentiated Application

The ‘Differentiated Application’ pattern assembles a collection of individual screens whose distinct compositions and designs support individual discovery modes of Analysis, Comparison, Evaluation and Monitoring in aggregate to address the ‘Strategic Oversight’ mode sequence. Application-level patterns often address a spectrum of discovery needs for a group of users with differing organizational responsibilities, such as management vs. detailed analysis.


The above analysis is predicated on the notion that the user scenarios provide a unique insight into the information needs of enterprise knowledge workers. However, a number of caveats apply to both the data and the approach.

Firstly, the scenarios were originally generated to support the development of a specific implementation rather than for the analysis above. Therefore, the principles governing their creation may not faithfully reflect the true distribution or priority of information needs among the various end user populations.  Secondly, the particular sample we selected for this study was based on a number of pragmatic factors (including availability), which may not faithfully represent the true distribution or priority among enterprise organizations. Thirdly, the data will inevitably contain some degree of subjectivity, particularly in cases where scenarios were generated by proxy rather than with direct end-user contact. Fourthly, the data will inevitably contain some degree of inconsistency in cases where scenarios were documented by different individuals.

We should also acknowledge a number of caveats concerning the process itself. In inductive work with foundations in qualitatively centered frameworks such as Grounded Theory, it is expected that a number of iterations of a “propose-classify-refine” cycle will be required for the process to converge on a stable output (e.g. Rose & Levinson, 2004). In addition, those iterations should involve a variety of critical viewpoints, with the output tested and refined using a separate, independent sample on each iteration. Likewise, the process by which scenarios are classified would benefit from further rigour: this is a critical part of the process and of course relies on human judgement and inference, but that judgement needs to go beyond simple word matching and be consistently applied to each scenario so that subtle distinctions in meaning and intent can be accurately identified and recorded.

That said, some interesting comparisons can already be made with the existing frameworks. For example, the first and third of the search modes suggested by O’Day and Jeffries have also been identified as distinct discovery modes in our own study, and the second (arguably) maps on to one or more of the mode chains identified above. Likewise, the search results analysis techniques that O’Day & Jeffries identified also present some interesting parallels.


To design better search and discovery experiences we must understand the complexities of the human-information seeking process. In this paper, we have examined the needs and behaviours of varied individuals across a range of search and discovery scenarios within various types of enterprise. In so doing, we have extended the classic IR concept of information-seeking to a broader notion of discovery-oriented problem solving, accommodating the much wider range of behaviours required to fulfil the typical goals and objectives of enterprise knowledge workers.

In addition, we have proposed an alternative model focused on information discovery rather than information seeking which has at its core a taxonomy of “modes of discovery” that knowledge workers employ to satisfy their information search and discovery goals. We have also examined some of the initial implications of this model for the design of more effective search and discovery platforms and tools.

Suggestions for future work include further iterations on the “propose-classify-refine” cycle using independent data. This data should ideally be acquired based on a principled sampling strategy that attempts where possible to address any biases introduced in the creation of the original scenarios. In addition, this process should be complemented by empirical research and observation of knowledge workers in context to validate and refine the discovery modes and triggers that give rise to the observed patterns of usage.


[1]     Bates, Marcia J. 1979. “Information Search Tactics.” Journal of the American Society for Information Science 30: 205-214

[2]     Bates, Marcia J. 1989. “The Design of Browsing and Berrypicking Techniques for the Online Search Interface.” Online Review 13: 407-424.

[3]     Broder, A. 2002. A taxonomy of web search, ACM SIGIR Forum, v.36 n.2, Fall 2002

[4]     Kuhlthau, C. C. 1991. Inside the information search process: Information seeking from the user’s perspective. Journal of the American Society for Information Science, 42, 361-371.

[5]     Lamantia, J. 2006. “10 Information Retrieval Patterns” JoeLamantia.com, http://www.joelamantia.com/information-architecture/10-information-retrieval-patterns

[6]     Glaser, B. & Strauss, A. 1967. The Discovery of Grounded Theory: Strategies for Qualitative Research. New York: Aldine de Gruyter.

[7]     Marchionini, G. 2006. Exploratory search: from finding to understanding. Commun. ACM 49(4): 41-46

[8]     Norman, Donald A. 1988. The psychology of everyday things. New York, NY, US: Basic Books.

[9]     Donald A. Norman. 2006. Logic versus usage: the case for activity centered design. Interactions 13, 6

[10]   O’Day, V. and Jeffries, R. 1993. Orienteering in an information landscape: how information seekers get from here to there. INTERCHI 1993: 438-445

[11]  Rose, D. and Levinson, D. 2004. Understanding user goals in web search, Proceedings of the 13th international conference on World Wide Web, New York, NY, USA

[12]  Salton, G. (1989). Automatic Text Processing: The Transformation, Analysis, and Retrieval of Information by Computer. Addison-Wesley, Reading, MA.

[13]  A.G. Sutcliffe and M. Ennis. Towards a cognitive theory of information retrieval. Interacting with Computers, 10:321–351, 1998.

Related Posts:

Read Full Post »

1. Introduction

In our last post we looked at some of the fundamental issues in designing faceted search such as layout (e.g. where to place the faceted navigation menus) and state (e.g. whether they should be open or closed by default). In this post, we continue the mini-series with a review of the various formats for displaying facets and the key principles for choosing between them.

2. Fundamental Principles

2.1 Facets and Search

Before we get into the detail of display formats, we should first establish some basic terminology. Facets are essentially independent properties or dimensions by which we can classify an object. For example, a book might be classified using an Author facet, a Subject facet, a Date facet, and so on. Faceted search enables users to intuitively explore information spaces by progressively refining their choices in each dimension. So for example, we could explore a collection of books by selecting a specific Author, Subject, or Date range, and so on. Selections are made by applying facet values which update the navigational context, i.e. the user’s current location in the information space. The navigational context then defines the set of records returned for a given query, and the facet values that are applicable to that result set. This leads us to our first principle:

  • Principle 1: Display only currently available facet values.

By observing this principle, we provide a search experience that guides users toward meaningful navigational choices and avoids the possibility of zero results. (Note that there are exceptions to this such as the use of Smart Dead Ends, which we’ll discuss in a later post).

2.2 Facet Semantics

Facets can be either single-select or multi-select. In the former case, the facet values are assumed to be mutually exclusive, i.e. only one may be applied at any given time. For example, a given copy of book may be assumed to have only one location: if it is in Library X, then by definition it cannot be simultaneously in Libraries Y or Z. This facet is therefore single-select. Conversely, some facets represent values which are *not* mutually exclusive, i.e. more than one may apply at any given time. For example, a given book may have more than one Author: if it is co-edited by Professor X, then it could also be simultaneously co-edited by Professors Y and Z. This facet is therefore multi-select.

Multi-select facets can either be multi-select OR or multi-select AND. In the first case (OR), we assume that the values are combined disjunctively, e.g. a given book may have been published in either 2001, 2002 OR 2003. In the second case (AND), we assume that the values are combined conjunctively, e.g. a given book may have been co-authored by Professors X, Y AND Z. Multi-select AND tends to be somewhat rarer in faceted search, as it implies that selected facet values only make sense when applied in their totality. A typical example is purchasing a car: if the user specifies that they are looking for features A, B and C, the assumption is that they want ALL of these features to be present on EVERY record (e.g. air con AND sat nav AND sunroof), rather than just a subset of them (e.g. air con OR sat nav OR sunroof). Strictly speaking, if we accept the definition of facets as comprising mutually exclusive attributes, then a multi-select AND facet is actually a collection of individual Boolean facets that are grouped together for pragmatic reasons.

2.3 Facet States and Behaviours

By convention, values applied across different facets are normally applied conjunctively (e.g. Author A and Subject B and Date C) whereas values applied within a given facet are normally applied disjunctively (Date X or Date Y or Date Z). Facet values can be removed as well as applied. There are various ways to achieve this, but the principle is the same: the user deselects an applied value and the navigational context is updated accordingly.

Facets change their state and available values to reflect the current navigational context. For example, if the user selects a particular Location, then the other values for Location are no longer applicable to the current result set (since this facet is single-select). In some faceted search applications, this facet would be ‘refined away’, i.e. removed from display since there are no further choices to be applied.  (Of course, if the user changes the navigational context by removing the applied value, the facet should re-appear.)

Facets can also enter a kind of ‘passive’ state indirectly. For example, the values applied in Facet A may result in the available values in Facet B being reduced to a singleton. In our library example, if we select books authored by Professor Smith, we may discover that the only applicable Date is 2002. Applying that single value would not change the navigational context as it applies equally to all records in the current result set. In some faceted search applications, facets in this state are also removed from display.

3. Displaying facet values

We discussed above how facets are essentially independent properties by which we can classify an object. Conceptually, each of these facets is based on an underlying data type, e.g. in our book collection, the values for Author could be stored as text (i.e. character strings), the values for Subject could be one or more terms from a controlled vocabulary, the values for Date could be stored as long integers, and so on. Such decisions shape the underlying architecture of faceted search applications. But how should such facets be displayed to the end user, and what kind of interactivity should be provided? Ideally, the display format should reflect and communicate the nature of the underlying data. This leads us to our second principle:

  • Principle 2: Match the display format to the semantics of the facet values.

Facets can be used to express a wide variety of data types, and consequently there is a wide variety of available display formats. In the following section, we examine some of the main options.

3.1 Hyperlinks

Hyperlinks are probably the most common technique for representing facet values. They provide a simple and direct mechanism for representing textual values, and afford interaction through direct selection (e.g. via a mouse click). The example below from Food Network shows a typical faceted navigation menu, with the facets arranged in a vertical stack configuration. Each of the ten facets contains values that are essentially textual in nature, so as such are ideal for display using hyperlinks.

Hyperlink facets at Food Network

One of the reasons for the popularity of hyperlinks is their simple interaction model: the user selects a value, and the system responds by applying that value as a refinement to the current navigational context. So in the example above, if the user selects Content Type=Recipe, the result set is updated to include only recipes (and the breadbox is updated to show this selection). Likewise, if the user selects Course=Main Dish, the results are updated to include only recipes for main dishes.

This simple example also illustrates the one of the design behaviours mentioned above: single select facets are ‘refined away’ after being applied. For example, once a value for Content Type has been applied, the facet disappears. Likewise, once a value for Course has been selected, the facet disappears. The end result is that the faceted menu shrinks as further refinements are applied.

Note that multi-select facets require a different behaviour: in this case, the assumption is that more than one value from each facet may be simultaneously applied, so the individual facets need to remain visible for further selections to be made by the user.

This raises an interesting question: if Food Network did want to make their existing facets multi-selectable (and there is little inherent in their semantics to preclude such a possibility), could they continue to use the hyperlink format and simply continue to display each facet following a selection? There is no technical reason why this cannot be done – in fact, we see such an example at NCSU libraries:

Hyperlink facets at NCSU Libraries

In this example, the user can select multiple Subjects, Genres, Formats, and so on, and these are added to the navigational context each time.

But there are two reasons why hyperlinks are not the ideal display format for multi-select facets. First, there is the issue that they are by convention typically used to display single-select facet values, and offer a strong affordance of single-select behaviour. Secondly, there exists an alternative display mechanism that is specifically designed to support multiple selections from a number of options: the checkbox.

3.2 Checkboxes

Checkboxes are an ideal format for the display of multi-select facets. An example of their use of can be found at many sites, including eBay:

Checkbox facets at eBay

Checkboxes support multiple selection and the communication of navigational state through inline breadcrumbs. In this example, the user can select multiple models (e.g. Golf OR Jetta) and multiple model years (2009 OR 2008 OR 2007) and these choices are displayed inline as selected checkboxes.

A discussion of the negative consequences of using hyperlinks and checkboxes inappropriately can be found at UXMatters. However, this article itself conflates the issue of facet semantics (single-select vs. multi-select) with that of display mechanism (hyperlinks vs. checkboxes). Although there are dependencies between these two issues, they are in fact separate: the first reflects the conceptual data model, the second the desired user experience. A more informed design approach would recognize this distinction.

3.3 Range Sliders

In the examples above, the facet values are essentially categorical in nature, i.e. qualitative data organised on a nominal or ordinal scale. But facets often need to display quantitative data, such as price ranges, product sizes, date ranges and so on. In such cases a range slider is often a more suitable display mechanism. An example of their use can be found at Molecular’s Wine Store:

Range sliders at Molecular

This example shows the use of sliders for quantitative data such as of Price, Expert Score, User Rating and for interval data such as Vintage. Note also that this example uses single ended sliders for the first three but double-ended for the latter. The rationale here is that most users would only be interested a maximum value for price, or a minimum value for Expert Score and User Rating. Conversely, they may be interested in both a start date and an end date for a particular range of vintages (using both a maximum and a minimum).

This example also illustrates how the basic slider can be overlaid with supplementary information such as a histogram showing the distribution of record counts across the range. This helps the user understand the overall information space by providing them with a global view of the ‘landscape’ within each facet, guiding them toward more meaningful and productive selections.

3.4 Input Boxes

One of the disadvantages of sliders is that that they offer a relatively coarse level of control over the values. In the Molecular example, it may be relatively easy to specify a precise pair of dates, as the entire scale spans just 20 years or so (1986 to 2006). However, quantitative values can of course extend over much greater intervals, in which case sliders start to become cumbersome and awkward to use accurately. Consequently, sliders often appear paired with input boxes, which allow the direct entry of arbitrary values along a quantitative range. An example of this can be seen at Glimpse.com, in which a query for ‘shoes’ returns results across a relatively wide price range:

Input boxes at Glimpse

With a range as wide as $15 to $470, specifying a precise value much easier using the input boxes than using the slider.

Sometimes it is appropriate to transform the semantics of one data type into another. For example, quantitative data can be transformed into an interval scale by subdividing the range into a sequence of smaller ranges and giving each a label. This is the approach taken by Amazon in their treatment of price ranges:

Interval scales at Amazon

Note that the intervals need not be of equal size: in Amazon’s case, they divide the overall range into five ‘bins’ of differing size, in what may be a strategy to smooth the distribution of record counts within each range (we’ll discuss the issue of displaying bin counts in a later post). Alternatively, this may simply be a reflection of the price points found to be uppermost in shopper’s minds when they browse these particular products.

3.5 Colour Pickers

In the above examples we’ve discussed how the choice of display format is shaped by the semantics of the underlying data and the user experience we wish to provide. In this respect, colour pickers are perhaps the ultimate custom control: they are designed exclusively to represent the visual dimension of colour. However, there are various ways in which this can be executed.  Littlewoods, for example, displays a colour swatch with associated text labels, and shows only values that are specific to the current result set:

Colour picker at Littlewoods

Artist Rising, by contrast, uses a generic colour picker, offering a choice across a continuous colour spectrum:

Colour picker at Artist Rising

Although the user has great flexibility in selecting a precise colour value, the corollary is that it is easy for the user to select an illegal value (i.e. one which is not available within the current result set). In this respect, this approach violates Principle 1 above.

An alternative to the colour picker is to simply use text labels for each value, and this approach is surprisingly common (being widely used by both Amazon and eBay). The challenge is, of course, to select textual labels that are going to be meaningful to the end user and also faithfully represent the appearance of the item itself. Inevitably, once the range extends beyond basic primary and secondary colours, such mappings start to become increasingly tenuous.

3.6 Tag Clouds

A decade or so ago, there was no such thing as a tag cloud – at least, not outside of a few research labs and data visualization projects. Then along came Flickr, Delicious and a host of other online community sites with vast repositories of user-generated and user-tagged content. Tag clouds, with their ability to represent measures such as tag frequency and popularity in a visually appealing manner, rapidly became the standard technique for displaying and exploring such content. Soon, their use was extended to include unstructured content, displaying clouds of terms extracted from text documents.

A decade on, we seem to have come full circle. Perhaps victims of their own popularity, tag clouds are becoming an increasingly rare part of the faceted search experience. One of the few remaining examples can be found at Artist Rising, which displays a tag cloud as a dialog overlay within a horizontal faceted menu:

Tag clouds at Artist Rising

As tags are selected, they are added to the breadbox alongside other refinements. (Unusually, the tag cloud in this implementation appears to allow only a single value to be applied, which rather weakens their essential value.)

A somewhat different treatment can be found at PC Authority, which uses tag clouds to present terms extracted from unstructured content (i.e. text documents). These are displayed in a separate container which is disconnected (conceptually and physically) from the left hand faceted navigation menu. As tags are selected, they are added to the breadbox alongside other refinements:

Tag clouds at PC Authority

Unlike Artist Rising, the tag cloud in this implementation supports multiple refinements, updating its own contents on each iteration.

3.7 Data Visualizations

In each of the above examples the records have been considered as unique entities, i.e. the goal of the search experience is locating and then viewing one or more individual records. In this context, the role of the facet values is primarily to facilitate that process; to smooth the journey from initial query to product record. But an increasing number of applications are concerned with understanding patterns inherent in the collection at a much higher level, where the focus is not on locating individual records but on understanding patterns of distribution and occurrence at an aggregate level. In these applications, the facets play a much more central role in the discovery experience, with the focus shifting from findablity to broader tasks such as analysis, sensemaking and discovery-oriented problem solving.

Applications such as this are designed to aggregate, organize, and summarize data from a variety of quantitative and qualitative sources, using data visualizations to communicate key metrics, patterns, and overall status. An example of such a visualization could be found at Newssift (illustrated below, but since closed), in which pie charts were used to communicate the distribution of Article Sources and associated Sentiment:

Data visualizations at Newssift

In common with hyperlinks, these visualizations provide a simple interaction model: the user selects a value (e.g. by mouse click), and the system responds by applying that value as a refinement to the current navigational context. But more importantly, the facets provide an instant overview of the aggregate distribution for each set of values: we can see at a glance, for example, that the majority of sentiment is positive, and that the majority of articles are sourced from Online News. Of course, this insight could also be facilitated by other display formats, but a well-chosen visualization will do this much more effectively than the more traditional display formats discussed above. (As an aside, the choice of pie charts here is somewhat questionable, but the principle of using visualizations to communicate key metrics is the central point.)

Another common use of data visualisation in faceted search is to communicate patterns in geospatial data. An example of this can be found at WITS (the Worldwide Incidents Tracking System), which uses various forms of visualization to display terrorist incidents overlaid on a map of the world:

Data visualization at WITS

Visualizations such as this allow users to perceive spatial patterns in record distribution and explore relationships between particular facets (rendered as hyperlinks in the upper panel) and aggregate distributions across the map. However, the interaction model in this implementation is somewhat different to Newssift, in that selecting an item on the map (e.g. a cluster in the rendering above) appears to centre and zoom the map on that region, rather than applying the selected item as a refinement. In this respect, the visualization is not behaving as a facet in the strict sense, but it nonetheless allows the end user to productively explore patterns at the aggregate record level.

4. Conclusions

Over the last few weeks we’ve looked at some of fundamental design issues in faceted search, such as layout (e.g. where to place the faceted navigation menus) and state (e.g. whether they should be open or closed by default). In this article, we’ve complemented that with a review of the many formats for displaying facets and the key principles for choosing between them. In our next post, we’ll round out this mini-series with a look some of the remaining design fundamentals including display scalability (i.e. techniques for managing long lists of facet values).

Related Posts:

Read Full Post »

I’m pleased to announce the final line up for the EuroHCIR 2011 workshop, which will be held as part of the BCS HCI Conference in Newcastle on July 4. This event is particularly significant as it represents the first major HCIR event to be held outside of the US, and as such represents a critical point in the development of the HCIR community in Europe. We’re just in the process of finalizing the programme, which will include 9 presentations, a keynote speaker (to be announced) and a poster session. We also hope to include an interactive group session in the afternoon – more on that later! In the meantime, I’ve appended the full list of accepted papers below. More details on the EuroHCIR website. Hope to see you there.

Accepted Papers for Oral Presentation

  • The potential of Recall and Precision as interface design parameters for information retrieval systems situated in everyday environments
    Ayman Moghnieh and Josep Blat
  • The Mosaic Test: Benchmarking Colour-based Image Retrieval Systems Using Image Mosaics
    William Plant, Joanna Lumsden and Ian Nabney.
  • Exploratory Search in an Audio-Visual Archive: Evaluating a Professional Search Tool for Non-Professional Users
    Marc Bron, Jasmijn Van Gorp, Frank Nack and Maarten De Rijke
  • A Taxonomy of Enterprise Search
    Tony Russell-Rose, Joe Lamantia and Mark Burrell
  • Evaluating the Cognitive Impact of Search User Interface Design Decisions
    Max L. Wilson
  • Supplying Collaborative Source-code Retrieval Tools to Software Developers
    Juan M. Fernández-Luna, Juan F. Huete and Julio Rodriguez-Cano
  • Problem Solved: A Practical Approach to Search Design
    Vegard Sandvold
  • Back to MARS: The unexplored possibilities in query result visualization
    Alfredo Ferreira, Pedro B. Pascoal and Manuel J. Fonseca.
  • Interactive Analysis and Exploration of Experimental Evaluation Results
    Emanuele Di Buccio, Marco Dussin, Nicola Ferro, Ivano Masiero, Giuseppe Santucci and Giuseppe Tino

Accepted Posters

  • Towards User-Centered Retrieval Algorithms
    Manuel J. Fonseca
  • Design Thinking Search User Interfaces
    Arne Berger
  • The Development and Application of an Evaluation Methodology for Person Search Engines
    Roland Brennecke, Thomas Mandl and Christa Womser-Hacker

Related Posts:

  1. From Search to Discovery: a taxonomy of search tasks, modes and activities
  2. Designing faceted search: Getting the basics right (part 1)
  3. Where am I? Techniques for wayfinding and navigation in faceted search
  4. Interaction Models for Faceted Search
  5. Reflections on Faceted Search and Beyond

Read Full Post »

1. Introduction

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 interaction models and 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 James Kalbach, and in particular his tutorial on faceted search design, which provides an excellent framework for many of the key principles outlined below.

2. Layout

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:

Vertical stack faceted navigation at eBay

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):

Facets on the right at Edinburgh University Library

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:

Horizontal facets at 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):

Facets wrap across the page at Amphenol

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):

Hybrid layout at TravelMatch

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 information scent 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:

Facets open by default at 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:

Open and closed facets 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:

Facetes open for query disambiguation at eBay

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:

Facets now open and closed at eBay

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 breadbox) to communicate the current navigational state. If inline breadcrumbs 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.

Related Posts:

  1. Where am I? Techniques for wayfinding and navigation in faceted search
  2. Interaction Models for Faceted Search
  3. Reflections on Faceted Search and Beyond
  4. Tutorial on Designing the Search Experience
  5. From Search to Discovery

Read Full Post »


Faceted search offers tremendous potential for transforming search experiences. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple lookup and fact retrieval to complex exploratory search and discovery scenarios. In recognition of this, UX designers are now starting to embrace its potential and have published many excellent articles on a variety of design issues, covering topics such as facet structure, layout & display, selection paradigm, and many more.

The purpose of this article is to explore one aspect that has received somewhat less attention than most: the interactive behaviour of the facets themselves, i.e. how they should respond and update when selected. Surprisingly, the design choices at this level of detail can make a remarkable difference to the overall user experience: the wrong choices can make an application feel disjointed and obstructive, and (in some cases) increase the likelihood of returning zero results. In this post, we’ll examine the key design options and provide some recommendations.

Design Principles and Interaction Models

One of the fundamental principles of faceted search is that the set of facet values displayed at any given time should be constrained to those for which results are currently available. Consequently, it should not normally be possible for a user to obtain zero results through the selection of individual facet values alone. (Note however that there are circumstances under which a zero result set can become unavoidable, but we’ll cover that in a future post.)

For example, in the example from computer manufacturer Dell shown below, we can see that there are seven laptop products that match the specification Screen=’small’ AND price=£400-800. Note that by convention, values from different facets are usually applied conjunctively, i.e. using AND rather than OR. At this point, the user can widen their search to include other screen sizes, such as Standard, Large, etc. or other price ranges; such as e.g. Up to £400. Note that the facets in this design also communicate values which would have been available had the initial selections not been made: i.e. the other Processor options which are currently disabled (and rendered in pale grey). These are sometimes referred to as Smart Dead Ends, and we’ll discuss these further in a future post.

Faceted search at Dell


The point is that in each case, the user can only select values for which results are currently available. This is made possible by applying the following interaction design principle: that the set of results and facet values should update immediately as soon as any selection is made.  By observing this principle, the result set and available facet values remain consistent and accurately reflect the products available to the user at any given time.

This “instant update” model is very common, and forms the basis of many faceted search experiences. Another such example is the travel site Kayak, which combines traditional facet selection options in the form of categorical values (rendered using hyperlinks or check boxes) with quantitative values that are rendered in this case using sliders (e.g. the Flight times):

'Instant update' interaction model at Kayak


Incidentally, note that the Price range data on dell.com could also have been rendered using sliders, and likewise the Flight times on kayak could have been converted to an ordinal scale. There are advantages and disadvantages to each approach, and exactly which to choose will depend on a number of factors.

It is when we start to examine such ‘non-traditional’ facets that the limitations of the Instant Update model become apparent: in this case, each of the sliders is double-ended, and in many scenarios it will feel more natural for users to adjust both ends as part of a single interaction. But of course this is not possible: the user must wait for an update to take place in between each selection. Furthermore, in cases where the sliders provide only a coarse level of selection over the underlying data, it is likely that some degree of iteration with these controls will be required.

But there is an alternative approach. In the example below, computer equipment supplier CDW allows the users to “cherry pick” multiple facet values in a single iteration, and then submit them en masse via the View Results button:

Two-stage facet selection at CDW


The advantage now is that a user can select as many values as they like without interruption, and choose to view the results when they are ready. But the disadvantage is equally apparent – this style of interaction is in effect a type of parametric search, and in many instances (including the one above) this can return zero results. In the example shown, there are simply no products available that match the selection of Brand=(Apple OR Asus) AND Type=(Tablet PC OR UltraPortable). The user is thus forced to remove the facet selections one by one until a legitimate combination is found (or they just clear them all and start again).

Upon reviewing the above example it would be easy to conclude that the “two-stage” interaction model is fundamentally flawed, as it allows facet selections and result sets to become ‘out of sync’. But there is more to it than that. In fact, the shortcoming with this design is not the two-stage model per se – it is the combination of this model with the design decision to allow the end user to arbitrarily open and close facets at will. In the above example, the range of values revealed when the user opens the Notebook Type facet is not updated to reflect any selections already applied, and thus it breaks the fundamental principle described in the opening section. The inevitable result is that ‘illegal’ combinations of facet values can be selected and these will return zero results.

So how can this be avoided? Automotive classified site Carzone provides one such example. In the figure below, we see a similar instance of the two-stage model, with each facet allowing selection of multiple values and an Update button provided to submit them en masse:

Two-stage facet selection at Carzone


But the difference this time is that the user does not have the ability to arbitrarily open and close facets at will: instead, opening one facet will, by default, close any other. This crucial difference means that when a facet is opened, its values can be updated to be consistent with the current result set and any facet values applied thus far. So in the example above, if the user chooses to apply values from another facet such as Body Type, as soon as the facet is opened it will be updated to show only values which are consistent with those applied thus far, i.e. Make&Model=(Audi A2 OR Audi A3 OR Audi A4). A dialogue overlay is used to remind users to choose whether to commit any values selected thus far (although by default they will always be applied unless explicitly cancelled).

So which of the two approaches (instant update and two-stage) is to be preferred? As we have seen from the examples above, they both have their strengths and weaknesses. Indeed, it is possible to offer both approaches, and let the user decide which interaction model they prefer. In the example below electronic component distributor Farnell does exactly this, offering a checkbox to “Auto Apply filters to update results dynamically” which applies the instant update model to the facets (shown here in the Open Parametric configuration), and a “Show Results” button to refresh the results pane with the currently selected values.

User-selectable interaction model at Farnell


Multi-select AND vs. multi-select OR

Note that the facet values examined in the two-stage examples above are disjunctive (multi-select OR), e.g. the selection of a value for a facet such Make & Model does not preclude the selection of another value from the same facet. In this case, selecting multiple independent facet values has the effect of widening the search. However, if the facet values are conjunctive (multi-select AND), then the choice of which interaction model to apply is quite different. An example of a typical conjunctive facet would be ‘features’ (e.g. air con, alloy wheels, sat nav, etc.), as these only meaningful when applied as a conjunctive set (i.e. the results should match cars with ALL these features, not just one or more of them).  In this case, the facet values are no longer independent, as selecting one value directly affects the number of results for which the other features also apply. In this case, the only meaningful interaction model is the instant update, as this is the only approach which will ensure that facet values and the current result set stay in sync.

Interstitial Pages

It is interesting also to compare the various approaches to interstitial pages, i.e. the messaging that is provided to indicate that the facets are being updated and results retrieved. Dell, for example, leaves the facets in situ but reloads the entire results pane, which inevitably introduces something of a cognitive disconnect between the two result sets. CDW takes this further by refreshing the entire page and discarding the open/closed state of the facets, thus introducing an even greater degree of disruption to the user’s mental flow. Kayak and Carzone both adopt a more lightweight approach, providing an “Applying your filter choices” overlay but otherwise ensuring that any updates stay on the page.

But possibly the most sophisticated interstitial treatment is that found at LinkedIn, which provides a semi-transparent mask over all the elements that need to be refreshed (e.g. the results pane and any facets other than the one the user just applied) but other than that keeps the disruption to a minimum:

Interstitial search page at LinkedIn



Faceted search offers tremendous potential for transforming search experiences. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple lookup and fact retrieval to complex exploratory search and discovery scenarios.

In this post, we have explored the detail of how facets should respond and update when selected. We have introduced two alternative interaction models, and reviewed their strengths and weaknesses and how they apply to different types of facet values (e.g. conjunctive and disjunctive). We’ve also reviewed some alternative approaches to the design of interstitial pages.

In an upcoming post, we’ll extend the above to explore some of the main approaches to communicating and managing navigational state in faceted search.

Related Posts:

  1. Reflections on Faceted Search and Beyond
  2. Tutorial on Designing the Search Experience
  3. From Search to Discovery
  4. Design Patterns for Spatial Information Visualisation and Analytics Applications
  5. Is search behaviour becoming more sophisticated?

Read Full Post »

If you’re interested in search and user experience and would like to know more about the science underpinning these disciplines, here’s an ideal opportunity: the 1st European Workshop on Human-Computer Interaction and Information Retrieval. This event is the outcome of a proposal put together with co-organisers Max Wilson, Birger Larsen and James Kalbach, and I am pleased to announce that it has been accepted for inclusion in the workshop programme at HCI 2011 in Newcastle, UK on July 4th. In common with the sister event in the US, we’ll be soliciting submissions that focus on research and practice at the intersection HCI and IR, such as:

  • Novel interaction techniques for information retrieval
  • Exploratory search and information discovery
  • Information visualization and visual analytics

We’ll be focusing in particular on building the HCIR community in Europe, and as part of that extending an explicit invitation to the European Search/UX practitioner community to share with us their lessons learned through case studies and practical papers.

The full Call for Papers is appended below. For further details, see the EuroHCIR website.

Related Posts:

  1. ECIR Industry Day: Lineup Announced
  2. Reflections on Faceted Search and Beyond
  3. Tutorial on Designing the Search Experience
  4. From Search to Discovery
  5. Enterprise Search Meetup: Searching for Leisure, Travelmatch and Real-time search

1st European Workshop on Human-Computer Interaction and Information Retrieval

4th July at the BCS HCI2011 Conference, Newcastle, UK

Key Points:

  • We want to stimulate the European HCIR community with a series of workshops similar to successful HCIR events in the states.
  • Submission Deadline: 1st May 2011
  • Details are online: http://fitlab.eu/euroHCIR2011/

Call for Papers:

In common with the wider HCIR community, this workshop will be focused on submissions based on, but not limited to, the following topics:

  • Novel interaction techniques for information retrieval
  • Modelling and evaluation of interactive information retrieval
  • Exploratory search and information discovery
  • Information visualization and visual analytics
  • Applications of HCI techniques to information retrieval needs in specific domains
  • Ethnography and user studies relevant to information retrieval and access
  • Scale and efficiency considerations for interactive information retrieval systems
  • Relevance feedback and active learning approaches for information retrieval

Industry: The enterprise and web search experiences from professionals, such as UX designers etc, are a key part of understanding excellence in HCIR design. We are inviting case studies and position papers that go beyond a simple narrative to describe lessons learned for the community.
**Industry submissions will be evaluated more in terms of their contributions to lessons learned than through pure academic merit.**

Academia: From the research community, we are interested in late breaking results, or challenging, controversial, or insightful position papers that might shape the way the HCIR community thinks ahead.
** Academic contributions will be evaluated in terms of their contribution to the thinking and discussion for the workshop and the community.**


Participants must submit anonymised 2-4 page ACM format PDFs to the EasyChair page, optionally indicating whether the submission is from industry or academia. More details will appear on http://fitlab.eu/euroHCIR2011/submission.php

Important Dates:

  • 1st May 2011 – Submissions Due
  • 20th May 2011 – Notifications
  • 2nd Jun 2011 – Camera Ready versions
  • 4th July 2011 – Workshop


Registration details will appear on the HCI2011.co.uk website.


Tony Russell-Rose (Industry)
Endeca, UK
trose – at – endeca.com

Max L. Wilson (Academia)
Swansea University, UK
m.l.wilson – at – swansea.ac.uk

James Kalbach (Industry)
LexisNexis, Germany
James.Kalbach – at – lexisnexis.co.uk

Birger Larsen (Academia)
Royal School of Library and Information Science, Denmark
blar – at – iva.dk

Read Full Post »

« Newer Posts - Older Posts »