Leksjon 7: Brukergrensesnitt - NTNUStiftelsen TISIP i samarbeid med Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Brukergrensesnitt side 3 av 24 Brukergrensesnitt

Stiftelsen TISIP i samarbeid med Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag

Leksjon 7: Brukergrensesnitt Jarle Larsen

05.03.2004 Opphavsrett: Forfatter og Stiftelsen TISIP

Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid

1. INNLEDNING ............................................................................................................................................. 2 2. MENNESKE-MASKIN-INTERAKSJON................................................................................................. 2

2.1. MMI ER TVERRFAGLIG ......................................................................................................................... 3 3. BRUKBARHET........................................................................................................................................... 5

3.1. LIVSSYKLUSEN VED UTVIKLING AV BRUKBARHET. ............................................................................... 5 3.1.1. Kjenn brukeren................................................................................................................................ 6 3.1.2. Analysere konkurrentene................................................................................................................. 7 3.1.3. Sett brukbarhetsmål ........................................................................................................................ 7 3.1.4. Brukermedvirkning.......................................................................................................................... 8 3.1.5. Samordning av design ..................................................................................................................... 8 3.1.6. Retningslinjer og regler for design av grafiske brukergrensesnitt .................................................. 9 3.1.7. Prototyping.................................................................................................................................... 11 3.1.8. Empirisk testing............................................................................................................................. 11 3.1.9. Iterativ design................................................................................................................................ 12 3.1.10. Tilbakemelding fra brukerne .................................................................................................... 12

4. KONKRET ANVENDELSE AV RETNINGSLINJENE FOR GODE BRUKERGRENSESNITT... 12 4.1. EKSEMPLER PÅ KONKRETE REGLER FOR UTFORMING AV BRUKERGRENSESNITT ................................. 12 4.2. DE ENKELTE GUI-KOMPONENTENE .................................................................................................... 13 4.3. 4.3 BRUK AV KNAPPENE OK, LAGRE, BRUK, AVBRYT OG LUKK ........................................................ 15

5. DIALOGTYPER ....................................................................................................................................... 16 5.1. SPØRSMÅL OG SVAR ........................................................................................................................... 17 5.2. MENYER ............................................................................................................................................. 17 5.3. DIREKTE MANIPULERING .................................................................................................................... 17 5.4. KOMMANDOBASERT DIALOG .............................................................................................................. 18 5.5. SKJEMAUTFYLLING............................................................................................................................. 18

6. BRUK AV FARGER................................................................................................................................. 19 6.1. FARGER ER VIKTIGE............................................................................................................................ 19 6.2. LESBARHET OG FARGER...................................................................................................................... 19 6.3. HVORFOR ANVENDE FARGER? ............................................................................................................ 23 6.4. REGLER FOR FARGEBRUK. .................................................................................................................. 23

7. VERKTØY FOR DESIGN AV BRUKERGRENSESNITT .................................................................. 24 8. REFERANSER.......................................................................................................................................... 24

Stiftelsen TISIP i samarbeid med Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Brukergrensesnitt

side 2 av 24

1. Innledning I denne leksjonen skal vi først ta for oss samspillet mellom mennesket og datamaskinen.

Moderne datasystemer arbeider i interaksjon med brukeren. Brukeren gir inn data og datasystemet responderer med å gi ut data i en eller annen form som tekst, lyd, bilde etc. En slik arbeidsform setter store krav til brukergrensesnittet – kontaktflaten mellom menneske og maskin.

Med Apple MacIntosh begynte leverandører av datamaskiner og programvare å innse hvor viktig det var å ha et godt brukergrensesnitt. Med utstyr som grafiske skjermer og mus kunne en implementere ”direkte manipulasjon” og ”skrivebord” systemer, som var adskillig lettere å bruke enn de tidligere kommandobaserte systemene. Prinsippet bak direkte manipulasjon er at alle objekter og handlinger i maskinen har fått en visuell representasjon på skjermen, som menyer, skjema, knapper, ikoner osv. Brukeren arbeider direkte på den visuelle representasjonen, og bak kulissene vil systemet utføre de analoge handlinger på de virkelige objektene.

Med enklere grensesnitt kan brukergruppene utvides, fra eksperter til amatører. Dette setter igjen krav til oversiktlighet og enkelhet i grensesnittet. I dag finner en datamaskinen i de fleste hjem og brukere med helt forskjellige forutsetninger kan hente informasjon fra hele verden via Internett , gjøre innkjøp f.eks. bøker, bestille flybilletter, konsertbiletter, overføre penger, betale regninger osv. Dette var handlinger som før var forbeholdt de med god kunnskap om data. Det er klart at å kunne utføre disse funksjonene for alle type brukere, stiller langt større krav til datasystemene og da særlig brukergrensesnittet, enn den gangen dette ble gjort av ansatte med god opplæring og lang erfaring.

Brukergrensesnittet omfatter all samhandling mellom menneske og maskin dvs. skjermbilde, tastatur, mus, utskrift, lyspenn osv. Vi skal avgrense dette til spesifikt å se på det som vi i hovedsak oppfatter med brukergrensesnittet, nemlig de skjermbilder som brukeren kommuniserer med når et program kjøres.

Vi skal ta for oss de forskjellige kriterier og retningslinjer som er grunnleggende ved design av et brukergrensesnitt.

2. Menneske-maskin-interaksjon I begynnelsen var datamaskinen en regnemaskin som ble benyttet i hovedsak av fysikere, matematikere, programmerere og etter hvert systemkosulenter.

På 80-tallet ble det mer fokus på brukeren og etter hvert som bruk av datamaskin ble alminneliggjort, ble det viktig å ta hensyn til brukeren ved utforming av brukergrensesnittet.

Dette førte til at det vokste fram et nytt fagfelt ”human computer interaction” (HCI). I norsk sammenheng er det blitt vanlig å bruke betegnelsen ”menneske-maskin interaksjon” (MMI).

Det er et tverrfaglig forskningsfelt under stadig utvikling.


side 3 av 24

Brukergrensesnitt er vanskelig å designe og det forbruker ca. 50% av de totale ressurser som går med til å lage et nytt datasystem. Derfor kan det være kostbart å gjøre feil i utviklingsfasen, noe som stiller store krav til det arbeidet utviklingsteamet gjør. Ja, dårlig design har ført til flere ulykker der menneskeliv har gått tapt.

