Proponents of various abuses of Flash and Ajax cleverness have a frequent defence of their sins: “I’m allowed to break the back button, bookmarking and ‘open in new window’ and all that other stuff people take for granted because that stuff only applies to websites. This isn’t a website – it’s a web application!”
Well I am prepared to accept this argument if we agree on a proper definition of ‘web application’. I’m tempted to be snarky and state that a web application is a web site where I would never deam of bookmarking or using my back button but for the sake of making my argument in good faith I will endevour to present a slightly more useful definition.
Websites have pages. Web Applications have states. An application can be spread over several pages of a website in which case the back button and bookmarking should work between pages. It’s OK for them not to work between states.
How do we differentiate between ‘states’ and ‘pages’? Here’s my not very well thought out rule of thumb. GET’s are pages and POST’s are states. For the less HTTP involved among you then here’s it put another way. If you’re changing data on the server then that’s a POST and I don’t need to bookmark or go back. (However you’re welcome to implement an ‘undo’). If, however I’m just moving to a different view of the data then I will probably want to be able to bookmark that view, send the URL in an email, open it in a new window and all that other stuff a normal website gives me for free.
I’m not sure that differentiating between GET and POST is going to be useful.
Primarily because the user can’t tell: both involve reloading a page (even if it’s the same page).
Also, from a development point of view neither mechanism determines whether the back button works.
The problem is that there is often no page reload (via Flash or AJAX), and the times there is a page reload, it does not necessarily match a useful back/undo point.
Ideally, you would map the back-button to ‘undo‘ for the last change, or at least provide an undo as part of the application.
Alestair – you missed my point a bit. I admit developers can implement the same page request arbitrarily as GET or POST and users often can’t tell which is which.
I was talking about how the request SHOULD have been implemented. Requests that suit GET (idempotent, non-data-changing views) should fully support back button and bookmarking as users will feel that they are simply moving to a different view of the data even if form fields are involved.
Requests that should be POSTS (non-idempotent data-amending or creating) are allowed to break the back button although if the developer wants to be nice and it’s technically feasilble to undo the changes then they can add this and also indicate that undo is allowed. Users won’t expect it so it’s not a usaility mistake if it isn’t there.
What I object to in Flash or Ajax (or frames for that matter) is those situations were a normal site wouldn’t dream of preventing bookmarking and/or back button usage but the technology doesn’t allow it.
Oh dammit. That means I’ve just talked myself into adding damn back button support on the site I’m building. I wish I’d kept my gob shut now…