Sync state vs Offline state vs Progress bar vs Error state

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.

Sync state live example Offline state live example Progress bar live example Error state live example

Decision dimensions

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.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
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.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
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 blue bar fills across the top of the page with no label, no percent, and no affected object.	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.	The app keeps a spinner on Save during airplane mode and never explains that no network request can start.	A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.	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	The product has no local copy or queued work and a simple loading, success, or error state is enough.	A single request failed while the rest of the app is reachable and an error state is clearer.	Progress cannot be measured or would be guessed.	Nothing exists yet and the state is expected.
Required state	Local saved state for data persisted on the device but not yet sent.	Online normal state with no offline warning.	Idle state before the operation starts.	Normal expected state before failure.
Accessibility burden	Use visible text and accessible names for statuses; do not rely on spinning arrows, checkmarks, color, or icon overlays alone.	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.

Sync state

UI or UX: UI + UX - Local-and-remote reconciliation status
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.
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.
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.
Bad UI: A single green Saved badge appears while several attachments are still queued.
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.
Bad UX: The offline banner disappears after reconnect, but hidden queued changes keep failing in the background.
Best fit: Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device.
Avoid when: The product has no local copy or queued work and a simple loading, success, or error state is enough.
Required state: Local saved state for data persisted on the device but not yet sent.
Accessibility burden: Use visible text and accessible names for statuses; do not rely on spinning arrows, checkmarks, color, or icon overlays alone.
Common misuse: Calling local persistence Synced before remote acceptance.

Offline state

UI or UX: UI + UX - Connectivity-mode and local-work continuity state
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.
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.
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.
Bad UI: A blank page says You are offline even though the app has cached drafts and help content.
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.
Bad UX: The app keeps a spinner on Save during airplane mode and never explains that no network request can start.
Best fit: Connection loss or server reachability changes the user's current task.
Avoid when: A single request failed while the rest of the app is reachable and an error state is clearer.
Required state: Online normal state with no offline warning.
Accessibility burden: Announce significant connectivity changes with status messaging when they affect the current task.
Common misuse: Showing only a browser-style offline page when useful cached or local content exists.

Progress bar

UI or UX: UI + UX - Measurable system-operation progress indicator
UI guidance: 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 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 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 blue bar fills across the top of the page with no label, no percent, and no affected object.
Good UX: 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 fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.
Best fit: A system operation has a measurable total or bounded progress value.
Avoid when: Progress cannot be measured or would be guessed.
Required state: Idle state before the operation starts.
Accessibility burden: Provide an accessible name that identifies the operation and affected object.
Common misuse: Fabricating progress values just to make users feel movement.

Error state

UI or UX: UI + UX - Recoverable failure surface
UI guidance: Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance: Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI: Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI: Tiny transient toast for a blocking failure.
Good UX: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX: Clearing work after save failure.
Best fit: A system or task failure blocks expected content or action.
Avoid when: Nothing exists yet and the state is expected.
Required state: Normal expected state before failure.
Accessibility burden: Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse: Using a transient toast for critical errors.

Decision rules

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 offline state when the device or app cannot reach the network and users need to know which cached data, local edits, and online-only actions are available or unavailable.
Choose progress bar when the operation has a meaningful numeric amount, such as bytes uploaded, records imported, or photos processed, and the percentage itself helps users judge time or scope.
Choose error state when a load, save, submit, sync, validation, or permission attempt has already failed and the affected item needs durable recovery instructions.
Do not say Synced or Saved online until the remote copy has accepted the local change; distinguish local saved, queued, syncing, synced, failed, and conflict-needs-review states.
Do not hide a multi-item sync queue behind one global spinner; show item-level status, failed items, retry actions, and last successful sync time.
Use sync state at the smallest truthful scope: app account, folder, record, attachment, field edit, message, or one queue item.
When sync fails for only part of the queue, preserve the completed items, keep unsynced local data visible, and offer retry, cancel, export, or review rather than clearing the whole queue.

Inspect live examples

Sync state Offline state Progress bar Error state

Failure modes

A field report says Synced while photos are still waiting in a hidden upload queue.
A single spinner covers five queued changes, so users cannot see that one item failed and four succeeded.
A disconnected app shows sync progress even though no request can leave the device.
A failed server validation is treated as generic offline mode, so users keep retrying a change that needs editing.
The app clears local work after a sync error instead of preserving it with retry or export.
A percentage reaches 100 percent before server acceptance, making users believe remote save is complete.