Eksempel på dårlig design som fikk katastrofale konsekvenser:

3. juli 1988 ble en Airbus 320B2 skutt ned og 290 mennesker omkom. Første rapport fra Pentagon var at et Iransk F-14 jagerfly var skutt ned. Marinen benektet først de iranske rapporter om at ubevepnet sivilt fly var skutt ned, men måtte etter hvert bekrefte mistaket. Flyet ble skutt ned av USS Vincennes. Tragedien var en designfeil i brukergrensesnittet til Aegis, et sofistikert kampsystem til $ 400 millioner. Granskningsrapporten konkluderte med at radarbildet viste flyets posisjon og høyde, men kritisk informasjn var utelatt, bl.a. om flyets høyde. denne ble vist på forskjellige konsoller og det var i beste fall vanskelig å korrelere informasjonsbitene.

Opp gjennom årene er det utviklet en rekke retnigslinjer og regler for design av brukergrensesnitt og disse kan være til god hjelp ved fornuftig bruk.

2.1. MMI er tverrfaglig Det er mange fagområder som bidrar ved utviklingen av brukergrensesnittet. Her er noen av de mest sentrale:

Menneske-

Dataspråk Kunstig intelligens

Kognitiv psykologi

Sosiologi

Systemutvikling

Sosialpsykologi

Matematikk

Organisasjonspsykologi

Ergonomi


side 4 av 24

1. Systemutvikling. Alle utviklingsmodeller følger en hovedinndeling hvor man starter med et forstudium og

en analyse av hva systemet skal gjøre. Deretter lages et design (konstruksjon – modell) som viser hovedstrukturen i systemet. Til slutt implementeres systemet ved hjelp av et eller annet programmeringsspråk. Brukermedvirkning og prototyping er to viktige faktorer i utviklingen av brukergrensesnitt og dette skal vi se nærmere på senere i leksjonen. I den senere tid er det utviklet en rekke verktøy og metoder for å lage brukergrensesnitt. Det finnes i dag verktøy for å lage vinduer med menyer av ulike typer, knapper og skjema m.m.

2. Dataspråk. Det forskes mye på hvordan datasystemer skal forstå og produsere naturlig språk slik at

dialogen med datamaskinen skal være mest mulig likt det daglige språk. Her vil spørsmål som hvordan skal meldinger og kommandoer utformes for å være mest mulig lettfattelig og entydig, være av sentral betydning for et brukbart grensesnitt.

3. Kunstig intelligens. Kan datamaskiner tenke? Kunstig intelligens er studiet av menneskets mentale

prosesser gjennom bruk av datamaskinmodeller. Når en anvender kunstig intelligens ved utvikling av brukergrensesnitt kan en snakke om intelligente og tilpassede bukergrensesnitt. Med intelligente brukergrensesnitt er det snakk om at brukergrensesnittet inneholder intelligente agenter som over en viss tid lærer brukeren av systemet å kjenne og etter hvert kan utføre funksjoner på vegne av brukeren. Brukere har ulike behov for brukergrensesnitt alt etter kunnskapsnivå og erfaring. Tilpassede brukergrensesnitt er slik laget at de etter hver som en bruker starter å bruke systemet, vil brukergrensesnittet bli mer og mer tilpasset den aktuelle bruker. Intelligente agenter lærer brukeren å kjenne, de kan også korrigere brukeren slik at dialogen med datamaskinen blir enklere. Bindersen som hopper opp for å hjelpe i Microsoft Office-programmene er mer eller mindre et forsøk på intelligens ved at den tilbyrenten ved å gi oss tips i en gitt situasjon eller for å få oss ut av en situasjon der vi står fast. Erfaringen med denne bindersen er svært blandet. Noen ganger kan den være grei å ha , men andre ganger kan den være irriterende ved at den dukker opp uten at vi har behov for hjelp.

4. Kognitiv psykologi. Kognitiv psykologi er den delen av psykologien som handler om menneskets

informasjonsprosesser samt å forstå menneskelig adferd. Det vil si hvordan vi innhenter, bearbeider og anvender informasjonen. I det inngår persepsjons-, hukommelses-, tanke- og språklige prosesser. Hva er enklest å huske, et bilde(ikon) eller tekst(kommando)? Hvor mange objekt kan et menneske oppfatte samtidig? Hvilke farger skal en bruke for at skjermbildet skal virke behagelig? Hvordan skal farge brukes for å markere eller skille objekt fra hverandre?

5. Sosiologi. Sosiologer er opptatt av relasjoner mellom mennesker, grupper og sosiale systemer. Det viktige er

å utvikle en forståelse av at menneskene vi studerer, lever og handler i en sosial sammenheng – sosiologien er altså opptatt av å se samspillet mellom de enkelte menneskene og det store samfunnet. Sosial klasse, kjønn og utdannelse er blant de faktorene som influerer på den måte mennesker aksepterer et datasystem.

6. Ergonomi. Denne fagdisiplinen bidrar til den fysiske utforming av de fysiske delene av brukergrensesnittet

slik som skjermutforming, tastatur og mus. Skjermen må være behagelig å se på, tastaturet må være utformet slik at det ikke belaster f.eks. håndleddet og likeledes må musens utforming og bruk ikke virke anstrengende.

7. Organisasjonspsykologi. Psykologiske og mellommenneskelige prosesser er viktige for å forstå en rekke

fenomener innen organisasjon, ledelse og arbeidsmiljø. Psykologisk teori gir dessuten bakgrunn for bl.a. å forstå læring og kompetanseutvikling, og personalvurdering (jf. ansettelser). Kunnskap innenfor dette fagfeltet vil hjelpe oss i å forstå hvilken påvirkning et datasystem kan ha på en organisasjon.

8. Matematikk. Dette faget hjelper oss i å definere strukturen og logikken i et datasystem. Videre benyttes

matematikk i en rekke ulike analysemetoder for å evaluere lærbarheten og brukbarheten av et brukergrensesnitt.

9. Sosialpsykologi. Sosialpsykologien utgjør et viktig og omfattende felt i moderne psykologi. Én grunn til

