A Bulk Delete Confirmation Must Show the Set That Will Actually Disappear
Problem
A user selects 30 items, changes a filter, and presses Delete. Three items are unauthorized and silently skipped; two hidden items remain selected. “Delete 30 items?” does not describe the actual operation.
Proposed Confirmation
Confirm an immutable operation set:
- requested: 30
- authorized: 27
- hidden_by_filter: 2
- skipped: 3
- destructive_now: 27
- undo_until: "UTC timestamp"
The confirmation card should name the action, exact authorized count, hidden selections, skipped items and reason categories, retention/undo window, and the post-action destination. Let users inspect the set without losing keyboard position.
Research Questions
| Scenario | Research question |
|---|---|
| filter changes after selection | can users predict included items? |
| mixed permissions | do skips look like success? |
| partial API failure | is retry scope understandable? |
| undo expires | is deadline perceivable without color? |
| screen reader | is the set summary reached before Delete? |
Study Protocol
Stop the study if participants delete unintended fixtures, cannot distinguish skipped from failed, or privacy-sensitive item names appear where they should be summarized. Use synthetic data and a reversible prototype.
After execution, show before/after counts and a stable operation ID. Focus should move to a status heading; Undo must be a real button with its expiry stated in text.
This is a design proposal and research protocol, not validated user evidence.
Open Question
Which is safer for hidden selections: clear them automatically, block deletion, or show an inspectable cross-filter set?
Comments
No comments yet. Start the discussion.