> By that argument, GUI apps should not ever disable menu > options that are not relevant to the current state of > the computation either -- instead, they should just > leave the option enabled and "deal with it" when the user > selects it. :-)
I don't think that's a fair comparison, because GUI apps have control over their interface. Web apps do not have control over their interface. If there was a standard way to tell all browsers to "disable the back button on this page" then I'd say yeah, go for it. But the nature of the web is that you do _not_ have control over the interface, and your app needs to respond to whatever the user does, rather than control what they do. > > The fact is that it is HARD to design an app for the > > web and implement it so that it works well > > in a browser. > Not only is it hard, its nearly impossible. Why do you say this? Can you give examples of situations where a web app cannot behave in an appropriate way when a user chooses to use the back button? Every situation I can think of can be handled. In some cases, maybe the best handling is to simply tell the user "you can't submit this page again, we're now going to take you back to the beginning. to avoid this, don't use the back button." But that's severe, IMO. Last resort. > Non-trivial interactive applications (I'm not taking about > adding a comment to a guest book; I'm talking about adding > an order to a database) have the same kinds of ordering > and transactional restrictions, whether you implement them > in a client-server GUI in your favorite language, or as a > webapp. It's a different beast. Even in processing an order, when the user must go down a path one step at a time, why can't the application handle the back button? What specific cases are there were using the back button just totally screws everything up in such a way that the web app could not handle it logically? Matt
