Wait, so all of the hand wringing over the crappy UI was pointless because it was actually a case of miscommunication?
So if earnestness is to rule the day, allow me to say that my point was more serious than mere pedantry. Because most of us here are software people living highly visual environments, and because our thinking is shaped by language that disproportionally based on visual metaphors, we tend to assume that "interfaces" are necessarily visual systems. They are not. They can be auditory and even tactile. If an audio message gives incorrect, contradictory, or badly-structured information, then that's no less an interface failure than a badly-designed web page. In this case, both the audio message and the alert interface shared a common point of failure: a deep, seemingly institutional inattention to how information is presented and interpreted. In both cases, doing a better job with the interfaces is hardly rocket science; that's not the interesting part of this fiasco. The interesting part is: why didn't the institutions care about this, how did the project managers fail to spot the problems, and how should this change procurement and management practices in the future?
Hopefully that's a bit less pedantic!
Being a mod has got to be tough: you're not allowed to look away from the assholes; you're required to look directly at them. After dealing with the 10,000th jerkwad, an optimistic reading of what anyone says has got to be challenging. So divergent readings are totally understandable, and thanks for the reminder that when using flippancy or sarcasm online, it's a good idea to telegraph one's amiable intent.
I'll never be shamed out of questioning clear nonsense.
What is confusing is that the article still points to the UI as being a part of the problem though while they're now saying the employee intentionally sent the live message. Looks like the PR campaign is still trying to deflect blame or perhaps keep things just ambiguous enough that they'll be able to rush through some extra spending to "fix" the UI issue.
Hopefully more details will continue being shared and they deal with the organizational flaws instead of pouring blame on scape goats (software and individuals).
Last time this happened, the story simply disappeared from the media altogether. Expect that to happen here too.
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.
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.
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.
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.
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.
So you look at all of the contributing factors and you come up with a plan for all the ones you can reasonably address.
It's been identified that a reasonable person could accidentally send a real alert even when they intended to send a fake one. So you fix that too because why the hell would you leave it once you've found it?
Or to put it another way, they're already in the middle of a PR disaster. You get a second one if the press gets wind of the idea that you're cutting stupid simple corners on the remediation. And make no mistake: Fixing a UI issue with the benefit of hindsight is a stupid simple fix (avoiding it to begin with is much harder).
https://en.wikipedia.org/wiki/Two-man_rule
What does Bob do when he goes to the toilet? He asks Steve to cover him.
So if you need 2 people to send an alert, when Bob is at the console, and Steve is secondary, when Steve has to go to the toilet, he asks Jill to cover him. Alternatively a backup authorization method could be used.
It does mean having 3 people available at all times, but since there are life-safety implications of real alerts as well as false alerts, it seems like a reasonable safeguard to have.