INF5261 Development of mobile information systems and services. Sluttrapport. Espen Stokkerud

Transkript

1 INF5261 Development of mobile information systems and services Sluttrapport Espen Stokkerud Mari Breivik Emil Hansen Kristian Oddtrøen Universitetet i Oslo

2 Innhold 1. Introduksjon 1.1 Ide 1.2 Problemstilling Forskningsspørsmål 2. Teori 2.1 Personvern 2.2 Universell design 2.3 Brukeropplevelse 2.4 Sosial navigasjon 3. Case 3.1 Eksisterende applikasjoner Yelp TripAdvisor Google Maps CityMaps2Go 3.2 Målgruppe 3.3 Fokusgruppe 3.4 Overordnet arkitektur 4. Metode 4.1 Brukertesting 5. Utvikling og funn 5.1 Low fidelity prototype Krav til mockup Design av mockup 5.2 Funn Brukertest og observasjon Del 1 introduksjon til applikasjonen Del 2 observasjon av applikasjonen Del 3 Feedback Konklusjon fra brukertest 5.3 Spørreundersøkelse 5.4 High Fidelity prototype 5.5 Faglige valg 6. Diskusjon 7. Konklusjon 7.1 Forskningsspørsmål 7.2 Svakheter med oppgaven 7.3 Videre arbeid 8. Referanser 9. Vedlegg Vedlegg 1 Mockup Vedlegg 2 Intervjuspørsmål Kvalitativ dybdeintervju for brukertest av mockup Del 1 Intro Del 2.1 Eksplorering Del 2.2 Scenario Del 4 Etter test intervju Vedlegg 3 Spørreundersøkelse Vedlegg 3.1 Spørsmål Vedlegg 3.2 Respons Vedlegg 4 High fidelity Prototype Vedlegg 5 Ulike former for fargeblindhet 2 av 36

3 1. Introduksjon Prosjektet er etablert som en del av faget INF5261. Denne rapporten tar for seg forskning og utviklingsprosess for applikasjonen JourneySwipe. Prosessen med å utforske nye steder kan være kompleks og for noen stressende. I mange tilfeller kreves det mye planlegging i forkant av reisen. For å oppleve mest mulig på et nytt sted må man ofte innom flere aktører som tilbyr ulik informasjon om reisemålet. Gjennom applikasjonen JourneySwipe ønsker vi å forenkle prosessen, ved å samle denne informasjonen i én applikasjon. JourneySwipe er en applikasjon hvor man kan velge mellom ulike aktiviteter basert på 1 lokasjonen man befinner seg på. Applikasjonen baserer seg på swipe trend hvor man får 2 opp et utvalg av aktiviteter og swiper enten til høyre eller venstre for å legge til eller velge bort en aktivitet. Swiper man til høyre vil attraksjonen legges til i en liste, man vil da få en plan over aktiviteter man ønsker å besøke, samt avstand og rute mellom de ulike attraksjonene. Etterhvert som man besøker de ulike stedene vil de forsvinne fra listen, og man kan gå til neste. Det vil være mulig å filtrere attraksjonene basert på personlige preferanser og ønsker. Figur 1 JourneySwipe Promobilde [1] 1 Mye sett i applikasjoner som Tinder [2] og hot or not [3] 2 I vår betydning er aktivteter restauranter, museum, kjente attraksjoner m.m. 3 av 36

4 1.1 Ide Inspirasjonen til prosjektet baserer seg på de populære swipe applikasjonene, som Tinder [2] og Tender [4] er gode eksempeler på. Vi ønsket å lage en applikasjon der brukeren får presentert aktiviteter, som spisesteder og attraksjoner. Ideen kommer av at vi selv er glad i å reise, men prosessen med å planlegge en tur skygger ofte litt for gleden. Vi ønsker derfor å se på mulighetene for å forekle denne prosessen. 1.2 Problemstilling Reiseinformasjon er spredt rundt hos flere forskjellige aktører, det kan føre til en omfattende planleggingsprosess i forkant av en reise. Vi ønsker å se på hvordan vi kan forenkle denne prosessen ved å samle informasjon fra ulike aktører til én applikasjon under ett enkelt brukergrensesnitt. Forskningsspørsmål Et overordnet forskningsspørsmål vil være: Kan prosessen med å utforske nye steder forenkles ved å kombinere eksisterende reiseinformasjon fra flere kilder? Grunnet oppgavens tidsramme er området som skal eksploreres begrenset til Oslo, og målgruppen er avgrenset til en foksugruppe (Se kapittel 3.3). Forskningsspørsmålet er derfor blitt noe modifisert: Kan prosessen ved å utforske aktiviteter i Oslo forenkles ved å kombinere eksisterende reiseinformasjon fra flere kilder? 4 av 36

