Hovedprosjekt Anvendt Datateknologi ved Høgskolen i Oslo vår 2010 Gruppe 20

Hovedprosjekt Anvendt Datateknologi ved Høgskolen i Oslo vår 2010 Gruppe 20 Anders Johansen Edvin Sulic Eirik Vesterhus Eirik Rud Iversen Tek Beng Tan

PROSJEKT NR. 20 Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL AUDIOKIOSK DATO 28.05.2010 ANTALL SIDER 198 PROSJEKTDELTAKERE Anders Johansen Edvin Sulic Eirik Vesterhus Eirik Rud Iversen Tek Beng Tan S148119 S148104 S148176 S148151 S148150 INTERN VEILEDER Frode Eika Sandnes OPPDRAGSGIVER Høgskolen i Oslo (www.hio.no) KONTAKTPERSON Frode Eika Sandnes, HiO SAMMENDRAG Selvbetjeningsautomat Berøringsskjerm Lydgrensesnitt

Overordnet sammendrag Selvbetjeningsautomater med berøringsskjerm blir stadig vanligere. Dette er en spennende teknologi, men har sine svakheter når det kommer til brukervennlighet. Blinde og svaksynte er en av brukergruppene som blir påvirket av dette. Mangelen av fysiske holdepunkter på skjermen gjør at navigasjon blir vanskelig. Dette resulterer i at de må ha hjelp for å bruke automaten, noe som ikke burde være nødvendig. Nettsidene til Blindeforbundet har retningslinjer for minibanker, nettbank og billettautomater. Under krav til billettautomater står følgende (Blindeforbundet, Krav til minibanker og billettautomater): «Unngå berøringsskjerm (touchscreen)» NSB er en av flere som i dag benytter berøringsskjermteknologi i sine billettautomater. Vår oppgave har vært å eksperimentere, generere ideer og realisere en proof-of-concept prototype som gjør det mulig for blinde og svaksynte å bruke automater med berøringsskjerm. Vi brukte starten av prosjektet til å innhente informasjon og tilegne oss kunnskap rundt temaet. Informasjonen ble analysert og brukt til utvikling av våre prototyper. Testing ble utført kontinuerlig under hele utviklingsperioden og tilbakemeldingene brukt til forbedring. Gruppen har hatt hovedfokus på fire strategier, men har også utforsket andre områder. Prototypene våre baserer seg alle på et lydgrensesnitt. Det vil si at brukeren får tilbakemelding gjennom lyd. Dette var et krav i oppgaveteksten, og en nødvendighet for vår målgruppe. Vi valgte til slutt en løsning, som etter omfattende brukertester demonstrerer at konseptet egner seg for blinde og svaksynte. Dette motbeviser Blindeforbundets retningslinjer for billettautomater.

Forord Denne rapporten inneholder dokumenter som er utarbeidet i forbindelse med prosjektet Audiokiosk. Rapporten er ment å leses av personer med tilknytning til prosjektet. Rapporten vil også være relevant for personer med interesse for området universell utforming. Vi håper at prosjektet på sikt vil kunne bidra til å minske det digitale skillet ved å tenke i nye retninger. Rapporten skal kunne leses av alle, men for å ha fullt utbytte av de tekniske aspektene er det anbefalt med grunnleggende IT-forståelse. Vi har gitt rapporten en struktur som vi føler vil gi en logisk og god leseopplevelse. Rapporten inneholder dokumentasjon om følgende: - Arbeidsprosess - Prototyper - Testing Rapporten kan brukes i forbindelse med undervisning, men da med tillatelse fra gruppen. Vi har valgt å la møtereferatene og arbeidsloggen kun være tilgjengelig på hjemmesiden til prosjektet: http://www.eeeat.net/audiokiosk Alle fungerende prototyper vil også være tilgjengelig for nedlasting fra samme side. Vi vil gjerne få takke følgende personer: Frode Eika Sandnes For å ha vært en bidragsyter og motivator gjennom hele prosjektet. Frode har stilt opp når vi trengte han. Vi har satt stor pris på hans kunnskap og samarbeid. Blindeforbundet Vi vil takke Blindeforbundet for deres samarbeid. Deres disposisjon av testlokaler og testpersoner har vært uunnværlig for prosjektets fremdrift. Irontech v/jørn Jensen For utlån av berøringsskjerm og nyttig kunnskap. Uten denne skjermen ville ikke prosjektet ha fått den dybden det har oppnådd. Activium v/ole Petter Braathen For lisenser til talesyntese. Anders Johansen Edvin Sulic Eirik Rud Iversen Eirik Vesterhus Tek Beng Tan

Innholdsfortegnelse Kapittel 1 Problemstilling og hypotese... 1 1.1 Oppgaven... 3 1.2 Situasjonen per i dag... 3 1.3 Ønsket resultat og virkning... 4 Kapittel 2 - Bakgrunn... 5 2.1 Anvendt Datateknologi... 7 2.3 Gruppen... 7 2.4 Valg av oppgave... 8 2.5 Høgskolen i Oslo... 8 2.6 Blindeforbundet... 9 Kapittel 3 - Behovsanalyse... 11 3.1 Universell utforming... 13 3.2 Digitale skiller... 14 3.3 Synshemminger... 17 3.4 Kontakt med interessenter og ressurspersoner... 20 3.4.1 Veileder og oppdragsgiver... 20 3.4.2 Blindeforbundet... 20 3.4.3 Irontech... 20 3.4.4 Activium... 21 3.4.5 Andre ressurspersoner... 21 Kapittel 4 - Research... 23 4.1 Kartlegging av ulike billettautomater... 25 4.1.1 Lærdom fra automatene... 27 4.2 Lydmuligheter i forbindelse med automater... 28 4.3 Berøringsskjermteknologier... 28 4.3.1 Våre erfaringer med forskjellige berøringsskjermer... 30 4.4 Relevant teknologi... 30 4.4.1 Android... 30 4.4.2 iphone... 31 Kapittel 5 - Prosjektutviklingsfase... 33 5.1 Arbeidsmiljø... 35 5.2 Tidsplan... 35 5.3 Dokumentasjon av arbeid... 36

5.4 Smidige metoder... 36 5.5 Idéskapende arbeid... 38 5.6 Utviklingsarbeid... 39 Kapittel 6 - Verktøy... 41 6.1 Dropbox... 43 6.2 Penn og papir... 44 6.3 Microsoft PowerPoint... 44 6.4 Voxit Budgie Pro... 45 6.5 Adobe Flash CS4... 45 6.6 E-Speaking... 46 6.7 Audacity... 47 Kapittel 7 Prototyping og testing... 49 7.1 Prototyping... 51 7.2 Prosedyre for utvikling av prototyper... 51 7.3 Hvorfor teste?... 52 7.4 Testmiljø... 53 7.4.1 Uformelle tester... 53 7.4.2 Formelle tester... 54 7.5 Absolutt og relativ... 55 7.5.1 Absolutt... 55 7.5.2 Relativ... 55 7.6 Kravspesifikasjon... 56 Kapittel 8 - Knappebasert... 59 8.1 QWERTY- vs ABC-tastatur... 61 8.2 Split4 (Prototype)... 65 8.3 Drag and Drop (Prototype)... 69 8.4 Numb3rs (Prototype)... 71 8.5 Cake8 (Prototype)... 74 8.6 Tap4 (Prototype)... 76 Kapittel 9 - Eliminering... 77 9.1 Stegis Stegern (Prototype)... 79 9.2 GeoElim (Prototype)... 83 Kapittel 10 - Swipe... 87 10.1 Teknisk løsning... 89

10.2 Swipe4 (Prototype)... 92 10.3 Swipe8 (Prototype)... 96 10.4 Scrollslide (Prototype)... 108 Kapittel 11 - Lyd... 111 11.1 Swipe8_ambient (Prototype)... 113 11.2 VoiceBob (Prototype)... 114 Kapittel 12 Ikke-realiserte konsepter... 117 12.1 Håndskriftsgjenkjenning... 119 12.2 Sonar... 119 Kapittel 13 Etter prosjektet... 121 13.1 Valgt løsning... 123 13.1.1 Mulige forbedringer... 124 13.1.2 Brukerdokumentasjon... 124 13.2 Etterord... 131 Kapittel 14 - Kilder... 133 Kapittel 15 - Appendiks... 139 15.1 Lavnivå prototype skisser... 141 15.1.1 Split4... 141 15.1.2 Numb3ers... 144 15.1.3 Tap4... 148 15.1.4 Scrollslide... 152 15.1.5 Swipe4... 155 15.1.6 Swipe8... 159 15.1.7 Stegis Stegern... 163 15.2 Rapporter av automater... 166 15.2.1 NSB billettautomat... 166 15.2.2 Flytoget billettautomat... 168 15.2.3 Flytoget billettløst kortautomat... 169 15.2.4 Saga kino billettautomat... 170 15.2.5 Ruter billettautomat... 171 15.2.6 Nordea minibankautomat... 172 15.3 Testrapporter... 173 15.3.1 Qwerty- vs ABC-tastatur... 173 15.3.2 Stegis Stegern... 176

15.3.3 Swipe8... 178 15.3.4 Numb3rs... 183 15.4 Swipe8 fargekombinasjoner... 185

Kapittel 1 Problemstilling og hypotese 1

2

1.1 Oppgaven Oppgaveteksten er som følger: «NSB har fått mye kritikk for sine billettautomater som er kun tilgjengelige for personer med akseptabelt syn da all interaksjon skjer via berøringsskjermen. I dette prosjektet skal gruppen eksperimentere, generere ideer og realisere en proof-of-concept prototype av et lydgrensesnitt mot NSBs billettautomat som gjør automaten mer tilgjengelig for sterkt svaksynte og blinde» Som oppgaven sier skal vi eksperimentere, generere ideer og realisere en prototype med et lydgrensesnitt. Denne prototypen skal være tilgjengelig og brukervennlig for både personer med synshemninger og for funksjonsfriske. 1.2 Situasjonen per i dag Per dags dato er det en utfordring for synshemmede å bruke berøringsskjermer. Det er hovedsakelig to grunner til dette: - Ingen fysiske holdepunkter - Ingen lydbasert tilbakemelding Andre automater som tillater mer klassiske inputmetoder, som tastatur, er lettere å bruke. Dette fordi brukeren kan føle knappene, og dermed kunne operere automaten. Som en del av vår research har vi testet brukervennligheten og funksjonaliteten til eksisterende automatløsninger som bruker berøringsskjerm som input. Dette var alt fra kinobillettautomater til NSBs billettautomat. Det er NSBs billettautomat som er utgangspunktet for alle våre prototyper, og all funksjonalitet denne innehar på nåværende tidspunkt er bevart så langt det er mulig. Billettautomaten har vært offer for mye kritikk. Norges Blindeforbund har vært en av de mest aktive i diskusjonen. Sverre Fuglerud, leder av seksjonen for informasjon og samfunnskontakt i blindeforbundet, sier følgende: «Vi har medlemmer som har fått utdelt NSBs moro-piller mot automatfobi, men mange av våre folk klarer ikke bruke automatene. Vi hører om noen som prøver å bruke automatene, men som får ut billetter med feil stedsnavn, og daglig hører vi om folk som ikke blir trodd på at de ser dårlig, de blir avkrevd gebyret av konduktørene» Resultatet av at blinde og svaksynte ikke kan bruke automatene, er at de må kjøpe billetter på toget, men dette medfører et gebyr på 20 kr. Personer som ikke har mulighet til å bruke automatene blir dermed straffet. 21. august 2008 sier Blindeforbundet i en artikkel på sine egne sider at de har seiret i NSB saken. Etter hardt press har NSB lagt seg flate i den omtalte gebyrsaken. Blinde og svaksynte slipper å betale gebyret, og NSB skal jobbe aktivt med å bedre brukervennligheten for synshemmede. Dette innebærer å øke skriftstørrelse og forbedre kontrasten på skjermen. I tillegg vil de se på utformingen av automatene generelt sett, og vurdere muligheten for et lydgrensesnitt. 3

To år etter har NSB ennå ikke kommet med forbedringer på automatene. 1.3 Ønsket resultat og virkning Vi ønsker å bidra til å gjøre automater med berøringsskjerm universelt utformet. Vår løsning skal muliggjøre bruk for flere brukergrupper. Vi håper også at teknologien vi utvikler ikke skal begrense seg til kun billettautomater, men også andre løsninger som nyttegjør seg av berøringsteknologi. Det er viktig at funksjonaliteten ved de eksisterende automatene blir bevart. Derfor er det viktig at det utvikles en løsning som er basert på berøringsteknologien som eksisterer i dag. Vi håper at resultatet av vårt prosjekt vil bli godt mottatt av alle interessenter, og at vår teknologi kan være et utgangspunkt for videre utvikling. 4

Kapittel 2 Bakgrunn 5

6

2.1 Anvendt Datateknologi Anvendt datateknologi på Høgskolen i Oslo er et bachelorstudie som gir deg bred kunnskap om mange fagområder innen IT. Studiet tilbyr tradisjonelle datatekniske fag som databaser, datanettverk og programmering, men også emner som engelsk, økonomi og ledelse. Prosjektarbeid står veldig sentralt i mange av fagene. Dette for å gi studentene erfaring med å samarbeide med andre, da dette er en vanlig arbeidsform i arbeidslivet. Studiet avsluttes med et hovedprosjekt der studentene har muligheten til å bruke kunnskapen de har opparbeidet seg gjennom studietiden. Vår tid som studenter ved Høgskolen i Oslo har vært lærerik og er en tid vi aldri vil glemme, og vi føler oss forberedt på arbeidslivet. 2.3 Gruppen Vi ble tidlig kjent med hverandre og har jobbet sammen gjennom alle de 3 årene vi har gått på høgskolen. Dette medfører at vi har god kommunikasjon oss i mellom, og kjenner til styrkene og svakhetene til hver enkelt person. Av den grunn kan arbeidsoppgaver fordeles på en god måte slik at vi får en effektiv og produktiv arbeidsprosess. Navn: Født: Ansvarsområde: Anders Johansen 1988 Testansvarlig Navn: Født: Ansvarsområde: Edvin Sulic 1988 Lydansvarlig Navn: Født: Ansvarsområde: Eirik Rud Iversen 1988 Hovedrapportansvarlig 7

Navn: Født: Ansvarsområde: Eirik Vesterhus 1984 Gruppeleder Webansvarlig Navn: Født: Ansvarsområde: Tek Beng Tan 1987 Sekretær 2.4 Valg av oppgave Høsten 2009 ble det lagt ut forslag til hovedprosjektoppgaver, og vi bet oss fort merke i oppgaven ved navn Audiokiosk. På grunn av gruppens tidligere erfaring innen universell utforming og HCI (Human-computer interaction) mente vi at vi hadde gode nok kvalifikasjoner til å løse oppgaven. Å opparbeide seg kunnskap rundt dette temaet er noe vi tror vil være viktig i tiden framover. Dette vil gi oss en fordel og gjøre oss attraktive i jobbmarkedet. Vi tok raskt kontakt med veileder og oppdragsgiver Frode Eika Sandnes og ble tildelt prosjektet etter et kort informasjonsmøte. 2.5 Høgskolen i Oslo Høgskolen i Oslo er per dags dato landets største statlige høgskole. Skolen ble opprettet i 1994 og har i dag over 12 000 studenter og 1250 ansatte. Skolen tilbyr 33 bachelorstudier og 18 masterstudier som er fordelt over 7 avdelinger. Avdelingene består av: - Estetiske fag - Helsefag - Ingeniør - Journalistikk, bibliotek- og informasjonsfag - Lærerutdanning og internasjonale studier - Samfunnsfag - Sykepleierutdanning Flere av utdanningstilbudene ved høgskolen er HiO alene om å tilby i Norge. I tillegg har HiO et doktorgradsprogram i profesjonsstudier. 8

Internasjonal utveksling er noe HiO satser mye på. Forskning er vektlagt, og mye av fag- og forskningssamarbeid skjer på internasjonalt nivå. Et av HiOs satsningsområder er universell utforming. Som eneste høgskole i Norge tilbyr ingeniøravdelingen et emne dedikert til dette fagområdet. Det jobbes også med en mastergrad innen dette. 2.6 Blindeforbundet Blindeforbundet er en av Norges eldste organisasjoner for funksjonshemmede, og har mer enn 100 år med virksomhet bak seg. De har ca 13 000 medlemmer i Norge. Blindeforbundet jobber for å fremme de blindes rettigheter og for å integrere de blinde i samfunnet. De driver også bistandsarbeid for sine medlemmer gjennom blant rehabiliteringskurs, opplæring av førerhund, og støtte i dagliglivet. Overordnede mål for Blindeforbundet er samfunnsmessig likestilling for blinde og svaksynte. Dette gjøres gjennom interessepolitisk arbeid. Aktuelle saker er: - Transport - Uteområder - Bygg - Teknologi I dette kapittelet har vi presentert bakgrunnsstoff knyttet til oppgaven. I neste kapittel vil vi gå nærmere inn på universell utforming, digitale skiller, synshemninger, samt presentere interessenter knyttet til prosjektet. 9

10

Kapittel 3 Behovsanalyse 11

12

3.1 Universell utforming Universell utforming er et begrep innen design som brukes over hele verden. Hensikten med universell utforming er å legge til rette for at produkter, kommunikasjon og omgivelser kan brukes av alle mennesker i så stor utstrekning som mulig, uten behov for ytterligere tilpassing. 1. januar 2009 trådde Antidiskrimineringsloven i kraft i Norge. Dette er Norges versjon av en lov som krever universell utforming og likestilling for alle. Formålet med denne loven er å bryte ned hindringer for de med funksjonshemminger og å skape muligheter for et lettere liv. Loven krever at alle nye byggeplaner skal være universelt utformet. I nærområdet rundt Høgskolen i Oslo kan vi se effekten av loven i form av at alle fortauskanter er blitt bygget om for å bli lettere for rullestolbrukere å bruke. Loven omfatter også IKT-verden. Det vil si at alle IKT-løsninger etter 1. januar 2009 skal være universelt utformet. Alle utforminger som ble utviklet før 7. januar 2011 skal være universelt utformet innen 1. januar 2021. Figur 3.1: Universell utforming illustrasjon - Bilder hentet fra Wikimedia Commons - De syv grunnprinsippene for universell utforming(wikipedia, Universell utforming): - Like muligheter for bruk -utformingen skal ikke medføre ulemper eller sette stempel på noen brukergrupper, men være like brukbar og tilgjengelig for alle. Det første punktet forteller at poenget med loven ikke er å sette folk i bås. Alle mennesker skal ha like store muligheter til å gjøre hva de har lyst til med livet sitt og det er derfor viktig å fjerne flest mulig hindringer slikt at alle står likestilt. - Fleksibel bruk -utformingen skal tjene et vidt spekter av individuelle preferanser og evner. Fordi det er mange forskjellige funksjonshemminger er det aldri noen som er helt like. Det er derfor viktig at alle ting blir utformet slik at det er lett å gjøre justeringer i henhold til hvert 13

