26 December 2011
One of the advantages of the prevailing model of faceted filtering on the web is the display of magnitude, or the size of the resulting set of items after selecting a filter value. You’ve seen this already: I’m talking about the numbers next to filter labels. This let’s you know how many things you’re going to get if you select that option.
While these calculations may be performance intensive, indication of magnitude provides valuable navigational cues to users. Seemingly trivial, this tiny bit of information can affect a user’s decision to select a filter or not. This post reviews approaches to showing magnitude in faceted navigation.
I’m happy to announce I’ll be giving a one-day workshop on some my favorite topics in New York City:
- What: “Web Navigation and Faceted Search Design”
- When: Saturday October 22, 9:00-5:00
- Where: General Assembly, 902 Broadway, NY, NY, 10010
General Assembly is hosting the event. You can register online at their website.
The first half of the day will cover various aspects of web navigation design. The second half will focus specifically on faceted search. Here’s a list of the topics covered:
- Principles of navigation - We’ll look at principles such as transitional volatility, banner blindness, and the scent of information.
- Mechanisms and types of navigation - Mechanisms are the basic building blocks of navigation systems. We’ll review and analyze a wealth of examples.
- Cores and Paths - You’ll apply many of the principles from throughout the day with a modern technique called Cores and Paths. This turns the normal approach to navigation design on its head—from the inside out.
- Analysis and implementation of facets – You’ll learn how to identify, document and implement facets with a clear framework.
- Interface design using facets – You’ll learn about the layout, display, and interaction with facets in detail. Together, we’ll examine numerous real-world examples.
- Advanced topics – You will also be exposed to special topics in faceted search design, including SEO, selecting multiple values, grouping, and more.
This is some of my best material, and I’m looking forward to the event.
17 July 2011
Faceted navigation is widespread on the web (a.k.a faceted search and faceted browse). It’s become an expected standard. I’ve written several posts on the subject and also have a popular workshop on faceted navigation. (Next one: 22 Oct 2011 in NYC). Yet we really don’t know much about the ROI of faceted navigation. Or do we?
I’ve only been able to find a few studies or case studies reporting a measureable ROI of faceted navigation. There are lots of variables in play, and definitively showing measureable gains directly to faceted navigation can be tricky. But a simple before-and-after comparison should be possible.
One helpful sources is Endeca’s case studies. Examples of ROI include:
- Kiddicare.com: 100% increase in conversion rates; 100% increase in sales; Additional 100% increase in conversion rates with PowerReviews
- AutoScout 24: 5% increase in lead generation to dealers; 70% decrease in no results found
- Otto Group: 130% increase in conversion rates; Doubled conversion rates for visitors originating from pay-per-click marketing programs; Search failure rate decreased from over 33% to 0.5%
If you have such data or evidence in any form, please let me and others know about by commenting here. Note I’m not talking about studies that show how efficient faceted navigation is in terms of interaction or time on task (such as the ones reported here): I’m looking for hard evidence on ROI in real world situations.
It’s a positive sign that so many websites have faceted navigation these days: there must be something “right” about it. But why have so many site owners and stakeholders funded and implemented faceted navigation systems? What’s the actual return against the cost of implementation and maintenance?
Some logical arguments include combinations of the following:
- Conversion: Customers can’t buy what they can’t find: Findability is critical for ecommerce sites. A well-designed navigation plays a key role in getting people to the information or products you want to see. This ultimately helps you sell products or ideas. Faceted navigation has been shown to improve findability, in general.
- Efficiency: Employees lose productivity when navigation is inefficient: These days company intranets can be enormous. The time to find information impacts employee productivity. Even the smallest increase in navigational efficiency can have huge returns for a large corporation if you multiple it by thousands of employees. Faceted navigation is efficient.
- Confidence: Faceted navigation increases information scent: Revealing facet values gives users better insight into the type of terms and language used on the site. They are then able to match their information need with the content of the site, giving them confidence as the navigate forward through a given collection. This keeps them on the site and away from the customer support hotline.
- “Aboutness”: Facets show the overall semantic make-up of a collection: Faceted metadata–the values associated with a collection of documents or products–give clues into the “aboutness” of that collection. Facets convey the breadth and type of a results list, for instance. This can help get to their target information better.
- Reduced Uncertainty: Users don’t have to specify precise queries: With faceted navigation, users don’t rely on formulating precise keyword searches alone to find information. Instead, they can enter broad searches and use the facets in a flexible way to refine the initial query. This gives confidence in being comprehensive and reduces uncertainty in information seeking in general, as well as removes the frustration of finding no results.
- Navigation: Browsing categories provides a different experience than keyword search: Jared Spool and his colleagues found that people tend to continue shopping more often when navigating than after doing a direct keyword search: people tend to continue browsing—and buying—when they can successfully navigate to the products they want to purchase. Sure, keyword searching may also get them there, but that experience is different. He writes in an article entitled “Users Continue After Category Links” (Dec 2001):
- Apparently, the way you get to the target content affects whether you’ll continue looking or not. In a recent study of 30 users, we found that if the users used Search to locate their target content on the site, only 20% of them continued looking at other content after they found the target content. But if the users used the category links to find their target, 62% continued browsing the site. Users who started with the category links ended up looking at almost 10 times as many non-target content pages as those who started with Search.
A well-designed faceted navigation system won’t solve all your problems. But because navigation is so central to the basic web experience, it stands to reason that that are financial implications involved. What are they exactly?
Again, if you have any support for the above contentions or have another argument around the benefits of faceted navigation, please let me know.
I’m honored to be on the organizing team for the first European workshop on HCIR at the HCI 2011 conference in Newcastle on July 4. See the workshop website for more details.
We are looking for submissions from industry professionals, as well as from academics. If you work in related areas–such as IA, UX, search systems design, etc.–we’d love to hear about your practical experience in the form of a short position paper. The call for papers is now open.
What is HCIR, you ask? Human computer Information Retrieval (HCIR) is a relatively new area of investigation that brings together concerns of human-computer interaction (HCI) and information retrieval (IR). The term was coined by Professor Gary Marchionini around 2005. Wikipedia defines HCIR as:
…the study of information retrieval techniques that bring human intelligence into the search process. The fields of human–computer interaction (HCI) and information retrieval (IR) have both developed innovative techniques to address the challenge of navigating complex information spaces, but their insights have often failed to cross disciplinary borders. Human–computer information retrieval has emerged in academic research and industry practice to bring together research in the fields of IR and HCI, in order to create new kinds of search systems that depend on continuous human control of the search process.
HCIR includes a ranges of techniques and approaches that allow people to better interact with information and find what they are looking for, such as auto-complete, spell correction, and relevance feedback. A significant amount of attention is given to faceted navigation.
If you will be in Hamburg or Sydney in April, consider attending one of my workshops. I’ll be focusing on some of these aspects of HCIR around IA, web navigation, and faceted navigation:
- a. Prinzipien der Informationsarchitektur
- b. Elemente des Navigationsdesigns
Die online Anmeldung ist offen.
11 February 2011
Are you in OZ and want to learn about faceted search, strategic alignment diagrams, IA, navigation and more this April? I’m delighted to announce that I’ll be giving 2 workshops in Sydney on April 28-29, 2011!
Here are some highlights:
WORKSHOP 1: Information Architecture for Strategic Web Design
Thursday 28 April 2011, 9:30-17:00 - This workshop focuses on the conceptual and strategic side of information architecture (IA). Topics include: alignment diagrams, mental models, concept maps, Cores and Paths, information structures and facets.
WORKSHOP 2: Web Navigation Design
Friday 29 April 2011, 9:30-17:00 – This workshop focuses on the nuts and bolts of good navigation design. Topics include principles of web navigation, navigation mechanisms, types of navigation, the scent of information, and faceted navigation.
- Earlybird (to April 2): AUD 660
- Regular Price: AUD 759
Beginner to intermediate web designers, interaction designers and IAs; usability experts looking to improve web design skills; and project managers, product mangers, and others seeking to better understand web navigation design.
See the registration details page for more information and to sign up.
Filed in Customer Journeys, Designing Web Navigation, Facets, Information Architecture, Information Experience, Information Interaction, Information Seeking, Navigation, Search, Usability, User-Centered Design, Workshops
Tags: Faceted classification, faceted navigation, Faceted search, Information Architecture, Navigation, Sydney, Usability, Web design, Workshop
I’m proud to be part of William Hudson’s UX Fest in London in February 2011. We’re planning 4 workshops in all:
- Dynamic User Experience: Ajax Design & Usability, 07-Feb-11 (William Hudson)
- Agile User Experience & UCD, 08-Feb-11 (William Hudson)
- Designing Web Navigation, 09-Feb-11 (James Kalbach)
- Faceted Search & Beyond, 10-Feb-11 (James Kalbach)
There are several ways to get a discount:
- Early bird price
- 3-for-2 special
- Or book all 4 workshops for a single price.
I’ll be giving two day-long workshops:
Workshop 1 - Designing Web Navigation
Wednesday February 9, 2011, Central London (James Kalbach)
This full-day workshop covers principles of web navigation and methods of navigation design with practical examples and exercises. Participants should have some experience creating or maintaining websites but are looking to deepen their design skills.
- Principles of navigation
- Scent of information
- Elements of navigation: mechanisms, types and pages
- Cores and Paths
Workshop 2 - Faceted Search & Beyond
Thursday February 10, 2011, Central London (James Kalbach)
Faceted navigation has become very popular in the last decade. It’s seen as way to improve the findability of information on many sites, particularly those with large collections of products or documents. The design of real-world faceted navigation systems, however, proves to be more intricate than people first assume, and designers must be aware of many details.
This workshop covers principles of faceted classification and shows you how to use facets in web design. Many examples of faceted navigation will be presented and discussed. A clear, structured framework for understanding the individual components is presented to help you understand all the decisions involved. The topics are brought to life through several hands-on exercises.
- Facet analysis
- Implementing facets
- Interface design using facets
- Advanced topics including SEO, selecting multiple values, grouping, and more
Audience for both workshops:
- Beginner to intermediate web designers, including interaction designers, graphic designers, and information architects
- Usability experts looking to improve web design skills
- Project managers, product mangers, and others working in related roles seeking to better understand web navigation design, who also have some experience creating websites.
Workshops In German
In April 2011, I’ll also be giving workshops on similar topics in German in Hamburg. See the “Workshops” link on my blog (to the right) for more details.
4 September 2010
Faceted navigation, when done well, can help customers find what they are looking for quicker and in a more satisfying way. This is good for business and for the bottom line. After all, customers can’t buy what they can’t find.
I’ve been interested in faceted navigation for some time now. I’ll be giving a workshop on faceted navigation at the Euro IA conference in Paris at the end of September. (There’s still room if you want to attend. You don’t have to attend the conference to attend the workshop). In preparing for my workshops, I continued to be amazed by how much detail and complexity there is in the design of faceted navigation systems, particularly when dealing with real-world implementations. And there’s lots of room left for creativity and innovation, too.
One issue that’s recently come to my attention is that of SEO and faceted navigation. Now, I’m not an SEO expert in any way—in fact, I know very little about the field. Still, I wanted to cover some of the aspects of facetted navigation and SEO in a blog post based on research I did on the web. Please provide constructive criticism in a comment if I miss something or get something wrong.
The basic problem is this: facets are fundamentally polyhierarchical—infinitely so, or so it seems. In a system of faceted filters for search results of products, for instance, there can easily be millions of possible combinations.
Search engine crawlers don’t like this. It slows them down und eats up crawl bandwidth. Worse, some search engines might start seeing redundancy and think it’s some kind of spam. They then give up.
If you have a facetted navigation system on your site, it may be difficult to get it indexed effectively or indexed at all. But it’s not impossible—it just takes a bit of extra thought and planning from the beginning.
From surveying what others have said about how to deal with this, I’ve put together a simple list of what appear to be the top approaches to consider. Combinations of the below techniques generally improve the situation, as well: if you can do the top three, you’re probably in good shape.
- Use a unique URL for each page, particularly product pages.
Strive to create static URLs, even if they primarily parameter-driven. This advice comes from Rand Fishkin at SEOmoz.org in a Whiteboard Friday video on faceted navigation. Having a static URL allows search engines unique identify a page and index it.
- Use a standard, topical hierarchy as a main navigation.
Search engine crawlers like hierarchy. Having a primary path for them to index helps greatly. Include this hierarchy in the URL, as well, and strive to keep the navigation shallow. This advice comes from Matt Cutts, head of the Webspam team at Google. In an interview, Matt says:
“While faceted navigation can be good for some users, if you can decide on your own hierarchy how you would categorize the pages, and try to make sure that the faceted navigation is relatively shallow, those can both be good practices to help search engines discover the actual products a little better.“
I believe the screen shot below—from HomeDepot.com—shows this, to some degree. Regardless of the order of selection of filters, the topical hierarchy always comes first in the breadcrumb and in the URL. In Figure 1, I selected Grills first, then a price category from $100-$200, and then Propane Grills—in that order. Both the breadcrumb and the URL force the category selections together, however. In this case, Propane Grills was inserted into the breadcrumb ahead of the price range, despite having selected the price range first. The human-readable category hierarchy in the URL is the second element, as well, which should help SEO.
3. Publish an XML sitemap of your entire site with directory style URLs.
For a company like Endeca, a leading provider of faceted navigation solutions—their “guided navigation“ system—SEO is a challenge they’ve come across long ago. And, accordingly, they’ve done quite a bit with SEO and faceted navigation. In addition to the above points, Rob Swint of Endeca recommends publishing an XML sitemap of your site. He outlines this approach along with others in the article “Three Techniques for Maximizing SEO.“
4. Other approaches
I also uncovered a few other approaches that didn’t seem to have widespread approval or acceptance. Some seem like workarounds and may have negative side effects, as well. Still, you might want to consider the following techniques. Again, this is not a recommendation, so please research them carefully:
- Examine search logs to see what people are searching for, and then create gallery pages or sub-pages for them.
- Add “nofollow“ attributes for faceted navigation links. It seems like the prevailing opinion, however, is against this. Using “nofollow“ is more of a workaround than a solution.
- Keep basic sorting functions out of the mix. To do this, track the sort with AJAX and/or via the user’s cookies. If you take this approach to an extreme, you could also do the filtering on the front end AJAX.
Done right, facets can let you create more landing pages than you could by hand, addressing long tail searches better. And, as mentioned at the beginning of the post, there are user benefits as well. While SEO and faceted navigation can be tricky, it’s not impossible to overcome. Please research the above approaches before implementing them.
“Facets As A Navigational & SEO Powerhouse” by Jamie Sirovich
“The New Natural Search Spam” by Brian Klais
18 July 2010
Facets are categories that describe the properties of an object or collection of objects. Facet categories then have values. In faceted navigation schemes, the values are the things you click on to navigate to a set of items or to filter a list. The type of structure that those values have, however, can vary depending on the type of facet you are dealing with.
Take wine. (Hey, who doesn’t use wine as an example for facets?). Typical facets include things like region, color, type, winery, price and rating. If you consider nature of the values for each of those facets, it’s obvious that they have different structures. And those structures give rise to different ways of representation as well as carry display challenges. For example, a slider might be a good way to filter by price, but it’s not so good for region.
Before beginning the design of faceted navigation, it’s important to first understand the nature of value structures.
Fundamentally, there are two types of value structures: hierarchical or flat. But within the latter type (flat) there are some important differences and variations to consider.
In my workshops on faceted navigation design (next workshop: Euro IA in Paris, Thursday Sept 23) I point to five common structures of facet values, outlined below.
A hierarchy is an arrangement of values with parent-child relationships. Think: tree structure. In the above example for wine, “region” is a hierarchy and may look something like this:
- North America
- New York
- South America
Hierarchies may be represented as tree structure (like in Windows Explorer), where the user can open and close levels. This may present some interaction difficulties, particularly within the context of faceted navigation online. Namely, there are two elements for the user to keep separate: the mechanism to open and close a branch of the hierarchy (usually a + or – sign, or maybe an arrow of some kind) and the value itself, which when clicked presumably filters the set of items.
An alternative to using tree structures for hierarchies is to only present one level at a time. For instance, a user isn’t able to access the specific wine regions of France until first selecting “France.” This generally requires a page reload or update of some kind.
This is the approach taken in the FLAMENCO model for faceted navigation. However, to give users a preview of sub-categories in a hierarchy, the FLAMENCO interface uses a rollover display to reveal sub-options. The values in this preview are not clickable, but the researchers’ tests showed that they helped users better navigate by foreshadowing values at lower levels .
The image below shows an example from the FLAMENCO interface. In the red circle on the image you’ll see that the upper level categories in the hierarchy are indicated (North America > United States), as well as the values of the current level (the filter links). Then, subcategories are shown in a tool tip dialog. The user can then see both the parents of the current level as well as the children.
Figure 1: Indicating multiple levels of hierarchy on FLAMENCO (click to enlarge)
Of course, this brings up the question, Why not just allow users to directly select a lower level option in a hierarchy in the dynamic menu? That is certainly possible, but may present interaction and usability challenges if not designed and implemented carefully. (I don’t know of any examples of hierarchical faceted metadata that use dynamic menus to access lower levels of a hierarchy, but I presume they exist somewhere.)
Finally, hierarchies could also be represented in a flattened form. That is, you could also remove the levels of the hierarchy and just present the values in a simple list. The facet values for “region” from the above scenario may also be displayed like this for a given search:
The first value in the above list is from level 3 of the hierarchy, while the second value is from level 1. Hungary, on the other hand, is from level 2. From a navigation standpoint, these are all considered within a single flat list. For filtering a list of items (e.g., a search results list), such an approach may be quite useful.
Nexis.com, the flagship news product from LexisNexis, flattens hierarchy when displaying search result filters. In the image below, you can see the facet “Geography” (lower left side) includes values from all levels of the hierarchy in a single flat list. “North America,” “United States,” and “California” all appear at the same level, though within the native structure of this facet they are hierarchical.
Figure 2: Flattened hierarchy for facet values on Nexis.com
Generally, it’s expected for lower-level values to “roll-up” to parent categories. That is, if you select North America as a filter, you should also get all of the items from that category’s children (e.g., USA, California, New York, Washington, Canada). So flattening a hierarchy to display facet filters can bring up inconsistencies in the item counts after each value: the sum of the numbers in parentheses from all of the filter values will total more than the number of items in your set. You therefore might want to consider just displaying the lowest levels only.
A “List” is as simple as it sounds: a flat enumeration of values. In our wine example, “winery” would be represented as a flat list. Usually, a stack of plain links will do. (Or, symbols or icons of some kind may be appropriate instead of plain links depending on the type of information in the facet.)
A problem with some flat lists, however, arises when they are very long. A list of all wineries–even for a relative small set of results–could have hundreds of values. Displaying these in a left-hand panel may be challenging.
Or, consider the following example from the ACM digital library. The filters for search results include the facet “Publication Names.” The values are represented in a flat list. In the image below the first eight values are displayed by default along with the option to see all publication names (via the “More…” link).
Figure 3: Eight default values for “Publication Names” on the ACM Digital Library
Clicking on the “More…” link reveals the full list of publication names, shown in the next image. As you can see, the list is quite long. What’s more, the value labels themselves–publication titles–are also long, some of which wrap onto 4 lines. Displaying this single flat list on the left side of the page would be challenging and not provide a good browsing and scanning experience.
Figure 4: A flat list of all publication names on the ACM Digital Library
A binary structure to facet values is really a subset the “list” type. But, by nature these values have and “either-or” aspect to them. For example, the facet “Gender” can only have two options: male or female.
In the example of wine, the facet for something like “Means of Production” might have binary values of “Organic” or “Not Organic.” These could be represented as simple filter links as if in a flat list:
Means of Production
Or, you could represent them with checkboxes or even radio buttons.
Alternatively, you could also only present one of the binary values with a checkbox to either opt in or opt out of that value. So in our example, you could also represent the filter as a simple on/off option, like this:
[ ] Show only organic wines
Note that the facet category label (i.e., Means of Production) is not necessary in this case; it’s implied. Still, you can treat this metadata as a facet in terms of conception of the navigation system and maintenance of metadata.
The North Carolina State University library catalog makes use of faceted navigation. In a results list, there are also some binary options to filter results. In the image below there are three such checkboxes. The first option, for instance, has the implied facet category of “Availability.” Here, there are only two values: “not available” or “currently available.” In this case, the user can opt in to the latter value, thereby excluding all items that are not available.
Figure 5: NCSU Library catalog results with an example of binary facet values.
A continuum is a list of values that have a potentially unlimited number of points on a range. Generally, continuums are numerical in nature (whereas hierarchy and lists are typically textual information). “Price” is an example of a continuum.
Of course, there is in fact a limit to the number of prices available for a given collection of wine, so it’s not that the continuum is endless. Rather, each item in a given collection could potentially have a different price. So, a results set of 100 items could have 100 different price values. Another set could then have a completely different set of price values. The values in a continuum can vary dynamically.
Contiuums are sometimes represented with a slider. In the image below from Endless.com, you can see the prices for women’s shoes range from $18 to $1,921, with just about every price point in between.
Figure 6: Price continuum on Endless.com accessed via a slider
As Mike Madaio points out in a presentation facets given at the IA Summit 2010 , the above example can be problematic. Namely, if you show the entire range linearly, the filter may be hard to control. To limit the above set of women’s shoes to those under $100 only, the slider controls have to be placed nearly on top of each other, and they are difficult to use as a result. The necessary granularity for shoes under $100–which account for about 2/3 of all of the items in the collection–isn’t present in the UI. An alternative is to plot the prices in the continuum on a logarithmic scale so they are better distributed.
Instead of sliders, sometimes input fields are used to filter a collection of items. For instance, date is another common facet that represents a continuum of values. Sometimes you’ll find input fields to filter by a date range. Of course, input fields are also used for price, among other things.
Also called a discrete scale, this type of value structure represents a potential continuum of information, but the values are limited to fixed categories. These are generally arranged from low-to-high or from old-to-new in terms of order.
For instance, “rating” could be a continuum, with any number of values between 0.0 and 100.0. Or, it could be represented as a discrete scale of 1-5 stars. Amazon.com, for instance, allows users to filter on average rating. The image below shows a scale for the ratings:
Figure 7: Ratings on a discrete scale on Amazon.com
So, a continuum could potentially be made into a scale. We see this often with the facet “price.” Instead of showing actual prices as filter values, groups of prices are created on a discrete scale. In the image below from HomeDepot.com, the price filter is shown as a scale instead of a continuum.
Figure 8: Price range categories on HomeDepot.com
With numerical facet values, you have to decide whether to represent them as a continuum (requiring a slider or input fields) or on a discrete scale (allowing for simple link categories).
 Marti Hearst, “Design Recommendations for Hierarchical Faceted Search Interface.” ACM SIGIR Workshop on Faceted Search, August, 2006″
 Mike Madaio, “Better Faceted Navigation.” Presentation at the IA Summit 2010.
