G4.07.4explain why position restore faileddesignresearch

When position restore fails, say why—deleted or reordered

Aliases: restore failure copy · deleted item · reordered list

What it is

Restore-by-object cannot find the object: deleted, merged, filtered out of the current set, moved by someone else to another page. The viewport can no longer be aimed at “that row.” Failure needs a reason—land on an honest substitute (a neighbour, the top of the list, that set’s empty state) and say in one sentence why this is not the band they left. Silently stopping on blank or silently jumping to the top is read as the restore feature breaking.

Why it happens

Restore promised continuity: “the world you left is still here.” After the object is gone, continuity cannot be kept, but an explanation can keep the model: the world changed, the navigator did not lose the bookmark. An unexplained jump to the top is indistinguishable on the surface from “restore was never implemented,” and next time people stop trusting Back. Deletion, permission withdrawn, reorder, expired filters are different branches in code and the same “that row is gone” to the user; the reason has to land on the understandable layer (“this item was deleted,” “the list was re-sorted”), not an HTTP status.

The substitute landing talks too. Stopping on blank at the old pixels looks like a hole; stopping on an unrelated hot new post looks like a recommender hijack. A neighbour, or “no longer in this filter; showing all,” is a landing that can still continue the task. The notice is one-shot and dismissible, not a permanent banner.

Studying it

Have people open a detail from an item that will fail (the experimenter deletes, reorders, or changes filters while they are away). On return, compare unexplained jump-to-top, explained neighbour landing, and explained landing on an unrelated item.

  • Dependent variables: whether the outcome is explained as “the system lost my place,” whether the current task can continue, whether the reason is retold correctly.
  • Independent variables: failure type (delete / reorder / filtered out), whether a reason is given, substitute landing.
  • Methodological note: staff who know the study will delete data will pre-attribute failure to deletion. Use a brief in which they believe the collection is unchanged. Reason copy must not use implementation words (“anchor miss”). Do not share one sentence “content updated” across failure types, or you cannot tell whether people can tell them apart.

Where it stops holding

If restore actually succeeded and new items were only inserted around it, that is object alignment, not a failure to report. If the user deleted the item in the detail, a neighbour plus one sentence is enough; it is not an apology for a system fault. A tick list that reorders almost every second would drown in per-restore notices; one standing statement—“live reorder, position is approximate”—is enough.

Applying it

  • When restore cannot find the id, branch on reason: deleted → neighbour or list plus “the original item was deleted”; reordered → still try the id, else top plus “the list was re-sorted”; filtered out → offer “clear filters to find it” rather than pretending it is in the current results.
  • Do not reuse the pixel offset from leave on failure.
  • Put the notice at the top of the list or near the old anchor, once, dismissible.
  • Verify: for the same item, apply delete, sort change, and filter change while away, then return. In all three, someone uninvolved should be able to say in their own words why they are not in the original place, and the list must not be blank. Three unexplained jumps to the top all fail.

Related

  • Within the group: G4.07.1 When a list mutates while away, restore the item, not the pixel offset · G4.07.2 Infinite-scroll restore depends on how much was loaded; returning too deep retriggers fetch · G4.07.3 Unsubmitted input drafts should survive leaving by navigation, not be cleared · G4.07.5 Cross-device resume stores position on the account, not in local state
  • Adjacent: E6.06 Empty states · H3.02 Three parts of an error message · G4.03 State persistence
  • Search terms: restore failure · deleted item · stale scroll anchor

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/G4.07.4