Posts Tagged ‘Information Discovery’

Just a quick shout out that on July 1st I’ll be presenting a tutorial at the IRF Conference in Vienna. This is part of a day of tutorials that precedes the main conference. I’ve not been to the IRF conference before, so am looking forward to it. Also I like the look of the tutorial immediately preceding mine – I’m tempted to arrive early and gatecrash it 🙂

My tutorial will be slightly longer than usual this time, as I’ll be including a new exercise that I piloted at ECIR in April (which I’m pleased to say went down rather well). I’m keeping it a secret for now – if I told you how it works it would spoil the experience – but I’ve appended the abstract below (and the full description is available from the conference website).


Read Full Post »

In the previous post we looked at techniques to help us create and articulate more effective queries. From auto-complete for lookup tasks to auto-suggest for exploratory search, these simple techniques can often make the difference between success and failure.

But occasionally things do go wrong. Sometimes our information journey is more complex than we’d anticipated, and we find ourselves straying off the ideal course. Worse still, in our determination to pursue our original goal, we may overlook other, more productive directions, leaving us endlessly finessing a flawed strategy. Sometimes we are in too deep to turn around and start again.

Conversely, there are times when we may consciously decide to take a detour and explore the path less trodden. As we saw earlier, what we find along the way can change what we seek. Sometimes we find the most valuable discoveries in the most unlikely places.

However, there’s a fine line between these two outcomes: one person’s journey of serendipitous discovery can be another’s descent into confusion and disorientation. And there’s the challenge: how can we support the former, while unobtrusively repairing the latter? In this post, we’ll look at four techniques that help us keep to the right path on our information journey.


Read Full Post »

Have you ever tried the “I’m Feeling Lucky” button on Google? The idea is, of course, that Google will take you directly to the result you want, rather than return a list of results. It’s a simple idea, and when it works, it seems like magic.

I'm Feeling Lucky on Google

But most of the time we are not so lucky. Instead, we submit a query and review the results; only to find that they’re not quite what we were looking for. Occasionally, we review a further page or two of results, but in most cases it’s quicker just to enter a new query and try again. In fact, this pattern of behaviour is so common that techniques have been developed specifically to help us along this part of our information journey. In particular, three versions of as-you-type suggestions—auto-complete, auto-suggest, and instant results—subtly guide us in creating and reformulating queries.


Read Full Post »

A little while ago I posted an article called Findability is just So Last Year, in which I argued that the current focus (dare I say fixation) of the search community on findability was somewhat limiting, and that in my experience (of enterprise search, at least), there are a great many other types of information-seeking behaviour that aren’t adequately accommodated by the ‘search as findability’ model. I’m talking here about things like analysis, sensemaking, and other problem-solving oriented behaviours.

Now, I’m not the first person to have made this observation (and I doubt I’ll be the last), but it occurs to me that one of the reasons the debate exists in the first place is that the community lacks a shared vocabulary for defining these concepts, and when we each talk about “search tasks” we may actually be referring to quite different things. So to clarify how I see the landscape, I’ve put together the short piece below. More importantly, I’ve tried to connect the conceptual (aka academic) material to current design practice, so that we can see what difference it might make if we had a shared perspective on these things. As always, comments & feedback welcome.


Read Full Post »

A couple of weeks ago I had the pleasure of presenting a paper at Enterprise Search Europe on a Taxonomy of Enterprise Search. This was the first time that the Enterprise Search Summit had found its way this side of the Atlantic, and I’m pleased to say it was a great success (due in no small part to the efforts the conference chair, Martin White).

The paper was essentially a research-driven piece, reporting on some empirical work into studying the search strategies and tactics that users commonly employ across a range of enterprise search contexts. As such, it mirrors Andrei Broder’s classic 2002 paper (A Taxonomy of Web Search), which addresses a broadly similar goal within the domain of web search. However, we used a more qualitative, user-oriented data source, and also extended the analysis to present some initial implications into how the findings could be applied in the design of search and discovery experiences.

After the event, Martin confided in me how unusual it would be to see such a paper at the New York event, intimating that there would be little room in the program for such a piece. That conversation and a subsequent exchange with Daniel Tunkelang at the CIKM Industry Event got me thinking: is the search industry playing its part in building an effective dialogue between researchers and practitioners? Could it do more? Is the job of disseminating and promoting the benefits and outcomes of IR research purely the responsibility of academics and researchers?

I hope to explore this issue further in a subsequent post. For now, here are the slides from the event. The associated paper is also available in a previous post and as a pdf from the HCIR conference website.

Related Posts:

  1. A Taxonomy of Enterprise Search and Discovery
  2. Findability is just So Last Year
  3. Designing the Search Experience (tutorial at Search Solutions 2011)
  4. A Taxonomy of Search Strategies and their Design Implications 
  5. Search Solutions 2011: London, November 16

Read Full Post »

Last week I attended the October edition of the London Enterprise Search meetup, which gave us (among other things) our usual monthly fix of great talks and follow up discussions. This time, one of the topics that particularly caught my attention was the question of how to measure the effectiveness of enterprise search. Several possible approaches were suggested, including measuring how frequently users can “find what they are looking for” within a fixed period of time (e.g. two minutes).

Now I’m not saying findability isn’t important, but in my opinion metrics like this really seem to miss the point. Leaving aside the methodological issues in defining exactly what is meant by “find what they are looking for”, they seem predicated on the notion that search is all about finding known items, as if to suggest that once they’re found, everyone can go home. In my experience, nothing could be further from the truth.

