3 ms·

When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place. Instea

When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place. Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds. The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake. But more importantly - for each dialogue (of whatever kind) you have in an application, the chances of the user reading it declines by the square of the number of dialogues they encounter in a given session to the point where they will never be read, ever.

Symbiote 8y ago
That gives me an idea for my .bashrc: rm () { (sleep 30 && \rm "$@") & } (Untested, and I'm unlikely to use this.)
- alanning 8y ago
  I’ve seen it generally recommended to use a different command rather than aliasing `rm`. Pretty sure there are a plethora of options for each OS but here’s a couple: For OSX, homebrew has a handy “trash” command line tool [1]. For Ubuntu, trash-cli seems popular [2]. 1. `brew install trash` 2. http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1.html http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1...
- llcoolv 8y ago
  lol. good luck running a bash script that does a bunch of 'rm's.
  - jeremyjh 8y ago
    His aliases wouldn't be in scope there.
    - llcoolv 8y ago
      Thanks a lot! Here is a better explanation https://unix.stackexchange.com/questions/362546/what-is-the-scope-of-environment-variables-defined-in-bashrc https://unix.stackexchange.com/questions/362546/what-is-the-... . This seems like a decent gap in my knowledge. Is it still going to be out of scope if he e.g. runs the shell script from the shell?
      - jeremyjh 8y ago
        Not if the alias is in .bashrc / .zshrc and they execute the shell script in the normal way. If they source the script, sure. But no one runs scripts that way, for this exact reason.
jeremyjh 8y ago
I think this depends on the actual semantics of the delete. If the operation is truly non-recoverable, and you simply lie about doing it and do it after a delay, there is a chance you will be caught in that lie when your process is cancelled or failed for whatever reason. That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.
- ProxCoques 8y ago
  That may be your opinion. But 30 years of HCI research and recommendations on the subject say otherwise: https://en.wikipedia.org/wiki/Mode_(computer_interface)#Assessment https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse... https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/ https://asktog.com/atc/principles-of-interaction-design/
erichurkman 8y ago
Maybe for power users. Time based UI actions are not accessible, though. Novice users, elderly, those with lowered motor functions, etc will struggle with time-based interactions. In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."
- ProxCoques 8y ago
  That's not what the HCI research and general literature on this says. https://en.wikipedia.org/wiki/Mode_(computer_interface)#Assessment https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse... The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo. This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).
oldcynic 8y ago
I've never come across that recommendation before. I can't immediately think of a case where I'd want that or it would be anything but annoying. > 99.9% of people know what they're doing You have very different users than those of anything I've ever written then. :)
- Sylos 8y ago
  I think, Google recommends this for Android application development. Not that I would consider Google a shining beacon of great UIs. Well, and it is also much easier to quickly locate and hit an Undo-button on a small touch screen than it is with a mouse on a giant screen.
  - oldcynic 8y ago
    Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.
    - wtetzner 8y ago
      The only one that comes to mind is the GMail app. When you swipe to archive an email, it gives you an undo button. I have to say I don't particularly like that UI though. If I accidentally swipe, then I only have a few seconds to undo it. I'd prefer a screen that showed me actions I've performed in the past, and let me undo them. That way I wouldn't have to worry about the undo popup disappearing too quickly.
    - Sylos 8y ago
      The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples. But yeah, I definitely also see a lot more confirm-dialogs still. Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment. That is, if you are not a preinstalled app. If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files. Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.

Symbiote 8y ago

That gives me an idea for my .bashrc: rm () { (sleep 30 && \rm "$@") & } (Untested, and I'm unlikely to use this.)

alanning 8y ago
I’ve seen it generally recommended to use a different command rather than aliasing `rm`. Pretty sure there are a plethora of options for each OS but here’s a couple: For OSX, homebrew has a handy “trash” command line tool [1]. For Ubuntu, trash-cli seems popular [2]. 1. `brew install trash` 2. http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1.html http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1...
llcoolv 8y ago
lol. good luck running a bash script that does a bunch of 'rm's.
- jeremyjh 8y ago
  His aliases wouldn't be in scope there.
  - llcoolv 8y ago
    Thanks a lot! Here is a better explanation https://unix.stackexchange.com/questions/362546/what-is-the-scope-of-environment-variables-defined-in-bashrc https://unix.stackexchange.com/questions/362546/what-is-the-... . This seems like a decent gap in my knowledge. Is it still going to be out of scope if he e.g. runs the shell script from the shell?
    - jeremyjh 8y ago
      Not if the alias is in .bashrc / .zshrc and they execute the shell script in the normal way. If they source the script, sure. But no one runs scripts that way, for this exact reason.

jeremyjh 8y ago

I think this depends on the actual semantics of the delete. If the operation is truly non-recoverable, and you simply lie about doing it and do it after a delay, there is a chance you will be caught in that lie when your process is cancelled or failed for whatever reason. That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.

ProxCoques 8y ago
That may be your opinion. But 30 years of HCI research and recommendations on the subject say otherwise: https://en.wikipedia.org/wiki/Mode_(computer_interface)#Assessment https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse... https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/ https://asktog.com/atc/principles-of-interaction-design/

erichurkman 8y ago

Maybe for power users. Time based UI actions are not accessible, though. Novice users, elderly, those with lowered motor functions, etc will struggle with time-based interactions. In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."

ProxCoques 8y ago
That's not what the HCI research and general literature on this says. https://en.wikipedia.org/wiki/Mode_(computer_interface)#Assessment https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse... The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo. This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).

oldcynic 8y ago

I've never come across that recommendation before. I can't immediately think of a case where I'd want that or it would be anything but annoying. > 99.9% of people know what they're doing You have very different users than those of anything I've ever written then. :)

Sylos 8y ago
I think, Google recommends this for Android application development. Not that I would consider Google a shining beacon of great UIs. Well, and it is also much easier to quickly locate and hit an Undo-button on a small touch screen than it is with a mouse on a giant screen.
- oldcynic 8y ago
  Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.
  - wtetzner 8y ago
    The only one that comes to mind is the GMail app. When you swipe to archive an email, it gives you an undo button. I have to say I don't particularly like that UI though. If I accidentally swipe, then I only have a few seconds to undo it. I'd prefer a screen that showed me actions I've performed in the past, and let me undo them. That way I wouldn't have to worry about the undo popup disappearing too quickly.
  - Sylos 8y ago
    The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples. But yeah, I definitely also see a lot more confirm-dialogs still. Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment. That is, if you are not a preinstalled app. If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files. Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.