File upload (batch)

The user picks twelve files and clicks Upload. The wall-clock time crosses ten seconds easily — past the unit-task boundary, the user is going to disengage if the perception layer does not earn its keep. The pattern stack is bigger than the single-file case, but the principles are the same.

This scenario sits in the 10 S+ band. The perception layer carries it through the time-aware feedback progression: per-file determinate progress, aggregate progress at the top, engagement cue past the 10 s boundary, background sync option for the long tail. Myers 1985 Myers 1985 covers the per-file determinate signal; Block & Zakay 1997 Block & Zakay 1997 covers the engagement trade past 10 s; Doherty 1982 Doherty 1982 is the background-sync rationale.

What is happening

The single-file demo stands in. For a real batch, the tuned UI stacks:

1. Per-file rows — name, size, individual progress bar. The user sees the entire queue at once.
2. Aggregate progress at the top — total bytes transferred over total bytes queued. Determinate.
3. Engaging affordance past 10 s — the active queue, the upload speed, the estimated time remaining. The user has something to read while they wait.
4. "Do this in the background and notify me" option for very long batches — defer off the user's perceived path entirely via background sync.
5. Cancellation per file and per batch — the user can drop individual transfers without aborting the whole queue.

What to tune

1. Pre-action — file rows render immediately (name, size, queued state) before any bytes transfer.
2. First 1 s — per-file progress bars start filling. Aggregate bar at the top tracks total bytes transferred / queued.
3. 1 – 10 s — bars run in parallel (4–8 concurrent transfers). Cancellation visible per file and per batch.
4. Past 10 s — active-queue display: upload speed, estimated time remaining, files in flight. "Notify me when done" appears.
5. Completion — each file flips to a checkmark + metadata. Final summary row; never silent.

When perceived performance hurts you here

Batch uploads have the same trap engaging loading does — a 60-second batch with rich engagement feels short while it runs and long in retrospect. For users who upload batches multiple times per session, the retrospective cost compounds.

The cleaner answer: lean on per-file determinate progress (the user learns what's happening), aggregate progress for orientation, and background sync past the 30 s mark so the user can leave the surface. Skip the motivational quotes — the queue itself is engaging enough.

The other failure: serialising the uploads when they could be parallel. A batch UI that processes one file at a time triples the apparent duration; for small files the bottleneck is connection round-trips, not bandwidth. Parallelise to ~4–8 concurrent uploads where the network supports it.

Accessibility

1. Per-file aria-busy flags so screen readers can navigate to active items.
2. Aggregate role="progressbar" at the top of the queue.
3. Polite live region for batch-level state changes ("3 of 12 complete") — every minute or two, not every file.
4. Cancellation must be keyboard-reachable for each file and for the batch.
5. Don't trap focus on the queue — the user might want to navigate elsewhere while it runs.

References