enkelt individs behov. Hvis ikke kan man ende opp med en løsning som fungerer for noen personer men som er helt ubrukelig for andre. - Enkel og lett forståelig bruk -bruken skal være lett å forstå uansett hvilken erfaring, kunnskap, språkevner eller konsentrasjonsnivå brukeren har. Siden løsninger skal brukes av mange forskjellige grupper og folk med forskjellige forutsetninger, må alle løsninger være såpass lette å oppfatte slik at det ikke tar lang tid å skjønne hvordan man skal bruke løsningen. - Forståelig informasjon -utformingen skal gi brukeren nødvendig informasjon effektivt, uavhengig av forhold knyttet til omgivelsene eller brukerne sine evner til å oppfatte disse. - Toleranse for feil -utformingen skal avgrense farer, skader og uheldige virkninger av utilsikta handlinger. - Minst mulig fysisk strev -effektiv og naturlig bruk, med et minimum av strev. Siden mange av brukerne av universelt utformede løsninger ofte har dårligere fysikk enn andre personer. Det er derfor viktig at løsningene krever minst mulig fysisk og mental kraft slik at brukeren ikke blir unødvendig sliten og utmattet fordi han må bruke løsningen. - Størrelse og plass for tilnærming og bruk -tilstrekkelig plass for tilgang, betjening og bruk, uavhengig av brukeren sin kroppsstørrelse, stilling, rekkevidde og mobilitet. 3.2 Digitale skiller Det digitale skillet er gapet mellom folk med effektiv tilgang til digital- og informasjonsteknologi og de med svært begrenset eller ingen tilgang i det hele tatt Hvorfor må vi minske dette skillet? Når et digitalt skille oppstår medfører dette at en brukergruppe blir ekskludert fra en tjeneste eller et produkt. Nå som mer og mer tid blir brukt på digitale medier, og mange dagligdagse tjenester blir lagt til internett, er det viktig at alle har lik tilgang og mulighet til å bruke disse. Norge har satt seg som et mål at alle IKT-løsninger skal være universelt utformet fra 7. januar 2021 (Stortinget, 2008). Når vi en gang i fremtiden forhåpentligvis får fjernet dette skillet vil både samfunnet og enkeltbrukere tjene på det. Samfunnet vil tjene på det i den forstand at folk som tidligere ikke har kunnet bruke de elektroniske løsningene nå vil kunne bidra med kunnskap og synspunkter, samt at selskaper vil få en bredere brukergruppe. Brukerne vil tjene på det siden flere personer vil få mulighet til å kunne benytte seg av løsninger som før var utilgjengelige for mange. Et eksempel på hvor et slikt skille har oppstått er i forhold til de eldre. Den eldre brukergruppen har ikke hatt sjanse til å kunne henge med i den digitale utviklingen og som en følge av dette kan man si at de på flere måter har falt litt utenfor det moderne samfunnet. Mange hverdagslige tjenester og gjøremål er flyttet over til digitale løsninger, og når man har liten eller ingen kunnskap om hvordan man skal bruke disse blir det vanskelig å henge med. Nettbank er et bra eksempel på dette. Eldre mennesker er vant med å gå i banken for å kunne betale regningene sine, men nå forventes det at man skal bruke nettet til å gjøre dette. Når man har vokst opp uten elektroniske medier lett tilgjengelig er det vanskelig å sette seg inn i alt og lære seg hvordan man skal bruke det. Dette er noe man må arbeide videre med. I 2040 vil 30 % av Norges 14

befolkning regnes som eldre og det er da viktig at alle løsningene er utformet på en slik måte at de er lette å bruke og tilgjenglig for alle. Andre brukergrupper som blir rammet Det er ikke bare de eldre som blir rammet av dette skillet. Personer med forskjellige funksjonshemminger har ofte store problemer med å bevege seg i den digitale verden. Det kan virke som at løsningene nå om dagen rett og slett ikke er utviklet for å kunne ta høyde for slike problemstillinger. De er utviklet for den «normale» brukeren hvor man tar utgangspunkt i at brukeren kan benytte seg av alle tjenester og løsninger. Digitale skillet og utdanning i Norge En måte å kunne forebygge det digitale skillet på er å gå inn i skolevesenet. Ved å introdusere barn til IKT fra en ung alder vil kunne forme de til å senere være lettere mottakelig til ny teknologi. Målet til Utdanningsdirektoratet er å kunne tilby hver skoleelev sin personlige datamaskin som de kan både bruke på skolen og hjemme til lekser. Utdanningsdirektoratet gjennomførte tester i 2003, 2005 og 2007 for å kartlegge hvor mange studenter det var per pc, og for å finne ut i hvilken retning og hastighet utviklingen gikk. Resultatene var som følger (Utdanningsdirektoratet, 2007): - 2003: 7,8 elev per datamaskin - 2005: 6,5 elev per datamaskin - 2007: 4,7 elev per datamaskin Ut i fra disse resultatene kan man se at utviklingen går i riktig retning, men det er langt fra å være perfekt. For å kunne oppnå 100 % dekning må hver kommune utstyres med nok finansielle midler til å kunne kjøpe inn nok utstyr. Det må også komme tilstrekkelige tilbud til lærere om opplæring slik at elevene får ressurssterke personer de kan be om hjelp. Hvis dette gjennomføres og utviklingen fortsetter i samme hastighet vil vi innen få år nå målet om 100 % dekning. En undersøkelse gjort av ITU, Forsknings- og kompetansenettverk for IT i utdanning, som ble utført i 2005 kom det frem at 94 % av husstandene med skolebarn har datamaskiner hjemme, og 84 % har tilgang til internett. Et interessant funn viser derimot at kun 84 % av minoritetshusstander med skolebarn har datamaskin og 69 % har tilgang til Internett. (Ottestad, 2005) Det er derfor ekstra viktig at man legger inn ressurser til å dekke minoritetselever sitt behov for datamaskiner. Dette vil både hjelpe til i forhold til det digitale skillet, men også i forhold til det kulturelle skillet da minoritetsbarn raskere vil kunne lære seg norsk og bli mer inkludert i det norske samfunnet. Det digitale skillet på global basis Det er viktig å huske på at det også er et stort globalt skille mellom lite utviklede nasjoner og utviklede nasjoner. Med et globalt skille menes det at utviklingen har vært ujevn på verdensbasis og mange nasjoner har blitt hengende etter, noe som igjen har skapt problemer innenfor teknologi, utdannelse, arbeid, demokrati og turisme. 15

Det globale digitale skillet har blant annet blitt brukt som et argument for at det har blitt et enda større økonomisk skille mellom de mindre utviklede landene og de landene som har ressurser til å investere og utvikle informasjonsteknologi. Veldig få av de mindre utviklede landene som har god dekning på tilgang til internett. En del av grunnen til dette er blant annet fordi de mindre utviklede landene må betale dyrt for å bli koblet til et utviklet land. Danmark har for eksempel dobbelt så mye båndbredde som Latin Amerika og Karibia har til sammen. Mange faktorer spiller inn på tilgang til internett i forskjellige land, noen av disse er blant annet kostnader, økonomiske prioriteringer, språkproblemer, mangel på relatert innhold og teknologisk bistand. Disse faktorene er bare noen av problemene som de mindre utviklede landene må overkomme for å gjøre internett tilgjenglig. Det er mange hindringer som må tas stilling til for å minske det globale digitale skillet, men flere av landene har andre behov som må dekkes først, slik som forsyninger av mat og helsepleie til alle innbyggerne i landet. Dermed er det viktig at man prioriterer riktig og ser på hvilke hindringer som er realistiske å overkomme for de mindre utviklede landene, slik at man kan minske det digitale skillet. Noen av hindringene er: - Tilgang til elektroniske hjelpemidler - Økonomiske kostnader - Tilgang til riktig informasjon - Tilgang til informasjon på riktig språk - Sensur av internett 16

3.3 Synshemminger 130 000 nordmenn har i dag et såpass svekket syn at de regnes som synshemmede. Av disse regnes ca 1 000 som blinde. De seks mest vanlige øyesykdommene er (Blindeforbundet, Brosjyre for øyesykdommer): AMD Aldersrelatert Macula Degenerasjon (svekket skarpsyn/forkalkninger) Dette er en netthinnesykdom der område for skarpsyn er svekket. Det finnes 2 typer AMD: 1. Tørr variant som gradvis svekker synet. Kjennetegn: Dårligere skarpsyn og fargesyn. 2. Våt variant som på uker eller måneder kan føre til tap av lesesynet. Årsaker: - Høy alder - Røyking - For høyt eller lavt blodtrykk øker risikoen - Redusert transport av næringsstoffer til netthinnen Virkning: - Svekket skarpsyn - Blir nesten helt blind - Ofte kalt for praktisk blindhet Behandling: - For våt AMD brukes laserbehandling - Vitaminer og mineraler reduserer risikoen - Injeksjon med sprøyte i øyet med et stoff som hindrer dannelsen av blodkar og betennelser Figur 3.2: AMD Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund Retinitis pegmentosa (kikkertsyn/tunnelsyn) Dette er en arvelig netthinnesykdom som fører til innsnevret synsfelt og/eller blindhet Årsaker: - Genfeil i netthinnen - Nedbrytning av underliggende pigmentceller og pigmentavleiringer dannes. - Arvelig Virkning: - Mørkesynet blir dårligere (Nattblindhet) - Synsfeltet blir gradvis dårligere - Orienterings- og bevegelsesvansker - Ofte kalt kikkertsyn eller tunnelsyn Behandling: - Det finnes ingen behandlinger per dags dato Figur 3.3: Retinitis pegmentosa Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund 17

Katarakt og Traumatisk katarakt (Grå stær) Denne sykdommen oppstår når øyelinsen blir ugjennomsiktig(grå). Det er normalt å få katarakt gjennom normal aldersforandring, men kan også oppstå av andre sykdommer som diabetes eller bivirkninger av medisiner. Årsaker: - Alder - Diabetes - Bivirkninger av medisiner - Sterkt sollys kan framskynde prosessen - Skade i linsen ved følge av slag/stikk (Traumatisk katarakt) - Arvelige defekter - Røde hunder under svangerskapet Virkning: - Øyelinsen blir ugjennomsiktig(grå) - Ser dårligere ute enn inne - Dobbeltsyn - Nærsynthet - Ofte kalt grå stær Behandling: - Operasjon er eneste mulighet Figur 3.4: Grå stær Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund Glaukom (Grønn stær) Grønn stær oppstår når det er for høyt trykk inne øyet. Det forekommer i alle aldersgrupper, men hyppigere i høy alder. Også etnisk opprinnelse kan være betydelig for utvikling av glaukom. Det finnes 2 typer glaukom: - Kronisk (mest vanlig) som gradvis og smertefritt fører til en vekkelse av synet. - Den andre er en akutt variant. Gir tåkesyn og ubehag i øyet. Store smerter, dårlig syn og rødhet i øyet Årsaker: - Redusert blodsirkulasjon - Høyt blodtrykk - Diabetes - Nærsynhet - Skader - Infeksjoner - Svulster Virkning: - Nærsynhet - Svekket syn - Smerter og hodepine ved fokusering Behandling: - Senke trykket med øyedråper - Laserbehandling - Operasjon Figur 3.5: Grønn stær Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund 18

Diabetes retinopati (diabetes og syn) Dette er en sykdom i øyets netthinne pga diabetes. Årsaker: - Diabetes - Forårsake glaukom og katarakt - Høy blodsukker i lengre tid - Røyking virker negativt inn - Høyt kolesterol- og triglyserid innhold i blodet - Høyt blodtrykk - Protein i urinen Virkning: - Tomme flekker i synsfeltet - Sløret syn - Nedsatt kontrastsyn Behandling: - Laserbehandling - Operasjon - Forebygging av stabilt langtidsblodsukker(hba1c) Figur 3.6: Diabetes retinopati Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund Synsforstyrrelser etter hjerneslag (slag og syn) Bare i Norge rammes ca. 15 000 mennesker av hjerneslag årlig. 60 % av disse får ulike synsforstyrrelser. Årsaker: - Hjerneslag (blodpropp eller hjerneblødning) Virkning: - Synsfeltutfall (Evnen til å se til en av sidene) - Svekket øyemotorikk - Dobbeltsyn - Lysømfintligheter - Tørre/såre øyne - Hallusinasjoner - Svekket visuell hukommelse Behandling: - Medisinsk behandling finnes ikke - Målrettet synstrening kan ha positiv effekt Figur 3.7: Synsforstyrrelser etter hjerneslag Brukt med tillatelse fra Thomas Barstad Eckhoff, Siri Berrefjord og Norges Blindeforbund - - 19

3.4 Kontakt med interessenter og ressurspersoner I denne delen vil vi presentere de ressurspersonene og interessentene vi har hatt kontakt med i løpet av prosjektperioden. 3.4.1 Veileder og oppdragsgiver Vi hadde vårt første møte med vår veileder og oppdragsgiver, Frode Eika Sandnes, i starten av januar. Under dette møtet la vi opp en slagplan for hvordan vi skulle angripe oppgaven. Da oppgaven er veldig åpen ble vi enige om å bruke mye tid på informasjonsinnhenting, idemyldring og prototyping. Dette ble gjort for å kontinuerlig provosere fram nye ideer og tenkemåter. På denne måten ville vi unngå å låse oss fast i et bestemt tankesett. Siden oppstarten i januar har vi hatt ukentlige møter med Frode. Disse møtene har vært til stor hjelp for oss med tanke på fremgangen i prosjektet. Han har hjulpet oss med å tenke i mange ulike retninger som har gjort at prosjektet har fått en større dybde og bredde. Frode har også vært tilgjengelig på e-post de dagene vi ikke har hatt møte. Han har i tillegg hatt tilgang til arbeidsmappen vår som gjorde at han raskt kunne få et overblikk over hva vi holdt på med og prosjektets fremdrift. 3.4.2 Blindeforbundet Vår opprinnelige kontaktperson i Blindeforbundet var Kari-Anne Flaa, men i januar gikk hun ut i permisjon. Grunnet dette ble det begrenset kontakt med Blindeforbundet de første månedene. I mars ble vi satt i kontakt med en ny person, May-Britt Haug. Det første møtet ble avholdt i Blindeforbundets lokaler i midten av mars. På dette møtet deltok May-Britt Haug og Beate Alsos som begge jobber som interessepolitiske konsulenter hos Blindeforbundet. Her presenterte vi våre tanker rundt prosjektet og fikk tilbakemelding på dette. Her fikk vi også vist fram en tidlig prototype. Det ble avtalt at vi i april skulle gjennomføre to tester av større omfang. Den første testen ble gjennomført i starten av april. Seks personer testet prototypen, hvorav alle hadde forskjellige grader av synshemminger. Tilbakemeldingene var positive og de var svært fornøyde med løsningen. De anbefalte oss også å ta kontakt med NSB for å forhøre oss om et mulig samarbeid. Senere samme måned utførte vi en større test med 11 testpersoner. Tilbakemeldingene i dette tilfelle var også positive. Inntrykket vi sitter igjen med etter vår kontakt med Blindeforbundet er at det er behov for en slik løsning. Vi takker for deres samarbeid, som vi har funnet veldig lærerikt. 3.4.3 Irontech Under de første testene benyttet vi en berøringsskjerm tilhørende Høgskolen i Oslo. Den viste seg å ikke møte våre krav til respons og nøyaktighet, som igjen ga unøyaktige resultater. For å få så nøyaktige resultater som mulig fra testene trengte vi en berøringsskjerm med kapasitiv teknologi (se punkt 4.3). Det er denne teknologien som NSB benytter til sine automater. 20

Vi bestemte oss dermed for å undersøke om en ekstern aktør ville være villig til å låne oss en skjerm som vi kunne bruke under prosjektperioden. Etter en kontaktrunde kom vi i kontakt med Irontech AS. Det viste seg at de var villige til å låne ut en slik skjerm til oss. Irontech leverer løsninger for industrielle applikasjoner. De spesialiserer seg på skjerm-, berøringsteknologi- og videoløsninger. Hvis Irontech ikke kan møte kundens behov ved å bruke sine underleverandører, designer og produserer de produktet selv. Vi møtte Jørn Jensen, som er ansvarlig for salg og utvikling, i Irontech sine kontorer i Oslo. Under møtet fikk vi prøve ut en av prototypene våre på skjermen vi skulle få låne. Dette fungerte utmerket. Videre fikk vi fikk mye nyttig informasjon om forskjellige type berøringsskjermer og opplæring i hvordan vi skulle bruke den aktuelle skjermen. Irontech og Jørn Jensen har vært meget behjelpelige, og lånet av denne skjermen har vært essensielt for våre resultater. 3.4.4 Activium En viktig del av prosjektet går ut på å eksperimentere med lyd. Det var derfor viktig at vi hadde tilgang til talesyntese. Det er mange som leverer denne typen programmer, men vi tok kontakt med Activium da vi fra tidligere arbeid hadde erfaring med deres produkt. Activium AS utvikler og leverer digitale hjelpemidler for personer med lese- og skrivevansker. De har siden 1998 levert løsninger til studenter, bedrifter og privatpersoner. Noen av løsningene de tilbyr er: - Talesyntese - Skrivehjelpemidler - Digitale skrivepenner - Håndholdte oversettere - Skannere - Presentasjonsverktøy Activium synes vår prosjektoppgave virket spennende, og sa seg villige til å låne oss lisenser til deres talesyntese, Voxit Budgie Pro (se punkt 6.4). Vår kontaktperson, Ole Petter Braathen, var meget behjelpelig og ga oss tilgang til mange forskjellige stemmer vi kunne velge mellom. 3.4.5 Andre ressurspersoner Etter å ha søkt på nettet etter informasjon rundt universelle løsninger til automater ble vi gjort oppmerksomme på organisasjonen Design for Alle. Vi tok kontakt med den danske lederen i organisasjonen, Karin Bendixen. Hun var veldig interessert i oppgaven vår og ga oss masse nyttig informasjon om hvor utbredt problemet også er i Danmark. 21

Hun satte oss i kontakt med Franscesc Aragall som jobber i den internasjonale Design for All Foundation. Aragall var med på å utvikle billettautomatene i Barcelona som har fått mye skryt for å være brukervennlige for mennesker med synshemninger. Franscesc kunne fortelle oss at de samme automatene var utplassert i Stockholm, men da uten det lydbaserte grensesnittet. Han ga oss også kontaktinformasjonen til firmaet som har laget automatene. Vi tok kontakt via e-post, men fikk dessverre ikke svar. 22

Kapittel 4 Research 23

24

4.1 Kartlegging av ulike billettautomater Som en del av vår research knyttet til prosjektet følte vi det var nødvendig å kartlegge dagens automater. Tanken var å lære av disse automatene. Lærdommen ble brukt til utviklingen av våre egne prototyper. Vi konsentrerte oss hovedsakelig om automater med berøringsskjerm, men også vanlige automater med tastatur og eventuelle lydgrensesnitt. I alt testet vi seks automater. Under følger en kort beskrivelse av automatene vi testet. En grundigere rapport finnes i appendiks (se punkt 15.2) Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: NSB Billettautomat Nei Akseptabelt for seende og delvis enkel å bruke Noe å merke seg er høyden på skjermen. Den er plassert en anelse for høyt, slik at kortvokste, høyvokste og rullestolbrukere kan ha problemer med å bruke den. Stort Figur 4.1: NSB billettautomat Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: Flytoget Billettautomat Nei Ryddig, simpelt og svært enkel å bruke Høyden og fysisk utforming mer tilgjengelig enn NSBs automat Noe Figur 4.2: Flytoget billettautomat 25

Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: Flytoget Billettløst (Kortautomat) Nei Meget enkel og tilbyr bare en tjeneste Høyden og fysisk utforming mer tilgjengelig enn NSBs automat Liten Figur 4.3: Flytoget billettautomat Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: Saga kino Billettautomat Nei Meget enkel og tilbyr bare en tjeneste Høyden varierer Liten Figur 4.4: Saga kino billettavhentingsmautomat Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: Ruter Billettautomat Nei Kjapp og enkel Høyden og fysisk utforming mindre tilgjengelig enn NSBs automat Stort Figur 4.5: Ruter billettautomat 26

Navn: Type: Lydgrensesnitt: Grensesnitt: Fysisk utforming: Forbedringspotensiale: Nordea Nationaltheatret Minibankautomat Ja Enkel Høyden og fysisk utforming mindre tilgjengelig enn NSBs automat Stort Figur 4.6: Nordea minibank 4.1.1 Lærdom fra automatene Etter å ha testet flere ulike automater, har vi fått kunnskap om hvilke minimumskrav vår prototype må tilfredsstille. Automatene vi testet er laget til forskjellige formål med ulike brukergrensesnitt. Den primære lærdommen var at ytterst få automater tilbyr brukeren tilbakemelding i form av lyd. - Absolutt (se punkt 7.5.1) Alle automatene er absolutte. Det vil si at grensesnittets elementer er posisjonert på et fast område. Absolutt grensesnitt begrenser enkelte brukergrupper fra å bruke automaten. - Plassering av skjerm Ingen av automatene hadde lik plassering av skjermen. Den fysiske utformingen av skjermen var ulik. Ingen av automatene hadde en skjerm som kunne tilfredsstille alle brukergrupper. - Plassering av betalingsmuligheter Den fysiske utformingen av kortterminalen var alle forskjellige. Det som er merkbart er at høyden til betalingsterminalene begrenset bruken for noen brukegrupper. - Plassering av billettskrivere Billettskrivere er som oftest under skjermen, men kan også befinne seg på venstre side. Høyden på billettskriverne er noe mer vennlig mot enkelte brukergrupper. - Type betalingsmuligheter Automatene tilbyr varierte betalingsmuligheter. Noen tar kun kort, andre kun kontanter. - Lydgrensesnitt Den eneste automaten med lydgrensesnitt var Nordea sin minibank. Lydgrensesnittet er bra, men er avhengig av hodetelefoner. Lokaliseringen for uttaket til hodetelefoner kan være vanskelig å finne. - Bildegrensesnitt Skjermbildet er meget variert. Noen automater er bedre enn andre. Men ingen av dem har optimale grensesnitt. De fleste er absolutte. 27

