Choose offline state when the primary job is explaining what remains usable while disconnected, such as cached content, read-only mode, local drafts, unavailable online actions, stale data, or reconnect checks.
Choose offline state when the primary job is explaining what remains usable while disconnected, such as cached content, read-only mode, local drafts, unavailable online actions, stale data, or reconnect checks.
Practice the judgment: Imagine this situation: A mobile form says Sent while offline and later creates duplicate records when users tap Submit again. 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 mobile retry | Offline state | Retry | Sync state | Pull to refresh | Fallback path |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Mobile queued-action retry and background replay recovery | UI + UX - Connectivity-mode and local-work continuity state | UI + UX - Scoped failed-operation retry control | UI + UX - Local-and-remote reconciliation status | UI + UX - Top-of-scroll vertical drag gesture that refreshes the current data set | UI + UX - User-directed alternate route when the primary path cannot complete |
| UI guidance | Render a mobile retry surface that names the queued action, local storage location, last attempt, next retry trigger, manual retry control, background retry eligibility, and duplicate-submit guard instead of using only a global offline banner. | 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. | Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization. | 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 pull-to-refresh only at the beginning of scrollable content, with a clear pull distance, threshold, release-to-refresh state, refreshing indicator, and completion status tied to the current data set. | Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence. |
| UX guidance | Use offline mobile retry when users need confidence that a mobile save, send, upload, submit, check-in, or payment attempt is preserved locally and will retry safely when connection and policy conditions allow. | Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share. | Help the person reach a clear task outcome. | Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers. | Help the person reach a clear task outcome. | Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task. |
| Good UI | A mobile inspection form says Saved on this device, 2 photos queued, last attempt 10:42, next retry on Wi-Fi, Retry now, and request ID MOB-1842. | 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 report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048. | 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 mobile inbox at the top of the message list shows Pull to refresh, Release to refresh, Refreshing, Last updated 10:42, and a Refresh menu item that runs the same request. | A service dependency outage panel says Identity check unavailable, shows saved application answers, and offers Upload documents for manual review with expected review time. |
| Bad UI | Queued mobile work disappears after the app is backgrounded or restarted. | A blank page says You are offline even though the app has cached drafts and help content. | Retry creates duplicate records, payments, invitations, exports, or queued jobs. | A single green Saved badge appears while several attachments are still queued. | A feed refreshes from any scroll position, causing accidental network calls while users read older content. | The only visible action repeats the failing lookup or request. |
| Good UX | A user submits a field report in a basement, sees it queued locally with photos and an idempotency reference, closes the app, and later sees background retry complete after reconnect. | 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 second failure increases the wait before the next attempt and then offers cached export, background notification, or support reference after attempts are exhausted. | 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 reaches the top of a notifications list, drags down, sees the pull distance cross threshold, releases, and the list updates while older items stay in place. | The person reaches the intended result with clear feedback. |
| Bad UX | The user repeatedly taps Submit because the app hides the offline queue and creates duplicate reports after reconnect. | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. | The app retries aggressively every second during an outage and makes the service harder to recover. | The offline banner disappears after reconnect, but hidden queued changes keep failing in the background. | A user tries to scroll up inside a nested comments panel and accidentally refreshes the whole page. | A user tries the same failed lookup five times because the manual route is hidden until after repeated failure. |
| Best fit | A mobile user action can be saved locally and retried after network or app lifecycle conditions improve. | Connection loss or server reachability changes the user's current task. | A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason. | Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device. | A top-of-list gesture is a platform-expected shortcut for checking freshness on a scrollable data surface. | A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish. |
| Avoid when | The failure is a validation, permission, policy, or conflict issue that needs correction before retry. | A single request failed while the rest of the app is reachable and an error state is clearer. | The error is caused by invalid user input and correction is required. | A confirmed failure blocks the whole view and needs a full error recovery surface. | Data freshness must be automatic, real-time, scheduled, or explicit through a visible command rather than hidden behind a gesture. | The only honest next step is retrying the same operation after a transient failure. |
| Required state | Online successful action state. | Offline banner or local status that names affected scope. | Retryable failed state with affected operation, object, and preserved request context. | Queued state for work waiting for a sync attempt. | Idle state with current content visible and last updated timestamp when freshness matters. | Primary path available state. |
| Accessibility burden | Expose queue state changes through polite status messages when they affect the current task. | Announce significant connectivity changes with status messaging when they affect the current task. | Expose pending, failed again, cooldown, succeeded, exhausted, and non-retryable outcomes through status text or live regions. | Expose sync summaries through polite status updates when state changes matter to the current task. | Keep refresh controls reachable by keyboard, switch, screen reader, external keyboard, and assistive pointer devices. | Use specific link and button names that describe the alternate method and outcome. |
| Common misuse | Showing a success toast for an offline submission that is only queued. | Showing only a browser-style offline page when useful cached or local content exists. | Offering Retry for every error regardless of whether the user or system state can change. | Calling local persistence Synced before remote acceptance. | Making pull-to-refresh the only way to update the data. | Hiding manual entry or support until users repeatedly fail. |