Finish and fail both have to notify
Aliases: notify on fail too · job done · export finished
What it is
The person is no longer looking. When the task ends (done or wrecked) they have to be called back. Both completion and failure notify: success is not a bar quietly hitting 100; failure is not an entry that turns red someday. Notification is an active channel — a system banner, an in-app unread, mail, depending on where the person is — whose job is to pull attention out of another task and back to this one.
Notify only success and let people discover failure themselves, and failure goes stale in silence. Notify only failure and let people look back for success, and success is misread as still running inside expired waiting. Both have to fire.
Why it happens
Past ten seconds the main attention has left. An end event that lands on the original locus lands in an empty room. Notification switches to a channel still alive: the OS tray, the lock screen, mail, a desktop badge. Channel choice follows “where attention is now”, not “where the task object lives”.
A failure notice is a different information structure from success. Success can be short: “export ready” plus open. Failure has to name a next step, or the person is called back onto a red sentence they cannot act on, and a second leaving buries the failure again. When both ends are silent, the model freezes on “probably still running”. That frozen model blocks retry and blocks the next step that depends on the result, until a chance open. Chance is not a mechanism.
Where it stops holding
If the person is still staring at the progress view, the terminal state on that view is the notice; a system banner need not steal focus — once the view is not foreground, the system notice covers. Do-not-disturb, night, meeting mode may delay display; they must not cancel the event. After the delay it still delivers. In a batch of nine successes and one failure, a single “done” that buries the failure in a list is not enough. When law or safety forbids content on a lock screen, the notice can be “an export has ended, open to see”; failure must still be visible after open. If the user has explicitly turned this class of notice off, the progress door must still accumulate an unread terminal state; that must not be read as “allowed not to tell”.
Applying it
- The beat the task hits a terminal state, fire on a channel the person is not in: success opens the result, failure shows a door to the reason.
- Success and failure get different copy and different visual weight. They do not share a “task updated”.
- Tapping the notice should land on that task’s terminal state, not the product home.
- How to check: start background work, switch to another app or the lock screen. Succeed once, fail once. Both should notify on their own; the failure notice should show a reason, not a frozen bar. Turn system notification permission off and run again: the terminal state must still be findable in-app, not gone with the permission.