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:
- What is the object of the operation? This could be a reference to data (e.g. a "key") or data itself.
- 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.