Bulk actions must show how many items are selected and the scope they will affect
Aliases: selection count · select-all scope · bulk toolbar count
What it is
A bulk action runs on “whatever is selected,” and that set is often invisible — some rows are off-screen, some are “this page,” some are “every match.” Bulk-action scope display requires that both the count and the scope’s wording are visible before the action: twelve checked rows you can see, or 3,401 matching records. Without a count, scale is unknown. Without wording, the count can be right about the wrong set.
Why it happens
Selection is a set that is not all on stage. Checks happen at different scroll positions and under different filters; working memory cannot keep “whom did I check.” People extrapolate from the few rows in view, and read “select all” as “select all I can see.” Filters, pages, and queries rewrite the set’s boundary, while checkboxes look the same across those rewrites. Putting count and wording on the bulk toolbar moves the set out of memory and into view: the number is scale, the phrase is boundary (this page / all results / loaded only). Vague wording makes a precise number a precise description of the wrong collection. The display also has to move with every check; a lagging number is a ghost of the previous selection, and the next action hits a stale set.
Studying it
Build three selections: a few in-viewport checks, select-this-page, and select-all-filtered-results. Before the action, show no number, a number only, or a number plus wording. Record estimates of the set that will change, and whether that matches the set actually hit. Independent variables: paging, whether a filter is on, wording of the count. Dependent variables: scope estimation error, rate of believing “only the rows I see will be affected.” Asking “what does 12 refer to?” beats asking “did you notice the number.”
Where it stops holding
When the whole set fits on one screen, with no select-all and no filter, what you see is the scope and a toolbar number is redundant. In live collaboration someone else may be mutating the set, so a local number can lie — mark whether it is “your selection at this moment” or “the set on the server.” If cross-page selection is not actually implemented, the UI must not offer “select all results,” or the wording promises a set the system cannot give.
Applying it
- Keep “N selected” on the bulk toolbar and update N on every check; hide destructive actions at 0.
- When paging or filtering exists, write the scope next to the number, and offer an explicit switch between “this page” and “all N results.” Do not let an indeterminate checkbox imply both scopes.
- On changing filter, sort, or query, either keep the selection and recompute N and wording, or clear the selection. Never leave a number standing over a set that has already been replaced.
- How to check: after filtering, have someone select all, then ask how many items will move and whether those are the ones on screen. Wrong wording is a copy problem; wrong N is a counting-source problem.