E2.15.3visible upload progress and retrydesign

Progress and failure must be visible and retryable

Aliases: upload progress · silent upload fail · retry without re-pick

What it is

After a file leaves the device there is a stretch when it is neither local nor on the server. That stretch must be seeable: how much has moved, whether it has stalled, whether failure can be tried again. Visible upload progress and retry argues against “a spinner after choose, a red line on fail” and against “failure means pick the file again.” The issue is state while bytes are in flight, not the intake for choosing, and not type copy before the choice.

Why it happens

Upload is a long operation; networks jitter, drop, and get refused. Without determinate progress people cannot tell “still going” from “already dead,” so they resubmit the same file into two copies, or leave and cancel the request. Failure that only says “error” and drops the chosen file makes retry into another folder search, cruel for large files. Progress must bind “this file” to a bar: one aggregate bar over many files hides a single failure. Retryable means the failure state still holds that local reference or the chunks already cut, and one click continues, rather than returning to an empty intake.

Where it stops holding

Tiny files finish in a blink; a bar that flashes is worse than going straight to success—but failure must still be retryable. Background upload (still going after the page closes) needs a system task; an unseen web bar is not “no progress,” and the copy should say to watch notifications. Auth expiry and quota failures will fail the same file again; change the reason copy rather than pretending another click will help. Screen readers need announced state changes, not an invisible bar.

Applying it

  • Show determinate progress per file (bytes or percent); when the total cannot be estimated, still say “still transferring” rather than a frozen spinner.
  • On failure keep the filename, the reason, and Retry; do not clear the chosen list.
  • Warn before leave that an unfinished upload will cancel, or continue in the background and give an inlet to it.
  • Verify on a slow network with a large file, drop the network mid-way, then tap retry. The same file should continue or re-send from the failure state without reopening a folder. Progress must have been moving before the drop; movement with neither success nor failure is invisibility.

Related

  • Within the group: E2.15.1 Offer both click-to-choose and drop · E2.15.2 State type and size limits before the file is chosen
  • Adjacent: E6.09 Determinate and indeterminate progress · E6.10 Error and fallback pages
  • Search terms: visible upload progress and retry · upload failure · resumable upload

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E2.15.3