E4.08.3list-position restoration on backdesignresearch

After that degradation, returning to the list must restore position

Aliases: scroll restoration · restore list offset · master-detail back

What it is

Once a narrow screen has folded master-detail into two pages, list context can only be cashed on the way back. List-position restoration means returning to the same stretch: scroll offset, selected row, filters, and the loaded window are still there, rather than dumping the reader at the top or a reset first page. Degradation already spent the neighbours in peripheral view. If position is not returned either, every row change in an inspection task starts from scratch.

Why it happens

Position is the coordinate of external memory. People remember “I was about halfway down,” and hand and gaze are ready to continue there. If the list unmounts and remounts, default scroll is 0 and selection may drop with it; the coordinate resets. It can feel as if the dataset changed, or as if this is the wrong page. A virtualised list must restore the data window, not only a pixel offset: remembering a number while the window reloads from page one leaves that stretch uncached, and the view goes blank or lands on the wrong row. If filter and sort were cleared on entering detail, return is not merely the wrong place — it is a different collection. Restoration has to bind to “which list this was,” not a global scroll value applied to every list.

Studying it

From mid-list, open detail and come back, comparing restore-offset, jump-to-top, and restore-selection-without-scroll. Record time to the next row, reports that the list was refreshed, and blank windows. Independent variables: virtualisation, whether the list unmounted in detail, whether filters persist. Dependent variables: position error (pixels or row index), time to resume inspection. Do not only ask “did we get back to the list”; ask “did we get back near that row.”

Where it stops holding

If the list was rewritten while detail was open (a new message inserted at top, a collaborator deleted the current row), exact pixels may be meaningless; scroll the original selected row into view if it still exists, or land on a neighbour and say why. One-shot search result lists may be stale on return; restore position together with the query, or the coordinate points at another hit list. Desktop master-detail never unmounted the list, so this constraint mainly fires on the degraded stack.

Applying it

  • Before entering detail, store the list identity, a scroll offset or anchor row id, and filter/sort. On back, align the viewport to the anchor row rather than only setting a pixel value.
  • For a virtualised list, restore the data window too, so the view does not paint empty and then flash to the middle.
  • If the original row is gone, scroll to the nearest neighbour and give a short reason; do not silently jump to the top.
  • How to check: enter detail from row N and return; the viewport should still contain row N. Top or blank means unmount and window rebuild need a look.

Related

  • Within the group: E4.08.1 A master-detail view keeps the list in context · E4.08.2 A narrow screen should degrade to two sequential pages
  • Adjacent: E4.18 Virtualized long lists · E5.07 Infinite scroll
  • Search terms: scroll restoration · back navigation · list position

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E4.08.3