Flaky networks are the normal case, not an error case
Aliases: flaky network · offline-first · intermittent connectivity · weak signal
What it is
Phone radios drop into high latency, high loss, or a full disconnect in elevators, subways, underground garages, roaming handoffs, and congested cells. A weak network is the ground of mobile use, not a rare fault. Painting a failed request as a full-screen red error that demands an immediate retry treats the normal case as an accident. Offline-first means locally held data stays operable; the network is a sync channel, not a prerequisite for the UI. This entry is connection quality as the default environment. It is not whether a heavy transfer should ask first, and not how background drain gets named in system battery UI.
Why it happens
Cellular round-trip time and loss move continuously with location. Application timeouts often last longer than a glance. While a request is in flight and unacknowledged, a UI that only knows success or failure spends those tens of seconds looking stuck or broken. People in motion do not stop to wait for the radio: entering a station, leaving a building, walking. If retry means reopening the page, the intent is already broken. Treating flaky links as exceptional also forces acceptance testing onto lab Wi-Fi, where latency is stable and loss is near zero, so every "needs network to tap" control passes—and then fails together in a carriage.
Studying it
Log requests on real movement paths, not scripts against an office hotspot.
Independent variables: link condition (lab Wi-Fi, congested cellular, flapping on/off), post-failure UI (full-screen error versus locally continuable), whether work is queued. Dependent variables: task completion, retry count, share of actions still possible with no link, reports of "is this broken."
A network conditioner can replay latency and loss; it cannot replay walking, entering a station, and reading a notification at once. Field logs should align failures with location change so server outages are not counted as weak radio. Mean success rate hides the tail: one percent of requests that always fall in the commute are a total failure for that cohort.
Where it stops holding
Strongly consistent money movement (a balance check followed by a transfer) must not pretend success on an unknown link; optimistic update stops there. Content that has never reached the device (a first-open uncached article) cannot be read offline from nothing; say there is no copy yet rather than fake a load. Desktop Ethernet sees flaky links less often; shipping the mobile offline-first stack there adds queues and conflict UI nobody needed. Airplane mode is a deliberate cut, unlike a flaky link: treat the former as offline immediately, the latter as quality jitter.
Applying it
- Make read, like, draft, and already-opened detail completable locally, then sync when the link returns. A timeout must not wipe the current page.
- On failure, stay on the same screen and mark "will finish when connected" rather than driving people back with a blocking error page.
- Verify by opening already-read content, switching on airplane mode, completing a like or annotation, then restoring the network. The action should remain and appear server-side after sync. If airplane mode swapped the page for an error, the weak network is still being treated as an exception.