3 ms·

I've reached for a pop-up and stopped using them exactly because of the "nobody reads this" problem. What's the alternative when you have a potentially dangero

I've reached for a pop-up and stopped using them exactly because of the "nobody reads this" problem. What's the alternative when you have a potentially dangerous action that you need to give the user fair warning about?

lazide 1y ago
<blink/> tag? (/s)
kragen 1y ago
You make it possible to undo the action! In rare cases that's not possible; four that I know of: - the action is controlling something in the physical world such as a CNC milling machine, or - the action involves acting on somebody else's computer, for example sending an email, or - the action involves securely deleting information so that future adversaries who obtain your data storage medium can't recover it, or - data storage space is so limited that you don't have room to log an undo record. Obviously none of those were the case here, but when there are, there are well-known techniques for reducing the risk. For example, you can include by default a "cooling off" period to cancel the email send in or restore from nightly backups, or figure out how to do a "dry run" without a cutting tool in the chuck to see if it looks like your CNC program is going to smash the mill. You can put a molly-guard over inevitably destructive actions; that's why the IBM PC's reset keystroke is a three-key chord, and Emacs asks for you to type "yes" or "no" rather than "y" or "n" in certain cases. (Although in many of Emacs's cases, being able to undo would have been better. Freeing up the memory of a closed buffer with unsaved changes, for example, could almost always wait a few minutes!) It's also important in such cases for the user to be able to clearly see all the relevant information.
- kragen 1y ago
  This should read "but when there is such a case" and "in which to cancel the email send".
scotty79 1y ago
You could simulate the destructive actions instead of asking beforehand and make user confirm all destructive action before proceeding to actually executing them.
WorldMaker 1y ago
In this specific case it seems a particularly poor implementation of a classic ordered and/or nested Checklist. If the order matters, remind people checking later steps that they missed a previous step. If nesting matters and there's some if->then logic in the checklist based on the answer, add more checklist steps as necessary. If neither the order or the nesting matters, then why is it a modal step?

lazide 1y ago

<blink/> tag? (/s)

kragen 1y ago

You make it possible to undo the action! In rare cases that's not possible; four that I know of: - the action is controlling something in the physical world such as a CNC milling machine, or - the action involves acting on somebody else's computer, for example sending an email, or - the action involves securely deleting information so that future adversaries who obtain your data storage medium can't recover it, or - data storage space is so limited that you don't have room to log an undo record. Obviously none of those were the case here, but when there are, there are well-known techniques for reducing the risk. For example, you can include by default a "cooling off" period to cancel the email send in or restore from nightly backups, or figure out how to do a "dry run" without a cutting tool in the chuck to see if it looks like your CNC program is going to smash the mill. You can put a molly-guard over inevitably destructive actions; that's why the IBM PC's reset keystroke is a three-key chord, and Emacs asks for you to type "yes" or "no" rather than "y" or "n" in certain cases. (Although in many of Emacs's cases, being able to undo would have been better. Freeing up the memory of a closed buffer with unsaved changes, for example, could almost always wait a few minutes!) It's also important in such cases for the user to be able to clearly see all the relevant information.

kragen 1y ago
This should read "but when there is such a case" and "in which to cancel the email send".

scotty79 1y ago

You could simulate the destructive actions instead of asking beforehand and make user confirm all destructive action before proceeding to actually executing them.

WorldMaker 1y ago

In this specific case it seems a particularly poor implementation of a classic ordered and/or nested Checklist. If the order matters, remind people checking later steps that they missed a previous step. If nesting matters and there's some if->then logic in the checklist based on the answer, add more checklist steps as necessary. If neither the order or the nesting matters, then why is it a modal step?