Utforming av brukergrensesnitt

1. Utforming av brukergrensesnitt Medlemsmøte DND 11.11.02 Kai A. Olsen Universitetet i Bergen/Høgskolen i Molde DND

2. Mål • Min oppgave er å forsøke å få dere til å: • Se behovet for gode brukergrensesnitt • Skape kritiske holdninger til våre egne og andres systemer • Lære av andres feil og suksesser • Få oversikt over grunnleggende prinsipper • Innblikk i standard metodikk • Forstå betydningen av testing og brukerrespons • 10% metoder og teknikker, 90% sunn fornuft Motivasjon

3. Historikk (HCI- Human Computer Interaction) • Xerox Parc (1975 - …) • Utviklet arbeidsstasjoner med grafiske skjermer • laserskriver • WYSIWYG tekstbehandling • Grafisk brukergrensesnitt • MacIntosh (1984) • Kommersialiserte ideene fra PARC • Rimelig PC med grafisk skjerm • Enkel i bruk • Nye markeder • ”Usability lab” for å teste programvare • Apple • IBM • Microsoft Motivasjon

4. . Stor gevinst av gode grensesnitt • Fjerne feil, reduserer feilfrekvens • Forenkler opplæring • Større effektivitet (”efficiency - effective operation as measured by a comparison of production with cost”) • Større produktivitet (”effectiveness - producing a decided, decisive, or desired effect”) • Gir mer fornøyde brukere • Bruke grensesnittet for å ”selge” systemet Motivasjon

5. .. 1 min. øving: Fjerne feil/redusere feilfrekvens • Bruker skal gi en dato • Hvilke problemstillinger har vi? • Hvordan kan dette implementeres? There is no medicine against death, and against error no rule has been found. Freud Motivasjon

6. Svar: Problemstillinger • Problemstillinger: • Forskjellig tegnsetting, f.eks: 02.03.02, 02/03-02, … • Forkortelser, f.eks: 2/3-02, 02/03-2002, • Navn og tall: 03, mars, … • Forskjellig rekkefølge: dag-måned-år, måned-dag-år, år-måned-dag • Nasjonale standarder forenkler: • I Norge er rekkefølgen vanligvis dag-måned-år, og vi forventer å gi inndata som tall. For tegnsetting gjelder mange varianter • Implementering: • Tekstfelt • Kombobokser • Grafisk, valg i kalender Motivasjon

7. Mens 20.03 gir: .. Dårlig eksempel Motivasjon

8. Akseptabel løsning • Enkel løsning • Svakheter: • Gir ikke full oversikt • Flere klikk • Dag og måned er uavhengig i HTML-grensesnitt Motivasjon

9. Bedre eksempel? Motivasjon

10. Feil har store kostnader • Irritasjon • Tidstap • Tap av data • Mister flyt i operasjonene • Lavere effektivitet • Reduserte muligheter for ansatte til å gjøre en god jobb • Misfornøyde kunder • Kunder og ansatte velger mindre effektive, men sikrere prosesser • Feil i produkter og tjenester Motivasjon

11. Mer alvorlige konsekvenser av feil i grensesnitt • Three Mile Island, Harrisburgh, Pennsylvania – på randen av kjernefysisk katastrofe • NSB, Årsta ulykken • Fellesdata, banktjenester borte i en uke • Fly: • Cessna: likeens spaker for flaps og understell • Airbus: Samme format på to instrumenter, glidevinkel og høydeforandring • Boeing: Svak kopling mellom angivelse av motordata og motor • USA, flygerne tok feil av pund og kilo • Våpenssystemer: • Manglende informasjon om høyde og hastighet førte til at amerikanerne skjøt ned et Iransk passasjerfly under Golfkrigen Motivasjon

12. Effektivitet og feil • Når alt virker som det skal: • Operasjonene går fort • Systemet blir usynlig (transparent) • Vi kan konsentrere oss om å gjøre jobben • Strømlinjeforming av operasjoner • Blir ”glad” i verktøyet • I feilsituasjoner: • Operasjonene går sakte • Grensesnittet blir meget synlig • Vi må konsentrere oss om systemet, mindre tid til den egentlige jobben • Irritasjon og stress, vi mister flyten og gjør gjerne nye feil • Ser oss om etter andre løsninger Motivasjon

