When going back to previous page may cause disorder

Question

Let's suppose a page listing items whose URL would be: /items.
Its content is loaded through Ajax at the page's initialization time, thus not directly populated on server initially.

Each item contains a link "view detail", rendering the detail page for the concerned item.
URL of detail page would be: /items/:id.

When the user goes back to the list of items by clicking the browser's back button, the list get automatically refreshed since the Ajax call is always made when routes is /items.

Should I prevent the Ajax call each time the user comes back to the list to improve the user experience? Indeed, it would be boring to wait for the refreshment, especially if current viewed item disappears or is masked by new ones. I would think of a refreshment on demand..

What would be a good practice?

Answer 1

This depends totally on your context. How important is it to the user that the list is always current? How long does a refresh take?

Extreme case 1: Totally important. For example, you are listing stocks available for purchase, with prices. Then you have to display current information, period.

Extreme case 2: Unimportant or even undesirable. Imagine a company which promises that any orders posted until 11 AM will be processed the same day. You have a worker who refreshes the list of orders at 11 AM and starts working on them. If the list was kept current every time he goes back to it, the list filling with newer orders will be somewhat impractical, assuming he has to process all of the old ones before he needs to pay any attention to the new ones.

Most cases will probably fall somewhere between the two extremes, but barring unusual circumstances (which can probably be solved better than with a non-refreshing list, like my example above), users will have a preference for current lists.

As users also have a preference for promptly responding systems, there is a trade-off between how much freshness and promptness the users get. But there is no general rule that users always prefer one over the other. Microeconomics offers a very elegant analysis of this type of problem with indifference curve analysis.

I'll skip the explanation of the microeconomic model and come to the conclusion: Your perfect solution would be to try to find a technical solution which will offer more of both things users want. Maybe you could implement some kind of smart caching which asks the server if there were changes to the list (quick roundtrip) and only refreshes (slow roundtrip) if there were changes, else shows the old list (instant response)?

If you can't come up with a technical solution, the ideal point on the freshness vs promptness curve is determined by the shape of the users' preferences, which is dependent on the context, as described above. It is only you, who is in the middle of the project, who can know or find out which one they value more. If you cannot predict their preference by reasoning, you will have to find out their preference by live user testing.

For live testing, you can either invite users to use the system in front of you and observe their reactions, plus ask them for feedback. Or, if you have a live system already, do an A/B test and collect relevant usage metrics for a variation with a current but slow list vs a variation with an old but quick list. The first is better for explorative analysis, as you frequently learn things you didn't expect. But it is costly and delivers very few data points. The second option is cheaper, and can be used well to confirm an existing hypothesis due to the large numbers, but won't give you any further insights beyond what you thought to measure.

Finally, there are some empirically confirmed numbers for annoyance threshold. This Nielsen article is probably the classic one. If you think that your loading times fall below some bad threshold (and you will have to be the one to decide which threshold you are willing to live with in your application), you can just decide to give up the whole costly optimization.

Answer 2

The important thing is that the back button do what is expected. Of course it's not always easy to figure out what is expected, but if clicking on a link changes the URL, the back button should revert the URL to what is was before the like click, and (ideally) the state of the page should also be reverted. Ask yourself "what would old fashion static HTML do?" - that fact that AJAX is used shouldn't matter, if possible it should "act" like it's good old static HTML with regards to history/back/forward button. Sometimes this isn't possible, the behavior of a dynamic page can't be mapped onto the old synchronous paradigm, but it often can.