Every applied filter must remain visible

What it is

Every constraint that has been ticked must still be visible next to the results. Applied filters must all remain visible means which conditions currently narrow the set can be read from a summary beside the list, without opening a side panel and without remembering what was ticked on the previous page. Invisible filters become implicit world-state: the set shrank, and people blame the query or missing stock. Hearst’s faceted-search interfaces keep selected values as a standing summary so constraints and results stay in one glance.

Visible means “every condition in force now,” not “the filter panel must stay expanded.” The panel may collapse; the summary must not collapse the conditions away with it.

Why it happens

A filter is an assertion about the result set; people use the seen assertion to explain the seen list. If the assertion lives only inside a closed drawer, working memory has to hold a long tick-list, and it will not. The list is then read as “the world is this small,” and later query rewrites proceed from a false premise—the words were already right; an unseen “in stock only” is doing the cutting.

Partial visibility is not full visibility. Showing “4 selected” or only the most recent chip leaves the rest implicit. People will edit the chip they can see and spare the ones actually responsible for the squeeze. Filters that arrived from a URL, from personalization, or from a default, and that never enter the summary, are worse: the user never ticked them and cannot remember them. Visibility puts system-imposed and user-imposed constraints in the same chip set, rather than reporting only “what you just clicked.”

Studying it

On UIs that tuck filters into a panel, test whether people can paraphrase every current constraint without opening the panel.

• Paradigms: after a multi-filter task, close the panel and immediately ask “what is narrowing this now”; in logs, the rate of rewriting the query rather than the filters after the set shrinks. Hearst / Flamenco evaluate selected facets as persistent chrome.
• Independent variables: whether the summary lists every selected value, whether defaults are included, whether the summary survives panel close.
• Dependent variables: accuracy of reciting the full constraint set, rate of misreading the squeeze as query failure, times the panel must be opened just to discover filters.
• Methodological note: if the panel stays open for the whole lab task, “invisible after close” is never tested. Include an apply-and-collapse step. Default filters never appear in the participant’s action history; asking “what did you tick” will miss them—ask “which conditions are in force.”

Where it stops holding

A single on/off (“unread only”) can be labeled on the switch itself; it does not need a chip bar. Huge selected sets (dozens of tags) cannot be listed on one screen; the summary may fold, but folding must expand to the full list, and the folded state must still say “N more not shown.” Forced compliance filters that cannot be cleared (“only what you are allowed to see”) need not be chips, but they should appear in a scope statement so they are not attacked as ordinary filters. On a live result stream, a jittering summary can be worse than invisibility; throttle it, do not cancel visibility.

Applying it

• Keep a standing summary of selected filters above the result list, one readable chip per value in force, including defaults the user did not tick this turn.
• After the panel closes, the summary stays; do not let filters take effect in a drawer while the outside shows only a result count.
• Pre-ticks from URLs or personalization enter the same summary, marked if needed as not just-chosen (a “default” note).
• Verify by ticking three filters, closing the panel, and handing the screen to someone who did not watch. If they cannot name all three, visibility failed. Open an entry that carries a default filter; if the summary shows only the chip the user newly ticked, system-imposed constraints are still implicit.

Related

• Within the group: G3.08.2 Filters need both per-chip removal and a clear-all action · G3.08.3 Result counts should be previewed before a filter is applied
• Adjacent: G1.06 Faceted classification · G3.10 Faceted navigation · G3.07 Zero-result handling
• Search terms: applied filters · filter chips · faceted search