13. Effektivitet i inndata • Mange systemer krever unødvendig mye inndata • En undersøkelse av eHandels butikker viste at 2 av 3 brukere gav opp, vesentlig på grunn av at systemet krevde for mye data • Ha en god begrunnelse for hvert dataelement som kreves • Data kan lagres: • I brukerprofiler • Fra siste kjøring • Makroer • Data kan ekstraheres: • Fra det brukeren har gjort til nå • Fra andre kilder (databaser) Motivasjon

14. 2 minutters øving • Vi har et system for å bestille flybilletter over Internett • En innloggingsrutine er påkrevet (for gamle kunder og nye kunder) • Det er lagt fram to alternativer plassering av denne: • I starten av prosessen • I slutten av prosessen, i forbindelse med betaling • Hvor vil du plassere innloggingsrutinen? Motivasjon

15. Eksempler • Dårlige: • Telefonbank, 64 tastetrykk for å betale en giro – kan gjøres med 14 • Braathens på telefon, ber om Wings nr. men vil i tillegg ha telefonnummer, adresse, m.m. • Gode: • Word: foreslår filnavn lik overskriften (første linje) i dokumentet • Office program: Automatisk retting, erstatning av ”f.eks” med ”for eksempel”, osv. • Amazon, kjenner oss igjen (ved bruk av ”cookies”), kundeprofil er lagret (”one click book order”) Motivasjon

16. 2 minutters øving • Dere har fått i oppdrag å utvikle det billettbestillingssystemet som telefonoperatørene til Braathens skal benytte • Hva kan dere gjøre for å effektivisere kontakten med kunden, som ringer inn for å bestille en flybillett? Motivasjon

17. . Brukereffektivitet (overse feil) Motivasjon

18. ... men ikke NSB og Braathens Hos Braathens er Gardermoen en ukjent flyplass, hos NSB er Oslo upresist. Men systemene vet heldigvis hvor Bergen er! Motivasjon

19. Effektivitet (understøtte brukerens oppgave) US Air forteller oss på hvilken datoer vi kan regne med å få økonomibilletter, hos SAS og Braathens må vi prøve oss fram. 01.04 kl. 08.00 - ikke det; hva med 01.04 kl. 12.00 - ikke det… Motivasjon

20. Fornøyde brukere • Når systemet • gjør det som brukeren forventer • er effektivt • hjelper brukeren til å gjøre en god jobb • Får vi: • Gode talsmenn/salgsfolk for systemet • Brukere som vil være meget skeptisk til å gå over til et nytt system Motivasjon

21. Grensesnitt som salgskanal • Fysiske produkter kan ofte vurderes: • ved å se på/teste produktet, prototypen eller modellen • Programvare er ikke like håndfast: • Usynlig • Komplekst • Det er kostbart og vanskelig å vurdere hvilken nytte en kan ha av systemet • Men, vi har lært at også abstrakte elementer (som filer, kommandoer) kan synliggjøres ved grafiske representasjonsmåter • Slik synliggjøring forenkler opplæring,og teknikken vil også kunne brukes til å gi kjøperen et intuitivt/raskt inntrykk av systemet og dets muligheter Motivasjon

22. Sentrale spørsmål • Hvor lang tid tar det før en kunde • Har god oversikt over systemets funksjonalitet • Har en god idé om hvordan systemet brukes • Ser hvilken effekt hun kan ha av systemet • Hvor mye tid er en kunde villig til å spandere på dette? Motivasjon

23. Eksempler (Unix, DOS): > Motivasjon

24. Eksempel (Access) Motivasjon

25. Eksempel (Et system for Oshaug Metall AS) Motivasjon

26. Motivasjon - konklusjon • Gevinsten ved gode grensesnitt kommer fram på mange områder • Apple, IBM og Microsoft mener at de får hundre dollar tilbake for hver dollar investert i sine ”usability labs” • Verdien ligger i grensesnittet: • Det kan finnes bedre tekstbehandlingssystem enn MS Word • Det eksisterer langt billigere systemer • Men hva koster det å få brukerne over til et nytt system? Motivasjon

