Bring Back the Dead Ends
by Pete Bell
There’s still so much room for innovation on faceted search user experiences. Here’s a great improvement that’s still rarely seen in the wild: graying out dead ends instead of removing them. “Gray ends” are just for certain cases, but in those conditions, they make a big difference. Moreover, they exemplify one of the great Edward Tufte lessons.
An excellent implementation is up right now at B&H, a professional photo, video, and audio store based in New York. (Don’t miss it if you get a chance to visit their brick and mortar store. They gave me a tour, and it was clear they had designed the store experience around the well-understood needs of their pro customers — plus, it’s fun to walk down an entire row of broadcast television cameras.)
In this example, I searched for camera lenses made by Canon and narrowed the results by picking the least expensive range in facet:Price. Now if you look at the facet:Focal Length Type, voila – gray ends. They show me that when I selected the lowest price band, some focal length types, like “Super Telephoto,” are no longer available to me.
There are a few obvious benefits here, but also some nuances worth discussing. I made one more selection in facet:Focal Length Type, “Zoom Super Wide,” to highlight some of the nuances.
-In faceted spaces, when you make an explicit selection in one facet, you are also making implicit selections in the other facets. You already know this, but it’s not obvious to most users. Gray ends make it obvious, which helps them understand how facets work, and avoids confusing them when things disappear for reasons that aren’t obvious.
-To the searcher, linking explicit and implicit selections helps them understand tradeoffs. By showing the gray ends, people can understand the tradeoffs they’re making across facets without being forced to ping pong between screens. In the B&H example, I can perform sophisticated price/performance optimizations with a simple interface.
-I made that additional selection, Zoom Super Wide, to show that Focal Length Type is a multi-select facet – using the check boxes, I can now expand my selection to include, say, Wide and Super Wide lenses too. (Note it’s multi-select OR, as opposed to AND, which would have narrowed my selection.) Multi-select facets are the primary use case for gray ends. After making my first selection in the facet, I have clear visual cues from the check boxes, grays, and category counts that I can make additional choices in this facet. (B&H had an earlier implementation of multi-select without check boxes and grays, and they told me that with that earlier interface, no one noticed you could multi-select.)
-In ecommerce, gray ends can be good for merchandisers because they show abundance. For example, if there’s a facet for brands and I make a selection in a different facet that implicitly turns most of the brands into dead ends, I can still display to the shopper that I carry those brands. (Of course, as Barry Schwartz teaches us in The Paradox of Choice: Why More Is Less, additional choices can have the unexpected affect of making it so difficult for shoppers to make a decision that they’re more likely to leave empty handed.)
-You’ll notice that in facet:Price, the dead ends have been removed instead of grayed out. I can select $100-199 or $350-$499, but all the other choices in $0-$500 are gone. That’s because B&H treats price as a hierarchical facet, and from a UX standpoint, gray ends don’t work well with hierarchy. The same holds with multi-select and hierarchy, where instead of gray ends you get split ends. I’ll leave the reasoning as an exercise for the reader.
-Gray ends and multi-select can bring unwanted attention to dirty data, which everyone has in spades. In particular, things get mildly confusing for users when your records aren’t marked with at least one value from each gray end facet. For example, in the B&H example, there’s a facet for Camera Compatibility with just two choices, Full Frame or APS-C. You’ll notice in this screen shot that both are grayed out. That suggests that the remaining lenses aren’t compatible with either, but in this case, I think they’re just not tagged. The simple fix is to programmatically populate a value for “Unspecified” to gray end facets that don’t have at least one tag. The expensive fix is to clean all your data, but I’m not a utopian.
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.
If you’re a faceted UX historian, the first website I know of with an implementation of gray ends was a mutual fund evaluator that Fidelity built in the UK around 2001. Gray ends are still pretty rare, but they shouldn’t be, so I expect we’ll start seeing more of this goodness for multi-select facets.
on June 20, 2010 at 5:01 pm
Permalink
[...] Search Facet Blog von Endeca werden aktuelle Themen rings um Guided Navigation [...]
on June 29, 2010 at 7:36 pm
Permalink
I’m a fan–it’s all about the principle of least surprise. The only constraint is screen real estate: gray ends only work when you can afford to keep all facet values displayed at all times.
on July 5, 2010 at 2:56 am
Permalink
Oooh, very nice. This article brings up an interesting design decision I’ve wondered about.
B&H has 2 types of devices presented to the user:
1. Links for drilling to subcategories
2. Checkboxes for filtering
This is very intuitive. Link = drill. Checkbox = narrow.
Then it has one more type: price.
When one adds that hierarchical price facet to the mix, it creates another weird type of facet — the hierarchical for non-hierarchical data; and it looks more hierarchical than the category facet (which is flat on B&H). As we know from UX:
“People have no idea how computers work, and they have no idea what a hierarchy vs. what a facet is, etc.”
It’s all about cues and simplicity.
There is an advantage to being consistent in my opinion, and the price facet could be presented as a flat facet. It could also have been organized into a finite number of levels — say exactly 2 — to prevent the split ends problem.
It’s worthwhile to note that a certain competitor of yours takes a very simple approach of just forbidding split ends. They do not use it for price, however. They instead use to allow selecting N siblings of category at the same level.
I don’t really love this. They never allow it at level 0, which is common sense, I guess. Unfortunately, this can have the undesirable effect of disabling the ability to drill.
Amazon’s faceting interface seems to allow for multiple selections if all children are leaf nodes. This is probably 100% correct. However, it makes one wonder if those categories should have been a facet anyway.
What would be wrong with:
[x] 0-100
–[ ] 0-25
–[ ] 25-50
–[x] 50-75
–[x] 75-100
[x] 100-200
–[x] 100-125
–[ ] 125-150
…
…
It’s my gut feeling that most mortals don’t dealing with trees, but one level is fairly intuitive. The only real issue with the above I can see is the implicit “NULL selected means all.” But that can probably communicated somehow.
Thoughts? This was some great material worth pondering. Thanks.
on July 5, 2010 at 3:19 am
Permalink
Worthwhile addendum:
Using a hierarchy limited to 1 level allows for multiple price selections across parents — without split ends. The example I created demonstrated this, and 2 levels might provide:
1. Fewer clicks
2. Avoiding the split ends problem.
Or it might be a really bad idea
Not sure yet.
on July 21, 2010 at 4:31 pm
Permalink
Looks like you’re experimenting with this approach on Walmart. Nicely done. It’s very easy to use and entirely avoids the split end problem. You appear to uncheck the parent when you check a child, which is basically the same as the above. There is the duplicate state {parent} vs. {sum children} issue.
There are a few other ideas I’ve seen posited, but it looks like you’re split testing the single level price control and I can’t see what you did and didn’t do
I’d love to know how this performs. If it’s OK to share, please do.
on July 22, 2010 at 11:04 am
Permalink
Hi
We pondered this issue a number of times with our site that’s just gone live with Endeca – http://www.thomsonski.co.uk
We ended up with “gray ends” as you call them, but couldn’t get the hierarchy + multi-select to work within the timeframe. Our issue was that we did not want to have the “Update” button that you see on Walmart as we thought our customers would want instant feedback. (Direct manipulation of the data, as Mr Nielsen would say!)
Also, by using combinations of checkboxes AND links within one option, you’re potentially making the click target smaller. (Search for Tog on Fitt’s Law for more)
As a result, we’ve ended up with simple links and single select.
It’s still got a few bugs that we’re ironing out but would love to hear people’s feedback.
Cheers
DJ