What does ‘Back’ really mean?

Website owners spend a lot of time and effort debating and designing navigation menus for their sites, but for users, the most frequently used navigation aid is likely to be their browser’s ‘Back’ button. Consistently placed, and almost always available, it can be trusted to return them to their previous page whenever they suspect they are heading the wrong way.

At least, that was how things used to be. In modern web apps, there is often no concept of a ‘previous page’, but instead a series of previous ‘states’ in which individual widgets have been updated without ever reloading the entire view. The technology behind this is commonly referred to as ‘AJAX’, and has transformed users’ experience of the web in recent years, adding finer grained interactivity to the old request/response/reload model.

But it has also introduced a new challenge for developers, since by default ‘Back’ will no longer magically just ‘work’ as it used to. Instead, its default action of taking users to the last full page they loaded is likely to return them to Google, just before they clicked through to your shiny new AJAX-y site. For developers, the main issue with ‘Back’ has therefore now changed from ‘how can we disable it?’ (as is commonly seen in online banking and e-Commerce checkouts), to ‘how do we make it work as wanted?’.

And this can be tricky, as how users expect ‘Back’ to behave is not always clear cut. As a starting point we could say, ‘Back’ should return users to their previous ‘state’, rather than the last full page they loaded. OK – but what if they just added an item to their shopping basket. Should going back ‘undo’ that action, and return them to the ‘state’ of having an empty basket? Very likely not. Or if that one’s debatable, how about going back after clicking ‘Logout’? Should that restore the ‘state’ of being logged in? Definitely not! (think Internet cafe).

In addition, there’s also the question of what constitutes an application ‘state’, since it’s not always desirable to retrace your steps over every individual change to a page. For example, hiding and showing text on an article page or expanding sections of a dynamic menu is probably not ‘Back’ significant. Similarly, on dragging and dropping a series of items, the user might expect the page to return to its original ‘reset’ state on clicking ‘Back’, rather than replacing them one by one in reverse order. Or in some cases, maybe the opposite…

Over time, more conventions defining best practice for all this will probably emerge, but it’s likely there will always be an element of what ‘feels right’ within a specific context, which will inevitably leave grey areas. So, next time the ‘Back’ button behaves unexpectedly, remember that going ‘Back’ can mean different things to different people, and it’s not always as simple as it seems!