Skylla dålig ui-design för hawaiis falska missilvarning

Människor gör misstag, varför användargränssnitt och mjukvarudesign är så kritisk. Fråga bara Hawaii Emergency Management Agency (HEMA), som av misstag skickade ett falskt inkommande ballistiskt missilhot som varnar till invånare och turister tidigare denna månad, vilket uppmanade dem att söka skydd.

"Detta är inte en borr", läs meddelandet, som dök upp på tusentals telefoner såväl som TV- och radiostationer mitt i växande kärnkraftsspänningar mellan USA och Nordkorea. Inte överraskande panikerade människor och skickade skräckslagen meddelanden till vänner och nära och kära i mer än en halvtimme - då HEMA äntligen meddelade att varningen var ett falskt larm.

Senare erkände byrån att en anställd tryckte på fel knapp när man testade missilvarningssystemet, delvis eftersom den dåligt utformade programvaran inte hade några skydd mot falska larm.

Hjälp en användare

Händelsen fick Federal Communications Commission (FCC) att starta en utredning.

"Baserat på den information vi hittills har samlat in verkar det som om Hawaii-regeringen inte hade rimliga skyddsåtgärder eller processkontroller på plats för att förhindra överföring av en falsk varning, " sade FCC: s ordförande Ajit Pai i ett uttalande. "Federala, statliga och lokala tjänstemän i hela landet måste arbeta tillsammans för att identifiera eventuella sårbarheter för falska varningar och göra vad som är nödvändigt för att fixa dem. Vi måste också se till att korrigeringar omedelbart utfärdas i händelse av att en falsk varning slocknar."

Enligt Washington Post var det enda som stod mellan ett systemtest och skickar en riktig missilvarning ett rullgardinsmenyalternativ.

Bra användargränssnitt (UI) design hänger på isoleringsfunktioner som har olika syften. När du vill separera ett internt test och ett kommando som skickar ett kritiskt meddelande till hundratusentals människor, måste du integrera visuella signaler. Detta kan vara så enkelt som att använda separata knappar eller ändra färgtema för UI när användare går in i alarmläget. En annan bästa praxis kan vara att använda en "Är du säker?" fråga innan du kör ett kommando.

Missionsvarningssystemet på Hawaii innehöll ingen av dessa funktioner.

Ingen väg till rätt fel

HEMA använde Wireless Emergency Alarm (WEA), ett allmänt säkerhetssystem som skickar varningar till alla mobila enheter inom ett angiven område. Det är ett effektivt sätt att nå många människor på kort varsel, men WEA: er är begränsade till korta textmeddelanden. De kan inte innehålla bilder, klickbara telefonnummer eller länkar till onlinekällor. Mottagarna lämnas för att undersöka varningen ytterligare.

Det som förvärrade incidenten på Hawaii var att systemet inte kunde utfärda korrigeringar; som Post rapporterar ger Federal Emergency Management Agency (FEMA) HEMA "stående tillstånd… att använda civila varningssystem för att skicka ut missilvarningen - men inte för att skicka ut en efterföljande falsk larm."

Det var uppenbart att designteamet inte hade hänt att en operatör kan trycka på fel knapp. HEMA publicerade en uppdateringstweet cirka 13 minuter efter det att den första varningen skickades, men meddelandet nådde inte så många människor som WEA. Hela 38 minuter gick innan en andra WEA skickades och informerade alla om att det fanns "INGEN missilhot."

"En del av problemet var att det var för lätt - för alla - att göra ett så stort misstag", sa en talesman för HEMA till Posten . Han sade också att byrån har avbrutit borrningarna och lagt till skyddsåtgärder för systemet, inklusive en förfrågan för att bekräfta operatörens avsikt innan ett larm skickas.

Incidenten på Hawaii är en påminnelse om hur designfel som är så liten som att välja fel UI-element och hoppa över enkla funktioner kan ha stora följder. Detta understryker det kritiska ansvaret för programvaruutvecklare och ingenjörer eftersom programvara blir allestädes närvarande.

När det gäller den anställde som gjorde misstaget kommer han inte att bli sparken, enligt HEMA-talesman. Det är bara rättvist. När programvaran misslyckas med detta, bör utvecklare - inte användare - hållas ansvariga.