Choose sync state when work exists locally and the main question is whether it is queued, uploading, downloaded, accepted by the server, partially synced, failed per item, paused, or ready for conflict review.
Choose sync state when work exists locally and the main question is whether it is queued, uploading, downloaded, accepted by the server, partially synced, failed per item, paused, or ready for conflict review.
Practice the judgment: Imagine this situation: A field report says Synced while photos are still waiting in a hidden upload queue. 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 | Sync state | Offline state | Progress bar | Error state |
|---|---|---|---|---|
| UI or UX | UI + UX - Local-and-remote reconciliation status | UI + UX - Connectivity-mode and local-work continuity state | UI + UX - Measurable system-operation progress indicator | UI + UX - Recoverable failure surface |
| UI guidance | Show sync state close to the object or queue it describes, using labels such as Local saved, Queued, Syncing, Synced, Partially synced, Failed, Paused, and Conflict needs review. | 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. | 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. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. |
| UX guidance | Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers. | Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share. | 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. | 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. |
| Good UI | A field report queue shows 5 local changes: notes synced, two photos uploading, meter reading queued, signature failed with Retry, and supervisor comment needs review. | 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 document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. |
| Bad UI | A single green Saved badge appears while several attachments are still queued. | A blank page says You are offline even though the app has cached drafts and help content. | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. | Tiny transient toast for a blocking failure. |
| Good UX | A user reconnects after editing offline and sees the queue move from local saved to syncing, then to one failed photo with retry while the accepted notes remain synced. | 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. | 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. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. |
| Bad UX | The offline banner disappears after reconnect, but hidden queued changes keep failing in the background. | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. | Users leave after 100% transfer even though server processing later rejects the file. | Clearing work after save failure. |
| Best fit | Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device. | Connection loss or server reachability changes the user's current task. | A system operation has a measurable total or bounded progress value. | A system or task failure blocks expected content or action. |
| Avoid when | A confirmed failure blocks the whole view and needs a full error recovery surface. | A single request failed while the rest of the app is reachable and an error state is clearer. | The wait is short and only needs scoped activity feedback. | Nothing exists yet and the state is expected. |
| Required state | Queued state for work waiting for a sync attempt. | Offline banner or local status that names affected scope. | Idle state before the operation starts. | Normal expected state before failure. |
| Accessibility burden | Expose sync summaries through polite status updates when state changes matter to the current task. | Announce significant connectivity changes with status messaging when they affect the current task. | Provide an accessible name that identifies the operation and affected object. | Use appropriate alert or status semantics for newly appearing critical errors. |
| Common misuse | Calling local persistence Synced before remote acceptance. | Showing only a browser-style offline page when useful cached or local content exists. | Fabricating progress values just to make users feel movement. | Using a transient toast for critical errors. |