5 2. Teori Vi har sett på personvern, universell design, brukeropplevelse og sosial navigasjon som er relevant for vår applikasjon. 2.1 Personvern Artikkelen Negotiating Privacy Boundaries in Social Applications for Accessibility [5] presenterer noen sentrale retningslinjer for personvern. Disse er meget aktuell i vår oppgave ettersom vår applikasjon krever at man deler sin lokasjon. Et sentralt punkt er at brukeren selv skal ha kontroll over personvernet i en applikasjon. Vi vil i vår applikasjon fokusere på å ikke lagre unødvendige personopplysninger i henhold til datatilsynets personvernprinsipper [6]. Noen av personopplysningene vil være valgfrie, men kan gi en bedre brukeropplevelse dersom alle blir utfylt. Dette gir brukeren kontroll over hvor mye informasjon de selv ønsker å oppgi. 2.2 Universell design Nødvendig for nokon, bra for alle om universell utforming. Applikasjonen vil ideelt sett være tilpasset for ulike brukergrupper basert på Brugaler s (2007) 7 prinsipper [7] : 1. Rettferdig bruk. Designet er brukervennlig og appellerende for personer med ulike ferdigheter. 2. Fleksibilitet i bruk. Designet er tilpasset et bredt spekter av individuelle preferanser. 3. Enkel og intuitiv bruk. Designet er så enkelt at alle forstår hvordan man kan bruke det. Uavhengig av brukerens erfaringer, kunskap, språkkunnskaper eller konsentrasjonsnivå. 4. Forståelig informasjon. Designet kommuniserer nødvendig informasjon på en effektiv måte til brukeren, uavhengig av brukerens miljø eller sanseevner 5. Toleranse for feil. Designet reduserer farer og uønskede konsekvenser, og minimaliserer uønskede handlinger. 6. Lavt behov for fysisk innsats. Designet kan brukes effektivt og komfortabelt, samtidig som det er lav sjanse for utmattelse 7. Størrelse og plass for tilgang og bruk. Passende størrelse og plass skal gis brukeren av løsningen uavhengig av fysisk størrelse og mobilitet. Mange av disse prinsippene vil sannsynligvis ikke bli realisert i en high fidelity prototype ettersom det tekniske ikke gjennomføres. Vi vil fortsatt ta flere faglige valg knyttet til visuelle elementer. Vi vil blant annet utføre Coblis fargeblindhet test [8]. Plos (2006) [9] diskuterers det også at mock ups burde strukturelt utarbeides som en ferdig applikasjon. En mock up vil være nytt for en bruker, og kan derfor skape forvirring som fører til negativ tilbakemelding. 5 av 36

6 2.3 Brukeropplevelse User experience is how a person feels when interfacing with a system. [10] Et av våre hovedmål er å skape en applikasjon som er enkel å bruke, for å nå flest mulig brukere i målgruppen. I Sandnes (2011) [11] vises det til fem nøkkelattributter som må være tilstede for å skape en god brukeropplevelse. 1. The system must be easy to learn. 2. Should be effective to use. 3. Must be easy to remember how to use the system. 4. The system should minimize the chances of errors and be tolerant of user errors. 5. The system must be comfortable to use. Disse nøkkelattributtene vil stå sentralt i vår utvikling og utforming av applikasjonen. 2.4 Sosial navigasjon Sosial navigasjon baserer seg på hvordan brukere kan få informasjon om områder de befinner seg i, ved hjelp av andres input. Artikkelen CityFlocks [12] deler dette hovedsaklig opp i direkte og indirekte sosial navigasjon. Indirekte vil si at det er brukere av system som produserer deler av informasjonen sammen over tid. Direkte vil si at det er profesjonelle aktør som leverer informasjonen. Et resultat av CityFlocks studier viser at brukere generelt foretrekker en kombinasjon av direkte og indirekte sosial navigasjon. Videre viste gjennomført brukertesting at mobilbrukere foretrekker indirekte sosial navigasjon. Dette vil være sentralt å tenke på i utviklingsprosessen. Det er også viktig å tenke på hva som er kriteriene og motivasjonen til brukere som kommer med input, slik som det blir argumentert med i artikkelen Aspects of personal navigation with collaborative user feedback [13], har brukere ofte en lavere terskel for å gi vurderinger dersom opplevelsen er negativt ladet. 6 av 36