27. SensitivitetstreningBrukergrensesnitt mål: ”når vi snubler i dørstokken skal vi snu oss og finne ut hvorfor” DND

28. Eksempler • Skilting: • Skilting til Flytoget (Nasjonalteateret stasjon) • Vegskilt (Hamar-Hamar-Hamar-Trondheim?) • Dersom vi må stoppe opp og spørre/lete er det sannsynligvis noe galt med skiltingen • Beskjeder: • Flytoget: ”Vi kommer nå til Oslo S. Dere finner taxi ute til venstre. Avstigning til plattform på høyre side...” • Telenor: ”Du vil nå få to valg. Privatkunder trykker 2, bedriftskunder...” • Telefonmenyer som ikke godtar ”type ahead” • Når Web systemet (Skattedirektoratet, SAS, …) tillater inndata selv når databasen ikke er tilgjengelig • Når Braathens ikke sjekker at mine profildata (kredittkort m.m.) er oppdatert før bestillingen starter • Når Web siden ikke gir adresse eller telefonnummer til organisasjonen Motivasjon

29. . 15 sekunds øving • Er do-rullen montert riktig? Motivasjon

30. Flere eksempler • Når menyelementer er lagret under feil heading (header/footer under view i Word) • Når Powerpoint gir meg advarsel for makroer, selv om presentasjonen ikke inneholder dette • Når Powerpoint ikke klarer å sette riktig fontstørrelse • Når standard format ikke godtas (dato/NSB) • Når begrensninger ikke er angitt (hvor kort/langt fram i tid kan vi bestille) • Når teksten blir uleselig • Når systemet er for smart (automatiske lister i Word, automatisk retting…) Motivasjon

31. Vi kan lære av andres feil og suksesser • Når du gjør feil, stopp opp • Hvorfor gjorde du feilen? • Har du gjort samme feilen før? • Er det feil i grensesnittet? • Kunne feilen vært unngått med et bedre system? • Når alt går glatt, forsøk å finne ut hvorfor! • Hvorfor er det så lett å ta T-banen i London, hvorfor er P-automaten så grei å bruke? • Det er tillatt å ”stjele” ideer fra andre Motivasjon

32. 10 sekunds øving • Vi leter etter tog den 20.03 og får en liste som dette med flere alternativ. • Hvordan kan dette forbedres ved å gi ytterligere informasjon? Motivasjon

33. Grunnleggende prinsipper for gode brukergrensesnitt DND

34. ”8 golden rules” • Standarder og konsistens • Snarveier for ekspertbrukeren • Gi informativ feedback • Reverserbare handlinger (”undo”) • Bruk lukkede dialoger • Unngå feil, god feilhåndtering • La bruker være i kontroll • Reduser hukommelsesbruk Motivasjon

35. Standarder • Standarder • ”Backoffice”, Apple, … • Presentert formelt som ”Guidelines” • Men også tilgjengelig indirekte gjennom systemene (for eksempel Word, Excel, … for Office-plattformen) • og gjennom de verktøy vi benytter (VB, Access, Java…) • Guidelines: • Lærebok • Beskrivelse av ”look and feel” i et grensesnitt • Håndboksmateriale (oversikt over fil ”extensions”, oversettelse av kommandonavn, bruk av cursor, …) Motivasjon

36. Hva skjer når vi flytter (ved å dra) en fil til en av disse tre ikonene? . Konsistens • Gjør det enklere å lære og å bruke systemet • Utforming av skjermbilder, til valg av ikoner og plassering av taster • Men ingen ”lov”, det kan være mange grunner til at vi skal bryte konsistensregler: Motivasjon

37. . 30 sekunds øving – finn inkonsistens Hvor finner du bolig til leie? Motivasjon

38. Snarveier for ekspertbrukeren • Mange av de løsningene vi bruker er enkle, men ikke alltid like effektive: • Valg i menyer • Mus-klikk • Viktig å tilby snarveier for ekspertbrukerne: • ALT + eller CTRL + alternativer • Makroer • Hjelp tilpasset ekspertnivået • Fleksibilitet (programspråk) • Vise linker før annen tekst, tekst før bilder i Web grensesnitt • ”Type-ahead” i tunge menysystemer (som i telefonbank) Motivasjon

