Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undo

sachagreif.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Undo

#91

Post by GuiA »

Joeri wrote: post #83
GuiA wrote: post #25

Interesting write up. Thanks a lot for writing it Sacha. Okay, so I have a question. Isn't this just a property of the internet as a system? If we remember the history of human-computer interaction on 2D displays, we first really remember what led to the desktop GUI (Xerox Alto, all that stuff). This domain had tons of research poured into it (of which Raskin is a member) - including from the military, for usability…

I've implemented multi-level undo/redo on both the desktop and the web, and the complexity is no different between the platforms. Client/server is a red herring, because what kills you is unexpected state changes, and a desktop app has to contend with that as well (e.g. what if you want to undo a file delete but a file has been created with the same name by another app?) The trick is to put everything in commands whi…

Re: your 3rd paragraph: yes, I wanted to mention that in my original comment and forgot. Thanks for bringing it up.

A lot of our modern infrastructure comes from the almighty UNIX era- before GUIs had really become as mainstream as there are todays. In that era, things like "undo" were close to non-existent (there is no undo for `rm`- the GUI's "hack" to solve that is the "Recycle Bin" (which is also nonexistent on mobile, interestingly enough)).

A lot of our modern web tools are mere interfaces to those various Unix utilities (phpmyadmin, as mentioned by Sacha, is just a neat little HTML interface to mysqladmin), and thus can't do much to provide functionality that's missing at the source.

Re: Undo

#92

Post by andyroid »

j_s wrote: post #77

CouchDB supports undo as part of their core storage model. http://guide.couchdb.org/draft/btree.html The short answer is that because CouchDB uses append-only files, the B-tree root node must be rewritten every time the file is updated. However, old portions of the file will never change, so every old B-tree root, should you happen to have a pointer to it, will also point to a consistent snapshot of the database.

Doesn't that mean a rollback of the entire database, as opposed to just a single operation?

Re: Undo

#93

Post by jfoster »

r00fus wrote: post #44
jfoster wrote: post #37

Earlier quoted context omitted.

How does Google Drive handle this?

Doesn't Drive, just like Dropbox, simply version everything similar to a source control system? Using the optimistic locking pattern, this would mean that Alice could undo, and if Bob then makes changes referring to Alice's entry, it'd be pointing to a previous versioned entry (Alice's undo would simply copy version n-2 and make it version n while Bob would be pointing or editing version n-1)

Not sure. That behaviour would be a little weird, if Alice hitting Ctrl-Z undoes what Bob just did. Google Drive's document editors explicitly appear to support "undo".

Re: Undo

#94

Post by crystaln »

blub wrote: post #40
crystaln wrote: post #39

Undo is hard, not a core competency for most companies, and most users don't care. In fact, many users don't want deletes to be undoable, they want deletes to be delete. You could probably make a stronger case for improving deletes by overwriting the disk space with garbage and ensuring users that no derivatives were left around. That would be a selling point. Imagine SnapChat with undo...

Undo is hard? With web apps most developers complain that it's actually too hard to delete things so they use a delete flag instead...

Delete can be hard too...

Undo is definitely harder.

Re: Undo

#95

Post by krallja »

For FogBugz and Kiln, we try to follow the principle that changes should always be reversible. Clicking "delete" on something just marks it as deleted, for example, with a corresponding "undelete" action hidden somewhere administrators can find it. If you want to truly delete something, you have to get in contact with our customer service folks (sometimes to our users' chagrin).

Re: Undo

#96

Post by mcphage »

elithrar wrote: post #27
mcphage wrote: post #21

Earlier quoted context omitted.

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

> 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 delete…

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

Re: Undo

#97

Post by mcphage »

dandelany wrote: post #28
mcphage wrote: post #21

Earlier quoted context omitted.

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

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

Re: Undo

#98

Post by barrkel »

strictfp wrote: post #85
barrkel wrote: post #62

Earlier quoted context omitted.

If REST follows HATEOAS fully, the back button is 90% of your undo.

Hmm. This would require a representation of the complete state history in resource urls, wouldn't it? I can only come up with something like /image/edit1/edit2/edit3/edit4 where going back would bring you to /image/edit1/edit2/edit3. I suppose you can also do something state-based like /image/state4 going back to /image/state3. This would push the storage of the edit stack to the server. Is this what you mean?

Yes; with request / responses reanimating a continuation, and with a copy-on-write tree of activation records instead of a stack.

But the usability probably wouldn't be fantastic.

Re: Undo

#99

Post by dandelany »

mcphage wrote: post #97
dandelany wrote: post #28

Earlier quoted context omitted.

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

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

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.

Re: Undo

#100

Post by vdm »

jakejake wrote: post #13

My philosophy is that of all the things that are important for a business or a web service - keeping your data is the very highest priority. Just about anything else can be fixed, but if your data is lost with no backup then no amount of programming or time or sweat is going to get it back. It's a good idea to just keep this in mind when you're working anywhere near a production database. backup, backup, backup.

Backup is manual Undo.
Post reply on HN