Kapittel 2 – Teorier, prinsipper og guider

2.2 Høy-nivå-teorier

Noen teorier er forklarende. Disse hjeper oss å observere oppførsel og aktivitet og gir oss idéer til hvordan vi skal sammenligne høynivået av to design.

Noen teorier er forutseende. Disse hjelper designere å sammenligne tiden som trengs for å utføre en handling, og feilraten ved ulike design.

Taxonomy er klart definerte begreper som vi kan bruke for å beskrive et design.

2.2.1 Konseptuelle, semantiske, styntakse og leksikale modeller

· Den konseptuelle modell er brukerens mentale modeller av et system. Eksempler på forskjellige konseptuelle modeller er linje- og fullskjerms teksteditorer.

· Den semantiske modell beskriver meningen med brukerens kommandoer og systemets respons på kommandoene.

· Den syntakse modell definerer hvordan brukeren bygger/skal bygge opp en setning av kommandoer, og hvordan maskinen tolker de gitte kommandoer.

· Den leksikale modell definerer hvilke bokstaver, knapper, mustaster etc. som brukeren angir kommandoer med.

2.2.2 GOMS og tastetrykk modellen

GOMS står for goals, operator, methods and selection rules. Dette er en modell som beskriver hvordan brukeren formulerer mål (goal), for eksempel redigere et dokument, og delmål, for eksempel sette inn et ord. Metodene (method) brukeren benytter for å utføre handlingen, for eksempel flytte musen og trykke en rekke taster på tastaturet. For å få dette utført må brukeren (operator) tenke og gjøre en fysisk handling, og foreta en del valg (selection).

2.2.3 Modeller for trinnene i en handling

1. Forme et mål

2. Forme en intensjon

3. Spesifiser en handling

4. Utføre en handling

5. Observere resultatet

6. Tolke resultatet

7. Evaluere resultatet

Denne modellen leder oss fram til Norman’s fire generelle designtips.

1. Alle valg og kommandoer som kan gjøres/utføres bør være synlige.

2. En god konseptuell modell og et konsistent GUI.

3. Systemet bør ha en logisk tilknytning mellom kommando og handling (mapping).

4. Brukeren bør få kontinuerlig tilbakemelding på de handlingene som gjøres.

2.3 Modellen for grensesnittet mellom Objekt og Handling

I den nye utgaven av boka (3. ugave) er Objekt <-> Handling viktige begreper. Den underliggende teorien om design kalles Object-Action Interface Model, OAI. Ettersom kommandobaserte systemer erstattes av GUIs, gir dette en mulighet for bruk av OAI. For eksempel kan man dra et dokument over en papirkurv for å slette dokumentet. Man har da knyttet en handling opp mot objektet (her dokument) som gjenspeiler dagligdagse/virkelige handlinger.

2.3.2 Grensesnitthierarkier av objekter og handling

Når man skal skrive et brev ved hjelp av tekstbehandling må brukeren forsøke å overføre det han vet om brevskriving til å bruke tekstbehandlingsprogrammet. Brukeren må ha en høynivå modell for hvordan han skriver (oppgavens handling) et brev (oppgavens objekt), og vite at brevet vil bli lagret som et dokument (grensesnittets objekt). I tillegg må han vite detaljene om hvordan man lagrer (grensesnittets handling) dokumentet. Brukeren må også ha kjennskap til en middelnivå modell som forteller hvordan man bygger opp en setning, hvordan den startes og hvordan den avsluttes. Til slutt må brukeren vite hvordan man staver ordene (oppgavens lavnivå), og han må vite hvilke knapper han skal trykke på for å skrive ordene (grensesnittets lavnivå). Direkte manipulasjon er en designteknikk som forsøker å minske forskjellen mellom oppgaven som skal utføres og grensesnittet.

2.4 Prinsipp 1: Å erkjenne forskjellene

Nybegynnere og førstegangsbrukere Antallet tilgjengelige handlinger bør være få, slik at nybegynnere lett kan utføre enkle oppgaver og redusere frykten for det nye systemet. Systemet er avhengig av å bygge opp tillitt fra brukeren. Informativ tilbakemelding for hver oppgave er konstruktivt, og spesifiserte feilmeldinger må tilbys når brukeren gjør feil. Godt designet brukermanualer og steg-for-steg online opplæring kan være nyttig.

