It may be true that the "back" button might evoke a different behaviour than expected by the user in the traditional sense. But the issue ends there, and I don't think that the developer/end user is too worried in the current world about this, as long as the application provides their own reliable links / buttons in their pages for these functions.
Browsers assume that one URL refers to one resource/document on the web. This definition has been debated for quite some time now. I am one of the satisfied users (with millions of others, I suppose) of GMail, and I know that "back" button will screw up my mail session. AJAX, and our good old DHTML too have had perennial problems fighting with browser's back buttons, and finally with the acceptance of GMail, users and application developers have agreed to application-specific back/forward URLs.
Rather than tagging design patterns like AJAX or this one as cases of "failed to handle the back button," it would be appropriate to state that the "back" button that the browsers implement fail to understand and deliver innovative techniques as AJAX and this one.
In short, the definition of "back" in the traditional WWW sense is changing. At least for now, I think developers and end users would choose to have their own custom "BACK" buttons in their pages, instead of presuming browser implementations. |
java.net RSS Feeds
