| 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. | Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects. | Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers. | Use pull-to-refresh when users expect to check for newer content in a feed, inbox, list, dashboard, or status surface without leaving their current place. | 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. | An address lookup says We could not find this address, keeps postcode SW1A 1AA visible, and offers Enter address manually, Try another postcode, and Get help with reference APP-2048. |
| Bad UI | A phone shows Sent while in airplane mode and gives no queue, request ID, or local-save explanation. | A blank page says You are offline even though the app has cached drafts and help content. | A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request. | 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. | A lookup returns No matches and only shows Search again, even though manual address entry is supported. |
| 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 user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters. | 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. | A user whose address is missing from the lookup switches to manual entry with the postcode and application reference retained, completes the same application, and can return to lookup without losing typed fields. |
| Bad UX | The user repeatedly taps Submit because the app hides the offline queue and creates duplicate reports after reconnect. | The app keeps a spinner on Save during airplane mode and never explains that no network request can start. | 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 app cannot persist the action locally or safely identify whether the first attempt reached the server. | 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. | The product has no local copy or queued work and a simple loading, success, or error state is enough. | The surface is not scrollable or does not have a clear top boundary. | The only honest next step is retrying the same operation after a transient failure. |
| Required state | Online successful action state. | Online normal state with no offline warning. | Retryable failed state with affected operation, object, and preserved request context. | Local saved state for data persisted on the device but not yet sent. | Idle state with current content visible and last updated timestamp when freshness matters. | Primary path available state. |
| Accessibility burden | Use visible text and accessible names for queued, local, retrying, paused, failed, sign-in required, and sent states; do not rely on icons alone. | Announce significant connectivity changes with status messaging when they affect the current task. | Use an action label that names the operation, not only an icon or generic phrase. | Use visible text and accessible names for statuses; do not rely on spinning arrows, checkmarks, color, or icon overlays alone. | Provide a manual refresh command that does not require a path-based gesture. | Make the fallback option visible near the blocked control or step, not only in help text or after mouse hover. |
| 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. |