UX question: is better to have "serious delete" or have "trash"

Question

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? How does an "archive" function work into this? That is how gmail works. Give enough discussion to justify your answer... Would love to be pointed towards some relevant research.

-FT

Answer 1

Totally context-dependent.

• If it's an easily reversible action, just delete it, you might not even need a confirmation
• If you might be losing lots of data, a "temporary deleted items storage" might well be in place

Answer 2

I don't see that the presentation of the application (Web App or not) is a major driver for this decision. I would be more concerned with the value of the data, its ease of recreation and the costs of keeping and housekeeping it.

My feeling is that when your app is acting as a respository of valuable data then delete-via-trash is preferable.

Answer 3

My opinion is that there really is no reason to hard-delete anything that could be of importance to someone. In my experience, the pain of having to do a tape backup because a user realized they deleted something last week that they needed is easily resolved by using an 'IsActive' or 'IsDeleted' flag on records that a user could soft-delete.

Answer 4

In my personal idiosyncratic view, every irreversible action is a serious design error. These “Are you REALLY, ABSOLUTELY, POSITIVELY sure?” message boxes are pure crap because the user is very quickly conditioned to just click “OK” and be done with it. In fact, I have lost important data despite such dialogs on several occasions.

In other words: these dialog boxes do not add a working fail-safe barrier, just a usability barrier.

Even trash systems have this problem (they just postpone the moment); the best solution from a usability point of view is an infinite history. Of course, implementing this may carry forbidding costs (e.g. in terms of memory usage).

Permanently deleting sensitive data can (and should!) by all means be implemented as a much more complicated action: it is rarely needed. The only issue is to make it clear to the user that data is normally not lost. Using a history instead of the trash can may help here: the trash can could be misunderstood as being a permanent delete while a (visible) history of actions doesn’t give this illusion of safety.

Answer 5

Here is a relevant article you might like. It's more focused on business scenarios, but it can apply anywhere.

Don't Delete, Just Don't.

Answer 6

I think you pretty well summarized the pros and cons for the trash model:

• Pro: Overall, better for the user.

• Con: Overall, easier for the developer.

For a usability specialist like myself, it’s a no brainer. As far as I’m concerned developers are supposed to work hard to make life easier for users. Frankly, until web apps have Undo capabilities like trash, I don’t think we can consider them usable. Time that web apps catch up to 1984.

A few other details:

• Another advantage of the trash model is the capacity to eliminate the need for confirmation message in most cases. The vast majority of the time, the user is deleting something intentionally, so putting an extra step in with a confirmation message is usually adding work for them. Worse, they get in the habit of smacking OK quickly, which generalizes to other confirmations they really better read. See http://alistapart.com/articles/neveruseawarning.

• Part of the beauty of the trash metaphor is that it suggests to user that deleting is not permanent. Like a physical trash can, objects can be retrieved. If you feature the trash can obviously enough on your page (so users realize they can open it), and include an image of the trash can as an icon next to the Delete menu item, that should be enough to indicate that deleting doesn’t destroy, but rather moves things to the trash.

• It’s probably acceptable to destroy the oldest deletions in the trash if there are performance considerations. That is once again consistent with the trash can metaphor: users can anticipate that sooner or later “someone” is going to empty the trash. I don’t think users will care if the trash never empties. If they need to truly destroy something sensitive, you can provide an explicit procedure for it (e.g., deleting something that’s already in the trash).

Answer 7

Trash: a great affordance and metaphor. From the man himself: http://www.joelonsoftware.com/uibook/chapters/fog0000000060.html

My views:

1) Who are your users? This would be the biggest deciding factor for me. Example: If you complain to a linux geek about accidently deleting something with rm, they'll either tell you to alias it to 'rm -i' or to RTFM. However, judging from the tone of your question, I'm guessing you want to be nice to your users. In that case, you can give them the affordability to do random stuff with your app knowing that they have a safety net.

2) No dialogs. Stop that. Especially with a web app. They're ugly, confusing, and useless. I think everyone's on the same page with this.

3) What's the data? I may have a dissenting opinion on this, but if we're talking about Uncle Bob's phone number, does it really matter if you delete it without question? However, you mention "sensitive data" and the "illusion of destruction". Easy fix: they click to delete something, a spiffy message appears somewhere on the screen saying "Moved to trash. Click here to empty trash." or something like that. As for 'eventually' deleting the data, that's up to you.