Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "11.11.2002DND1 Utforming av brukergrensesnitt Medlemsmøte DND 11.11.02 Kai A. Olsen Universitetet i Bergen/Høgskolen i Molde."— Utskrift av presentasjonen:

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

2 11.11.2002Motivasjon2 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

3 11.11.2002Motivasjon3 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

4 11.11.2002Motivasjon4 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.

5 11.11.2002Motivasjon5 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..

6 11.11.2002Motivasjon6 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

7 11.11.2002Motivasjon7 Dårlig eksempel Mens 20.03 gir:..

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

9 11.11.2002Motivasjon9 Bedre eksempel?

10 11.11.2002Motivasjon10 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

11 11.11.2002Motivasjon11 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

12 11.11.2002Motivasjon12 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

13 11.11.2002Motivasjon13 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)

14 11.11.2002Motivasjon14 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?

15 11.11.2002Motivasjon15 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”)

16 11.11.2002Motivasjon16 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?

17 11.11.2002Motivasjon17 Brukereffektivitet (overse feil).

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

19 11.11.2002Motivasjon19 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…

20 11.11.2002Motivasjon20 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

21 11.11.2002Motivasjon21 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

22 11.11.2002Motivasjon22 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?

23 11.11.2002Motivasjon23 Eksempler (Unix, DOS): >

24 11.11.2002Motivasjon24 Eksempel (Access)

25 11.11.2002Motivasjon25 Eksempel (Et system for Oshaug Metall AS)

26 11.11.2002Motivasjon26 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?

27 11.11.2002DND27 Sensitivitetstrening Brukergrensesnitt mål: ”når vi snubler i dørstokken skal vi snu oss og finne ut hvorfor”

28 11.11.2002Motivasjon28 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

29 11.11.2002Motivasjon29 15 sekunds øving Er do-rullen montert riktig?.

30 11.11.2002Motivasjon30 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…)

31 11.11.2002Motivasjon31 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

32 11.11.2002Motivasjon32 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?

33 11.11.2002DND33 Grunnleggende prinsipper for gode brukergrensesnitt

34 11.11.2002Motivasjon34 ”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

35 11.11.2002Motivasjon35 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, …)

36 11.11.2002Motivasjon36 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: Hva skjer når vi flytter (ved å dra) en fil til en av disse tre ikonene?.

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

38 11.11.2002Motivasjon38 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)

39 11.11.2002Motivasjon39 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

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

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

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

43 11.11.2002DND43 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.

44 11.11.2002Motivasjon44 Testing kan være billig Jakob Nielsen

45 11.11.2002Motivasjon45 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

46 11.11.2002Motivasjon46 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

47 11.11.2002Motivasjon47 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…

48 11.11.2002Motivasjon48 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

49 11.11.2002Motivasjon49 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

50 11.11.2002Motivasjon50 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 hilsen audun tjomsland

51 11.11.2002Motivasjon51 3 Sidene til UiB tok vi for oss et tidligere år. I dag er de derfor ikke like godt egnet som et negativt eksempel. Vi får håpe at vi kan trekke fram NSB som et godt eksempel i kommende kurs. I dag er dere dessverre i selskap med mange andre norske institusjoner, som f.eks. Braathens og SAS, og vi må stort sett gå til utlandet for å finne de gode Web sidene. -kai a. olsen

52 11.11.2002Motivasjon52 4 Tenkte jeg det ikke, utlendingene er alltid så mye flinkere. Svenskene også? Nå har vi ikke vurdert svenske system, men mitt poeng kan kanskje illustreres av følgende enkle eksempel: Går jeg til www.usair.com kan jeg oppgi PITSBURG som avreiseby. Det aksepterer systemet til tross for at jeg har glemt både en T og en H (PITTSBURGH). Usair har åpenbart som sin forretningsidé å selge billetter, ikke å drive stavekontroll. www.usair.com Oppgir jeg dato som 11/02 hos NSB får jeg følgende respons fra systemet: "Microsoft VBScript runtime error '800a000d'. Type mismatch: 'CInt'. /persont/r1_core.inc, line 680". Er det noen forretningsidé bak dette eller det kun lurvete programmering?...

53 11.11.2002Motivasjon53 2 minutters øving – håndtering av respons fra bruker Negativ brukerrespons kan oppfattes som kritikk av organisasjonen eller utviklerne Negativ respons kan føre til merarbeid Det er derfor grunner til at brukerrespons blir ignorert Hvordan kan vi sikre oss at brukernes kommentarer blir tatt alvorlig? For eksempel: Ombudsmann (som representer brukerne) Oversikter/statistikk.

54 11.11.2002Motivasjon54 Mål (oppsummering) Min oppgave var å forsøke å få dere til å: Se behovet for gode brukergrensesnitt Skape kritiske holdninger til de systemer som brukes i hverdagen Lære av andres feil og suksesser Få oversikt over grunnleggende prinsipper Innblikk i standard metodikk Forstå betydningen av testing og brukerrespons Deres jobb: Utnytte dette til å lage bedre brukergrensesnitt. 10% metoder og teknikker, 90% sunn fornuft

55 11.11.2002Motivasjon55 Kilder Bøker om brukergrensesnitt: Shneiderman ”Designing the User Interface”, Addison Wesley Preece, Rogers, Sharp ”Interaction Design”, Wiley Dix, Finlay, Abowd, Beale ”Human Computer Interaction”, Prentice Hall eller søk på ”HCI User Interface” hos Amazon Data presentasjon: Tufte ”The Visual Display of Quantitative Information”, Graphics Press Web sider: http://www-personal.umich.edu/~bing/oversite/hci.html (oversikt) http://www.useit.com/ (Jakob Nielsen) http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/558 (IBM) http://www.iarchitect.com/mshame.htm (”hall of shame”) http://www.microsoft.com/usability/ (Microsoft) eller søk på ”User Interface Design” i Google/Altavista/...


Laste ned ppt "11.11.2002DND1 Utforming av brukergrensesnitt Medlemsmøte DND 11.11.02 Kai A. Olsen Universitetet i Bergen/Høgskolen i Molde."

Liknende presentasjoner


Annonser fra Google