Offline must be indicated, not inferred
Aliases: offline badge · disconnected state · connectivity lamp
What it is
The device is already off the network and the interface still looks as if it were on — that is the expensive kind of unknown. Offline must be indicated: a stable, readable signal that cannot be drowned by content says “there is no connection now”, rather than waiting for a submit to fail and leaving people to guess. The signal is the connectivity fact, not which features still work, and not whether actions will queue. Those two questions can only be asked once the indicator exists.
Without the indicator, offline is perceived as jank, blankness, or “the product is broken”. With it, offline becomes a named mode.
Why it happens
Connectivity is a global mode that occupies almost no pixels. People default to “I opened this app, therefore we are online”; the default is tested only at failure. Failure often wears other errors’ clothes: a timeout, an empty list, a spinner that will not stop. Attribution lands on content, account, server — not the radio. An explicit indicator turns connection from inference into perception: before the gulf of evaluation closes, “is the world reachable” is already in view.
The indicator has to survive attention leaving. A toast that says “network unavailable” and dies sends the person to a message and back, and the model returns to default-online. So an offline indicator behaves like a mode lamp: while still offline, the lamp stays. It competes with content for a persistent slot, not for a burst of attention.
Where it stops holding
In environments where airplane mode or a system-wide “no network” bar is already hard, the in-app cue can be quieter — it cannot treat the system bar as its own state. Users dismiss system notices; the app still owes a line. A weak link (high latency, loss) is not offline: labelling it offline forbids requests that would still work; labelling it online makes timeouts look like breakage. Weak links need their own honest phrase (“connection unstable”), not a seat in the offline lamp. LAN up, public net down (intranet tools, cached sites) splits “can I work” from “can I sync to the cloud”; one lamp is not enough — say which hop is missing. A background sync process dying while foreground browsing still routes must not paint the whole app offline.
Applying it
- Put a lamp in the primary task view that stays for as long as the device is offline: a top bar, a dot by the avatar, a line under the title. Do not rely on a single toast.
- Copy names connectivity, not “something went wrong”. Offline, weak link, and server fault get three vocabularies; they do not share one red dot.
- Both going offline and coming back must change the lamp. On restore the lamp can go out, with an optional “reconnected” line on top — that line must not be the only home.
- How to check: turn on airplane mode, return to the product’s home, wait three seconds. If “we are off the net” cannot be read in the primary view, the indicator failed. Turn airplane off: the lamp should die after connectivity actually returns, not when a button merely looks tappable. Walk the path with a screen reader; offline must be spoken as a state, not only recolored.