Separate an empty result from a failed request
Imagine a Budapest print shop using an app to coordinate parcel collections. Staff open the list for a selected day. If retrieval fails, showing “No collections” could send someone away with the wrong conclusion. That message should appear only after a successful result for the visible day and filters contains no matching work.
Ask for separate examples of first load, a successfully loaded list, a valid empty result and a failed load. Include the selected date in the explanation so staff can check their context. This print shop is a hypothetical example.
Keep useful information while explaining its age
For this example, an existing list can remain visible during a refresh if the business permits staff to consult older information. Put the refresh message beside that list, and show when it was last successfully checked. If the refresh fails, the old entries must not quietly acquire a new freshness label.
Keeping a previous list helps staff stay oriented, but it risks decisions based on changed collection arrangements. Agree which actions require a fresh check. If someone changes the date while loading, ensure a late result for the previous day cannot replace the newly selected view.
Offer recovery that fits the failure
Android guidance distinguishes loading, content and error states, and recommends considering error type when retrying. MDN also explains that Fetch responses need status checks: receiving a response does not necessarily mean the request succeeded.
Have the developer demonstrate a connection interruption, an unavailable service and a session that requires sign-in again. For the print shop, agree a useful action for each case: retry the list, contact the office or return through sign-in. Avoid blaming the phone connection when the cause is unknown. Preserve the chosen date through recovery when appropriate.
Agree when automatic attempts stop and how staff can leave the screen. Automatic recovery reduces tapping during brief interruptions; repeated attempts without a clear stopping point can leave people waiting without knowing what to do.
Treat refreshing and changing a record differently
Reloading the collection list and marking a parcel collected have different consequences. MDN describes idempotency as repeated requests having the same intended server effect. Ask how that property is handled for the collection action before enabling automatic retries.
In the rehearsal, interrupt the response after the collection record changes. The app should help staff establish the recorded outcome without creating another collection event. Agree how unresolved cases reach the office, and which parcel reference staff can use. A generic Retry button should not hide these different responsibilities.
Review the states as one short story
Use fictional parcels and ask a member of staff to explain each screen before pressing anything. Record unclear wording alongside technical defects. Start with this checklist:
- Load a day with collections and a day with a confirmed empty result.
- Fail the first load, then fail a refresh of an already visible list.
- Change the date while loading and check that labels and results still match.
- Recover through retry or sign-in and verify the selected context.
- Interrupt a collection update and confirm one recorded business event.