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…

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.