Å vise det ene fartøyet som krever en beslutning

Et kart med hundrevis av fartøy er ubrukelig hvis alt har lik vekt. Den virkelige jobben til et overvåkingsgrensesnitt er ikke å vise all trafikken — det er å svare på ett spørsmål, raskt: hvilket fartøy krever en beslutning nå, og hvorfor?

Det er signal mot støy. Et AIS-bortfall midt i åpent hav er støy. Det samme bortfallet rett ved en sjøkabel, fra et fartøy med en risikabel profil, er nettopp det en operatør må handle på. Hele prototypen er organisert rundt å skille de to.

Designet er forankret i to faktiske mønstre i norske farvann. De er grunnen til at konteksten — ikke bare hendelsen — avgjør prioritet.

Begge har samme designimplikasjon: beslutningsvinduet er til sjøs, i sanntid, hos operatøren. Det er verdien Varde demonstrerer.

Alt henger på én flyt: prioritert kø → identifikasjon → beslutning → journal.

1. 1

   Køen rangerer

   Hendelser sorteres etter en forklarbar prioritetsscore, høyest først. Toppen av listen er alltid svaret på «hva trenger meg nå?». Fullt tastaturstyrt: piltaster navigerer, K/X/E avgjør, og hver beslutning flytter fokus til neste åpne hendelse — som en innboks.

2. 2

   Panelet identifiserer

   Å velge en hendelse åpner et bunnpanel som leses identifikasjon-først: hvem er dette, hvilken kilde, hvor mye kan jeg stole på det — før vurderingen og beslutningen.

3. 3

   Operatøren tar stilling

   Tre eksplisitte valg: kvitter, avvis, eskaler. Aldri flere. Den visuelt primære knappen følger det scoringen konkluderte med — eskaler for kritiske, kvitter ellers — uten å skjule alternativene.

4. 4

   Journalen husker

   Hver beslutning og angring logges med tidsstempel og operatørsignatur. Vaktjournalen er det som overlever når arbeidstilstanden ryddes — og grunnlaget for en vaktoverlevering.

En operatør (og en intervjuer) skal kunne peke på hvorfor noe rangerer der det gjør. Prioritetsscoren er derfor en ren sum av eksplisitte faktorer: grunnscore for hendelsestypen, nærhet til infrastruktur, risikoprofil, atferdsmønster, ferskhet. Hele regnestykket ligger bak selve tallet — ett klikk unna, aldri påtvunget.

Vektene bor i én konfigurasjonsfil. Det gjør modellen lett å forklare og lett å justere — og holder den ærlig: ingenting er skjult i uleselig logikk.

Et portefølje­prosjekt som later som det har etterretning det ikke har, er verdiløst. Varde trekker en hard, synlig grense mellom det som er ekte og det som er illustrativt:

• Bekreftet — posisjon, fart, kurs, identitet og flaggstat er avledet fra AIS. Vises som ekte.
• Illustrativt — forsikring, byggeår og sanksjonstreff finnes ikke i AIS og har ingen åpen kilde her. De finnes kun for konstruerte demofartøy, og er alltid tydelig merket. For reelle fartøy konstrueres de aldri.
• Konstruerte aktører — trusselfartøyene er fiktive. Reelle navn (som Bastø-fergene) brukes bare der den viste atferden er deres faktiske, daglige atferd. Reelle identiteter knyttes aldri til konstruert trusselatferd.

Panelet skiller dette visuelt med egne, merkede seksjoner — og kabelkorridorene er representative, fordi eksakte kabeltraseer bevisst ikke er offentlige. Det er i seg selv en del av den operative virkeligheten.

Mye er lånt — bevisst — fra systemer og spill som allerede har løst lesbarhet under press:

Språket er operatørens, ikke generisk UI: en hendelse kvitteres (alarmkvittering), loggen er en vaktjournal. Ord en kontrollromsoperatør allerede har muskelminne for.

Mørkt er ikke en preferanse her — det er en domenebeslutning (dempede kontrollrom, nattevakter). Resten følger noen få regler:

• Styrkeregel: bare alvorsgrad og beslutningsknapper får være «høye». Alt annet er dempet tekst, så operatøren kan skille alarm fra attributt.
• Farge er funksjonell og alltid paret med form, ikon eller tekst — mening overlever uten fargesyn. Pil = i fart, sirkel = kontakt uten AIS, hul kontur = mørkt fartøy.
• WCAG måles, ikke gjettes. Et skript regner kontrast for hvert token mot riktig bakgrunn — og for kartoverlegg mot selve sjøkartet, ikke UI-flaten.
• Kantprinsippet: lyse aksenter (sporlinje, seleksjon) berører aldri det lyse sjøkartet direkte — en mørk kant bærer kontrasten.

Datamodellen er kildeagnostisk: AIS er én kilde blant flere. Hver posisjonsmelding bærer sin kilde, så en radar-, satellitt- eller undervannssensor kan mate samme pipeline uten omskriving. Den ene illustrative radarkontakten beviser nettopp dette.

• En tynn server-proxy håndterer OAuth, caching og avgrensning mot BarentsWatch. Hemmeligheter forlater aldri serveren — nettleseren snakker bare med /api/ais.
• Hendelsesavledning er ren og tilstandsløs; operatørens beslutninger legges oppå via stabile id-er, så ny avledning aldri visker ut en beslutning.
• Scenariomodus er deterministisk — fartøy følger skriptede ruter, verifisert til å ligge på vann mot kartfliser — så beslutningshistorien spilles av likt hver gang.

Like viktig som det som er bygget: det som er valgt bort, og hvorfor.

• Innlogging og roller — kontrollrommets praksis med vakt-initialer gir ansvarlighet uten en full auth-stack. Ekte fler­bruker er en senere skive.
• Lyst tema — token-laget gjør det strukturelt billig senere, men hvert WCAG-løfte er målt mot den mørke paletten. Vi valgte å ikke bruke kontrast-budsjettet her.
• Ekte multi-sensor og responsutsending — én illustrativ ikke-AIS-kontakt viser at modellen er klar; ekte radar/satellitt og patrulje­tildeling er neste skiver.