Arbitration must tell the user that more alarms are queued

What it is

The queue must be visible. When the system decides to play A before B, a user who hears only A readily concludes that nothing else is pending. Arbitration turns concurrent events into a sequence, and with that comes the duty to show the sequence exists, so users know events are waiting.

Why it happens

Users judge system state from observable output, and the queue is internal state—invisible by default. The consequence of invisibility is not "slightly less information" but a wrong conclusion: users think the system is clear and stop checking. A visible queue also changes time expectations: knowing two more are coming prevents repeated triggering and giving up. The cost is that queue indicators consume attention and channel capacity, so they must be lighter than the alarms themselves.

Studying it

Compare conditions with and without a queue indicator on judgment accuracy about pending events, duplicate triggering, and omission rate. Measures include missed queue items, wrong judgments, and behavior while waiting. Control queue length, since the indicator may be noise for short queues and essential for long ones.

Where it stops holding

For very short queues that drain quickly, an explicit indicator can disturb more than it helps, and a light follow-up cue suffices. If the system guarantees nothing is dropped, trust in completeness rises, but the fact "something is waiting" still needs to be visible. In high-safety settings the indicator may need greater salience, because omission costs more.

Applying it

• While the current alarm plays, indicate that further events are pending, rather than only signalling at the end.
• Let users inspect queue contents instead of waiting for sequential playback.
• Keep the indicator clearly weaker than the alarms so it does not compete for attention.
• Verification: create three concurrent alarms and, while only the first plays, ask users whether more are pending; if most say no, queue state is not visible.

Related

• Within the group: D2.10.1 Simultaneous alarms need arbitrated ordering, not overlapping playback · D2.10.4 Without arbitration, multiple alarms mask each other and critical ones go unheard
• Adjacent: D2.10.2 Higher-priority alarms should interrupt lower-priority playback · D5.06.4 Arbitration must handle queueing and dropping among simultaneous events
• Search terms: queue visibility · pending alerts · backlog indicator