A Selection Counter for Nested Bulk Actions
Picture a catalogue admin screen listing product families. Each family row can expand to show its variants. A user ticks a family, clicks "Archive", and wonders: did that archive the family only, or all twelve variants hidden beneath it? If the interface cannot answer, people either hesitate or act on a guess. This article proposes a selection counter that states the scope plainly. Everything here is a design proposal to test with your own data.
First decide what a parent tick means
There are three possible meanings, and your screen must pick one per action, not leave it to inference.
Meaning 1, parent only: the action applies to the parent record and nothing below it.
Meaning 2, parent and all children: the action cascades, including children that are collapsed, filtered out, or on another page.
Meaning 3, parent and visible children: the action covers only children currently shown. This is the riskiest meaning because the result depends on view state, so consider avoiding it.
Some actions suit different meanings. Changing a family label might be parent only. Archiving might cascade. Write the choice down per action.
Selection-scope truth table
Use this table as the primary artifact. Rows are selection states, columns are what the action touches. Adapt the action meaning to your choice.
State 1: parent ticked, children collapsed. Counter should say the parent and its hidden children if the action cascades, otherwise the parent only.
State 2: parent ticked, children expanded, all children ticked. Counted records are the parent plus every child.
State 3: parent ticked, children expanded, one child unticked. Parent shows a partial state. The counter should name the exclusion, for example one variant excluded.
State 4: parent unticked, one child ticked. Only that child is counted. The parent shows a partial mark and is not counted.
State 5: filter hides some children, parent ticked. Decide explicitly. The counter should say whether filtered-out children are included, and the confirmation should repeat it.
State 6: children span pages. The counter should state a total, not a page count.
Counter wording to try
A single number is not enough. Consider two parts: the count and the scope. For example, "3 families selected, including 27 variants not currently shown" for a cascade, or "3 families selected, variants not affected" for parent only. For a partial state, "3 families, 26 of 27 variants, 1 excluded".
The confirmation button should echo the count: "Archive 30 records", not "Archive".
Hypothetical worked example
Suppose a user selects two families. Family A has 5 variants, Family B has 3, all collapsed. Archiving cascades. The counter reads "2 families selected, including 8 variants not currently shown", and the button reads "Archive 10 records". The user then expands Family B and unticks one variant. The counter updates to "2 families, 7 of 8 variants, 1 excluded" and the button to "Archive 9 records". Each figure can be checked by arithmetic: 2 plus 5 plus 2 variants of B... recompute: 2 parents plus 5 plus 2 is wrong; Family B now has 3 minus 1, which is 2 variants, so 2 plus 5 plus 2 equals 9, and the counter reads 7 of 8 variants. The numbers agree.
Branching choices
If records are costly to restore, choose parent only by default and offer cascade as an explicit secondary option. If the action is easily reversed, cascade with a clear counter may be acceptable. If you cannot compute hidden child counts cheaply, say "and all variants" without a number rather than showing a wrong one.
Stop conditions
Pause the design if testers cannot state the scope after reading the counter alone, if the counter and the final result differ in any case, or if the same tick means different things in different actions without a visible cue.
Acceptance checks
For each truth table row, a reviewer predicts the affected count before clicking, then compares it with the counter and the result log. All three should match. Treat any mismatch as a defect in the design, not in the reviewer.