Most ‘finding’ tasks are but a small part of a much larger overall task, and are at best the beginning of an information interaction episode, rarely ever the end. Much of the value we can add in delivering enterprise search solutions should be in understanding the complete task lifecycle and helping the user complete their overall information goals, which invariably extend far beyond simple known-item search. To me, findability is but one element of the overall search experience, which (particularly in enterprise environments) often involves significant elements of higher-level problem-solving behaviour such as analysis and sensemaking:

Search is more than just findability

So why the fixation with findability? Part of the reason may be because it is both easy to understand (intuitively and quantitatively) and relatively easy to measure, with readily available metrics such as precision, recall, etc. But like the drunk searching for his car keys under the lamp post, just because it is more convenient, doesn’t mean it is the right place to look.

So I took the liberty of testing my own hypothesis against the data we used in the recent EuroHCIR paper, to see whether these intuitions have any basis in reality. I reviewed the scenarios we used in that study and counted how many of them actually were bona fide ‘findability’ tasks.

The answer? Two. Out of 104 enterprise search scenarios, less than 2% were categorised as findability tasks (i.e. locating a known item). The rest were focused on much broader goals, such as comparing, comprehending, exploring, evaluating, analysing, synthesising, and so on. Moreover, when findability was an influence, it was invariably part of a larger, composite activity, embedded in a longer sequence of analysis & sensemaking activity. So in that context, measuring the time it takes to “find what you are looking for” is at best a crude instrument; at worst, it simply measures the wrong thing.

Now of course, I’ve used a reasonably modest data sample here, and if you gather your own data, I’m sure your mileage will vary. So I plan to extend the analysis and dig a little deeper to look for further evidence to support (or contradict) the hypothesis above.

In the meantime, if you have some data or your own & you’d like to share (or even better, collaborate), I’d love to hear about it, either here or by email.

BTW, if you want to learn more about the ideas I’ve talked about above, the following are all good resources for further reading:

  • Bates, Marcia J. 1979. “Information Search Tactics.” Journal of the American Society for Information Science 30: 205-214
  • Cool, C. & Belkin, N. 2002. A classification of interactions with information. In H. Bruce (Ed.), Emerging Frameworks and Methods: CoLIS4: proceedings of the Fourth International Conference on Conceptions of Library and Information Science, Seattle, WA, USA, July 21-25, 2002, (pp. 1-15).
  • Jarvelin, K. and Ingwersen, P. 2004. “Information seeking research needs extension towards tasks and technology”, Information Research, Vol. 10, No. 1. (October 2004)
  • 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.
  • Marchionini, G. 2006. Exploratory search: from finding to understanding. Commun. ACM 49(4): 41-46
  • Peter Pirolli and Stuart Card (2005). ‘The sensemaking process and leverage points for analyst technology as identified through cognitive task analysis’, Proceedings of the 2005 International Conference on Intelligence Analysis, McClean, VA, May 2005
  • O’Day, V. and Jeffries, R. 1993. Orienteering in an information landscape: how information seekers get from here to there. INTERCHI 1993: 438-445
  • 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

Related Posts:

  1. A Taxonomy of Enterprise Search
  2. Designing the Search Experience (tutorial at Search Solutions 2011)
  3. A Taxonomy of Search Strategies and their Design Implications
  4. EuroHCIR 2011: lineup announced!
  5. Interaction Models for Faceted Search

Read Full Post »

I know the official publicity isn’t due to go out for a little while just yet, but here’s a sneak peek at this year’s lineup for Search Solutions 2011. For those unfamiliar with the event, it is described as:

… a special one-day event dedicated to the latest innovations in web & enterprise search. In contrast to other major industry events, Search Solutions aims to be highly interactive, with attendance strictly limited. The programme includes presentations, panels and keynote talks by influential industry leaders on novel and emerging applications in search and information retrieval.

The major news this year is that we’ll be preceding the event with a tutorials day on November 15, which will offer conference attendees and local participants a stimulating and informative selection of practical training courses reflecting current topics and state-of-the-art methods in search and information retrieval. More on that later! Meanwhile, here is the provisional programme thus far:

  • Ricardo Baeza-Yates, VP Research, Yahoo!, Beyond the ten blue links
  • John Tait, Chief Science Officer, Information Retrieval Facility, Using Physical Quantities in Finding Similar Documents
  • Gabriella Kazai, Research Consultant, Microsoft Research Cambridge, Crowdsourcing Search Relevance
  • Matt Taylor, General Manager, Funnelback, Search Experience Management – Techniques for Search Success
  • Toby Mostyn, CTO, Polecat, Search for public conversations
  • Jarred McGinnis, Research Manager, Press Association, The Press Association Approach to Search and News
  • Lewis Crawford, Web Archiving Programme Technical Lead, British Library, Analytics and Access to the UK Web Archive
  • Ian Kegel, Technical Group Leader, British Telecom, Broadband TV and Recommendation: Improving the customer experience
  • Marianne Sweeny, Principal, Daedalus Information Systems, Successful Enterprise Search by Design

We’ll more than likely be adding to this, and don’t forget that the programme will also include a panel session (to be announced), an evening drinks reception, and the biggest crowd puller of all, the IRSG AGM 🙂

More news (e.g. on the panel topic and abstracts for the talks) when I get it, but for now save the date: Wednesday November 16 at BCS London in Covent Garden.

Related Posts:

  1. Search Solutions 2010: Reactions & Reflections
  2. Tutorial on Designing the Search Experience
  3. ECIR Industry Day – lineup announced
  4. Events & Presentations
  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 »

« Newer Posts - Older Posts »