4.2 Lydmuligheter i forbindelse med automater Ved implementering av lydgrensesnitt finnes det flere varianter for lydavspilling. - Øretelefoner Forutsetter at brukeren har med sine egne øretelefoner. Denne metoden vil begrense lyden kun til brukeren, og unødvendig støy fra omgivelsene blir blokkert. - Høytalere Kan føre til at lyden drunker i støy fra omgivelsene rundt, samt eliminerer enkeltindividets krav til diskresjon - Lyddusj Plasseres over automatene. Dusjene begrenser lyden til kun de som står under dusjen, samt unødvendig støy blir blokkert. Dette virker som den mest brukervennlige metoden da den ikke setter noen krav til brukeren. 4.3 Berøringsskjermteknologier Her vil vi liste opp og forklare de mest brukte teknologiene som er på markedet i dag. Grunnen til at vi har satt oss inn i dette er for å hjelpe oss selv med å forstå hvordan teknologien fungerer. Vi har tatt for oss fire forskjellige typer berøringsskjermteknologier: - Resitiv - Kapasitiv - Surface Acoustic Wave - Infrarød Kapasitiv Kapasitive berøringsskjermer har elektroder rundt hele skjermen og et tynt elektrisk ledende lag på utsiden. Når man trykker på skjermen oppstår det en spenning som blir registrert av elektrodene og definert som trykkpunktet. Fordeler: - God driftsikkerhet - Lang varighet/levetid - Kan brukes i et røft miljø Ulemper: - Lav oppløsning - Kan bare brukes med tilpasset stylus - Ikke beregnet for bruk med hansker - Krever vedlikehold - Kan påvirkes av elektromagnetiske ladninger Resitiv Resitive berøringsskjermer er den mest brukte teknologien i dag grunnet den lave produksjonskostnaden. Skjermen fungerer ved at to metalliske lag som leder elektrisitet er montert med et lite mellomrom. Trykkpunktet blir registrert ut ifra hvor lagene trykkes sammen. 28

Fordeler: - Høy oppløsning - Kan brukes med alle typer stylus (så lenge riper unngås) - Kan brukes med hansker - Rask responstid - Billig Ulemper: - Begrensede bruksområder - Lav levetid - Dårlig driftsikkerhet Surface acoustic wave (SAW) Surface acoustic wave er en relativt ny teknologi på markedet. Den baserer seg på bølger som brer seg på et materiale av spesielle krystaller som genererer spenning ved belastning og motsatt. Rundt hele skjermen er det montert sensorer som oppfatter lydbølger. Ved hjelp av disse beregnes trykkpunktet. Fordeler: - Høy oppløsning - Kan brukes med hansker - Lang levetid - Driftsikker Ulemper: - Krever myk signalgiver - Ikke egnet for bruk hvor det er store sjanser for at den blir våt - Ujevnheter kan skape feil input - Dyrere enn resistiv og kapasitiv Infrarød (IR) IR består av to eller flere bildesensorer som er plassert rundt kantene av skjermen med lysdioder i synsfeltet på motsatt side. For å beregne trykkpunktet blir det kalkulert hvor lysstrålen blir brutt. Fordeler: - Høy oppløsning - Kan brukes med alle typer stylus - Lang levetid - Rask responstid 29

Ulemper: - Ujevnheter kan skape feil input - Dyreste løsningen på markedet - Kan gi feilindikasjoner i sterkt sollys 4.3.1 Våre erfaringer med forskjellige berøringsskjermer I løpet av vårt prosjekt har vi benyttet oss av to typer skjermer. Den første skjermen var en eldre resitiv modell som vi fikk låne av skolen. Denne skjermen fungerte greit til de første prototypene vi utviklet, men etter en stund oppdaget vi at denne skjermen ikke ville klare å dekke behovene som oppstod i forbindelse med utviklingen og tilhørende testing. Noen av problemene som oppsto var mangel av følsomhet og treg respons på den eldre skjermen. Dette påvirket testresultatene. Etter hvert som vi satt oss inn i berøringsskjermteknologier ble det klart at vi måtte gå til anskaffelse av en nyere modell som liknet den NSB benytter seg av i dagens automater. Dette var nødvendig for at vi skulle kunne utvikle en prototype som vi var sikre på ville fungere med de nåværende skjermene. Da vi endelig hadde den nye skjermen på plass kunne vi kjøre tester av prototypene med stor nøyaktighet, og allerede etter de første testene ble resultatene forbedret. Den nye skjermen hadde høyere nøyaktighet, forbedret følsomhet og flere funksjoner i programvaren. Hadde det ikke vært for den nye skjermen kunne vi ikke ha utviklet visse prototyper og testet de slik vi ville. Denne prototypen krevde nettopp en slik skjerm av nyere standard for å fungere. 4.4 Relevant teknologi Foruten automater er det mange enheter som bruker berøringsteknologi. For eksempel PCer, tablets og mobiltelefoner. Spesielt mobiltelefoner er interessant for oss. Apple med sin iphone og Google med Android har funksjoner som tilrettelegger for synshemmede. Her vil vi presentere enhetene og tilhørende funksjoner. 4.4.1 Android Android er et operativsystem for mobiltelefoner. Operativsystemet er basert på åpen kildekode. Eyes Free Android Eyes Free er et prosjekt med mål å gjøre Android telefoner universelt utformet. Utfordringen er å la brukeren håndtere telefonen uten å se skjermen. Eyes Free består av følgende teknologier: - Text-to-speech Talesyntese som leser opp informasjonen fra skjermen - One stroke Baserer seg på snarvei ved bruk av tastetrykk eller dragning av fingeren - Talkback Applikasjon som gjenkjenner lyd og vil utføre forskjellige oppgaver ut i fra gitt lyd - StrokeDialer Løsning for nummertastatur 30

Figur 4.7: Strokedialer for Android Alle disse funksjonene hjelper synshemmede å bruke telefonen, men det er spesielt en funksjon som er interessant for oss. StrokeDialer fungerer ved at uansett hvor brukeren plasserer fingeren på talltastaturet, vil man alltid havne på 5. Slik vet man hvor de andre tallene befinner seg. Dette er en relativ løsning som gjør at man ikke må se skjermen. 4.4.2 iphone Figur 4.8: iphone I likhet med Android har også iphone funksjoner som hjelper synshemmede brukere. De viktigste funksjonene er: - Voiceover Program som leser opp teksten på skjermen - Stemmestyring Bruke tale for å utføre kommandoer - Zoom Mulighet for å forstørre skjermbildet - Hvitt på sort For bedre kontrast kan man velge hvit skrift på sort bakgrunn - Taktile knapper Knapper rundt telefonen i ulike utforming som utfører funksjoner 31

32

Kapittel 5 Prosjektutviklingsfase 33

34

5.1 Arbeidsmiljø Før prosjektets start ble vi enige om å opprette et sett faste arbeidsrutiner. Det ble avtalt at vi skulle møtes hver dag 08.00 og jobbe til 14.00, eventuelt lengre hvis nødvendig. Dette tilsvarte seks timers effektivt arbeid, inkludert 30 minutter lunsj. Årsaken var at prosjekt skulle gjenspeile en autentisk arbeidssituasjon. Dette gjorde vi for å unngå tidspress og unødvendig mye arbeid mot slutten av prosjektet. Tidlig oppmøte gjorde at vi fikk samme grupperom hver dag. Dette gjorde at dagene fikk et mønster. Vi har sett på det å ha et eget grupperom som veldig positivt for prosjektets fremdrift da vi kunne arbeide konsentrert uten støy fra åpent landskap. En slik intim arbeidsatmosfære gjorde at kommunikasjonen gikk glatt innad i gruppen. Grupperommet har også fungert ypperlig som lokale for testing. Det har blitt avholdt ukentlige møter med vår veileder gjennom hele perioden. Under disse møtene ble ukens arbeid lagt fram og diskutert. Dette tvang fram resultater. Tilbakemeldingen vi fikk bidro til prosjektets kvalitet. Ukeplan: Mandag 08:00 14:00 Arbeid med prosjekt Tirsdag 08:00 14:00 Arbeid med prosjekt Onsdag 08:00 12:00 12:00 12:45 Arbeid med prosjekt Møte med veileder Torsdag 08:00 14:00 Arbeid med prosjekt Fredag 08:00 14:00 Arbeid med prosjekt 5.2 Tidsplan Figur 5.1: Tidsplan 35

5.3 Dokumentasjon av arbeid For å holde orden på alt vi gjorde ble det innført strenge rutiner på dokumentasjon. Det ble opprettet en felles logg der alt som ble gjort i løpet av en dag ble notert. Dette ble også skrevet ned i en webbasert blogg. Dette gjorde det enkelt å holde seg oppdatert rundt progresjonen til prosjektet og hjalp oss under rapportskrivingen. Hvis man ved fravær ikke hadde mulighet til å være tilstede, kunne man ved hjelp av bloggen holde seg oppdatert. 5.4 Smidige metoder I forkant og underveis i prosjektet hentet vi inspirasjon fra Scrum og extreme Programming, som begge er smidige metoder. Vi har ikke fulgt de til punkt og prikke, men de har fungert som inspirasjon og veiledning. Vi vil nå forklare hva smidige metoder er, samt presentere vår arbeidsmetode. Smidige metoder er en ny og moderne metode å jobbe på. Kort oppsummert baserer de seg på effektivt arbeid ved hjelp av tett samarbeid mellom de involverte og høy fleksibilitet i arbeidet for en optimal måloppnåelse. (Schuh, 2004) definerer de agile retningslinjene som: Tett samarbeid og kommunikasjon Fleksibilitet i forhold til tidsrammer og budsjett Kontinuerlig samarbeid med kunden Maks 50 personer involvert i prosjektet Konstant re-evaluering og testing Scrum Scrum er en metode hvor man jobber sammen i grupper uten spesifikasjoner eller nøye planlegging. Ved bruk av Scrum jobber man i iterasjoner som kan vare fra en uke til en måned. Dette kalles en Sprint. Før man starter en Sprint har man en gitt liste over spesifikke funksjoner som skal implementeres. Funksjonene blir lagt i en kravliste kjent som Product Backlog. Listen med kravene som skal implementeres i en Sprint heter Sprint Backlog. Hver uke skal det være korte daglige møter hvor man diskuterer målsetninger, arbeidsprosessen og problemer. Et Scrum team er sammensatt av opptil 10 personer med ulik bakgrunn og kompetanse. Rollene som må være definert er: - Produkteier - Scrum-master - Scrum-team extreme Programming(XP) extreme Programming er en fleksibel utviklingsmetode i motsetning til tradisjonelle metoder. Metoden kan virke ustrukturert da man starter med utviklingen allerede første dag. Andre metoder følger som regel en nøye planlagt arbeidsprosess. Utviklerne skal alltid være åpne for endringer 36

underveis i arbeidet, noe som gjør at man står friere i forhold til kravspesifikasjonen. Utviklerne er i konstant dialog med kunden, som til en hver tid skal kunne komme med endringer som skal etterfølges. extreme Programming har fem kjerneverdier: - Kommunikasjon - Enkelhet - Tilbakemelding - Mot - Respekt Hovedverdiene er kommunikasjon og tilbakemelding, og man kan si det er disse to ordene som beskriver metoden best. Metoden baserer seg på hyppige tester og tilbakemeldingene fra disse er en viktig brikke i arbeidet til programmererne. I metoden er det fokus på å utvikle mange enkle prototyper over kort tid, hvor man deretter kjører testing og gjennomgang med oppdragsgiver. Dette er ulikt mange andre metoder der man gjerne bruker lang tid på å utvikle en ferdig prototype som man kjører testing på. Tekniske problemer blir løst ved at man lager flere «spikes». En «spike» kan være et alternativ til en måte å løse problemet som har oppstått. Når den beste løsningen er funnet blir de andre forkastet. Mange av alternativene er som regel for dårlige til å brukes i den endelige løsningen. Tanken bak er at risikoen for feil blir lavere når man jobber med et problem av gangen. Et av hovedelementene ved extreme Programming er at metoden legger til rette for parprogrammering. Det vil si at to utviklere arbeider sammen på en maskin. De to utviklerne har hver sin rolle, gjerne kalt sjåfør og navigatør. Dette betyr at den som har minst kunnskap fungerer som navigatør imens den erfarne sitter som sjåfør. På denne måten lærer den minst erfarne av den erfarne. Etter hvert byttes rollene. Vår arbeidsmetode Vår arbeidsmetodikk har basert seg på Scrum kombinert med extreme Programming. Vi har ikke fulgt metodene slavisk, men tilpasset de til vårt behov. Utviklingen har foregått i korte iterasjoner. Viktige verdier i vår arbeidsprosess har vært: - Samarbeid - Kommunikasjon - Inkludering - Tilbakemelding - Hurtighet Disse verdiene er beskrivende for vårt prosjekt. Da vi ønsket å starte på utviklingen av prototyper tidlig, valgte vi å jobbe etter extreme programming metoden. Dette gjorde at vi kunne utvikle mange raske prototyper slik at vi fikk 37

realisert de fleste ideene. Tilbakemeldinger gjennom hyppig testing av prototypene har vært grunnlaget for nye prototyper og videreutvikling av eksisterende. Stegene i vår utviklingsfase: Figur 5.2: Stegene i utviklingsfase Modellen over illustrerer stadiene i vår arbeidsprosess. Pilen viser at hver gang det har blitt produsert en ferdig prototype går man tilbake til idestadiet. Dette viser en kontinuerlig iterasjonsprosess. Ved å arbeide på denne måten slutter man aldri å skape ideer, man produserer hele tiden noe nytt. Tiden på våre iterasjoner varierte ut i fra omfanget til prototypen, og kunne derfor vare fra mellom noen få dager til flere uker. På grunn av gruppens størrelse har vi kjørt parallelle iterasjoner for og utforske flest mulig løsninger. 5.5 Idéskapende arbeid Universell utforming er et aktuelt tema for tiden, men det betyr ikke at informasjon rundt det er lett tilgjengelig. Vi måtte proaktivt søke etter informasjon som var relevant for prosjektet. Den første måneden av prosjektet ble satt av til dette. For å sikre at dataene vi fant var relevant og ville være til nytte for prosjektet følte vi at det var nødvendig å sette fokus på å kvalitetssikre denne informasjonen. Dette gjorde vi for å bekrefte at alle kilder var troverdige, da noen informasjonskilder ikke alltid er like pålitelige. Måten vi gjorde dette på var å finne en tilsvarende kilde til den vi allerede hadde oppdaget. Ved å se at innholdet blir beskrevet på flere steder kunne vi føle oss trygge på at det var troverdighet i informasjonen. Da vi ikke hadde bred kunnskap på dette området før prosjektet har denne delen vært essensiell i forhold til å øke kunnskapsnivået til gruppemedlemmene. Metodene vi brukte for innsamling av data: - Internett - Ressurspersoner - Artikler - Tidsskrifter 38

- Eksisterende teknologi - Feltarbeid Etter å ha fått impulser fra forskjellige kilder ble vi inspirert til å dykke inn i så mange forskjellige løsningsmetoder som mulig. Vi følte at dette var nødvendig for at prosjektet skulle få den dybden og bredden som var nødvendig. I arbeidet med å skape nye forslag jobbet vi både kollektivt og individuelt. Kollektive gruppemøter der alle måtte bidra med sine synspunkter ble utført på ukentlig basis. Disse møtene tvang oss til å tenke kreativt og nyskapende. Tvungen idémyldring hjalp også hver enkel person i sitt individuelle arbeid med å skape nye ideer, og hver uke måtte hvert gruppemedlem presentere en ny idé for diskusjon. Figur 5.3: Idemyldring Hentet fra Wikimedia Commons 5.6 Utviklingsarbeid Da vi var ferdige med å samle informasjon og skissere forslag til løsninger, gikk vi over til å realisere disse. Dette kalte vi for utviklingsfasen. Det var den mest tidkrevende perioden under prosjektet og varte fra februar til mai. Vi valgte å fokusere på kjappe prototyper for å få realisert flest mulig ideer. Dette gjorde at vi kunne kjøre mange brukertester og få raske tilbakemeldinger. Tilbakemeldingene har bidratt til videreutvikling og nye hybrider fra de opprinnelige prototypene. I arbeidet med prototypene som krevde programmering tok vi i bruk parprogrammering. Dette ga de gruppemedlemmene som ikke hadde mye erfaring med programmering muligheten til å forbedre seg. Ved å programmere sammen med en erfaren programmerer blir det enklere å tilegne seg nye kunnskaper. På denne måten ble den erfarne programmerer avlastet og arbeidet kunne fordeles på flere personer Figur 5.4: Parprogramming Hentet fra Wikimedia Commons 39

40

Kapittel 6 Verktøy 41

42

Verktøyene vi har brukt har vært en essensiell del av vårt prosjekt og de har bidratt til prosjektets resultat. Det har blitt brukt alt fra penn og papir og PowerPoint, til mer avanserte verktøy som Adobe Flash CS4. I dette kapittelet vil vi presentere verktøyene. 6.1 Dropbox Figur 6.1: Dropbox logo Hentet fra http://www.dropbox.com Dropbox er en tjeneste som ved hjelp av cloud computing muliggjør lagring og deling av filer på nett. Tjenesten er gratis og fungerer på de fleste operativsystemer. En klient installeres lokalt på datamaskinen og muliggjør denne fildelingen. Det finnes også en webbasert klient. Funksjonalitet Dropbox gir brukerne muligheten til å legge filer i mapper som blir synkronisert til en server. Alle filene vil da dukke opp på alle PCene som er synkronisert mot den Dropbox-kontoen. Dette kan være flere PCer brukeren har, eller andre personer som også har fått tilgang til den delte mappen. Man kan også koble opp flere datamaskiner mot en og samme Dropbox konto, mappene blir oppdatert når synkroniseringen er fullført. Du får også muligheten til å laste opp filer via den webbaserte klienten. Dropbox har i dag mer enn 4 millioner brukere og er i stadig utvikling. Hvorfor valgte vi Dropbox Dropbox ble valgt fordi flere av gruppmedlemmene hadde positive erfaringer med tjenesten. Vi testet programmet ut før prosjektet startet, og vi fikk et svært godt inntrykk. Hvordan brukte vi Dropbox Vi lagde en egen mappe på Dropbox, denne var da synkronisert med kontoene til alle medlemmene av prosjektet, inkludert vår veileder og oppdragsgiver Frode Eika Sandnes. Dette var med på å øke og gjøre kommunikasjonen bedre og lettere innad i gruppen og med vår veileder. 43

6.2 Penn og papir Figur 6.2: Blyant Hentet fra Wikimedia Commons Hvorfor valgte vi å bruke penn og papir For å raskt kunne skissere ideer på lavnivå. Enkle tegninger er meget godt egnet da det øker effektiviteten og viser seg tidsbesparende i motsetning til å programmere direkte fra ideer. Ved å bruke penn og papir kunne vi også tenke i nye retninger uten at vi ble låst til funksjonaliteten til elektroniske verktøy. Hvordan brukte vi penn og papir Når vi kom opp med en idé ble den først skissert på papir for så eventuelt å bli omskapt til en digital løsning. 6.3 Microsoft PowerPoint Figur 6.3: Microsoft PowerPoint logo Hentet fra http://www.tushar-mehta.com Dette verktøyet er et presentasjonsprogram som er utviklet av Microsoft. PowerPoint er en del av Office pakken. Hvorfor vi valgte verktøyet Verktøyet ble valgt på grunn av dets funksjonalitet. Primært laget for presentasjoner, egner det seg også meget godt som prototypingsverktøy. Tidligere bruk har gjort at vi har opparbeidet oss ferdigheter som har kommet til nytte under prosjektperioden. Det er enkelt å gjøre endringer underveis, noe som passet godt til vår smidige arbeidsmetodikk. 44