7 3. Case Vi har sett på eksterne kilder som vil bli brukt i applikasjonen. Basert på dette er det satt opp en struktur og avgrenset en målgruppe og fokusgruppe for applikasjonen. 3.1 Eksisterende applikasjoner Applikasjonen vår baserer seg på innhenting av informasjon og ideer fra eksterne kilder. Disse er valgt basert på deres markedsposisjon og popularitet blant reisende. Yelp Yelp er en brukerorientert anmeldelsesnettsted. Yelp ble startet i 2004 for å hjelpe folk med å finne bra lokale bedrifter som tannleger, frisører og bilmekanikere. K ort fortalt er Yelp et nettsted hvor brukere kan anmelde og gi kommentarer til alt fra butikker og restauranter til hoppbakker og lokale svømmebasseng. [14] TripAdvisor TripAdvisor er et av verdens største reisenettsteder, som gjør det mulig for reisende å planlegge og bestille den perfekte reisen. Reiseportalen besøkes av mer enn 340 millioner mennersker hver måned for å planlegge egne eller andres reiser både privat og i jobbsammenheng. [15] Google Maps Google Maps er en av verdens mest brukte karttjenester, både for PC og mobil. Google Maps gjør det blant annet mulig for brukere å finne lokale virksomheter, vise kart og få veibeskrivelser. [16] CityMaps2Go CityMaps2Go er en offline kart og reiseinformasjonstjeneste som lagrer reiseinformasjon offline, slik at man kan planlegge reisen på forhånd og unngå å bruke mobildata når man benytter applikasjonen. [17] 7 av 36

8 3.2 Målgruppe Hovedmålgruppen er reisende som ønsker å utforske nye steder. De som ønsker å være spontane og ikke planlegger så mye på forhånd, vil også være meget aktuell for vår applikasjon. En sekundær målgruppe kan være mennesker som ønsker å være turist i egen by. Dette kan være nyttig for å utforske mindre kjente aktiviteter i sin egen by. Det kan også være effektivt for når man får besøk, eller dersom man er nyinnflyttet. Målgruppen er meget generell, og dette kan by på problemer under utvikling av applikasjonen. Vi har derfor valgt å sette opp en fokusgruppe, som er en mer spisset målgruppe for dette prosjektet. 3.3 Fokusgruppe Det er i dette prosjektet opprettet en fokusgruppe bestående av studenter. Dette er for å få testet prototypen på noen brukere innenfor prosjektets tidsramme. Ideelt ville denne fokusgruppen bestått av personer fra ulike land, bakgrunn, alder og ferdigheter. Dette er for å dekke så mye av målgruppen som mulig, og for å få testet prototypen på så mange brukergrupper som mulig. Vi har god tilgang på medstudenter, og kan derfor få testet prototypen i flere runder eventuelt på studenter fra flere ulike retninger. 8 av 36

9 3.4 Overordnet arkitektur Under har vi en modell over hvordan den overordnede arkitekturen skal se ut og hvordan de ulike elementene skal kommunisere med hverandre i sluttresultatet. Figur 2 Overordnet arkitektur [18] 9 av 36

10 4. Metode For å teste prototypen vil vi i dette prosjektet gjennomføre brukertester i form av intervju og observasjoner. Dette vil gi oss både kvalitativ og kvantitativ data å bearbeide i ettertid. 4.1 Brukertesting Brukertesting er en metode for å evaluere og teste et produkt på brukere og er mye brukt i brukersentrert interaksjonsdesign. Som nevnt i artikkelen Web evaluation: Heuristic evaluation vs. user testing [19] så er det her viktig med gode scenarioer som har muligheter for feil, dette er fordi det da er mulig å avdekke mulige problemområder. Vår brukertesting skal utføres ved hjelp av think aloud [20] intervjuer, der brukerene vurderer mockup en. Vi bruker WAI Site Usability Testing Questions [21] som mal for utarbeidelse av intervjuspørsmålene. Vi vil også gjennomføre en spørreundersøkelse (Se vedlegg 3) etter brukertesten hvor deltakeren får avgitt sin mening anonymt. 10 av 36

11 5. Utvikling og funn Vi har valgt å bruke prototyping som en metode for å visualisere og fremstille vår ide. Utviklingen foregår i to faser. Første fase består av å lage en mock up hvor ideen og konseptet er i fokus. Denne mockupen vil bli testet av en fokusgruppe. Målet med dette vil være å få innspill og tilbakemeldinger på konseptet som en helhet. Mock ups er en effektiv måte å involvere brukerene i utviklingen, fordi de lettere kan få en forståelse av hva konseptet faktisk er når det er mulighet for hands on experince og gjennomføring av visuelle scenarioer. [22] 5.1 Low fidelity prototype Vi har hele tiden hatt et brukerorientert fokus, det ble derfor produsert en enkel mockup for å illustrere konseptet til applikasjonen. Denne skulle ved hjelp av programmet Balsamiq mockups [23] enkelt illustrere oppsett av de enkelte skjermbildene og hvordan man navigerer rundt i applikasjonen. Krav til mockup Vi satt opp enkle krav til mockupen basert på hva vi ønsket at applikasjonen skal kunne gjøre: Vise aktiviteter i nærområdet Vise filtrering av aktiviteter Vise mer informasjon om aktiviteter Mulighet til å lagre eller avslå aktiviteter Liste opp lagrede aktiviteter Legge til eller fjerne lagrede aktiviteter fra en liste i et kart Vise reiserute mellom valgte aktiviteter Holde oversikt over brukerinformasjon (navn, epost m.m.) Design av mockup Som nevnt, ble Balsamiq mockups brukt til å skissere opp og gjøre mockupen så interaktiv som mulig. Balsamiq gir et standard design / utseende som vi ikke har tatt store designvalg mot. Det gir et litt barnslig / tegneserieaktig utseende, som fort kan påvirke resultatet av intervjuet. Det sparer oss derimot mye tid ved at mockupen blir så enkel som mulig. Det er også begrenset med funksjonalitet i dette programmet, og vi har bare brukt det for å teste konseptet. Se vedlegg 1 for de ulike skjermbildene fra mockupen. 11 av 36

