5 ms·
I don't really understand how it is part of the problem. If the worker really believed an attack was incoming, confirmation screens wouldn't help at all.
by rhino369 9y ago
I don't really understand how it is part of the problem. If the worker really believed an attack was incoming, confirmation screens wouldn't help at all.
- bearcobra 9y agoI guess it would depend on how that confirmation screen worked. If the design asked for a confirmation from a second user, then a single user's confusion wouldn't have resulted in the error.
- jeddawson 9y agoNot only that, but once they realized the message was sent in error they didn't have a simple way to correct course so there was a big delay between the realization and informing the terrified public. Your suggestion of having multiple user confirmations coupled with a simple way to "cancel and correct" the notice would have likely meant this never became news worthy.
- paulddraper 9y agoSure, but that's a lot different from "move these buttons around and have the user double click to be sure."
- jsjohnst 9y agoThe extra confirmation shouldn’t have been on the same user. The “two man rule” exists for emergency protocols for a reason.
- krapp 9y agoConfirmation screens might have given the operator a moment's pause to consider whether or not they were certain. A UI that makes it easy to make a mistake, even when the mistake is intended, and makes it almost impossible to correct that mistake, is a badly designed UI.
- dragonwriter 9y ago> Confirmation screens might have given the operator a moment's pause to consider whether or not they were certain. There was a confirmation screen. I have seen no suggestion how a different confirmation than actually existed would have helped, and I don't think we want to introduce more delay in the critical path of a live alert without clear and massive benefit. > A UI that makes it easy to make a mistake, even when the mistake is intended, and makes it almost impossible to correct that mistake, is a badly designed UI. The problem with correcting the mistake is not a UI problem, but a deeper planning and procedure problem.
- krapp 9y ago> and I don't think we want to introduce more delay in the critical path of a live alert without clear and massive benefit. If that delay reduces false alarms, when false alarms erode public trust in and concern about the alert system, then the massive benefit is clear. With such a system, drills and tests are going to be massively more common than actual events. Designing the UI so that the one-in-a-million option is as easy to invoke as the once-every-week option is a UI problem. Notwithstanding it not being a primary issue in this particular case, I believe it's still an issue worth discussing. Also, bear in mind that correcting the "deeper planning and procedural problems" would introduce delays as well. Anything but a purely automated system, or a big red button would introduce some delay.
- dragonwriter 9y ago> Also, bear in mind that correcting the "deeper planning and procedural problems" would introduce delays as well No, it wouldn't, because those are problems that impact after an alert is issued, and whose existence caused delays in sending an all-clear. Resolving them won't effect the path prior to an alert, and would eliminate rather than introduce delays.