3 ms·

It sounds like you found the solution, you just made it really cumbersome: undo. All confirmation dialogs should be replaced with undo. The happy path has lowe

It sounds like you found the solution, you just made it really cumbersome: undo. All confirmation dialogs should be replaced with undo. The happy path has lower friction, and in case of a mistake they'll heave a huge sigh of relief. When possible, it's better in all cases for all users, whether novices or power users. And many things that at first blush seem like undo isn't possible, are actually easy to make undoable with a simple tweak: deleting data? Don't actually delete it until 24 hours later. Sending an email? Wait 10 seconds to actually send it, similar to Gmail's Undo Send.

stickfigure 6y ago
Implementing soft-delete is much easier than "soft-update", which is what this would have been.
- eru 6y ago
  You could still wait 10 seconds, and have a 'fake' undo button that aborts. (You can even put up a progress bar to pretend you are doing work during those 10 seconds.) That's purely a UI element and is completely independent of how the actual destructive operation is implemented in the backend nor how hard it would be to reverse.
  - laughinghan 6y ago
    I don't think that would be much better than a confirmation dialog that makes you wait 10 seconds before you can click OK. It's often only after clicking around and seeing the resulting changes that it sinks in that a mistake was made, and they reach for Undo. And that would add just as much friction to the happy path.
    - eru 6y ago
      It can be much better than the confirmation dialog, because it's meant to be implemented in such a way that you can get on with the rest of your work while the undo-countdown is ticking. From personal experience with gmail's fake undo, in terms of things sinking in, it works almost as well as regular undo for me; and not like a confirmation dialog (which doesn't work at all). So there's less friction, there's no extra click you need to make after ten seconds. And, also from personal experience, the force-delayed confirmation dialog I've used (I think in Chrome and Firefox for certain actions), don't seem to lead me to thinking at all. At least not any better than a regular confirmation dialog. But in any case, all these are empirical questions, and it would be interesting to run a little user study with the different options, instead of endless speculation.
      - stickfigure 6y ago
        Gmail is a pretty specific case - email is fundamentally asynchronous and "delay send" for something that's already scheduled is straightforward. Imagine trying to apply this undo to a bulk add/remove labels operation. Once you've committed the transaction, there is no simple 'undo'. It's possible to build a system capable of undo, sure, but you're talking about a lot of upfront work and complexity. Plus a fairly exotic database schema.
        eru 6y ago
        I don't see the problem? I would imagine you would stick all your UI actions in something like a log, and then only apply that log to your actual data with a delay? But not sure whether you call that 'a lot of upfront work and complexity'? Perhaps I'm a bit blind, because I come from a part of the programming world that's very keen on persistent datastructures, where undos are trivial to implement. (https://en.wikipedia.org/wiki/Persistent_data_structure https://en.wikipedia.org/wiki/Persistent_data_structure)
        laughinghan 6y ago
        There's nothing exotic about it, you just need an OLAP rather than OLTP database schema: https://en.wikipedia.org/wiki/OLAP_cube https://en.wikipedia.org/wiki/OLAP_cube
- laughinghan 6y ago
  Yeah, unfortunately in some cases if you didn't plan for it from the beginning it's not easy to tack on later. In my opinion, it's usually worth it though. You only hear from the folks asking you to restore things from backup—you won't hear from the folks who experience unnecessary friction and tell their friends or coworkers "it's okay, it works, it's kind of annoying to use though, I can't put my finger on anything specific".
AstralStorm 6y ago
Unless you're actually trying to do a huge synthetic operation where info would choke, e.g. creating an archive while removing existing files. That one is still possible to undo, just slower and more expensive... Then there are fun ones like Windows update holding 20 GB of insufficient undo, mechanical or hardware failures induced by extra load, and how to decide where an operation ends.

stickfigure 6y ago

Implementing soft-delete is much easier than "soft-update", which is what this would have been.

eru 6y ago
You could still wait 10 seconds, and have a 'fake' undo button that aborts. (You can even put up a progress bar to pretend you are doing work during those 10 seconds.) That's purely a UI element and is completely independent of how the actual destructive operation is implemented in the backend nor how hard it would be to reverse.
- laughinghan 6y ago
  I don't think that would be much better than a confirmation dialog that makes you wait 10 seconds before you can click OK. It's often only after clicking around and seeing the resulting changes that it sinks in that a mistake was made, and they reach for Undo. And that would add just as much friction to the happy path.
  - eru 6y ago
    It can be much better than the confirmation dialog, because it's meant to be implemented in such a way that you can get on with the rest of your work while the undo-countdown is ticking. From personal experience with gmail's fake undo, in terms of things sinking in, it works almost as well as regular undo for me; and not like a confirmation dialog (which doesn't work at all). So there's less friction, there's no extra click you need to make after ten seconds. And, also from personal experience, the force-delayed confirmation dialog I've used (I think in Chrome and Firefox for certain actions), don't seem to lead me to thinking at all. At least not any better than a regular confirmation dialog. But in any case, all these are empirical questions, and it would be interesting to run a little user study with the different options, instead of endless speculation.
    - stickfigure 6y ago
      Gmail is a pretty specific case - email is fundamentally asynchronous and "delay send" for something that's already scheduled is straightforward. Imagine trying to apply this undo to a bulk add/remove labels operation. Once you've committed the transaction, there is no simple 'undo'. It's possible to build a system capable of undo, sure, but you're talking about a lot of upfront work and complexity. Plus a fairly exotic database schema.
      - eru 6y ago
        I don't see the problem? I would imagine you would stick all your UI actions in something like a log, and then only apply that log to your actual data with a delay? But not sure whether you call that 'a lot of upfront work and complexity'? Perhaps I'm a bit blind, because I come from a part of the programming world that's very keen on persistent datastructures, where undos are trivial to implement. (https://en.wikipedia.org/wiki/Persistent_data_structure https://en.wikipedia.org/wiki/Persistent_data_structure)
      - laughinghan 6y ago
        There's nothing exotic about it, you just need an OLAP rather than OLTP database schema: https://en.wikipedia.org/wiki/OLAP_cube https://en.wikipedia.org/wiki/OLAP_cube
laughinghan 6y ago
Yeah, unfortunately in some cases if you didn't plan for it from the beginning it's not easy to tack on later. In my opinion, it's usually worth it though. You only hear from the folks asking you to restore things from backup—you won't hear from the folks who experience unnecessary friction and tell their friends or coworkers "it's okay, it works, it's kind of annoying to use though, I can't put my finger on anything specific".

AstralStorm 6y ago

Unless you're actually trying to do a huge synthetic operation where info would choke, e.g. creating an archive while removing existing files. That one is still possible to undo, just slower and more expensive... Then there are fun ones like Windows update holding 20 GB of insufficient undo, mechanical or hardware failures induced by extra load, and how to decide where an operation ends.