12 5.2 Funn Det er i denne prosessen brukt dybdeintervjuer/observasjoner av en fokusgruppe for å teste mockupen mot brukere. Intervjuene ble gjennomført ved å la brukeren teste mockupen, mens vi observerte deres håndtering av den. Det ble også stilt spørsmål underveis i testingen for å bedre kartlegge deres inntrykk av konseptet. Brukertest og observasjon Brukertesten ble gjennomført av et utvalg personer som falt innenfor fokusgruppen. Totalt ble det gjennomført brukertesting med ni ulike personer. Dette ga konstruktive tilbakemeldinger om forbedringer til en high fidelity prototype, hvor brukeren er i fokus. Brukertesten besto av tre deler. Første delen var for å fange brukerens førsteinntrykk, andre delen for å observere hva brukeren ville gjort i applikasjonen, og siste delen for å hente inn brukerens helhetsinntrykk og meninger om applikasjonen. Del 1 introduksjon til applikasjonen Testen startet med å kun la brukeren se første skjermbilde av applikasjonen, og beskrive hva de så og hva de trodde denne applikasjonen handlet om. Brukernes førsteinntrykk av applikasjonen hadde noen fellestrekk. Mange skjønte at applikasjonen handlet om steder og lokale bedrifter. Få skjønte at den skulle brukes til å sette opp veibeskrivelse til disse stedene. Noen forsto heller ikke hvorfor de skulle bruke denne applikasjonen over yelp eller eventuelt andre eksisterende reiseapplikasjoner. Dette tyder på at reisedelen av applikasjonen kanskje ikke kommer tydelig nok frem. Flere mente designet lignet på facebook, på grunn av farger og menyen nederst i applikasjonen. I tillegg var det flere som kjente igjen «hot or not» mekanismen som brukes i blant annet tinder. Det første brukerne ville gjøre var enten å trykke på mer informasjon om steder eller X og V for å gå til neste sted. Vi ser på dette som positivt, da de ikke trykker seg vekk fra første steg i applikasjonen (nemlig å velge steder), istedenfor å trykke seg bort i menyen. Etter første del av brukertesten opplevde flertallet at det handlet om å dra ut å reise for å se nye steder og flertallet mente at målgruppen var turister og unge på reisefot. Del 2 observasjon av applikasjonen I denne delen av Brukertesten lot vi brukeren trykke fritt i applikasjonen og gjøre seg kjent med de ulike delene, for så å be de utføre et scenario. Scenarioet var å «like» et sted, gå i favoritter, legge attraksjonen til i journey og se reiseruten i Journey. Det som kom tydeligst frem i denne delen av testen var pluss( + ) og minus( ) knappene i favoritter. Veldig få skjønte at disse skulle brukes for å legge til steder man ønsket å dra til i «journey». I tillegg var det flere som ønsket en måte å fjerne steder fra favoritter. Det ble 12 av 36

