Facets for used car classifieds like I would design them.
Facet design may seem like a trivial task at first. After all, it’s just a list of links representing a range of facet choices. By clicking on one choice after another users simply refine and narrow down the search results. Sort them by popularity (frequency) and show those neat hit counts on each facet choice, and you collect instant bonus points for improved usability and information scent. It’s not a lot more to it, right?
Wrong. You can and should put a lot more consideration into how you give shape to facets, in terms of both information design and interaction design. Poor facet design hurts. It alienates and confuses users by disregarding established mental models and overloading them with information. Good facet design on the other hand, makes use of web design conventions and familiar vocabulary to increase affordance and help users anticipate the effects of their actions.
It’s probably true that real knowledge of what works and what doesn’t in design should be based on empirical studies and hard evidence. But I also believe that best practices and reasoning takes us a long way towards something that works better. Design patterns, evidence-based or not, is a great asset for us all, and great things should be shared. For what it’s worth, I would like to share 3 of my own favorite design patterns for faceted search. I have good experience with these, and I hope they may serve you just as well.
Pattern 1: Multi-select with check boxes
A facet design with check boxes is ideal for multiple selection within a facet, like when you’re looking to buy a car and want your search to target a few chosen manufacturers. A facet with check boxes lets you choose all these in one go, saving you both time and frustration.
You should use check boxes for multi-selection facets because:
- It’s a strong visual design element that tells users by convention to “select as many of these as you like”. Choices are implicitly combined with a logical OR, finding items matching one or more choices.
- They work well for disjunctive (mutually exclusive) categories when it’s necessary to cross-compare items from different categories. Tabs or links, on the other hand, will not let you cross-compare.
- They support concept composition, allowing users to form idiosyncratic concepts like “Japanese cars” or “Reliable used cars” without a need for prior classification by the content editors.
- You avoid tiresome pogo-sticking between categories like you would have to with regular link list facets.
You should not use check boxes when:
- Don’t use check boxes for facet that are very large (50+) or hierarchical. Multi-selection with check boxes doesn’t scale with size.
I also add a few extra details to my multi-selection facet designs:
- I include an extra set of radio buttons (Show All/Choose Makes) to avoid confusion when all check boxes are initially empty (saving the diligent user who concernedly checks all the boxes for unnecessary work).
- I initially present a short teaser list (7±2) sorted by hit count. A link to “More choices” reveals a longer list of facet values sorted alphabetically (if another sorting criteria isn’t more suitable).
- I let the facet value hit counts indicate how many search results you add/remove by checking/un-checking an option.
Pattern 2: Single-select with radio buttons
Sometimes it’s better to think of facets as a way to toggle between different views of the result set. Examples could be a facet for low, mid and high-priced cars, or a facet for mileage ranges. These options are mutually exclusive (a car can’t have both a low and a high price, or both low and high mileage) and the number of options are few. With radio buttons it’s painfully obvious to the user that just one choice can be made at a time, and it’s reassuring to know that radio button choices can easily be changed.
You should use radio buttons for single-selection facets because:
- They work well for a small number of successive inclusive or overlapping choices, like price, date and other numerical ranges.
- It’s a strong visual design element that tells users by convention to “select either this or that”.
- Undo is really easy, since all options are visible all the time.
You should not use radio buttons when:
- Don’t use radio buttons for facets of even moderate size (9+), since long lists of options take up a lot of screen real-estate. You may also run the risk of choice overloading the users.
- Don’t use radio buttons when items need to be compared across categories. Use multi-selection with check boxes instead.
A few details I make sure to include in my single-selection facet designs:
- I include a default “Show All” option in the list that implies not having made a choice.
- Even options with zero results are visible, but disabled.
- I show facet value hit counts that indicate how many search results each choice will produce.
Pattern 3: Repeated selection with link lists
The dominant design for facets is by far the link list. In this example we have a list of features you may want in a used car. Each successive click on a facet value adds a constraint to the search, helping you find cars that match all the criteria that are important to you. Each selection also reduces the number of options left to choose from. On the upside, this interaction style takes you quickly from a larger general result set to a smaller specific one. The downside is pogo-sticking.
You should use links for repeated selection facets because:
- They work well for large facets with overlapping categories, both flat and hierarchical. Choices are implicitly combined with a logical AND, finding items matching all choices.
- Links are safe – everybody understands what a link is (not everybody understands what facets are, however, but that’s a different discussion).
You should not use links when:
- Don’t use links for facets if check boxes or radio buttons (or drop-down lists or tabs) suit your problem better.
- Facets with links have one major drawback – undo is less obvious as options disappear. Choices you make eliminate choices you haven’t made, since those options are no longer available and visible.
Some details I make sure to add to my link list facets:
- I include a “Show All” link that removes all choices made for the facet. A positive wording may encourage users to explore this feature, as opposed to a more negative “Remove Choices”.
- I provide clear visual feedback on chosen values (bold face and check mark graphics).
- Hit counts for chosen values are usually equal to the number of search results, so I simply hide those.
- I sort the teaser (7±2) on hit count, and will perhaps change the sorting to alphabetical for the full list.
More search design patterns
Peter Morville has a nice collection of search pattern screenshots. Marti Hears has published her book Search User Interfaces online for free. Rumours has it that Endeca is planning to release their UI Design Pattern Library sometime soon.
Hi Vegard,
Great stuff. Really thought provoking, as usual! Can I explore a couple the details:
“Tabs or links, on the other hand, will not let you cross-compare”. Is this strictly true? I may be mis-interpreting what you mean by ‘cross-compare’, but in principle I don’t think using links per se precludes this. If I understand you correctly, what matters is whether you ‘refine away’ the dimension once a selection has been made. Obviously for multi-select dimensions you don’t want to do this, but that doesn’t mean you *can’t* use links. For example, check out the multi-select subject dimension here, which uses links:
http://www2.lib.ncsu.edu/catalog/?view=full&Ntt=natural+language+processing&Ntk=Keyword&N=4294941540+4294965454
“Don’t use check boxes for facet that are very large (50+) or hierarchical. Multi-selection with check boxes doesn’t scale with size.” What would be your preferred alternatives? (e.g. a vertical scroll bar, a pop up expandable panel, etc?)
“I include an extra set of radio buttons (Show All/Choose Makes)” I don’t quite understand the use case for having a “show all” – isn’t that what “more choices” does? Or did you mean “Select all”?
Re Single-select with radio buttons: “Undo is really easy, since all options are visible all the time.” This implies that the dimension stays visible after selection, which for single select, would not normally be the default behaviour (they would typically be refined away, and the breadbox would then be used to maintain navigational state). In your experience, do you assume the converse (i.e. dimensions aren’t refined away by default)?
Repeated selection with link lists – I agree with your general guidance here, but the example you’ve chosen strikes me as a bit of an edge case – multi-select AND is quite rare (e.g. compared to multi-select OR) and possibly the most difficult combination to get right (IMHO). Because it is multi-select, I’d normally expect a check box to give the right affordance, but because it is AND, we have to be careful of the combinatorics (as soon as you select one feature, it affects the number of hit counts on the other features, so you *have* to update the values immediately or risk getting zero results… in which case, links perhaps give a better affordance of the “click this and something will happen straight away” interaction.
But that’s why I feel multi-select AND isn’t the best example here – unless the point you are specifically about the “Repeated selection” (i.e. the multi-select AND) part rather than the “with link lists” part (which is a much more generic design element).
Cheers,
Tony
Hi Tony!
Thanks for taking time to comment. It’s good of you to speak up when I write things that are unclear or misleading. As a consequence I learn something new from all our discussions
First I would like to answer your questions about links, check boxes and radio buttons for refinement and multi-selection:
You’re right to point out that links don’t prohibit cross-comparison between items from different categories. You give a good example of that yourself. I was making a point about check boxes having higher affordance for multi-selection, focusing on mutually exclusive categories combined with logical OR. The Subject facet in you example is a multi-select AND, which lends itself naturally to links.
I assume that links have a higher affordance for refining away options, by way of creating an expectation that clicks make something happen right away. Check boxes and radio buttons, on the other hand, create an expectation of persisting options. I’m not familiar with Endeca technology, but when working with FAST ESP it’s necessary to perform extra utility searches for facets when options need to persist despite of refinements. I assume this is required for both multi-select OR (check boxes) and single-select XOR (radio buttons).
I hope I have managed to answer you questions. In short, I find links to be good for repeated (multi-)selection AND, while check boxes work better for multi-select OR. Radio buttons may work for special cases of single-select XOR.
Then for your other questions:
Filling a screen with 50+ check boxes is not necessarilly in the best interest of the user. And I feel that multi-select OR with so many options is really a special kind of use case that you won’t find in most e-commerce applications. If it’s really necessary for “experts” to perform this kind of task, perhaps a dialog with a two-panel selector could work better, also combined with some kind of live search filtering?
http://www.welie.com/patterns/showPattern.php?patternID=parts-selector
http://ui-patterns.com/pattern/LiveFilter
“Select All” is better than “Show All” – thanks for point that out. The intended meaning was lost in translation from Norwegian
[...] [...]
Awesome. But…
Comic Sans!!!??
I digress.
Thanks for this post – it helped me better understand design decisions and possibilities when it comes to facets. Two further facet improvements came to my mind when reading it:
(1) Scaling the font size of this different elements to visualize the number of occurrences, e.g. Ford would have the biggest font size in your example for pattern 1. This is similar to the idea behind tag clouds and has been applied in some research projects, e.g. Jadeit ( http://edelstein.pebbles.cs.cmu.edu/jadeite/index.php?api=java6 )
(2) The filter element for a facet can be a visualization, e.g. a scented widget ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.401&rep=rep1&type=pdf ). This is might be appropriate if the data of the facet numerical, e.g. car mileage, or a date. VisGets is a nice example for faceted search with visualizations ( pages.cpsc.ucalgary.ca/~carey/papers/2008/VisGets2008.pdf ).
@Lars Grammel
(1) Good point about using font size to visualize the hit counts. I’m familiar with tag clouds, but I didn’t think about applying that to facets. Haven’t seen many examples of it either.
Before going down that path I would make sure that number of occurences is indeed a good indicator of relevance. Have a look at this post about the effect recall may have on faceted search, and share your thoughts with us:
http://www.thingsontop.com/mindless-recall-kills-faceted-search-876.html
(2) Visualizing numerical range facets as histograms is a good idea. Check out http://www.globrix.com for a good example. A timeline is the classical example.
Summarization, which is a strengt of visualization, may also be a drawback. When information is summarized in a timeline or POI (point of interest) on a map, the details are automatically hidden. The user then needs to perform an extra action to access the information, via a hover (mouse-over) action or a click. Whenever possible I try not to hide anything important from the user.
Thanks for sharing!