Alex has been working with the Back button in Ajax applications as part of the Dojo toolkit. Thinking about this, in an Ajax application, I think that Back and Forward map to Undo and Redo. Sort of. What I’m trying to decide is, if you could implement Undo on the Back button and Redo on the Forward, would this actually be a good idea? Does that break the semantic of what those buttons mean? I don’t think that it does, because “do an action” means, in a web browser, “click a link“, pretty much. (Or possibly “drag something“, but in general it’s “click something“.) People are used, on the web, to thinking “click on this…and the Back button takes me back to where I was before I clicked it“. So, clicking something in an Ajax app, which doesn’t actually navigate to a new page but instead just does something, would be “undone” by clicking Back, because the semantic is “the Back button takes me back to where I was before I clicked that last thing“.
This will likely annoy serious web developers, because they know that Back doesn’t mean “return to the state before the last click“, it means “go back to the previous page” (modulo frame-ish things). But that’s because an Ajax application isn’t like the web-as-was; “Back” and “Forward” don’t make that much sense when the page metaphor is broken anyway.
Note that I’m not talking about implementation detail here; Alex’s method seems to be the approach. But essentially what Ajax apps could do is provide an “undo stack” in the same way as client apps do; the implementation of making the back/forward buttons trigger this is then simply a call to one of Alex’s iframes when you move back or forward in the stack, and every action needs to write itself into the undo stack so that it can be undone.
This is rather rambly. I need to work up a demo to explain what I mean, perhaps.
So I totally agree about the back button being undo for the web. The approach that we’re using in Dojo for mapping the back button to request states is going to be the building block for a more complete undo framework for Dojo apps. It’s difficult, though, to tie everything to a data request, and not necessarialy useful in non-HTML environments (which Dojo does worry about), so dealing explicitly with back and forward buttons in bind() seemed the way to go.
I’d like to know if you dissagree = )
Posted by Alex Russell on March 12th, 2005.
I think that I’m not necessarily thinking that everything should be tied to a data request. The point is, when you do any undoable action at all, you do one of your iframe request things, which adds it to the undo stack. So every action gets a data request, even if it didn’t need one, but that makes that action undoable. I think. Like I say, I need to do an example :)
Posted by sil on March 12th, 2005.
It’s a good idea, but I don’t think it would be good UI for most users. While expert users would understand the metaphor, I think the majority of people would be confused as to why a web page was suddenly hooking into browser chrome (but obviously no in those terms). I’d still like to see a demo though. A nice little hook API for the the back/forward buttons would be good.
Posted by Gary Fleming on March 12th, 2005.
Gary: I don’t think I agree. Looking at my users at work, what they’ve learned is that the Back button basically means to back out of what they’ve gone, to go backwards in time if they’re confused and go back to somewhere that they understood. That’s what undo is, I reckon…
Posted by sil on March 12th, 2005.
Why do a request for each stack addition rather than storing the data on the client side? unless you want to be able to comeback and reload it in which case you could save the stack every 30seconds or something. just a thought
Posted by Derek on April 4th, 2005.
Derek: because the Back button tracks requests.
Posted by sil on April 4th, 2005.
I believe that a radical and easier solution would be to conditionally disable “Back” and “Forward” buttons of Web browser. I may tell me that that brakes a principle of web page browsing, but I think that AJAX application is an example of what calls a “web application” rather than a “web page” http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke.
See also a more in-detail review at http://pro-thoughts.blogspot.com/2006/01/dynamic-web-applications-and-disabling.html
Posted by Vladimir Kelman on January 8th, 2006.
Good Article. I want to know more about AJAX.
Posted by Malcom on January 17th, 2006.
Good Article. Keep it up. I want to know more about AJAX.
Posted by Malcom on January 17th, 2006.
Hello there
I can say that I create the simpliest function that enable the Back and Foward browser buttons.
http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke
This here is good, but is using around 300 lines or more of code. My one is just 4!!
You will be able to see it in few days when i upload my new website.
Posted by Georgi on March 6th, 2006.
Hi Georgi,
Where is your script? Can you put script there?
Posted by Andrew on July 25th, 2006.
when clicked on browser back, i need to overwrite history url with my url.. is this possible…
any javascript on the same is highly appreciated…
Posted by Anonymous on September 5th, 2006.
hi, i found a full ajax website, and the back button works : http://itbreaks.net
Posted by riper on June 16th, 2007.
whatever
Posted by gamer on August 14th, 2008.
whatever
Posted by gamer23 on August 14th, 2008.
This problem can be mitigated to an extent by using collapsable and closable div tags. Like when I click something, a DIV area opens up, the DIV has a toolbar and ways to enter content into it. It can be collapsed and closed. Like Gmail’s chat. Now user’s don’t expect browser back button to work with this. It’s like a subform. So when you click back, the form should go back! and along with it, all the subforms.
Posted by shyam on January 21st, 2009.