13 også kommentert at dette var et redundant steg, fordi man måtte velge en attraksjon to ganger, før det vises i journey. De fleste forsto at man kunne trykke på bildet for å få mer informasjon om de, men når de trykket på de igjennom favoritter ble de forvirret. Mange følte seg litt låst på «mer info» og visste ikke helt hvordan de skulle komme seg tilbake til hovedsiden. Her nevnte også mange at de savnet mer informasjon på hovedsiden slik at de ikke trengte å trykke på mer info. Nesten ingen skjønte hva filterikonet var før de trykket på det og teksten «filter» kom frem. Noe som kan tyde på at dette ikonet ikke er brukt nok i andre applikasjoner til å bli et universalt ikon. Når testerne skulle gjennomføre et scenario var det få som skjønte funksjonen til «Favoritter og hoppet rett til «Journey» vinduet, etter å ha valgt et sted. Det var også tydelig at brukeropplevelsen ble lite realistisk for brukerne siden det bare var en mockup/low fidelity prototype, som førte til at de fleste følte at noe manglet for å danne en fullstending forståelse av applikasjonen. Del 3 Feedback Etter observasjonene av brukerne ble det stilt noen spørsmål for å kartlegge helhetsinntrykket av applikasjonen. Selv om mange brukere forsto at det handlet om å reise, var det ikke alle som hadde helt skjønt meningen med applikasjonen og mente at dette ikke kom godt nok frem. Mange trodde blant annet at favoritter var en liste over alle eksisterende attraksjoner, og at denne listen kom til å bli veldig lang. Flertallet likte kartfunksjonen til applikasjonen best og så på det som noe nyttig. Veldig få likte pluss og minus funksjonen i favoritter. Ett par brukere nevnte også at de savnet funksjonen til å kunne legge til steder de allerede viste om. Slik at de kan legge til attraksjoner de ønsket å besøke, i tillegg til å finne nye attraksjoner. Én bruker mente også at applikasjonen enkelt kunne blitt utkonkurrert av CityMaps2Go [16], som er en lignende tjeneste, men også en offline funksjon. Det kan være positivt i forhold til kostnadsnivå på datatrafikk i utlandet. Konklusjon fra brukertest Vi fikk mye konstruktiv tilbakemelding, og så flere fellestrekk blant testobjektene. Bl.a at de fleste fikk assosiasjoner til facebook og at favoritter delen var mest forvirrende. Det var også småting som pushnotifikasjoner og profil som virket unødvendig på noen brukere. Fokusgruppen forsto hvem målgruppen var, selv om selve applikasjonens mål ikke var like tydelig for alle brukerne. 13 av 36

14 5.3 Spørreundersøkelse Vi laget også en enkel spørreundersøkelse som testobjektene gjennomførte etter brukertesten (se vedlegg om spørreundersøkelse), for å samle kvantitative data om applikasjonen. Dette ble ikke et godt representativt utvalg av hele målgruppen, men gav et lite inntrykk av hva fokusgruppen mente om applikasjonen. Vi valgte å prioritere det som fikk mest negativ tilbakemeldinger i spørreundersøkelsen. Vi fikk blant annet inntrykk av at applikasjonen egnet seg godt for repeterende bruk og at vi hadde valgt riktig fokusgruppe for intervju. Navigasjon og målet med brukernes rolle på de ulike sidene varierte. Noe som kan skylde mangel av informasjon på hvert skjermbilde. Her var det også noe uenhighet om hvor godt applikasjonen var for førstegangsbrukere. Det kan tyde på mangel av instruksjoner, ettersom repeterende bruk hadde mer positive tilbakemeldinger. Det virket også som det var enkelt for brukeren å huske hvor de ulike tingene var. Både ønske om å bruke applikasjonen og at den virket appellerende fikk positive tilbakemeldinger det kan bety at det finnes et marked for denne applikasjonen. Vi ser derfor behovet for å gjøre applikasjonen mer forståelig for brukeren i starten, slik at de får et bedre førsteinntrykk. 5.4 High Fidelity prototype Basert på tilbakemeldingene på low fidelity prototypen utviklet vi en high fidelity prototype ved hjelp av programvaren Sketch [24]. Denne inneholder mer funksjonalitet og interaktivitet [25]. Fuksjonalitet og interaktivitet er lagt på ved hjelp av Invision [26]. Basert på tilbakemeldingene endte vi opp med følgende funksjonalitet: Vise aktiviteter i nærområdet Filtrere aktiviteter Vise mer informasjon om aktiviteter Mulighet til å lagre eller avslå aktiviteter Liste opp lagrede aktiviteter Fjerne lagrede aktiviteter Søke opp attraksjoner Vise reiserute til valgte aktivitet Holde oversikt over brukerinformasjon (navn, epost m.m.) Filtrere aktiviteter basert på aldersrestriksjoner Vi har fokusert på et rent design som skal være enkelt å bruke, og skape en behagelig opplevelse av applikasjonen. Det er gått bort fra fargevalg som kan assosieres til andre 14 av 36

15 applikajsoner (som facebook). Hjem knappen i navigasjonen er byttet til discover. Det er fordi hjem er en meget vag beskrivelse av en funksjonalitet, og fort kan føre til forvirring. Det er lagt til mer informasjon på discover skjermen, slik at det ikke alltid vil være nødvendig å klikke på mer informasjon. Her er det lagt til beskrivelse av aktiviteten (restaurant, museum osv). samt prisklasse og åpningstider. Den største endringen som er gjort i forhold til funksjonalitet er favoritter. Dette steget i applikasjonen var en redundant funksjon, og skapte mer forvirring enn forståelse. Den er derfor omdøpt til aktiviteter. I dette vinduet vil man få en liste over alle aktivitetene man har trykket ja til. Her kan man slette en aktivitet, eller få veibeskrivelse til aktiviteten. Ved å swipe til venstre sletter man aktiviteten, swiper man til høyre får man opp veibeskrivelse. Trykker man på teksten kommer man til siden for mer informasjon. Dette kan være nyttig dersom man trenger en påminnelse på hva denne aktiviteten inneholdt. Man kan nå frivillig velge å gå innom aktiviteter, eller å gå rett til kart. Listen kan være en fin oversikt for å se hvilke aktiviteter man ønsker å besøke. Man kan også styre timeplanen sin selv, ved å få veibeskrivelse direkte til den aktiviteten fra sin nåværende plassering. Kartfunksjonen fungerer bare som en kartvisning, som viser en rute mellom de ulike attraksjonene man har valgt. Her klikker man bare på en rute, og får veibeskrivelse på hvor man skal kjøre, sykle eller gå. Vi har fokusert mye på en behagelig brukeropplevelse i denne prototypen, men dersom det skulle oppstå forvirring er det også mulig å få en gjennomgang av funksjonalitetene i applikasjonen ved å trykke på Tutorial under Profile. 15 av 36

