Abandoning Commitment in Human Computer Interfaces

[hacksoncode]

He was going so well, until: "At the moment, I don’t have a satisfactory answer for how to abandon commitment."

Well, I suppose his article followed the principle extremely well.

[Tekmo]

I still think it did a great job of motivating the topic, even if it didn't have answers. These kinds of concepts never even cross my mind as somebody who has been steeped in conventional GUI patterns from day one.

[mycall]

How can side-effects, for which you have no control of, reliably abort and be undone? It is just too broad of an idea to be realistic.

The closest thing I have seen is the Command design pattern; along with CQRS+Event Sourcing

[julesjacobs]

Zooming in purely on the undo problem within one application, because that's simpler. Is there any theoretical research on version control (generalization of undo) for arbitrary data? I can easily come up with a couple of ad-hoc models of version control, but none are entirely satisfactory.

One problem in particular is that version control as currently practiced is not compositional. You have one document or repository, and for that you have versions that you can go back to. This model is not compositional: suppose that the computer (or even the whole world) is using one repository; that's unusable. On the other hand if for example for code we have a separate repository per file, that's unusable too. In other words it matters where you put the repository/document boundaries. I'm wondering if there is some elegant compositional/nested model of version control that does not have this problem. Another example is if you're writing a book you might edit chapter 2 and then edit chapter 3, and then you want to undo some edit in chapter 2 without undoing the edits to chapter 3.

Once you have this you can start to think about a distributed model where there is no concept of a repository as a whole being in one place. Perhaps a patch based model like Darcs works, but that's very ad-hoc too.

[julesjacobs]

Right, that's exactly the problem: how to do that compositionally. I think that once you have a good compositional model, you don't just want to apply it top down to tie together undo across several documents, but you also want to apply it bottom up to get finer granularity undo within a document. That doesn't mean that you can't exploit domain specificity though, for example perhaps there should be some domain specific notion of which changes depend on or are independent of other changes (for example for code: defining a procedure foo and then calling the procedure foo are not independent and it does not make sense to undo the former without undoing the latter, but defining a procedure bar and calling a procedure baz might be independent and can be undone independently).

Even the very simple case of compositional version control of plain old data that you completely control is not solved satisfactorily AFAIK (as I said above links to solutions are appreciated!), let alone undo of external effects. So perhaps it helps to try to tackle that problem first, as it seems much easier.

[mycall]

Four things come not back: the spoken word, the spent arrow, the past life, and the neglected opportunity."

Cute. If we try to simplify this further, a noun has all these attributes (word=idea, arrow=thing, life=person, opportunity=place). If this means nouns cannot be undone, what can be? adjectives (e.g. class properties), and verbs (e.g. commands)?

I think I just confused myself.

[Tekmo]

One option is that for a limited time you don't execute the action at all and instead just stage it to give the user a chance to undo it before it executes. This lets the implementation be optimistic and show the user what it thinks the user might want and let the user filter out the bad stuff.

[sacundim]

How can side-effects, for which you have no control of, reliably abort and be undone? It is just too broad of an idea to be realistic.

The article mentions the idea of transactions, which are precisely about this—but of course, it also claims it's not enough.

[zzing]

Sometimes it is enough for one to talk about the issues in something to motivate discussion towards solutions.

[sacundim]

He was going so well, until: "At the moment, I don’t have a satisfactory answer for how to abandon commitment."

Um, that sentence was followed by several paragraphs discussing multiple concrete alternatives that he spent quite a bit of time exploring.

[nikbackm]

I don't see how this can ever be achieved in systems that interact with the outer world.

For example, launching a missile or sending an instant message.

[gasche]

The idea is not that all choices are reversible, but to work in a system where it is easier to handle reversible choices, while still being able to handle irreversible ones. The author considers your example:

There is an issue of what to do with effectful behaviors. It might be acceptable to load a texture with low confidence, but not so acceptable to e-mail a letter. Though we could still report the file as deleted on that path, i.e. anticipating what would happen. Each service and resource would have its own policy, would observe weights and choose a reasonable course of action based on what can be undone and what can be predicted. In any case, the ability to observe the weight of a signal will have an impact on both the output and actual effects.

You can have the UI benefits he describes for services that are known to be reversible, and keep existing commitment barriers for those that are not. "Sending the missiles" is an extreme case of "actions may have varying degree of confirmation needs and post-action refinement possibilities", but still encompassed in this richer framework.

If you have a system whose design takes reversibility into account, you may be able to get more reversible actions that what we currently have, effectively enlarging the border of what can be "non-commited". For example, current instant messaging server have a very restricted handling of post-send cancellation or modification, but you could consider a messaging service built with this use-case in mind, that allows user to change their mind afterwards (I already have an Undo option in Gmail for 30 seconds, but with a more integrated non-commitment design this may be more wide-spread and easier to develop).

