When does delete not mean delete?

Question

I recently submit a bug report about a user interface. The steps shown demonstrated that "deleting" something didn't allow it to be recreated afterwards.

The error on creation was "Another account is already using this unique key." but the user interface shows no such key in use anywhere.

However, the developers response was that it was not a bug. Since the software maintains a unique key throughout its lifetime, that key should not be destroyed. Their suggestion was to access the underlying database and delete the unique key. The problem was that the key in this case was a commonly-used value that would make it hard to avoid. (e.g. the user's email address)

On a software development level, the principle problem is choice of unique key. If that key needs to be unique throughout the lifetime of the product, then it shouldn't be user-chosen.

However, from a user experience level, if I "delete" something, then shouldn't it be properly deleted, warts and all? Thus, there should be no problem if I choose to create it again.

Some other ways to look at this experience might be:

• If the key affects the user experience, then it should be shown in the interface. So if it's only partially deleted, then I should still find it listed somewhere.

• If components of the deletion remain, perhaps it should be called "disable" or "hide"?

Is there some kind of subtle line where delete stops meaning delete?

(As a corollary, I note that some online systems have "delete profile" but don't delete everything, either!)

From the discussion, and after some thinking time, there appears to be 2 facets and 3 operations that can be described here:

1. What is the object of the operation? This could be a reference to data (e.g. a "key") or data itself.
2. What operation is being performed? In other words, what are we deleting? Are we:
   • changing a link between some data? e.g. unlink
   • deleting a key that acts as a reference? e.g. dereference or remove (maybe)
   • erasing the data itself? e.g. wipe or erase

It could be argued that in all cases something is lost and therefore "deleted". It could also be argued that nothing is ever lost but simply changed. That is a primarily technical difference, however, and we're focusing on what the user perceives is happening and how that can be improved. So this is irrelevant to the question.

From the user's perspective, in all cases here, something is lost and the possibility of finding it again is wide-ranging. As pointed out by @evil-closet-monkey, the concept of "deleting" suggests destruction beyond possible recovery, which is why many common UIs choose not to use that term anymore.

However, the very first part of this question demonstrated that "deleting" didn't actually delete but unlink or remove, and that created an unexpected impediment to another operation (the creation of the new account). I think this hasn't been really fully addressed in any answers so far. Imagine if, after "deleting" a file, you were never able to create that file with the same name again. That would be a bit silly, wouldn't it? Or would it?

Furthermore, there can be an egotistical relationship between the user and the data. I am more concerned with where my email is stored than being counted as a visit to a site, for example. This can have an effect on what I expect will be deleted.

Answer 1

From a user's point of view, delete should represent a permanently destructive action on that object.

Example: Place an apple in front of user and ask them to "delete the apple". They might be puzzled at first but they will eventually do something with it. Now, ask them to eat the apple. Chances are they will be very puzzled now because they either (1) already ate ("deleted") the apple, or (2) threw it in the trash and really don't want to eat an apple that was in the trash. Any attempt to take action on the apple require a new apple!

Example: Put a document or drawing in front of a user and ask them to "delete" a particular element from it "with this pencil". They will either scratch it out, draw a line through it, or erase it. In all cases it is a destructive action to the original.

Example: Do you honestly believe these guys don't mean what they say!?

The destructive metaphor of delete was brought over into the computer world as well. Microsoft DOS has the del command and UNIX as the rm command (although short for 'remove', lots of documentation on the command will use the term "delete").

Moving into the UI world, before the days of a "recycle bin" or "trash", to ask to delete a file still meant to destroy it completely. Today we do have those concepts though, and they are used like so:

Mac & GNOME (couldn't find a KDE snapshot) do it correctly! Notice you are moving items to a trash can, just like you would in the physical world. When I throw a piece of paper out, I can always pull it back out of the bin.

Windows does it wrong! You "delete" a file to a "recycle bin"... huh? I've never deleted a soda can before, let along into my recycle bin. How are software files "recycled" anyway? But I digress, this just really irks me!

When done right, you aren't "deleting" files anymore. You move them to a space where they can be recovered. When you "Empty Trash" (on Mac) the files are gone for good, just like on Friday morning when the trash truck comes and takes your weeks worth of trash away.

While the file is still technically on your hard drive, for 99.9% of users the file is effectively gone at this point. It is "deleted."

Looking more specifically at the backend, the SQL delete command is just as destructive. There is no "kind of deleted" about this command. You run it and you better hope your SQL string is correct!

On a software development level, the principle problem is choice of unique key. If that key needs to be unique throughout the lifetime of the product, then it shouldn't be user-chosen.

Exactly correct. So your developer is wrong, this is a bug! As a former developer myself I know what he thinking, and the user experience is not in the mix. The fix might not allowing the user to create that unique key, or changing a label. It isn't necessarily a code fix.

Is there some kind of subtle line where delete stops meaning delete?

The subtle line is created by poor use of words within the user interface. Delete should be just as destructive as it sounds, else you put users into a false sense of security when "delete" here isn't as destructive as the "delete" that is over there!

From your question's description of the product, I would say you are on the correct track that the unique key should not be user defined. If the unique key was being used as (for example) a "name" field, you might need to add a new field to the database to fill that need from the users - but the field does not have to be unique on the system side.

Now, when you "delete" a record it is gone with no trace from the user point of view. If they recreate it exactly the record may have a new unique id but they don't care - they don't see it anyway!

Answer 2

There's no hard and fast rule here. In most cases, the end-user no longer sees it, but whether or not it's deleted is a murky concept.

Take a look at your average desktop GUI.

• Delete a file and...
• It's still there. In the trash/recycle.
• Delete it from the trash/recycle and...
• Well, you don't see it, but it's still there on the hard drive

So if we get into the technical aspects of it all...such as DB GUIDs, it's definitely murky.

Broadly speaking from a user experience standpoint, it really depends on context. But typically you'd want two-form 'validation' of a delete. This could be as simple as the common 'delete moves to trash where it can be recovered or permanently deleted'...sometimes that latter option is in the user's hand, sometimes that requires some form of admin level rights (depending on the application and the data).

Answer 3

On systems where user actions are recorder and may be linked to more data and other users, it's difficult to completely delete all traces of a deleted user.

For instance, in a forum, after you have written some posts and answers, if you decide to remove your use account, it may happen that the reference to quotes are still there because the table related to quotes is linked by the unique key, which may be the user's email; or the list of most prolific users is also linked to the email or key associated to the user, etc.

So in those situation, removing you account usually means that your personal information is gone, but your linkage to other elements on the system remain; still, those may not be traceable to you directly, at least if the associated key is not the email, but they are there for consistency of the database.

Designing complex systems where data is linked are difficult to completely clean up for the presence of removed items. So I'd say that in that kind of situations, delete means "we remove direct traces of your existence here and kind of transform your past on a ghost"

Answer 4

Why delete is not delete

The reason why they don't really delete it from a technical perspective is to keep relations in place. However, that doesn't mean anything to the end-user, and therefor leads to a sub-optimal experience.

How to make it look like delete from a user's perspective

What they can do is reconciling the two: when a user delete an account it stays in the system, but is completely hidden from the user. Then when they user wants to recreate the account, simply revive it (but keep in mind that old data will show up then), or create an alternative account with the same credentials.

Legal caveats

Always keep in mind that there may be applicable legal obligations to totally destroy the (user's) data. When they apply, then make sure delete is really, really delete.

Answer 5

Not an answer but... use "Remove from list" if an object is just removed from a list but not removed from software/hard drive. Too often, "Delete" is used and that has an ambiguous meaning to it.

As long as the functions has clear names/explanations/icons you are on a good way to a software that's easy to understand and use.

Answer 6

One difficulty that can arise in database design is how to handle record identifiers that may exist in places the database doesn't know about. If some particular string can be used by itself to identify a record in a database, a strong argument can be made that no copy of the string should ever be able to identify any other record in the database. Enforcing that requires one of two things:

1. Tracking down and destroying all evidence which might exist anywhere in the universe which would indicate the string had ever been used as a database key.

2. Never allowing that same combination of characters to represent anything other than the original record.

From a user-interface standpoint, the question of how to expose record identifiers thus becomes very important. Exposing only surrogate identifiers will ensure that if a record is deleted and recreated, the new records can be assigned new identifiers, but requiring people to use surrogate identifiers can sometimes be annoying. Using or exposing user-supplied identifiers can make things more convenient for users in most cases, but if identified records are removed, allowing the identifiers to be reused will mean that existing references to the old record will become references to a new record which may or may not really be related to it.

Answer 7

I have worked as a software developer for over a year. During most of that time it was working with web interfaces that connected to databases. During this time I learned there is a difference in "delete". I am not sure it is the proper terms, but there is a hard delete and a soft delete.

Hard delete is where information is completely wiped out. Most programmers avoid this for many reasons when it comes to database programming. For example if you do not have a query string correct when removing a record, it is much easier to switch a "deleted" flag in a DB than it is to restore backups. For this purpose, you can use a soft delete.

A soft delete basically works like your recycling bin does on your Windows desktop. While you can not see the files through your file explorer, the files are still on your hard disk (Even after you empty your recycle bin until the files are overwritten by other files). This allows developers to maintain records and makes auditing as well as researching bugs much easier.

Answer 8

I believe your submitted bug report was 100% correct.

If an interface has a delete option that removes an object "permanently" -- in the regard that there is no user-facing mechanism to recover it -- then it is, as far as the user is concerned, permanently deleted and able to be recreated.

The developer response might be correct from an architecture standpoint but that simply means the interface and the architecture it's built upon are not representing the same thing. (I do believe, as you mentioned, user-input should not be generating a unique key to avoid situations like this).

If you delete a file in your filesystem, it does not disallow you from creating a new file with that name; if you delete a character from a document, you are not disallowed from typing that character next once again; if you delete a draft in an email client, you can create another one with that same subject. All of these are the correct implementation of delete and handle the user-input differently than the unique key they store it as.