Use offline state when connectivity changes what can be read, edited, queued, or synced; use error state for confirmed failures, spinner for short indeterminate waits, and progress bar for measurable operations.
Use offline state when connectivity changes what can be read, edited, queued, or synced; use error state for confirmed failures, spinner for short indeterminate waits, and progress bar for measurable operations.
Practice the judgment: Imagine this situation: A disconnected form says Saved even though the answer exists only on the device and may conflict later. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Offline state | Error state | Loading spinner | Progress bar |
|---|---|---|---|---|
| UI or UX | UI + UX - Connectivity-mode and local-work continuity state | UI + UX - Recoverable failure surface | UI + UX - Bounded indeterminate wait indicator for a named action or region | UI + UX - Measurable system-operation progress indicator |
| UI guidance | Show offline status where it changes the current task, naming what remains available such as cached reports, local draft editing, queued saves, or read-only history. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Render a compact spinner only beside, inside, or over the affected action, component, or page region, and pair it with concise text that names what is loading or processing. | Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages. |
| UX guidance | Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Prevent duplicate or conflicting actions while the operation is in flight, but keep context, status, safe cancellation, and timeout recovery available when the wait exceeds the expected threshold. | Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later. |
| Good UI | A field report says Offline: 3 edits saved on this device, cached customer history shown from 10:42, Submit disabled until connection returns, and Retry connection. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | A Pay invoice button becomes Processing payment with a small spinner, disables only duplicate payment actions, and leaves the invoice reference visible. | A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. |
| Bad UI | A blank page says You are offline even though the app has cached drafts and help content. | Tiny transient toast for a blocking failure. | A search results panel shows skeleton rows, a spinner, and a progress bar for the same request. | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. |
| Good UX | A user loses connection while editing an inspection note, sees it saved on this device, attaches photos to a queue, and later watches the queue sync after reconnect. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | After submit, users see payment PAY-2048 processing, can tell the button is temporarily unavailable, and then get either success or retry guidance. | A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds. |
| Bad UX | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. | Clearing work after save failure. | The spinner blocks the whole workspace for a small table refresh and prevents users from continuing other work. | Users leave after 100% transfer even though server processing later rejects the file. |
| Best fit | Connection loss or server reachability changes the user's current task. | A system or task failure blocks expected content or action. | The operation has defined resolution, timeout, cancellation, or failure paths. | A system operation has a measurable total or bounded progress value. |
| Avoid when | A single request failed while the rest of the app is reachable and an error state is clearer. | Nothing exists yet and the state is expected. | The content layout is predictable and a skeleton would better preserve structure. | The wait is short and only needs scoped activity feedback. |
| Required state | Offline banner or local status that names affected scope. | Normal expected state before failure. | Inline processing state for a button or small local action. | Idle state before the operation starts. |
| Accessibility burden | Announce significant connectivity changes with status messaging when they affect the current task. | Use appropriate alert or status semantics for newly appearing critical errors. | Give the spinner or affected region an accessible name that identifies the operation. | Provide an accessible name that identifies the operation and affected object. |
| Common misuse | Showing only a browser-style offline page when useful cached or local content exists. | Using a transient toast for critical errors. | Showing an unlabeled spinner on a blank page. | Fabricating progress values just to make users feel movement. |