The screen that set off the ballistic missile alert on Saturday

Currently unscrewing one of those as my day job.

"Delete all production orders for period" - no confirmation, no ability to rollback (beyond me restoring from a backup) that kind of thing.

It's not that it isn't user friendly, it's that it is actively user hostile.

In the end, the correct process is probably have two people activate the alert, so that two people have to independently not read the dialog boxes or whatever to send a false alarm. But maybe that doesn't work either, I haven't done any research to that effect and don't really know.

On some level, I like the interface. There is a list of possible alerts, and you click the one you want to send to send it. It's just that it doesn't account for the possibility that the user doesn't ACTUALLY want to send the one they clicked. The same problem exists with any powerful tool. Hammers don't check that you're hammering a nail and not your thumb. Cars don't ask "there appears to be a pedestrian, are you sure you meant 'accelerate' and not 'brake'?" With great power comes great responsibility.

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.

Consumer software is chosen by people that actually use the software. They can see that it is shit, give it bad reviews etc.

I used to work at a very large company who use Teamcity (think git for CAD), which was the worst POS I have ever used. A 90s Java mess that was so slow you could watch it redrawing GUI controls in slow motion. Everybody that used it hated it. At least some of the higher ups liked it, but they didn't actually have to use it.

Such misteackes in the cockpit of an airliner are deadly, which is why a great deal of effort is expended to prevent such mistakes. Unfortunately,

1. bad UI design is usually only obvious in hindsight

2. doing good UI design is expensive, and not always worth the effort

Of course, I face the same sorts of issues in designing a programming language (D), so this topic is of continuing interest for me.

That requires a paper form. The payroll system in the state has failed to be upgraded for some 20 years or so of promises. Staff are paid via checks which are sent direct to their banks because they can't even pay over the wire.

Here's a good article about it: http://khon2.com/2015/05/11/costly-consequences-of-outdated-...

These 48 minutes may well have changed a whole bunch of people's lives for the better, in the long term.

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

The Test Records probably do the same thing just to a smaller list than the real one.

So there is no real way to separate them.

Accessibility becomes an issue for colourblind people then.

When I've been given PSDs in the past, either for review or for implementation, there's never been any documentation with any of the reasoning behind any of it. And when I've asked follow-up questions about why something was done the way it was, I've typically been met with either defensiveness or "that's how it is, now go and build it"

There had to have been quite the cavalcade of idiots behind the making of this system.

Actually, with government contracts, you are legally obligated to perform only the task assigned. Providing work to the government without the government paying for it is illegal. And you are only being paid for what's in the contract. (This is actually overall a good thing. Otherwise, large companies with better margins could easily provide free value-adds to government customers to win contracts away from small shops with small margins.)

Now, in this case, yes maybe the contractual item could have been interpreted in a way that allowed a proper page redesign. However, I would never state that as a fact without having the requirements and also receiving agreement from the government customer over such changes.

I've seen lots of organizations try to save a buck by extending a previously existing system with in-house labor after the original contractor asked for more money to do the change. I would bet that the original contractor (if they're still involved with the project) hasn’t seen that screen because it's some homebrew patch put in by whichever administrator babysits the machines for the state government.

The problem with organizations maintaining their own rogue patches is that, if those organizations had people compentent enough to make changes well, they wouldn't have hired a contractor or bought off the shelf in the first place.

But only to a point. People resist perceived change. You can improve the back-end all you want, as long as you don't make unexpected changes to the front-end. This includes something as simple as a clarifying pop-up, or a speed increase of a procedure.

  <H2> Testing </H2>
  ...
  <H2> FOR REAL </H2>
  ...

I'd be very surprised if the ultimate cost of this mistake isn't far higher than the added cost of adding an "Are you really sure?" confirmation option.

This is why you don't let accountants make cost decisions in a vacuum. Of course if you're counting beans, the cheapest option is best.

In reality-based accounting, the hidden costs, consequential costs, potential damages, and costs of failure guarantee that cheapest is risky if you're lucky, and suicidally expensive if you're not.

The GAP are not designed to analyse those costs, so stupid decisions are made, avoidable consequences occur, and ultimately money is wasted, not saved.

We're seeing the same thing in the UK now where a huge government services contractor has gone bust.

In the UK it's policy to give government contracts to the lowest bidder. This makes perfect sense, if you're clueless and have no idea what you're doing.

In other countries it's policy to offer contracts to the second or third cheapest bidder, because this encourages bidders to to put in estimates that mean they're more likely to finish the job without cutting corners, more likely to include realistic margins to keep their business afloat, and more likely to estimate unexpected costs realistically.

