OAuth Flow
2 min read
Sign in. Or click "Continue with Google" and round-trip through a third-party. The wait is one to several seconds — most of it the network handshake the user can do nothing about. The perception layer cannot shorten the handshake; it can ensure the wait is filled with affordances rather than blank.
List Skeleton
A small list of items loads from a synthetic API. The naive side waits silently; the tuned side shows skeletons that match the final layout.
Off
Press Run to start
On
Press Run to start
What is happening
The list-fetch demo stands in for the OAuth round-trip. The naive side leaves the page blank; the tuned side renders a skeleton of the destination layout immediately, ready for the auth response. For real OAuth, the tuned flow looks like:
- Press feedback within 50 ms on the sign-in button — Fitch's Fitch 200 ms active-state animation.
- Optimistic redirect to the destination with a skeleton of the post-auth view — anticipating success.
- Determinate progress during the multi-step handshake (where supported) — Myers 1985 Myers 1985.
- Honest failure path if the OAuth flow rejects, with re-attempt control on the same surface.
What to tune
- Pre-action — press feedback on the sign-in button within ~50 ms; 200 ms active-state animation (Fitch).
- First 1 s — optimistic redirect to the destination with a skeleton of the post-auth view in place.
- 1 – 10 s — determinate progress where the handshake exposes stages; otherwise hold the destination skeleton.
- Completion — focus lands on the destination's main heading; the surface is ready for the user, not for the loader.
- Failure path — return to the sign-in surface with a clear, recoverable error. Never strand the user on a half-loaded destination.
When perceived performance hurts you here
OAuth handshakes can fail for reasons the user did not cause — third-party outages, expired tokens, browser quirks. An optimistic redirect that lands on a destination skeleton and then fails silently is the worst-case version of this pattern. The failure path must return the user to the sign-in surface with a clear, recoverable error message — not strand them on a half-loaded destination.
Accessibility
role="alert"on auth failure messages — the user thought they were signed in.- Focus management on the redirect — land on the destination's main heading.
- Don't trap on the spinner. A 10-second OAuth round-trip with no escape locks the user.
prefers-reduced-motionfor the redirect transition.
Other patterns that fit
Same band, same surface — switch in whichever maps best to your UI.
Pulsing Orb
AI-presence cue for short waits. Naive: a static "Working…" line. Tuned: a small primary-coloured circle that breathes (opacity + scale). Calmer than a spinner, more present than nothing — the modern "the agent is here" signal used between tool calls and after a user message.
Off
Press Run to start
On
Press Run to start
Indeterminate Progress Bar
Indeterminate inline bar. Naive: empty muted line; the wait reads as absence. Tuned: a primary-coloured segment slides left-to-right repeatedly inside the track. No completion claim — just motion that says "working." The right cue when you genuinely don't know how long it will take.
Off
Press Run to start
On
Press Run to start
Determinate Progress Bar
Top-edge bar for sub-second waits. Naive: nothing happens between click and result. Tuned: a thin bar trickles to ~80 % over the first ~300 ms, holds calm at 80 %, then snaps to 100 % when the actual work lands. Lighter cousin of the gradient-overshoot bar — no animation in the held state, no completion claim made.
Off
Press Run to start
On
Press Run to start
References · 2
- Myers 1985
Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proceedings of CHI '85, 11–17. Determinate progress beats blank wait — applies during the multi-step OAuth handshake.
- Fitch
Fitch, E. Perceived Performance: The Only Kind That Really Matters (conference talk). 200 ms active-state animation on the sign-in button covers the press feedback.