39. Informativ feedback • Umiddelbar effekt av kommando (minimum som et timeglass) • Relevant feedback: • WYSIWYG • Bekreftelse på at operasjon er utført med melding • ”Slider” eller lign. som viser at operasjonen er initiert • Eksempler på manglende feedback • I mange Web systemer er brukerne usikre på om bestillingen er utført (bestiller ofte på nytt for sikkerhets skyld) • Mange system forteller ikke hvilken tilstand (”mode”) de er i Motivasjon

40. Gulf of evaluation: Få vurdert respons i forhold til mål. Gulf of execution: Få satt handlingen ut i livet Handlinger Respons .. Norman’s modell Mål Systemet Motivasjon

41. Mål Handlinger Respons Systemet .. Eksempel – Telenor’s telefonvekking Taster kode for vekking og tidspunkt. Får spesiell summetone som kvittering. Vi får respons, men kan ikke evaluere om målet er oppnådd. Motivasjon

42. Du har fylt ut denne siden på finn.no og skal starte søking. Er neste handling åpenbar? 1 minutts øving Motivasjon

43. Testing Vi utvikler det perfekte grensesnitt basert på gode kunnskaper om brukernes krav og bakgrunn, samt på vår egen faglig dyktighet. Deretter tester vi dette, for å finne hullene i vår kunnskap. DND

44. Testing kan være billig Jakob Nielsen Motivasjon

45. Testing kan være billig • Universiteter og Høgskoler med HCI kurs er interessert i realistiske test-case • Kan tilby store testgrupper (25 til 100 studenter) • Krever: • Komplette systemer som er greit å implementere • Begrenset opplæring Motivasjon

46. Testmetoder • Av utviklerne • Nødvendig som en første test • Begrenset verdi som slutt-test der det er stor avstand mellom utviklere og sluttbrukere • I laboratorier • Egne HCI-eksperter • Video-overvåkning • Prosesser for ”briefing” og ”debriefing” • I brukermiljøet • Ofte best • men kan være vanskelig i praksis • Observasjon kan være en god metode Motivasjon

47. Evaluering mens systemet er i bruk • Systemet kan registrere alle data om bruken: • Antall feil • Typer av feil • Tidsbruk m.m. • Valg av opsjoner • Frekvens i kommandobruk • … • Data kan overføres utviklere • Over Web • Email • Diskett… Motivasjon

48. Brukerrespons • Inviter til brukerrespons • ”Spørreskjema” • Mailadresser • Belønning… • Meget rimelig testing, ikke bare får en respons men brukerne får også en avledningskanal • Brukerne investerer i systemet gjennom å kommentere mangler, komme med forslag til forbedringer. • Tar vi hensyn til brukerkrav knytter vi disse nærmere til systemet, og det blir mer kostbart å gå over til et annet system Motivasjon

49. En liten historie …1 Til Kommunikasjonsdirektør Audun Tjomsland NSB BA NSB's Web sider Jeg underviser et kurs i brukergrensesnitt ved Institutt for Informatikk, Univ. i Bergen. Som en øving har studentene evaluert NSB's Web sider (ruteopplysning og billettbestilling). Listen over feil og mangler som studentene har funnet ligger på www.ii.uib.no/~erikaa/i192/nsb. Dette kan kanskje være til hjelp for å forbedre sidene. Mine studenter står sikkert til rådighet med å gi utfyllende kommentarer. Med hilsen Motivasjon

50. 2 Takk for interessen. Vi er interessert i alle gode innspill - og dette var jo et riktig krafttak. Vi skal ta henvendelsen seriøst; og vi har mottatt både en og to priser for sidene våre. Men vi tar henvendelsen seriøst - alt kan sikkert forbedres. Det forsøker vi å gjøre hele tiden. Så kan jo vi en dag vi har god tid, ta for oss sidene til UiB....Beste hilsenaudun tjomsland  Motivasjon