dette er at nærmest alle psykologiske fenomener fremtrer innenfor en sosial ramme - de har en sosial dimensjon. Det er viktig å forstå hvilken betydning denne sosiale dimensjonen har. Kunnskap fra sosialpsykologisk forskning har dermed potensielt stor betydning i å forstå og løse samfunnsproblemer.


side 5 av 24

Kunnskap innenfor dette fagfeltet gjør oss i stand til å forstå hvorfor mange har endringsvegring i forhold til innføring eller endring av datasystem og dermed setter oss i stand til å designe brukergrensesnitt som lettere aksepteres.

3. Brukbarhet Det er viktig å forstå at det ikke finnes noen optimale løsninger for design av brukergrensesnitt eller faste regler som kan følges i alle situasjoner. Design av brukergrensesnitt er preget av kontekst-avhengighet, unikhet og kreativitet, hovedsakelig som et resultat av at brukere og deres brukssituasjoner ikke på forhånd kan spesifiseres. Det gjør at utviklingen av gode interaktive edb-systemer er tid- og ressurskrevende, og kan ikke isoleres fra andre aktiviteter i systemutviklings-prosessen. Kjennskap til design av brukergrensesnitt og den praksis det innebærer er viktig for systemutviklere som vil være med på utviklingen av dagens og fremtidens komplekse, interaktive edb-systemer.

Empirisk forskning har vist at brukbarhet er en hovedfaktor ved design av brukergrensesnitt, ja mer enn, som mange tror, hurtighet og muligheter. Undersøkelsene viser at brukbarhet dramatisk reduserer kostnadene og øker produktiviteten.

Det viser seg at profesjonelle designere lager brukergrensesnitt som har færre feil og raskere brukerutførelse enn brukergrensesnitt som er utviklet av programmerere. Derfor har det i den senere tid blitt satset mye på dette fagfeltet og dette vil klart fortsette i fremtiden der tilpasningsmulige og intelligente brukergrensesnitt vil være i fokus.

3.1. Livssyklusen ved utvikling av brukbarhet. Med fallende priser og økende mengde av programvare stilles det større krav til brukergrensesnittet. Variasjonen i brukernes forutsetning til å bruke PC er stor, fra nybegynnere til eksperter. Det er således behov for høy grad av brukbarhet, noe som ikke uten vider inntreffer fordi vi ønsker det. For å sikre at det programmet som skal lages, har en høy grad av brukbarhet, må vi aktivt inkludere brukbarhetsprinsipper i systemutviklingsprosessen. Det er nok aldri noen som tenker på å designe et ubrukbart brukergrensesnitt, men det er bare en systematisk utvikling med bruk av etablerte metoder som kan sikre en høy brukbarhet. Gode intensjoner er ikke nok.

I en utviklingsprosess for å få frem høy brukbarhet er det viktig at en tidlig i prosessen setter søkelyset på brukeren, brukerens deltakelse i design av brukergrensesnittet, koordinering av de ulike deler av brukergrensesnittet, empiriskt brukertesting og iterativ revidering av design basert på testresultatene.

Jacob Nielsen har modifisert noen ”gyldne regler” utviklet av Gould og Lewis som inneholder hovedelementene i en utvilingsmodell for brukergrensesnittet. Disse reglene er:


side 6 av 24

• Kjenn brukeren • Analysere konkurrentene • Sette brukbarhetsmål • Brukermedvirkning • Samordning av design • Retningslinjer og regler for design av grafiske brukergrensesnitt • Prototyping • Empirisk testing • Iterativ design • Tilbakemelding fra brukerne

Selv om alle reglene har sin betydning for et godt brukergrensesnitt så er empirisk testing og prototyping kombinert med iterativ design de viktigste. Dette fordi det er nesten umulig å å lage et korrekt brukergrensesnitt ved første forsøk. Det er altfor kostbart å endre på et ferdig implementert brukergrensesnitt.

3.1.1. Kjenn brukeren. Første trinn i en utviklingsprosess av brukergrensesnittet er å undersøke hvilken kategori brukere det ferdige programmet er beregnet for. Brukernes ulikhet og variasjon i oppgaver et system skal kunne utføre er de to forhold som har størst betydning for hvorvidt et brukergrensesnitt har høy brukbarhet eller ikke. Derfor må disse to forhold studeres nøye av de som utvikler et datasystem.

I enkelte sammenhenger er det lett å få kjennskap til brukeren f.eks. når vedkommende hører til en bestemt avdeling i et firma. Annerledes er det når det produktet en skal lage vil ha en mer spredt brukergruppe. Da må en begrense muligheten til å få kunskap om brukeren ved å besøke noen få representative brukergrupper.

Alternativt utvikles det dataprogram der stor del av befolkningen er brukere. Her vil det være individuelle forskjeller i alder, utdanningsnivå, dataerfaring, evnen til å lese tekst, språkkunnskaper osv. F. eks. vil barn med liten eller ingen leseevne kreve grafiske brukergrensesnitt uten tekst.

Arbeidsmiljø og sosiale forhold er også viktig. På en arbeidsplass med åpent kontorlanskap vil det være lite heldig at det benyttes en lyd for å markere at en feil er gjort fra brukerens side. Vedkommende som gjør feilen vil fort føle seg dum overfor medarbeiderne i kontorlandskapet.

Et annet forhold som er viktig å avdekke ved utviklingen av et nytt datasystem er å finne ut hvordan brukeren utfører tilsvarende oppgave i dag. Finne ut hva som er svakheter ved dagens system, hvordan inn- og utdata blir behandlet, hvorvidt det brukes unødig tid på utføring av oppgaven og finne ut om det er bestemte forhold som gjør at brukerne feiler eller ikke. I det hele tatt en gjennomgående analyse av hvordan brukerne utfører oppgavene i dag.


side 7 av 24

Deretter må en se på hva som kan endres og på hvilken måte dette kan gjøre for å bedre brukbarheten i et nytt system. Hvis det nye systemet er en videreutvikling av et tidligere system må en være forsiktig med gjøre for radikale endringer uten å gi en grundig informasjom og opplæring i det nye.

