[Usability] Reducement of confirmation pages / Allow undo

[Jhong]

Yes you can, if you're doing a soft delete or moving to a recycle bin. In fact, I thought that was the original intention of this topic.

Presenting confirmation dialogs, just using a new way.... how does that aid usability?

I use Gnome (Ubuntu) for my daily work, and when I hit delete on a file, it just deletes. I know it has "just deleted" because: (a) I pressed delete, (b) it disappears, and (c) I have a modicum of common sense. I can get it back by going to the recycle bin.

Perhaps adding confirmation dialogs would be a nice option for disabled or otherwise incapacitated users who might hit keys or press buttons accidentally, but IMO it doesn't make sense as a default.

I don't see how an undo stack has much relevance to the discussion. Most deletions or items that have confirmation dialogs are mutually independent. I think an undo stack adds unnecessary complexity (an action log would be good enough for mods to hook into). I think connecting the discussion of an undo stack to the original intention of removing confirmation pages is a red herring.

[Eelke]

I don't. I think it is a wonderful idea to remove confirmation messages. I don't think that saying, "well, it was soft deleted, so if you made a mistake, you can go there an do such and such to get it back" cuts it as a "replacement", though. It needs to be as simple to get your deleted item back as it was to delete it in the first place, namely by clicking a link/button, right there and then (GMail demonstrates that wonderfully). If your Ubuntu interface requires you to go to the recycle bin to recover your deleted item (and it seems it does, just asked a colleague running Ubuntu to show me), I'd call that as much a usability problem as any confirmation popup/box.

My suggestion about a modal popup really is beside the point and is going with GravityDK's pre-assumption of "undos aside". At the very least, a modal popup doesn't require the same page reload as the current confirmation system does. That doesn't mean that confirmation boxes are suddenly a good idea, though. But connecting a universal undo mechanism to the removal of confirmation boxes is far from a red herring. Just MHO, of course.

[GravityDK]

Eelke's understood my view. Let me outline what I'd suggest.
Firstly, for terminology, I'll call "confirmation" pages those which ask a yes/no question, and "acknowledgement" pages those which say 'done, redirecting'.

Acknowledgement pages, in order of preference:

1. should be removed and replaced with some kind of pop-up acknowledgement without reloading a page
2. should auto redirect from the ack page instantly, using the one-line mod that's already gone through phpBB MOD approval

Confirmation pages, easiest to implement first:

1. replaced with an in-line pop-up confirmation yes/no, I imagine this could only be done with Javascript. A fallback behaviour would be required if js is disabled, I'd suggest using a confirmation checkbox next to the action-box they had to click in the first place. Example: checkbox label "delete?" and button labelled "delete it".
2. as above, but also having an 'undo' feature, which is accessed is a similarly simple way (think of the 'undo send' option in gmail)

I like the idea of an undo feature, but I think its supplementary to removing the ack and confirm pages, and not a precondition.

[Eelke]

See, that's where I disagree. What you call acknowledgement pages, all for it. It's not too difficult to implement a system where a script can do something, set a message, and then immediately redirect to the page where e.g. it was called from, where the message is displayed in some kind of message area.

Not sure if I'm on board on the suggestion you have for "confirmations", though. The biggest problem with these, apart from the usability issues (people are preconditioned to answer yes to popups, without giving much regard to the question they're being asked - because of that reason, I believe fast undo will be much more user friendly), is that they currently result in an extra page load. If that's eliminated by using a lightbox-style modal popup (in case JavaScript is enabled, otherwise the fallback would be the old style confirmation pages), I don't really see the benefit in any other type of confirmation action, such as setting a checkbox.

[ToonArmy]

We need to reduce the number of confirm boxes, however they cannot go entirely because of CSRF. See http://blog.phpbb.com/2009/01/14/fighting-csrf/ In addition there are also things which are irrecoverable and thus the user needs to be sure.

[ameeck]

We need to reduce the number of confirm boxes, however they cannot go entirely because of CSRF. See http://blog.phpbb.com/2009/01/14/fighting-csrf/ In addition there are also things which are irrecoverable and thus the user needs to be sure.

Link hashes for GET requests and Form tokens for POST request are not enough?

As for the unrecoverable part -> that's what some soft delete/trash/inactive flag or feature should take care of. Can you give an example of such unrecoverable action?

[Jhong]

I don't think there are any additional XSS concerns with using An AJAX postback rather than a confirm -- you can send a use-once security hash with each request (and receive a new one back).

If all AJAX postbacks are handled by a single back-end receiver, it should be quite easy to implement the security.

[ToonArmy]

We need to reduce the number of confirm boxes, however they cannot go entirely because of CSRF. See http://blog.phpbb.com/2009/01/14/fighting-csrf/ In addition there are also things which are irrecoverable and thus the user needs to be sure.

Link hashes for GET requests and Form tokens for POST request are not enough?

As for the unrecoverable part -> that's what some soft delete/trash/inactive flag or feature should take care of. Can you give an example of such unrecoverable action?

It depends on the severity of the consequences of the action, so the more damage an action can perform the greater the protection it requires.

Examples I can think of right now would be: Restoring a backup, expunging soft deleted data and user deleting their own account (even if it is soft deleted). It really comes down to the actions that aren't easy to reverse (for the invoker) and things that'll cause permanent damage if done accidentally. Now I'd certainly step away from the generic are you sure and tailor the message to the action, so they are genuinely useful to the user from a UX standpoint but provide the safeguards required.