Long loads need a cancel

What it is

A lock stops a second send; it should not trap someone in a wait they cannot leave. When loading clearly outlasts a short acknowledgement—upload, payment confirmation, remote render—the UI needs a cancel / abort: stop the request, unlock the button, return to an editable state. A long load with no cancel leaves people to kill the process, go Back, or mash a dead key.

Why it happens

How long a wait is tolerable depends on whether one can leave. Knowing cancel exists keeps attention on the task; without it, uncertainty inflates the wait and produces kill-app, reopen, submit again from another device—the real duplicates. Cancel is not undo of a succeeded transaction; it is abort of one that has not finished. The request must be abortable (client cancel of fetch, server drop of the unfinished job). Otherwise the on-button Cancel only unlocks locally and the server may still write later: “I cancelled and it still ordered.” Duration also interacts with known progress: an indeterminate spinner needs cancel more, because people cannot tell wait from death.

Studying it

Set submit delay to 8–20 seconds, with and without cancel. Allow process-kill and Back. Log when people abandon, which path they take, and whether the server still writes after a cancel.

Independent variables: delay, presence of cancel, determinate progress, whether cancel actually aborts the server. Dependent variables: abandon rate, kill rate, ghost success after cancel, time to re-enter the task.

Lab participants know it is a study and kill less. On their own device and account the motive “I might be charged twice, kill it” shows up.

Where it stops holding

A cancel on a request that dies inside 200 ms will only flash. Once the server has committed (money taken), cancel must become undo / refund, or the copy is lying. An offline queued send cancels a queue item; say that it has not gone out. Cancel itself must be keyboard-reachable and not exist only as decoration on a spinner.

Applying it

• If an operation still has no result after a few seconds, put Cancel beside the button or turn the button into an abort, and actually abort the request.
• After cancel, restore editable content and unlock; do not clear the form.
• If the transaction may already have committed, check and say truthfully “not sent” or “already sent, go undo.”
• Verify on a 10-second fake delay: cancel should abort in the network panel and leave no successful server write. A submit immediately after cancel should produce one new request.

Related

• Within the group: E1.09.1 Lock the control immediately after submit to prevent a second send · E1.09.2 Loading must keep the button’s size stable
• Adjacent: E1.17 Loading buttons and double-submit prevention · I2 Loading and waiting · H3.10 Retry strategy
• Search terms: abort request · cancelable submit · in-flight cancel