Etter at en bruker har tatt et nytt system i bruk vil han utvikle seg, bli flinkere og finner nye og mer avanserte måter å bruke datasystemet på. Derfor er det viktig med en fleksibel design som gjør det mulig med mer avansert bruk av dataprogrammet. Prinsipielt bør et design av brukergrensesnittet være slik at det gir høy brukbarhet for både nybegynnere og eksperter.

3.1.2. Analysere konkurrentene Prototyping er en viktig sekvens ved utvikling av brukergrensesnitt og eksisterende - kanskje konkurrerende – produkt er ofte de beste prototyper for vårt eget produkt. Vi kan analysere eksisterende produkt ut fra etablerte regler for hvordan en oppnår høy brukbarheten i et brukergrensesnitt og utføre empiriske brukertester med disse produktene.

Et konkurrerende produkt er allerede implementert og kan derfor testes enkelt og mer realistisk enn en annen prototype. På denne måten kan vi lære hvordan testprogrammets funksjonalitet og interaksjonsteknikker støtter de oppgaver som vi forventer at vårt planlagte produkt skal utføre. Dette vil kunne gi oss ideer om hva som vil fungere og hva vi må unngå i vårt nye design.

En slik analyse medfører ikke at vi bruker andres design, som har copyright, men vi ønsker å få et bedre resultat ved å analysere styrker og svakheter til konkurrerende design.

3.1.3. Sett brukbarhetsmål Brukbarhet omhandler alle forhold ved et system der et menneske må interaktere. Brukbarhet har flere komponenter og er tradisjonelt forbundet med disse 5 brukbarhetsmål:

• Lærbarhet. Systemet skal være lett å lære slik at brukeren fort kan begynne å

arbeide med systemet. • Effektivitet. Systemet skal være effektivt å bruke, slik at så snart brukeren har

lært systemet skal en kunne oppnå et høyt produksjonsnivå. • Hukommelse. Systemet skal være lett å huske slik at en tilfeldig bruker etter å

ha vært borte fra systemet en tid, skal kunne ta det i bruk igjen uten å lære alt fra starten av.

• Feil. Systemet skal ha en lav feilprosent slik at brukerne gjør få feil ved bruk og hvis en feil blir gjort skal brukeren lett fjerne feilen. Katastofale feil må ikke inntreffe.

• Tilfredstillelse. Systemet skal være behagelig å bruke slik at brukerene er fornøyd med å bruke det. De aksepterer og liker systemet.

Det er ikke mulig å sette lik prioritet mellom disse målene i et enkelt design, så en må gjøre prioriteringer på grunnlag av analyse av brukeren og de oppgaver han skal utføre. F. eks. er høy lærbarhet viktig for nybegynnere og tilfeldige brukere.


side 8 av 24

Det er mer samsvar mellom de fem brukbarhetsmål enn konflikt, så det er viktig å få et godt resultat for alle målene.

En bør definere brukbarhetsmålene til et brukergrensesnitt mer spesifikt enn de fem generelle målene som er listet opp evenfor. De viktigste målene bør defineres mer detaljert slik at det er mulig med empirisk testing av i hvilken grad brukergrensesnittet oppfyller målene.

3.1.4. Brukermedvirkning Selv om vi skal lære brukeren å kjenne på et tidlig stadium – før selve designfasen begynner – er det umulige å få så god kunnskap om brukeren at vi kan svare på alle problem som dukker opp under designfasen. Erfaring har vist at brukere ofte stiller spørsmål som et design team aldri hadde tenkt på. I stedet for å gjette, bør designteamet knytte til seg en brukergruppe og det må være regulære møter i utviklingsprosessen.

Brukere er ikke designere så en kan ikke forvente at de skal bidra med ideer fra starten av, men de er flink til å reagere på konkrete eksempler med å si i fra om hva de liker og hva som ikke vil fungere. For å få full nytte av brukermedvirkning må eksemplet som skal vurderes presenteres på en form som er konkret og synlig i form av prototyper. I starten kan det være prototyer bestående av tegninger med papir og blyant for deretter å være prototyper utviklet med et dataverktøy.

For program som er beregnet på unge mennesker, kan det være vanskelig å involvere disse i et designteam, så her må en i hovedsak stole på empirisk testing.

3.1.5. Samordning av design Konsistens er en av de viktigste karakteristikkene ved brukbarhet. Konsistens bør gjelde for alle deler som utgjør det totale brukergrensesnitt og også mellom ulike versjoner av programsystem samt i forhold til andre programsystem. For å oppnå konsistens i det totale brukergrensesnitt er det viktig at en person eller en gruppe personer – avhengig av hvor stort datasystemet er – samordner de ulike aktiviter i utviklinen av systemet. Dette gjelder både det å etablere en felles forståelse av hvordan brukergrensesnittet skal være samt å skapeen felles kultur i de ulike utviklingsgrupper.

Prototyping er et godt hjelpemiddel for å oppnå konsistens ved at en prototype tidlig i designfasen kan indikere i hvilken retning prosessen går. Videre kan en øke konsistensen ved at de ulike utviklingsgrupper bruker samme programkode for de deler av brukergrensesnittet som er tilsvarende.

Etter hver har det utviklet seg en del standarder slik at produkter utviklet av ulike produsenter er konsistente og det kan være viktig å utvikle egne produkter med de samme standarder.


side 9 av 24

3.1.6. Retningslinjer og regler for design av grafiske brukergrensesnitt Generelle retningslinjer for design av grafiske brukergrensesnitt er ofte publisert i tekniske blad eller bøker. Noen dokumenter inneholder hundrevis av retningslinjer mens andre nøyer seg med langt færre. Det finnes retningslinjer for menyer, kommandoer, skjemaer, bruk av farger, bilder osv. Vi skal ta for oss Shneidermanns 8 ”gyldne regler” for design av grafisk brukergrensesnitt (Graphical User Interface, GUI):

1. Streb etter konsistens.

Dette er noe av det som det er mest syndet mot ved design av brukergrensesnitt, men som kanskje er enklest å oppnå. Samme type knapper og menyer må være plassert på samme plass i de ulike skjermbilder. Like funksjoner i ulike skjermbilder har samme hurtigkommando. Bruk samme farge til samme type informasjon.