Erfarne brukere Byrden på hukommelsen kan lettes ved godt strukturerte menyer, konsistent terminologi og god synlighet. Dette medfører at brukere kan kjenne seg igjen, i stedet for å måtte huske. Disse brukerne vil dra nytte av online hjelp for å fylle inn informasjon som løser deler av oppgavene. Godt organiserte referansemanualer kan være nyttig.

Ekspertbrukere Disse brukerne forlanger hurtig respons, kortfattet og ikkedistraherende tilbakemelding, og kapasitet til å utføre handlinger med få tastetrykk. Dersom en handling krever tre – fire tastetrykk vil brukeren gjerne lage makro som utfører handlingen for ham. Kommandostrenger, hurtigtaster, typeahead-teknikk med mer er et krav.

En måte å få nybegynnerne i gang på, er å lære dem et minimum sett av operasjoner til å begynne med. Dette kan for eksempel gjøres ved hjelp av en online veiledning.

For å lage et system som kan brukes av alle de tre gruppene ovenfor, kan man tilby en funksjon hvor man velger bruk av tilbakemelding og tilgjengelige kommandoer.

2.4.2 Brukerprofiler

Eksempler på nyttige hurtigtaster i en tekstbehandler:

• Veldig ofte brukte funksjoner kan tilegnes spesialtaster, for eksempel piltastene, INSERT- og DELETE-tastene.
• Funksjoner som er litt mindre i bruk kan tilegnes hurtigtaster, som for eksempel CTRL+F for fet tekst, eller popupmeny som man får opp ved å høyreklikke. Eksempler kan være understreket tekst, kursiv tekst, sentrert tekst og innrykk.
• Funksjoner som er mindre brukt kan kreve at man går gjennom noen menyvalg eller foretar utfylling av skjema. Eksempel: Endre utskriftsformat.

2.4.3 Interaksjonsmetoder

Direkte manipulasjon Når en smart designer har klart å lage visuelle representasjoner av hverdaglige handlinger i systemet, blir brukerens handlinger mye lettere å utføre, fordi man vil kjenne igjen objektene fra virkeligheten. Direkte manipulasjon appellerer til nybegynnerne, det er lett å huske for de erfarne, og med god design kan det være raskt nok i bruk for ekspertene.

Menyer Den største fordelen må være at menyer tilbyr en klar struktur for å foreta valg, siden alle tilgjengelige og relevante funksjoner er synlige. Denne teknikken er tilstrekkelig for nybegynnere og erfarne, og kan være appellerende for ekspertbrukere dersom menyen er kjapp å navigere i.

Skjema For å benytte skjema må brukerne kjenne til hva som skal skrives inn i de ulike feltene, man må derfor være kjent med terminologien som er brukt i systemet. Man må også vite hvilke verdier som er ulovlige, og hvordan man handler i forhold til feilmeldinger. Siden denne teknikken krever litt kjennskap til systemet, appellerer dette mest til erfarne og eksperter.

Kommandobasert brukergrensesnitt For erfarne og eksperter virker kommandobasert grensesnitt på en måte som gjør at brukerne føler en stor kontroll over systemet. Men feilraten er stor, kjennskap til systemet er nødvendig, og det som huskes etter en stund opphold kan være lite. Feilmeldinger og online hjelp kan være vanskelig å tilby pga varierte muligheter og problemer med mapping mellom handling og konsept og syntaks.

Naturlig språk Det er vanligvis vanskelig for systemet å oppfatte hva som er relevante kommandoer i en setning av naturlig språk. Dette gjør at brukerne må velge blant mange mer eller mindre relevante alternativer til respons på kommandoene som gis. Dette gjør en slik teknikk mye langsommere og klumsete i bruk enn andre alternativer.

For å tilfredstille alle brukernes behov kan man ta i bruk flere av disse teknikkene i systemet. Kommandoer kan lede brukerne til skjema, og menyer kan brukes til handlinger som er vanskelig å visualisere i et direkte manipulasjonssystem.

