The thing that annoys me most about this situation is people complaining about how long it took to send out the "Sorry, there was no missile" message. Just as I expected these were hard-coded messages that were sent out by a button (link) click and not a free-form text area. There are many (good) reasons you want your program set up this way (let's ignore the rest of the terrible UI/UX for now).
It makes complete sense to me that given a spec of "make a button send this specific text" you would end up with this. So it's very easy to send the initial message but sending a custom follow up requires contacting someone with access to the underlying system who can send a custom message.
In the same way that I may give internal users the ability to fire off SPECIFIC (maybe with placeholders) push notifications with the press of a button but not custom messages. Sure my underlying infrastructure can handle custom messages but the UI for such a feature does not exist (or at least is not available to the person who might have the ability to send preset messages).
All in all this was terrible for the people in Hawaii, no doubt. That said I WANT my missile alert system to be easy to activate to give people the most time I can to prepare. The best fix for this (yes a new UI/UX would be best but let's be realistic on how much time/energy they are willing to spend on this) would be a scary looking alert confirmation dialog of "Are you sure you want to send this alert to the whole state?" and maybe have to type a confirmation string.
That's useless then. That's the sort of dialog that trains users to ignore it because it offers no useful information.
There's a post just a short distance down that twitter thread to a simple layout change that would have made it difficult to choose the wrong option by simply categorizing the options properly. But I'm betting that list is autogenerated on a hardcoded template from some goddamn database somewhere in this enterprise app that makes a simple layout change like that a nightmare to implement.
When someone is in a crisis situation, their actions have to be the SAME as a drill. Making someone do or type something different when things are already hectic is likely to send them into brain-lock.
The solution is something extra that pops up AFTER doing everything the same that says "Sending real alert in 10 ... 9 ... 8 ..." with a "Type: "Abort" in text field to stop".
If the operator brain freezes whether real or fake, the alert still goes out in 10 seconds. If the operator screwed up but doesn't brain-freeze, he can stop the situation.
That's pretty much the best you can do if you're trying to make your drill and your alarm almost identical in order to maximize crisis performance.
I can imagine that when someone accidentally sends out a real alert, the "Oh F" moment will last longer than the 10 seconds you give the operator to type those 5 characters, in the correct order, with shaky fingers.
It has a similar list of alert "templates" as this one, but in addition it has a confirmation box with a radio button "send TEST only / SEND EAS LIVE", and if you select the "send live" option you must enter an authorization code.
It would be interesting to see what the rest of the user interface looks like, if the hawaii one has something similar.
Having to type out YES or some phrase is a fairly common "Are you really sure you want to do this??" sort of thing. I gather they're also looking at requiring a second person's confirmation which, if practical and very unlikely to make it impossible to send any message, seems reasonable as well.
I think I have read some research in healthcare field that such confirmations aren’t s helpful as you would think.
One reason of course is a combination of alarm fatigue and the fact that software has trained people to just always click yes when an annoying pop up appears.
Another is that people will think the have already clicked the correct thing button. So it’s less “Oh a confirmation box has appeared, let me confirm that I pressed the correct button” and more “stupid computer, of course I clicked the right button, that’s what I want to do!” without realizing they did in fact accidentally click the wrong button.
Having to type "YES" or "ALERT" would be useless, I agree. But having to type: "SEND A REAL ALERT" or something like that would probably be reasonably useful. The way GitHub prompts me before deleting a repo is a good example of a useful prompt. The text I have to type is the name of the repo being deleted.
That's fair. Typing something out helps somewhat with the confirmation reflex problem. (Essentially hitting OK or typing Y as almost a single motion with the original selection.) But you're right that, if you think you've selected the right thing especially in a high pressure situation under time pressure, you may well not read through the warning but just take whatever action is required to confirm.
Do you want a button pushing clerk to be able to write any message to millions of people over an emergency network? There is so much potential for disaster in that idea. Options is much better. Having the employee type out the predefined message word for word would really be a good confirmation though.
> Do you want a button pushing clerk to be able to write any message to millions of people over an emergency network?
Yes, in situations where the message does not fit within a pre-defined list due to an unexpected event. Of course it should still have security mechanism's to ensure that the transmission is properly authorised.
The biggest threat is probably misuse by politicians rather than the poor clerk!
You're conflating two different issues. My original suggestion was a mechanism to prevent the clerk from accidentally sending the wrong message. Typing out the entirety of the message hopefully would force them to realize what they're sending.
Allowing a separate option for a clerk, maybe with confirmation from a supervisor or other clerk, to send an arbitrary message (with a separate approval chain) would be useful as well. In the Hawaii situation not having that option likely delayed sending out the retraction as they didn't have a built in.
When deleting a repository in Gitlab, you are required to type the name of the repository in a field. This forces you to change the response based on the particular action.
More like when you delete/rename a github repo and they make you type our the repo name. I'm thinking of having to type something like "MISSILE INCOMING SEND ALERT" or similar.
Well if it was a proper test run (also to check procedures), the test too would have this extra confirmation.
Maybe changing the challenge to "HOLY FUCKING SHIT YES THERE REALLY IS A FUCKING NUKE COMING AT US SEND THE FUCKING MESSAGE!!!" in the real challenge would work better. Of course, when you have to push the button like that, I'm not sure if you could still type straight ;).
But yeah: how do you properly write a test for a potentially dangerous operation?
Have PINs required for certain critical operations and post those PINs in multiple places around the facility. Each PIN is different for each operation. That way the user has to look up the PIN before sending out the "you're going to die" message.
Part of the problem is that these need to be sent quickly. An in bound ballistic missile could have only several minutes of warning or less. Make it too difficult and you waste thirty second looking up a pin. That could kill tens of thousands of people who couldn't get away from windows in time.
I misspoke, PIN would be the wrong term, it would be an activation code.
The codes would be per action not per person. So the "send missile threat" activation code would be, for example, 98790 for everyone and the "test send missile threat" would be 16289 for everyone. You'd have to look up what the code was for your message you wanted to send. All test message start with 1 while all real messages start with 9. They could be rotating so employees don't memorize them.
So to send an alarm by mistake someone would need to press the wrong button and also look up the wrong code and also ignore the meaning of the code prefix.
Just an example.
Though maybe just "this is not a drill" would be better/easier.
I think Y_Y was trying to convey that PIN expands to Personal Identification Number, which does not apply if no specific person can be identified.
In any case, your proposal suffers from the flaw that in a real emergency, nobody will have the extra seconds to spare to look up a code, because that would literally be thousands of people dying per lost second, so the emergency codes will all rotate from '99999' through '99999'. And an employee would actually be responsible for changing the codes from '99999' to '99999' every time they are required to rotate.
I don't recall the source, so I'm not sure of the accuracy, but I read that this is what happened, the employee clicked through the confirmation screen.
Does the "drill" link also have a confirmation screen? Do the two confirmation screen look equal or they are different?
If they are equal (for example a generic message like "Are you sure?") then it's almost like no confirmation, because people get trained to click it automatically.
I think that ideally each one must have a "nice" image about the alarm, that is very different from the other images.
Another possibility is to force the user to retype the message, so the user must read and understand the actual message to be send. (Remember to disallow cut and paste.) (Allow a small number of typos, perhaps a Levenshtein distance of 4 or 5, because the user will be probably nervous if there are some incoming missiles.)
Something that comes to mind is Skyrim's legendary skill confirmation. When you go to reset a skill it prompts you twice if you really want to do it and the second confirmation has the yes/no switched and the default on no so if you are just clicking through it's easy to not reset the skill. You have to read and know what you are doing. But also, yes, the drill shouldn't prompt so it stands out when it does prompt.
In the this case nuclear alert it should be a big red button with a locked cover - do we know how many people died in the panic due to traffic accidents, heart attacks etcetera
How would you test whether the big red button with the locked cover still works though? I mean that's the kinda thing you don't want to see broken (mechanical failure, rust, etc), and these systems can remain unchanged for decades. You have to be able to test the real thing somehow, which gives a chance for accidental triggering.
> How would you test whether the big red button with the locked cover still works though?
Simple: you don't put the button behind the cover, you put the media with the scary message behind it. Then you can test the whole transmission system with less chance for mistakes.
Ironically, this was exactly the solution to the last big EBS failure, the "code word hatefullness" incident in 1971. Back then an operator had to load a tape into the transmitter, but one day he loaded the wrong one because the real and test tapes were stored next to each other. After the incident, they moved the tape to a different location:
> …In the past three tapes, one for the test and two for actual emergencies, were hanging on three labeled hooks above the transmitter… In the future only the test tape will be left near the transmitter. The two emergency tapes [will be] be sealed in clearly marked envelopes and placed inside a nearby cabinet.
Agreed - there really is no excuse, development-wise, for the UI being this poorly designed. 30 minutes of easy work could take this to a point where it would be unlikely somebody would make a mistake.
100% Agree, there are a million little things that could have been done differently/better. My point really was trying to focus on that the delay in follow-up was completely understandable (also unfortunate) and that there was definitely some low hanging fruit for improvement (your suggestions being chief among them). This is, however, the UI/UX use end up with when you produce a specific spec and farm it out to the lowest bidder.
According to the Twitter thread the option at the bottom of the list (False Alarm) was added as the fix to this problem. Making a reasonable UI was apparently not an option.
There's likely a CMS of some sort for adding messages, so adding a false alarm one probably just meant someone with admin access just needed to fill out a web form.
UI changes, even simple ones, would take a little longer.
You are more concerned about what you see as inappropriate criticism of one aspect of this UI design than you are by anything else in this debacle? I hope you will be able to broaden your horizon, if only because narrow perspectives were probably part of the problem, as they often are.
That's an interesting thing to be annoyed about given that a faster way to send out the false alarm notification is one of the mitigations they have put in place.
No, I'm annoyed that people seem to think people sat around doing jack shit for some 30+ minutes instead of sending out the false alarm message. I'm confident they were going as fast as they can and I don't like the blaming of the operator for what was a failing in the designed software. I'm not even sure I blame the people that wrote the software as I'm sure they were given a very specific spec of what it should do and they met the spec.
> The best fix for this (yes a new UI/UX would be best but let's be realistic on how much time/energy they are willing to spend on this) would be a scary looking alert confirmation dialog of "Are you sure you want to send this alert to the whole state?"
If I was in the operator's place I would probably send all the other messages as well so that people know the system didn't work and don't go commit crimes/suicides thinking the world is gonna end
I really don't get all the high levels of excuse in this thread. Think about the victims here: think about putting your (terrified) kid a storm drain. Really think about it, let the feelings about it sink in.
The only correct solution is to fire the person involved, as the next guy will look closer. Yeah maybe not fair, but when working with landmines you have to pay attention - and it is politically much more feasible than redesigning the system.
However I also object to that system in the first place, since it doesn't matter where you hide if a nuke falls close to you, and you probably don't want to survive.
Thinking about it. Also quite possible that the system could only handle so many messages a second.
But regardless of excuses it should never take that long to send that message. You are going to have people with PTSD for years over this.
I wished the state would be sued by every single person in the state -- I am sure than both the guy who clicked the link and the UI would be gone presto. Probably some sovereign immunity that stops that though.
It makes complete sense to me that given a spec of "make a button send this specific text" you would end up with this. So it's very easy to send the initial message but sending a custom follow up requires contacting someone with access to the underlying system who can send a custom message.
In the same way that I may give internal users the ability to fire off SPECIFIC (maybe with placeholders) push notifications with the press of a button but not custom messages. Sure my underlying infrastructure can handle custom messages but the UI for such a feature does not exist (or at least is not available to the person who might have the ability to send preset messages).
All in all this was terrible for the people in Hawaii, no doubt. That said I WANT my missile alert system to be easy to activate to give people the most time I can to prepare. The best fix for this (yes a new UI/UX would be best but let's be realistic on how much time/energy they are willing to spend on this) would be a scary looking alert confirmation dialog of "Are you sure you want to send this alert to the whole state?" and maybe have to type a confirmation string.