How to Make Sure Users Don’t Accidentally Delete(uxmovement.com)
uxmovement.com
How to Make Sure Users Don’t Accidentally Delete
http://uxmovement.com/buttons/how-to-make-sure-users-dont-accidentally-delete/
3 comments
"type DELETE" is a big improvement on the old alerts that Aza wrote about. I think it actually fixes the problem.
The more common it is to delete something as part of a regular workflow, the less attention you pay when you do it, and no number of confirmation dialogs will resolve that.
99% of the time when I want to delete something, it's intentional instead of accidental, so why should have I have to confirm the action 99% of the time, to potentially save me 1% of the time.
Allowing the user to undo is a much better solution, as even if you confirm something, it's only after deleting it you realise you selected the wrong list to delete, or though you where on the development server instead of production. And there's no reason this should only apply to destructive actions such as deleting something. GMail let's you undo sending an email (or more specifically, it delays sending the email for a few seconds to give you a chance to realise you sent it to the wrong person, forgot an attachment or realise you're drunk emailing).
I aware that there's additional work involved in developing something to allow you to undo, as well as added overhead, such as how long do you store "deleted" files, how do you undo an action which has since had other actions performed on it etc.
99% of the time when I want to delete something, it's intentional instead of accidental, so why should have I have to confirm the action 99% of the time, to potentially save me 1% of the time.
Allowing the user to undo is a much better solution, as even if you confirm something, it's only after deleting it you realise you selected the wrong list to delete, or though you where on the development server instead of production. And there's no reason this should only apply to destructive actions such as deleting something. GMail let's you undo sending an email (or more specifically, it delays sending the email for a few seconds to give you a chance to realise you sent it to the wrong person, forgot an attachment or realise you're drunk emailing).
I aware that there's additional work involved in developing something to allow you to undo, as well as added overhead, such as how long do you store "deleted" files, how do you undo an action which has since had other actions performed on it etc.
This kind of problem was solved almost two decades ago:
1 - use the correct dialog button layout: cancel on the left, confirm on the right. always.
2 - default to the cancel button - highlight / color it & attach to the enter key
3. show an alert icon - something obvious, don't just show plain text
4. if it's really serious, allow undo / history
1 - use the correct dialog button layout: cancel on the left, confirm on the right. always.
2 - default to the cancel button - highlight / color it & attach to the enter key
3. show an alert icon - something obvious, don't just show plain text
4. if it's really serious, allow undo / history
Better: Allow undo/history even if it's unserious.
Is there any reason that concept is so rarely used in the web?
Well, there's usually an undo functionality in desktop-like web apps but most CRUD lack that kind of feature.
Because people don't know they want it, so it's easy to not bother implementing it knowing no one will ask for it.
[deleted]
Aza wrote about this way back in 2007: http://alistapart.com/article/neveruseawarning