The UK's policy has completely failed to save money. It's going to cost hundreds of millions of pounds in direct costs, and probably more than a billion in consequential losses around the rest of the economy, to deal with the fallout from a wholly avoidable corporate drama.

I have worked in shops that intentionally deliver bad software, and those that had higher ethical standards, and the only difference on the business side was that the bad software had higher budgets and more permanent employees (both more-permanent employees and more permanent-employees).

The problem is that all the people who can tell the difference between good and bad are employed by the contractors. The direct government employees are still counting SLoC and basing their UI requirements on the Excel spreadsheets that were directly copied from paper forms from the 1970s. I am not making this up.

The contract awards are still mostly based on who you know, rather than the quality of your past work, so given the choice between a slipshod initial implementation with a juicy back end in the form of continual maintenance and doing it right the first time and delivering something that never needs contractor support ever again, it isn't surprising that a lot of companies opt for the former even when most of their employees would prefer the latter.

Don't know what the equivalent in the graphics design world would be.

"Hygiene" is a great word overall, for both cases.

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.

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.

Any reasonable person typing in “This is not a drill...” would pause half way through. It’s not the same as blindly clicking “Yes”.

This should also only be used for the real alerts and not the drills/tests otherwise you're training users to blindly type YES.

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?

Of course they then need a way to test the button...

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.

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.

http://nuclearfiles.org/menu/key-issues/nuclear-weapons/issu...

1979 Nov 9 Computer Exercise Tape

ref https://en.wikipedia.org/wiki/Death_of_Sean_Cunningham_(pilo...

I'm assuming you meant you'd be surprised if that number was zero. It's awfully hard to, in good faith, directly associate a message with a death. I mean if you wanted to make it seem bigger than it was, you could associate any crash or heart related death that happened in that 38 minute (?) period as directly a result of the warning, but I don't think that would be in good faith.

"not only will it kill you, it will hurt the whole time you are dying"

At least with airlines this seems to be largely abandoned now. My wife worked for a large middle eastern airline for a few years, and the crews were just assigned randomly. Well I guess there is a complicated algorithm that figures it out, but given the company has nearly 15,000 cabin crew it’s unlikely you’ll see someone you flew with again on another flight.

Also from the stories I heard people were promoted to managerial roles (on big flights there’s usually a senior for each class, and then a purser who reports to the captain) through seniority, not because they had any specific people skills that made them a good manager.

Oh, and their display mode is set incorrectly. It's clearly non-native resolution (blurry text, bilinear "zooming" performed by the display, while individual pixels are in sharp focus) and wrong aspect ratio (the font appears too wide).

Perhaps 1024x768 on a display with 1920x1080 native resolution. Or something similar.

No one intentionally set off these alarms.

In any case, as these systems are powered up, updated, overhauled or even replaced, there's testing going on. And when there's testing, there's the opportunity for just this type of gaffe.

Actually, considering that timescale and all the variables involved in detection and tracking a few seconds is less than the margin of error for predicting the warhead's arrival. While the goal should obviously be to get a (valid) warning to the public as quickly as practical, the "every second counts" mantra in this situation is overly dramatic. In fact, I think it is even counterproductive because it can lead to a "better safe than sorry" attitude that triggers unnecessary false alarms.

> How many people are you willing to kill to reduce the risk of a false alarm?

Depends. How many people might die in a false alarm? How many people might die if they stop trusting the alert system and fail to properly react to a true alarm?

Really, there is no way to justify this as in any way "intentionally designed".

I agree that the 'real alert' should not be impeded and they could at least put a red or black rectangle around the 'real alert' button to make it stand out from the others.

I wonder if there is a clear plan, and if there's a better way to communicate that to the population. That seems like maybe it should be more of a priority then this alert message, which seemed to only sow confusion.

Lol

I find it sad that people have been conditioned to lump anyone who questions such a messed up narrative in with nonsense like that.

Let's not act as if we've never been lied to before. We have reached a very low point in both credibility and transparency, and just because I have serious doubts about this story doesn't mean I'm a flat earther or whatever else you're insinuating. Let's be mature here.

I can see a bunch of reasons for clicking that link, from just for fun to wanting more money to fix the UI to the more sinister of wanting to keep the populous scared so that they are more likely to support a war in the future.

No reason to bring lizard people into this.

A site is vulnerable to XSRF if it doesn't use tokens when performing critical operations, critical operations are (usually) performed using HTTP POST, which can be done via form submission... token generation and validation is done server side...

You can perform a successful XSRF attack in a browser with javascript completely disabled.

But I've read a lot of suggestions like spreading items across multiple pages, adding passwords, or big warning colors and lines around the live options that are not just obfuscating/distracting/annoying but are bound to cause errors and open the door for even worse design.