Show offline status before the action, not after submit fails

What it is

When the device already has no usable network, letting someone finish a form and only then announcing “network error” at submit hides a known constraint until after the labor. Showing offline before the action means the UI has already declared it cannot connect—disabling or degrading those actions, and saying why—before anyone starts a task that needs the network. An error page after failure may remain as a backstop; it cannot be the first channel. Offline is environment, not the ending of one submit.

Why it happens

People allocate effort according to what can be done now. If offline appears only at submit, the effort is already spent, and failure feels like a mistaken operation rather than a changed world. Browsers and systems often know connectivity much earlier; an interface that stays silent is probing the path with the user’s time. Declaring before the action moves the probe from the submit point to the decision point: one glance can drop “change payment method now” from the plan and switch to offline reading that still works. It depends on an honest split of which actions need the network. If even opening a cached article is locked as needing the network, the warning becomes over-block.

Where it stops holding

Connectivity jitters: a half-second drop in a subway should not disable everything at once, or the UI will flicker with it. The warning needs a short confirmation window that folds jitter into a stable offline or online. Purely local acts (drafting on an already open document, starring that writes locally only) need not wait on an offline warning, but should mark “will sync when back”—that is the next leaf’s queue. On a first open with no cache at all, before-action and a whole-page error coincide, and the warning is the error page. A live server with a failing endpoint is not offline; do not borrow offline copy, or people will toggle airplane mode for the wrong reason.

Applying it

• Show connectivity before a network-needing action can be reached; when already offline, disable or rewrite those actions and say “no network now.”
• Give connectivity a short stability window so buttons do not flip available/unavailable on a blip.
• If a submit still fails because of offline, the error copy should still say offline—and you should check why the warning did not stop the submit.
• Verify by turning on airplane mode and walking the main path. If “cannot connect” is news only at submit, the warning was late.

Related

• Within the group: E6.14.2 Say whether offline actions will queue for retry · E6.14.3 On reconnect, announce and sync what changed offline · E6.14.4 Long-term offline use depends on how complete local data is
• Adjacent: E6.04 Global status messages · E6.10 Error and fallback pages · E6.02 Banners
• Search terms: offline warning · connectivity before submit · pre-action status