User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 Jan 18 at 18:16
    
Use eTags and Cache-Control: must-revalidate – Neil McGuigan Feb 11 at 1:22
up vote 17 down vote accepted

From an UX perspective there's not doubt that you should always show the user the current state of the system, if not, 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 behaviour? 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.

share|improve this answer
4  
No JavaScript magic is necessary, just make the page expire immediately. – fNek Jan 18 at 17:54

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.

share|improve this answer
    
They could go for a compromise and use Ajax to query the dynamic components of the page (current list of sprockets, etc.), much as Stack Overflow does for inbox messages and the like despite being a multi-page site, assuming the current behavior is that the pages are generated server-side. That may add a bit more overhead, however, if QA is strict on bandwidth usage. (Though it could also potentially reduce server load to some degree.) – JAB Jan 18 at 16:27
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 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 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 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 at 21:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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