Pete Bell, from Endeca, makes an interesting observation about greying out non-relevant options when filtering with facets instead of hiding them. See his post “Search Facets: Bring Back the Dead Ends.” His example comes from the B&H Photo website, and it shows what Pete calls “grey ends” (as opposed to dead ends). He writes:
Gray ends are an exemplar of Edward Tufte’s advice to “always show comparisons adjacent in space rather than over time.” That is, if you want people to understand the difference between a “before” and “after” screen, when you redraw the screen, you’re asking them to rely on their memory to make the comparison. It’s always a risk to rely on memory, but it’s an even bigger risk here because we know people on the “before” screen were just focusing on the facet in which they made their explicit selection, rendering the others cognitively invisible. With gray ends, nothing has disappeared, so they get to compare the two states adjacent in space, no memory required. Tufte’s advice here is a classic for faceted UX work in general.
Grey ends make most sense with multi-select facets. The disadvantage is added complexity in the UI. Grey ends and multi-select facets aren’t appropriate for every situation, so I’d advise to use them with caution. Still, as Pete shows in his example, they can be a powerful addition to the faceted navigation experience.
I spotted grey ends a short while back on LinkedIn. This is also an example of multi-select facets, and it seems to work well. See the options in the Relationship facet on the left side of the image, below. After selecting a value from another facet, options in the Relationship facet turn grey.
Figure 1: Grey ends on LinkedIn (click to enlarge)
Finally, I also found Pete’s opening to his blog post interesting:
“There’s still so much room for innovation on faceted search user experiences.”
We’ve really just started to understand the intricacies of faceted navigation, I believe. Sure, Flamenco and other examples have made great strides. But there’s still lots more that can be done, particularly in real-world situations. Greg Nudelman’s example of Integrated Faceted Breadcrumbs I previously pointed to is just one example of the type incremental innovation that can take place in faceted navigation UIs.
12 June 2010
Overall, my interest in faceted navigation stems from the development and organization of workshop material on the subject. The intent is to address the primary questions designers face and identify possible solutions and directions. Where known, I’ve attempted to cite relevant literature, which is proving to be thin and/or indirect.
This post focuses on two aspects of the initial layout and display of facet filters in a results list. Designers of a faceted navigation start with 2 common questions:
- Where are the facets located?
- Are they shown by default or not?
In terms of location, there are 5 approaches we can identify:
1. VERTICALLY, ON THE LEFT SIDE
This is perhaps the most common position and seems to work well for obvious reasons. A left-hand position is common for navigation menus on the web. Here, the top facets will always appear horizontally, even at smaller browser sizes. Of course, there is more vertical scrolling involved to reach all the facets, and some may be below the fold. The results list can appear prominently in the center of the page and should be visible with this arrangement. Typically, the values are stacked vertically.
Hoovers.com is an example of a left-hand layout for faceted navigation:
Figure 1: Left-hand faceted navigation on Hoovers.com
There is no guarantee that users will notice and interact with this arrangement, though. Daniel Tunkelang, for one, suggests that a column on the right may be too subtle for users to notice. 
The Flamenco interface for faceted navigation developed at the University of Berkeley California even has an algorithm to determine label length, and if they are short the values are presented in two columns.  This is the only example of a dual column approach I could find. Dual columns for values don’t seem to have caught on in commercial setting, presumably because the benefit may not outweigh the effort.
Figure 2: The Flamenco faceted navigation interface with dual column values
2. HORIZONTALLY, ALONG THE TOP
Some instances of faceted navigation place the filters horizontally at the top of the results list. Studies with users at Ebay suggest that people used the facets to filter a list of items more when located horizontally than on the right side.  This is a big advantage. Of course, on the downside a horizontal arrangement is that the results list is further down on the page.
A horizontal arrangement also has more constraints than on vertical arrangement. Generally, not more than 4-5 facets with their values can be shown at any one time. Also, the Inline Expand approach to showing more values is not viable. (See my previous post on showing more values).
Yelp.com makes use of this arrangement, shown below.
Figure 3: Horizontal facet filters on Yelp.com
With a horizontal layout, the values are typically listed in vertical stacks, as in Figure 3. However, there are examples of also listing the facet values horizontally as well. This doesn’t seem to save much space, if any, and the values are harder to scan. The value of listing the values horizontally is questionable.
Shopping24.de, a German shopping portal, uses this approach. The fitlers are just above the top of the list, beginning with the German phrase “Produkte in Kaffee & Co.” The facets are “Hersteller,” “Preis,” “Serie,” and “Geräte-Typ.” The values for each are represented as link extending horizontally from the facet header labels. At the end of the values is a “more” link, which in German is “weiter.”
Figure 4: horizontal facets and values on Shopping24.de (German)
3. VERTICALLY, ALONG THE RIGHT SIDE
The University of Edinburgh library catalogue positions faceted navigation filters for search results on the right. This makes use of the AquaBrowser discovery interface from Serials Solutions.
Figure 5: University of Edinburgh OPAC with right-hand filters
In an empirical study , Tim Bosenick and I report findings from a large scale investigation on the location on the main navigation of websites. See “Web Page Layout: A Comparison Between Left- and Right-justified Site Navigation Menus.” This study compared two positions of the main navigation of a website: vertically on the left and vertically on the right. The results showed no significant difference in performance between two: participants we’re able to solve each of the five tasks given to them with either arrangement.
Contrary to these findings, other studies since then have shown the location of the main navigation has an affect on the amount of time spent on page. In Petrie et al. , the researchers found that users spent double the amount of time on the page with unconventional locations of the main navigation. (Of course, spending more time on the page isn’t necessarily bad. In fact, most site owners strive to keep people on their sites and focused on the content).
But even studies that show contradictory results to ours  also show that people adapt to unconventional layouts very quickly. When it comes to the location of navigation menus, people appear to be fairly ambidextrous–left or right do not present usability issues. Blogs, for one, often have a main navigation on the right (like this one). And there are other sites have right menus.
Nonetheless, I believe that a left-hand menu for faceted navigation filters is better than a right-hand menu. First of all, the studies cited above tested main navigation menus. There’s a difference to faceted filters in a results lists, where the focus is much more on the content starting a navigation episode. In a case study presentation on faceted navigation on KLM.com given at the European Information Conference 2008 in Amsterdam, Floris Ketel reported that users of that site universally overlooked the filters when positioned on the right side based on results of several usability tests.
From my experience and from what I see in the literature, it’s not recommended to place facets on the right side. Instead use the left side or top horizontal arrangement, depending on the degree to which using the facets is a critical step or not. (i.e., placing the facets horizontally across the top encourages their use more and a de-emphasizes the content to some degree).
4. WITHIN THE CONTENT OF THE LIST
Let me first explain what I mean by this approach. Some results lists have options embedded in the list items themselves. This is can be an action–like print or send to a friend–but it can also be some form of linked metadata, like topics to which the item belongs. Clicking such a topic link, for instance, would then show all items for that topic.
If you’re thinking, “That’s not faceted filtering,” you’re right. I’m aware of that. It’s actually a form of pivoting, which is defined as:
Still, I think it’s appropriate to consider pivoting here in the context of faceted filtering, particularly given real estate challenges one has when displaying faceted navigation. Some facets may lend themselves to being displayed within the items in the list. For instance, facets that may result in very large lists of values prove difficult to display and may not be easily navigated. A result list of 1000 items in a given database may have 500 different publication titles with a relative equal distribution across the set. If publication is a facet to filter on, displaying those 500 titles presents a problem for the design, and navigating them a problem for the user. My suggestion is to consider surfacing that type of metadata as pivot links within the list items.
For example, NextBio links author names in the results list (circled in yellow in Figure 6). Clicking one pivots to a new results list for that author. In this example, a complete list of all author names would be quite long to display.
Figure 6: NextBio
There are not many examples of linking faceted metadata within a results list, and for reason: the chance of getting lost in hyperspace potentially increases. You also lose the overview that faceted navigation potentially provides. As a result, many designers want to keep users focused on the content of the results list as well as the filtering possibilities without wandering off with a pivot.
Still, I think there is more potential in this approach then currently used. I envision implementations that allow users to filter or pivot by interacting with faceted metadata presented in a results list. For instance, clicking on a name in the NextBio example could present a small menu of options to either pivot or filter, among other things.
Few implementations of faceted navigation have filters in multiple locations. The Exhibit interface is one example, with filters on the left and the right side, as shown in the figure below.
You can also see in the NextBio image, above (Figure 6), that the top-level filters for things like “Publication” are on the left, but more specific filters (e.g., terms in the word cloud) are horizontal across the top. This is another example of combinations of layouts and arrangements of facets on the results page.
In general, some facets may need more space depending on the way they are displayed. For instance, a large date filter that charts results set size may be better displayed horizontally across the top, while topics are better in a vertically stacked list. Conceivably, the UI could have both vertical and horizontal display of values depending on the nature of the facet.
Open or Closed by Default?
Once you’ve decided where to place facets, you also have to determine whether they are shown or hidden by default.
In all of the above examples, the values or subset of values within each facet are revealed by default. However, some implementations of faceted navigation opt to hide the facet values by default. For instance, on Forrester.com the values of each facet not shown, but instead visitors must open the facet category first to access them. (See figure below).
Figure 7: Forrester.com has hidden values by default
In a presentation given at the Information Architecture Summit 2010, Mike Madiao refers to these are accordions.  The advantage is that more of the top-level facet category labels are visible on a single screen. (If the facets were open by default with, say, 5 default values, only about half of them would be visible above the page fold).
If facets are positioned horizontally across the top, hiding them by default saves valuable real estate. Eventim.de is a German ticket sales site. The filters are horizontal and hidden by default. (See the dark blue button-like bars in the center of the page just above the results list). Clicking on the facet label reveals a dynamic menu with the values. Selecting a value then replaces the facet label with the selected value for proper feedback on which filters are set.
Figure 8: Eventim.de, a German ticket site with horizontal filters that are hidden by default.
Of course, one approach is to mix the default state: show some open by default and hide others. An example of this can be found on JR Music. This site uses many facets for filtering results lists–up to 15 facets, depending on the product category. The first two are open by default, while the others are collapsed with the option to access them if needed.
Figure 9: J&R Music shows some facets open by default, with others hidden
I could not find any specific literature on showing or hiding values by default in the context of faceted navigation, but I assume the filters that are hidden by default don’t get used as much as they would if they were open by default. We’ve seen this in our products at LexisNexis, where some of the facet values are hidden by default. I’d personally recommend showing values by default to the degree possible.
Daniel Tunkelang  also suggests the possibility of displaying the results list and the facet filters in separate tabs within the UI. Here quickly admits that many people may not even be aware that the facets exist with this arrangement. I could not find any examples, so it’s a rather speculative suggestion with little practical value it would seem.
There is also the general question of whether or not control should be given to the user to expand and collapse the facet components. Of course, if they are not shown by default some mechanism will be needed. If they are open by default, it may not be necessary to provide control over the visibility of facet values. Given the user’s core goal at hand–differentiating result items and determining relevance–providing too much control in the UI may only distract and not add value.
|LEFT||Common location for navigation on web||Facets below fold not showing|
|TOP||Hard to overlook, Get used more||Uses valuable real estate, result further down on page|
|RIGHT||Prioritizes content over filters||Easy to overlook, not used as much|
|CONTENT||Integrated with user’s focus of attention||Distracting, could get user off track|
|COMBO||Leverage PROS, above||Inconsistency of filter display|
Show/Hide By Default:
|SHOW||Visible facets, readily used||Real estate challenges|
|HIDE||Can show more facet categories||Values not visible immediately, not used as much|
|COMBO||Exposes all top level facet categories and some values||Hidden values still require user action, not used as much|
 “Design Recommendations for Hierarchical Faceted Search Interfaces,” [PDF] Marti Hearst, ACM SIGIR Workshop on Faceted Search, August, 2006.
 “Faceted Metadata for Information Architecture and Search,” [PDF, 8mb] CHI Course for CHI 2006, by Marti Hearst and Preston Smalley and Corey Chandler of eBay, 2006.
 “Web Page Layout: A Comparison Between Left- and Right-justified Site Navigation Menus,” Journal of Digital Information, 4/1, April 2003.
 “Navigational Consistency in Websites: What Does it Mean to Users?” H Petrie, G Papadofragkakis, C Power, D Swallow, Interaction–INTERACT, 2009.
 “How do you re-design a business critical web application with billions of unique products?,” Floris Ketel, Mirabeau, NL, Presentation given at the European Information Architecture Conference 2008 in Amsterdam, 2008
 “User Interface Design,” by Moritz Stefaner, Sebastian Ferre, Saverio Perugini, Jonathan Koren and Yi Zhang. Chapter 4 in Dynamic Taxonomies and Faceted Search, Giovanni Maria Sacco and Yannis Tzitzikas (Eds.), Springer, 2009.
 “Better Faceted Navigation: Advanced Design Techniques,” by Mike Madiao, presentation given at the IA Summit 2010.
 Faceted Search, Daniel Tunkelang, Morgan & Claypool Pubs., 2009.
