I had already some discussion about the back button problem with AJAX related applications. In some scenarios we need this behavior, not for every action. But what we should seperate: the back button is not an undo button. I'm not sure if it is possible to create such a undo function. If it is possible the page must call a method on the server to undo all the actions, ... hm, very difficult.
The browser back button is just that - going back, to a previous resource. Think about in the context of wizards, Back/Next are the navigation, AJAX is the current resource interactivity tool. Of course there are going to be people who abuse AJAX, just like there are web sites that abuse Flash and put their whole site into a Flash content - resulting in the same navigation issues.
The Back button is purely navigational. If your AJAX application transitions between views by actually changing pages (Postback, Hyperlinks, or Redirects) then Back button support is unnecessary.
If your AJAX application transitions between views (say a list page to a detail page, like in Google GMail), Then you would need to find a way to snapshot and restore state for just that view. You could use a hidden iframe to track view changes, or use hash (#) values on the query string to do the same.
you guys dont get it. The web took off because of its highly orthagonal interface - a couple buttons and a textfield and thats all the user had to know to go anywhere. Try telling your grandma that the "back button is for changing views, and you are only adjusting model state".
I would put forward that when employing ajax technologies you are compromsising simplicity and usability for featurecreep. Period. Its not always bad, but for most webapps where the audience is unknown its a dangerous route.
if there is an application which saving data on each click and then move to next screen(e.g: Software Installers),then there will be always need to have a BACK button feature.what all could be done to save data in session variables,rather server to store dataa in db,OR save info in cookies by calling Javascript methods
-adnan
Olli
said
My wishes to new browser versions is to implement a button.onclick of the browser like you can attach to the window.onresize event. Another button could move thru the called domains instead of the opend pages.
Anyone interested in adding Undo functionality to AJAXian apps should read chapter 2 of -Design Patterns- by Gamma, Helm, Johnson, and Vlissides. Then have a look at the Command pattern specifically, in chapter 5.
If the architecture is clever enough, the gap between client and server will be abstracted away as far as commands and their undoability is concerned.
I agree that the back button is not, and should not, be an undo button. Even without AJAX, poor website planning can make the back button do some bizarre things.
Jerry Pisk said
The browser back button is just that - going back, to a previous resource. Think about in the context of wizards, Back/Next are the navigation, AJAX is the current resource interactivity tool. Of course there are going to be people who abuse AJAX, just like there are web sites that abuse Flash and put their whole site into a Flash content - resulting in the same navigation issues.
Ron Buckton said
The Back button is purely navigational. If your AJAX application transitions between views by actually changing pages (Postback, Hyperlinks, or Redirects) then Back button support is unnecessary.
If your AJAX application transitions between views (say a list page to a detail page, like in Google GMail), Then you would need to find a way to snapshot and restore state for just that view. You could use a hidden iframe to track view changes, or use hash (#) values on the query string to do the same.
koko said
you guys dont get it. The web took off because of its highly orthagonal interface - a couple buttons and a textfield and thats all the user had to know to go anywhere. Try telling your grandma that the "back button is for changing views, and you are only adjusting model state".
I would put forward that when employing ajax technologies you are compromsising simplicity and usability for featurecreep. Period. Its not always bad, but for most webapps where the audience is unknown its a dangerous route.
Adnan Siddiqi said
if there is an application which saving data on each click and then move to next screen(e.g: Software Installers),then there will be always need to have a BACK button feature.what all could be done to save data in session variables,rather server to store dataa in db,OR save info in cookies by calling Javascript methods
-adnan
Olli said
My wishes to new browser versions is to implement a button.onclick of the browser like you can attach to the window.onresize event. Another button could move thru the called domains instead of the opend pages.
Jeff Stewart said
Anyone interested in adding Undo functionality to AJAXian apps should read chapter 2 of -Design Patterns- by Gamma, Helm, Johnson, and Vlissides. Then have a look at the Command pattern specifically, in chapter 5.
If the architecture is clever enough, the gap between client and server will be abstracted away as far as commands and their undoability is concerned.
Jason said
I agree that the back button is not, and should not, be an undo button. Even without AJAX, poor website planning can make the back button do some bizarre things.