Skyddsrums­kompassen

Den offentliga skyddsrumskartan är en webbtjänst som visar registrerade skyddsrum i Sverige. Där kan besökaren söka på en adress eller använda sin aktuella position för att se skyddsrum i närheten. Tjänsten ger framför allt en geografisk överblick genom att presentera skyddsrummen som punkter på en karta.

I MSB:s utvärdering av skyddsrumskartan beskrev respondenter att tjänsten var svår att hitta och krävde för många steg att nå. Utvärderingen pekade också på förbättringsmöjligheter inom tillgänglighet och på behovet av en robustare lösning vid plötsliga belastningstoppar.

Skyddsrumsinformationen finns även tillgänglig som öppen geodata, vilket gör det möjligt att presentera myndighetens data i andra gränssnitt. Vi ville därför undersöka ett kompletterande mobilgränssnitt med fokus på orientering: vilket skyddsrum ligger närmast, åt vilket håll ligger det och hur långt bort är det?

Från början planerade vi en mobilapp och en tillhörande Wear OS-app som skulle fungera tillsammans. Mobilen skulle hantera kompass, karta, lista och inställningar, medan klockan skulle ge snabb tillgång till riktning och avstånd. För att färdigställa ett sammanhängande kärnflöde inom projektets tidsram prioriterade vi mobilappen och avgränsade Wear OS till ett planerat partnergränssnitt.

Magnetometern reagerade på störningar, särskilt inomhus, vilket fick kompassnålen att darra och hoppa mellan riktningar. Vi lade därför till ett lågpassfilter som dämpade små och snabba förändringar i sensorsignalen. Nålen rörde sig mjukare och blev lättare att följa utan att vi ändrade vad den pekade mot.

Kompassvyn var utgångspunkten, men en ensam pil gav för lite sammanhang när användaren ville kontrollera sin position eller välja ett annat skyddsrum. Därför byggde vi tre kompletterande vyer kring olika frågor.

Vi började med ett enkelt proof of concept för att se om offentlig skyddsrumsdata, telefonens position och kompass kunde fungera tillsammans. Därefter utvecklade vi lösningen genom fyra mobilversioner, V0–V3. För varje version blev hierarkin tydligare: riktning och avstånd fick störst plats, medan karta och lista gav sammanhang och möjlighet att välja ett annat skyddsrum.

Vi valde Flutter för att kunna fortsätta utveckla designen i kod. Med hot reload kunde vi snabbt se förändringar i den körande appen och justera hierarki, komponenter, tillstånd och interaktioner utan att behöva bygga om hela appen efter varje förändring. Figma satte den visuella riktningen, medan Flutter gjorde det möjligt att pröva hur designen faktiskt betedde sig.

Vid start valde appen automatiskt ett närliggande skyddsrum, så att användaren direkt fick en riktning. Om användaren sedan valde ett annat skyddsrum i listan blev det det nya målet och följde med mellan kompass- och kartvyn.

Vi ville att appens viktigaste information skulle gå att förstå utan att användaren behövde tolka en kompassnål eller karta visuellt. Därför visades riktning, avstånd, adress och kapacitet även som text. Listan gav dessutom ett alternativt sätt att hitta och välja skyddsrum.

Vi använde standardkomponenter där det var möjligt och lade till Semantics-beskrivningar för de egenbyggda delarna. Med TalkBack gick vi igenom flödet och kontrollerade att bland annat riktning, avstånd, adress och valt skyddsrum kunde läsas upp. Färg och form användes som stöd, men var aldrig det enda sättet att förmedla information.

Resultatet blev en Android-app med kompass, karta och en valbar lista över närliggande skyddsrum. Appen hämtade aktiva skyddsrum från ArcGIS och sparade skyddsrumsuppgifterna lokalt som reserv.