Skjermbildene over viser mangel på konsistens da knappene er plassert helt forskjellig i de to skjermbildene. Det er lett å skjønne at slikt vil være frustrerende og lite brukervennlig.

2. Muliggjør bruk av snarveier.

Med økende bruksfrekvens øker brukernes ønske om å redusere antall interaksjoner og interaksjonsfaser. Musebruk er tidkrevende for erfarne brukere og det bør være mulig å gjøre alle operasjoner via tastaturet. For avanserte brukere vil det bety kortere responstid og hurtigere skjermoppdatering.

3. Gi informative tilbakemeldinger.

Systemet bør alltid gi tibakemelding(feedback) for hver operasjon. Brukeren må få forståelse av at systemet har oppfattet hva han vil. De tilbakemeldinger system gir kan være av ulik karakter. Når det sendes en utskrift til skriveren skal det komme en tilbakemelding om at utskriften er sendt og hvor mange sider dokumentet består. Etter en tid kommer det medlding om at ”Dokumentet er skrevet ut”. Ved nedlasting av filer kommer det opp en meldingsboks som sier hvor langt i nedlastingen en er kommet. Dette er viktig informasjon for brukeren som da slipper frustrasjonen ved å tro at ingenting skjer.

4. Benytt dialoger med klart definert slutt.


side 10 av 24

Handlingssekvenser grupperes med begynnelse, middel og slutt. Informativ tilbakemelding ved avslutning gir brukerne en tilfredsstillelse av fullføring og klargjør dem for flere aksjoner.

5. Tilby enkel feilhåndtering.

I utgangspunktet bør brukergrensesnittet være slik utformet at feil unngås. Hvis det allikevel skulle inntreffe feil bør det tilbys enkle, slagkraftige mekanismer for feilhåndtering. Feilaktige kommandoer skal ikke endre systemtilstanden og systemet bør kunne gi instruksjon om hvordan tilstanden kan gjenopprettes. Feilmeldinger bør ikke være truende, bebreidende eller kryptiske. Derimot bør de være informative og hjelpe brukeren på rett spor.

Eksempel på kryptisk feilmelding

6. Tillat enkel reversering av handlinger

Handlinger bør i så stor grad som mulig være reverserbare. Det betyr at det må være mulig å angre en handling som er utført, slik de fleste som bruker f. eks. Word er fortrolig med. Ja det er mulig å angre flere trinn tilbake. Angremuligheten reduserer potensielle engstelser hos brukeren og oppfordrer til utforskning.

7. La brukeren få følelesen av å ha kontroll

Det er viktig at brukeren har følelsen av å ha kontroll og at systemet responderer på deres aksjoner og ikke slik at brukeren. La brukeren føle at han er initiativtaker og ikke en som svarer på initiativ fra systemet.

8. Reduser kravene til korttids-hukommelse.

Dette krever enkle skjermbilder slik at ikke korttids-hukommelsen blir for sterkt belastet. En tommelfingerregel er at menneske lagre 7 pluss/minus 2 klumper av informasjon i korttids-hukommelsen av gangen. Derfor bør en unngå dype og kompliserte menyer og dialoger. For den alminnelige bruker må en ikke kreve at han skal huske kommandoer. Baser utformingen av brukergrensesnittet på gjenkjenning i stedet for hukommelse.


side 11 av 24

Slike regler og retningslinjer er attraktive på grunn av sin slagordpregede form. Man må imidlertid være oppmerksom på at man ikke er sikret å få et godt brukergrensesnitt selv om man har denne listen hengende foran seg når en utformer brukergrensesnittet.

3.1.7. Prototyping Eksperimentell prototyping er sterkt å anbefale på et tidlig stadium i utviklingsprosessen. Den første prototypen vil aldri være god nok og den må kastes. Det er viktig å lage prototyper tidlig og ofte i stedet for å gjøre en stor innsats på slutten i utviklingsprosessen.

Erfaring viser at det ikke er fornuftig å involvere brukere i analysefasen ved å vise dem abstrakt spesifiserte dokumenter fordi de ikke er i stand til forstå dokumenter på tilsvarende måte som konkrete prototyper.

De første prototypene kan være ganske primitive, mens de senere prototyper stadig nærmer seg det endelige målet. Gjennom en iterativ prosess der brukerne vurdere og eventuelt prøver ut prototypen får designteamet tilbakemelding som blir analysert og grunnlag for en ny prototype.

3.1.8. Empirisk testing Det er to hovedformer for testing av et brukergrensesnitt som er mer eller mindre ferdig:

1. Kvantitativ testing. Her tester en hvorvidt de brukbarhetsmål en har satt fro

systemet er oppfyllt. 2. Kvalitativ testing. Her tester en på hvilke deler av brukergrensesnittet som

fungerer og hvilke som skaper brukerproblemer.

De mest vanlige testmetodene er:

• Tenke høyt. Testpersonene bruker systemet mens de tenker høyt. Ved å

verbalisere sine tanker, avslører testpersonene sitt syn på datasystemet og de lar oss identifisere sine misoppfatninger. Vi får en klar forståelse av hvilke deler av dialogen med datamaskinen som forårsaker flest problemer fordi tenke-høyt metoden viser oss hvordan testbrukerne tolker hver enkelt del av brukergrensesnittet.

• Konstruktiv interaksjon. I denne metoden arbeider to brukere sammen for å utføre testoppgaver. Særlig for barn er denne metoden nyttig da det for dem er mer naturlig å kommunisere med en partner enn å tenke høyt. Selv voksne finner denne metoden mer naturlig, men den krever dobbelt så mange testpersoner som tenke-høyt metoden.

• Spørsmål. Lag et spørreskjema med svaralternativ som er skalert f.eks. fra 1-5.

• Kunnskapsnivå. Test brukernes kunnskapsnivå før og etter bruk av systemet. • Datalogging. Automatisk datalogging av brukernes aksjoner. Loggingen kan

avsløre at en bestemt aksjon utløser så ofte feilmelding at en må endre måten brukerneutfører aksjonen på.


side 12 av 24

• Observasjon. En observerer brukerne mens de arbeider i sitt anturlige miljø. En bruker da oftest videokamera til overvåkingen og brukeren er vel vitende om dette.

