Long-term offline use depends on how complete local data is

What it is

A few seconds offline and a few hours offline are not the same product state. Whether long-term offline work can continue depends on how much, and how fresh, already lives on this device: opened documents, a cached list, attachments never downloaded. The notice has to bound “what still works” to what the device actually holds, not imply with a generic offline banner that the whole app is still intact. Availability is not an offline-mode switch. It is the cache inventory.

Why it happens

In a short drop, people are still on the screen they had; working memory and pixels are still there, and missing local copies are not obvious. Over time they walk to objects never opened, search collections never cached, open attachments that live only in the cloud. Each step reaches for a local copy that does not exist. If the UI still covers all of those attempts with the same “offline,” failures pop up here and there, and no one can form an “offline boundary.” Saying the completeness—“only the 4 already opened are readable,” “search unavailable,” “attachments need a network”—draws a map. People pull the task inside the map instead of hitting walls outside it. Completeness also decays: caches expire, the system purges storage. Long-term offline availability is a falling curve; the notice should follow it, not say the same sentence in hour one and hour ten.

Where it stops holding

An offline-first app whose local store is the source of truth is highly complete; the notice should emphasize “not yet synced” rather than “features missing.” Regulated or encrypted data may forbid a full cache at all; long-term offline on those objects should be simply unavailable, not dressed as a missing network. Completeness on “this device” is not completeness for “this user” across devices; copy should name the device or “this machine.” A complete read-only cache and a complete writable cache are different rungs; when reading works and writing does not, say so separately.

Applying it

• Spell can-do / cannot-do from what is actually local, not a single “currently offline.”
• When an uncached object is opened, say “this copy is not on the device,” not a generic load failure.
• When the cache is purged or stale, update that can-do list; after a long offline stretch, restate the boundary.
• Verify by caching only a couple of objects, going offline for an hour, and tapping around. If people cannot predict what will open and what will fail, completeness was never put in the notice.

Related

• Within the group: E6.14.1 Show offline status before the action, not after submit fails · E6.14.2 Say whether offline actions will queue for retry · E6.14.3 On reconnect, announce and sync what changed offline
• Adjacent: E6.06 Empty states · E6.10 Error and fallback pages · E6.04 Global status messages
• Search terms: offline cache · local completeness · offline capability