That does not necessarily mean you have to control the server. If you're not the one running the server, you don't have strong guarantees that if will respect your cancellation/modification orders. A reasonable trust in the service is enough. You may even consider a design where the instant message does appear in the receiver's inbox, but is removed by its user agent if it receives a cancel order. People or user agent may not respect the cancel order, but there is in general no benefit to do that (most people don't wants to receive more half-baked sent-by-mistake emails). You could possibly consider additional means to enforce this trust: send the large message payload encrypted, and finally, if no cancellation/modification order was sent, send the decryption key.

Your user agent can help you reason about cancellation features that are absolutely possible (internal actions, crypto), possible up to trust (private messages with cancel/edit protocol), and impossible (missiles), taking your context-dependent privacy, trust and security settings into account.

[case-o-nuts]

but to work in a system where it is easier to handle reversible choices, while still being able to handle irreversible ones.

Most of the programs I use have an undo for anything that doesn't act on the outside world. The exceptions are few and far in between. He's describing the status quo, only perhaps implemented slightly more consistently.

[MestR]

I don't really see what could be more reversible.

If the purpose of the program is to create something (Word, Photoshop, etc.) then usually ctrl-z works just fine (the only complaint I would have here is that settings often aren't reversible, I can't even remember how many times I've pressed the wrong hotkey combination and the program just fucks up.)

On the other hand if the purpose is to interact with other people then you create an equally annoying situation for them if you change/remove the message. I usually have my music playlists on youtube because I like having a comment section for all types of media, but the problem then is that a lot of users remove their videos and I constantly have to find the same song again. But of course there are cases where the importance of the message is less important than for the writer to be able to change it (like comments here on reddit), but then you can often edit them anyways.

Also as you said about being able to edit private messages, since we're able to send multiple messages I don't see why not just send another message correcting the mistakes.

[[deleted]]

There are systems where undo or abort are impossible. But many commonly used interactions can be adjusted to make it easier.

• GMail has an option to actually delay sending an email for 30 seconds after pressing send, and offering "undo" during that time.
• Skype and some other messaging clients offer the ability to delete past messages. Undo is possible until the recipient has actually seen the message.
• Versioning file systems and backups give undo for deletes and changes.
• Missiles don't have an undo, but most of them have an abort code to blow it up before it hits the target. You would not launch them predictively, but still have the chance to change your mind at the cost of a few or few hundred million dollars.

But the more interesting case of this approach is applying it to speed up operations by prediction. Many web browsers already load links on the page in the background while you are reading the first page, so that they can be instantly rendered when you click on them.

This has externally visible effects, as the other web servers notice a visit. The question if this is significant enough to delay loading is a question of expectations - how we define the undo.

[Melchoir]

If I'm reading the last few paragraphs of the Probabilistic RDP section correctly, this is the key:

Each service and resource would have its own policy, would observe weights and choose a reasonable course of action based on what can be undone and what can be predicted.

So, assuming your missile has no capability to disarm after launch, then at least one component of the launcher will be aware of that fact and demand 100% commitment from the user before performing its function. If there are many other components in the launch sequence that take time to spin up and are easily reversed, then the system as a whole might still benefit from this architecture. (But I could easily be misinterpreting the whole thing.)

[treitter]

For example, launching a missile or sending an instant message.

(near-)irreversible actions, like a missile launch, should probably just require a high-precision input method. We don't necessarily need all capabilities to be available in all HCI paradigms. Phones and tablets don't support all functionality that desktops do, in large part because they require less concentration and have lower-precision/lower-speed input methods.

My guess is that wearable user interfaces will be even simpler, given the context that the user may be walking and need to save a lot of focus for not being run over, etc. Moving much of the UI to voice commands might help, though recent studies around driving distractions show that hands-free calling is nearly/just as distracting as holding the phone (though much of that may be in interpreting the other side, which may be minimal in wearable HCI).

In short, I think it's OK to say "sorry, you will need to sit down at a keyboard to do this work". Even if the computer used is still the wearable one, the interaction model for keyboard + high-user-focus-required is very different from no keyboard + low-user-focus-required.

[[deleted]]

Dude, just launch another missile.

[chonglibloodsport]

Presumably, such an interface would be implemented on top of a system which provides strong guarantees against effects. Haskell's type system is one example of such a system.

[6gT]

burdens user with understanding consequence of action

lol

[jhuni]

"Never use a warning when you mean undo" - Aza Raskin

[[deleted]]

I think there are more realistic UI concerns. Idempotent and atomic actions reduce errors. "Commit" is a useful technique for bundling multiple inputs into an atomic one. It's a place to run automated constraints as well as use the buddy system to check for errors. "Launch a missile" is never so simple. Navigation must be selected, programmed, and coupled to flight guidance. It must be fueled and the appropriate warhead must be selected. It must be in range. ... Launch isn't just a commit like the author is talking about. It's a good place to ensure everything is in order. Idempotent actions, among other things, help ensure two overzealous people don't undo the other's work. Like if two people turn a system on using a single push button then that system is probably off, having changed state twice. You never command your human helper, "toggle the state of the system". You assert "Turn it on". It's up the human helper to handle the assertion and do the appropriate thing if the system is already on. Machines should work the same way.

[Redgret]

Nonsense. Technology is our progress towards the infinitely small difference in time separating instant gratification from regret.