Posts [ 8 ]

Topic: Controlling the browser's "Back" button

I am not sure if this is the right forum to ask - but I'll try. With the way I have designed my webpages, it causes problems when the user presses on the browser's back button. I am new to web-design, so it's possible my design is simply not "correct". However, the page works well and is user-friendly except if the back button is pressed.

So my question is if there is a way to either prevent the user from going back (not ideal) or get some sort of notification when it happens? The way I would deal with it would then be to reload the page, I think.

Or does it sound like I need to rethink my design? Does the user generally expect a full and complete "undo" of everything when going back to the previous page? That can be pretty hard to implement.

Re: Controlling the browser's "Back" button

What breaks specifically? The user shouldn't expect an "undo" when going back - I don't know any web app that does this. I think it's most important that it works with general browsing and not while submitting forms. Usually browsers give a dialog when attempting to go back while submitting the form.

Re: Controlling the browser's "Back" button

Well, nothing really breaks in the sense that there are no errors when the user goes back. But the previous page will show content that's no longer "in sync" with the data in the database. If the user is unaware of that, he might click on something and expect something to happen in the context of what it looks like to him. But the thing that really happens will be in the context of the state of the data on the server.

Hmm.. hard to explain in general terms. I will try to be more specific. The page implements an "advanced" interface for searching/filtering. However, I am trying to implement this in a different way than the usual forms and input fields because I think that non-tech users are a bit scared of those. Instead the idea is to use Javascript to allow clicking on icons that implement a descriptive search conditions. These elements can then be further customized/edited using Javascript if needed. I haven't completely decided wether to use Ajax to fetch data when the user selects these condition elements or if I will simply reload the page.

In addition, I am also trying to get away from storing the search specification in the URL. Instead, the search spec is stored in the database (referenced by a key in the session). One advantage of this is that search specs can be named and saved so that the user can later return to them easily.

Long explanation sorry. So to the point. If the user has made a search as explained above and then presses back, he will now on the page see a different version of the search than the one saved in the database. He may then try to edit that one - perhaps thinking he just undid his changes. I am simply not quite sure how to handle this confusing situation.

Maybe I am trying to do something that browsers simply aren't good for. I'm not sure but I start getting that feeling.

Re: Controlling the browser's "Back" button

I think something you need to be equally concerned about is the dual-window/tab browsing. If someone has two windows open on the site, he is unable to do a search in both windows because the search key is stored in the session.

Nothing's wrong with storing the search query in the database, but I recommend storing the search key in the URL instead of the session - this way the user can have multiple windows open without a problem. This might solve some of the back-button problem as well.

Re: Controlling the browser's "Back" button

I like simple and pretty URLs. But I guess a single query parameter is acceptable.

However, to implement your suggestion wouldn't I then need a new key (and new database entry) for each change made by the user? Otherwise he could still have two versions of the same search spec on his screen at the same time. It would of course give the extra advantage of full undo/redo support. But the database could grow large fast.

Re: Controlling the browser's "Back" button

Velschow wrote:

However, to implement your suggestion wouldn't I then need a new key (and new database entry) for each change made by the user? Otherwise he could still have two versions of the same search spec on his screen at the same time. It would of course give the extra advantage of full undo/redo support. But the database could grow large fast.

Yeah, I guess it would. In that case I recommend having a cleanup script to regularly remove the old searches that haven't been accessed recently. If someone has a better solution though, I'd love to hear it as I can imagine this is a common problem regarding storing searches in the database.

Re: Controlling the browser's "Back" button

I was also thinking that this must be a common problem really. But that also just got me thinking about what happens when using forms the usual way. There are fewer problems with those. I assume that's because all of the search spec is basically re-submitted to the server everytime. Thus, if the user goes back to a previous version, edit and submit, the result will effectively be replacing the entire search spec with the new one. That's not really a problem, though, since he gets exactly what he sees on the screen.

I think I need to draw a lesson from that. I need a way of sending the entire search spec back to the server as it is displayed on the user's current page. Just need to figure out how....

Thanks for your time. I need to go back to the drawing board a bit it seems.