30 May 2010
This is an update and extension to a previous post on showing more values in faceted navigation. First, I’d like to add one more approach to showing more values.
7. Overlay Dialog Window
Clicking a “more” link or “show all” link could open an overlay dialog window. This is similar to #4. Dynamic Menu mentioned in my previous post, but has an important difference. Namely, in this solution the items in the new dialog are not an extension of the default list of values. Instead, the list is presented again in its entirety. Subtle, yes–but it’s significant. For one, there is a greater transition to the new dialog window. This approach also allows for new order of values, if desired.
Presenting on overlay dialog window also differs from solution #3. New Page in my previous post. Instead of a page re-load, the new dialog is presented with the original page still in the background. So there is less transitional volatility from the original page and provides a better sense of staying close to the task as hand.
A key benefit of an overlay is increased real estate compared to dynamic menus and other solutions. It can essentially present the same amount of information as a new page. Ebay uses this solution for some of its facets, for instance for Brand shown in the figure below.
Figure 1: Example of an Overlay Dialog Window from Ebay.com
Second, inspired by Jason Hobbs’ talk at the IA Konferenz in Cologne, I did a literature search to find research on showing more values in faceted navigation. There is virtually no direct research on this topic. Indirectly, tests on Ebay have apparently shown that people are satisfied having a subset of all facet values presented by default with access to more . But how that access is provided doesn’t seem to have been studied.
One exception to this is the auto complete solution (#6 in my original post). Marti Hearst suggests that auto complete could aid in faceted navigation . She sites general studies of auto complete to begin [3, 4] and assumes these are effective approaches: “This is a rare case in which there have been few if any usability studies … but by observation and anecdote, I am willing to claim that the usability appears to be very high.” Bast and Weber  carried out a specific investigation into auto complete with facets. Their findings suggest that there is improved search times when using auto complete, but they did not investigate the interface solution presented in my example using LinkedIn, nor as found in Semedico (see my original posting).
If you are aware of any research on how to best show more values in faceted navigation, please let me know. Until, designers will have to rely on their design reasoning to arrive at usable and innovative solutions.
 “Faceted Metadata for Information Architecture and Search,” CHI Course for CHI 2006, by Marti Hearst and Preston Smalley, and Corey Chandler of eBay.
 “UIs for Faceted Navigation: Recent Advances and Remaining Open Problems,” in the Workshop on Computer Interaction and Information Retrieval, HCIR 2008, October 2008, Redmond, WA, by Marti Hearst.
 H. Bast and I. Weber. “Type less, find more: fast autocompletion search with a succinct index.” In Proceedings of the 29th annual international ACM SIGIR conference on Research and development in information retrieval, pages 364–371. ACM New York, NY, USA, 2006.
In preparation for my workshop on faceted navigation at the IA Konferenz 2010 in Cologne this past weekend, I’ve been thinking about faceted navigation quite a bit recently. In particular, I’ve been considering ways to explain and teach the subject effectively. )One not-so-trivial side effect of teaching is that the instructor can learn just as much as the students.*)
Looking at loads of examples and implementations of faceted navigation gets your creative juices flowing. In particular, I kept thinking how I would have done my last project that involved faceted navigation different or better. Hindsight is always 20/20.
So maybe breadcrumbs aren’t just quite dead yet. It really depends on how they are implemented. Perhaps we’ll see even more innovative uses of the mechanism in the future.
I’ve been toying around with how to make breadcrumbs effective main navigation mechanisms–just with sketches on projects and on my own. The basic idea is to have rich, dynamic options available from each of the nodes of the breadcrumbs. (This isn’t new, I know (see references below), but there are very few real-world examples of it). So merging rich breadcrumb trails with faceted navigation would also seem to make sense, in my opinion.
Greg Nudelman not only beat me to the punchline to integrate dynamic breadcrumbs with faceted navigation, it looks like he’s also tested them. Good work! Check out the full report in an article on Boxes and Arrows entitled Faceted Finding with Super-Powered Breadcrumbs. He calls the approach Intergrated Faceted Breadcrumbs or IFB. Greg writes:
I believe Integrated Finding [sic] Breadcrumb design is more intuitive and resourceful than other faceted breadcrumb solutions due to the following key design recommendations made based on several years of designing and researching finding interfaces:
- Combine hierarchical Location & Attribute breadcrumbs
- Use Change instead of Set-Remove-Set
- Automatically retain relevant query information
- Label breadcrumb aspects
- Make it clear how to start a new search
- Allow direct keyword manipulation.
There are a series of images in the article to illustrate each of his points. To some degree, Greg’s solution reminds me of the Newssift results interface–only the IFB is better. (Newssift is now shut done and I don’t have have a screenshot handy).
In the interest of continuing this line of thought, here is some (hopefully) constructive criticism of the IFB approach.
- Longer labels – The horizontal arrangement of breadcrumb trails potentially limits scalability for longer labels. All of the examples Greg shows are fairly short. The question is, what do you do with a really long value, such as a publication title with 100 or more characters? One suggestion would be truncation with a onHover display of the full value.
- Including a search field in the breadcrumb – I’m not sure if this is necessary or even desired. It might encourage more searching, which could lead to zero results quickly. It also assumes a simple all-in-one search engine. But if you have an advanced search or search with lots of fields, it would be harder to include this. Sure, the IFB solution is few online ecommerce situations where search is generally just a single input field, so it could work. But I’d suggest putting that just above breadcrumb itself to give more room and clarity to the IFB. Of course, I could be proven wrong. Also, the keyword search in the IFB seems to always be at the end, contradicting the breadcrumb as a “path” trail. An alternative might be to convert the user-entered keyword to a value and represent it as you do the other nodes of the IFB. Accessing the dynamic menu for that keyword would then provide the option to edit it, and you could possibly include search suggestions at this point as well.
- The relationship to the filters on the left isn’t yet clear – In the screenshot of the IFB for Walmart, there are filters on the left of the screen that should be updated to reflect their correct state. Which brings up the question, how do you represent the filters once a value has been selected, particularly if multiple selections are possible? Flamenco keeps the facet header on the left (but they only allow for single selection per facet at any one time). That could work here too. But maybe all you need is the breadcrumb, even from the beginning. Tru, this would take away the “path-ness” of the trail, but you could represent the facets horizontally as a breadcrumb trail with a value of “All <facet name>” as the default value for the start. In the end you’d only have the IFB and no list of filters on the left. But there are problems with that approach too.
- Name for “super-powered” breadcrumb – We should come up with a name for enhanced breadcrumb. These have been called “selection list navigation bars ”  and “look-ahead breadcrumbs”  by others (the former of which I don’t like at all). The problem with “look-ahead” is that in the IFB you may be looking back. But perhaps it works. Other options might be “enhanced navigation breadcrumb trail” or “rich breadcrumb navigation” or “dynamic navigation breadcrumb.” Thoughts?
I quite admire Greg’s thoughts on the IFB and am jealous of his work. It’s quite inventive, and that he did testing (for apparently no project) shows real initiative.
BTW, Jason Hobbs just gave a talk at the IA Konferenz 2010 above the relationship of theory and discipline to practice. He urges us to follow the path of practice-led research. The IFB is a good example of this (I think).
 Bowler, D., Ng, W., and Schwartz, P. (2001). “Navigation bars for hierarchical websites.” University of Maryland, Student HCI Online Research. http://otal.umd.edu/SHORE2001/navBar/index.html.
 Ahmed, I. and Blustein, J. (2005?). Influence of Spatial Ability in Navigation: Using look-ahead breadcrumbs on The Web. Int. J. Web Based Communities.
Also see this excellent resource on breadcrumbs in general: http://www.ils.unc.edu/~aery/inls181/final/index.html
* Arnold Schönberg begins his book on composition: “Dieses Buch habe ich von meinen Studenten gelernt” or “I learned this book from my students.”