13

QA have found the following bug in our web application:

  1. Go to a list of sprockets
  2. Create a new sprocket
  3. Click the back button

Result: The list of sprockets shown does not include the sprocket that was just created.

The reason is that the browser is caching the version of the page from before the sprocket was shown - intuitively this feels like bad usability, the solution being to defeat the browser cache to make sure that the page always shows the current state, but I'm hesitant to override default browser behaviour.

Should web applications override the browser back button cache to ensure that stale state is not shown to the user?

Improve this question
2
  • 4
    Using a short cache lifetime isn't "overriding default behavior", it's correctly informing the browser that the information being shown is likely to change frequently and needs to be rechecked.
    – chrylis -cautiouslyoptimistic-
    Jan 18, 2016 at 18:16
  • Use eTags and Cache-Control: must-revalidate
    – Neil McGuigan
    Feb 11, 2016 at 1:22

2 Answers 2

Reset to default
18

From an UX perspective there's no doubt that you should always show the user the current state of the system, otherwise users could think that their action was not really performed / recorded which can only derive in bad things. (users untrusting the system, getting mad, redoing actions then to discover they have duplicated data and have lost their time, etc).

The only reason not to do it would be if the consequences of technical changes for this could only derive in a bigger UX issue (which is likely not the case).

btw, is it really necessary to override browser behavior? Won't be enough with a "flag" and some javascript code to check if the loaded version is the last one and if not trigger reload?
Related: How to refresh page on back button click?

The onload event should be fired when the user hits the back button.
Elements not created via JavaScript will retain their values.

Improve this answer
1
  • 4
    No JavaScript magic is necessary, just make the page expire immediately.
    – elaforma
    Jan 18, 2016 at 17:54
4

The issue that you are facing is primarily caused by the fact that your QA team is expecting single-page application (SPA) behavior out of (what sounds like) a multi-page application (MPA) design.

You are right to question altering the behavior of the back button because users have been taught to expect that if the page reloads as they "move forward" through an MPA, that and page that they have gone through is "in the past". And there are many MAJOR websites out there that behave just this way.

Now you can change that behavior and (1 - depending on the design of your overall site, and 2 - assuming that you address all of the potential issues involved with altering standard browser behavior), it might not be a drastic impact on user expectations, but, assuming that I am correct about the MPA design, you will be going against the standard MPA pattern/experience.

Some alternate options include:

  1. Automatically take the user (forward) to an updated view of the previous page as a part of the confirmation that the new sprocket has been added. This allows them to see that it was properly added and reduces the likelihood that they will want to go back to the old version.

  2. Consider updating your application to an SPA design, if you find that your requirement are beginning to push you that way. While this is likely a BIG undertaking to overhaul your application design, you are MUCH better off doing a redesign than trying to retrofit SPA behaviors into an MPA design.

Improve this answer
8
  • 2
    @JAB - totally agree . . . really, it's not a technical issue, more of a question of UX impact. It boils down to the fact that browsers are MPA oriented by default, so unless you design your page early from an SPA point of view, you are going to be fighting the native MPA nature of your original design, as you try to implement features like this. That fight will, generally take a toll on one or more of: interface behavior, bandwidth, technical page weight, maintenance, conflicts with future browser releases, etc. . . . all of which can impact the user experience.
    – talemyn
    Jan 18, 2016 at 17:17
  • 2
    I disagree about the example going against standard MPA pattern/experience - I mean, assumping an MPA design, if the first step of the OP is "Go to a list of sprockets" then this means that the app has an explicit page for "a list of sprockets". This page should always show a correct and up-to-date list of sprockets for that user - no matter if you get there in the "default workflow", using the back button, with a bookmarked or emailed URL, or by crafting/guessing the URL. If you press 'back', you go back to the exact same page/URL but with changed content that reflects the changed reality.
    – Peteris
    Jan 18, 2016 at 19:11
  • 2
    @talemyn Your opinion would seem to be shared. madhatted.com/2013/6/16/you-do-not-understand-browser-history "In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. [...] If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents."
    – JAB
    Jan 20, 2016 at 21:45
  • 3
    Woops, original source: w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 But there's some hope: "This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale." So don't update the sprocket list immediately, but do indicate the list may be outdated (which could be done by indication on update, or just by a small Ajax query that checks if the sprocket data has changed and then, if requested by the user, uses another one to fetch the (potentially large) updated list/changes if the current sprocket list has a unique ID).
    – JAB
    Jan 20, 2016 at 21:46
  • 1
    I think a "This data is old" kind of a message, perhaps with disabling controls on the data, serves this purpose well. What if the user had a legitimate reason to view the old cached page? When adding a single item to the DB, part of that experience present the user with a refreshed view of the main list... which is yet another entry in browser history. Someone who's pressing back a few steps in history must have a good reason for doing so, and I think that most web users understand this could be a problem.
    – Kalnode
    Mar 9, 2018 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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