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

81–90 of 100 posts

Re: Undo

#81

Post by jmmcd »

joshguthrie wrote: post #65
gizzlon wrote: post #51

Earlier quoted context omitted.

Many things will be impossible unless you delay the initial action. I mean, how do you really undo sending an email? You can't. What you do instead, and I'm guessing this is what gmail does, is to delay the sending for 15 seconds to give the user time to regret. Seems like delaying the action will almost always be possible. Guess i could give the users the misconception that they can undo whenever they want, which is…

IIRC, "it's not a feature, it's a bug". Engineers noticed it took about 15 seconds to send a mail through Gmail and added an option to cancel it.

No -- it's an artificially-added delay. By switching the option on, your emails are delayed by the time period you choose.

Re: Undo

#82

Post by sesqu »

Legion wrote: post #36
uniclaude wrote: post #34

Earlier quoted context omitted.

This is a good point, but as the author points it, it feels so useful in Gmail.

Gmail undo is basically job cancellation, not really returning a changed state back to its original state. Gmail can't "undo" once that job has been processed - in other words, when something has been actually done .

Gmail can't, but Exchange and Skype can (and do).

Re: Undo

#83

Post by Joeri »

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 which keep track of the old ad the new state (or at least the parts you need), so that you can have a command history stack, and undo merely means "run the unexecute method of the command at the current position, and move the pointer to the previous command". If unexecute fails, you throw away all older commands (undo history). If execute fails during redo, you throw away all newer commands (redo history). Multi-level undo does need to be designed in from the start, but once you learn how it works it does not add that much complexity.

The reason that you don't see many web applications that implement this is because web development did not branch off from desktop development, but instead branched off from unix systems administration (by creating glorified shell scripting languages to output html pages, and gradually improving on that). Web developers never learned from their senior desktop developers how to implement a multi-level undo/redo using a command pattern, because the vast majority of web developers never had a senior desktop developer to learn from. I only learned it myself because I did have such a desktop development mentor. Mobile developers are typically repurposed web developers, so no surprise that it suffers from the same affliction.

Re: Undo

#84

Post by CodeMage »

On the one hand, I agree with the ideas here. On the other hand, it really worries me when I find out that some server doesn't delete the data when I tell it to delete it. For example, when you delete your Facebook profile or your mails on GMail, wouldn't you like that data to be utterly destroyed?

What would be the correct solution, the one that balances out both of these needs?

Re: Undo

#85

Post by strictfp »

barrkel wrote: post #62
strictfp wrote: post #38

Earlier quoted context omitted.

REST could accomodate for undo quite fine. The server would just have to return a resource representing the action in the response. The client could then delete the action with another request, which would amount to an undo. This is analogous to the command pattern and would require more effort from the programmer, just like normal undo. You need to keep an action history and make sure that all actions are reversible…

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?

Re: Undo

#86

Post by cgmorton »

CodeMage wrote: post #84

On the one hand, I agree with the ideas here. On the other hand, it really worries me when I find out that some server doesn't delete the data when I tell it to delete it. For example, when you delete your Facebook profile or your mails on GMail, wouldn't you like that data to be utterly destroyed? What would be the correct solution, the one that balances out both of these needs?

The correct solution would be to tell you what's happening.

"Your data will be deleted in 24 hours. You can undo this deletion at any time before then."

Re: Undo

#87

Post by Hannan »

CodeMage wrote: post #84

On the one hand, I agree with the ideas here. On the other hand, it really worries me when I find out that some server doesn't delete the data when I tell it to delete it. For example, when you delete your Facebook profile or your mails on GMail, wouldn't you like that data to be utterly destroyed? What would be the correct solution, the one that balances out both of these needs?

Presumably something similar to the Gmail "Undo Send" example? Time limited reversal (in this case specified by user preference) to give you at least some amount of time to reverse your actions before they become permanent.

It's 5/10/20/30 seconds for an email, which seems like a good fit for that use case. Perhaps a Facebook profile delete or mail delete might be more like a 5 min/1 hour/1 day option set, since it doesn't interfere with the primary purpose (i.e. I wouldn't want to wait an hour for all my emails to get sent, but I might be OK waiting an hour for them to actually delete).

Re: Undo

#88

Post by lazerwalker »

CodeMage wrote: post #84

On the one hand, I agree with the ideas here. On the other hand, it really worries me when I find out that some server doesn't delete the data when I tell it to delete it. For example, when you delete your Facebook profile or your mails on GMail, wouldn't you like that data to be utterly destroyed? What would be the correct solution, the one that balances out both of these needs?

Gmail's "undo send" functionality faces a similar but different problem: once an email has actually been sent, there is no way to undo it. They way they solve that is by letting you configure a delay, so you have some period of time in which the email hasn't actually been sent yet so you can undo it.

Something similar could work here. When you delete some data, it gets soft deleted (still exists in your database/etc, but is considered deleted by the application). After a matter of minutes (hours?), it gets actually deleted. You've got a grace period in which you can undo the delete, and then it's gone forever.

Since the most common use case for an 'undo' feature is undoing something you did very recently, that should strike a good balance.

Re: Undo

#89

Post by graue »

"every undoable action first needs to be represented by an object in your code. This is called the Command Pattern"

This is too OO for my taste. Having just seen a talk about MiniKanren, I wonder if you can implement undo effectively with a relational (logic) programming system. Is anyone aware of research (or practice) to that effect? My googling isn't turning up anything relevant.

Re: Undo

#90

Post by coolsunglasses »

alanning wrote: post #78
coolsunglasses wrote: post #52

Earlier quoted context omitted.

Excision is built into Datomic expressly for this purpose. I don't know why people assume those capable of building a database would also fail to anticipate this need. The difference is that you don't use excision except in special cases (like legal obligation to delete data), you use retraction which doesn't lose any history.

Thank you for sharing your experience. > I don't know why people assume those capable of building a database would also fail to anticipate this need. Praptak asked if it was hard to deal with and did not imply Datomic's developers failed to anticipate the need. Excision is a feature that must be prioritized like any other and in fact was not available until Datomic 0.8.3941. https://groups.google.com/forum/#!topic/da…

3941 was pretty early in Datomic's lifecycle so far. It's still a young product but it's very practical already.

Fair point. :)

Post reply on HN