G4.01.1back versus updesignresearch

Back to the previous page is not the same as up to the parent level

Aliases: previous page vs parent · up versus back · history back · hierarchical up

What it is

Back pops the frame just visited. Its object is the top of the history stack. Up walks to the parent on the classification or task tree. Its object is level, independent of how the user arrived. Both are often drawn as a left chevron, but the destinations coincide only when the user happened to enter from that parent. Android kept system Back on the back stack separate from toolbar Up for this reason: recency and hierarchy are different axes. Browsers ship Back and no native Up. A product that rebinds Back to Up rewrites a revocation model users already know.

This leaf only splits the two meanings. It does not ask who sits on the stack after an off-site arrival, and it does not ask whether scroll and filters survive the pop.

Why it happens

People treat Back as stepwise undo: the last forward move is taken back, together with the context that move created (a result list, a filtered view, another article half-read). Up is one step toward the root on a shared map: the parent is the same whether the entry was search, a notification, or a related-item rail. Bind Back to the parent and the undo grain disappears; the search-result frame is discarded and the system appears to have sent the user somewhere they never were. Implement Up as Back and the ancestor trail becomes path-dependent: the “parent” of the same product page mutates into search, home, or an ad landing, and the map stops being shared.

SPA routing makes it easy to weld both meanings onto a single history.back(). If the router replaces instead of pushes, the parent frame is never on the stack and Up has to be synthesized. If every departure is pushed, Back walks through hierarchical jumps that were never meant to be undone. Chrome does not decide the semantics: system gestures, the browser button, and an in-page “Back” must each declare which stack they pop.

Studying it

The classic probe is an up-versus-back task: the same detail screen is entered twice (from its parent / from search); participants tap system Back and tap Up; destinations are scored against prior expectation.

  • Paradigms: revisitation logs in the Cockburn–Tauscher–Greenberg line show Back as the dominant temporal navigation; the lab then dissociates the hierarchical control from system Back.
  • Independent variables: entry path (in-tree / out-of-tree), whether the visible control binds history or parent, whether the label says “Back” or names the parent.
  • Dependent variables: destination–expectation agreement, which control is used after an error, how often the two taps are described as the same action.
  • Methodological note: entering only from the parent makes the two semantics spuriously coincide and yields the false conclusion that one button suffices. At least one non-tree entry is required. A high Back rate in logs does not license deleting Up—it measures how often temporal undo is used, not whether hierarchical jumps have a separate demand.

Where it stops holding

Linear flows (wizards, checkout) have a previous step, not a parent; forging an Up target skips steps. Feeds, chats, and canvases with no stable tree give Up no legal destination; keep Back only. An embedded WebView with no history of its own may have the system Back close the container; the page then needs an explicit temporal return and cannot pretend Up will do. Closing a desktop window is neither Back nor Up.

Applying it

  • System Back, browser Back, and edge swipe always pop the history stack. Reach the parent with breadcrumbs, toolbar Up, or a link that names the parent—do not retarget system Back.
  • When both controls exist, split the copy: “Back” for the previous page, the parent’s name for Up. Do not draw two unlabeled chevrons.
  • In an SPA, Up is an explicit navigation to the parent route; Back is a real history.back(). Do not replace the parent frame away and still show a back chevron.
  • Verify: enter the same detail from a category and from search. System Back must land on the category and on search respectively; Up must land on the same parent both times. Any cross-wiring means the semantics were fused.

Related

  • Within the group: G4.01.2 Arrival from another source leaves Back's destination undefined · G4.01.3 Back should restore the page as it was left
  • Adjacent: E5.05 Breadcrumbs · G2.05 Location indication · G4.06 Task chains and recovery
  • Search terms: back versus up · history stack · back stack

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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