For an "application" perspective the concept of a universal back button is unnatural in a lot of respects. But for better or worse the back button is here to stay. I am happy to see that wicket is dealing with this issue directly. Here are some thoughts I hope might add some value to the discussion.
Having said that it seems to me that that their is one key question to ask when the back button is clicked - What is the user's intentions and expectations? 1) Simple navigation. In this case the user is "passively" navigating around the website/application and wants to go back to an earlier screen. In the case the back button is not really reversing any "action" but just moving back to a eariler page views. I think this is the most common case and very natural for a user to do from a navigational perspective and one of the things that makes web browsers intuitive to use for the casual user. This is the easy case where nothing special needs to be done. 2) Reversing an action/operation. I think the issue here is more about reversing an action than it is about the state of the HTML data vs the server data. The back button in this case is going back to a screen that may have "changed" something in the process of getting to the next screen. So clicking the back button here means the user wishes to reverse that action (whether they understand that or not) in the process of going back to the previous page. I think it will help to look at actual scenarios: a) Wizard Scenario. If the user is in the middle of using a wizard (or shopping basket) it is natural for them to believe that clicking the back button will take them back to the eariler state of the wizard. This is very natural and most wizards should be able to deal with this without to much trouble even if they are maintaining the state, of the shopping cart, in a database for example. Good application programming should allow the wizard/shopping cart to handle this. b) Check out Scenario. If you reach the end of the wizard or, for example, and you click "confirm purchase" on your shopping cart, you are out of luck when you click the back button now. Because clicking the back button now is more complicated. Going back to the earlier screen here is very confusing and something you don't want the user to do, because they have already commited to the purchase so going backward in the wizard or shopping cart does not make sense once you have finalized the transaction. There needs to be a way to allow the application to control this behavior or make it clear to the user that they are doing something that is not allowed. c) Delete item from a list Scenario. In this scenario the user is deleting an item from a list and that delete operation takes them to a new screen. Now if we click the back button here will see the list before the item was deleted. Not something that really makes sense functionally cause the item is now really deleted. However, even though this does not make functional sense from an application perspective it is not that bad as the application should be able to handle it. So if the user tried to edit that delete item, for example, the application should be capable of gracefully telling the user the item is no longer present and probably refresh the screen with the updated items listed. The scenarios above (a,b,c) are not completely mutually exclusive but if wicket could handle each of these general cases I think the problem of the back button would be addressed. Note, that in all the cases above (1 and 2) we are dealing with a mult-user system and there will always be cases where the data gets changed underneath the user (HTML not in sync with server model) with or without the back button in the equation. So the GUI/HTML being out of sync with the actual data on the server is always a possibility and this is something the application will always have to deal with and should deal with gracefully. -Sam > One thing I have just though of is that the conceptual separation is > slightly more subtle than I thought..... > > On one side are the things that only Wicket cares about: Pages, Components > & > Model instances that are usually mutable and which after creation are not > linked to business data in any way (e.g. a simple string model in a Label) > > On the other side are the Model instances that are backed by real business > data that is queried and possibly updated during processing and rendering > > > > Hi All, > Having had time to take a step back from the back button issues, here are > my > thoughts on exactly what we are trying to achieve plus some other > interesting observations...... > > Requirement > > Issue: > User presses the back button on their browser > > Expected Result: > The user is displayed an 'appropriate' page. By 'appropriate' page we mean > one of the following: > > 1. The exact page that the user saw previously > > 2. The same page that they saw previously but updated to reflect > underlying > model and/or contained component changes > > 3. A stale data error page with appropriate link to either the application > home page or another 'bookmarkable' page within the application. > > 4. The application home page or another 'bookmarkable' page within the > application but with a feedback panel informing them that the data they > were > working with is no longer valid and asking them to reselect from the > up-to-date set of data > > > Obviously, if the page is not stale then it can just be re-rendered. > Issues > only occur if the page is stale for some reason. > > Options 3 and 4 are not difficult and are in fact just variations of the > same thing. The configuration choices are whether to go to an error page > and > then on to another page or whether to go direct to that page and display a > feedback panel. > > > Regarding options 1 and 2, there are actually TWO totally different issues > (and I think this is where much of the confusion has been going on because > we have been mixing them up): > > a) The reason the page is stale is because the model data has changed > since > it was rendered > > b) The reason the page is stale is because the components on the page have > changed since it was rendered > > A page can be stale for reason 'a' OR reason 'b' OR both reasons 'a' and > 'b'. > > I think from a solution point of view we need to consider how to handle > 'a' > and 'b' separately. The main reason for this is that 'b' is something that > is entirely within the Wicket core and how we deal with containers, > components and replacement; whereas 'a' has an impact on people who > develop > applications using Wicket. We can therefore do some clever stuff in > solving > 'b' without having too much impact on the public API of Wicket. For option > 'a' we need to come up with something that works transparently for most > cases makes it easy for users to introduce their own level of control. > > There are also additional issues associated with reason 'a' that a > developer > using Wicket has to consider. Things like: what if the data for the model > we > want to redisplay is no longer available and we didn't/couldn't keep it in > memory or recreate it; what happens if we display a page to the user then > they try to commit an update but the underlying data has gone or has been > changed in another transaction; and so on. These sorts of issues are > probably not something easily addressed by Wicket as they will be very > application specific. Wicket can only help people out in making it easier > to > implement their chosen decision. Some applications may only want to > support > the back button if the data used as the page model is still present in the > database, others if it has not been changed by someone else and so on. > > This kind of conceptual separation between is also something we need to > think about for clustering purposes as well as there appears to be > completely different clustering criteria between Wicket pages and > component > and the models. > > Regards, > Chris > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