16 5.5 Faglige valg Det visuelle designet av den endelige prototypen ble vellykket når det gjaldt farger rettet mot de med synsproblemer. Vi testet hovedsidene våre i Coblis, og fikk inntrykk av at applikasjonen kunne brukes selv om man hadde ulike former for fargeblindhet (se vedlegg 5 for eksempel). Vi har prøvd å bruke kjente elementer for å forenkle brukeropplevelsen, og gjøre systemet så brukervennlig som mulig. Vi har hold oss til få skjermbilder, med minst mulig oppgaver per bilde. Som nevnt har vi også brukt den kjente hot or not stilen for å velge aktiviteter, som gjør applikasjonen lettere å lære, ettersom dette er noe deler av målgruppen allerede kjenner til. Denne funksjonen kan derimot være vanskelig å forstå for de som ikke har brukt tinder og lignende applikasjoner før. Dette erfarte vi i 1 av de 9 intervjuene. Dette fikk oss derfor til å legge på en hjelp ( Tutorial ) knapp under profil, som skal forklare dypere hvordan man tar i bruk applikasjonen. Figur 3 JourneySwipe Promobilde 2 [1] 16 av 36

17 6. Diskusjon I problemstillingen tidligere i denne rapporten presenterer vi problemet rundt spredt informasjon i relasjon til reising. Ved å kombinere denne informasjonen under ett brukergrensesnitt ønsket vi å forenkle prosessen med å utforske nye steder. Gjennom applikasjonen JourneySwipe har vi forsøkt å gjøre dette. Ved å lese artikler fra andre studier tilegnet vi oss en god forståelse for hva som var viktig å fokusere på. Ved hjelp av intervju og observasjoner av fokusgruppe fikk vi tilstrekkelig data til å produsere en high fidelity prototype. Vi har fokusert på et ryddig og behagelig design, for å skape en applikasjon alle kan bruke ved hjelp av Brugaler s (2007) [7]. Vi har brukt både direkte og indirekte informasjon med fokus på indirekte kommunikasjon som i følge artikkelen Cityflocks [12] egner seg best til mobilbruk. Ved å analysere eksisterende applikasjoner fikk vi et godt inntrykk i hva som eksisterte på markedet idag. Dette ga oss en god oversikt over hva som kunne brukes videre i vår egen applikasjon. Både yelp s og TripAdvisor s APIér kan i fremtiden brukes for å enkelt hente inn ulike aktiviteter og informasjon. Google maps kan brukes for veibeskrivelse og lokasjon. I tillegg ble vi veldig inspirert av CityMaps2Go s mulighet for å lagre informasjon om aktiviteter offline. Vi tenker derfor at det hadde vært ideelt å gjøre det samme for aktiviteter som brukeren har valgt. Innsamling av data er gjort på en måte som var realistisk å gjennomføre for oss. Her har vi brukt personer som faller innenfor målgruppen, og som vi hadde tilgang til. Dette er på ingen måte et godt representativt utvalg av målgruppen, men det gav oss nok data til å jobbe videre med. Dersom dette prosjektet skulle gjennomføres på nytt ville vi arbeidet mer med å finne et godt representativt utvalg av testpersoner tidlig i utviklingsprosessen. Vi støttet på noen problemer under brukertesting av mockup. Brukerne savnet en mer funksjonell prototype, som ga et negativt inntrykk av applikasjonen. Til tross for at de virket positive til konseptet. Vi fikk konstruktiv tilbakemelding som vi kunne bruke til å bygge videre på high fidelity prototypen. Vi kan derfor si at disse testene hadde verdi for oss gjennom utviklingen, selv om de gav en lite realistisk brukertesting. 17 av 36

