A long wait must be cancellable
Aliases: cancellable load · abort long wait · cancel on the wait UI
What it is
Once a load outlives the window in which thought can stay on the same job, people need a legal exit: cancel. Cancel here is a loading-semantic operation — stop this fetch or this long job — not merely the timeout-policy layer that says “an abandon exit exists”. That exit’s existence is already a requirement in another group. This leaf is stricter: on a long wait’s own UI, cancel is a first-class control, shown with progress, so people do not have to kill the app, close the page, or pull the network.
Why it happens
A long wait stakes attention and time on a path the person cannot advance. The stake can be extended voluntarily; it must be withdrawable. Without cancel, withdrawal spills into the OS: back gesture, swipe away the task, close the tab. Those tools have the wrong grain — they may tear down the whole session, or they may never notify the in-flight request, and you get “I thought it stopped; it is still writing”. In-product cancel recovers the grain to this load: end this one, keep the context.
Length is a property of the job, not of the animation. Export, sync, large files, cross-sea queries must be cancellable even with determinate progress, because progress answers “how much longer”, not “can I still change my mind”. A request so short it still sits inside the instant or continuity window will make a cancel button itself flicker; that is not an argument against cancel, it is an argument against dressing a wait no one has time to see with cancel chrome.
Where it stops holding
An uninterruptible short handshake (the few seconds a payment confirms with a bank) can omit cancel, but it must be actually short and named before entry; stretch it and cancellability returns. If cancel would leave a half-written dangerous state, that is not a reason to omit the button — it is a reason to say afterwards what happens to the half-write, the third leaf. Jobs the backend has already accepted and cannot retract when the UI cancels (a submitted print queue) should be labelled “stop showing progress and go to the task list”, not as a retracting cancel. A modal that implements cancel as a side effect of the system back key has no first-class control: not everyone uses that key, and it is unclear whether it cancels the load or the whole page.
Applying it
- For any load expected to cross the continuity-of-thought window while the person is still watching this UI, put a visible cancel next to progress or wait chrome.
- Do not hide cancel only in a system gesture. The gesture may be a second path; it must not be the only one.
- Do not flash a cancel on short requests for symmetry. Do not omit cancel on long ones because “there is already a bar”.
- How to check: start a load of at least a dozen seconds. Without reading docs, can you stop it on the wait UI itself. If the only moves are killing the app or waiting it out, this leaf is not met.