3

Our company is building an SPA and we're having a discussion about the best behavior for the browser back button. The SPA is a management tool with a lot of tables and filters. Every time a filter is changed the URL parameters are updated to reflect the current state.

There are two sides to the argument of what the back button should do:

  • One side thinks the back button should switch states. So every time a filter changes it should push the new state in the browser history.
  • The other side thinks the back button should switch pages. So filter changes should be ignored and the browser should return to the previous page/view.

Both options have their pro's and cons. Is there a common view on what the back button should do?

3

Test with your prospective users.

As you suggest, both sides have pros and cons but the best way to settle the matter is to get a bunch of users to test a prototype.

Taking control of the browser's back button can be very productive in situations where the user's view changes to the point where they feel like they are on a new page.

I would suggest performing the test from two different angles: 1) interview users while showing them the prototype and ask them if there are any situations when they might use the back button and what they expect to happen when they do. 2) build prototypes that work either way and see how users react when completing a task that implies the use of the back button.

You will probably find that the answer is a complex combination of both solutions depending on the context.

| improve this answer | |
  • I agree with you about testing both options. Still I was wondering if there is any logical reasoning or common opinion about how the back button should behave for single page applications. – generator Aug 28 '19 at 9:42
  • As I said in my answer, the problem with SPAs is that not every action or transition will feel to the user like a new page has been loaded. Without knowing your particular app, I couldn't possibly say what the behaviour of the back button should be at any given time. – Andrew Martin Aug 29 '19 at 15:19
0

Neither.

Provide your user with determinable action controls, that is, appropriate controls to remove filters that have been added and a navigation control to allow the user to go to the pages and locations they need to use your application.

Leave the browser back-button alone:

Breaking or Slowing Down the Back Button

The Back button is the lifeline of the web user and the second-most-used navigation feature (after following hypertext links). Users happily know that they can try anything on the web and always be saved by a click or two on Back to return them to familiar territory.

Except, of course, for those sites that break Back by committing one of these design sins:

•opening a new browser window (see mistake #2)

•using an immediate redirect: every time the user clicks Back, the browser returns to a page that bounces the user forward to the undesired location

•prevents caching such that the Back navigation requires a fresh trip to the server; all hypertext navigation should be sub-second and this goes double for backtracking

(source https://www.nngroup.com/articles/the-top-ten-web-design-mistakes-of-1999/)

| improve this answer | |
  • 2
    That article is 20 years old and doesn't take into account how modern single page applications are built. The trick is to make the back button do what the user expects it to do and sometimes that involves taking control of it to return your SAP to an earlier state rather than taking it to the previous web page. – Andrew Martin Aug 27 '19 at 15:01
  • 1
    Newer single page applications often give the user the sensation of moving through pages. If, for whatever reason, they decide they need to move backwards, their instinct would be to hit the back button. Taking control of the back button at that point would give the user exactly what they are expecting. On the other hand, if the back button is not under the control of the site, the user will be booted out of the application and back to square one of whatever task they are trying to achieve - Not very user friendly. – Andrew Martin Aug 27 '19 at 15:07
  • 1
    They would know what they are expecting by testing their hypotheses with their target users. The back button is always going to have priority over any controls you add because (as you pointed out) it's cross-platform and cross-device; it's the one stable element in their navigation arsenal and you need to make sure it behaves the way they expect it to when they use it. Testing with users would tell the OP what to change in the next iteration to make the controls more user friendly. – Andrew Martin Aug 28 '19 at 8:33
  • 2
    I agree with Andrew, there are actually very good reasons to 'mess' with the back button. The average users will not see the difference between navigating through pages in an SPA or a regular website. So it's our task as developers to make sure the back button behaves in the same way as any other regular website. – generator Aug 28 '19 at 9:35
  • 1
    @DarrylGodden I keep saying the same thing because you don't seem to understand that users won't see a difference between page style transitions in a SPA and actual page transitions but will still use the back button to move through those transitions. I'm not sure what more logic you need to convince you that talking to users and finding out how to make products that behave the way they expect is what UX is about. – Andrew Martin Aug 29 '19 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.