På bakgrunn av teorien som er diskutert i denne oppgaven, har jeg kommet fram til en del retningslinjer som bør følges ved design av brukergrensesnitt for militære domener. I bunnen av disse retningslinjene ligger de generelle retningslinjene som gjelder ved alle typer design av brukergrensesnitt. (f eks fontstørrelse, fargebruk, oppløsning på skjerm, utforming på knapper, etc.)
Disse retningslinjene har jeg satt sammen fra mange kilder, hovedsakelig fra Klein, Klinger og Miller (1997), Andriole og Adelman (1995), Rasmussen og Vicente (1989) og Endsley (1995a).
Hva Hvorfor Hvordan Presentere beregninger,
avstander, tider, etc direkte.
Oppmerksomhets, og arbeids-hukommelse er begrenset. Ved å unngå at operatøren må foreta beregninger reduseres den mentale belastningen.
Ved å presentere dataene "ferdig" utregnet vil det redusere belastningen på operatøren. For eksempel bør CPA12, KP13, tid til et valgt pkt, tid til at mål er innenfor en satt avstand (våpenrekkevidde), hvor fort et mål (fartøy, fly, etc) nærmer / fjerner seg, etc.
Presentere informasjon teknisk orientert – basert på fysiske systemparametre og målinger. For å forbedre dette trenger informasjon (presen-tasjonen) å bli bedre SA orientert.
Informasjonen bør bli organisert slik at informasjon som er nødvendig for å nå et spesielt mål er uthevet (fargelagt, innrammet, blinkende, etc) og direkte besvarer de viktigste beslutningene som er assosiert med dette målet. For eksempel forslag til valg av våpen for et spesielt mål, tid til avfyring av våpen, sannsynlighet for treff, valgt mål, etc.
Dette er muligens mindre viktig for taktiske presentasjonssystemer, men vil ha større betydning for systemer for våpenlevering.
Presentere hint / ledetråder minske faren for valg av feil modell, valg av feil
fremgangsmåte, etc.
Ved å analysere domenet med hensyn på de hintene / ledetrådene en typisk operatør trenger for å gjenkjenne / klassifisere en (prototypisk) situasjon og presentere disse på en slik måte at de kan bekrefte eller avbe-krefte den valgte (prototypiske) situasjonen.
Gi operatøren en "liste" av handlinger som må utføres ved den valgte situasjonen. For eksempel et mål kommer innenfor en gitt avstand f eks våpenrekkevidde vil systemet kunne presentere en liste av operasjoner som må / kan foretas i den gitte situasjonen (rapportere, velge våpen, velge (mulig) unnvikende manøver, etc.)
Dette er det mest omfattende punktet og det krever en nøyaktig analyse av domenet.
Presentere hensikt / intensjon
Presentere informasjon på en slik måte at det letter en operatøres oppgave med å definere eller utlede hensikten / intensjonen til et mål.
Gi operatøren verktøy for å være til hjelp for klassifisering av mål, oppdraget(ene) målet (ene) kan ha, hvilken funksjon de(t) kan ha i et oppdrag, hvilke andre mål det kan sam-arbeide med, etc. Dette kan være presentasjon av trackdata (historie, tidsrom, manøver-analyse, tendensdata (nærmer /fjerner seg, stiger / synker (høyde), etc), hvilke kilder / sensor som rapporterer målet (egne sensorer, link data, etterretningsrapporter, etc), kart data, sektorer (f eks er målet(fly) innenfor en internasjonal luftkorridor kan målet være en sivilt fly), etc. oppmerksom-heten blir rettet mot oppgaver som ikke er "viktige" i situasjonen.
Automatisk eller lette prosessen med å assosiere to mål. Automatisk eller lette prosessene med f eks loggføring, rapportering av mål til andre enheter, etc.
12 CPA – Closest Point of Approach
13 KP – Kollisjonspunkt
Hva Hvorfor Hvordan Være tilgivende overfor
feil av operatøren.
Minske effekten av operatørfeil. Gi operatøren mulighet for å tilbake-kalle handlinger og/ eller gi advarsler før kritiske handlinger, handlinger som ikke kan tilbake-kalles. Dette gjør at operasjoner på brukergrensesnittet kan gjøres med større hastighet og med mindre mental belastning, når operatøren vet at en handling kan tilbake-kalles.
Lagre alle handlinger som har foregått og gi en mulighet til å "angre" disse. Utforme og bestemme hvilke handlinger som er kritiske eller har stor betydning og som ikke kan tilbakekalles. for operatøren ved å hjelpe opera-tøren med å utforme hypoteser og planlegge handlinger. Lette vurder-ingen av konsekvensene av hand-lingen(er) før de er utført.
Konstruere verktøy og funksjoner for å forutsi hvordan situasjonen kan utvikle seg ved valgt handlemåte. Gi operatøren verktøy for å kunne simulere utviklingen av situa-sjoner / virkningen av beslutningen / handlingen, etc.
Presentere operatøren med et brukergrensesnitt slik at operatøren ikke må "lete" i menyer for å finne en ønsket funksjon.
Redusere den mentale belastningen for operatøren ved ikke å tvinge den kognitive kontrollen på et høyere nivå enn nødvendig.
Ved å designe brukergrensesnittet slik at kun funksjoner som er nødvendig i den gitte situasjonen er tilgjengelig kan en redusere menystrukturen og heller presentere funk-sjoner som knapper / ikoner direkte på brukergrensesnittet.
Gi operatøren feedback på sine handlinger.
Gi operatøren mulighet til å oppdage feil prosedyre, feil valg, feil handling, etc. Unngår at operatøren er usikker om en handling er iverksatt.
Presentere feedback ved hjelp av kursor, tegn, signaler, lister over handlinger o.l.
Tabell 4.1 Generelle retningslinjer for brukergrensesnitt
I tillegg til de generelle retningslinjene er det spesielle krav til brukergrensesnitt må oppfylles.
Disse kravene er spesifikt for det domenet brukergrensesnittet skal benyttes i, og kan være f eks design av ikoner og symboler, kartdata og skala, bruk av spesiell notasjon, bruk av spesiell maskinvare etc. Disse spesielle kravene vil ikke vil diskutert i oppgaven.
4.6 Oppsummering
Tradisjonelle retningslinjer eller tommelfingerregler for design og utforming av brukergrense-snittet kan ikke alltid benyttes i spesielle domener, fordi disse er mest for generelle applika-sjoner og for generelt bruk. Det må derfor utvikles retningslinjer for disse domenene.
Det er forskjellige måter en operatør tolker et bilde (brukergrensesnitt) på. Det kan ikke sammenlignes det å bruke et tekstbehandlingsprogram og det å operere på et brukergrensesnitt for et prosessanlegg. Derfor må spesielle designløsninger som utvikles for applikasjoner som skal brukes i komplekse domener.
Det er enighet i mange forskningsmiljøer om at mennesker bruker forskjellige former for kognitiv kontroll nå de bruker applikasjoner, tolker eller opererer på et brukergrensesnitt. Dette
tendens til å bli utført raskere, mer effektivt og med mindre resursser (mentalt), enn høyere nivås kognitivt kontroll (kunnskapsbasert adferd). Empiriske undersøkelser viser også at mennesker har en definert forkjærlighet for å utføre oppgaver ved å basere seg på lavere nivå av kognitiv kontroll, selv om brukergrensesnittet ikke er designet for å støtte denne typen oppførsel. For å kunne støtte et lavere nivå av kognitiv kontroll må brukergrensesnittet gjøres manipulerbart, d v s operatøren må kunne opparbeide seg sensormotoriske ferdigheter for å kunne utnytte de perseptuelle evnene til operatøren. Samtidig må brukergrensesnittet også støtte de høyere nivå av kognitiv kontroll.
Jeg har også vist til undersøkelser som viser at beslutningstakerne benytter seg av en gjen-kjennings-prosess og at SA er en av de viktigste interessene eller "bekymringene" beslut-ningstakeren har. Dette krever at designere av brukergrensesnitt for bruk i komplekse domener må undersøke hvilke kritiske hint og ledetråder som operatøren benytter for å katalogisere eller skille situasjoner. Dersom hvis designeren identifiserer de forskjellige hintene som benyttes av erfarne/uerfarne operatører. Kan brukergrensesnittet bli sentrert rundt beslutninger istedenfor rundt informasjonsflyt.