18 7. Konklusjon 7.1 Forskningsspørsmål Kan prosessen med å utforske aktiviteter i Oslo forenkles ved å kombinere eksisterende reiseinformasjon fra flere kilder? Det er vanskelig å si om JourneySwipe gjør prosessen med å utforske aktiviteter i Oslo enkelere basert på dette prosjektet. Våre data tilsier at folk er positive til ideen og konseptet, men ettersom det bare er utviklet prototyper er det ikke blitt gjennomført tilstrekkelig testing som vi kan trekke en konklusjon fra. Vi har med dette prosjektet sett på eksisterende applikasjoner og hvordan disse kan benyttes for å hente ut informasjon. Vi kan si at det finnes tilstrekkelig med informasjon, og at man i teorien skal kunne utvikle en fullt fungerende applikasjon med hjelp av disse kildene. 7.2 Svakheter med oppgaven Vi har fokusert mye på prototyping og ikke like mye på uvikling av en funksjonell applikasjon. Det har blant annet ført til at det ikke har vært mulig å gjennomføre fullstendig og tilstrekkelig brukertesting. Testingen har blitt gjort på en mockup og dette gir et vagt bilde av den fullstendige applikasjonen. Grunnet oppgavens tidsramme er det heller ikke blitt gjennomført brukertesting av high fidelity prototypen. Vi har derfor ingen data på hvordan denne vil bli mottatt av målgruppen. Grunnet tilgang på testpersoner og tidsbegrensninger er brukertestingen ikke gjennomført på et godt representativt utvalg av målgruppen. Ideelt sett ville både low fidelity og High fidelity prototypen blitt testet av brukere fra ulike land, bakgrunn, aldersgrupper og behov. Applikasjonen kunne da blitt testet på flere områder og ulike attraksjoner. Det ville sannsynligvis før til andre tilbakemeldinger enn de vi har samlet inn. Vår fokusgruppe besto av unge mennesker i Oslo, med relativ god teknisk kompetanse. Det er ikke lastet inn noe data i selve applikasjonen, fordi dette bare er en prototype. Vi har derfor ikke testet hvordan kombineringen av informasjonen fra de eksterne kildene fungerer i praksis. Vi har bare sett på de teoretiske mulighetene for dette. Det har vært et meget ambisiøst prosjekt å utvikle en fullstending applikasjon innenfor prosjektets tidsramme, og vi har ikke ansett dette som et realistisk mål. Det er derfor lagt vekt på det som har vært mest essensielt i forhold til fagets plan og pensum. Vi har hatt et høyt fokus på brukernes sentralitet i prosessen og på design av applikasjonen. 18 av 36

19 7.3 Videre arbeid Utviklingen av denne applikasjonen er ikke fullstendig, dersom vi skulle jobbet videre med prosjektet ville vi prioritert følgende punkt frem mot en 1.0 versjon av applikasjonen. 1. Brukerteste High fidelity prototype 2. Analysere tilbakemeldinger fra High fidelity brukertest 3. Implementere endringer av brukertest i designet av applikasjonen 4. Produksjon av applikasjon med funksjonalitet (kode) 5. Endelig brukertest av første utgave av applikasjonen 6. Implementere siste endringer, basert på brukertest Dette vil kreve en mye større tidsramme, men vi tror det også vil skape et produkt som ville blitt godt mottatt av målgruppen. Figur 4 JourneySwipe promobilde [1] 19 av 36

20 8. Referanser [1] Freebie promotion template for Apple Devices 6 ipad photo mockups/ (sist hentet ) [2] Tinder app, (sist hentet ) [3] Hot or not app (sist hentet ) [4] Tender app, food and recipes/id ?mt=8 (sist hentet ) [5] Holone, H., & Herstad, J. (2010, October). Negotiating privacy boundaries in social applications for accessibility mapping. In Proceedings of the 6th Nordic Conference on Human Computer Interaction: Extending Boundaries (pp ). ACM. [6] (sist hentet ) [7] Burgstahler, Sheryl (2001): Universal Design of Instruction. University of Washington ( ) [8] Simulering av fargeblindhet, blindness.com/coblis color blindness simulator / [9] Plos, A., Buisine, S (2006): Universal design for mobile phones: a case study. ACM. [10] is user experience design overview toolsand resources/ (sist hentet ) [11] Sandnes, F. E. (2011). Universell utforming av IKT systemer. Oslo: Universitetsforlaget. [12] Bilandzic, M., Foth, M., & De Luca, A. (2008). CityFlocks: Designing Social Navigation for Urban Mobile Information Systems. Paper presented at the ACM SIGCHI Designing Interactive Systems (DIS) Conference, Cape Town, South Africa. [13] Holone, H., Misund, G., Tolsby, H., Kristoffersen, S. (2008) : Aspects of personal navigation with collaborative user feedback. ACM. [14] Yelp, (sist hentet ) [15] TripAdvisor, (sist hentet ) [16] Google Maps, (sist hentet ) 20 av 36

