Long tasks need an intervening state between receipt and result
Aliases: pending state · processing state · task transition · asynchronous progress
What it is
An in-progress state tells people that work continues after input was received and before a final result exists, where it is in the process, and what actions remain available. It is not merely a loading animation but a visible representation of a real asynchronous lifecycle. Upload, generation, review, payment, import, and synchronization become black boxes if they jump directly from “received” to “completed”; an intervening state makes the work traceable.
Why it happens
Long waits repeatedly raise new questions: is work alive, can I leave, can I cancel, where will failure appear, and how do I continue later? Receipt answers only the first moment and completion only the outcome. An in-progress state supports decisions through progress, stage, queue, estimated range, background policy, or cancellation, while preventing silent waiting from being mistaken for failure and resubmitted. It must update with real work, not use looping animation to conceal ignorance or stall.
Studying it
Across task durations, network conditions, background switching, cancellation, retry, and injected failure, compare start/end-only feedback with an intervening state. Measure repeated input, accurate judgment that work continues, leave/cancel decisions, and reorientation after resumption. Include long-tail waits and abnormal state: quick happy-path completion cannot test an intermediate state because people never need to rely on it.
Where it stops holding
Tasks too brief to interrupt attention should not expose an elaborate process; fleeting layers only flicker. Unknown totals need not fabricate percentages and can instead show stage, activity evidence, or a traceable queue. Conversely, an in-progress state cannot last indefinitely: failure, denial, disconnection, and pause must transition into explicit states with recovery. “Processing” is not permission to delay reporting an error.
Applying it
- Define a state machine for receipt, in progress, completion, failure, cancellation, and retry, with real events driving each transition.
- Match information to duration: activity evidence for a short wait; stages, remaining range, background continuation, and cancellation consequence for longer work.
- When leaving is allowed, retain a traceable entry and completion notification; when it is not, explain the limitation and alternatives rather than silently locking the interface.
- Exercise disconnection, background resume, server long tail, and cancellation. Users should state where work is, what remains possible, and when help is needed.