4 ms·

Instead of actually deleting a record when a user hits 'delete' just flip a boolean that indicates it is 'deleted'. Then undoing a delete action is as easy as f

by smooj 13y ago

Instead of actually deleting a record when a user hits 'delete' just flip a boolean that indicates it is 'deleted'. Then undoing a delete action is as easy as flipping the boolean back. For more complex application state you can keep a stack of state or actions (depending on the application and code) and then push onto the stack as the user performs actions (killing off actions older than a certain point). When the user hits undo pop from the history stack and push onto a second 'future' stack to support redo. I agree with the author that it would be nice if more web apps implemented undo/redo. I Iecently implemented it in an interior design app I was working on and it's really not that hard to do.

jd007 13y ago
That may or may not be legal. IANAL but telling a user that his/her data has been deleted when in fact it still sits on the server could be regulation violating or downright illegal depending on where you are. Of course it would probably also depend on what your product ToS says and the nature of the data being deleted.
- sgdesign 13y ago
  Isn't that exactly what Facebook and every other social network does though?
  - kamakazizuru 13y ago
    Yes, and they keep getting flack from various regulatory authorities for things like that. Facebook or anyone doing something that isn't legal doesn't make it legal.
  - xerophtye 13y ago
    They don't even do a good job of hiding it :/ the URL of the image stays the same and it is still accessible through the URL. All they do is remove its link from their interfaces...
- smooj 13y ago
  I'm not sure about the legal implications either, but it would be interesting to know. From a totally different angle it might cause backlash from users if they felt betrayed by an action not actually doing what they thought it would do. You'd have to balance the conflicting desires to be able to undo things and have actions do what they say they will do. Maybe a 'trash can' or 'archive' system is the way to go.
- mcphage 13y ago
  > IANAL but telling a user that his/her data has been deleted when in fact it still sits on the server could be regulation violating or downright illegal depending on where you are Where on Earth do you think labeling a button "Delete" is a legally binding specification with an incredibly specific required implementation?!
  - nitrogen 13y ago
    Probably a place on Earth that legally frowns upon deceptive business practices, false advertising, and the like.
  - elithrar 13y ago
    > Where on Earth do you think labeling a button "Delete" is a legally binding specification with an incredibly specific required implementation?! It may not be "legally binding", but it certainly is a big risk: look at all the hoo-ha when (e.g.) Facebook/Adobe/etc. don't really delete your profile. Note that I'm not saying they should/shouldn't: I'm arguing that there's many cases where indicating something is deleted (and not deleting it) can cause user outrage.
    - mcphage 13y ago
      > I'm arguing that there's many cases where indicating something is deleted (and not deleting it) can cause user outrage. Oh, definitely; that's a great way to piss people off. But jd007 specifically mentioned that it might be "downright illegal", and that's what I was criticizing.
  - dandelany 13y ago
    EU member states are subject to the (soon to be rewritten) Data Protection Directive: http://en.wikipedia.org/wiki/Directive_95/46/EC_on_the_protection_of_personal_data http://en.wikipedia.org/wiki/Directive_95/46/EC_on_the_prote... In the UK, for example, this is implemented by the Data Protection Act 1998: http://en.wikipedia.org/wiki/Data_Protection_Act_1998 http://en.wikipedia.org/wiki/Data_Protection_Act_1998 The guidelines for complying with the DPA talk a bit about deletion here: http://www.ico.org.uk/for_organisations/data_protection/the_guide/information_standards/~/media/documents/library/Data_Protection/Practical_application/deleting_personal_data.ashx http://www.ico.org.uk/for_organisations/data_protection/the_... "If you offer users the option to delete personally identifiable information uploaded by them, the deletion must be real i.e. the content should not be recoverable in any way, for example, by accessing a URL from that site." In fact the DPA takes it even further by requiring that personal data "shall not be kept for longer than is necessary" ie. you are supposed to delete any personally identifying data once you're done using it for it's original purpose (or another legal use). Granted, I imagine it would be pretty hard to bring a case against a company for either of these things, and I can't tell if the former is legally binding or just a "guideline," but it's not outside the realm of possibility...
aquark 13y ago
In a traditional 'desktop style' app simply ported to the web this may be possible. But in a multi-user app that may not be the case. What if the record you deleted was subject to some kind of uniqueness constraint. If another user has added a record that has the same data, then flipping the delete flag off again would not violate that constraint. Sure, it could be handled by checking if the constraint is violated. but you rapidly run into a lot of code to implement that one feature and dealing with thinking of and testing all the edge conditions makes it much easier (& cheaper) to focus on other features.
- smooj 13y ago
  I think those constraints are often the same as when you create a new record, so you can reuse code from there. But I'm sure there can be edge cases that make it tricky for some apps and/or situations. Undo and redo aren't important features for every web app - in some they would't make sense at all - but for applications that facilitate any kind of creative process, such as photo editing, 3d modeling, or drawing, they are very important features to include. Users often want to try out an idea, then go back to an earlier version if the idea doesn't work out. In most cases for apps like these implementing undo/redo gives you a ton of usability bang for your proverbial buck.
- kika 13y ago
  I just went through it, it is actually difficult, but not THAT difficult. You don't flip a flag, you implement a Command pattern of sorts: instead of deleting an object you record the command "DELETE" along with the copy of the object. When you want to undo delete, you take this record, change "DELETE" to "CREATE" and submit this command to execution. Then all the constraint logic works as if you're creating the object from scratch, with possible conflict resolution along the way. Undo is easier if it's not an implementation of time travel but redoing something you did previously in the opposite direction.
