I’ve encountered some that will send you back to either the login page or the landing page where you started out after logging in. Often, this also means that any data in whatever multi-step process you were involved in, when you were naughty and used your own browser’s back button, gets thrown away.

Sometimes, the very reason I clicked my back button is because their multi-step process didn’t provide adequate means to go back and correct something on a previous step.

I’ve dealt with more than my fair share of back button issues in a few of the web applications I’ve worked on, over the years. I know how hard it can be to balance session state management with the possibility of users opening multiple browser windows sharing the same session, and things like that.

In at least one of these webapps, we ended up changing all the ‘Back’ buttons that we provided on the web pages into ‘javascript:history.go(-1)’ links, because then we only had to worry about one type of backward navigation, and we would not have to worry about browser back buttons screwing things up.

Also, if a user clicks a browser back button (or menu, etc.) such that a dropdown list of the recently navigated pages appears, they could go back (for example) 3 pages at a time, so we had to also code things so the app wouldn’t choke on this sort of navigation.

Of course, no single navigation mechanism is ideal for all webapps, as different app servers / programming languages / frameworks / 3rd-party APIs, etc. all have their own constraints and idiosyncrasies. It also depends on what type of data is being manipulated by users, whether multiple users can edit the same pieces of data, etc.

My point is that if a webapp is going to restrict users to only using the navigation controls provided on the web pages, then they need to *always* provide navigation controls on *every* page.

I do kinda like your thinking though, about how if other sites suck, then mine will look better. :)