Say whether offline actions will queue for retry

What it is

While offline, some actions can be accepted now and sent when the network returns; others will only fail if tapped now. Whether they queue has to be said before the tap. If “can still write offline” is taken to mean “already handed to the server,” closing the laptop drops the draft. If “cannot send now” is taken to mean “writing is pointless,” people will not use a local draft they actually have. Queueing is not an implementation detail. It is the meaning of the click: send now, or record a to-be-sent.

Why it happens

Send and record are different promises. A failed send leaves the world unchanged; a successful record changes the world locally and not yet remotely. If the same pressed state covers both promises, people apply online experience: the button jumping to “done” means the far side is done too. An offline queue breaks that experience, so the button and the receipt have to be rewritten in the open: “will send when connected,” “saved on this device, not synced.” Once queueing is explicit, people can decide whether to change many items now, whether to wait for a network, whether it is safe to quit. Left implicit, even a reliable queue is treated as already synced, or a reliable local ability is treated as missing.

Where it stops holding

Some actions cannot queue (payment, a one-time code, inventory that must be locked on the server now). Those should be untappable offline, not collected into a queue that will never send. A queue has capacity and conflict rules; the notice should show how many are pending, and say when it is full rather than drop silently. If the user edits the same object again after recording, the queue must have a rule—latest draft, or both sends—and that rule must be inspectable on the “to sync” state. Encrypted or sensitive content should not queue on this device; refuse the record and say why.

Applying it

• Label every still-tappable offline action with its promise: fail immediately, record to send, or local forever.
• Mark to-be-sent on the object as “not synced,” with an openable queue; do not only flash a line at the moment of the tap.
• Disable actions that cannot queue, with copy that says they need a network; do not collect them into the queue.
• Verify by writing one item offline and asking “if I quit now, is it still here, and can the other side see it.” Vague answers to either mean queueing was never stated.

Related

• Within the group: E6.14.1 Show offline status before the action, not after submit fails · 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.13 Inline result presentation · E6.09 Determinate and indeterminate progress · E6.10 Error and fallback pages
• Search terms: offline queue · pending sync · outbox