3.1.9. Iterativ design Ut fra de resultater en kommer frem til ved empirisk testing kan utviklingsteamet produsere en ny versjon av brukergrensesnittet. Noen av de endringer som blir gjort kan være feilaktige for å løse problemet eller det kan skje at endringen innfører nye problem. Dette gjør at det må foretas en ny test som gir grunnlag for en ny prototyp osv.

Hvis en er nær målene for brukbarhet som er satt og brukerne sier seg sånn noenlunde fornøyd med systemet vil det ofte være ufornuftig å utføre flere iterasjoner for å forbedre brukergrensesnittet. Kostnaden ved en ny iterasjon blir for stor i forhold til kvalitetshevingen av brukergrensesnittet.

3.1.10. Tilbakemelding fra brukerne Etter å ha lansert et datasystem kan det sees på som en prototyp for senere versjoner av systemet.

Derfor er det viktig å få tilbakemelding fra virkelige brukere av systemet i forhold til de laboratoriemessige tester som ble gjort ved utvikling av systemet. Det er viktig å få informasjon om både positive og negative sider. Derfor er det ikke nok å logge hvor ofte brukeren benytter support-tjenesten,fordi bruk av den ofte er forbundet med negative ting. En må besøke brukerne på arbeidsplassen for å se hvordan de fungerer i sitt naturlige arbeidsmiljø og hvordan de uører de daglige oppgaver.

4. Konkret anvendelse av retningslinjene for gode brukergrensesnitt

Retningslinjene som er er beskrevet i pkt. 3.1.6 gjelder like godt for tekstbaserte som for grafiske grensesnitt.

Det fins en mengde konkretiseringer av disse generelle prinsippene. De mest kjente er de såkalte ”style guides” som tilbys av de ulike programvareleverandørene. Se f.eks. [Microsoft 1995] og [IBM 1991]. Selv finner jeg imidlertid [CCI 1993-1995] som den mest matnyttige. I tillegg til at retningslinjene kommer på papir kommer de også som en help-fil bygget opp etter hypertekst-prinsippet. Hensikten er å ”extend and clarify” retningslinjene fra Microsoft og IBM.

4.1. Eksempler på konkrete regler for utforming av brukergrensesnitt

• Tekst skal vanligvis være venstrejustert, tall høyrejustert. Tekst i meldingsbokser skal være sentrert.

• Bruk statuslinja på samme måte hele tiden. • Omdefiner ikke den vanlige måten vindusobjektene oppfører seg på • Samle alle data som skal til for å utføre en operasjon i ett vindu (med ev. dialogbokser)


side 13 av 24

• Plasser det viktigste der brukeren ser først. • Grupper informasjon som hører sammen • Reduser antall nivåer med dialogbokser • Bruk MDI når flere forskjellige oppgaver skal kunne utføres i parallell • Modale dialogbokser bør være flyttbare • Tenk over om dialogboksen bør være modeless! Ofte best, men vanskelig å implementere • Husk de ferdigdefinerte dialogene (Open, Save As, Find, and/or Replace....) • Trykknapper i hovedvinduet samles i verktøylinjen. Bruk ikoner, eventuelt med tekst. • Trykknapper med tekst: Like store, pent under eller ved siden av hverandre. Bruk

imperativ-formen av verbet. • Husk å grå ut valg som ikke skal kunne utføres. • Bruk listebokser i stedet for editeringsfelter, der det er mulig. • Foreslå standardverdier der det er naturlig. • Datakontroll bør ligge på feltnivå, eventuelt på tegnnivå. • Dersom en operasjon tar mer enn fem sekunder, bruk en tidsindikator. • Feilmeldinger bør være konstruktive, eventuelt ha en Help-knapp. • Tilby alternativ (tastekombinasjoner) til musebruk. Husk: Sjekk guidelines! • Bruk ikke bare store bokstaver i f.eks. ledetekster • Husk på de som er fargeblinde! Unngå rød/grønn kombinasjon. • Pass på fargene! Ikke overdriv fargebruk og andre effekter.

4.2. De enkelte GUI-komponentene Figuren nedenfor viser eksempler på GUI-komponenter. De norske navnene er i henhold til [Microsoft 1995].

Flere GUI-komponenter:

kategorikontroll(tab control) kategorikort

(tab)

avmerkingsboks(check box)

ledetekst(label) tekstboks

(text box)

verdisettingsboks(spin box)

(kommando-) trykknapp((command) button)

rullegardinliste, lukket(drop down list box, closed)


side 14 av 24

Denne dialogen inneholder tre gruppebokser: Printer, Page range og Copies. Inni boksen "Page range" finner vi tre alternativknapper.

Standardknappen er den knappen som har noe kraftigere ramme rundt seg. Det er vanligvis OK-knappen som vist her.

Kombinasjonsbokser er ikke vist på figuren over. Det er en kombinasjon av et tekstfelt og en enkeltvalgliste. Det vil si at brukeren kan legge inn en verdi selv, eller velge en verdi fra ei liste. Vi har to typer:

Kombinasjonsboks som er permanent trukket ned:

Kombinasjonsboks som trekkes ned av brukeren:

En kommandomeny er en hurtigmeny som aktiviseres ved å trykke på en knapp:


side 15 av 24

Ved tilrettelegging for tastaturbruk skiller vi mellom hurtigtaster og tilgangstaster: • Hurtigtast (shortcut key, accelerator key) - tast eller kombinasjon av taster som fungerer

som en snarvei til en operasjon, eks. CTRL+S for File/Save). • Tilgangstast (access key, mnemonic) - bokstaven som er understreket i f.eks. et menyvalg.

4.3. 4.3 Bruk av knappene OK, Lagre, Bruk, Avbryt og Lukk De engelske navnene for disse knappene er henholdsvis OK, Save, Apply, Cancel og Close. Enkelte av disse er det vanskelig å holde fra hverandre. Det er også vanskelig å finne entydige anbefalinger i [Microsoft 1995] og [CCI 1993-1995]. Det er imidlertid viktig for brukeren at vi er konsekvente i bruken av disse knappene, og det hjelper sannsynligvis også dersom vi ikke bruker flere enn nødvendig i samme program. Jeg vil her prøve å klarlegge det jeg mener er eller bør være måten disse knappene skal brukes på.

