Selection

Picking one or more items from a set of options the actor can see, persisting until released or acted upon.

Forces

• Recognition against recall — an exposed set lets the actor recognise the value instead of recalling it, and doubles as documentation of what’s available
• Scan cost against typing cost — small sets are cheapest to scan whole, large sets cheaper to type against; visible options → collapsed list → type-to-narrow → search is one move that scales with set size, not four separate ones

Dimensions

• Cardinality — single, multi (set), range (contiguous span). These have different mental models and different input grammars
• Granularity — items in a collection, sub-items inside an item (cells in a row), content inside an item (text in a cell). Each granularity layer can hold its own selection, and they have to compose without colliding
• Persistence scope — does the selection survive scrolling, filtering, sorting, paging, navigation, refresh
• Visibility — explicit (checkboxes always present), implicit (highlight only, no resting affordance), or mode-based (an edit-mode toggle reveals checkboxes)
• Input modality — pointer (click, shift+click, ctrl+click, drag-rectangle), keyboard (shift+arrow, ctrl+a, space), touch (long-press, edit mode), assistive technology

Cardinality

Single selection

The “current item” model. The actor picks one thing; picking another replaces the first. This is the implicit baseline in inspector-style interfaces where one item drives a detail view.

The question is whether this is selection at all, or focus with extra affordance. The distinction is whether the item is acted on as a target (selection) or navigated to as a position (focus). When clicking a row reveals its details in a panel, that’s focus. When clicking a row arms a delete button in a toolbar, that’s selection.

Multi-selection

Non-contiguous, additive. The actor builds up a set by ticking checkboxes or modifier-clicking. The set has no internal order beyond insertion; each item is in or out independently of the others.

Feedback for the selected set

• Inline state on the items themselves — checkmarks, tick rows, highlight on selected rows. Cheap, but invisible the moment the actor scrolls past the selection.
• Chip rendering elsewhere in the UI — selected items rendered as removable chips in a header strip, side panel, or toolbar. Survives scroll, doubles as a remove-from-selection affordance, but costs layout.

The chip is worth it when the selection is intended to outlive the current view (e.g. building up a set across paged or filtered results). The list-only feedback is fine when the selection is acted on immediately.

Select all / Clear all threshold

A “Select all” master checkbox and a “Clear” affordance are the cheapest way to make the cardinality of the operation explicit. They earn their weight roughly when the visible set exceeds ~5 items, or when “all” is a coherent operation in the actor’s mental model (the inbox, the search results, the filter match). Below that threshold, individual ticks are faster than reading and resolving a master state.

Range selection

Contiguous, anchor-and-extend. The actor picks a start, then a span. Shift+click and drag-rectangle are the canonical inputs.

Range selection looks like a subset of multi-selection but behaves differently under sort and filter: when the underlying order changes, “the range from row 5 to row 12” loses meaning, while “these specific items” survives. A range selection has to be reified into a set the moment its frame of reference moves, or it has to explicitly track the anchors and re-resolve them.

Granularity

Item selection

The default case: items in a list, rows in a table, cards in a grid. Everything in the cardinality section above assumes this granularity.

Sub-item selection

Cells in a row, fields in a record. Common in spreadsheets; rare elsewhere. Sub-item selection composes with item selection — selecting a cell can imply selecting its row, or it can stay strictly local. The choice should match how the action surfaces are scoped: if the toolbar acts on rows, cell selection should imply row selection; if it acts on cells, it shouldn’t.

Content selection

Text inside an item, regions of an image, ranges of time on a timeline. The mechanics are isomorphic to range selection (anchor-and-extend).

The principles transfer: persistence under view changes, coherent input grammar, explicit semantics for “select all”. The differences are mostly in the affordances, not the underlying pattern.

Cross-view persistence

When the actor selects 12 rows and then sorts the table, are the same 12 still selected? When they filter, do filtered-out items remain in the selection set? When they page forward, does the selection from page 1 survive? Some options:

• Selection lives with the viewport — anything not currently visible is silently removed from the selection. Simple to implement, easy to reason about, but loses the actor’s commitment the moment they look away. Acceptable when selections are short-lived and small.
• Selection lives with the data — selected items persist regardless of whether they’re currently visible. The actor’s commitment is honoured, but they may end up acting on items they can’t see. This requires showing the actor that off-screen items are still in the selection (“12 selected, 8 not in current view”), or it becomes a footgun.
• Selection lives with the data, filter narrows the scope of action — selected items persist, but operations apply only to the visible intersection. Honours commitment without acting on the invisible. The most defensible choice for most cases, and the hardest to implement coherently.

”Select all” under filtering and paging

When 50 of 10,000 items are visible and the actor clicks the master checkbox, what does it mean?

• All visible — selects the 50 on screen. Predictable but often not what the actor wants.
• All matching — selects all 10,000 that match the current filter. What the actor probably wants, but invisible to them; needs explicit confirmation.
• All in collection — selects all items in the underlying collection regardless of filter. Almost never what the actor wants and usually a bug.

A go-to solution is to select the visible view first, then offer a follow-up affordance (“Select all 1,234 items”) that escalates to the matching set. Two-step opt-in: the actor sees the consequence of the smaller commitment before being offered the larger one.

Visibility and discoverability

How does the actor learn that items are selectable in the first place?

• Always-visible checkboxes — maximum discoverability, maximum visual noise. Appropriate when selection is a primary capability of the view (inboxes, file managers).
• Hover-revealed checkboxes — checkboxes appear on row hover, persist when selected. Reduces visual noise without hiding the affordance entirely. Doesn’t work on touch.
• Mode-based selection — an explicit select/edit toggle reveals checkboxes. Common on touch surfaces where hover doesn’t exist, and on content-first views where always-on selection would dominate the layout.

• Implicit selection through pointer gestures — no checkboxes; click-to-select, shift+click for range, ctrl+click for set.

Selection and filter as duals

Filter is declarative selection (“everything matching X”); selection is imperative filtering (“these specific items”). They solve adjacent problems, and the same scope can usually be reached either way.

The question for any view that supports both: can a filter be narrowed by a selection (act on these specific items within the filter)? Can a selection be converted into a filter (show only what I selected)?

To-do

Collaborative selection – co-presence cursors, shared selection state, “see what others have selected”. The mechanics differ enough (conflict, decay, identity) that they deserve their own treatment.

Related components

• Action bar — the primary consumer of multi-item selection; its existence is conditional on a selection existing
• Bubble menu — the primary consumer of content-range selection; spatially anchored to the selection
• Context menu — degenerate-case consumer; pointer-invoked on a single target
• Checkbox — the most explicit selection affordance
• Block-based editor — the surface in which content selection happens