Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The screen that set off the ballistic missile alert on Saturday

twitter.com

Post reply on HN
Print view View original

191–200 of 375 posts

Re: The screen that set off the ballistic missile alert on Saturday

#191

Post by hopeless »

sjs382 wrote: post #114

https://blog.codinghorror.com/the-opposite-of-fitts-law/ In the cockpit of every jet fighter is a brightly painted lever that, when pulled, fires a small rocket engine underneath the pilot's seat, blowing the pilot, still in his seat, out of the aircraft to parachute safely to earth. Ejector seat levers can only be used once, and their consequences are significant and irreversible. Applications must have ejector seat…

There's a lot we can learn from aviation: accident retrospectives, checklists, master caution alarms, crew relationship management, human factors research, etc.

However, my knowledge of these things is a bit piecemeal and anecdotal. Does anyone know a good book on these things?

Re: The screen that set off the ballistic missile alert on Saturday

#192

Post by blhack »

sjs382 wrote: post #114

https://blog.codinghorror.com/the-opposite-of-fitts-law/ In the cockpit of every jet fighter is a brightly painted lever that, when pulled, fires a small rocket engine underneath the pilot's seat, blowing the pilot, still in his seat, out of the aircraft to parachute safely to earth. Ejector seat levers can only be used once, and their consequences are significant and irreversible. Applications must have ejector seat…

Hey that text block is unreadable on mobile. Here it is readable

>In the cockpit of every jet fighter is a brightly painted lever that, when pulled, fires a small rocket engine underneath the pilot's seat, blowing the pilot, still in his seat, out of the aircraft to parachute safely to earth. Ejector seat levers can only be used once, and their consequences are significant and irreversible.

>Applications must have ejector seat levers so that users can "occasionally" move persistent objects in the interface, or dramatically (sometimes irreversibly) alter the function or behavior of the application. The one thing that must never happen is accidental deployment of the ejector seat.

>The interface design must assure that a user can never inadvertently fire the ejector seat when all he wants to do is make some minor adjustment to the program.

Several indents like that make code blocks, which respect original new line placements and are usually unreadable on mobile.

Re: The screen that set off the ballistic missile alert on Saturday

#193

Post by Chaebixi »

daveid wrote: post #157
7952 wrote: post #134

Earlier quoted context omitted.

Why not just make them type the message out manually every single time? Why is it a good idea to offer options at all?

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 mere "button pushing clerk" operating a system like this? IMHO, it should be operated by someone with some training and authority.

Re: The screen that set off the ballistic missile alert on Saturday

#194

Post by peterbraden »

One problem with interfaces like this is that they are an abjection of ownership. The situation probably doesn't warrant a dedicated designer, and the developer who make it, probably thought 'I'm not a designer, that will do'.

The amount of times I've heard 'Just add a button to do it' from 'backend developers'..

The point is, software is there to serve a user, and if you can't envisage the user using the software, then you don't understand the requirements. It's not a design question.

Too much responsibility is deferred as 'design' when it's actually a fundamental part of solving the problem at hand.

Not that design isn't also important, but the perception that usability == design needs to change.

Re: The screen that set off the ballistic missile alert on Saturday

#195

Post by bogomipz »

What is the provenance of this image? How do we know this is real? While UI/UX designers are falling all over themselves with their meme fest I didn't see any reference for the source of this image.

If you read the Washington Post account, it says the interface was a drop down menu of which this picture is not of. See:

https://www.washingtonpost.com/news/post-nation/wp/2018/01/1...

And perhaps not surprisingly some news outlets are using an unverified image from a tweet as a news story.

Re: The screen that set off the ballistic missile alert on Saturday

#196

Post by Blazespinnaker »

Cthulhu_ wrote: post #190
MicroBerto wrote: post #178

For those of you who don't believe a single thing we're being told about this situation -- including this screenshot -- just know that you're not alone. You don't need to question the narrative publicly like some of us do, but it's always good to keep an open mind about everything we're told, and sadly, that means considering the possibility that there have been more lies than truths told since Saturday. Hopefully so…

Are you suggesting that there may have been a real attack but it's being kept quiet (by idk, the Deep State, lizard people, round-earth conspiracists, etc?)

Or that it was done for political purposes.

Re: The screen that set off the ballistic missile alert on Saturday

#197

Post by Chaebixi »

Cthulhu_ wrote: post #189
walshemj wrote: post #130

Earlier quoted context omitted.

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:

http://conelrad.blogspot.com/2010/09/code-word-hatefulness-g...

> …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.

Re: The screen that set off the ballistic missile alert on Saturday

#198

Post by Omnius »

pc86 wrote: post #71
whatever_dude wrote: post #19

It's easy to see how this is bad, and I bet dozens of designers are now creating alternatives for their dribble and Twitter appreciation, but the problem is probably what led to this, not this specifically. I can see it: a contractor started with a link that triggers a push notification, then someone requested another link, then another, then it grew from there, never having the ability to stop and rethink this from…

As a government contractor who did not work on this, I can say I'd bet a lot of money that this is how this screen came about. Initially launched 2-10 years ago with 1-2 links, fast forward a bit and we have this. I can hear a forward thinking developer saying "hey should we at least have colored buttons or something on this screen so it's easy to see what is a test and what is not?" and the product owner/business ow…

They could have just an a confirmation window with the the text that was about to be sent.

"Everyone is going to die. Run but it won't help"... Is that want you wanted to send [Yes] [No]

Re: The screen that set off the ballistic missile alert on Saturday

#199

Post by astura »

Y_Y wrote: post #109
astura wrote: post #66

Earlier quoted context omitted.

Totally unscientific idea: 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.

And which Person would be Identified by such a Number?

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.

Re: The screen that set off the ballistic missile alert on Saturday

#200

Post by acdha »

naravara wrote: post #175
crispyambulance wrote: post #61

Earlier quoted context omitted.

It looks like quite a normal UI from an "internal" government or enterprise application point of view. In this case, the citizens of Hawaii paid for the bad system design with 48 minutes of existential horror. But these kinds of mistakes happens ALL THE TIME with "enterprise applications." Oracle has similar horrendous UX for their EBS (Enterprise Business Suite), so does SAP, Siemens, etc. People regularly make cost…

>It looks like quite a normal UI from an "internal" government or enterprise application point of view. The "normal" for enterprise and especially government software is dogshit though. It's because the people doing the procurement are not the people actually using the thing day to day. They treat UX and design as extravagances in the face of spec-sheets and slick marketing decks.

Or, more charitably, they're trying to balance a bunch of conflicting demands for requirements, budget, deadlines, etc.; the procurement process scares away the non-enterprise vendors; and they're not given enough budget to have in-house staff with enough expertise to meaningfully oversee it. If a big vendor says they'll handle it all and mount a huge PR push if anyone questions your decision, it's not hard to see why people opt to overpay.
Post reply on HN