Resources · 75
Network failures: preserve input and resume a task
Describe waiting, failure and uncertain outcomes without losing the person’s work.
· 2 min
What this guide helps achieve
- Describe states
- Preserve proportionately
- Explain recovery
- Replay interruptions
Quick check
- Does useful input survive interruption?
- Can the person distinguish waiting from confirmation?
- Can retrying create a duplicate effect?
Step-by-step method
- 01
Describe states
Separate local input, started submission, confirmed receipt and uncertain outcomes. Missing responses can occur after server receipt. Base confirmation on business state rather than a visual change alone.
Deliverable: state map.
- 02
Preserve proportionately
Keep useful fields during errors and indicate what reload will lose. Decide explicitly whether drafts may be stored, where and for how long. Avoid automatically retaining sensitive data on shared devices.
Deliverable: draft policy.
- 03
Explain recovery
Provide understandable messages available to assistive technologies and a specific action. Distinguish fixing a field, checking a request and retrying. Keep focus and navigation coherent; color alone or fleeting toasts are insufficient.
Deliverable: messages and keyboard journey.
- 04
Replay interruptions
Test offline before submission, interrupted transfer, delayed response and restored connectivity. Use fictional data and verify retention, announcements, focus and absence of duplicated effects. Include reload and browser-back behavior.
Deliverable: end-to-end recovery evidence.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| State | Local, sent, confirmed or uncertain |
| Retention | Fields, location, duration and deletion |
| Recovery | Message, focus, verification and business effect |
Worked example
Illustrative situation
Fictional example: a request form remains waiting after a lost response.
Decision and expected evidence
The interface keeps fields, announces uncertainty and checks the request identifier before retrying. One case is created and confirmation is accessible.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Confirmed error | Offer correction or another attempt | Check whether an operation already exists |
| Uncertain outcome | Look up request state | Do not announce failure as an established fact |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Recovered input | Useful fields retained in defined cases | Fix losses and excessive retention |
| Resumed tasks | One confirmed outcome after simulated failure | Review messages, state checks and repeats |
Common pitfalls
- Erase input after a transient error
- Retry an external effect without checking its state
Frequently asked questions
Does navigator.onLine establish service access?
No. Connectivity indications do not prove your server responds or an operation succeeds.
Should all forms be stored locally?
No. Choose fields and durations according to sensitivity, device and actual recovery needs.
Can retries be automatic?
It depends on the operation. External effects require repeat protection and appropriate state checks.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
