Selection count and scope must stay in view
Aliases: selected count · bulk scope · running selection
What it is
Once bulk mode is on, people decide what to do to a set. That decision needs two facts in play the whole time: how many are selected, and the scope—this page, this filter, or items not currently shown. Count and scope must remain visible while picking, while changing filters, and while confirming. A flash on the first tick, or a number that scrolls away, is not enough. A neighboring concern is whether an action bar writes the count as chrome. Here the object is the content-operation stretch: while someone is assembling a set of records to delete or move, does the size and boundary of that set travel with the hand.
Why it happens
Bulk consequences scale with the set. Deleting 2 and deleting 200 are the same verb, different liability. Working memory cannot hold “which ones I ticked,” especially after selected rows leave the viewport or a filter changes mid-way. A visible count compresses the set into a checkable number; a scope phrase stops “select all on this screen” from being heard as “everything in the library.” If the count lives only at the top of the first screen, the basis for the decision is gone once people scroll to farther items. A confirm dialog that covers the count makes the set unknown at the moment of commitment. If a filter change silently drops or grows the selection while the number stays stale, people execute the wrong quantity.
Studying it
Have people select items across screens in a long list, then delete or move. Compare a count pinned to the action bar, a count only on the first screen, and a count covered by the dialog.
Independent variables: whether the count survives scroll, whether it also names scope (n selected / N in the current filter), whether the count tracks filter changes. Dependent variables: error in quantity estimate before execute, deletion of items never intended, confirms that still use the old quantity after a filter change.
Lab lists often fit one screen, so scope errors never appear. Use a library longer than two screens, with filters. Asking “how many will you delete” is more sensitive than whether they confirmed. Partial failure (some items cannot be deleted) desynchronizes count and outcome; tally that separately, do not fold it into “count was invisible.”
Where it stops holding
A hard cap on how many may be selected, written next to the entry, turns the count into a near-limit warning more than a scope explainer. Switch-control and speech users may not see a pinned bar; the count has to be announced, not only badged. In live collaboration, if someone else deletes an item you had selected, the count must drop immediately or it describes a set that no longer exists. An empty selection should hide or zero the count, not keep the last number.
Applying it
- Pin “n selected” on the bulk bar. With filters or paging, write “n selected (N in current filter).”
- Carry the same sentence into delete/move confirm; do not let the dialog be the moment the only number disappears.
- When filter, sort, or search changes the visible set, update the count at once. If selected items fall out of the filter, say “k selected items are outside this filter.” Do not silently clear or silently keep.
- Verify: after ticks on the second screen, without scrolling back, ask how many are selected and on what slice. Change a filter and check that the number and the spoken description move together. Mismatch means it still is not visible.