5 ms·
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 th
by GuiA 13y ago
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 in extreme situations - and by now it's reached a pretty mature stage, and we have developed a nice design language to describe it and advanced technological tools to implement that language.
On my Finder, or in Pages, I can reliably undo things nicely. Just today, I deleted a file by mistake- command + z, boom, undone.
(by the way, this is exactly what Apple and mobile devs talks about when they say that well done native apps can never be beat by web apps- those decades of best practice experimental research)
Web apps, on the other hand, run on the internet, which adds some constraints structure wise. All of a sudden, we have at least 2 computers talking to one another, and in most cases many, many more than that. So we have to come up with design principles to make all of this somewhat work together, and we come up with things like RPC and REST. Those things are how our servers talk now, and they influence every technology that we build. They come with some constraints however- notably the ideal of statelessness, in which implementing "undo" would be really hard. Relational databases don't have the semantics to express "undo the last statement that was a user action done with id N", and good luck implementing things like undo in a system where you have caches you can't invalidate, content determined by one way hash functions, etc. If you have a binary blob of 5 lines, that user 1's action modify the first 3 lines, that user's 2 action modifies the last 3, and that user 1 then decides to undo his command?
You'd basically have to version everything, and have super amazing algorithms doing bisects and diffs on your content.
The http internet is really just a way to exchange documents. We've hacked it, using fancy stuff like AJAX, to make it behave more like the traditional GUI that we know and love, but at the core it's still a way to transfer documents. And naturally, HTML, the description language we use for web content, has semantics for describing static documents. Heck we've had to design a whole new language for design (CSS), because it's really just a way to describe documents! So ultimately it lacks the way to implement concepts like undo-ing as first class features.
Let it be noticed that mobile apps do undo-ing very poorly, as well.
- sgdesign 13y agoGreat points, I hadn't considered that angle while writing the post. Those are definitely hard problems to solve.
- strictfp 13y agoREST 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.
- barrkel 13y agoIf REST follows HATEOAS fully, the back button is 90% of your undo.
- joshguthrie 13y agoI would like to know more about this implementation. I don't see how going back after a POST action is related to HATEOS.
- strictfp 13y agoHmm. 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?
- barrkel 13y agoYes; 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.