UX question: is better to have "serious delete" or have "trash"
Posted
by ftrotter
on Stack Overflow
See other posts from Stack Overflow
or by ftrotter
Published on 2010-03-16T15:40:19Z
Indexed on
2010/03/16
15:41 UTC
Read the original article
Hit count: 514
I am developing an application that allows for a user to manage some individual data points. One of the things that my users will want to do is "delete" but what should that mean?
For a web application is it better to present a user with the option to have serious delete or to use a "trash" system?
Under "serious delete" (would love to know if there is a better name for this...) you click "delete" and then the user is warned "this is final and tragic action. Once you do this you will not be able to get -insert data point name here- back, even if you are crying..." Then if they click delete... well it truly is gone forever.
Under the "trash" model, you never trust that the user really wants to delete... instead you remove the data point from the "main display" and put into a bucket called "the trash". This gets it out of the users way, which is what they usually want, but they can get it back if they make a mistake. Obviously this is the way most operating systems have gone.
The advantages of "serious delete" are:
- Easy to implement
- Easy to explain to users
The disadvantages of "serious delete" are:
- it can be tragically final
- sometimes, cats walk on keyboards
The advantages of the "trash" system are:
- user is safe from themselves
- bulk methods like "delete a bunch at once" make more sense
- saves support headaches
The disadvantages of the "trash" system are":
- For sensitive data, you create an illusion of destruction users think something is gone, but it is not.
- Lots of subtle distinctions make implementation more difficult
- Do you "eventually" delete the contents of the trash?
My question is which one is the right design pattern for modern web applications? With enough discussion to justify your answer... Would love to be pointed towards some relevant research.
-FT
© Stack Overflow or respective owner