2.5 Prinsipp 2: Bruk de Åtte Gyllne Regler for grensesnittdesign

1. Sørg for konsistens. Rekkefølgen av handlinger, terminologien i prompt, menyer, hjelpeskjermer, farge, layout, skrifttype skal være konsistent. Noen unntak finnes, for eksempel skal ikke passord vises, og slettekommandoer bør kreve bekreftelse.
2. Tilby hurtigknapper for erfarne brukere. Forkortelser, spesialtaster, skjulte kommandoer og makrofunksjoner er ønsket av erfarne brukere.
3. Tilby informativ tilbakemelding. For erfarne brukere og mindre handlinger kan tilbakemeldingen være noe diskré. Men for nybegynnere og større oppgaver må tilbakemeldingen være fullstendig.
4. Design dialoger med tydelig start og slutt. Handlingssekvenser bør organiseres med begynnelse og slutt. Informativ tilbakemelding på slutten av en oppgave gir brukeren en følselse av å ha fullført.
5. Prøv å motvirke feil, og tilby feilbehandling. Først og fremst design slik at brukerne ikke kan gjøre feil, for eksempel bruk kombobokser i skjema, og ikke godta bokstaver i inputbokser for tall. Når brukrene har gjort en feil, tilby enkle og fullstendige instruksjoner for hvordan feilen skal rettes opp. For eksempel skal det ikke være nødvendig å skrive hele kommandoen på nytt, bare den delen som er feil. En feilhandling skal ikke forandre tilstanden til systemet.
6. Tilby angrefunksjon. Så langt som mulig må handlingene kunne reverseres, enten ved bruk av angrefunksjon, eller at brukeren har mulighet til å gå inn og endre på det han har gjort.
7. Tilby brukerne kontroll over systemet. Uforutsigbare handlinger av systemet, umulig eller vanskelig tilgang til nødvendig informasjon, umulig utførelse av ønsket handling, alt dette fører til frustrasjon hos brukerne.
8. Reduser behovet for korttidshukommelse. Tilby online hjelp med oversikt over kommandoer, syntaks og lignende.

2.6 Prinsipp 3: Unngå feil

Feilmeldinger skal være spesifikke, ha en positiv tone, og fortelle brukerne hva som må gjøres og ikke bare hva som er feil. Eksempel på dårlige feilmeldinger:

• SYNTAX ERROR
• ILLEGAL DATA

Istedet kan melingene være:

• MANGLER VENSTRE PARENTES
• MENYVALG FRA 1 TIL 6

Tre teknikker kan redusere antall feil ved å sørge for fullstendige og korrekte handlinger: korrekt sammenhørende kommandopar, komplette sekvenser, automatisk fullføring av kommandoer.

2.6.1 Korrekt sammenhørende kommandopar

Når brukeren skriver en venstreparentes, kan høyreparentesen tilføyes automatisk, og markøren settes mellom parentesene. Eller man man vise en melding i venstre hjørne om at høyreparentesen må skrives inn, helt til dette er gjort.

2.6.2 Komplette sekvenser

Siden brukerne har en tendens til å glemme noen steg i en handling, forsøker designere å samle flere trinn under én handling. For eksempel når en bilfører skal slå på blinklys før han svinger til venstre, setter han på blinklysene både framme og bak på bilen ved kun én handling. Når en flyger setter ned landingshjulene på et fly, utføres mange hundre kontroller automatisk.

Lignende automatikk kan brukes i programsystemer. Når man logger på internett, utføres en hel rekke handlinger idet brukeren trykker på ”koble til”-knappen. Maskinen ringer opp, skjekker brukernavn og passord, mottar påloggingsbeskjed osv.

Designere kan finne potensielle komplette sekvenser ved å studere hvilke handlinger brukerne gjør i én bestemt rekkefølge, og hvilke feil som evt oppstår.

2.6.3 Automatisk fullføring av kommandoer

Noen programmer tilbyr automatisk fullføring av kommandoer ved at brukerne taster noen få tegn av en lengre kommando, og deretter trykker mellomrom for å fullføre den. Eksempler på dette er adresselinjen i Internet Explorer og generell kodeskriving i Visual Basic.

