E5.09.3scroll-top is not backdesign

Returning to the top is not going Back

Aliases: scroll versus history · up is ambiguous

What it is

Back to top changes viewport position inside this page; Back changes which page sits on the history stack. Scroll-top is not Back splits those two exits: one stays on the page and only goes to its start; the other leaves the page for the previous frame. When both icons are an upward arrow, the paths get tapped interchangeably, and “I want to leave” is executed as “I am still on this page, at the beginning”.

Why it happens

“Up” in space looks both like rolling toward the page start and like returning the way one came. Deep in a page, with the top bar hidden and a system back gesture unreliable, people grab the nearest upward control. If that control only sets scrollTop, the stack does not move; they see a familiar page start, think they have come back, and tap again — still on this page. After two failures they go looking for real Back. Conversely, if the product makes the upward arrow mean Back, someone who only wanted the title or the filters is popped off the page, and reading position plus uncommitted filters die together.

Confusion is heavier on mobile: an edge swipe, top-bar Back, and a floating up-arrow may all exist, without separating “origin inside the page” from “previous frame on the stack”. Desktop browsers already have system Back plus an in-page button; similar copy or placement sends a miss off the site.

Where it stops holding

When a single-page app implements “Back” as scroll-to-previous-anchor, the semantics were already in-page; back-to-top and Back may then be different distances of in-page jump, and copy must split them (“to the top” versus “previous item”). In an embedded WebView with no browser Back, in-page up is more easily taken as the only exit, and an arrow alone is even less enough. A reader’s “previous chapter” is also an up metaphor and collides with page start. On a short page, showing Back and to-top together almost guarantees a miss — a short page should not have to-top.

Applying it

  • Label the to-top control “Top” or “To the top”, not an unexplained up-arrow. Keep Back on the system or top-bar slot and semantics.
  • Do not put to-top in the top-leading Back slot, and do not share one icon family between top-bar Back and the floating arrow.
  • Activating to-top must not call history back; activating Back must not only change scroll.
  • How to check: from mid-page, ask for “leave this page” and “go to the start of this page”. The two should hit different controls and land differently. Mask icons and copy and try again; if the two paths are still treated as one event, the spatial metaphor is mixed.

Related

  • Within the group: E5.09.1 Long pages need a fast path back to the top · E5.09.2 The control must not cover content or primary actions
  • Adjacent: E5.01 Top App Bars · E5.05 Breadcrumbs
  • Search terms: back to top · history back · scroll versus navigation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E5.09.3