Bundles must still show how items differ
Aliases: bundle discriminability · summary exceptions · collapsed preview
What it is
After several items collapse into one card, people still need to see what differs inside the set: who sent, which order, which device, whether a different kind of event snuck in. A count of "3 new messages" with indistinguishable members turns bundling from relief into a mask. Difference can show as one line while collapsed, or immediately on expand—but it must not require opening the app to learn what the pile contains.
This is recognizability after collapse. It is not whether to merge, and not whether handled members should leave the pile.
Why it happens
Grouping saves cards; decisions need member-level features. Vision can hold a few avatars, two keywords, and one anomaly mark in a single row. Those cues tell someone "this pile can be swept" versus "one item must be opened." When a number eats every cue, the only strategies left are ignore-the-set or open-the-set. The first misses exceptions; the second spends the time bundling just saved.
Exception members (a payment link inside an otherwise chatty thread, an @-mention in a group, shipping that flips from in-transit to failed) must surface while still collapsed, or merging will systematically bury high consequence. Discriminable is not every body expanded—that turns the summary back into a list.
Studying it
Build sets of "mostly alike plus one different." Compare count-only, a sender row, and a collapsed highlight on the exception. After a timed glance, ask whether the pile can be handled as a whole and what the exception is.
Independent variables: kinds of member cues while collapsed, whether the exception is marked, cost of the expand gesture. Dependent variables: exception detection, mistaken whole-pile clears, expand count, decision time.
If every pile is homogeneous, discriminability is untestable. The exception must be real enough to change the next action. Reading time after expand is not success—success is deciding whether to expand from the collapsed state.
Where it stops holding
When members are truly homogeneous (heartbeat of one system state, repeated readings from one sensor), a count is enough. Encrypted threads may forbid body or sender on the collapsed card; they must still distinguish which thread and whether someone mentioned you. RTL scripts and long display names will crowd out a second cue; decide which cue to keep first (identity over preview text).
Applying it
- Keep at least two collapsed cues: object identity (who / which order) and one latest preview; a third is an exception mark.
- When an event arrives that does not fully match the merge key, promote it to its own card or add a conspicuous exception row—do not keep hiding it in the count.
- After expand, members must be scannable without paging into the app.
- Verify by inserting one payment or failure among nine alike items and asking someone to look only at the collapsed card. If they cannot name the exception, the summary is a mask.