This has been a cause of frustration for me on many sites like IRCTC, Online Banking sites which wont allow Back, forward or refresh. If you do you would be logged out and you have to login again. What I don't understand is what concern had there been in their mind to have such terrible "feature".
2 Answers
A common reason for this "feature" is that a site tries to keep some state of the current session on the server side.
That desire to track "conversation" state on the server side often comes from trying to write a Desktop-like "rich client" on the web (as opposed to embracing the web as the chaos it is). To be fair, this mostly happened in a time when the concept of a rich web application wasn't as well-understood as it is these days.
For example if a site provides a multi-page wizard and tracks where exactly you are and what answers you have given, then supporting back/forward in a sane manner becomes complicated (because some operations don't get communicated to the server at all).
This complication sometimes goes so far that sites outright ban forward/back. As you noted, that has obvious usability problems.
-
1It boils down to whether you can guess the user's intention when pressing forward/back. If you can't do so in all cases, then I can understand why some sites would elect to ban the use of such buttons. Of course, this could simply be down to poor design in the first case. Commented Jun 25, 2013 at 13:27
-
1@RobbieDee - Yes, it's poor design. You can understand how someone might get there, if they have never seen the web before, but at this point it's well known that every browser has forward/back buttons, and frequently a long history. Anyone designing a web site that is broken by a standard browser feature like forward/back has screwed up, and needs to start over, rather than trying to make it work anyway. Commented Jun 25, 2013 at 17:14
-
1I must confess to being firmly on the fence here. The nub of the problem (as Joachim points out) is desktop-like applications. We're trying to seamlessly mesh 2 different paradigms with mixed results. What should happen with the back/forward/refresh buttons isn't always clear. Consider also that web applications aren't always hosted in a desktop browser e.g. a kiosk. Your back/forward/refresh buttons will be whatever the interface says they are. It sounds like the History API may bring further order to the chaos. I don't know HTML 5 myself so I'll bow to Joachim's superior knowledge here... Commented Jun 25, 2013 at 18:57
Modern web applications (notably those written in MVC or similar) have no need for such navigation methods as the process flow is driven by the on-screen assets.
Much of the interface of modern browsers is however still very much geared towards Web 1.0 style web sites where the content is static and there isn't so much need for maintaining state.
Even knowing all the above is true, I agree that it is something of a pain to have such features taken away when they're now so natural to us.
I'd take a punt that future frameworks will have some way of hooking on-screen assets into browser back/forward/refresh buttons in a similar way to winforms apps where buttons could be assigned to the Enter and Escape keys.
An alternative could be for browsers to (somehow) detect the underlying framework and hide buttons not supported by the web application interface.
-
4Back/Forward is a fundamental navigation concept on the web. Any good web application framework should embrace it (instead of trying to prevent it). And they can (by using the History API, for example). Commented Jun 25, 2013 at 10:42
-
1That is true for regular browsing but web applications are different beasts. Of course, the user doesn't care about all this - they just want the browser buttons to behave as they'd expect. Commented Jun 25, 2013 at 10:49
-
3Web applications are "different beasts" only because they where designed that way. You can design a web application to embrace and support that navigation paradigm in a useful way. For example GMail just "does the right thing" when you press back: it cancels the last navigation in a meaningful way. It's just that many web applications are not designed/implemented that way. Commented Jun 25, 2013 at 11:06
-
1It rather depends on context as to what you find "useful". I have about 10 different GMail accounts for my wife's businesses. From the inbox I'd often like to go back to the sign-on screen to use another account. I press back and what happens? Nothing. It just stays in the current inbox. It doesn't do what I expect. This isn't wrong - it just isn't relevant to my context. I imagine 99% of the time, users would be happy with this behaviour. Commented Jun 25, 2013 at 12:38
-
1Similarly for banking. I press a button to transfer money, a drop down appears (some Ajax magic) and I select an account and then move on to the amount field. Half way thru pressing the amount I notice I've selected the wrong account. What would you expect the back button to do here? Commented Jun 25, 2013 at 12:39