OK I dialogvinduer brukes denne knappen vanligvis sammen med Avbryt. Ved å trykke OK signaliserer brukeren at han/hun mener at de verdiene som er lagt inn er som de skal være. Brukeren anser seg ferdig med oppgaven og forventer at vinduet lukkes. Avbryt fungerer som en angre-knapp, se nedenfor. I en meldingsboks vil OK ofte være eneste knapp. Ved å trykke på knappen forteller brukeren at meldingen er lest. Han/hun forventer at boksen forsvinner. Dersom du bruker OK sammen med Avbryt i en meldingsboks, pass på at brukeren forstår hva du mener. Meldingen må da beskrive en prosess som skal settes i gang. Meldingen må være en bekreftende setning, eksempel: Setter i gang arbeidsflyten “Søknad om kontokreditt”. Dersom brukeren velger Avbryt, må det være helt klart at det betyr at prosessen ikke settes i gang. Eventuelt kan en bruke spørsmålsform, der svaret er ja eller nei, eksempel: Skal arbeidsflyten “Søknad om kontokreditt” settes i gang? I dette tilfellet må brukeren få valget mellom en knapp med Ja (standardknappen) og en knapp med Nei. Den første formen (bekreftende setning med OK og Avbryt) bør brukes dersom meldingen er en naturlig følge av aktiviteter brukeren har gjort fram til det tidspunktet da meldingen kommer. Den andre formen (spørsmål) brukes dersom denne sammenhengen ikke er helt klar.

Avbryt


side 16 av 24

En Avbryt-knapp i en meldingsboks: Brukeren forventer at systemet stilles tilbake til den tilstand det var i før operasjonen som genererte meldingen startet. Boksen lukkes. I enkelte situasjoner er det ikke mulig å kansellere, bruk da Stopp i steden. En Avbryt-knapp i et dialogvindu: Brukeren forventer at innlagte verdier ignoreres. Dersom vinduet inneholder Lagre- eller Bruk-knapp skal innlagte verdier etter siste anvendelse av disse knappene ignoreres.

Lagre En transaksjon er en enhet med arbeid, sett fra brukerens synsvinkel. Lagre betyr at brukeren anser seg ferdig med en (eller flere) transaksjon(-er). Lagre betyr ikke at vinduet automatisk skal lukkes.

Bruk Denne knappen anvendes vanligvis i egenskapsark (“property sheet” - for å sette f.eks. en font i Word). Der betyr den at de foreslåtte endringer skal tas i bruk, men vinduet skal ikke lukkes. Knappen bør ikke brukes i samme vindu som Lagre-knappen, selv om [Microsoft 1995] antyder at det kan være aktuelt. De sier at Lagre skal brukes for "commiting transactions at the file level" (p. 64), mens Bruk kan anvendes "on a level with finer granularity … for handling transcation within a file" (p. 65). Jeg vil tro at for de fleste aktuelle anvendelser er det bedre å bruke Lagre enn Bruk.

Lukk Dersom programmet viser fram data uten at brukeren har muligheter til å endre disse, kan man ha en Lukk-knapp i stedet for OK og Avbryt. Sørg i tilfelle for at det skjer det samme som når brukeren lukker vinduet på annen måte.

5. Dialogtyper Når vi skal utforme brukergrensesnittet må vi først bestemme hva slags dialogtyper en vil ha i programmet. De viktigste dialogtypene er: • Menyer: Brukeren velger fra menyer • Kommandoer: Brukeren skriver inn kommandoer • Direkte manipulering: Brukeren manipulerer på sine data eller på objekter på skjermen. • Skjemaer: Brukeren fyller ut data i skjemaer. • Spørsmål og svar: Dialogen foregår ved at brukeren svarer på spørsmål fra systemet


side 17 av 24

5.1. Spørsmål og svar

• Systemet stiller spørsmål, brukeren svarer • Fordeler

– Enkelt for nye brukere • Ulemper

– Kan ta mye tid

– Det er systemet som styrer dialogen, ikke brukeren

5.2. Menyer • Systemet viser valgmuligheter, brukeren velger blant disse • Det kan være flere nivåer av menyer • Fordeler

– Alle mulige valg er oppgitt på skjermen. Brukeren trenger ikke huske alle mulighetene

– Gir mulighet for en logisk struktur • Ulemper

– Egner seg ikke når det er for mange valg

– Langsomt for vante brukere

5.3. Direkte manipulering Eksempler: Endring i tekst i en tekstbehandler. Flytting av filer i Windows sin filbehandler • Brukeren arbeider direkte på sine data eller symboler som representerer data

1. Velg et objekt


side 18 av 24

2. Velg en aksjon for dette objektet • Vanlig i tekstbehandlere og vindussystemer • Fordeler:

– Brukeren styrer dialogen

– Gir mange muligheter

– Det er mulig å bruke symboler/bilder fra den virkelige verden

5.4. Kommandobasert dialog Eksempel: MS DOS.

copy *.doc A:

• Fordeler:

– Raskt for vante brukere

– Mange muligheter • Ulemper

– Vanskelig å huske kommandoer

– Vanskelig for nye brukere

5.5. Skjemautfylling Eksempel fra MS Project:

• Brukeren fyller inn data i et skjema • Egnet når mye data skal registreres, f.eks. i administrative systemer

Viktig med ryddige og oversiktlige skjema. Feltene bør ha en logisk rekkefølge og være logisk gruppert. Brukeren bør kunne velge hvilken rekkefølge hun vil fylle ut dataene.


side 19 av 24

6. Bruk av farger Ingen ser farge helt på samme måte eller med samme intensitet. Farger oppfattes som et rent fysisk fenomen som registreres ved hjelp av synssansen. Som en form for energi er farge aktiv på alle nivå av vårt vesen – mentalt, emosjonelt, fysisk og åndelig. Virkningen er ikke begrenset til bare det vi ser. Forskjellige mennesker opplever farge ulikt, de har forskjellig fargebilde. Dette gjør at ulike personer kan oppfatte et og samme maleri helt forskjellig. Hvis noen sier gul i en forsamling av 30 mennesker vil det være 30 gul i deres tanker og en kan være sikker på at alle disse gul er forskjellige farger (Josef Alberts 1975). En god regel for bruk av farge er å sørge for at brukergrensesnittet fungerer i en sort/hvit skjerm før en legger på farge.

