An update notice must not interrupt work already underway

What it is

An update notice that appears during typing, playback, a drag, or a payment covers the next few seconds of a live task with a version problem that can wait until tomorrow. Timing belongs at a session seam: idle after launch, after a document save, when coming to the foreground with no unfinished input. Even a forced update must not become a gate on the last step of a payment; the gate belongs on the next cold start or after this transaction ends. Intensity decides whether the notice can be bypassed. Timing decides which beat it appears on. The two are independent.

Why it happens

A live action occupies motor memory and uncommitted content. A modal update notice steals focus, so keystrokes land in the dialog, the drag cancels, playback pauses. Even an instant dismiss has already broken cause: that last act did not finish, and it is unclear what was hit. Updates are rarely urgent enough to insert inside the current action—a truly urgent force should block before the action starts or after it ends, not in the middle. Attention at a seam is empty, and the notice can be handled as the next small thing; attention inside an action is full, and the same notice is an ambush. A package already downloaded, needing only a restart, still waits for a seam, because a restart hurts in-flight state more than a notice does.

Where it stops holding

If the live action is “open a known-unsafe old version and edit production data,” waiting for a seam widens the danger window. A force can insert at a save point, but still should not sit on every keystroke. Full-screen presentation, exams, and navigation apps have their own do-not-disturb; update notices must join those modes, or a background-and-return during a talk will break the seam rule. A session that never hits a seam (a document open all day) cannot hide an optional update forever; it should appear after a save or an idle timeout, not be abandoned. Firing when a timer elapses, regardless of current focus, is the usual bad implementation of timing.

Applying it

• Queue update notices at seams: cold start with nothing unsaved, a successful save, return from background with no focused input. If work is in flight, wait.
• If a forced update must happen soon, pick the moment after the nearest save or the next launch; do not insert between input events.
• Honor system or product do-not-disturb and full-screen states.
• Verify by firing an update check while typing a sentence, dragging an object, and playing media. If a dialog cuts those three, timing is still inside the action.

Related

• Within the group: E6.15.1 Forced and optional updates need different notice intensity · E6.15.2 Silent updates cut interruption but can surprise with behavior change · E6.15.3 Update notes should name the actual impact, not vague improvements
• Adjacent: E6.12 When notices dismiss · E4.10 Modal dialogs · E6.05 Confirmation dialogs
• Search terms: update timing · do not interrupt · session seam