Facets allow independent filtering on several dimensions
Aliases: facets · multidimensional filtering · faceted search
What it is
Faceted classification places an object on several independent dimensions at once—color, size, price, brand—each a full axis, none of them fighting for a single slot. People can pick size then color, or the reverse, without walking a frozen path such as Clothing > Tops > Blue. Ranganathan’s facet idea was later turned into retrieval UI by Hearst and others: one query, several axes of narrowing. Facets address “we do not know which clue arrives first”—each known can be a constraint directly, without translation into a tree.
A facet is not another name for a multi-level menu. A multi-level menu is still one path. Facets are a set of constraints whose order can be swapped.
Why it happens
A tree writes decision order into the structure: this layer must be chosen before the next is visible. Facets return that order to the clue currently in hand. Each facet is a projection onto one attribute space; a check takes a subset on that projection; subsets from several facets intersect. Intersection commutes, so color-then-size and size-then-color yield the same set, and people need not guess the architect’s “correct” sequence.
That requires the objects to actually carry values on those dimensions. A faceted UI can be drawn; if the values are not on the objects, intersection is a no-op. Trees fail by taking the wrong branch. Facets fail when a constraint cannot form.
Studying it
Compare a fixed path with swappable constraints when clue order varies.
- Paradigms: the same products or documents, tree browse versus facet filters; scripts that shuffle the order in which clues are given (brand first, price first, purpose first). Image-search work such as Yee, Hearst and colleagues is a classic source for the paradigm.
- Independent variables: the available facet set, whether facets commute, whether the tree’s forced order aligns with the task’s clues.
- Dependent variables: the success gap across clue orders, number of constraint steps, whether people abandon and switch to keywords.
- Methodological note: if the lab writes every clue in the tree’s order, the tree will look sufficient. Shuffle on purpose. Too many facets is a separate problem; this leaf first tests whether independence and commutativity are needed at all.
Where it stops holding
On a tiny collection or with few dimensions, independent filtering has nothing to cut, and empty facets create “I can filter but nothing changes.” Strongly sequential tasks (wizards, courses) should not be facetized; steps are not swappable constraints. Pure exploration with no known attributes cannot take a first cut from facets and still needs a browsable entrance. Expert query languages (Boolean fields) can be stronger than facets; facets are independent constraints for people who will not write syntax, not an upper bound on fielded search.
Applying it
- Build facets only for attributes people actually use as a first cut. Do not spray every internal field as a facet.
- Each facet must be independently togglable, in any order. Do not require type before color becomes visible.
- Make sure the object model holds these fields and can intersect them before drawing the facet panel.
- Verify the same lookup with three clue orders (brand first, price first, purpose first). All three should finish without a detour. If one order still has to walk a fixed tree level, the facets are not yet independent.