Filters need both per-chip removal and a clear-all action
Aliases: clear all filters · remove one filter · chip dismiss
What it is
Every applied filter must be removable on its own, and the whole set must be clearable in one stroke. Per-chip removal and clear-all are two granularities, both required. Per-chip is for attribution: when the results look wrong, people loosen the most suspicious cut and watch the set jump back. Clear-all is for when constraints have tangled and no one wants to diagnose chip by chip, returning to the unfiltered query. Clear-all alone teaches nothing about which chip was at fault; per-chip alone makes exit cost linear in the number of chips when the tangle is hopeless.
What is removed is filters, not the query and not the sort. Dismissing a chip must not delete the search terms with it.
Why it happens
Several filters form a conjunction. To learn which link cut the target out, that link must be opened alone and the count watched—a controlled experiment whose independent variable is that one filter. If the only exit is “clear all,” the experiment deletes the whole chain, attribution fails, and next time every condition is ticked again. Conversely, without clear-all, seven or eight chips means seven or eight taps, on mobile mixed with scrolling and mistaps, and people abandon filtering.
Visibility of the two actions must match granularity. A close control on the chip is “this one”; “clear all filters” beside the summary is “this group.” If chip-close clears everything, or “clear” only drops the last chip, the label and the effect disagree and the next use is withheld. After removal the list must recompute on the new constraints at once; delay looks like a missed tap and a second tap dismisses two chips.
Studying it
On a task where one of several filters hides the target, compare recovery when only clear-all exists, only per-chip exists, or both.
- Paradigms: a known item cut out by one of three filters; record which chips are removed and whether the query is cleared by mistake; Hearst’s facet UIs treat deletion of selected values as a first-class action. Logs of clear-all versus single-chip close.
- Independent variables: per-chip close present, clear-all present, whether clear-all also injures query or sort.
- Dependent variables: steps to a visible target, count of constraints removed by mistake, rate of abandoning filters.
- Methodological note: if three chips sit close and look alike, mistaps will be scored as “removal design failed”; control spacing. Lab participants told to “find which filter” over-use per-chip; field users more often clear-all. Collect both; do not gold-standard only one.
Where it stops holding
With a single filter, per-chip and clear-all are the same action; do not make two buttons compete. Forced filters (compliance, permission) must not enter the clearable set; mixed in, “clear all” either fails or the filter snaps back and looks broken. Parent–child dependencies (RAM appears only after Laptop) should cascade-remove children when the parent goes, and the child leaving should be visible, or the summary keeps orphan conditions. Undo for clear-all is valuable when many constraints were on; a mistap otherwise means reticking everything.
Applying it
- Each selected chip carries its own close; beside the summary, a separate “clear all filters” whose copy names filters as the thing being cleared.
- Neither action touches the query string or the current sort; a different “reset search” is what returns to a fully initial state.
- If many chips are on, offer one-step undo after clear-all so a mistap does not force a full retick.
- Verify by hiding a target behind three filters, only one of which is the culprit. If that one can be removed alone and the target appears, per-chip holds. If seven or eight chips clear in one stroke and the query remains, clear-all holds. If clearing filters deletes the search terms, granularity has been tangled with finding itself.