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

41–50 of 100 posts

Re: Undo

#41

Post by r00fus »

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 .

It's not job cancellation, your view is such that unless you undo, that's reality (you can confirm this by browsing in a separate window, your non-undone actions have taken place).

What Google is doing is (at least for deletes on mails) is equivalent to a database transaction rollback. So they have a tiny (likely 1-entry) transaction log that they keep per user, and if the user desires, they can use it to fully reverse any operation that is undoable aka reversible.

I suppose it works different for email sends you can undo - in that case it is job cancellation.

Re: Undo

#42

Post by uniclaude »

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 .

We, on HN, all have an idea of the tech behind this, but to the user, it is still perceived as an undo action, and that's what I believe the point of the author was.

Re: Undo

#43

Post by blub »

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 don't think that undo has much to do with the type of app, but rather with its design. So mobile, web and desktop apps should be able to offer similar functionality. At least for delete many sites are using a deleted flag anyway, which should be easily reversable. Getting back even part of the content might be worthwile.

In your example, if user 1 doesn't see the edits of user 2 there's a bigger problem. Undo would be liniar.

Re: Undo

#44

Post by r00fus »

jfoster wrote: post #37
brianberns wrote: post #32

"Undo" only makes good sense in an app where each user works in her own isolated sandbox. This is a common paradigm on the desktop (e.g. word processing), but less common on the web. As soon as Alice's transaction is visible to Bob, making it undo-able gets much more complex.

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)

Re: Undo

#45

Post by brryant »

We here at Webflow went through great lengths to implement the command pattern in our web designer. It has definitely paid off when we tell our users they can just hit Cmd+Z and Cmd+Shift+Z anytime they make a mistake.

That said, it's really difficult for webapps to fully support undo/redo. A lot of the web is transactional, and different actions trigger follow on actions. GMail does a really good job with its undo, but there's a reason it goes away after 10, 15 seconds!

Re: Undo

#46

Post by jayfuerstenberg »

Cocoa offers the same undo implementation as described here with "NSUndoManager" where, for each action, you add the opposite action to an undo stack.

As a pattern it is proven to work. It just consumes memory and servers might not scale as well as a desktop app in this regard.

If the undo/redo stacks don't grow too long and the operations are simple enough in nature it might work though.

Re: Undo

#47

Post by kika »

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…

There is absolutely no problem implementing undo on the web with restful interfaces. I just built a quite complex data management application where almost anything is undoable in a very Photoshop way (you see the "History" pane in your UI and can undo whatever you desire). If something is not undoable there it's either a bug or NIY (not implemented yet).

The product is hardcore JS single page application backed by document oriented database, JSON, REST, buzz, buzz, buzz, etc.

Re: Undo

#48

Post by radicalbyte »

This is funny, as in my career I've seen a number of domains, and built (web) systems which required a form of undo. You just don't see it too often in the PHP/Ruby crowd because it's hard to get right and each implementation has inherent limitations.

Luckily there has been work on patterns since the CoF Command/Memento: the Event Sourcing pattern (http://martinfowler.com/eaaDev/EventSourcing.html) can be used to implement system-wide undo functionality.

Re: Undo

#49

Post by kika »

aquark wrote: post #17
smooj wrote: post #9

Earlier quoted context omitted.

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

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

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.

Re: Undo

#50

Post by praptak »

coolsunglasses wrote: post #10

Easier to implement this if your data is backed by Datomic. I'm working in a HIPAA environment and we're quite happily using Datomic there.

That's interesting. Do you have any "really delete this data" requirements and if so, is it hard to deal with that with Datomic?

(sorry if question is dumb, I have near zero knowledge on both HIPAA and Datomic)

Post reply on HN