Background work must have progress you can look up
Aliases: job progress · look-up progress · export progress
What it is
The task no longer owns the current screen, yet a person must be able, when they remember, to ask “how far is it”. Queryable progress is an answer that does not depend on still staring at that patch: a percent, a stage name, a count processed, readable from a fixed door. A spinner, a one-shot toast, a “please wait” are not progress once the person has left — they cannot be asked again.
This leaf is the ability to query. How completion calls the person back, whether a task list is the component, whether work continues after quit, are other questions. Without queryability, background is a task thrown into an unaddressable hole.
Why it happens
Past about ten seconds, attention leaves this human–computer dialogue and the task keeps running. After leaving, pixel change at the original locus no longer enters perception. If progress lives only in the patch about to be left, information and attention vanish together. Queryability makes progress addressable state: a name, a door, a current value, still sampleable from another screen, another time. Sampling is active, so it does not replace a completion notice; it replaces the anxiety of “I think it wedged, all I can do is wait”.
Progress also has to be true at query time. A bar forever at 73%, or one that jumps 0 to 90 on every open, makes the query a second lie. Queryable includes a stable current value, not “there is a bar”. A stage name (“compressing”, “uploading”) is more askable than a fake percent when remaining time cannot be estimated.
Where it stops holding
Work that ends inside a second or two does not need queryable progress; the door would outlive the task. Uninterruptible, unobservable kernel work (some hardware wipes) can only report “in progress”, but “in progress” must still be askable again, not a sentence that existed only on the first click. A shared export’s progress should be queryable to the initiator, not necessarily to every collaborator. For a screen-reader user the query is a status region or a title, not bar width; queryability has to hold for them too. When frontend polling is frozen by the OS, on-device progress stalls while the task may continue on the server — the query should hit the authority, not read a stale local bar.
Applying it
- Every background job that may exceed ten seconds has a progress view that can be re-opened: stage or ratio, plus elapsed time since start.
- The door stays for the life of the task; it does not unload with the current page. Leave and return: the value continues, it does not play from zero.
- When remaining cannot be estimated, show stage and amount done. Do not invent a percent.
- How to check: start an export of at least 30 s, switch page, ask progress from the door. If the door is missing, or opens blank / plays from 0, it fails. Slow the network so the stage sits on “upload”: the queried stage should still be upload, not a fake smooth bar.