Hvordan vi brukte verktøyet Mange av våre prototyper benyttet PowerPoint som grunnlag for utvikling. Når vi trengte mer avanserte former for funksjonalitet, ble det enten simulert i PowerPoint, eller utviklet i Flash. 6.4 Voxit Budgie Pro Figur 6.4: Voxit Budgie Pro logo Hentet fra http://www.activium.no/voxit/ Dette verktøyet er et program for talesyntese som er utviklet av Activium AS. Verktøyet er primært laget for personer som har problemer med å lese, men brukes av alle slags mennesker. Hvorfor vi valgte verktøyet Vi valgte dette verktøyet fordi det var på norsk, men også fordi det er et stort utvalg av både stemmer og språk som vi kunne bruke, samt at stemmene holder høy kvalitet. Activium var meget samarbeidsvillige og de ga oss lisenser som vi fritt kunne bruke til vårt prosjekt. Hvordan vi brukte verktøyet Vi brukte verktøyet for å lage lyder til våre prototyper. Verktøyet ligner på et tekstredigeringsprogram. Her skriver man inn tekst som skal bli opplest. Du velger stemme, språk, hastighet på stemmen og eventuelle pauser stemmen skal utføre. Når man er fornøyd med resultatet får man muligheten til å lagre filen i enten wav eller mp3. På grunn av mp3-formatets solide kompresjonsratio, ble mp3 brukt i alle våre prototyper. 6.5 Adobe Flash CS4 Figur 6.5: Adobe Flash CS4 logo Hentet fra http://www.adobe.com/products/flash/ Adobe Flash CS4 er en del av Adobe Creative Suite, og programmets primære bruk er til utvikling av flashapplikasjoner. Det kan være webapplikasjoner, spill, programmer, filmer osv. I vårt tilfelle ble 45

programmet brukt til å lage prototypene som tilhørte Swipe-familien, CakeEight og VoiceBob (se kap 10, punkt 8.5, og punkt 11.2). Flash har fått en del kritikk grunnet formatets (.swf) proprietære natur. Nylig eksemplifisert av Apple og deres nekt av å støtte teknologien på iphone. Vi så tidlig begrensingene ved PowerPoint. Da det er et fantastisk verktøy til og kjapt realisere en ide, er det vanskelig å få til avansert animasjon og logikk. Det var på dette punktet flash hjalp oss mye. Det tilhørende scriptspråket actionscript 3.0 tillot oss å implementere ting som ikke var mulig med PowerPoint. Teknologien som ligger til grunn for Swipefamilien av prototyper, nyttegjør seg kraftig av actionscript. Hvorfor valgte vi verktøyet For å implementere funksjonalitet som ikke var mulig med andre verktøy. Dette er avansert animasjon og muligheten til å legge til logikk med actionscript. Hvordan vi brukte verktøyet Verktøyet ble brukt til å lage teknologien som ligger til grunn for Swipe. 6.6 E-Speaking E-speaking er et program til Windows Vista og Windows 7 som benytter den allerede tilstedeværende tekst-til-tale teknologien som ligger i operativsystemet. Det tillater brukeren å få opplest tekst, samt styre PCen ved å lese inn kommandoer. Hvorfor vi valgte verktøyet For å muliggjøre enkelte prototyper som baserte seg på stemmestyring. Hvordan vi brukte verktøyet Verktøyet ble brukt i sammenheng med Adobe Flash CS4 for å lage prototyper med stemmestyring. Vi koblet enkelte kommandoer slik som «Enkelbillett», eller «Voksen» til taster på tastaturet. Disse tastene ble igjen brukt som identifikatorer i flash applikasjonen. På denne måten simulerte vi talestyring. 46

6.7 Audacity Figur 6.6: Audacity logo Hentet fra http://www.uweb.edu/learntech/podcast/audacity/logo.jpg Audacity er et gratis lydredigeringsprogram som fungerer på de fleste operativsystemer. Funksjonalitet Audacity har en rekke funksjonalitet: - Konvertering av lydformater - Spille inn og spille av lyder - Editere og forandre lyder - Støyrensing Hvorfor valgte vi Audacity Vi valgte Audacity fordi vi hadde et behov for å redigere lydfiler. Hvordan brukte vi Audacity Når vi skulle utvikle prototypene våre brukte vi Audacity til å redigere lydfilene. Audacity ga oss muligheten til å slå sammen flere lydfiler til en lydfil. Vi brukte også programmet til et eksperiment vi hadde med lyder som overlappet hverandre. 47

48

Kapittel 7 Prototyping og testing 49

50

7.1 Prototyping Prototype er en generell betegnelse som omfatter en rekke ulike modeller som lages i løpet av en utviklingsprosess fram til et ferdig produkt. Det finnes flere typer prototyper: - Skissemodeller Viser designideer - Funksjonsmodeller Demonstrerer funksjonen - Utseende-modeller Viser design - Førserie Siste steg i prosessen. Prototypen er klar for produksjon Vi var gjennom tre av disse: skisse, funksjon, utseende. Vår løsning skal ende på funksjon eller utseendestadiet. Den skal demonstrere funksjonen til en billettautomat med lydgrensesnitt. Det vil si at den kan om så kan være realisert på papir, så lenge den viser funksjonen. Vi har allikevel hele tiden vært bestemt på å komme så nær en førserieprototype som mulig. Figur 7.1: Prototypestadier 7.2 Prosedyre for utvikling av prototyper Fordi vi skulle utforske mange ulike områder ble vi tidlig enige om å lage en mal for utvikling av prototyper. Dette gjorde at hver prototype ble lagt frem på lik måte for gruppen og selv om prototypene var svært ulike kunne de evalueres likt. Prosessen så slik ut: 1. Hver idé til en prototype ble skissert på ark. Her blir alle krav, forutsetninger og avgrensninger kartlagt 2. Ideen og skissene ble lagt frem for gruppen for diskusjon. Alle gruppemedlemmene fikk vite all nødvendig informasjon rundt ideen, og fikk komme med innspill på eventuelle forbedringer 3. Gruppen stemte over hvorvidt prototypen skulle utvikles videre 51

4. Ble prototypen godkjent gikk den til utviklingsstadiet. Her ble ideen, så langt det gikk, realisert til en fullverdig prototype klar for testing Rapport for prototype Etter at den enkelte prototype var ferdig utviklet ble det skrevet en rapport. Denne rapporten dokumenterte arbeidsprosessen fra start til slutt. Konseptet og funksjonaliteten ble også dokumentert. For at alle rapportene skulle være oversiktelige og lette å finne frem i ble det laget en mal for dette. Det gjorde arbeidet enklere og man kunne konsentrere seg om spesifikke ting som skulle dokumenteres. Rapporten skulle alltid inneholde: 1. Versjon for prototype - Fordi prototypen ofte måtte endres eller oppdateres var det viktig å skille disse så vi alltid kunne se tilbake på tidligere versjoner og dokumentere utviklingen 2. Testing - Om testing var blitt utført og eventuelle resultater av denne 3. Verktøy - Hvilket verktøy som ble brukt i utviklingen 4. Bilde - Diverse skjermbilder som forklarte ideen 5. Konsept - Hva utvikleren hadde tenkt med prototypen og hvordan den ville fungere 6. Fremgangsmetode - Kort bruksanvisning for prototypen som forklarte hvordan den skulle brukes 7. Avgrensninger - Eventuelle ting eller valg som ikke fungerte i den daværende versjonen av prototypen 7.3 Hvorfor teste? Testing er prosessen med å prøve ut et program med den hensikt å finne feil eller bevise en hypotese. I motsetning til teknikker for verifisering, gjør testing ikke sikte på å bevise riktigheten av et program. Testing er en aktivitet som vurderer egenskapen eller evnen til et program eller system og om de oppfyller de nødvendige krav. Det viktigste for oss ved å teste var å få tilbakemelding fra brukere. Den kontinuerlige tilbakemeldingen fra både formelle og uformelle tester var særdeles viktig for prosessen vår. Før en test ble det definert hva vi var ute etter å finne ut. Dette kunne være: - Fungerer prototypen tilfredsstillende teknologisk? - Skjønner brukeren konseptet? - Hvilke problemer opplever brukeren? - Tidsbruk 52

- Feilratio - Antall trykk/sveip Figur 7.2: Testperson og kontrollør 7.4 Testmiljø For å få realistiske resultater fra testene våre var det viktig å gi alle testpersoner det samme utgangspunktet og forutsetninger. Vi la derfor stor vekt på at alle testpersoner skulle ha likt utgangspunkt og like materialistiske forutsetninger mens de utførte testen. Dette vil si at: - Fast rom for testing - Antall testkontrollører holdt til et minimum - Testpersonene ble presentert for samme instruksjoner og oppgaver Testene ble utført på to lokasjoner: - Høgskolen i Oslo - Blindeforbundet 7.4.1 Uformelle tester Uformelle tester ble først og fremst brukt til å teste deler av funksjonaliteten til en prototype. Ved å utføre disse testene fikk vi raske tilbakemeldinger på arbeid vi hadde gjort. Tilbakemeldingene ble så analysert og brukt i videre utvikling. Testpersonene var hovedsakelig studenter ved Høgskolen i Oslo. Helst skulle vi testet på personer med synshemninger, men for å opprettholde den kontinuerlige testingen var det lettvint å bruke studenter. Noen av disse hadde synshemninger, men ingen i den grad at de kunne kategoriseres som ekstremt svaksynt eller blind. Tester som ble utført med det formål å teste bruk uten syn ble simulert ved at seende fikk bind for øynene. De to kontrollørene har forskjellige oppgaver under testingen. Den ene gir instruksjoner og fungerer som observatør, den andre fungerer som datamåler. Det vil si å ta tiden, registrere feil og andre relevante mål avhengig av prototype og funksjonalitet. 53

Eksempel på testscenario: - Bruker mottar instruksjoner fra testkontrollør - Bruker utfører test uten å se skjerm - Bruker utfører test med å se skjerm - Bruker gir tilbakemelding Figur 7.3: Testperson Brukt med tillatelse fra testperson Da denne aktiviteten var nyttig for oss, må vi også være kritiske til resultatene. Det er flere faktorer som spiller inn: - Skjerm Den første skjermen vi utførte tester med var av gammel teknologi - Teknologi Visse prototyper ble testet for tidlig med det resultat at testen ble ufullstendig - Miljø Distraksjoner under testingen - Tankesett Blinde og svaksynte benytter hørselen i større grad enn seende. Selv om en seende person har bind for øynene og blir tvunget til å bruke denne sansen, vil det ikke bli realistisk 7.4.2 Formelle tester Formelle tester ble utført på fullstendige prototyper. Det vil si at det ikke bare ble testet enkeltfunksjoner, slik som på de uformelle, men fullt fungerende løsninger. Det var bare en prototype som kom til dette stadiet. Dette grunnet prosjektets tidsbegrensninger. Formell testing ble utført i samarbeid med Blindeforbundet. De stilte lokaler og testpersoner til disposisjon. Totalt ble det utført to tester. Det som skilte disse testene fra uformelle tester, var at testpanelet hadde reelle synshemninger, samt at personene ikke hadde brukt berøringsskjermer før. 54

7.5 Absolutt og relativ I de neste punktene vil vi presentere og forklare forskjellene mellom absolutte og relative prototyper 7.5.1 Absolutt De eksisterende billettautomatene til NSB bruker eksakt posisjonering på alle funksjoner. Dette er eksemplifisert på bildet under. Figur 7.4: Grensesnitt billettautomat NSB Skjermbildet er hentet fra NSBs billettautomat. Som man ser er alle funksjoner knyttet til en knapp. Problemet er at man ikke kan føle disse knappene. Dette kombinert med mangel på lydgrensesnitt resulterer i at mange ikke kan bruke den. En forutsetning er altså at brukeren kan se. Alle automatene vi testet var av denne typen. Vi kjenner heller ikke til noen andre som ikke er absolutte. De første prototypene vi utviklet var av absolutt natur. Årsaken til dette var innflytelsen de utprøvde automatene hadde på oss. Vi var under inntrykk av at dette var den eneste måten å gjøre det på. Vår veileder, Frode Eika Sandnes, gjorde oss oppmerksom på at det var andre måter å gjøre det på. 7.5.2 Relativ En forklaring på ordet relativ kan være følgende: «Noe som er relativt, har ingen absolutt verdi eller absolutte egenskaper i seg selv, men skifter egenskaper og verdi avhengig av hvem som ser» For oss betyr relativ å lage en løsning som ikke er avhengig av absolutte punkter på skjermen. Med dette menes at alle funksjoner skal kunne utføres hvor som helst på skjermen. Et godt eksempel på dette er StrokeDialer for Android. 55

De har tatt for seg problemet med inntasting av nummer på berøringsskjerm. Løsningen er at uansett hvor på skjermen brukeren plasserer fingeren, vil man alltid starte på tallet fem. Med det som utgangspunkt er det lett å finne de andre tastene ved å dra fingeren i riktig retning. Bildet under viser dette i praksis: Figur 7.5: Android Strokedialer Å tenke på denne måten var uvant for oss, men vi utviklet to prototyper som følger dette konseptet. Vi har erfart at disse ikke bare har forenklet bruken for synshemmede, men også for funksjonsfriske. 7.6 Kravspesifikasjon Våre løsninger er basert på de eksisterende billettautomatene til NSB. Disse automatene har en viss funksjonalitet. Målet er at løsningene skal bevare disse på en best mulig måte. Videre i denne delen blir funksjonaliteten presentert. Overordnede funksjoner Språk Kunden skal kunne velge mellom følgende språk: - Norsk - Engelsk - Tysk - Fransk Billetter Kunde skal kunne kjøpe fire typer billetter: - Enkel 56

- Tur/Retur - Periode - Referanse Type reisende Kunden skal kunne velge mellom fire typer reisende: - Voksen - Student - Barn - Honnør - Militær/SL - Hund Antall Kunden skal kunne velge antall billetter på en enkel måte. Destinasjon Kunden skal kunne velge mellom alle NSBs destinasjoner i Norge. 57

58

Kapittel 8 Knappebasert 59

60

De aller fleste av dagens automater med berøringsskjermer har et grensesnitt som er basert på knapper. Det vil si at for å utføre en funksjon må man trykke et bestemt sted på skjermen. Konseptet er en metafor på fysiske knapper. Dette er et konsept de fleste brukere er kjent med. De eksisterende billettautomatene til NSB følger dette prinsippet. Ved å benytte knapper som funksjonsutløser kan man også få plass til flere funksjoner på samme skjermbilde. Dermed kan man spare plass og samtidig benytte seg av fordelene ved å kunne ha et fullverdig tastatur på skjermen. Vanligste form for tekstinput er ved et onscreen-tastatur. For å gjøre våre knappebaserte løsninger brukervennlige for synshemmede, er det implementert lydgrensesnitt. Det fungerer slik at brukeren får tilbakemelding når en knapp er trykket på eller blitt berørt. Ved å bruke lyd åpner man for en større brukergruppe samtidig som kan forenkle funksjoner og bruk. Videre i dette kapittelet vil vi presentere prototypene som knappebaserte, men først vil vi belyse forskjellen mellom QWERTY- og ABC-tastatur. 8.1 QWERTY- vs ABC-tastatur Hvis vi skulle bruke onscreen-tastatur som tekstinput, ville vi finne ut hva som er best av QWERTYog ABC rekkefølge. På datamaskiner er normen QWERTY, men mange billettautomater bruker ABC. Figur 8.1: ABC-tastatur utviklet i Flash Figur 8.2: QWERTY-tastatur utviklet i Flash Det ble utført en uformell test på Høgskolen i Oslo der målet var å finne ut hvilket tastatur som ville fungere best på berøringsskjerm. 61

Deltakere 15 datastudenter ved Høgskolen i Oslo uten synshemninger. Utstyr - Berøringsskjerm - Datamaskin for å registrere resultater - Flash-tastatur - Talesyntese Figur 8.3: Teststasjon under tastatur-test. Papp er limt på for å illustrere Split4-konseptet Metode Det vi ville finne ut var: - Preferanse - Hurtighet - Feilratio Oppgave Testpersonene ble presentert for en kopieringsoppgave. Oppgaven var å skrive ordet «Oslo». Dette skulle utføres både med og uten syn. Prosedyre Testpersonene ble ført inn i testlokalet og plassert foran berøringsskjermen. Alle testpersonene fikk de samme instruksene i henhold til oppgaven. Rekkefølgen for utføring av oppgaven var alltid den samme. Når testeren holdt fingeren over en av tastene på skjermtastaturet ble den markerte bokstaven lest opp ved hjelp av talesyntese. 62

Analyse av resultater Testet Antall testere Gjennomsnittstid (sek) Gjennomsnittsfeil QWERTY i blinde 15 45,6 0,8 QWERTY med syn 15 2,7 0,06 ABC i blinde 15 55,9 0,66 ABC med syn 15 3,6 0,13 Graf 8.1: Gjennomsnittstidunder tastaturtest Graf 8.2: Gjennomsnittsfeil under tastaturtest 63

Som man ser av tallene er QWERTY raskest og har lavest feilprosent, både i blinde og med syn. Tid uten syn Feil uten syn Testperson QWERTY ABC QWERTY ABC 1 35,3 36,7 0 0 2 39,2 47,7 0 0 3 34,6 16,9 0 1 4 39,8 27,8 3 1 5 134 28,3 1 2 6 31,5 25,2 0 1 7 29,5 21,3 2 0 8 45 16,8 0 1 9 24 50,7 1 1 10 22,7 76 2 0 11 104 24 0 1 12 77 50,6 0 2 13 54 87 0 0 14 28,8 118 1 0 15 140 57 2 0 Noe som kan ha påvirket resultatene er det faktum at testpersonene er datastudenter har vært godt eksponerte for denne type tastatur. Hvis testpanelet hadde vært av en mer variert brukergruppe, kunne resultatene vært annerledes. For mer utfyllende resultater se vedlegg (se punkt 15.3.1) 64

8.2 Split4 (Prototype) Prototype: Split4 Type: Absolutt Knappebasert Input: Knapper - Tastatur Verktøy: Penn og papir PowerPoint - Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Ja Figur 8.4: Split4 billettvalg Beskrivelse Split4 var den første prototypen som ble utviklet. Ideen er at skjermbildet deles opp i fire like store deler. Dette er et mønster som går igjen gjennom hele prototypen. Ved å bruke denne metoden vil brukeren enkelt kunne orientere seg ved hjelp av de fysiske hjørnene på berøringsskjermen. For å tydelig vise inndelingen av skjermen, har de fire delene hver sin unike farge. Fargene som ble valgt i denne versjonen var: Hver del blir fra nå av referert til som del 1, del 2 osv (starter fra øverst til høyre) - Del 1 Lyseblå bakgrunn, hvit skrift - Del 2 Grønn bakgrunn, Hvit skrift - Del 3 Blå bakgrunn, Hvit skrift - Del 4 Oransje bakgrunn, Hvit skrift 65

For hvert skjermbilde blir det opplest en instruksjon om hvilket valg som skal utføres. Dette kan for eksempel være «Velg Språk», eller «Velg type billett». Videre får brukeren lest opp alle valgmulighetene som er tilgjengelig. Dette kan være «Norsk, Engelsk, Tysk, Fransk». Brukeren får også bekreftelse i form av lyd når det er gjort et valg. Figur 8.5: Split4 språkvalg Når man kommer til skjermen for destinasjonsvalg valgte vi å bruke et onscreen tastatur. Det er plassert i del 1. Figur 8.6 Split4 destinasjonsvalg Som man ser er inndelingen ivaretatt, selv med introduksjonen av et tastatur. På bakgrunn av vår test, er tasterekkefølgen QWERTY, men på grunn av plassmangel er det 6 rekker, i motsetning til 3 på et vanlig QWERTY-tastatur. Det blir alltid gitt lydtilbakemelding på hvilken bokstav man har markert med fingeren. Dette er for å hjelpe brukeren med å navigere. Når brukeren taster inn en bokstav vil det i del 2 bli listet opp de mest besøkte stasjonene på den bokstaven. Stasjonene blir lest opp når man beveger fingeren over de. Hvis stasjonsvalgene ikke tilfredsstiller brukeren kan man fortsette å bruke tastaturet til å skrive sin destinasjon. 66