En mer effektiv måte å unngå feil på, er å bruke direkte manipulasjon, hvor brukerne gjør valg istedet for å skrive inn kommandoer. Disse sytemene viser gyldige kommandoer i menyer, eller filnavn i en liste, og tilbyr brukerne å klikke på disse.

2.7 Retningslinjer for visning av data

2.7.1 Organisering av skjermen

1. Konsistent visning av data Gjennom hele designprosessen skal terminologien, formatering, farger, bruk av store bokstaver osv være standardisert ved bruk av en nedskrevet oppskrift.
2. Kjent organisering av informasjon Oppsett av tekst skal være konsistent. En tabell med tekst og tall skal være justert rett under hverandre, tekst skal være venstrejustert, heltall skal være høyrejustert, desimaltall skal være justert etter komma.
3. Minimal hukommelsesbruk av brukerne Brukeren skal ikke være nødt til å huske informasjon fra ett skjermbilde til et annet. En oppgave som krever flere handlinger skal være arrangert slik at feil ikke oppstår, og antallet handlinger skal begrenses slik at risikoen for å glemme en av handlingene begrenses.
4. Kompatibilitet mellom innskrevne data og viste data Formatet på dataene presentert på skjermen skal være likt formatet til innskrivingen av dataene.
5. Fleksibilitet for brukerne til visning av data Det skal være mulig for brukerne å endre rekkefølgen i kolonner og sortering i rader. Informasjonen skal være presentert i et format som er tilpasset den oppgaven brukerne holder på med.

En mer detaljert liste med krav til organisering:

• Vær konsistent med tekst og grafikk
• Bruk konsistent format på overskrifter, topptekster og bunntekster, menyer osv
• Ved bruk av mange sider, vis sidetall og tilby mulighet for å hoppe mellom sidene ved å referere til sidetallene.
• Ikke vis data som ikke tilhører brukeren
• Design skjermbildene uten bruk av farger. Strukturer skjermbildet ved hjelp av mellomrom, organisering av elementer. Bruk til slutt farge der dette er nødvendig.
• Involver brukerne i designprosessen av nye skjermbilder.

2.7.2 Få brukerens oppmerksomhet

• Intensitet
• Merking Understreking, rammer, pil, eller punkt.
• Størrelse Bruk opptil fire størrelser, der større elementer opptar mer oppmerksomhet.
• Skrifttyper Bruk opptil tre fonter.
• Negativ farging av bilder
• Blinking Bruk dette kun i begrensede områder, og med stor forsiktighet. Blinkingen skal være mellom 2 og 4 hertz.
• Farger Bruk opptil fire standard farger. Andre farger til spesiell bruk.
• Blinkende farger Vær veldig forsiktig ved bruk av denne teknikken. Må kun benyttes på små områder
• Lyd Bruk myke lyder for vanlig positiv tilbakemelding, og skarpe lyder for nødsituasjoner.

Bruk disse teknikkene med stor forsiktighet. Det er en fare for at grensesnittet frustrerer brukerne hvis man overdriver bruk av disse. Nybegynnere trenger enkle, logisk organiserte og godt merkede skjermbilder som guider dem gjennom oppgavene. Ekspertbrukere aksepterer ikke overdreven bruk av disse teknikkene.

Fargekoder er svært praktisk for å gruppere elementer som hører sammen, men gjør det vanskeligere å bruke disse elementene på tvers av grupperingen.

Lydbruk kan være en god måte å gi tilbakemelding på. Alarmer fører til at brukerne reagerer raskt. Når man bruker mange alarmer må man teste i hvilken grad brukerne oppfatter viktigheten av de forskjellige alarmene.

2.8 Retningslinjer for innskriving av data

1. Konsistent bruk av kommandoer for å hoppe mellom elementer.
2. Færre handlinger fører til mindre feil. Tilby velging i lister i stedet for inntasting av lange tekststrenger der dette er mulig. Dette fører til mindre feil, organiserer mulighetene, og minsker bruk av korttidsminnet.
3. Når samme data skal brukes på to forskjellige steder skal systemet kopiere valgte data fra det ene stedet til det andre.
4. Formatet på inntastede data skal være likt formatet på viste data.