Saturday, October 29, 2005
Freeze!
Over on Randomize there is a great idea on how to bake in native history support in browsers for AJAX apps:
"I was just reading some documentation for a framework designed to make it possible to add "back-button compatability" to AJAX applications and was struck by the complexity required.
Instead, I'd like to see browser support for a new method. Immediately before executing a DHTML action that might be considered analogous to "navigation," a web app could call the method (if supported). This would create a clone of the current document as it exists and "freeze" it in the browser history, making the old version available in the Back/Forward button queue. A "restore point," if you will--not in terms of a true undo/redo, but at least a bread-crumb trail back to previous "screens."
This would be ridiculously easy to implement, would degrade gracefully (test for support, older browsers just don't get the history navigation capability), and would go a long way toward improving usability of sites with heavy in-page interactivity.
Going further, users of tabbed browsers should be able to do the same thing ad-hoc. Currently, if a user opens a hyperlink in a new tab and the href is a JavaScript action, they get a blank page. A better response would be for the browser to clone the DOM to a new tab and execute the action on the cloned tab (but not on the source tab). This would, for instance, allow a GMail user to open a message in a new tab just as they would with a non-AJAX application."
The blog poster has some good ideas on how to reduce the complexity in my original proposal for native browser DHTML history support, which I agree is too complex.
"I was just reading some documentation for a framework designed to make it possible to add "back-button compatability" to AJAX applications and was struck by the complexity required.
Instead, I'd like to see browser support for a new method. Immediately before executing a DHTML action that might be considered analogous to "navigation," a web app could call the method (if supported). This would create a clone of the current document as it exists and "freeze" it in the browser history, making the old version available in the Back/Forward button queue. A "restore point," if you will--not in terms of a true undo/redo, but at least a bread-crumb trail back to previous "screens."
This would be ridiculously easy to implement, would degrade gracefully (test for support, older browsers just don't get the history navigation capability), and would go a long way toward improving usability of sites with heavy in-page interactivity.
Going further, users of tabbed browsers should be able to do the same thing ad-hoc. Currently, if a user opens a hyperlink in a new tab and the href is a JavaScript action, they get a blank page. A better response would be for the browser to clone the DOM to a new tab and execute the action on the cloned tab (but not on the source tab). This would, for instance, allow a GMail user to open a message in a new tab just as they would with a non-AJAX application."
The blog poster has some good ideas on how to reduce the complexity in my original proposal for native browser DHTML history support, which I agree is too complex.
Subscribe to Posts [Atom]
