5 ms·

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications. Would you tolerate a text editor that asked you to confirm each letter you typed?

pmiller2 8y ago
Some actions aren’t undoable.
- amelius 8y ago
  "Launch missiles" is the prototypical example, although in reality I hope there is some sort of undo functionality.
  - pmiller2 8y ago
    "Send email" is a more mundane example that's actually likely to occur in real apps.
    - ReverseCold 8y ago
      Some email software (notably, Gmail) allows you to undo by delaying the actual send for a few seconds.
amelius 8y ago
You're assuming there is no useful purpose for the dialog box other than asking the user to confirm their action.
dpark 8y ago
1. Side effects may be permanently destructive, making Undo infeasible. How do you undo emptying the recycle bin? How do you undo posting a cert on the public internet? 2. Cancel is not just for “are you sure”. It’s often there for “never mind, let me go back”, as in the file open dialog example.
ggg9990 8y ago
Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.
- lewisinc 8y ago
  It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.
  - jeremiep 8y ago
    Anything where your app state is modelled as a series of actions over immutable data, undo and replay will be essentially free to implement :)
    - blackenough 8y ago
      destructive updates to your universe, or actions with side effects (anything regarding io) might not be recovered by a simple state management. delete my account, charge my credit card, add a friend, delete a friend...
      - jeremiep 8y ago
        But that is precisely how undo is currently implemented most of the time. Its a series of actions where you know how to undo the side-effects, or you know it was a destructive update and you just skip the undo of that step. Where I have issues with that is it usually feels like an afterthought rather than a first-class feature. If you instead model your application after an event log then your current state is just a fold over these events. You have the same list of actions you previously had to manage undo, but now its positioned at the very center of the architecture. And then you start seeing emergent features of that design: - you can time travel the UI's state, which is probably the best debugging tool you can have for UIs. - you can replay the event log over fixed application code, which greatly decrease iteration times. - it moves logic outside of the UI components, making the app easier to unit test. - you're storing a sequence of intents rather than results; its effectively free to audit such a design, its convenient to report the last X actions performed with a bug report and more precise than asking the user what they were doing. The list goes on and on. I believe most of the complexity in applications is generated from the fact there is very little synergy between the different features of these applications. If everything requires a different abstraction and set of indirections, then you're just accreting complexity over time. If you have a design where features can emerge from it, its usually a safe-bet to say you're on to something :)
dnaf 8y ago
a mechanism to undo the change. hmmmm. a button that takes you back. some sort of... back button?
- kchr 8y ago
  I feel like you're on to something here!
oneeyedpigeon 8y ago
If I write a sentence in my editor, then change a preference setting, then click 'undo', should that undo my typing or the preference change? I feel like a global 'undo last action' would be very confusing, but how else would you get rid of 'cancel' everywhere?

pmiller2 8y ago

Some actions aren’t undoable.

amelius 8y ago
"Launch missiles" is the prototypical example, although in reality I hope there is some sort of undo functionality.
- pmiller2 8y ago
  "Send email" is a more mundane example that's actually likely to occur in real apps.
  - ReverseCold 8y ago
    Some email software (notably, Gmail) allows you to undo by delaying the actual send for a few seconds.

amelius 8y ago

You're assuming there is no useful purpose for the dialog box other than asking the user to confirm their action.

dpark 8y ago

1. Side effects may be permanently destructive, making Undo infeasible. How do you undo emptying the recycle bin? How do you undo posting a cert on the public internet? 2. Cancel is not just for “are you sure”. It’s often there for “never mind, let me go back”, as in the file open dialog example.

ggg9990 8y ago

Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.

lewisinc 8y ago
It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.
- jeremiep 8y ago
  Anything where your app state is modelled as a series of actions over immutable data, undo and replay will be essentially free to implement :)
  - blackenough 8y ago
    destructive updates to your universe, or actions with side effects (anything regarding io) might not be recovered by a simple state management. delete my account, charge my credit card, add a friend, delete a friend...
    - jeremiep 8y ago
      But that is precisely how undo is currently implemented most of the time. Its a series of actions where you know how to undo the side-effects, or you know it was a destructive update and you just skip the undo of that step. Where I have issues with that is it usually feels like an afterthought rather than a first-class feature. If you instead model your application after an event log then your current state is just a fold over these events. You have the same list of actions you previously had to manage undo, but now its positioned at the very center of the architecture. And then you start seeing emergent features of that design: - you can time travel the UI's state, which is probably the best debugging tool you can have for UIs. - you can replay the event log over fixed application code, which greatly decrease iteration times. - it moves logic outside of the UI components, making the app easier to unit test. - you're storing a sequence of intents rather than results; its effectively free to audit such a design, its convenient to report the last X actions performed with a bug report and more precise than asking the user what they were doing. The list goes on and on. I believe most of the complexity in applications is generated from the fact there is very little synergy between the different features of these applications. If everything requires a different abstraction and set of indirections, then you're just accreting complexity over time. If you have a design where features can emerge from it, its usually a safe-bet to say you're on to something :)

dnaf 8y ago

a mechanism to undo the change. hmmmm. a button that takes you back. some sort of... back button?

kchr 8y ago
I feel like you're on to something here!

oneeyedpigeon 8y ago

If I write a sentence in my editor, then change a preference setting, then click 'undo', should that undo my typing or the preference change? I feel like a global 'undo last action' would be very confusing, but how else would you get rid of 'cancel' everywhere?