dugmartin 13y ago
The problem with adding tombstones to a schema is that they infect every join and you must manually cascade the delete in related tables. For simple schemas, like a blog or simple cms it is manageable but it gets hairy as your schemas get more complex.
- warmwaffles 13y ago
  This is 100% accurate. In some cases you can't use a unique on a column because of the "deleted" boolean or a state machine that is in a deleted state. I would venture to guess that this is where a NoSQL solution would come in handy. Just grab all the data they deleted, shove it into a nice json or xml data structure and store it in the nosql database as a document.

by smooj 13y ago

jd007 13y ago

That may or may not be legal. IANAL but telling a user that his/her data has been deleted when in fact it still sits on the server could be regulation violating or downright illegal depending on where you are. Of course it would probably also depend on what your product ToS says and the nature of the data being deleted.

sgdesign 13y ago
Isn't that exactly what Facebook and every other social network does though?
- kamakazizuru 13y ago
  Yes, and they keep getting flack from various regulatory authorities for things like that. Facebook or anyone doing something that isn't legal doesn't make it legal.
- xerophtye 13y ago
  They don't even do a good job of hiding it :/ the URL of the image stays the same and it is still accessible through the URL. All they do is remove its link from their interfaces...
smooj 13y ago
I'm not sure about the legal implications either, but it would be interesting to know. From a totally different angle it might cause backlash from users if they felt betrayed by an action not actually doing what they thought it would do. You'd have to balance the conflicting desires to be able to undo things and have actions do what they say they will do. Maybe a 'trash can' or 'archive' system is the way to go.
mcphage 13y ago
> IANAL but telling a user that his/her data has been deleted when in fact it still sits on the server could be regulation violating or downright illegal depending on where you are Where on Earth do you think labeling a button "Delete" is a legally binding specification with an incredibly specific required implementation?!
- nitrogen 13y ago
  Probably a place on Earth that legally frowns upon deceptive business practices, false advertising, and the like.
- elithrar 13y ago
  > Where on Earth do you think labeling a button "Delete" is a legally binding specification with an incredibly specific required implementation?! It may not be "legally binding", but it certainly is a big risk: look at all the hoo-ha when (e.g.) Facebook/Adobe/etc. don't really delete your profile. Note that I'm not saying they should/shouldn't: I'm arguing that there's many cases where indicating something is deleted (and not deleting it) can cause user outrage.
  - mcphage 13y ago
    > I'm arguing that there's many cases where indicating something is deleted (and not deleting it) can cause user outrage. Oh, definitely; that's a great way to piss people off. But jd007 specifically mentioned that it might be "downright illegal", and that's what I was criticizing.
- dandelany 13y ago
  EU member states are subject to the (soon to be rewritten) Data Protection Directive: http://en.wikipedia.org/wiki/Directive_95/46/EC_on_the_protection_of_personal_data http://en.wikipedia.org/wiki/Directive_95/46/EC_on_the_prote... In the UK, for example, this is implemented by the Data Protection Act 1998: http://en.wikipedia.org/wiki/Data_Protection_Act_1998 http://en.wikipedia.org/wiki/Data_Protection_Act_1998 The guidelines for complying with the DPA talk a bit about deletion here: http://www.ico.org.uk/for_organisations/data_protection/the_guide/information_standards/~/media/documents/library/Data_Protection/Practical_application/deleting_personal_data.ashx http://www.ico.org.uk/for_organisations/data_protection/the_... "If you offer users the option to delete personally identifiable information uploaded by them, the deletion must be real i.e. the content should not be recoverable in any way, for example, by accessing a URL from that site." In fact the DPA takes it even further by requiring that personal data "shall not be kept for longer than is necessary" ie. you are supposed to delete any personally identifying data once you're done using it for it's original purpose (or another legal use). Granted, I imagine it would be pretty hard to bring a case against a company for either of these things, and I can't tell if the former is legally binding or just a "guideline," but it's not outside the realm of possibility...

aquark 13y ago

In a traditional 'desktop style' app simply ported to the web this may be possible. But in a multi-user app that may not be the case. What if the record you deleted was subject to some kind of uniqueness constraint. If another user has added a record that has the same data, then flipping the delete flag off again would not violate that constraint. Sure, it could be handled by checking if the constraint is violated. but you rapidly run into a lot of code to implement that one feature and dealing with thinking of and testing all the edge conditions makes it much easier (& cheaper) to focus on other features.

smooj 13y ago
I think those constraints are often the same as when you create a new record, so you can reuse code from there. But I'm sure there can be edge cases that make it tricky for some apps and/or situations. Undo and redo aren't important features for every web app - in some they would't make sense at all - but for applications that facilitate any kind of creative process, such as photo editing, 3d modeling, or drawing, they are very important features to include. Users often want to try out an idea, then go back to an earlier version if the idea doesn't work out. In most cases for apps like these implementing undo/redo gives you a ton of usability bang for your proverbial buck.
kika 13y ago
I just went through it, it is actually difficult, but not THAT difficult. You don't flip a flag, you implement a Command pattern of sorts: instead of deleting an object you record the command "DELETE" along with the copy of the object. When you want to undo delete, you take this record, change "DELETE" to "CREATE" and submit this command to execution. Then all the constraint logic works as if you're creating the object from scratch, with possible conflict resolution along the way. Undo is easier if it's not an implementation of time travel but redoing something you did previously in the opposite direction.

dugmartin 13y ago

The problem with adding tombstones to a schema is that they infect every join and you must manually cascade the delete in related tables. For simple schemas, like a blog or simple cms it is manageable but it gets hairy as your schemas get more complex.

warmwaffles 13y ago
This is 100% accurate. In some cases you can't use a unique on a column because of the "deleted" boolean or a state machine that is in a deleted state. I would venture to guess that this is where a NoSQL solution would come in handy. Just grab all the data they deleted, shove it into a nice json or xml data structure and store it in the nosql database as a document.