Delete - Undo
-
It has become increasingly popular to implement Delete functions in such a way that the user will not be bothered with MessageBox confirmations, but will instead be given the option to undo his action. Gmail does it, and this is covered very well in an article at alistapart.com[^]. I've been implementing this in my own projects, and would like some input from others regarding the best design for this. In many cases, the implementation isn't terribly complex: When an entity is deleted, it is simply deleted from a table, but a copy of the deleted entity is stored on the side (for instance in ViewState if this is a web application) and the user given the option to undo his action. If the user chooses to undo, this entity is simply re-inserted into the table. If the user doesn't choose to Undo, this copy will simply get lost when the page is closed, which is very much in line with the user experience (when he closes the page he will probably expect to loose the chance to undo his action). As I said, this might be OK under some circumstances. But then there are others. For instance, lets assume I'm writing my own blog site, I want the admin to be able to delete blog entries, and I want to implement undo as well. Each blog entry has a unique ID allocated by the database, each blog could then have zero or more comments, where each comment could be linked to another comment (similar to the messages in the CP messageboards). This would be implemented such that each comment has also a unique ID (assigned by the DB), each comment has a BlogID and a ParentCommentID. Blog posts are then linked to using their ID (myblog.com/Blog.aspx?ID=10). Let's assume that the admin now wants to delete a blog entry. By using the implementation given above, several problems arise. First, if the admin chooses to undo the deletion of a blog entry, a new entry would essentially be created, so the BlogID's of each comments would have to be updated. Also, comments would have to be relinked together since each comment would also receive a new unique ID, so all the parent ID's would have to be updated. Both of these tasks are very well manageable, but annoying. However, the biggest drawback lies in the fact that any links to this post are now invalid, since the blog entry wasn't really undeleted, a new one with the same content was created but with a new ID. So this implementation
-
It has become increasingly popular to implement Delete functions in such a way that the user will not be bothered with MessageBox confirmations, but will instead be given the option to undo his action. Gmail does it, and this is covered very well in an article at alistapart.com[^]. I've been implementing this in my own projects, and would like some input from others regarding the best design for this. In many cases, the implementation isn't terribly complex: When an entity is deleted, it is simply deleted from a table, but a copy of the deleted entity is stored on the side (for instance in ViewState if this is a web application) and the user given the option to undo his action. If the user chooses to undo, this entity is simply re-inserted into the table. If the user doesn't choose to Undo, this copy will simply get lost when the page is closed, which is very much in line with the user experience (when he closes the page he will probably expect to loose the chance to undo his action). As I said, this might be OK under some circumstances. But then there are others. For instance, lets assume I'm writing my own blog site, I want the admin to be able to delete blog entries, and I want to implement undo as well. Each blog entry has a unique ID allocated by the database, each blog could then have zero or more comments, where each comment could be linked to another comment (similar to the messages in the CP messageboards). This would be implemented such that each comment has also a unique ID (assigned by the DB), each comment has a BlogID and a ParentCommentID. Blog posts are then linked to using their ID (myblog.com/Blog.aspx?ID=10). Let's assume that the admin now wants to delete a blog entry. By using the implementation given above, several problems arise. First, if the admin chooses to undo the deletion of a blog entry, a new entry would essentially be created, so the BlogID's of each comments would have to be updated. Also, comments would have to be relinked together since each comment would also receive a new unique ID, so all the parent ID's would have to be updated. Both of these tasks are very well manageable, but annoying. However, the biggest drawback lies in the fact that any links to this post are now invalid, since the blog entry wasn't really undeleted, a new one with the same content was created but with a new ID. So this implementation
dabs wrote:
would like some input from others regarding the best design for this
Your not asking about design, you are asking about what feature should be implemented. That question needs to be asked for each project based on the project definition. An admin deleting threads and all it child replies is not at all equivalent to someone deleting text in a word processor. For this reason I don't believe the Undo is a good fit. A recycle bin where it must be manually deleted or perhaps expired but until then can be restored sounds like a much better use model for an Administrator and that problem domain.
led mike