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

Redesigning Hawaii’s Emergency Alert System UI

hackernoon.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Redesigning Hawaii’s Emergency Alert System UI

#11

Post by mc32 »

jmisavage wrote: post #6

It looks like it would help prevent the recent incident, but the confirmation screen at the end doesn't make it clear whether it's a test or a real thing. I know there was that big screen at the front, but if you're confirming something you need all the options presented again to double check.

There was a story of a nurse who was looking after a mother and her child in ICU. Child had many probes and alarms for alerting of change in condition.

The alarms were going off constantly, but often times, the condition was not severe. Mother was not getting sleep. Nurse took pity on mother. She tried silencing alarms. The system had, i believe, seven warning screens warning against deactivation, all needed to be acked to proceed. She proceeded. Mother got rest. Alarms were silently blaring. Nurses did not get the critical alarms. Toddler did not make it. Nurse obviously fired hospital sued, monitoring system mfg sued.

Monitoring mfg stated they didn't put in further failsafes because they never imagined someone would possibly go past seven ack Windows with all the warnings . Someone did.

Re: Redesigning Hawaii’s Emergency Alert System UI

#12

Post by bmelton »

jmisavage wrote: post #6

It looks like it would help prevent the recent incident, but the confirmation screen at the end doesn't make it clear whether it's a test or a real thing. I know there was that big screen at the front, but if you're confirming something you need all the options presented again to double check.

Agreed. I'd move the environment screen to the end.

Start an alert -> What kind of alert -> What message to send -> What environment to send to (test / production).

In the event of a production message, you should have a confirmation prompt, in red, that must be confirmed.

I think ultimately, you work towards a Pointing and Calling[1] system, such that it requires a second party to confirm the alert before it can be sent, but this is an improvement over current stage.

Also, I have reservations on adding bureaucracy to the process given that in a real life missile emergency, I have little faith that the entire body of civil servants are going to wait around to make sure the alert is sent before rushing home to their families / beginning their own evacuations.

[1] - https://en.wikipedia.org/wiki/Pointing_and_calling

Re: Redesigning Hawaii’s Emergency Alert System UI

#13

Post by koolba »

casperb wrote: post #8

I think step 2 and 3 are not very clear that you are sending an important message to millions of people, that should only be send in a rare occasion. It could just be that the designer likes red. What blows my mind is that something like this can be send by a single person. A better approach would be that you need 2 or 3 people to send such an alert to millions of people. How can a single person, that misplaced it's…

Is it possible to have two separate cursors?

Having two mice plugged in controls the same cursor so it doesn’t work for dual entry.

With two separate cursors you can have a “double double click” on two sides of the screen. It’s be like the dual key, “1-2-3-Engage!” in the movies.

Re: Redesigning Hawaii’s Emergency Alert System UI

#14

Post by hvidgaard »

dstjean wrote: post #10

What I find astonishing is that there was not a Two-man rule security control in place.

UI is not even remotely relevant compared to this. It can be as ugly 80'ies inspired as it wants to with poor UX. It should require 2 people signing off with their credentials for it to be send.

Re: Redesigning Hawaii’s Emergency Alert System UI

#15

Post by ceejayoz »

softwareqrafter wrote: post #5
olliewagner wrote: post #4

Imagining using this 3-page design makes me feel uncomfortable at step 2 and 3. What if I didn't know what the "test" notification was supposed to look like and wanted to make sure the system took my input correctly? What if it's such a dire emergency that the operator forgets (perhaps from experiencing intense anxiety) which one was selected? I think a stronger approach would be to flatten the design to one page. Yo…

You should probably also keep in mind that this isn't a consumer app. Who ever uses this will have seen the entire process before and tested it in a training environment. The redesign seems mostly to focus on making sure stuff isn't done by accident.

I've seen video of police shootouts where the cops - presumably trained on such a thing, plus daily exposure to tense situations - miss repeatedly from just a couple feet away, trip and fall, and otherwise screw up.

Training is not a replacement for good design. It helps, but I'd expect someone genuinely thinking they're about to be nuked to act differently than someone participating in a drill about it.

Re: Redesigning Hawaii’s Emergency Alert System UI

#18

Post by niftich »

As others are pointing out, steps 2 and 3 are flawed in this design. In an effort to break out the decision steps into a wizard, the author chooses to treat the distinction of 'test alert' vs 'real alert' as a simple configuration option whose decision was already chosen, so it doesn't need to be shown on step 2. This is the sort of designer-bias mistake that, ironically, leads to terrible interfaces like the original that precipitated this whole sequence.

Test alerts and real alerts are entirely different in every imaginable way: one's normal procedure, the other is hopefully a rare event; one causes people to scoff at their phones while the other creates urgency and concern. Playing up the distinction on 'step 1' is good, but eliminating all visual indications of the choice on further steps is bad in ways a confirmation screen can't rectify. UI is only a portion of the UX and the overall operator process, but there should be as few commonalities between the process (and UX) surrounding test alerts and the process surrounding real alerts as the trained operators of the system can bear. It's even odd to have them originate in the same entry point, but as the author has done, I'll also keep my criticism focused on a UI that can do both.

Concretely, I propose a simple way of rectifying the loss of context on 'step 2' is to get rid of the spurious 1-2-3 breadcrumb that doesn't communicate anything that isn't abundantly clear otherwise, and use the space for several conditional indicators that trigger in case a real alert was selected. Warning icons, clear wording, exclamation marks, attention-pulling colors or patterns should be used to distinguish the context of real alerts from text alerts in so many visual ways that accidentally confusing them, even through a momentary loss of situational awareness, is practically impossible.

Re: Redesigning Hawaii’s Emergency Alert System UI

#19

Post by always_good »

CameronBanga wrote: post #3

We're going to see a multitude of design hot takes here over the next 10 days, but I think most of these designers are missing the problem. The interface that caused this failure isn't because the system lacked designers. This design was created by being handcuffed by bureaucracy, with no strong leadership in place to solve the problems that were caused.

No, the UI is just a limited problem and people enjoy taking their whack at it just like how developers like to test out their own abstractions.

Neither a line of code nor a stroke of paint is going to solve bureaucratic issues. To suggest that everyone is unknowingly glancing past these issues except for you is a bit tacky, as if one is trying to score some me-too points.

Post reply on HN