Best practice: How to handle concurrency of browser and website navigation.

Question

It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).

Lets assume the following:

The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.

We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.

When you change the "struts-flow" - which may result in using a different form - this information will be lost.

If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!

My "solution":

I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.

At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.

And thats it. When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).

This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.

Resumé: It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).

So, what were your solutions to this problem?

cheers,

mana

Answer 1

The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.

I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.

If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.

Answer 2

This is an legacy system, which runs for about 3 years now.

I need a personal state for each user beacause we use a tabletag where information like "on which page was the user" and "how was the table sorted" ... will be lost, if we just have a static back-url.

This is definately not that easy.