A Back button that does not add a page

The back office is a single page that rewrites itself as you move about: open a report from the dashboard, open a dish from the menu, open the recipe from the dish. The browser’s own back arrow always worked, but on a tablet it is a long reach and on a phone it is a gesture people do not trust. The tester’s row was plain: a Back on every page reached from inside the app.

The obvious way to build that is to draw a link to the page you came from. It is also wrong, and the reason is worth a paragraph. A link is a new entry in the browser’s history. Open the menu, open a dish, tap the drawn Back, and you are on the menu again, but your history now reads dashboard, menu, dish, menu. Tap the browser’s arrow and you go to the dish you just left. Do it three times and the browser button has to unwind a staircase you built by trying to go backwards.

A step, not a link

So the page head’s Back is a step back through history rather than a new page. When the app moves you somewhere from inside itself, it writes down where you came from on the history entry it creates. The page head reads that and draws a Back only when there is something to go back to. Tapping it asks the browser to go back one step, exactly as its own arrow would, so the two never disagree and the stack never grows.

A page opened cold, from a bookmark or a link somebody sent, shows no Back at all, because there is nothing behind it inside the app and a Back that jumps to the dashboard would be a lie about where you were. That matches the rule we use everywhere: an X closes a sheet, a left arrow goes back one screen, and a control that cannot do what it says is not drawn.

The test for this is a browser one rather than a reading one. Reach the recipes screen from the menu hub, confirm the Back is drawn, tap it, confirm you are on the hub and that the history is one entry shorter rather than one longer. A navigation bug is the kind a green test suite has no opinion about unless something actually navigates.