21 [17] CityMaps2Go, the app (sist hentet ) [18] Overordnet arkitekturillustrasjon, tegnet i Balsamiq Mockups ( ) [19] Wei siong Tan, Dahai Liu, Ram Bishu (2009) "Web evaluation: Heuristic evaluation vs. user testing" Department of Industrial and Management Systems Engineering, University of Nebraska at Lincoln, USA Department of Human Factors and Systems, Embry Riddle Aeronautical University, 600 S. Clyde Morris Blvd., Daytona Beach, USA [20] Elizabeth Charters (2003), The Use of Think aloud Methods in Qualitative Research An Introduction to Think aloud Methods, Seneca College of Applied Arts & Technology [21] WAI Site Usability Testing Questions, (sist hentet ) [22] Iacucci, G., Kuutti, K., Ranta, M., On the Move with a Magic Thing: Role Playing in the Design of Mobile Services and Devices. In the Proceedings of DIS2000, Designing Interactive Systems, New York City, USA, pp [23] Balsamiq Mockups, Programvare brukt for å lage low fidelity prototype, [24] Sketch, programvare for ptototyping, [25] Rudd J., Stern K., Isensee S., (1996) "Low vs High fidelity prototyping debate", New York, USA [26] Invision, webapp for å sette sammen interaktive prototyper, 21 av 36

22 9. Vedlegg Vedlegg 1 Mockup 22 av 36

23 Vedlegg 2 Intervjuspørsmål Kvalitativ dybdeintervju for brukertest av mockup Spørreundersøkelsen er skrevet i muntlig form, slik den vil bli utført for vært intervju. Del 1 Intro 1. Uten å gjøre noe, utifra hva du ser på skjermen, hva tror du at du kan gjøre i denne applikasjonen? 2. Kan du gi oss/meg et umiddelbart førsteinntrykk av layouten av applikasjonen? a. Hva tenker du om bruken av farger, grafikk, bilder eks? 3. Hva er det første du ville gjort/trykket på? 4. Hva tror du at meningen med applikasjonen er? 5. Hvem tror du er målgruppen? Del 2.1 Eksplorering Utforsk applikasjonen fritt i ca 3 minutter, og snakk gjerne høyt mens du gjør dette. (Intervjuer skal svare på minst mulig spørsmål) Del 2.2 Scenario Prøv å legg til en attraksjon og start navigering til valgt attraksjon. Snakk gjerne høyt mens du gjør dette, og si ifra når du mener at du har fullført oppgaven. Del 4 Etter test intervju 1. Hva er ditt helhetsinntrykk av applikasjonen? 2. Kan du gi oss tre ord som du mener beskriver denne applikasjonen? 3. Hva liker du best med applikasjonen? 4. Hva liker du minst med applikasjonen? 5. Hvis du kunne gjøre én signifikant endring i applikasjonen, hva ville det vært? 6. Er dette en applikasjon du ville tatt i bruk, hvis du var ute å reiste? a. Hvorfor? 7. Er det noe du føler mangler / ønsker ble lagt til? 8. Har du noen spørsmål om applikasjonen? 23 av 36

24 Vedlegg 3 Spørreundersøkelse Vedlegg 3.1 Spørsmål Kvantitativ spørreskjema for etter brukertest av mockup 1. Applikasjonen er applerende 2. Førstesiden gir meg lyst til å utforske applikasjonen 3. Det er enkelt å finne frem/navigere i applikasjonen 4. Jeg finner raskt det jeg er ute etter 5. Det er enkelt å huske hvor ting var 6. Informasjon er plassert strategisk på de enkelte sidene 7. Hvert skjermbilde har tilstrekkelig med informasjon 8. Applikasjonen er relevant for meg 9. Tjenesten gjør at jeg ønsker å bruke applikasjonen 10. Applikasjonen er godt egnet for førstegangsbrukere 11. Applikasjonen er godt egnet for repeterende bruk 12. Applikasjonens ulike sider har alltid et konkret mål 13. Jeg hadde til en vær tid en god oversikt over hva jeg kunne gjøre på de ulike sidene 14. Det er forståelig hvordan elementer (knapper, menyer eks) fungerer 24 av 36

25 Vedlegg 3.2 Respons 25 av 36

26 26 av 36

27 27 av 36

28 28 av 36

29 Vedlegg 4 High fidelity Prototype 29 av 36

30 Menyen består av 4 hovedbilder, 3 5, 9, 13 og 15. Som vist på bilde 7, så vil filter menyen kunne åpnes på alle bilder hvor topmenyen er tilstedet. Topmenyen har også en valgmulighet for å søke etter aktiviteter, men det ble ikke utviklet et skjermbilde for dette i denne prototypen. 30 av 36

31 31 av 36

32 32 av 36

33 33 av 36

34 34 av 36

35 Vedlegg 5 Ulike former for fargeblindhet Simulert i blindness.com/coblis color blindness simulator/ ( ) 35 av 36

36 36 av 36