Figur 8.7: Split4 destinasjosnvalg Teknisk løsning Prototypen ble først skissert ved hjelp av penn og papir. Skissene finnes i appendiks (se punkt 15.1.1). Videre ble tegningene brukt som utgangspunkt i utviklingen av en interaktiv utgave i PowerPoint. Lydfilene som gir instruksjoner og tilbakemeldinger underveis ble laget i Voxit Budgie Pro som er et program for talesyntese. Lydformatet som ble brukt var MP3. PowerPoint gir gode muligheter for å integrere lyd, og det var enkelt å koble sammen lydfilene og prototypen. Farger Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men de har ikke gjenomgått testing. Type Del 1 Del 2 Del 3 Del 4 Tekst RGB R:205 G:243 B:255 R:149 G:187 B:69 R:79 G:129 B:189 R:255 G:154 B:48 R:255 G:255 B:255 HEX# CDF3FF 95BB45 4F81BD FF9A30 FFFFFF Comment/Colo r sample Type BakgrunnRader OppHøyre BakgrunnRader OppVenstre 1 BakgrunnRader OppVenstre 2 Tekst Tastatur RGB R:169 G:226 B:244 R:222 G:231 B:209 R:239 G:243 B:234 R:0 G:0 B:255 HEX# A9E2F4 DEE7D1 EFF3EA 0000FF Comment/Colo r sample 67

Test Testen ble utført i et grupperom i rolige omgivelser på Høgskolen i Oslo. Berøringsskjermen var satt opp på et bord med en stol foran. Testpersonen brukte sin egen hånd til å skjerme for øynene. Figur 8.8: Teststasjon Testpersonen fikk i oppgave å bestille en enkelbillett til Oslo. Som vanlig var det først med bind for øynene, og så med syn. I utgangspunktet fungerte konseptet med oppdeling av skjerm bra, men når det kom til det stadiet hvor det skal tastes inn destinasjon, oppsto det problemer. Under følger en liste over positive og negative observasjoner fra testen Positivt: - Instruksjonene i form av stemme fungerte bra - Testpersonen fant lett frem til hjørnene av skjermen - PowerPoint som testplattform fungerte bra Negativt: - Dårlig respons på skjerm - Mangel av tilbakefunksjon - Ruten nederst til venstre ble overflødig Konklusjon Det viste seg at PowerPoint som testplattform fungerte meget bra, og det faktum la grunnlaget for videre utvikling på plattformen. Det største problemet vi opplevde var skjermen. Den hadde lav følsomhet, og medførte at testpersonen måtte anstrenge seg unødvendig, som igjen bidro til unøyaktighet. Mangelen av tilbakefunksjon gjorde også at den var lite tolerant for feil. Vi satt igjen med inntrykket av konseptet er verdt å ta med seg videre, men det burde jobbes med delen hvor man skal velge destinasjon. Inndelingen av skjermen begrenset også valgmulighetene 68

8.3 Drag and Drop (Prototype) Prototype: Drag and Drop Type: Absolutt Input: Dra og slipp Verktøy: MS PowerPoint Lydtilbakemelding: Ja Testet: Nei Figur 8.9: Drag & Drop billettvalg Beskrivelse Prototypen baserer seg på dra og slipp. Konseptet er at brukeren drar bokser med valgmuligheter inn i bekreftelsesområdet. Deretter må man trykke nederst til høyre for å gå videre. Figur 8.10: Drag & Drop språkvalg Figur 8.11: Drag & Drop språkvalg 69

Teknisk løsning Dra og slipp funksjonen muliggjøres ved hjelp av en Visual Basic-makro i PowerPoint. Farger Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men de har ikke gjenomgått testing. Prototype: Type Drag and Drop Bakgrunn Knapp 1 Bakgrunn Knapp 2 Bakgrunn Knapp 3 Bakgrunn Knapp 4 RGB R:170 R:123 R:67 R:35 G:215 G:204 G:150 G:77 B:219 B:210 B:158 B:81 HEX# AAD7DB 7BCCD2 43969E 234D51 112123 Comment/Colo r sample Gradient Bakgrunn Knapp 5 R:17 G:33 B:35 Type Knapp tekst Bakgrunn Dra hit Verifisere knapp Bakgrunn Knapp 6.1 Bakgrunn Knapp 6.2 RGB R:255 G:255 B:255 R:190 G:190 B:190 R:57 G:216 B:57 R:117 G:117 B:220 R:255 G:0 B:0 HEX# FFFFFF BEBEBE 39D839 7575DC FF0000 Comment/Colo r sample Type Bakgrunn Knapp 6.3 RGB R:51 G:204 B:51 HEX# 33CC33 Comment/Colo r sample 70

Test Ikke utført på grunn av manglende tro på løsningen. Erfaringer Dette er en meget eksperimentell løsning. I forhold til blinde og svaksynte har den ingen faktiske fordeler. Man vil tro at et mer klassisk design, slik som de eksisterende automatene til NSB har i dag, vil fungere bedre. 8.4 Numb3rs (Prototype) Prototype: Numb3rs Type: Absolutt Knapp/Tall-basert Input: Knapper - Talltastatur Verktøy: Penn og papir PowerPoint - Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Nei Figur 8.12: Numb3rs billettvalg Beskrivelse Inspirasjonen til denne løsningen kom fra Sør-Korea. Den baserer seg på at alle destinasjoner er gitt et unikt nummer. Dette forenkler destinasjonsvalg betraktelig. Resten av prototypen er også basert på tall. Hvert tall representerer et valg, og brukeren må bruke et onscreen talltastatur som inputmetode. Tallene blir lest opp ved berøring. 71

På bildet under ser man hvordan dette kan gjøres: Figur 8.13: Skilt på togstasjon fra Sør-Korea Foto: Frode Eika Sandnes Figur 8.14: Numb3rs destinasjonsvalg Bildet over viser hvordan destinasjonsvalg utføres. Tastaturet kan ses på høyre side. Hele denne siden er reservert til tastaturet. Når de tre tall som utgjør nummerkoden er tastet inn, vil destinasjonen bli lest opp. Teknisk løsning Prototypen ble utviklet i PowerPoint. Farger Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men de har ikke gjenomgått testing. 72

Prototype: Numb3rs Type Velkomstskjerm Tekst Bakgrunn Knapp 1 Bakgrunn Knapp 2 Bakgrunn Knapp 3 RGB R:255 G:0 B:0 R:0 G:0 B:0 R:255 G:0 B:0 R:0 G:176 B:80 R:255 G:255 B:0 HEX# FF0000 000000 FF0000 00B050 FFFF00 Comment/Colo r sample Type Bakgrunn Knapp 4 Bakgrunn Knapp 5 Tekst input Bakgrunn Numpad RGB R:0 G:32 B:96 R:0 G:176 B:240 R:255 G:255 B:255 R:127 G:127 B:127 HEX# 002060 00B0F0 FFFFFF 7F7F7F Comment/Colo r sample Test Ikke utført på grunn av manglende tro på løsningen. Erfaringer Løsningen introduserer et interessant konsept, men er avhengig av at brukeren vet nummerkoden til destinasjonen. Videre er onscreentastatur alltid vanskelig å bruke for synshemmede, selv med lydtilbakemelding. 73

8.5 Cake8 (Prototype) Prototype: Cake8 Type: Absolutt Knappebasert Input: Sirkulære knapper Verktøy: Penn og papir Adobe Flash CS4 Lydtilbakemelding: Ja Testet: Nei Figur 8.15: Cake8 type reisende Beskrivelse Fra våre mange tester, både formelle og uformelle, la vi merke til en tendens blant mange av testpersonene. Spesielt ved bruk av Swipe4 og Swipe8 gjorde de en sirkulær bevegelse for å utforske menyvalg. Denne løsningen prøver å utforske dette nærmere. Alle menyvalg er plassert som kakestykker i et kvadrat. Når brukeren har fingeren over et valg vil dette valget leses opp av talesyntese. For å bekrefte valget må brukeren utføre et dobbelt-tap på samme sted. Posisjoneringen av valgene gjør at det kan gjøres en sirkulær bevegelse for å orientere seg i henhold til menyvalg. Dette er illustrert på bildet under. 74

Figur 8.16: Cake8 type reisende Teknisk løsning Dette er en enkel flash applikasjon. Vi blir ikke til å gå nøyere inn på teknologien som ligger bak. Farger Type Bakgrunn Tekst & linje Utheving RGB R: 102 G:102 B:102 R:255 G:255 B:255 R:51 G:51 B:51 HEX# 666666 FFFFFF 333333 Comment/Colo r sample Erfaringer Løsningen utforsker en interessant teori rundt sirkulære bevegelser. Grunnet mangel av tid ble det dessverre ikke utført tester på prototypen. Det er absolutt et potensial for videreutvikling. Vi ser for oss at mønsteret beholdes gjennom hele prototypen, slik at kontinuitet oppnås. 75

8.6 Tap4 (Prototype) Prototype: Tap4 Type: Relativ Trykkbasert Input: Enkelt trykk Dobbelt trykk Trippel trykk Kvadruppel trykk Verktøy: Penn og papir Flash Lydtilbakemelding: Ja Testet: Nei Beskrivelse Denne ideen handler om at brukeren skal benytte fingeren til å trykke et visst antall ganger for å gjøre valg. Følgende eksempel beskriver prosessen ved å velge type billett: - Enkelbillett Ett trykk - Tur/Retur To trykk - Periodebillett Tre trykk - Referanse Fire trykk Sånn vil det fortsette gjennom hele bestillingsprosessen. Det som er interessant med denne løsningen er at trykkene er ikke avhengig av posisjon på skjermen. Det er mulig å utføre valgene hvor som helst, så lenge det innenfor skjermens rammer. Dette var vårt første forsøk på en relativ prototype. Teknisk løsning Ideen ble prøvd realisert i Flash. Det viste seg etter hvert at vi fikk problemer med utviklingen, og løsningen fungerte ikke på måten forespeilt. Av den grunn valgte vi å ikke gå videre med denne prototypen Test Ikke utført på grunn av manglende tro på løsningen. Erfaringer Tanken er god, men den fungerte ikke tilfredsstillende i praksis. Det ville for eksempel vært vanskelig å implementere destinasjonsvalg. 76

Kapittel 9 Eliminering 77

78

Elimineringsbasert teknologi fungerer ved å utelukke valgmuligheter. Dette kan gjøres gjennom stavelse, geografi, kjennetegn eller lignende. På denne måten vil man kunne utelukke mange alternativer på en gang og øke effektiviteten ved mange av elementene i en automat. Prototypene i denne delen er en kombinasjon av eliminering og knapper. En slik løsning har også den bakdelen at den er absolutt, i likhet med knappebaserte løsninger. Dagens NSB automat benytter elimineringsteknologien når man skal velge stasjoner. Metoden fungerer ved at et tastatur som er basert på knappeteknologi vises på skjermen. Ettersom man velger bokstaver i navnet på stasjonen man ønsker å reise til blir andre alternativer eliminert og man sitter til slutt igjen med ønsket reisemål. Vi har valgt å benytte oss av denne teknologien ved alle valgfunksjoner der det er flere muligheter. Et lydgrensesnitt har også blitt implementert her, da dette er essensielt for at automaten skal kunne betjenes av alle brukergrupper. 9.1 Stegis Stegern (Prototype) Prototype: Stegis Stegern Type: Absolutt Knappebasert Eliminasjon Input: Knapper Eliminasjon Verktøy: Penn og papir PowerPoint - Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Ja Figur 9.1: Stegis stegern bokstavvalg 79

Beskrivelse Prototypen er en videreutvikling av Split4 (se punkt 8.2). Den beholder konseptet, men det er igjen en ny metode for stasjonsvalg. Metoden baserer seg på eliminering ved hjelp av stavelsen av stasjonsnavnet. På denne måten eliminerer man stasjoner etter hvert som man velger flere bokstaver i navnet på stasjonen. Instruksjoner og tilbakemelding til brukeren blir gitt gjennom lyd. Figur 9.2: Stegis stegern bokstavvalg På førsteskjermen velger man forbokstaven i navnet på stasjonen. Ved hjelp av lyd får man opplest hvordan man skal gå frem for å ta riktig valg. Figur 9.3: Stegis stegern Valg av de to første bokstavene i destinasjon Teknisk løsning Prototypen ble først skissert ved hjelp av penn og papir. Den ble skissert opp og disse tegningene finnes i appendiks (se punkt 15.1.7). Videre ble tegningene brukt som utgangspunkt i utviklingen av en interaktiv utgave i PowerPoint. 80

Lydfilene som gir instruksjoner og tilbakemeldinger underveis ble laget i Voxit Budgie Pro som er et program for talesyntese (punkt 6.4). Lydformatet som ble brukt var MP3. PowerPoint gir gode muligheter for å integrere lyd, og det var enkelt å koble sammen lydfilene og prototypen. Farger Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men har ikke gjenomgått testing. Type Bakgrunn Bakgrunn Bakgrunn Bakgrunn Tekst OppVenstre OppHøyre NedVenstre NedHøyre RGB R: 79 G:129 B:189 R:192 G:80 B:77 R:155 G:187 B:89 R:247 G:150 B:70 R:255 G:255 B:255 HEX# 4F81BD C0504D 9BBB59 F79646 FFFFFF Comment/Colo r sample Test Testen ble utført i et grupperom i rolige omgivelser på Høgskolen i Oslo. Berøringsskjermen var satt opp på et bord med en stol foran. Testpersonen brukte sin egen hånd til å skjerme for øynene. Figur 9.4: Teststasjon Testpersonene skulle kjøpe billett til Sandnes. Først i blinde og så med syn. Testet Antall testere Gjennomsnittstid (sek) Gjennomsnittsfeil I blinde 15 168 1,9 Med syn 15 10,3 0 Som man ser er det stor forskjell mellom blind og med syn. Det skiller hele 157,7 sekunder. Begge er akseptable tider. Feilratioen er overraskende lav, noe som skyldes grundige instruksjoner. 81

Den generelle tilbakemeldingen var at det var lett å forholde seg til inndelingen og de skjønte prinsippet. Graf 9.1: Antall sekunder brukt under test av Stegis Stegern uten syn Graf 9.2: Antall sekunder brukt under test av Stegis Stegern med syn For utfyllende resultater (se punkt 15.3.2) Erfaringer Siden den er basert på Split4, har den like begrensinger når det gjelder antall valg. Det nye elimineringsbaserte destinasjonsvalget løser dette, om mulig noe uelegant. Den lave feilratioen er betryggende, og styrker vår tro på løsningen. 82

9.2 GeoElim (Prototype) Prototype: GeoElim Type: Absolutt Knappebasert Elimineringsbasert Input: Knapper - Eliminasjon Verktøy: Penn og papir - GUI Design Studio PowerPoint - Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Nei Figur 9.5: GeoElim destinasjonsvalg Beskrivelse Denne prototypen er basert på Split4, med en modifikasjon av destinasjonsvalgprosessen. Det vil si at den benytter seg ikke av onscreen tastatur. Derimot introduserer vi en elimineringsløsning. Den fungerer på den måten at man gjør en rekke valg for å eliminere antall destinasjoner. Det første man gjør er å velge hvilken landsdel man vil reise til. Denne prosessen utelukker mange destinasjoner. Man kan velge mellom 4 valg: - Østlandet - Sørlandet - Vestlandet - Midt-Norge/Nord-Norge Midt-Norge og Nord-Norge ble slått sammen grunnet få destinasjoner i disse landsdelene. 83

Figur 9.6: GeoElim landsdelvalg Videre velger man forbokstaven til sin destinasjon basert på bokstavgruppene. Gruppene er delt inn med 3 bokstaver per valg. Dette er for å opprettholde gjengangen av kun 4 valg på de neste skjermbildene. Hvis bokstaven man leter etter ikke finnes på skjermbildet bruker man «Neste»- knappen for å få flere valgmuligheter. Figur 9.7: GeoElim bokstavgruppevalg På denne skjermen ser man konsekvensene av å ha gått vekk fra tastatur. Nå er del 1, del 2 og del 3 delt opp i ytterligere deler med en stasjon i hver rute. Når man skal velge en stasjon holder man over rutene for å få en tilbakemelding via lyd. Hvis man har funnet riktig stasjon bekrefter man valget ved å trykke enda en gang på ruten. Man vil da få en bekreftelse på valget: «Du har valgt Asker stasjon». For å gå videre trykker man så på del 4 som er en «Neste»-knapp. 84

Figur 9.8: GeoElim destinasjonsvalg Alle valgmulighetene er representert med lyd. Når brukeren holder fingeren over hver enkelt rute/del vil en stemme lese opp valget. Teknisk løsning Prototypen ble først skissert ved hjelp av penn og papir. Den ble skissert opp, men skissene gikk tapt under arbeidsprosessen. Videre ble tegningene brukt som utgangspunkt i utviklingen av en interaktiv utgave i PowerPoint. Lydfilene som gir instruksjoner og tilbakemeldinger underveis ble laget i Voxit Budgie Pro som er en talesyntese (se punkt 6.4). Lydformatet som ble brukt var MP3. PowerPoint gir gode muligheter for å integrere lyd, og det var enkelt å koble sammen lydfilene og prototypen. Farger Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men de har ikke gjenomgått testing. Type Bakgrunn Bakgrunn Bakgrunn Bakgrunn Tekst OppVenstre OppHøyre NedVenstre NedHøyre RGB R:255 G:0 B:0 R:79 G:129 B:189 R:146 G:208 B:80 R:255 G:255 B:0 R:0 G:0 B:0 HEX# FF0000 4F81BD 92D050 FFFF00 000000 Comment/Colo r sample Test Ikke utført på grunn av manglende tro på løsningen. 85

Erfaringer Et av elementene ved Split4 var den enkle utformingen. Fire deler gjør den oversiktlig og enkel i bruk. GeoElim går vekk fra dette. Den ekstra inndelingen av skjermen ved destinasjonsvalg bidrar til forvirring, og kan oppfattes som rotete Det er vanskelig å si om en slik løsning har en fremtid, i så fall tror vi at den må ses i sammenheng med Stegis Stegern og Split4, slik at det utvikles en hybrid. 86

Kapittel 10 Swipe 87

88

Etter å blitt inspirert av iphone som bruker sveipbevegelser i stor grad, utviklet vi Swipe. Swipe baserer seg på retningsbestemte sveipbevegelser. Konseptet benytter seg av bevegelse i stedet for trykk. Dette er en helt ny måte å tenke på i forbindelse med selvbetjeningsautomater. Denne løsningen hadde ikke vært mulig med eldre teknologi. Det unike med løsningen er det faktum at disse bevegelsene kan utføres med en relativ tilnærming. Fingerbevegelsen kan starte og ende hvor som helst på skjermen. For å gjøre valg ved bruk av denne teknologien sveiper man fingeren i den retningen hvor valget man ønsker befinner seg. Det er retningen på sveipet som bestemmer utfallet. Maks antall retninger er fra en til åtte. Flere enn dette vil sannsynligvis forvirre brukeren og det vil være vanskelig å operere automaten. På grunn av løsningens relative natur vil blinde og svaksynte sannsynligvis kunne bruke en slik løsning. De er derimot avhengig av et lydgrensesnitt. Dette vil bli forklart i detalj i prototyprapportene. 10.1 Teknisk løsning Her presenteres teknologien som ligger til grunn for Swipe. Det er kodet i actionscript 3.0. Forklaringer og kodesnutter vises under. Først lages variabler som skal brukes senere. Fire som skal holde start og slutt koordinater, og to som definerer minimumslengde på sveip. De ulike typer gestures blir også tildelt et tall fra 1-9. 1. var startx:number; 2. var starty:number; 3. var endx:number; 4. var endy:number; 5. var minlengthx:number; 6. var minlengthy:number; 7. var NOTHING:Number = 1; 8. var rightgesture:number = 2; 9. var leftgesture:number = 3; 10. var upgesture:number = 4; 11. var downgesture:number = 5; 12. var skewedupperrightgesturenumber = 6; 13. var skewedupperleftgesture:number = 7; 14. var skeweddownrightgesture:number = 8; 15. var skeweddownleftgesture:number = 9; Deretter implementeres det «mouselisteners». Disse overvåker musetrykk og museslipp. Så beregnes minimumsveip ved å dele skjermbildet på åtte. 16. stage.addeventlistener(mouseevent.mouse_down, mouse_down); 17. stage.addeventlistener(mouseevent.mouse_up, mouse_up); 18. var _stage:stage = this.stage; 19. minlengthx = _stage.stagewidth / 8; 20. minlengthy = _stage.stageheight / 8; 89

