Faceted navigation merges filtering with browsing
Aliases: faceted search · browse-and-filter · attribute navigation
What it is
Faceted navigation makes a single click do two jobs: narrow the current set, and enter a subset that can still be browsed. Choosing “Bronze” is not a post-hoc filter on keyword hits; it is arrival in a slice of the collection that still carries every facet and still invites the next click. Hearst uses faceted navigation for this, as distinct from faceted search that merely hangs filters beside a query box: the former lets people walk by attributes when they have no query; the latter assumes a query already happened.
It is also not faceted classification. Classification decides which independent dimensions an object can carry; navigation decides how those dimensions are walked, clicked, and treated as places. The same metadata, forced into a mutually exclusive tree, is still a browse path; only interchangeable constraints make faceted navigation.
Why it happens
Finding and browsing compete for the same cue in working memory. People often hold one known attribute (period, material, author) and no title they could type. A tree forces that attribute into the architect’s prescribed order; a query box forces it into a string. Faceted navigation lets the attribute be a step: click, the set shrinks, the other facets recompute, and the next cue stays visible. Intersection (filter) and “where I am now” (browse) become one state update.
Systems such as Flamenco treat every value as both a filter and a place. Breadcrumbs record constraints already walked; the result pane is always the content of the current place; the facet pane is always the edges still walkable from here. Drop either side and the UI collapses into “search then filter” or “pick a class then scan a list,” and the two entries cannot continue each other.
Studying it
Compare query-then-filter, pure hierarchical browse, and faceted navigation when the type of known cue varies. Yee, Hearst and colleagues’ image-collection studies are the canonical contrast: tasks scramble cue order and watch whether people type, climb a tree, or click facets.
- Paradigms: one object set, three interfaces; scripts that supply only topic, only creator, or only material.
- Independent variables: whether facets are a first move with no query, whether selected constraints rewrite as clickable places, whether breadcrumbs revoke one constraint at a time.
- Dependent variables: completion on no-query tasks, switches from browse into keywords, constraint steps, whether people can say “where I am.”
- Methodological note: if the lab forces a query before facets appear, the study measures filtering, not navigation. Score “no title in hand” tasks separately. Tiny collections make any structure look sufficient.
Where it stops holding
Strongly sequential flows (checkout, account opening, lesson 3) are not interchangeable attribute spaces; faceting them disguises steps as optional constraints. When objects share almost no metadata, facets cannot be walked, and empty panes are worse than a tree. Expert Boolean search can name several fields at once; faceted navigation serves people who will not write syntax and whose cues arrive out of order. On a narrow phone, showing results and every facet at once hits a layout wall: the merge still holds as a mechanism, but presentation must walk one facet at a time.
Applying it
- Make every facet value clickable with no query present; the click should enter that subset, not merely badge a result list.
- Write selected constraints as places that can be torn off one at a time (breadcrumb or chip); sync the result heading to the current place.
- Recompute remaining facets on the current subset so the next move is still a browse, not a return to square one.
- Verify with a task that supplies an attribute but no title (“Song-dynasty ceramics”). Completion by clicking alone is the merge working. If people must type before facets appear, navigation has not been folded in.