Queue pending items into one send window instead of dripping them

What it is

Deferrable items should not drip onto the device at the pace they are produced. Hold them for a send window—once an hour, at lunch, in the evening—and emit then, so one interrupt covers a batch. This is delivery scheduling, not collapsing cards already in the shade into a summary: things that have not appeared yet have their interrupt count collapsed by the clock.

Why it happens

Each arrival can cut the task once. Five like items ringing on server-event time bill five resumptions; held to a window boundary they cost about one, with the information still there. The window trades latency for interrupt count. That trade is acceptable for deferrable types and not for time-critical ones, so admission to the window is gated by the consequence matrix, not by "everything waits for the hour."

The window must also not become an on-the-hour bomb: forty items in an hour, forty sounds at the boundary, and batching has failed. The boundary should be one interrupt; the payload can be one digest or a set of cards that enter the shade together without each sounding.

Studying it

Take the same deferrable stream as "send on event" versus "send on the hour," during a real primary task. Compare interrupt count, whether information is still seen, and whether delay caused expiry.

Independent variables: window length, whether items inside the window still sound, whether time-critical types bypass. Dependent variables: interrupt count, expired unseen items, opens and handling after the window, primary-task resumption lag.

Labs make windows look "tidier," but expiry has to be measured: a code that entered the window is dead. Arrival count is not interruption—interruption is sounds or screen-takeovers.

Where it stops holding

Instant messaging carries a social expectation of seconds; forcing it into a window makes the channel look broken. Live collaboration, navigation, and call state also stay out. If the window overlaps the user's quiet hours, flush on the first window after quiet, rather than ringing on the hour inside it. After being offline, the window should merge into one catch-up, not replay the backlog at original event times as a burst of rings.

Applying it

• Put marketing, achievements, social digests, and non-urgent state on a send window; security and codes bypass.
• At the window, sound at most once; the rest enter the shade. Prefer a digest when the payload is large.
• Items whose expiry is shorter than the window must not enter the queue.
• Verify with eight deferrable items in an hour. The person should be interrupted once, not eight times, and all eight should be findable in the shade. Eight sounds means scheduling is still dripping; one interrupt with missing members means the batch became loss.

Related

• Within the group: H5.10.1 Caps should be per type, not one shared budget · H5.10.2 Quiet hours must still let high-urgency items through · H5.10.4 The cap's reset period must be visible
• Adjacent: H5.04 Notification bundling · H5.02 Interruption cost and timing · H5.07 Push frequency
• Search terms: batched delivery · send window · digest delivery