Her lages funksjonen som kalles ved musetrykk. X og Y koordinatene til museposisjonen lagres i variablene startx og starty. 21. function mouse_down(e:mouseevent) 22. { 23. startx = stage.mousex; 24. starty = stage.mousey; 25. } Her lages funksjonen skal kalles ved museslipp. X og Y koordinatene til museposisjonen lagres i variablene endx og endy. Deretter kalles funksjonen checkgesture(). 26. function mouse_up(e:mouseevent){ 27. endx = stage.mousex; 28. endy = stage.mousey; 29. checkgesture(); 30. } checkgesture() sjekker hvilken gesture brukeren har utført. Variabelen usergesture inneholder i utgangspunktet tallet null. Så brukes en switch-struktur for å sjekke type gesture. Dette beregnes ved hjelp av xdelta, ydelta og minlengthx, minlengthy. Type gesture blir så lagt inn i variabelen usergesture. Hvis usergesture ikke er satt til null kalles funksjonen handlegesture med usergesture som parameter. 31. function checkgesture() 32. { 33. var xdelta:number = endx - startx; 34. var ydelta:number = endy - starty; 35. trace( xdelta: +xdelta); 36. trace( ydelta: +ydelta); 37. var usergesture:number = 0; 38. var switchgesture:boolean = true; 39. switch(switchgesture) 40. { 41. case ((xdelta > minlengthx) && (ydelta < - minlengthy)):. 42. usergesture = skewedupperrightgesture; 43. break; 44. case ((xdelta < - minlengthx) && (ydelta < - minlengthy)): 45. usergesture = skewedupperleftgesture; 46. break; 47. case ((xdelta > minlengthx) && (ydelta > minlengthy)): 48. usergesture = skeweddownrightgesture; 49. break; 50. case ((xdelta < - minlengthx) && (ydelta > minlengthy)): 51. usergesture = skeweddownleftgesture; 52. break; 53. case (xdelta > minlengthx): 54. usergesture = rightgesture; 55. break; 56. case (xdelta < - minlengthx): 57. usergesture = leftgesture; 58. break; 59. case (ydelta < - minlengthy): 60. usergesture = upgesture; 61. break; 90

62. case (ydelta > minlengthy): 63. usergesture = downgesture; 64. break; 65. default: 66. gesture = NOTHING; 67. break; 68. } 69. 70. if(usergesture!= 0) 71. { 72. handlegesture(usergesture); 73. } Denne funksjonen utfører handlinger basert på sveiperetning. usergesture som ble sendt med som parameter i forrige funksjon brukes til å avgjøre hvilken handling som skal utføres. Selve handlingene er ikke tatt med da de er flash relatert og vil ikke gi mening for leseren. 74. function handlegesture(usergesture:number) 75. { 76. } 77. if(usergesture == rightgesture) 78. { 79. //perform action based on gesturedirection 80. } 81. } 82. 83. else if(usergesture == leftgesture) 84. { 85. //perform action based on gesturedirection 86. } 87. else if(usergesture == upgesture) 88. { 89. //perform action based on gesturedirection 90. } 91. else if(usergesture == downgesture) 92. { 93. //perform action based on gesturedirection 94. } 95. else if(usergesture == skewedupperrightgesture) 96. { 97. //perform action based on gesturedirection 98. } 99. else if(gestureflags == skewedupperleftgesture) 100. { 101. //perform action based on gesturedirection 102. } 103. else if(gestureflags == skeweddownrightgesture) 104. { 105. //perform action based on gesturedirection 106. } 107. else if(gestureflags == skeweddownleftgesture) 108. { 109. //perform action based on gesturedirection 110. } 111. else if(gestureflags == NOTHING) 112. { 113. } } 91

10.2 Swipe4 (Prototype) Prototype: Swipe4 Type: Relativ Sveipbasert Input: Sveip Verktøy: Penn og papir PowerPoint Flash- Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Ja Figur 10.1: Swipe4 billettvalg Beskrivelse Denne prototypen baserer seg på at brukeren sveiper fingeren over skjermen i ulike retninger. Hver av retningene representerer et valg. Man har muligheten til å sveipe i fire retninger: - Opp - Høyre - Ned - Venstre På hver valgskjerm blir de ulike valgmulighetene lest opp. Brukeren kan da gjøre sitt valg ved å sveipe fingeren i ønsket retning. 92

Det som er unikt med denne løsningen er det relative aspektet. Det har ikke noe å si hvor på skjermen sveipbevegelsen startes. Man oppnår ved dette en universell løsning uten krav til syn eller andre forutsetninger. Brukeren starter ved å velge språk: - Opp Norsk - Høyre Engelsk - Ned Tysk - Venstre Fransk Videre velger man type billett: - Opp Enkel - Høyre - Tur/Retur - Ned Forhåndsbestilt - Venstre Periode Så kommer man til destinasjonsvalget. Her startes det med å velge landsdel: Figur 10.2: Swipe4 geografivalg Destinasjonene er delt inn geografisk og dette eliminerer mange fremtidige valgmuligheter som forenkler prosessen for brukeren. 93

Deretter velges bokstavgruppe etter hvilken bokstav destinasjonen begynner på: Figur 10.3: Swipe4 bokstavgruppevalg For å velge riktig destinasjon sveiper man fingeren til høyre eller venstre. Hvis destinasjonen begynner på en annen bokstav drar man fingeren opp eller ned for å forandre denne. Her får man også direkte tilbakemelding i form av lyd. For eksempel når brukeren bytter bokstav blir denne lest opp. Dette for å hjelpe brukeren til å orientere seg. Figur 10.4: Swipe4 destinasjonsvalg Teknisk løsning Første steg i utviklingsprosessen var å skissere med penn og papir. Det var en omfattende prosess og alle mulige scenarioer og problemstillinger ble kartlagt. Den er så å si identisk med det endelige produktet utviklet i Flash. Farge Hovedfokuset under utviklingen var utformingen av prototypen. Hvis prototypen møtte våre endelige krav, skulle vi ved en senere anledning gå mer inn på fargevalg og kontrast. Fargene på prototypen var etter beste evne, men de har ikke gjenomgått testing 94

Type Bakgrunn Tekst Piler RGB R:255 G:255 B:255 R:0 G:0 B:0 R:200 G:218 B:254 HEX# FFFFFF 000000 C8DAFE Comment/Color sample Test Ikke utført grunnet videreutvkling. Erfaringer Konseptet med sveiping er en helt ny måte å tenke på i sammenheng med selvbetjeningsautomater. I motsetning til tidligere prototyper er den relativ, og dette sammen med et lydgrensesnitt, muliggjør bruk for synshemmede. Ulempen er begrensingen med fire retninger, noe som vi har utbedret i neste prototype som blir presentert. 95

10.3 Swipe8 (Prototype) Prototype: Swipe8 Type: Relativ Sveipbasert Input: Sveip Verktøy: Penn og papir PowerPoint Flash- Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Ja Figur 10.5: Swipe8 billettvalg Beskrivelse Swipe8 er en videreutvikling av Swipe4. Den baserer seg også på at brukeren sveiper fingeren over skjermen i ulike retninger. Det som er unikt med denne løsningen er det relative aspektet. Det har ikke noe å si hvor på skjermen sveipbevegelsen startes. Man oppnår ved dette en universell løsning uten krav til syn eller andre forutsetninger. I motsetning til Swipe4, kan man i denne versjonen sveipe fingeren i åtte retninger. - Opp - Skrått opp til høyre - Høyre - Skrått ned til høyre - Ned 96

- Skrått ned til venstre - Venstre - Skrått opp til venstre Seks av retningene er knyttet til valgmuligheter, mens høyre og venstre fungerer som «Neste» og «Tilbake»-knapper. Det er ikke mulig å benytte «Neste»-knappen uten å ha gjort et valg. Det første skjermbildet brukeren ser er en liste med instruksjoner for bruk av automaten. Disse instruksjonene blir også lest opp av talesyntese. På hver valgskjerm kan brukeren dra fingeren i de åtte retningene. En stemme vil da lese opp valget som er tilknyttet retningen. Figur 10.6: Swipe8 billettvalg Hvis man ser på skjermbildet over blir lyden «Enkelbillett» lest opp ved sveiping oppover. Hvis brukeren ikke er fornøyd med valget, er det mulig å sveipe i de andre retningene for å høre andre valgmuligheter. Når brukeren er fornøyd med valget sitt, sveiper man til høyre for å bekrefte og gå videre til neste skjermbilde. Brukeren starter ved å velge språk: - Opp Norsk - Skrått opp til høyre Engelsk - Skrått ned til høyre Tysk - Ned Fransk Videre velger man type billett: - Opp Enkel - Skrått opp til høyre Tur/Retur - Skrått ned til høyre Periode - Ned Forhåndsbestilt 97

Så velger man antall billetter: Figur 10.7: Swipe8 antall billetter Neste er type reisende: Figur 10.8: Swipe8 type reisende 98

Destinasjonsvalg steg 1. Her velger man forbokstaven til destinasjonen basert på bokstavgruppene: Figur 10.9: Swipe8 bokstavgruppe Destinasjonsvalg steg 2. Her velger man første bokstaven i destinasjonen: Figur 10.10: Swipe8 forbokstav til destinasjon 99

Destinasjonsvalg steg 3. Her velger man de to første bokstavene i destinasjonen. Figur 10.11: Swipe8 to første bokstavene i destinasjon Destinasjonsvalg steg 4. Her velger man destinasjon. Figur 10.12: Swipe8 destinasjonsvalg 100

Oppsummeringsskjerm. Brukeren sveiper oppover for å høre valgene som er utført: Figur 10.13: Swipe8 oppsummering Betalingskjerm: Figur 10.14: Swipe8 betalingsvalg Teknisk løsning Første steg i utviklingsprosessen var å skissere med penn og papir (se punkt 6.2). Det var en omfattende prosess og alle mulige scenarioer og problemstillinger ble kartlagt. Den er så å si identisk med det endelige produktet utviklet i Flash. Farge Fargene til denne prototypen er nøye gjennomtenkt. Alle mennesker har forskjellig preferanse når det kommer til farge og kontrast. Derfor ble tre fargeutkast laget til denne prototypen. Disse finnes i appendiks (se punkt 15.4) 101

Type Bakgrunn Tekst & linje Piler Piler & Tekst hevet RGB R:68 G:72 B:87 R:255 G:255 B:255 R:83 G:194 B:220 R:253 G:160 B:19 HEX# 444857 FFFFFF 53C2DC FDA013 Comment/Colour sample Fargene ble testet ved hjelp av en fargekontrastkalkulator. Den tester bakgrunn- og forgrunnsfarger og sjekker om de tilfredsstiller kravene til WCAG 2.0. Fargekombinasjonen mellom bakgrunn og tekst/linje oppfyller AAA kravene til WCAG, mens kombinasjonen mellom bakgrunn og uthevet piler og tekst oppfyller AA kravene. Test På denne prototypen ble det utført en uformell og to formelle tester. Uformell Deltakere 15 datastudenter ved Høgskolen i Oslo uten synshemninger. Utstyr - Berøringsskjerm - Datamaskin for å registrere resultater - Talesyntese Metode Formålet med testen var å finne ut om konseptet fungerte som forespeilet. Oppgave Testpersonene fikk et gitt scenario som skulle utføres. Dette var følgende: - Norsk språk - Enkelbillett - 1 billett - Bilettype voksen - Destinasjon Sandvika - Høre oppsummering - Betale med bankkort 102

Prosedyre Testpersonene ble ført inn i testlokalet og plassert foran berøringsskjermen. Alle testpersonene fikk de samme instruksene i henhold til oppgaven. Rekkefølgen for utføring av oppgaven var alltid den samme. Analyse av resultater Testet Antall testere Gjennomsnittstid (sek) Gjennomsnittsveip I blinde 15 175 38 Test ID Tid sek Swipes 1 153 34 2 210 46 3 173 34 4 132 30 5 141 39 6 135 36 7 168 36 8 209 38 9 131 31 10 194 47 11 166 37 12 147 34 13 137 29 14 350 58 15 178 40 Graf 10.1: Antall sekunder og sveipbevgelser brukt under uformell test av Swipe8 103

Testpersonene synes dette var en enkel og morsom måte å utføre oppgaven på. De aller fleste testpersonene skjønte raskt hvordan systemet fungerte. Det var enighet om at man ikke trengte syn for å kunne benytte seg av løsningen. Formell 1 Deltakere Fem ansatte ved Blindeforbundet. Alle hadde forskjellig grad av synshemninger. Utstyr - Berøringsskjerm - Datamaskin for å registrere resultater - Talesyntese Metode Formålet med testen var å finne ut hvordan løsningen fungerte for personer med synshemninger. Oppgave Testpersonene fikk et gitt scenario som skulle utføres. Dette var følgende: - Norsk språk - Enkelbillett - 1 billett - Bilettype voksen - Destinasjon Moss - Høre oppsummering - Betale med bankkort Prosedyre Testpersonene ble ført inn i testlokalet og plassert foran berøringsskjermen. Alle testpersonene fikk de samme instruksene i henhold til oppgaven. Rekkefølgen for utføring av oppgaven var alltid den samme. Analyse av resultater Antall testere Gjennomsnittstid (sek) Gjennomsnittsveip 5 297 41 104

Test ID Tid sek Swipes 1 165 34 2 690 46 3 234 31 4 200 53 5 196 42 Graf 10.2: Antall sekunder og swipes brukt under første formelle test av Swipe8 Løsningen ble tatt godt i mot av testpanelet. En av testpersonene utalte at han ikke trodde det var mulig å lage noe så enkelt, men likevel så komplekst. De av testpersonene som var blinde ga utrykk for at dette var første gang de kunne bruke en berøringsskjerm. Det var forskjellige innspill på bokstavgruppe-valget, men som testpersonene sa blir dette individuelle preferanser. Dette gjalt også kontrastene på prototypen. Formell 2 Deltakere 11 personer med forskjellig grad av svaksynthet. Utstyr - Berøringsskjerm - Datamaskin for å registrere resultater - Talesyntese 105

Figur 10.15: Teststasjon hos Blindeforbundet Metode Formålet med testen var å finne ut hvordan løsningen fungerte for personer med forskjellig grad av svaksynthet. Oppgave Testpersonene fikk et gitt scenario som skulle utføres. Dette var følgende: - Norsk språk - Enkelbillett - 1 billett - Bilettype voksen - Destinasjon Moss - Høre oppsummering - Betale med bankkort Prosedyre Testen foregikk i et åpent landsskap. Testpersonene ble ført plassert foran berøringsskjermen. Alle testpersonene fikk de samme instruksene i henhold til oppgaven. Rekkefølgen for utføring av oppgaven var alltid den samme. 106

Analyse av resultater Antall testere Gjennomsnittstid (sek) Gjennomsnittsveip 11 197 29 Test ID Tid sek Swipes 1 196 30 2 118 21 3 105 21 4 227 24 5 170 23 6 231 25 7 258 36 8 385 46 9 125 21 10 173 52 11 174 24 Graf 10.3: Antall sekunder og swipes brukt under andre formelle test av Swipe8 Denne sveipbaserte løsningen ble godt mottatt av testpanelet. Konseptet var lett å forstå og sammen med instruksjonene var det ingen som hadde problemer med å utføre oppgaven de ble presentert for under testing. En observasjon som ble gjort under testen var at noen av testpersonene brukte sirkulære bevegelser for utforskning av menyvalg. Dette tok vi til oss og ble realisert i en annen prototype. En annen observasjon vi gjorde var et gjentatt bruk av automaten fører til raskere tid og færre sveip. For detaljerte resultater og tilbakemeldinger fra testene se punkt 15.3.3. 107

10.4 Scrollslide (Prototype) Prototype: ScrollSlide Type: Relativ Sveipbasert Input: Sveip Tap Verktøy: Penn og papir PowerPoint Flash- Voxit Budgie Pro Lydtilbakemelding: Ja Testet: Nei Figur 10.16 ScrollSlide-tastatur Beskrivelse Denne prototypen begrenser seg til destinasjonsvalg. Konseptet er at alfabetet blir presentert horisontalt, og brukeren skal sveipe fingeren i høyre og venstre retning for å bla gjennom bokstavene. Bokstaven blir så lest opp av talesyntese. Når ønsket bokstav er lokalisert, dobbeltapper man for å bekrefte valget. Da vil alle bokstavene som hittil er valgt bli lest opp. På denne måten kan brukeren stave ønsket destinasjon. Løsningen er relativ. Det vil si at det kan sveipes hvor som helst på skjermen. Teknisk løsning Første steg i utviklingsprosessen var å skissere med penn og papir. Det var en omfattende prosess og alle mulige scenarioer og problemstillinger ble kartlagt. Den er så å si identisk med det endelige produktet utviklet i Flash. Farger Type Bakgrunn Bakgrunn Piler Bakgrunn Tekst Oppe Midten Tekst RGB R:0 G:176 B:80 R:255 G:255 B:255 R:79 G:129 B:189 R:142 G:180 B:227 R:0 G:0 B:0 HEX# 00B050 FFFFFF 4F81BD 8EB4E3 000000 Comment/Color sample Test Ikke utført på grunn av manglende tro på løsningen. 108

Erfaringer Det positive ved denne prototypen er at det er kun to retninger å forholde seg til, men dette er også en begrensning. Personer med erfaring fra iphone vil kjenne seg igjen, da disse bevegelsene går igjen i flere av telefonens funksjoner. At man alltid må bla seg frem til en bokstav kan også sees på som en ulempe. Man har ikke muligheten til å gå direkte til ønsket bokstav, noe som kan være frustrerende hvis man ser skjermbildet. 109

110

Kapittel 11 Lyd 111

112

Lyd har vært en essensiell del av våre prototyper. Her vil vi presentere prototyper som bruker lyd på en litt mer spesiell måte. Å gi informasjon i form av lyd er en svært nyttig og effektiv måte å gi brukeren tilbakemeldinger på. Brukeren får med dette en bedre oversikt over systemet. Hørbar lyd er svært viktig for mennesket, det utgjør den viktigste måten å kommuniserer på oss mennesker imellom. 11.1 Swipe8_ambient (Prototype) Prototype: Swipe8_ambient Type: Relativ Input: Sveip Verktøy: Adobe Flash CS4 Lydtilbakemelding: Ja Testet: Nei Figur 11.1: Swipe8_ambient billettvalg Beskrivelse Prototypen er basert på Swipe8. Den baserer seg på at lyder skal brukes som et stemningsskapende virkemiddel. En unik lyd spilles av i bakgrunnen av hvert skjermbilde. Poenget er at brukeren skal benytte seg av denne lyden, bevisst eller ubevisst, for å orientere seg i billettkjøpsprosessen. Teknisk løsning Lik løsning som øvrige swipe-varianter. 113

Farger Fargene til denne prototypen er nøye gjennomtenkt. Alle mennesker har forskjellig preferanse når det kommer til farge og kontrast. Derfor ble tre fargeutkast laget til denne prototypen. Disse finnes i appendiks (se punkt 15.4) Type Bakgrunn Tekst & linje Piler Piler & tekst hevet RGB R:68 G:72 B:87 R:255 G:255 B:255 R:83 G:194 B:220 R:253 G:160 B:19 HEX# 444857 FFFFFF 53C2DC FDA013 Comment/Colou r sample Test Ikke utført grunnet tidsmangel. Erfaringer Dette er et veldig spennende konsept, og vi skulle gjerne kjørt testing på det, men tidsbegrensninger gjorde at dette ikke ble mulig. Det hadde vært interessant å sammenlignet resultatene med den originale swipe8 prototypen. Et aspekt som kan tenkes å skape problemer er om den simultane avspillingen av instruksjonslydene og bakgrunnslydene vil forstyrre brukeren i den grad at ingen av lydene oppfattes. Testing ville avdekket dette. 11.2 VoiceBob (Prototype) Prototype: Type: Input: Verktøy: Lydtilbakemelding: Testet: Beskrivelse VoiceBob Relativ Talestyring Tale PowerPoint - Voxit Budgie Pro Flash Ja Nei VoiceBob er en prototype som baserer seg på talestyring. Man kommuniserer med automaten ved å gi kommandoer via tale. Kommandoene vil da bli oppfattet av prototypen og handlingene blir utført. Det vil si at man kan bestille en fullverdig billett uten å måtte røre automaten. Teknisk løsning For å få til denne løsningen ble programmet e-speaking brukt sammen med Adobe Flash CS4. E- Speaking tilbyr muligheten til å styre PCen med stemmen. Dette gjøres med kommandoer. 114

Kommandoer som «Enkelbillett», eller «Voksen» ble koblet til taster på tastaturet. Disse tastene ble igjen brukt som identifikatorer i flash applikasjonen. På denne måten simulerte vi talestyring. Test Ikke utført på grunn av manglende tro på løsningen. Erfaringer Det største problemet med talestyring er ingen personer prater helt identisk. Typisk vil en person som har behov for å styre PCen med stemmen sin spesialtilpasse hjelpeprogrammet. Det vil si å for eksempel lese inn en lengre tekst slik at programmet kan bli kjent med stemmen. I en situasjon hvor brukeren skal styre en automat på denne måten mister man denne tilpasningen og automaten vil få problemer med å oppfatte stemmekommandoene. I våre interne tester fikk vi overraskende gode resultater, programmet klarte å oppfatte flere forskjellige stemmer og dialekter. Det var dessverre tilfeller hvor kommandoer ikke ble oppfattet og det gjør løsningen uaktuell. I en mer realistisk situasjon hvor billettautomaten står ute på for eksempel en togstasjon, vil også bakgrunnslyder være en faktor. 115

116

Kapittel 12 Ikke-realiserte konsepter 117

118

Under prosjektperioden har vi vært inne på områder som har vært spennende, men som ikke har vært aktuelle for videre utvikling. Dette har som oftest vært på grunn av tidsbegrensning. Alle disse er samlet i dette kapittelet. 12.1 Håndskriftsgjenkjenning Berøringsskjermer begrenser muligheter, men teknologien åpner også for ny funksjonalitet. En av disse er håndskriftgjenkjenning. Teknologi for håndskriftgjenkjenning har vært tilgjengelig lenge for en rekke enheter. Dette har spesielt vært forbeholdt håndholdte enheter som palm tablets, og i det siste mobiltelefoner med berøringsskjerm. Dette har vært et interessant tema som vi tidlig ønsket å eksperimentere med. Målet i starten var å utvikle vår egen håndskriftgjenkjenningsapplikasjon i flash, men det stoppet på idéstadiet. Prinsippet bak programmeringen er relativt enkel, men tidsbegrensinger stoppet oss. Disse begrensingene tvang oss til å se på ekstern programvare som tilbydde slik funksjonalitet, men de ga varierende resultater. Den innebygde støtten i Windows 7 viste seg faktisk å gi best resultater. Å implementere noe slikt i en billettautomat vil være utfordrende. Skal hele løsningen basere seg på tekstinput, eller bare for destinasjon? Det kan tenkes at spesielt destinasjonsvalgprosessen kunne nyttegjort seg av dette. Dette setter krav til skriveferdighetene til brukeren. Personer med lese- og skrivevansker vil bli utelukket. Et interessant konsept som vi gjerne skulle utforsket nærmere. 12.2 Sonar Sonar er en teknikk som bruker lydbølger under vann til å navigere med eller detektere andre fartøyer. Vi ønsket å eksperimentere med dette, og eventuelt lage en prototype basert på teknikken. Vi så for oss at løsningen for destinasjonsvalg kunne se slik ut: - Brukeren blir presentert for et kart - Brukeren drar fingeren over kartet for å finne destinasjon - Brukeren får tilbakemelding i form av en lyd som representerer avstanden til destinasjoner - Lyden er svak når det ikke er noen destinasjoner i nærheten - Lyden er sterk når det er destinasjoner i nærheten Eventuelle valg vil da for eksempel kunne bekreftes ved dobbelt-tap. En slik løsning hadde vært mulig å implementere i flash. Det er vanskelig å si om noe slikt kunne fungert, men det hadde vært interessant å kjørt tester på det for å få avkreftet eller bekreftet teknikken. 119

120

Kapittel 13 Etter prosjektet 121

122

13.1 Valgt løsning I løpet av prosjektperioden har vi vært innom mange løsninger. Den vi anser som har kommet nærmest en mulig løsning, er Swipe8. Det er helt klart den prototypen vi har brukt mest tid på, og det er ikke uten grunn. Vi skjønte tidlig at det var en løsning verdt å satse på. Grunnen til dette var det relative aspektet. Prototypen tillater sveip uavhengig av start- og sluttposisjon, hvilket gjør at løsningen ikke har noen faste treffpunkter. Det er dette som gjør løsningen unik. Testing av prototypen bekreftet at blinde og svaksynte kan bruke den på lik linje med seende. Dette er viktig for oss, da prototypen skal være ment for alle. Vi har utelatt noen av de mer avanserte funksjonene til NSBs automat, men det er rom for å implementere all eksisterende funksjonalitet. Noe som har vært viktig er Blindeforbundets støtte, deres entusiasme har oppmuntret oss til å gjøre Swipe8 så bra som mulig. Det faktum at vi har muliggjort bruk av berøringsskjerm for blinde og svaksynte beviser at prosjektet har vært vellykket. Swipe-løsningen begrenser seg ikke bare til billettautomater. Vi ser også for oss andre bruksområder. Dette kan være alle enheter som benytter berøringsskjerm. Eksempelvis: - Datamaskiner - Mobiltelefoner - MP3-spillere - GPS 123

13.1.1 Mulige forbedringer Swipe løser mange problemstillinger knyttet til berøringsskjermer og svaksynte, men det er allikevel forbedringspotensiale. Zoom er en funksjon som vi lenge vurderte, men på grunn av tidsbegrensninger ble det ikke implementert. Dette kunne blitt gjort på samme måte som på iphone. Der brukes en tofingerteknikk for å zoome inn og ut. Man drar fingerene fra og mot hverandre for å bruke funksjonen. Figur 13.1: Bildet til venstre: før zoom. Bildet til høyre: etter zoom Hentet fra Wikimedia Commons Talesyntesen som ble brukt i prototypen holdt en høy standard, men vi skulle gjerne sett for oss å bruke ekte stemmer. Vi tror dette hadde bidratt til en bedre brukeropplevelse. For å få den kvaliteten vi ønsker, krever det imidlertid avansert utstyr som vi ikke har hatt tilgang til. Selv om vi kunne brukt oss selv stemmeskuespillere, hadde det vært best å leie inn en profesjonell skuespiller. Dette hadde imidlertid kostet penger. Under testingen fikk vi et innspill angående brukertilpasning. Ideen er at brukeren kan velge kontrast/fargekombinasjoner i forkant av bestillingsprosessen. I Swipe8 hadde det innebært å dra i forskjellige retninger for å se kombinasjonene. Ulempen med dette er at det medfører flere valg, og dermed kan bidra til forvirring. Videre kan også kildekoden til swipe forbedres. Etter at vi fikk funksjonene til å fungere, ble det ikke satt fokus på videre optimalisering. 13.1.2 Brukerdokumentasjon Her vil det komme en detaljert beskrivelse av hvordan man skal gå frem for å bruke Swipe8. Alle steg i prosessen vil bli dokumentert med et skjermbilde og forklarende tekst. Følgende scenario blir beskrevet: 1. Høre instruksjonene 2. Norsk språk 3. Enkelbillett 4. 1 billett 5. Voksen billett 6. Bokstavgruppe JKLM 124

7. Bokstav M 8. Bokstavgruppe MO 9. Moss 10. Høre oppsummering 11. Betale med bankkort Før hvert skjermbilde vil det bli lest opp en instruksjon som beskriver hvilket valg som skal utføres. Man vil alltid kunne se hvor langt man har kommet i prosessen ved å bruke stien øverst på skjermen. Steg 1: Instruksjoner Figur 13.2: Swipe8 instruksjonsskjerm Brukeren får her opplest grundige instruksjoner om hvordan automaten skal betjenes. For å gå videre drar brukeren fingeren til høyre. 125

Steg 2: Velg språk Figur 13.3: Swipe8 språkvalg For å velge norsk språk drar man fingeren oppover. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. Steg 3: Velg type billett Figur 13.4: Swipe8 billettvalg For å velge enkelbillett drar man fingeren oppover. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. 126

Steg 4: Velg antall billetter Figur 13.5: Swipe8 antall billetter For å velge 1 billett drar man fingeren oppover. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. Hvis man ønsker flere billetter enn de som er vist på skjermen kan man dra skrått opp til venstre for flere valgmuligheter. Steg 5: Velg type reisende Figur 13.6: Swipe8 type reisende For å velge voksenbillett drar man fingeren skrått opp til høyre. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. 127

Steg 6: Velg bokstavgruppe Figur 13.7: Swipe8 destinasjonsvalg: Velg bokstavgruppe Dette er det første steget når man skal velge destinasjon. Det første man skal gjøre er å velge den bokstavgruppen som inneholder forbokstaven til ønsket destinasjon. Vi skal til Moss og må dermed velge gruppen JKLM. For å velge JKLM drar man fingeren skrått ned til venstre. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. Steg 7: Velg forbokstav til ønsket destinasjon Figur 13.8: Swipe8 destinasjonsvalg: Velg forbokstav til destinasjon 128

Her velges forbokstaven til ønsket destinasjon. For å velge M drar man fingeren ned. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. Steg 8: Velg de to første bokstavene i ønsket destinasjon Figur 13.9: Swipe8 destinasjonsvalg: Velg to første bokstaver i destinasjon Her velger man de to første bokstavene i ønsket destinasjon. Valgmulighetene viser kun kombinasjoner der det er tilgjengelige destinasjoner. Vi skal til Moss og velger derfor MO. For å velge MO drar man fingeren ned. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. 129

Steg 9: Velg stasjon Figur 13.10: Swipe8 destinasjonsvalg: Velg stasjon For å velge Moss drar man fingeren skrått ned til venstre. Valget vil da bli lest opp og markert ved at pilen skifter farge. For å bekrefte valget og gå videre drar man fingeren til høyre. Steg 10: Oppsummering Figur 13.11: Swipe8 oppsummering Her får brukeren valget om å høre en oppsummering av valgene som er blitt gjort eller gå videre til betaling. Valgene som har blitt utført står også skrevet i midten av skjermbildet slik at personer med syn ikke trenger å høre lydfilen. Man får her presentert hvor mye billetten vil koste. 130

For å høre oppsummeringen drar man fingeren oppover. For å gå videre til betaling drar man fingeren til høyre. Steg 11: Betaling Figur 13.12: Swipe8 betalingsvalg For å betale med bankkort drar man fingeren oppover. For å bekrefte kjøpet drar man fingeren til høyre. Man har nå fullført bestillingsprosessen. 13.2 Etterord Nå som vi er ferdige med prosjektet sitter vi igjen med mange gode minner og erfaringer. På grunn av vår profesjonelle tilnærming til prosjektet føler vi at vi har fått et innblikk i hvordan det vil være i arbeidslivet. Gruppen har fungert veldig bra, og alle har vært flinke til å ta sin del av arbeidet og opprettholdt arbeidsrutinene. Vi føler vi har fullført de tekniske sidene ved prosjektet tilfredsstillende, men det er selvfølgelig alltid noe som kunne vært gjort annerledes Et område som vi kunne utforsket mer var lyd. Dette området var nevnt i oppgaveteksten, og selv om vi har brukt lyd til en viss grad kunne vi ha gått mer i dybden rundt dette. Det er mange måter man kan bruke lyd på. Hadde tiden strukket til, ville vi ha gått nærmere inn på dette. Det samme gjelder arbeidet rundt zoom som ville vært et godt verktøy for svaksynte. På grunn av vår forsinkede kontakt med Blindeforbundet ble det mindre brukertesting enn hva vi hadde håpet på. Hadde samarbeidet startet tidligere kunne vi ha planlagt flere og større tester som kunne inkludert flere prototyper. 131

Gjennom vår informasjonsinnhenting, utvikling og kontakt med brukergruppen, har vi opparbeidet oss mange nye og nyttige kunnskaper som vi håper å få bruk for senere. Vi håper vi har kommet frem til en løsning som vil kunne brukes i fremtidig forskning, og som kan bidra til å minske det digitale skillet som finnes i dagens samfunn. 132

Kapittel 14 Kilder 133

134

Activium. (u.d.). Hentet fra http://www.activium.no Activium. (u.d.). Voxit Budgie Pro. Hentet fra http://activium.no/talesyntese/voxit-budgie-pronorges-mest-komplette-talesyntese.html Adobe. (u.d.). Adobe Flash CS4. Hentet fra http://www.adobe.com/products/flash/ Apple. (u.d.). iphone: Hvordan bruke Voice-Over. Hentet fra http://www.apple.com/no/iphone/howto/index.html#tilgjengelighet.bruke-voiceover Audacity. (u.d.). Hentet fra http://audacity.sourceforge.net/ Barber, G. (2009, Mars 25). 16 Design tools for prototyping. Hentet fra http://articles.sitepoint.com/article/tools-prototyping-wireframing Bendixen, K. (2008, Mars 3). Design for All is about learing from users. Hentet fra http://www.designforalleurope.org/design-for-all/articles/article_archive/design-for-all-is-about- Learning-from-Users/ Blindeforbundet. (u.d.). Hentet fra http://www.blindeforbundet.no Blindeforbundet. (2008, Juli 1). Automat Marerittet. Hentet fra https://www.blindeforbundet.no/internett/nyheter/automat-mareritt Blindeforbundet. (u.d.). Brosjyre for øyesykdommer. Hentet fra https://www.blindeforbundet.no/nbf/publikasjoner/brosjyrer/oyesykdommer/samlehefte.pdf Blindeforbundet. (2008, August 21). Seier i NSB-saken. Hentet fra https://www.blindeforbundet.no/internett/nyheter/seier-i-nsb-saken Blindeforbundet. (u.d.) Krav til minibanker og billettautomater. Hentet fra https://www.blindeforbundet.no/internett/tilrettelegging-i-samfunnet/minibank-nettbankbillettautomater Brownlee, J. (2009, April 3). Android perfects touchscreen dialing for the blind. Hentet fra http://www.geek.com/articles/mobile/google-android-perfects-touchscreen-dialing-for-the-blind- 2009043/ Cardoso, J. (2009, Januar 14). Blind people cant use touchscreens. Hentet fra http://jorgecardoso.eu/blog/index.php?/archives/138-blind-people-cant-use-touch-screens.html Carew, S. (2009, Januar 8). Touchscreen gadgets alienate blind. Hentet fra http://www.reuters.com/article/idustre5080t320090109 Christensen, B. H. (2003). Effektiv anvendelse av IKT; Elektronisk forretningsdrift. Colvin, K. (2008, Oktober 5). My favorite prototyping tools. Hentet fra http://design-forusers.com/design/my-favorite-prototyping-tools/ Datakjeden. (u.d.). Datakjeden. Hentet fra www.datakjeden.no Dropbox. (u.d.). Hentet fra http://www.dropbox.com 135

Edupics. (u.d.). Icon for accessibility for the blind. Hentet fra http://www.edupics.com/en-coloringpictures-pages-photo-icon-for-accessibility-for-the-blind-i9836.html E-Speaking. (u.d.). Hentet fra http://www.e-speaking.com/ Eyes-Free Project. (u.d.). Hentet fra http://eyes-free.blogspot.com Google-OpenSource. (2009, April 1). Announcing Eyes-Free Shell For Android. Hentet fra http://google-opensource.blogspot.com/2009/04/announcing-eyes-free-shell-for-android.html GUI Prototyping Tools. (u.d.). Hentet fra http://c2.com/cgi/wiki?guiprototypingtools GUUUI. (u.d.). How to use Visio for rapid prototyping. Hentet fra http://www.guuui.com/issues/02_03_02.php Hansen, L. D. (2010, Januar 29). Tast deg frem til tapt bagasje. Hentet fra http://www.aftenposten.no/reise/article3491408.ece Harrelson, D. (u.d.). Rapid Prototyping Tools. Hentet fra http://www.adaptivepath.com/blog/2009/03/24/rapid-prototyping-tools/ Høgskolen i Oslo. (u.d.). Hentet fra http://www.hio.no Hot Virtual Keyboard. (u.d.). Hentet fra http://hot-virtual-keyboard.com/ Irontech AS. (u.d.). Hentet fra http://www.irontech.no Karlsen, J. K., & Langseth, M. Hvor skal jeg sitte? Litchfield, S. (2009, September 17). Nokia Braille Reader. Hentet fra http://www.allaboutsymbian.com/news/item/10481_nokia_braille_reader-no_really.php Mathisen, I. (2007, Mars 28). Nå snakker minibanken. Hentet fra http://pub.tv2.no/nettavisen/ioslo/article949310.ece Microsoft. (u.d.). PowerPoint. Hentet fra http://office.microsoft.com/nbno/powerpoint/default.aspx NCH Software. (u.d.). WavePad Sound Editor Software. Hentet fra http://www.nch.com.au/wavepad/index.html Nordea. (u.d.). Minibank for blinde. Hentet fra https://www.kortaccept.se/1/85.html Omniglot. (u.d.). Hentet fra http://www.omniglot.com/writing/braille.htm Ottestad, G. (2005). Forsknings- og kompetansenettverk for IT i utdanning. Hentet fra http://www.ituarkiv.no/filearchive/nr4_digitale_skiller.pdf Pan, J. (1999, Vår). Software Testing. Hentet fra http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/ RNIB. (u.d.). Hentet fra http://www.rnib.org.uk/pages/home.aspx Rundmo, L. (2009, April 2). Billettautomater ikke for alle. Hentet fra http://forbrukerportalen.no/artikler/2009/billettautomater_ikke_for_alle 136

Sandnes, F. (2010, Mai). Effects of common keyboard layouts on physical effort: Implications for kiosks and Internet banking. Hentet fra http://www.iu.hio.no/~frodes/unitech10/022- Sandnes/index.html Schuh, P. (2004). Integrating agile development in the real world. USA: Charles River Media. xviii. Snook. (u.d.). Colour contrast check. Hentet fra http://www.snook.ca/technical/colour_contrast/colour.html Stortinget. (2008). Diskriminerings- og tilgjengelighetsloven. Utdanningsdirektoratet. (2007). Utstyrs- og driftssituasjonen i grunnopplæringen 2006-2007. Hentet fra Utdanningsdirektoratet: http://www.udir.no/upload/satsningsomraader/digital_kompetanse/utstyrsog_driftssituasjonen_i_grunnopplaringen_06-07.pdf VG, & Haugen, I. A. (2008, Mai 6). Blindeforbundet raser mot NSB. Hentet fra http://www.vg.no/helse/artikkel.php?artid=519573 Watson, D. (u.d.). Playing MP3 files during a slideshow (PowerPoint). Hentet fra http://www.cadtutor.net/dd/power/mp3/mp3.html Wikipedia. (u.d.). Android. Hentet fra http://no.wikipedia.org/wiki/android Wikipedia. (u.d.). Android (Engelsk). Hentet fra http://en.wikipedia.org/wiki/android_(operating_system) Wikipedia. (u.d.). extreme Programming. Hentet fra http://no.wikipedia.org/wiki/extreme_programming Wikipedia. (u.d.). Handwriting recognition. Hentet fra http://en.wikipedia.org/wiki/handwriting_recognition Wikipedia. (u.d.). iphone. Hentet fra http://no.wikipedia.org/wiki/iphone Wikipedia. (u.d.). Optical character recongition. Hentet fra http://en.wikipedia.org/wiki/optical_character_recognition Wikipedia. (u.d.). Pen computing. Hentet fra http://en.wikipedia.org/wiki/pen_computing Wikipedia. (u.d.). Scrum. Hentet fra http://no.wikipedia.org/wiki/scrum Wikipedia. (u.d.). Tablet PC. Hentet fra http://en.wikipedia.org/wiki/tablet_pc Wikipedia. (u.d.). Testing. Hentet fra http://no.wikipedia.org/wiki/testing Wikipedia. (u.d.). Universell utforming. Hentet fra http://no.wikipedia.org/wiki/universell_utforming Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pair_programming_1.jpg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:brainstorming.gif 137

Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pictograms-nps-accessibility-wheelchair-accessible.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pictograms-nps-accessibilityassistive_listening_systems.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pictograms-nps-accessibility-low_vision_access.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pictograms-nps-accommodations-womens_restroom.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:pictograms-nps-accommodations-mens-restroom.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:question_mark_alternate.svg Wikipedia. (u.d.). Wikimedia Commons. Hentet fra http://commons.wikimedia.org/wiki/file:icon_tools.svg Wilson, R. (2008, November 7). 16 user interface prototyping tools. Hentet fra http://www.dexodesign.com/2008/11/07/review-16-user-interface-prototyping-tools/ WiseGEEK. (u.d.). What is an ABC-style keyboard. Hentet fra http://www.wisegeek.com/what-is-anabc-style-keyboard.htm Youtube. (u.d.). Android: Eyes-Free Project. Hentet fra http://www.youtube.com/watch?v=dozybep8ays Youtube. (u.d.). Android: Eyes-Free Project. Hentet fra http://www.youtube.com/watch?v=xsju61voqw Youtube. (u.d.). Android: Eyes-Free Project (Youtube-kanal). Hentet fra http://www.youtube.com/user/eyesfreeandroid Youtube. (u.d.). EeeTop. Hentet fra http://www.youtube.com/watch?v=yltgqxvppwy Youtube. (u.d.). Eyes-Free adaptive keypad. Hentet fra http://www.youtube.com/watch?v=amansa8jtam&feature=related 138

Kapittel 15 Appendiks 139

140

15.1 Lavnivå prototype skisser 15.1.1 Split4 Figur 15.1:Split4 - Språkvalg 141

Figur 15.2: Split4 Valg av type billett Figur 15.3: Split4 - Oversikt over hvor tastatur, destinasjon er plassert, samt valgt destinasjon og neste knapp Figur 15.4: Split4 - Antall reisende 142

Figur 15.5: Split4 - Valg av dato og avganger 143

15.1.2 Numb3ers Figur 15.7: Numb3rs - Automat med stasjonsnavn ved siden av Figur 15.8: Numb3rs - Valg av språk 144

Figur 15.9: Numb3rs - Valg av område Figur 15.10: Numb3rs - Valg av bane 145

Figur 15.11: Numb3rs - Valg av stasjon Figur 15.12: Numb3rs - Valg av type billett 146

Figur 15.13: Numb3rs - Type resiende 147

15.1.3 Tap4 Figur 15.14: Tap4 - Type billett 148

Figur 15.15: Tap4 - Type reisende 149

Figur 15.16: Tap4 - Valg av område og bokstav 150

Figur 15.17: Tap4 - Valg av stasjon 151

15.1.4 Scrollslide Figur 15.18: Scrollslide - Velkommen Figur 15.19: Scrollslide - Type billett 152

Figur 15.20: Scrollslide - Skriv inn din destinasjon (håndskriftsgjenkjenning) F Figur 15.21: Scrollslide - Velg destinasjon etter valgt bokstav 153

F Figur 15.22: Scrollslide - Velg forbokstaven for din destinasjon 154

15.1.5 Swipe4 F Figur 15.23: Swipe4 - Velg språk F Figur 15.24: Swipe4 - Velg type billett 155

F Figur 15.25: Swipe4 - Velg område F Figur 15.26: Swipe4 - Velg bokstavgruppe 156

F Figur 15.27: Swipe4 - Velg destinasjon Figur 15.28: Swipe4 - Velg dato og tid 157

Figur 15.29: Swipe4 - Velg type reisende 158

15.1.6 Swipe8 Figur 15.30: Swipe8 - Velg språk Figur 15.31: Swipe8 - Velg type billett 159

Figur 15.32: Swipe8 - Velg type billett Figur 15.33: Swipe8 - Velg antall reisende 160

Figur 15.34: Swipe8 - Velg type reisende Figur 15.35: Swipe8 - Velg bokstavgruppe 161

Figur 15.36: Swipe8 - Velg bokstav 162

15.1.7 Stegis Stegern Figur 15.37: Stegis Stegern - Velg bokstav Figur 15.38: Stegis Stegern - Velg de to første bokstaver 163

Figur 15.39: Stegis Stegern - Velg de tre første bokstavene Figur 15.40: Stegis Stegern - Velg de fire første bokstavene 164

Figur 15.41: Stegis Stegern - Velg stasjon 165

15.2 Rapporter av automater 15.2.1 NSB billettautomat Type automat: NSB billettautomat Testpersoner: - Anders Johansen - Edvin Sulic - Eirik Rud Iversen - Eirik Vesterhus - Tek Beng Tan Dato: 07.01.2010 Sted: Lysaker Stasjon Bilde: Figur 15.42: NSBs billettautomat Beskrivelse: Automaten vi testet er plassert på Lysaker stasjon. Den befinner seg i et eget rom sammen med andre automater og fasiliteter. Dette gjør at NSBs kunder kan bruke den i fredelige omgivelser da automaten er skjermet mot værforhold og støy. Automaten har følgende funksjonalitet: Valg - Enkelbillett - Periodebillett - Tur/Retur - Forhåndsbestilt Enkelbillett - Eventuelt velge fra-stasjon - Velge ankomststasjon - Bekrefte valg, tidspunkt, antall og billettype - Betaling Periodebillett - Eventuelt velge-fra-stasjon - Velge ankomststasjon - Bekrefte valg, tidspunkt, startdato, varighet (30 dager f. eks), Type reisende - Taste inn kundenummer 166

Tur/Retur - Eventuelt velge fra-stasjon - Velge ankomststasjon - Bekrefte valg, tidspunkt, antall og billettype - Tidspunkt for returreise - Betaling Forhåndsbestilt billett - Tast inn referansenummer og telefonnummer - Betaling Analyse: Positivt: - Plassering av selve automaten - Høyde på skjermen - Klar skjerm - Skjermens følsomhet - Billettlukens plassering - Informasjonsknapp - Engelsk og Norsk språk - Navigasjonssti - Fargevalg på knapper - Mange muligheter - Løsning på valg av stasjon Negativt: - Diskriminerer brukergrupper Blinde, svaksynte, kortvokste, rullestolbrukere - Berøringsskjerm gir ikke tilbakemelding på valg Kunne blitt gjort i form av lyd? - Høyde på kortterminal og myntmottak - Dårlig kontrast - Uoversiktlig For mange valg. - For dårlig informasjon i betalingsøyeblikk - Begrenset og uoversiktlig hjelpeinformasjon - Varierende betalingsmuligheter på automater - Spesifiser billett Konklusjon: Denne automaten har et stort forbedringspotensiale. Det som er mest merkbart er rotete grensesnitt, høyde på betalingsterminal og mangel av lydgrensesnitt. 167

15.2.2 Flytoget billettautomat Type automat: Flytoget billettautomat Testpersoner: - Anders Johansen - Edvin Sulic - Eirik Rud Iversen - Eirik Vesterhus - Tek Beng Tan Dato: 07.01.2010 Sted: Lysaker Stasjon Bilde: Figur 15.43: Flytoget billettautomat Beskrivelse: Automaten vi testet er plassert på Lysaker stasjon. Den befinner seg i et eget rom sammen med andre automater og fasiliteter. Dette gjør at Flytogets kunder kan bruke den i fredelige omgivelser da automaten er skjermet mot værforhold og støy. Automaten har følgende funksjonalitet Valg: - Enkelbillett Enkelbillett - Voksen - Honnør - Barn - Andre billettyper - Antall Analyse: Positivt: - Meny - Kontrast - Instruksjoner 168

- Betalingsmuligheter (Mynter, Sedler og kort) - Skjermens følsomhet - Bra informasjon i betalingsøyeblikk Negativt: - Informasjonsknapp mangler - Diskriminerer brukergrupper - Uskarpt bilde på skjermen - Skjerm gir ikke tilbakemelding - Høyde på kortterminal og myntinntak - Vanskelig å finne hvor billetten kommer ut Konklusjon: Enkel automat som fungerer bra til det formålet den er laget for. Noe forbedringspotensiale spesielt i forhold til fysisk utforming og mangel av lydgrensesnitt. 15.2.3 Flytoget billettløst kortautomat Type automat: Flytoget sveipautomat Testpersoner: - Anders Johansen - Edvin Sulic - Eirik Rud Iversen - Eirik Vesterhus - Tek Beng Tan Dato: 07.01.2010 Sted: Lysaker Stasjon Bilde: Figur 15.44: Flytoget billettautomat Beskrivelse: Automaten vi testet er plassert på Lysaker stasjon. Den befinner seg i et eget rom sammen med andre automater og fasiliteter. Dette gjør at flytogets kunder kan bruke den i fredelige omgivelser da automaten er skjermet mot værforhold og støy. Analyse: Automaten er meget enkel og tilbyr bare en tjeneste. Automaten fungerer ved at man drar kredittkortet gjennom en kortleser som registrerer kortet. Når man kommer til Gardermoen drar man kortet igjen og blir da belastet for en billett. Instruksene er på engelsk og norsk. Konklusjon: 169

Enkel automat som bare tilbyr en tjeneste. Bra høyde, men mangler lydgrensesnitt. 15.2.4 Saga kino billettautomat Type automat: Billettavhentingsautomat Testpersoner: - Edvin Sulic - Eirik Vesterhus - Tek Beng Tan Dato: 12.01.2010 Sted: Saga kino Bilde: Figur 15.45: Saga kino billettautomat Beskrivelse: Automat for å hente betalte kinobilletter som er kjøpt over nett. Automaten befinner seg inne på Saga kino. Valg - Hente billett Hente - Taste inn referansenummer Analyse: Positivt: - Enkel meny - Kontrast - Bra skjerm og følsomhet Negativ: - Lite informasjon - Diskriminerer brukergrupper - Høyden på automaten - Vinkling av skjermen Konklusjon: Automaten fungerer bra til formålet den er laget for. Negative ting er høyden på automaten, informasjon og mangelen på lydgrensesnitt. 170

15.2.5 Ruter billettautomat Type automat: Ruter# T-bane elektronisk billettautomat (Flexus) Testpersoner: - Anders Johansen - Edvin Sulic Dato: 18.01.2010 Sted: Nationalteateret Stasjon Bilde: Figur 15.46: Ruter billettautomat Beskrivelse: Automaten vi testet er plassert på Nationalteateret stasjon. Den befinner seg rett ved siden av perrongen. Automaten har følgende funksjonalitet: Valg - Enkelbillett - Periodebillett Enkelbillett - Kun velge Oslo, må også velge antall dager man vil ha billetten. (1.dag, 7.dager, 30. dager) - Endre kategori, dette vil si at man velger hvilken type billett man trenger (barn, student, honnør, voksen) - Velge betalingsmåte (kontanter, kort) - Betaling Periodebillett - Kun velge Oslo, men man må også velge antall dager man vil ha billetten. (1 dag, 7 dager, 30 dager) - Endre kategori, dette vil si at man velger hvilken type billett man trenger (barn, student, honnør, voksen) - Velge betalingsmåte (kontanter, kort) - Betaling Disse to billettmulighetene er under samme menyen. Analyse: Positivt: - Kjapt og enkelt 171

- Høyde på skjermen - Klar skjerm - Skjermens følsomhet - Elektronisk Billett - Engelsk og Norsk språk Negativt: - Diskriminerer brukergrupper Blinde, svaksynte, kortvokste, rullestolbrukere - Berøringsskjerm gir ikke tilbakemelding på valg Kunne blitt gjort i form av lyd? - Høyde på kortterminal og myntmottak (Bedre høyde enn NSBs billettautomater) - Dårlig kontrast - Ingen informasjonsknapp - Få billettmuligheter (burde vært mulig å velge f. eks Akershus som reisemål, ikke bare T bane, men også busser og tog. Dette er ikke mulig på denne elektroniske billettautomaten) - Valgknappene har dårlige farger. Knappene er sorte. Konklusjon: Denne automaten har et stort forbedringspotensiale. Det som er mest merkbart er rotete grensesnitt, høyde på betalingsterminal og mangel av lydgrensesnitt. Samme som på NSBs billettautomater. 15.2.6 Nordea minibankautomat Type automat: Nordea minibank Testpersoner: - Edvin Sulic - Eirik Vesterhus - Tek Beng Tan Dato: 12.01.2010 Sted: Nationaltheatret Stasjon Bilde: Figur 15.47: Nordea minibank Beskrivelse: Minibanken plassert inne på Nationaltheatret stasjon. Det som er spesielt med denne minibanken er at den har muligheten for å koble til et headset. Da vil man få instruksjoner og tilbakemelding i 172

form av lyd. Vi går ikke nærmere inn på mulighetene til minibanken. Den har alle de normale funksjonene man forventer. Automaten har følgende funksjonalitet: Valg - Uttak - Uttak annen valuta Uttak - Taster inn beløp man ønsker å ta ut Uttak annen valuta - Velger først ønsket valuta - Deretter taster man inn ønsket beløp Analyse: Positivt: - Mulighet for tilkobling av hodetelefoner og instrukser i form av lyd - Uthevede knapper med tegn og prikk på fem tallet. - Enkel meny - Kontrast Negativt: - Søppelkasse foran automaten Forhindrer tilgjenglighet og synsvinkel - Vanskelig å finne innsetting av kort, kvitteringsprinter og hvor pengene kommer ut Konklusjon: Automaten har lydgrensesnitt som gjør at man får instruksjoner i form av lyd. I tillegg er det taktile tegn på tastene. Det burde kanskje vært indikatorer på hvor kvittering kommer ut, hvor man skal sette inn kortet og hvor pengene kommer ut slik at man kan føle seg frem. 15.3 Testrapporter 15.3.1 Qwerty- vs ABC-tastatur Prototype: Qwerty vs ABC-tastatur Sted: Høgskolen i Oslo IU avdelingen Dato: 26.01.2010 Antall test: 15 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic, Eirik Rud Iversen, Eirik Vesterhus 173

Resultater av QWERTY med syn: Resultater av QWERTY i blinde: Test ID Tid sek Feil Test ID Tid sek Feil 1 2,3 0 1 36,7 0 2 2,3 0 2 47,7 0 3 2,2 0 3 16,9 0 4 2,6 0 4 27,8 3 5 2 0 5 28,3 1 6 3,7 0 6 25,2 0 7 2,2 0 7 21,3 2 8 1,5 1 8 16,8 0 9 1,8 0 9 50,7 1 10 4,3 0 10 76 2 11 3 0 11 24 0 12 3,8 0 12 50,6 0 13 3,5 0 13 87 0 14 3 0 14 118 1 15 3 0 15 57 2 Resultater av ABC med syn: Resultater av ABC i blinde: Test ID Tid sek Feil Test ID Tid sek Feil 1 5,5 0 1 35,3 0 2 2,2 0 2 39,2 0 3 3,6 0 3 34,6 1 4 3,7 0 4 39,8 1 5 4,4 0 5 134 2 6 2,9 1 6 31,5 1 7 3,5 1 7 29,5 0 8 2,4 0 8 45 1 9 2 0 9 24 1 10 4,5 0 10 22,7 0 11 2,4 0 11 104 1 12 3,4 0 12 77 2 13 5 0 13 54 0 14 3 0 14 28,8 0 15 6 0 15 140 0 174

Diagram QWERTY 175

Diagram [Blinde] 15.3.2 Stegis Stegern Prototype: Stegis Stegern Sted: Høgskolen i Oslo IU avdelingen Dato: 02.03.2010 Antall test: 15 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic 176

Resultater av vanlig: Resultater av i blinde: Test ID Tid sek Feil Test ID Tid sek Feil 1 7 0 1 119 1 2 9,7 0 2 223 3 3 7,2 0 3 77 0 4 20 0 4 144 1 5 12 0 5 393 7 6 10 0 6 93 1 7 16,9 0 7 358 4 8 10,7 0 8 124 2 9 4 0 9 163 2 10 8,1 0 10 215 2 11 23,3 0 11 209 2 12 8,7 0 12 136 2 13 4,2 0 13 75 1 14 6.9 0 14 119 1 15 5,9 0 15 67 0 Tilbakemeldinger Positiv: Mange mente løsningen var brukervennlig. Lett å forholde seg til 4 inndelinger av skjermen. Veldig lett å bruke når brukerne fikk lov til å se. Negativ: Noen mente at det burde vært en tilbake/angre knapp. Når du har valgt S for ikke brukeren vite at S er valgt. Men sier heller videre hvilke bokstaver man kan velge. Brukerne blir for utålmodig og ville gjerne at dette skulle gå fortere i blinde. Det burde kanskje være en instruksjon der det forklarer at skjermen er delt inn i fire deler. Diagram [Vanlig] 177

Diagram [Blinde] 15.3.3 Swipe8 15.3.3.1 Uformell Prototype: Swipe8 Sted: Høgskolen i Oslo IU avdelingen Dato: 16.04.2010 Antall test: 15 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic, Eirik Rud Iversen, Eirik Vesterhus 178

Resultater[blinde]: Test ID Tid sek Swipes 1 153 34 2 210 46 3 173 34 4 132 30 5 141 39 6 135 36 7 168 36 8 209 38 9 131 31 10 194 47 11 166 37 12 147 34 13 137 29 14 350 58 15 178 40 Tilbakemeldinger Positivt: - Genialt - Veldig bra og enkelt - Kjempekult Negativt: - Dårlig å ha samme scenario i både blinde og når man ser - Forvirrende - Fikk inntrykk av at høyre og venstre var valgmuligheter - Litt forvirrende i starten, ble bedre etter hvert 179

Diagram [blinde] 15.3.3.2 Formell 1 Prototype: Swipe8 Sted: Blindeforbundet Dato: 19.04.2010 Antall test: 5 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic, Eirik Rud Iversen, Eirik Vesterhus Resultater[blinde]: Test ID Tid sek Swipes 1 165 34 2 690 46 3 234 31 4 200 53 5 196 42 Tilbakemeldinger Positiv: - Bra - Trodde ikke det var mulig å lage noe så enkelt men likevel så komplekst - Anbefalte å ta patent Negativ: - Forvirring med tilbake-funksjonen - Mannlig stemme - Størrelsen på skjermen - Bytte plass på ABC osv (Forskjellig preferanser gjennom hele testpanelet) - Bedre kontrast, forskjellige bakgrunner 180

Diagram [blinde] 15.3.3.3 Formell 2 Prototype: Swipe8 Sted: Hovedkontoret til Blindeforbundet - Sporveisgt.10, Majorstua Dato: 28.04.2010 Antall test: 11 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic, Eirik Rud Iversen, Eirik Vesterhus Resultater Test ID Tid sek Swipes 1 196 30 2 118 21 3 105 21 4 227 24 5 170 23 6 231 25 7 258 36 8 385 46 9 125 21 10 173 52 11 174 24 Tilbakemeldinger Positiv: - Raskere når man blir kjent med automaten - Veldig gode kontraster - Positivt til automaten - Bra kontrast - Tydelig - Godebokstaver - God løsning - Treningssak - Bra kombinasjon mellom syn og tall 181

- Meget bra skjermbilde - Godt med oppsummering - Genialt - Minste felles multiplum - Kjempetøff Negativ: - Tungvint ved stasjonsvalg(mange valg) - (testperson har lite synsfelt) Vanskelig å se hele skjermen - Vil gjerne ha litt mørkere blåfarge - Gjerne bedre kontrast - Stasjonsvalg litt problematisk - Hvis man er stressa så er det lettere å bomme - Mer logisk å bruke fingeren rundt for å utforske menyvalg - Bakgrunn for grå - Bedre skille mellom M og N Annet: - IDE Bankkort med chip som automaten tilpasser seg til (f. eks bakgrunn, skriftstørrelse, osv) - Kanskje ha en guide på nett, der man kan lære seg automaten før man går ut og bruker den - Eget valg for blinde/svaksynte og vanlige - Etter man har bestilt billett, kunne kanskje automaten si ifra hvilket spor og tidspunkt hvor toget går ifra.(dette hadde hjulpet for å få ned letetiden) - Automaten skulle gjerne vært på selve toget (de store) Diagram 182

15.3.4 Numb3rs Prototype: Numb3rs Sted: Høgskolen i Oslo IU avdelingen Dato: 08.03.2010 Antall test: 5 Ansvarlig: Tek Beng Tan, Anders Johansen, Edvin Sulic, Eirik Rud Iversen, Eirik Vesterhus Resultater av vanlig: Resultater av i blinde: Test ID Tid sek Feil Test ID Tid sek Feil 1 14,2 0 1 85 0 2 25 0 2 104 1 3 17,7 0 3 50 1 4 27,7 1 4 130 1 5 32,2 0 5 122 1 Tilbakemeldinger Positiv: Funker bra for de som er vant til å bruke tall tastatur på minibank og betaling med kort Negativ: Tomrom på begge sider av tallet 9 bidrar til forvirring Diagram [Vanlig] 183

Diagram [Blinde] 184

15.4 Swipe8 fargekombinasjoner Prototype: Swipe8_Olav_2nd_edition Type Bakgrunn Tekst & linje Pil Pil & tekst hevet RGB R:149 G:203 B:233 R:128 G:0 B:32 R:2 G:71 B:105 R:128 G:0 B:32 HEX# 95CBE9 800020 024769 800020 Comment/Colo r sample Figur 15.48: skjermbilde av Swipe8 185