Live data from Hacker News

Undo

sachagreif.com

51–60 of 100 posts

Re: Undo

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

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

Re: Undo

#52
post #50

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)

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.

Re: Undo

#53
post #47
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 do…

How do you avoid that the users action have a cascading effect through the system? Was the undo/history option built in from the start?

For example, your app inserts a new doc, some other process sees the new doc and updates a table or inserted into a message queue, it gets picked up by Foo and..

Re: Undo

#54

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

I've worked on event sourcing based systems, Datomic is a lot saner.

Re: Undo

#55
post #53
post #47

Earlier quoted context omitted.

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

How do you avoid that the users action have a cascading effect through the system? Was the undo/history option built in from the start? For example, your app inserts a new doc, some other process sees the new doc and updates a table or inserted into a message queue, it gets picked up by Foo and..

Built from the start, yes.

and... what? you mean what would happen if I undo the creation of the doc? Like I was deleting the doc - the system either would not allow me because of the linked docs/events/objects or would do a cascade delete, if it can.

Re: Undo

#56
post #53
post #47

Earlier quoted context omitted.

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

How do you avoid that the users action have a cascading effect through the system? Was the undo/history option built in from the start? For example, your app inserts a new doc, some other process sees the new doc and updates a table or inserted into a message queue, it gets picked up by Foo and..

Moreover, that other proces need not be on the same server, or even on a server that you control; worse, it could trigger a meatspace effect. "User now authorized, access granted, door opened. [five minutes pass] Oops, that was a mistake." How do you undo _that_?

Re: Undo

#57
post #55
post #53

Earlier quoted context omitted.

How do you avoid that the users action have a cascading effect through the system? Was the undo/history option built in from the start? For example, your app inserts a new doc, some other process sees the new doc and updates a table or inserted into a message queue, it gets picked up by Foo and..

Built from the start, yes. and... what? you mean what would happen if I undo the creation of the doc? Like I was deleting the doc - the system either would not allow me because of the linked docs/events/objects or would do a cascade delete, if it can.

Meant and.. a cascading effect resulting in 100 other actions you're only half-aware of, maybe on other systems =) So building the whole system with this in mind is probably a good idea.

Re: Undo

#58
This isn't a web thing, it's a technology thing. If you dropped a database via a command line tool or desktop app, you'd still lose everything. It's not phpMyAdmin -nor any other web app- being lazy, it's just how that technology works.

And I think the argument that you can't blame the users isn't fair because these are sysadmin tools - so you'd expect the users to know what they're doing.

Re: Undo

#59
post #58

This isn't a web thing, it's a technology thing. If you dropped a database via a command line tool or desktop app, you'd still lose everything. It's not phpMyAdmin -nor any other web app- being lazy, it's just how that technology works. And I think the argument that you can't blame the users isn't fair because these are sysadmin tools - so you'd expect the users to know what they're doing.

"That's how technology works" because that's how the specific bits of technology we're talking about have been implemented. We make the technology, and we could make it work differently. There are cases where un-undoable commands are useful, but these cases are only a small fraction of the things we do on computers, sysadmins or not. Sysadmins may "know what they're doing" but they make mistakes like anyone else, and software should, where possible, be designed to reduce the impact of those mistakes.
Post reply on HN