6.1. Farger er viktige Riktig bruk av farger er av avgjørende betydning ved design av brukergrensesnitt. Tross dette er det skrevet lite om bruk av farger i bøker om brukergrensesnitt. Farger har mange ulike informative budskap f.eks. rødt betyr fare, med grønt forstår vi klart eller systemet er ok, gult kan bety risiko eller billig osv. Videre vil mennesker med svekket fargesyn oppfatte farger på en helt annen måte enn de med normalt fargesyn. To farger som gir god kontrast for noen mennesker vil for de med svekket fargesyn være vanskeligere å skille.

For en person med svekket fargesyn vil panelet til venstre i figuren fortone seg slik som panelet til høyre vil gjøre for en person med normalt fargesyn.

Vår fagereaksjon er så fundamental at når 5-6 år eller eldre blir bedt om å sortere fargede former, begynner de automatisk å dele dem inn etter farge og ikke etter form. Senere i oppveksten vil gutter og jenter utvikle seg forskjellig. Mens jentene oppretholder sitt reaksjonsnivå på farger, begynner guttene å reagere mer på former.

6.2. Lesbarhet og farger. God lesbarhet av tekst og symboler er viktig ved design av brukergrensesnitt. Særlig hvis en skal skrive ut dokumentet kan store deler bli uleselig ved feil bruk av farger. Vi skal se på noen eksempler av fargebruk:


side 20 av 24

I figueren over er samme fargetekst skrevet på en sort og hvit bakgrunn. Det er lett å se at det som vi oppfatter som mørke tekster er vaskelig å se mot en mørk bakgrunn. Tilsvarende for lyse tekster mot lys bakgrunn.

Her ser vi at uthevet tekst øker lesbarheten.


side 21 av 24

Denne figuren viser hvor vanskelig det er å lese farger. Alt for mange glemmer dette ved utforming av brukergrensesnitt og er mer opptatt av å bruke farger enn å bruke dem riktig.

Her ser vi et eksempel på forholdet mellom tekst og bakgrunnsfarge. Hvis det er ønskelig med en farget bakrunn, vil den fungere best med sort eller hvit tekst.

Hvis en allikevel ønsker å ha farge i både tekst og bakgrunn, så bør en velge en blek bakgrunnsfarge innen samme farge som teksten eller i en komplementær farge.


side 22 av 24

Et viktig prinsipp ved valg av farger er at en aldri skal ha sterk bakgrunnsfarge når en har farget tekst.

I det øverste feltet ser vi at bruk av farger uthever teksten og gir prioritet. Det nederste feltet virker klart forvirrende på leseren. Det er fordi for mange farger forstyrrer øyets normale scanningsprosess.

Selvforklarende!!


side 23 av 24

6.3. Hvorfor anvende farger? Hensikten er å presentere ting på en naturlig måte, slik vi kjenner dem fra naturen. De ulike objekt på skjermen representerer symboler som vi assosierer med virkeligheten, og da er det viktig å bruke farger som samsvarer med det vi kjenner fra før. Farger kan brukes for å differensiere melom ulike objekt eller også for å tiltrekke og styre oppmerksomheten. dette skjer bl.a. ved utheving av tekst med farge - f.eks. hyperlenker som ofte har blå tekst – og ved at en knapp får en farge når den er aktiv. Farger kan også brukes for å skape en viss stemning.

6.4. Regler for fargebruk.

1. Vær konsistent i bruk av farger

2. Sørg for god kontrast mellom data og bakgrunn

3. Unngå å kombinere farget tekst med sterkt farget bakgrunn

4. Bruk sterke farger med stor forsiktighet

5. Gjør det riktig i sort/hvit (8% av menn i den vestlige verden er fargeblind)

6. Antall farger i et gitt skjermbilde bør begrenses til 4 pr. skjermbilde og 7 for et

system som et hele

7. Vær oppmerksomme på utbredte forventninger om farger

8. Forstå hvordan farger kan utnyttes i kodingsteknikker, bl.a. til å øke

gjenkjenningshastigheten. 9. Fargekoding skal komme fram med minimalt arbeid for brukeren. (F. eks.

automatisk farge på overtrukne konti)

10. Fargekoding bør kunne styres av brukeren

11. Farger kan hjelpe til med ”formatering” f. eks. til å gruppere objekter som

hører sammen

12. Benytt fargepar som passer sammen. Rød og blå ligger på hver sin side av

fargespekteret. (Øyet vil bli anstrengt hvis man må fokusere begge farger samtidig)

13. Benytt farger til å gjøre brukeren oppmerksom på endringer i status til et

system. F. eks. så skifter et digitalt speedometer farge når fartsgrensen overskrides


side 24 av 24

14. Benytt farger til å lage geografiske oversikter med mye informasjon

15. Velg farger i rommet som ikke stjeler oppmerksomheten fra skjermbildet

16. Bruk hvis mulig nøytralt farget lys(hvit) for opplysning av rommet

7. Verktøy for design av brukergrensesnitt Etter hvert har det kommet en del gode dataverktøy for design av brukergrensesnitt. Med mange av disse verktøyene kan en tegne opp skjermbildene omtrent som i et tegneprogram. Systemet genererer deretter programmet mer eller mindre automatisk.

Mest utbredt er kanskje såkalte 4. generasjonsverktøy, der en både utformer database og brukerdialog. I mange verktøy for utvikling av programmer (kompilatorer, programmeringsomgivelser o.l) finnes det nå muligheter til lett å kunne tegne opp vinduer og skjermbilder som programmene skal bruke. For Windows kan jeg nevne Visual Basic, Visual C++ og Borland C++ & application frameworks. For UNIX og X-windows har vi systemet TeleUSE.

8. Referanser Brad A. Myers: Challenges of HCI Design and Implementation

Jakob Nielsen: The Usability Engeneering Life Cycle

W.E. Gilmore m.fl.: User Computer Interface in Process Control

Documents

Leksjon 7: Brukergrensesnitt - NTNUStiftelsen TISIP i samarbeid med Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Brukergrensesnitt side 3 av 24 Brukergrensesnitt