Hacker News Reader

Comment by smooj | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

> 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?!

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_prote...

In the UK, for example, this is implemented by the 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_...

"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...

> 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)

I think you could easily argue that "needing it for an undo feature" is still a legal use for that data. But, thanks for pointing out that "delete" is a lot more legally loaded a term than I had assumed. It makes a pretty convincing case to call things "remove" instead of "delete".

Maybe so, I'd be really curious to talk to a UK lawyer who has some experience in these matters to get a sense for how they're enforced. Thanks for asking the question and inspiring me to do the research - like you I assumed there was no way "delete" was regulated, but decided to look it up before replying and was very surprised.

Probably a place on Earth that legally frowns upon deceptive business practices, false advertising, and the like.

> 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.

> 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.

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.

Isn't that exactly what Facebook and every other social network does though?

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.

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...

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.

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.

Reply on news.ycombinator.com