UNIVERSITETET I OSLO Institutt for informatikk INF4260 Endelig rapport Vidar Johansen (vidaj) Hanne Johansen (hannj) 3. desember 2007 Av Hanne Johansen og Vidar Johansen 1
Table of Contents Introduksjon...3 Begrepsmodell (Conceptual Model)...3 Eksisterende planleggere...4 Bruksområde...4 Brukere...4 Brukertyper...4 Forutsetninger...5 Funksjonelle...5 Data...6 Brukskontekst...6 Brukerkarakteristikker...6 Mål for brukskvalitet (usability)...8 Mål for brukeropplevelsen...8 Prototype...8 Fase 1: Ikke i bruk...9 Fase 2: Velg reise...11 Velg reisemål...12 Velg reisestart...12 Velg reisedato...13 Velg tidspunkt for avreise...13 Valg av transportmiddel...14 Fase 3: Velg riktig reise...14 Fase 4 Detaljert reiseinformasjon...15 Fase 5 Vis kart...16 Videre arbeide...17 Av Hanne Johansen og Vidar Johansen 2
Introduksjon Vårt prosjekt har gått ut på å utforme en prototype for en reiseplanlegger som er tilgjengelig på stoppesteder for kollektivtransport. Det eksister allerede flere typer reiseplanleggere (www.nsb.no, www.trafikanen.no, tlf: 177 osv.), men ingen som er enkelt tilgjengelig på selve holdeplassene. Vi ønsker derfor å utforme et produkt som kan uplasseres på holdeplassene som skal kunne gi informasjon og veibeskrivelse om en reise. Reiseplanleggeren skal ikke utstede billetter, men kun gi informasjon om reisen. Tanken bak prosjektet er at det finnes mange som skal et sted de ikke helt vet hvor er. De har kanskje ikke rukket å finne ut av reisedetaljene før de dro hjemmefra og står litt fast på hvilke transportmiddel de skal bruke og hvor de skal gå. Vår reiseplanlegger skal da være plassert ut ved de fleste holdeplasser slik at brukeren enkelt kan finne frem til reisemålet sitt og få se et kart over området med reisebeskrivelse. Begrepsmodell (Conceptual Model) Vi skal designe et system som gjør det enkelt for en bruker å finne frem til en holdeplass eller adresse. Brukeren skal enkelt kunne: velge destinasjon: som holdeplass som adresse endre dato for reisen endre klokkeslett for reisen endre startpunkt for reisen hvis man vil planlegge for reiser fra en annen holdeplass velge bort transportmidler for å begrense søket. velge språk for grensesnitt. Med disse valgmulighetene skal brukeren enkelt kunne spesifisere parametere for å finne akkurat sin reise. For å gjøre parameterspesifiseringen raskere vil dato automatisk være satt til dagens dato og klokkeslett være satt til nåværende tidspunkt. Planleggeren skal kunne: Ta imot data fra brukeren Finne reiser basert på brukerens parametere Vise en liste over aktuelle reiser begrenset av brukerens parametere Vise detaljert informasjon om en reise når brukeren ber om det Vise kart over reisen med start- og sluttpunkt tegnet inn, samt ruten reisen tar. Gi mulighet for lagring av reisen til mobiltelefon. Tekstmelding med reisebeskrivelse Tekstmelding med link til en nettside hvor man kan se resultatet av søket med kart. Av Hanne Johansen og Vidar Johansen 3
Eksisterende planleggere Det finnes flere reiseplaneggere man kan bruke for å planlegge en reise. For kollektivtransport i Oslo og Akershus har man www.trafikanten.no. For togtransport kan man planlegge reisen på nsb.no. For ruteinformasjon for hele landet har man Ruteopplysningen 177 på telefon. Problemet med disse planleggerne er at det er kun Ruteopplysningen 177 man kan bruke når man allerede har startet reisen. For å benytte seg av de andre planleggerne trenger man en datamaskin eller telefon med internettilkobling, noe som ikke alltid er tilgjengelig. Ruteopplysningen 177 krever at man må ha med seg telefon samt at det koster penger (tellerskritt). Google har en nettbasert reiseplanlegger som heter Google Transit [Google Transit]. Denne ser veldig lovende ut og er meget enkel å bruke. Desverre finnes den kun for fire byer i Europa, hvor ingen er i Norge. Vi har brukt denne siden som inspirasjon til vårt prosjekt. Bruksområde Hensikten med prosjektet er å gi brukerne muligheten til å finne frem til en adresse/holdeplass når personen allerede har startet reisen. Den skal være helt gratis å bruke. Man skal ikke trenge å ha med mobiltelefon eller datamaskin for å bruke systemet. Brukere Brukerne av dette systemet vil være de samme som bruker kollektivtransport. Vi har valgt å se på alle brukerne i en gruppe, men heller gruppere typen reise de er på. Vi har endt opp med to typer reiser: Kjent reise En reise man tar ofte. Ukjent reise En reise man sjeldent eller aldri har tatt før. Reisende med kjent reise vet allerede hvordan de skal komme seg frem til målet, så disse antas det sjeldent eller aldri kommer til å bruke systemet. Reisene med ukjent reise er derfor fokusgruppen vår. Brukertyper En reisende med ukjent reise er en veldig udefinert bruker. Forskjellige typer personer har forskjellige behov som vi må ta hensyn til når vi utvikler planleggeren vår. Ved å observere personer som bruker kollektivtransport har vi kommet frem til følgende forskjellige typer brukere: Voksne Vanlige kvinner og menn som kan norsk Barn Små personer som reiser alene. Eldre Eldre kvinner og menn Funksjonshemmede Personer med en eller flere typer funksjonshemninger. Vi har valgt å fokusere på de typene som er nevnt i [Interaction Design] side 483, pluss et par ekstra: Fargeblindhet Dysleksi Av Hanne Johansen og Vidar Johansen 4
Fyskiske funksjonshemninger Svaksynthet Blindhet Turister Personer som ikke er norske og som ikke er bosatt i Norge. Innvandrere Denne typen beskriver personer som er bosatt i Norge, men som ikke kan norsk eller kan språket dårlig. Ny bruker Person som sjeldent eller aldri har brukt systemet før. Erfaren bruker Person som kjenner systemet godt. Forskjellige typer kan kombineres til å lage den faktiske brukeren. F.eks funksjonshemmet (dyslektisk) barn som er ny bruker og eldre innvandrer med fysisk funksjonshemning (sviktende motorikk). Ved å støtte hver type hver for seg bør det ikke være problematisk å kombinere typene til en bruker. Forutsetninger Her beskriver vi de forutsetningene vi har satt og samlet inn for prosjektet. Forutsetninger er definert i [Interaction Design] (side 476): «A requirement is a statement about an intended product that specifies what it should do or how it should perform» På side 478-479 i samme bok er det definert en del forskjellige typer forutsetninger som vi har valgt å følge for å gruppere forutsetningene våre. Funksjonelle De rent funksjonelle forutsetningene er allerede definert i avsnittet Begrepsmodell. For litt mer fysiske forutsetninger så er det viktig at systemet er billig å produsere slik at det er lettere å sette ut planleggere på alle holdeplasser uten at det koster alt for mye. Vi tenker oss at systemet kan brukes via en trykk-sensitiv skjerm. All input av tekst gjøres ved å trykke på et virtuellt tastatur som kommer opp på skjermen. Dette gjør at programvaren kan kjøre på allerede eksisterende maskiner som har trykk-sensitiv skjerm. På stasjoner med generellt lite trafikk, men som har en av de nye billettautomatene til Oslo Sporveier eller NSB, så kan det være mulig å integrere programvaren inn i billettautomatene og på denne måten kutte kostnadene betraktelig. For å redusere utgiftene til vedlikehold kan det være effektivt å lage selve planleggeren som en tynnklient hvor programvaren kjøres fra en sentral tjener. Siden planleggeren skal kunne finne tidspunkt for reiser må den være tilkoblett internettilgang, så da er det enkelt å lage planleggeren som en tynnklient. Dette gjør det enkelt å oppgradere alle maskinene samtidig hvis det blir endringer i programvaren. Kostnadene til maskinvare på klientsiden vil også synke siden det kreves mindre av en maskin å kjøre som tynnklient. Av Hanne Johansen og Vidar Johansen 5
Data Vi ser for oss at all data til og fra planleggeren utføres via remote procedure calls i XML. Dette gjør det enkelt å koble seg på allerede eksisterende systemer fra NSB og Oslo Sporveier. (Finner ingen referanser til dette, men vet dette pga erfaring fra arbeid med systemet til NSB. Antar at Oslo Sporveier har gjort det på samme måten.) På denne måten eksisterer allerede mange av tjenestene som trengs for å implementere planleggeren. Brukskontekst Planleggeren må tåle å både stå ute i all slags vær, såvel som inne. Veldig mange av holdeplassene til NSB, Oslo Sporveier og Stor-Oslo Lokaltrafikk er ute og gjerne uten tak. Systemet kan være i omgivelser med mye støy og stor trafikk, så for å være mest mulig skånsom med miljøet må det være lydløst. Det må også være internettmuligheter der planleggeren skal brukes, enten via trådløst/mobilt internett eller kablet internett. Brukerkarakteristikker Hver av brukertypene nevnt i begrepsmodellen har forskjellige behov og krav. Vokse Disse har ingen spesielle krav. Barn - Dette er en en brukertype som lett blir distrahert og krever at produktet er enkelt å bruke med klare veiledninger for hvert steg. Hold grensesnittet rent og bruk gjerne bilder for å fange oppmerksomheten til riktige elementer. Eldre - Denne brukertypen er den som har det mest vanskelig for å lære nye ting. Grensesnittet må være intuitivt og enkelt å forstå, gjerne basert på velkjente metaforer. Det må være enkelt å gå tilbake å endre parametere hvis man har tastet feil. Funksjonshemmede Fargeblindhet Wikipedia [Wikipedia - Color blindness] skriver at man bør unngå å beskrive informasjon med farger. Dette innebærer f.eks. at man ikke bør angi feilmeldinger som rød tekst uten å angi kontekst på andre måter. Man bør også bruke klare kontraster mellom bakgrunns- og forgrunnsfargene slik at teksten ikke oppleves som forsvunnet. Dysleksi Accessibility101 [Accessibility101] angir en liste med teknikker man bør følge for å designe websider som er lettere å bruke for personer med dysleksi. Disse gjelder i stor grad for dette systemet også. Her er det verdt å nevne ting som Stor skrift. Unngå ord i bare store bokstaver for ekstra trykk på ordet. Unngå også kursiv. Ha mellomrom mellom paragrafer for å bryte opp teksten. Paragrafer bør også være korte. Bruk samme størrelse på mellomrom mellom ord. Bruk korte ord der det er mulig og skriv enkle setninger. Referer til bruker som «Du». Ikke bruk bevegende tekst. Dette er vanskelig å fokusere på og stjeler også fokus fra Av Hanne Johansen og Vidar Johansen 6
andre elementer på skjermen. Bruk bilder for å illustrere innholdet av teksten. Ved å følge disse enkle reglene for systemdesign vil man også oppnå (forhåpentligvis) at systemet er enkelt å bruke og lite forvirrende. Fysiske funksjonshemninger Det finnes mange typer fysiske funksjonshemninger. Her er det verdt å nevne muskelsvinn/sviktende muskelmotorikk. Dette er spesiellt vanlig hos eldre personer. Grensesnittet må derfor være responsivt for lette trykk, slik at man ikke trenger å trykke hardt på knappene for at det skal reagere. I tillegg bør knappene være store slik at de er enkle å treffe. Det er også et krav at man kan har armer eller tilsvarende funksjonalitet slik at man kan operere en trykk-sensitiv skjerm. Svaksynthet Mary Walker skriver i [Internet Accessibility] om en del tips for å designe nettsider for blinde og svaksynte. Her er det en del relevant informasjon som vårt grensesnitt kan ha nytte av: Ha mye tomrom rundt elementer på siden. Unngå «flislagt» bakgrunn, siden teksten fort kan bli utydelig. Bruk høy kontrast mellom tekst og bakgrunn. Skriv dato i fulltekst, dvs Februar 28, 1996 og ikke 28/02/96 siden det ofte kan oppfattes feil. Dette gjelder også for turister, siden det ikke er ett standard datoformat i alle land i verden. Ellers tar også dysleksi-teknikkene for seg temaer som er viktig for svaksynte. Blindhet Turister Denne gruppen er ekstremt vanskelig å ta hensyn til i vårt system. En mulighet vil være at maskinen leser opp all informasjonen som står på skjermen og kan styres med stemme. Dette vil mest sannsynligvis føre til stor sjenanse for andre reisende på holdeplassen og blir fort et problem ved høyt traffikerte holderplasser. En annen mulighet er å inkludere en Braille-list i maskinen slik at de blinde kan lese det som står på skjermen. Dette vil bli alt for dyrt å produsere til at produktet kan bli effektivt distribuert til alle holdeplasser. Vi har derfor valgt å ekskludere blinde fra vår brukergruppe og heller henvise de til andre typer reiseplanlegging som allerede eksisterer og som er tilrettelagt for blinde, vi tenker da her på Ruteopplysningen 177 på telefon. Turister er her den typen brukere som ikke kan norsk. Her er det vitalt for systemet at det er flerspråklig, og at det må være enkelt å skifte språk. Skal vi følge det gamle ordtaket «Et bilde sier mer enn tusen ord», er det lurt å angi språkvalg ved å trykke på flagget til de respektive språkene. Dette eliminerer også unødvendig tekst på siden, som gjør den mer ryddig og lettere å lese. Det er også intuitivt at man endrer språk ved å trykke på et flagg. For at flest mulig skal kunne bruke planleggeren har vi bestemt at den minst bør støtte følgende språk Norsk Engelsk Av Hanne Johansen og Vidar Johansen 7
Spansk Tysk Fransk Innvandrere Stor sett de samme kravene som turister. Ny bruker For at nye brukere lettest og raskest mulig skal bli erfarne brukere, bør det være hjelpetekster på alle skjermene som enkelt forklarer hva som skal gjøres for hvert steg. Erfaren bruker En erfaren bruker vil gjerne at hjelpetekstene som nye brukere trenger er godt gjemt bort, siden disse fort blir irriterende når man vet nøyaktig hva som skal gjøres. Dette kan løses elegant ved å ha en egen «Hjelp» knapp på hver side hvor hjelpeteksten kommer opp i en ny dialog, slik at denne ikke forstyrrer designet for hovedsiden. Mål for brukskvalitet (usability) Brukskvalitet kan være vanskelig å definere siden det er en subjektiv opplevelse. Jacob Nielsen [Nielsen 1993] har lagd et system for å kunne si om et system har brukskvalitet, hvor det må oppfylle en rekke krav: Lett å lære, så brukere kan og raskt fra å ikke kjenne systemet til å gjøre noe arbeid. Effektivt, lar ekspertbrukeren oppnå en høy grad av produktivitet. Lett å huske, så brukere med lav brukshyppighet kan returnere etter en periode med inaktivitet uten å måtte lære alt på nytt. Relativt feilfritt og feiltolerant, slik at brukere ikke gjør mange feil, og at disse feilene ikke er katastrofale (og at man lett kan ta seg inn igjen) Behagelig å bruke, tilfredstiller brukerne subjektivt, slik at de liker å bruke systemet. Mål for brukeropplevelsen Vi ønsker å lage et system som oppfyller alle kravene for brukskvalitet og som gir brukeren en tilfredstillende følelse etter reisen er funnet. Av Hanne Johansen og Vidar Johansen 8
Prototype Vi lagde først en prototype som viste første del av planleggeren vår. Etter en del tilbakemeldinger på denne har vi endret ganske mye på designet, og nå fått en prototype av nesten hele systemet som skal være enklere både å skjønne og å bruke. Illustration 1: Tidlig prototype. Forkastet Vi har lagd en ny prototype for grensesnittet basert på de forutsetningene vi tidligere har beskrevet. Protypen er lagd som en rekke bildet som skal illustrere hvordan systemet vil se ut. De eneste språkene vi kan her er norsk og engelsk, så i de skjermene hvor det er tekst på flere språk har vi brukt BabelFish [Babel Fish] til oversetting. Dette er mest sannsynligvis ikke riktig oversettelse, men det er kun ment som en illustrasjon. Bildene er krympet endel for få plass i rapporten. Tekst og figurer vil derfor kunne virke uskarpe eller ute av proposjoner. Av Hanne Johansen og Vidar Johansen 9
Fase 1: Ikke i bruk Når systemet ikke er i bruk vil det stå en velkomstskjerm som vil kunne se slik ut: Illustration 2: Velkomstskjerm - del 1 På denne måten forstår nye brukere med en gang hva maskinen gjør og at den kan brukes. Men den sier ingenting og hvordan man starter. For å få mer informasjon i velkomstskjermen uten at den skal bli overfyllt har vi valgt å dele den inn i to deler, som skifter etter et satt intervall, f.eks hvert 15. sekund. Del to vil kunne se slik ut: Illustration 3: Velkomstskjerm - del 2 Man kommer altså videre til neste steg i planleggeren ved å trykke på flagget for ønsket språk. Vi mener derfor at nye brukere skjønner hvordan de skal starte planleggeren ved å lese instruksjonene på del 1 og del 2, og erfarne brukere kan starte direkte bare ved å trykke på flagget. For de litt intuitive så vil man kunne prøve å trykke på flagget uten å lese teksten. Dette bringer oss videre til fase 2. Når man forlater fase 1 forsvinner også muligheten til å velge språk. Dette fordi det blir et penere og renere grenesnitt hvis man slipper å ha fem flagg på alle skjermene. For å endre språk må man trykke seg tilbake til Fase 1. Av Hanne Johansen og Vidar Johansen 10
Fase 2: Velg reise Illustration 4: Fase 2 - Oversikt Her ser vi hovedskjermen for valg av reise. Her ser man hvilke parametere som er satt, det er en klar merking av hva hver linje inneholder, og man kan endre innholdet ved å trykke på endreknappen. Hvis man er usikker på hva hvert element gjør, kan man trykke på spørsmålstegnet for å få en hjelpetekst som gir mer detaljert informasjon. Det er også en knapp for å velge bort transportmiddel man ikke ønsker å reise med. Av Hanne Johansen og Vidar Johansen 11
Velg reisemål Illustration 5: Fase 2 - Hjelp til reisemål Når man trykker på endre for å velge reisemål eller reisestart (fra, til) kommer det opp en ny skjerm som har et tastatur. Vi har valgt å bruke en litt modifisert versjon av et QWERTY-tastatur siden det er den typen tastatur som er vanlig å ha på alle norske datamaskiner. Noen taster er flyttet på for å bedre utnytte plassen, men dette bør ikke by på store problemer for brukeren. Når man begynner å skrive så kommer det opp en liste med de vanligste stoppestedene som man kan trykke på for å velge. Illustration 6: Fase 2 - Velg reisemål Av Hanne Johansen og Vidar Johansen 12
Velg reisestart Skjermen for valg av startsted vil se rimelig lik ut og er derfor ikke presentert her. Velg reisedato For at brukeren skal få et grensesnitt som han/hun er vant til fra dagliglivet har vi valgt å representere valg av dato som en typisk vegg-kalender. Illustration 7: Fase 2 - Velg reisedato Her velger brukeren den datoen han/hun vil reise på ved å trykke på firkanten for den dagen. Vi har her antatt at man oftest vil velge datoer som er i nær fremtid, slik at det er nåværende måned som kommer frem først. Man kan velge andre måneder ved å trykke på bildet av neste måned nederst i bildet. Igjen, hvis man er usikker på hva man skal gjøre så har man alltid hjelp-knappen tilgjengelig øverst til høyre. Vil man ikke velge dato trykker man bare på tilbake-knappen. Velg tidspunkt for avreise Her finnes det mange måter man kan representere valg av klokkeslett på. Man kan vise en typisk analog klokke som man kan trykke på og flytte viserne. Vi tenkte at dette ble litt for komplisert og valgte istedet en digital fremvisning hvor man trykker inn klokkeslettet men en num-pad lignene kontroller som de fleste kjenner igjen fra tastaturet til en datamaskin. Av Hanne Johansen og Vidar Johansen 13
Illustration 8: Fase 2 - Velg tidspunkt Valg av transportmiddel Ved å trykke på knappen «Velg transportmiddel» får man opp en dialog som man kan velge bort enkelte transportmiddel man ikke vil reise med. Illustration 9: Fase 2 - Velg transportmiddel Her får man «checkboxes» som man kan skru av og på ved å trykke på knappene. Av Hanne Johansen og Vidar Johansen 14
Fase 3: Velg riktig reise Når alle parametere er riktig fyllt ut og brukeren trykker videre skal systemet vise en liste over mulige reiser. En enkel representasjon av dette er å få en tabell med alle reisemulighetene. Denne tabellen har en scroll-bar som gjør at brukeren kan få se flere reiser enn det er plass på til på skjermen. Brukeren kan også sortere tabellen på felt ved å trykke på overskriften. Alt dette er beskrevet i hjelp-boksen. Illustration 10: Fase 3 - Velg reise Av Hanne Johansen og Vidar Johansen 15
Fase 4 Detaljert reiseinformasjon Når brukeren har valgt ønsket reise ved å trykke på den i tabellen og så trykket på knappen «Videre», viser systemet en mer detaljert reisebeskrivelse. Dette kan se slik ut: Illustration 11: Fase 4 - Detaljert reisebeskrivelse Her kan brukeren trykke på knappen «Vis kart» for å se et kart med beskrivelse av reisen, eller trykke på send sms for å sende reiseinformasjonen til sin telefon. Av Hanne Johansen og Vidar Johansen 16
Fase 5 Vis kart Her skal systemet vise frem et kart som angir reisestart og reisemål samt informasjon om hvor ruten går. Vi tenker oss at dette kan se ut på noe av samme måten som Google Transit viser kartene sine, bare en litt enklere utgave. Ideen bak kart-visningen er at brukeren skal kunne se hvor reisen går, samt hvor han/hun skal gå fra siste stoppested og frem til adressen brukeren skal til. Illustration 12: Skjermbilde fra Google Transit Videre arbeide Vi har lagd et par prototyper, en som ble forkastet etter tilbakemeldinger, og en som vi har stor tro på. Videre arbeide bør da innebære en grundig testing av denne prototypen for å se om den faktisk oppfyller de kravene og forutsetningene vi har satt. Her er det ønskelig med et stort utvalg testpersoner som inneholder alle de nevnte brukertypene. En evaluering av dette systemet kan gjerne bruke DECIDE-rammeverket ([Interaction Design] side 626). DECIDE spesifiserer en del kriterier som bør være med når en evaluerer en prototype: Bestemme målene for evalueringen Utforske spørsmål Velge en evaluerings-tilnærming og metode Bestemme de praktiske spørsmålene Bestemme hvordan man takler de etiske spørsmålene Evaluere, analysere, tolke og presentere innsamlet data Målet med å evaluere vår prototype bør være om folk liker den, kunne tenkte seg å bruke den og Av Hanne Johansen og Vidar Johansen 17
forstår den. Et annet mål bør også være om vi har klart å oppfylle alle forutsetningene vi har satt. Den beste tilnærmingen til evaluering av prototypen mener vi må være intervjuer. På denne måten kan man presentere prototypen på en slik måte at brukeren får en følelse av hvordan systemet ville vært i bruk hvis det var implementert. Det er vanskelig å få presentert prototypen via et spørreskjema. Man kan gjerne kombinere de slik at brukeren fyller ut et spørreskjema under intervjuet slik at det bli lettere å analysere og tolke dataene senere. Av hensyn til brukerne som er med i evalueringen bør all data samles inn anonymt. Det er derimot interessant å ha med informasjon om hvilke typer brukere tilhører. Men det er viktig å passe på å ikke ta vare på informasjon som kan identifisere brukeren. Brukeren må også være informert om hva den innsamlede dataen skal brukes til. Av Hanne Johansen og Vidar Johansen 18
Referanser Google Transit: Google, Google Transit, 2007, http://www.google.com/transit Interaction Design: Peerce, Rogers & Sharp,, 2007 Wikipedia - Color blindness: Collaboration, Design implications of color blindness, 2007, http://en.wikipedia.org/wiki/color_blindness#design_implications_of_color_blindness Accessibility101: JackP, Designing For Dyslexia, 2007, http://www.accessibility101.org.uk/tips/100.htm Internet Accessibility: Mary O. Walker, Designing Web Pages for Blind and Visually Impaired, 1998, http://www.scils.rutgers.edu/~mowalker/access05.htm Nielsen 1993: Jacob Nielsen, Usability Engineering, 1993 Babel Fish:, Babel FIsh oversetter,, http://babelfish.altavista.com/tr Av Hanne Johansen og Vidar Johansen 19