1. Introduksjon. Side 3 av 20. (Kopetz 2011). 2 Et konsept der mobile enheter tilpasser sin funksjonalitet etter hvilken kontekst de befinner

Transkript

1

2 1. Introduksjon Mål og målgruppe Prosjektgruppen Prosjektplan 3 2. Idé- prosess og datainnsamling Første idé og intervju Andre idé Observasjon Spørreundersøkelse 5 3. Fra idé til prototype Scenario Low- fidelity prototype Funksjoner Designprinsipper og retningslinjer Universell utforming og WCAG Teknisk løsning High- fidelity prototype 8 4. Evaluering Formativ brukertesting Planlegging og gjennomføring Resultat av formativ test Resultat av formativ test Heuristiske evalueringer Summativ brukertesting Planlegging og gjennomføring Resultat Eksperiment Design Sted Utvalg Eksperiment 1 Finn rom Eksperiment 2 Avtale møte Piloteksperiment Formidling av informasjon Training session Random assignment Kvalitativ data Belønning av deltakere Resultater fra eksperimentet Pålitelighet Etiske aspekter ved prosjektet Integritet Informert samtykke Videre muligheter Overførbarhet Veien videre Konklusjon 19 Side 2 av 20

3 1. Introduksjon Denne rapporten omhandler vårt prosjekt i INF2260, utført i samarbeid med Accenture. Accenture har et kontor på Institutt for Informatikk ved Universitetet i Oslo, der våre veiledere holder til. Prosjektet er en del av House of Things, et konsept som Accenture har basert på Internet Of Things 1. Målet med prosjektet var å lage en funksjonell high- fidelity prototype til demonstrasjon og evaluering. Det ble ikke satt noen absolutte krav til hva som skulle designes eller hvilken teknologi som skulle brukes, men det ble oppfordret til at prosjektet skulle omhandle Contextual Awareness 2 på smarttelefoner via ibeacons Mål og målgruppe Gjennom brainstorming og datainnsamling (som blir beskrevet nærmere i kapittel 2) kom vi frem til at det å møte hverandre på campus var noe mange studenter brukte mye tid og ressurser på. Derfor ville vi lage en mobilapplikasjon for innendørs lokalisering med studenter som målgruppe. Målet med applikasjonen var at den skulle gjøre det lettere for brukerne å lokalisere og avtale møter med hverandre. Etter oppfordring fra Accenture, snevret vi inn målgruppen til å kun inkludere studenter ved Institutt for informatikk. Dette var hensiktmessig siden det var de som var mest tilgjengelige for oss. 1.2 Prosjektgruppen. Prosjektgruppen består av Oscar Carlström, Jarl Erik Cedergren, Stian Kongsvik og Malin Aandahl. Alle studerer andre året på bachelorprogrammet Informatikk: Design, bruk, interaksjon ved UiO. 1.3 Prosjektplan Som en del av læringsprosessen og samarbeidet med Accenture ble vi oppfordret til å benytte oss av den smidige utviklingsmetoden Scrum. Dette innebar at vi skulle jobbe i sprinter på to uker. På slutten av hver sprint hadde vi en demo med Accenture der vi presenterte hva vi hadde gjennomført siden sist. Ettersom dette innebar at vi måtte forholde oss til mange korte frister fikk vi en jevn arbeidsfordeling ut over hele 1 Internet of things er et konsept med en visjon om å forene internett med den fysiske verden (Kopetz 2011). 2 Et konsept der mobile enheter tilpasser sin funksjonalitet etter hvilken kontekst de befinner seg i (Makkonen, Avdouevski, Kerminen & Visa, 2009 : ). 3 Teknologi som bruker Bluetooth Low Energy (BLE) for å sende ut et signal som kan fanges opp av mobile enheter (Apple Inc., 2014) Side 3 av 20

4 prosjektet. Vi brukte et Scrumboard 4 til å holde oversikt over backlog med To- Do, Doing og Done (Sommerville, 2014 : 70-72), som gjorde det enkelt å se hva vi hadde igjen å gjøre og hva som hadde blitt gjennomført. 2. Idéprosess og datainnsamling For å fremme idéutvikling deltok vi i en workshop arrangert av Accenture der vi jobbet frem nye ideer og forslag til prosjektet. I etterkant fortsatte vi i prosjektgruppen med videre brainstorming, tanke- kart, enkle skisser og storyboards. 2.1 Første idé og intervju Den første idéen vi utforsket var en løsning som gikk ut på å gjøre forelesninger smartere ved hjelp av ibeacons. For å finne ut om det fantes noe behov for en slik løsning, ville vi undersøke dette temaet nærmere ved hjelp av semi- strukturerte intervjuer (Rodgers, Sharp & Preece, 2011: ). Vi valgte denne metoden siden vi ønsket å samle inn kvalitativ data fra intervjuobjektene, samtidig som vi hadde noen konkrete spørsmål som vi ville stille. Vi intervjuet en foreleser og en pedagogikkstudent fra Universitetet i Oslo. Ut i fra tilbakemeldingene vi fikk fant vi ikke noe behov for en slik løsning. Foreleseren mente blant annet at forelesningene var gode nok slik det var, og at eventuelle problemer med forelesninger ikke var knyttet til mangel på tekniske hjelpemidler. Med bakgrunn i dette forkastet vi idéen med smart- forelesninger og startet på nye runder med idéutvikling. 2.2 Andre idé Tidsplan over semesteret En av idéene som dukket opp gjennom en ny idémyldring var en applikasjon som skulle hjelpe studenter å finne hverandre. Innad i prosjektgruppen brukte vi mye tid hver dag for å finne hverandre og avtale hvilket rom vi skulle møtes på, og det var ofte 4 I Scrum brukes en tavle med oppgaver for å visualisere kravspesifikasjonen (backlog) Side 4 av 20

5 tidskrevende å finne akkurat dette rommet. Siden dette var et problem for oss, ville vi undersøke om det fantes behov for en slik løsning hos andre studenter. 2.3 Observasjon For å forstå studentenes vaner rundt å møte hverandre gjennomførte vi en observasjon hvor vi tok rollen som komplette observatører (Lazar, Feng & Hochheiser, 2010 : 229). Denne metoden ble valgt for å få et inntrykk av møtevanene til studenter ved Institutt for Informatikk, i tillegg til å avdekke eventuelle utfordringer rundt dette. Observasjonene ble gjennomført i områder hvor studenter møtes, som for eksempel i ganger og ved grupperom. All observasjon ble gjennomført anonymt slik at ingen personlig data ble samlet inn. Gjennom observasjonen la vi merke til at mange bruker mobiltelefon for å avtale møter, i form av SMS og ringing. 2.4 Spørreundersøkelse For å samle inn kvantitativ data fra mange deltakere på kort tid valgte vi å gjennomføre en spørreundersøkelse over internett (Lazar, Feng & Hochheiser, 2010 : ) med verktøyet Google Forms 5. Gjennom en internett- basert løsning ble også deltakere utenfor Institutt for Informatikk invitert til å svare. Det var nyttig for å undersøke om dette var et problem for andre studenter. Om det var tilfelle, kunne løsningen potensielt gjenbrukes andre steder. Alle spørsmålene var utformet som lukkede spørsmål(lazar, Feng & Hochheiser, 2010 : 112) slik at vi enkelt kunne sammenligne svarene og prioritere hvilke funksjoner som skulle implementeres. Med over 60 deltakere viste resultatene at det var interesse for en slik løsning selv om Facebook var det som ble mest brukt for å lokalisere andre. Grunnet det høye antallet positive respondenter valgte vi å gå videre med denne idéen. Funksjoner som var ønskelige ble også notert og blir beskrevet nærmere i 3.3. En mulig svakhet ved denne spørreundersøkelsen var at den ble publisert på Facebook. Det kan ha vært derfor at Facebook resulterte som det 5 Google Forms er verktøy der man kan lage spørreskjemaer på internett. Side 5 av 20

6 mest brukte verktøyet for å lokalisere hverandre. Vi valgte likevel å benytte oss av Facebook siden vi mente at det var den enkleste måten å nå målgruppen vår på. 3. Fra idé til prototype Etter analyse av datainnsamlingen var neste steg å utvikle prototyper. Prototypene var viktige for å kunne gi et visuelt inntrykk av utviklingen og over hvordan sluttproduktet kunne bli. De var også sentrale midler for kunne kommunisere idé, visjon og ved evaluering med Accenture og potensielle brukere (Houde & Hill, 1997 : ). 3.1 Scenario Etter datainnsamlingen utviklet vi et scenario som var relevant til situasjoner der man skal lokalisere og møte kontakter. Vi valgte å bruke scenario for å enkelt kunne formidle idéen til Accenture og brukerne våre (Rodgers, Sharp & Preece, 2011: 415). Scenarioet tok for seg en elev som var ny på en skole og skulle finne sine kamerater. Ved hjelp av en mobilapplikasjon fant han raskt ut hvor kameratene hans befant seg. 3.2 Low- fidelity prototype Med utgangspunkt i scenarioet begynte vi å utvikle low- fidelity prototyper i form av storyboards, skisser og papir- prototyper. Vi lagde også en mer detaljert prototype der vi brukte Adobe Photoshop og en prototyping- applikasjon kalt POP. Både storyboardene, skissene, papirprototypene og POP- prototypen ble benyttet i formative brukertester for å få tilbakemelding fra brukere (Lazar, Feng & Hochheiser, 2010 : 260). Dette diskuteres nærmere i kapittel Funksjoner Etter spørreundersøkelsen fikk vi tall på hvilke funksjoner brukerne mente var viktigst i en slik applikasjon. Ut i fra brukernes ønsker lagde vi en kravspesifikasjon hvor de fire viktigste funksjonene var (prosentandelen kommer fra hvor mange deltakere som ønsket funksjonen): Skisse av low-fidelity prototype 1. Mulighet å endre sin tilgjengelighetsstatus (70 %) 2. Mulighet til å skjule sin egen posisjon (inkognito) (67 %) 3. Begrense hvem som kan se din egen posisjon til sine kontakter (66 %) 4. Et kart som viser din posisjon, samt hvor dine kontakter befinner seg (52 %) Til tross for at brukerne ønsket flere funksjoner enn kun disse fire, anbefalte Accenture å begrense funksjonaliteten til det mest nødvendige i en prototype grunnet prosjektets Side 6 av 20

7 tidsrammer. Sammen ble vi enige om å implementere disse fire funksjonene. Andre ønskelige funksjoner noterte vi i en backlog som en del av Scrum- prosessen. Et eksempel på en slik funksjon var muligheten å opprette møter med sine kontakter, noe som vi også implementerte senere i prossesen. 3.4 Designprinsipper og retningslinjer Resultatet av spørreundersøkelsen påvirket enkelte av designvalgene vi tok, slik at løsningen skulle ta vare på brukerens behov gjennom et godt og intuitivt design. Vi valgte å utvikle for ios siden alle i vår prosjektgruppe eier en iphone, noe som gjorde utviklingen mer praktisk for vår del. Dette valget førte til at vi måtte forholde oss til Apples retningslinjer for design (Apple Inc., 2014). For å skape et renere design valgte vi å skjule enkelte elementer og funksjoner (John Maeda, 2006), f.eks. gjennom å bruke drop- down menyer for å endre tilgjengelighetsstatus. Siden dette er en funksjon brukeren ikke behøver å se til en hver tid kan den godt skjules. Vi har også brukt den samme strategien for møter gjennom å pakke de inn i små bokser som kan ekspanderes. De designprinsippene som vi har valgt å fokusere mest på er: Feedback & Visibility: Vi har valgt å bruke både farger, symboler og tekst for å indikere brukerens valg. Consistency: For at brukerne lettere skulle lære seg å forstå grensesnittet valgte vi å gjenbruke mange av elementene til lignende funksjoner i appen. Mange av disse elementene følger også ios sine retningslinjer for design, slik at iphone- brukere vil kjenne seg igjen. 3.5 Universell utforming og WCAG Med hensyn til universell utforming har vi blant annet sørget for at viktig informasjon kommer tydelig fram. Når brukeren skal endre status gis feedback ved at Sterke farger for status farger og elementer i brukergrensesnittet forandrer seg. I tillegg er hvert valg tekstlig beskrevet for å ta hensyn til fargeblinde brukere. Informasjon blir presentert tydelig ved å benytte sterke kontraster slik at det blir enklere for svaksynte å benytte seg av appen. Side 7 av 20

8 Disse valgene er tatt i henhold til punkt og i WCAG (W3C, 2008), og oppfyller på enkelte steder kravene med karakter AA og AAA 6. Se punkt 6.2 for veien videre rundt universell utforming. 3.6 Teknisk løsning Accenture har en innovasjonslab med IBM, og disse deler kontorer med iad laben på Institutt for informatikk. Som et ledd av dette var det derfor ønsket av vi skulle benytte oss av ny IBM teknologi for rapid app prototyping. Derav ble brukergrensesnittet utviklet ved hjelp av rammeverket IBM Worklight. Med Worklight var det mulig å utvikle en hybrid- app 7 ved bruk av HTML, CSS og JavaScript. Å utvikle på denne måten var et alternativ til å utvikle native i Objective- C (som benyttes for ios). Server- siden av appen ble utviklet med sky- tjenesten IBM Bluemix. Her håndterte vi all informasjon som synkroniseres mellom klientene, som f. eks. brukerprofiler, statuser, møter osv. For dataoverføringen til databasen tok vi i bruk Node.js med Express som rammeverk før data ble plassert i en database gjennom MongoDB. Systemarkitektur til applikasjonen. 3.7 High- fidelity prototype Prototypen fungerer slik at når brukeren av appen står i et rom, kan alle brukerens kontakter se hvor han/hun befinner seg på et kart. Kontaktene kan også se om brukeren har satt sin status som ledig eller opptatt. Brukeren sin posisjon blir automatisk registrert når han/hun er innenfor rekkevidden til en ibeacon. Hver ibeacon er plassert slik at den representerer et unikt rom. Det er også mulig å avtale møter med sine kontakter på de forskjellige rommene. I tillegg er det mulig å skjule sin egen posisjon om man ikke ønsker å dele denne med sine kontakter. Gjennom disse funksjonene tilfredsstiller prototypen 6 Karakter for godkjent krav til WCAG, hvor A er laveste kriterie og AAA høyeste kriterie. 7 En hybrid- app er en applikasjon som kan brukes på flere plattformer men med en felles kodebase. Side 8 av 20

9 kravspesifikasjonen og dermed de viktigste behoven for brukerne. 4. Evaluering Gjennom en brukersentrert tilnærming (Rodgers, Sharp & Preece, 2011: ) gjennomførte vi tidlig i design- fasen formative tester med brukere i tillegg til heuristiske evalueringer med Accenture. Mot slutten benyttet vi oss også av summative tester og eksperiment. I dette kapittelet vil vi ta for oss formålet med disse metodene, hvordan de ble planlagt og hvilke resultater vi fikk. 4.1 Formativ brukertesting For å teste ut hvordan brukerne oppfattet enkelte dimensjoner ved applikasjon gjennomførte vi formative brukertestinger med low- fidelity prototypene (Lazar, Feng & Hochheiser, 2010 : 260) Planlegging og gjennomføring Den første formative testen vi gjennomførte var en gonzotest (Toftøy- Andersen & Wold, 2011: 129). Gonzotesting ble valgt grunnet at det var raskt, enkelt og at vi hadde potensielle brukere lett tilgjengelig. Verktøyet vi brukte var prototypeapplikasjonen POP. Vi testet hvordan brukerne oppfattet funksjonen for å endre tilgjengelighetsstatus og informasjon om en person på kartet. For å få en bredere forståelse av hvordan brukerne oppfattet grensesnittet, ba vi de tenkte høyt mens de testet ut, også kalt think- aloud- teknikk (Rodgers, Sharp & Preece, 2011: 256). Deltakerne som ble plukket ut var fire personer fra Institutt for Informatikk. Den andre formative testen ble også gjennomført som en gonzotest. Her brukte vi en enkel papir- prototype hvor målet var å evaluere brukergrensesnittet til møtefunksjonen Resultat av formativ test 1 Av tilbakemelding nevnte brukerne at noen av symbolene var for utydelige og at kartet ikke viste hele etasjen. Flere nevnte også at de kjente seg igjen i problemstillingen rundt å finne vennene sine på skolen, og var positive til idéen og konseptet. I ettertid ser vi at et mulig problem ved denne testen var at prototypen var Formativ test 1 ovenfor med POP, og formativ test 2 nedenfor med papirprototype. Side 9 av 20

10 såpass detaljert og høyoppløselig at den så ut som et ferdig produkt, noe som førte til at brukerne ofte prøvde å trykke på knapper og deler av skjermen som fortsatt ikke hadde noen funksjonalitet. Siden brukergrensesnittet lignet veldig på et ferdig produkt, kan det ha ført til at brukerne ikke ville kritisere denne prototypen like mye som de kanskje ville ha gjort med en papirprototype (Lazar, Feng & Hochheiser, 2010 : 260) Resultat av formativ test 2 Til den andre formative testen tok vi i bruk en enkel papir- prototype. Fra denne testingen fant vi ut at brukerne ikke forsto hvordan de skulle ta i bruk møtefunksjonen. Mange syntes møtelisten var for lik kontaktlisten og at det derfor var vanskelig å skille mellom disse. Inntrykket av denne formative testen var at brukerne ga mer kritisk tilbakemelding, noe som kan skyldes bruken av en papir- prototype. Tilbakemeldingen vi fikk fra brukerne resulterte i endringer i brukergrensesnittet og møtefunksjonen. Vi fokuserte på å gjenbruke funksjonalitet og elementer som fantes andre steder i applikasjonen slik at brukerne skulle kjenne seg bedre igjen og få mer flyt i navigasjonen. Informasjon rundt møter ble tydelig skilt fra kontaktlisten ved å plassere disse i små bokser. 4.2 Heuristiske evalueringer Som nevnt tidligere hadde vi ukentlige stand- up møter med Accenture, og Scrum- demo annen hver uke. Her fikk vi kontinuerlig tilbakemelding på prototypen fra flere eksperter. Blant annet fikk vi tilbakemelding på at kontrasten var for lav og at vi burde fokusere mer på WCAG. Stand-up møte til venstre og Scrum demo til høyre. 4.3 Summativ brukertesting Før vi gjennomførte eksperimentet (som blir beskrevet i punkt 4.4) ville vi at prototypen skulle være testet såpass godt at deltakerne kunne fokusere på å løse oppgavene uten å bli distrahert av mangel og feil i grensesnittet. Derfor valgte vi å gjennomføre en summativ brukertest der vi testet prototypen i sin helhet. Seks deltakere ble rekruttert til testingen, hvorav en var pilotdeltaker. Vi så på dette som et tilstrekkelig antall siden man ikke ønsker å generalisere i en summativ testing, men å rette opp feil og gjøre forbedringer i grensesnittet. Noen eksperter mener dessuten at Side 10 av 20

11 fem deltakere kan være nok til å finne hele 80 % av feilene (Lazar, Feng & Hochheiser, 2010 : 263) Planlegging og gjennomføring Siden vi ville teste helheten satt vi opp en rekke oppgaver som svarte til å teste ut de ulike funksjonene til appen. Vi brukte tid og feil- ratio til å måle brukbarheten. For å samle inn kvalitativ data under testen observerte vi deltakerne og stilte spørsmål etter at oppgavene ble fullført. For å sikre en god struktur under testen fordelte vi ansvaret slik at en av oss observerte, en målte tid og antall feil, en ledet testen og en noterte hva deltakeren svarte på spørsmålene. Skjermbilder av MeetIn Resultat Da vi var ferdige måtte vi sammenstille og analysere data som vi hadde samlet inn. Vi observerte at nesten alle brukerne gikk inn på en kontakt i kartet for å prøve å opprette et møte. Det var også mange som var litt forvirret over at det var et pluss- symbol som alltid sto i menyen og de tolket det som at det var en funksjon som tilhørte valg av tilgjengelighet. Dette viser at vi ikke hadde fokusert godt nok på designprinsipper som mapping og affordance (Rogers, Sharp & Preece, 2011 : 29). På grunnlag av dette måtte vi derfor foreta noen små, men viktige endringer i grensesnittet. Vi gjorde også en del andre interessante funn som at alle brukerne halverte tiden fra første gang de skulle opprette et møte til neste gang de skulle opprette et møte. Dette tolket vi som et tegn på god memorability (Rodgers, Sharp &, Preece, 2011 : 21). Side 11 av 20

12 4.4 Eksperiment Siden vi ønsket å teste prototypen vår opp mot dagens hjelpemidler gjennom å måle tidsbruk tok vi i bruk eksperiment som metode. Vi drøftet flere muligheter for hvordan vi kunne gjennomføre et eksperiment, og flere forslag ble forkastet grunnet praktiske begrensinger. Vi endte opp med et ganske komplekst eksperiment og besluttet derfor å dele det opp i to mindre eksperiment. Et av de gikk ut på å finne rom, imens det andre gikk ut på å avtale et møte. Alle oppgavene ble formidlet skriftlig Design Både observasjonen og spørreundersøkelsen viste at SMS var et foretrukket verktøy for å lokalisere og møte kontakter. Derfor ønsket vi å undersøke om MeetIn kunne gjøre det mer effektivt å finne kontakter i forhold til å benytte seg av SMS. Det falt da ganske naturlig å ha en kontrollgruppe som brukte SMS og en eksperimentgruppe som brukte MeetIn. Dermed sikret vi at målingene av de to hjelpemidlene var uavhengige av hverandre og eliminerte læringseffekter som kunne ha oppstått hvis samme deltakere hadde gjennomført samme oppgaver med begge verktøyene. SMS er derimot til liten hjelp for å finne et rom. Derfor besluttet vi at kontrollgruppen for det første eksperimentet ikke skulle bruke noe annet hjelpemiddel enn de som var tilgjengelige i bygningen. Det ble altså between- group design for begge eksperimentene (Lazar, Feng & Hochheiser, 2010 : 49) Sted Stedet for eksperimentene var tredje etasje i Ole- Johan Dahls hus, som er en av bygningene ved Institutt for Informatikk. Som en prototype var det kun denne etasjen som applikasjonen støttet med kart. Dette førte til at eksperimentet ikke ble gjennomført i et kontrollert miljø, noe som økte risikoen for bias. Dette diskuteres nærmere i punkt Utvalg Vi vurderte muligheten til å teste på brukere som aldri hadde vært på Institutt for Informatikk tidligere, men det viste seg å bli for komplekst og ressurskrevende med tanke på rekruttering og organisering. Vi valgte derfor å kun inkludere studenter fra Institutt for informatikk, siden de er vår målgruppe og primærbrukerne av applikasjonen. Vi prøvde å la utvalget være så representativt som mulig, og ønsket å ha en variasjon i alder, kjønn og antall år studert på Institutt for informatikk. Utvalget ble valgt ut i fra convenience sampling (Rodgers, Sharp &, Preece, 2011: 224) for å spare tid Side 12 av 20

13 på rekrutteringsprosessen. Tilsammen var det 32 deltakere som deltok i eksperimentene Eksperiment 1 - Finn rom Research spørsmål: Går det raskere å bruke applikasjonen MeetIn for å finne rom enn å gjøre det uten ekstra hjelpemiddel? Uavhengige variabler: Verktøy for å lokalisere rom (MeetIn eller ingenting). Avhengige variabler: Tidsbruk. H0: Det er ingen forskjell i tidsbruk mellom å bruke MeetIn eller ingenting for å finne et rom. H 1: Det er en forskjell i tidsbruk mellom å bruke MeetIn eller ingenting for å finne et rom. Design av eksperimentet: Til det første eksperimentet målte vi tiden deltakerne brukte for å finne et spesifikt rom. Den ene halvdelen fikk i oppgave å finne rommet Ada, imens den andre halvdelen skulle finne rommet Euclid. Plassen der deltakerene startet hadde lik avstand til hver av rommene slik at resultatene kunne måles opp imot hverandre i enheten tid. Deltaker leter etter rom Eksperiment 2 - Avtale møte Research spørsmål: Går det raskere å bruke applikasjonen MeetIn enn SMS for å avtale møte? Uavhengige variabler: Verktøy for å avtale møte (MeetIn eller SMS). Avhengige variabler: Tidsbruk. H 0: Det er ingen forskjell i tidsbruk mellom å bruke MeetIn eller tekstmeldinger for å avtale et møte. H1: Det er en forskjell i tidsbruk mellom å bruke MeetIn eller tekstmeldinger for å avtale et møte. Design av eksperimentet: Til det andre eksperimentet målte vi tiden det tok for deltakeren på Euclid å arrangere et møte på Euclid med den andre deltakeren. Grunnen til at vi testet med to deltakere Side 13 av 20

14 samtidig var at vi ikke klarte å spesifisere en representativ svartid på meldinger som vi måtte hatt hvis de skulle ha opprettet møtet med en fiktiv person Piloteksperiment I forkant av de faktiske eksperimentene gjennomførte vi flere piloteksperimenter. Her undersøkte vi blant annet om lengden på eksperimentene påvirket deltakerne, at strukturen var god eller om det var noe vi hadde glemt. Vi måtte gjennomføre nye piloter helt til vi var fornøyde med designet av eksperimentene. Det ble tilsammen seks piloteksperimenter Formidling av informasjon Til alle oppgavene i eksperimentene ble instruksjonene formidlet skriftlig til deltakerne. Dette var for å sikre at alle deltakerne fikk den samme informasjonen. Siden vi likevel ønsket å gi en muntlig introduksjon til deltakerne, passet vi på at det da var den samme personen som snakket til alle deltakerne Training session For å minimere risikoen for bias forårsaket av at deltakerne hadde kjennskap til SMS fra før, gjennomførte vi en training session med alle deltakerne som testet MeetIn. De fikk utdelt en skriftlig guide, og en instruksjon om å opprette et møte og utforske applikasjonen på egenhånd. Deltaker gjennomfører training session Random assignment. For å randomisere eksperimentene slo vi kron og mynt for å bestemme hvilket rom og hvilke oppgaver hver deltaker skulle gjennomføre. Eksperimentene var kvasi- eksperimenter siden utvalget og rekkefølgen av deltakere ikke var randomisert Kvalitativ data. Under eksperimentene observerte vi deltakerne. Dette gjorde vi for å samle inn mer informasjon om hvordan grensesnittet og funksjonaliteten påvirket brukerne, noe som egner seg bedre for kvalitative metoder. Observatøren kunne stille spørsmål til deltakerne etter eksperimentet, men under eksperimentet tillot vi ikke spørsmål for å unngå bias Belønning av deltakelse. Som kompensasjon fikk alle som deltok en termokopp fra Accenture. Side 14 av 20

15 Resultater fra eksperimentet Valg av metode for analyse. Siden det opprinnelige eksperimentet ble delt opp i to mindre eksperiment endte vi opp med to datasett. For hvert sett hadde vi en uavhengig variabel med to conditions. Derfor valgte vi å analysere begge med Independent- sample T test (Lazar, Feng & Hochheiser, 2010 : 76). Vi brukte verktøyet SPSS for å analysere data fra eksperimentet. Deskriptiv statistikk Gjennomsnittsverdiene fra eksperimentene tyder på at det gikk raskere for gruppen som brukte MeetIn for å finne rom, mens det gikk raskere for gruppen som brukte SMS for å avtale møte. Derimot var spredningen generelt sett ganske stor for alle de avhengige variablene. Det var større spredning på verdiene fra kontrollgruppen enn eksperimentgruppen i det første eksperimentet, der deltakerne skulle finne rom. I det andre eksperimentet var det omvendt. For å virkelig kunne si noe om forskjellen mellom gruppene i de to eksperimentene er det ikke nok å sammenligne gjennomsnittsverdier. Vi måtte først finne ut om sannsynligheten for denne forskjellen var tilfeldig eller signifikant (Lazar, Feng & Hochheiser, 2010 : 75). Eksperiment 1: Group Mean Median SD Variance Mode Range 1 - Ingenting 78, , , (Meetin) 67,5 68,5 10,59 112, Eksperiment 2: Group Mean Median SD Variance Mode Range 1 SMS 157, ,28 857, MeetIn 178, , Independent- sample T test Eksperiment 1: t(30) = 1.122, p = Eksperiment 2: t(11.955) = , p = I begge tilfeller er p > 0.05 som er grensen for 95% statistisk sikkerhet (Lazar, Feng & Hochheiser, 2010 : 78). Testene viser altså at det ikke var noen statistisk signifikant forskjell mellom eksperimentgruppen og kontrollgruppen, hverken når det gjaldt å finne rom eller å opprette møte. For å unngå Type I feil burde vi derfor ikke forkaste null- hypotesene for eksperimentene (Lazar, Feng & Hochheiser, 2010 : 32-33). Det finnes mange tenkelige årsaker til hvorfor forskjellene ikke var signifikante. Den største årsaken er antakeligvis at det var meget stor spredning i de fleste datamengdene. For eksperiment 1 var også variasjonen helt tilfeldig for de deltakerne som ikke visste Side 15 av 20

16 hvor rommet lå. Dette ettersom at de startet i midten av gangen og da hadde 50% sjanse for å gå i riktig retning. De som brukte applikasjonen hadde derimot ikke dette problemet siden de kunne bruke kartet. Dette gjorde at data fra kontrollgruppen ikke ble normalfordelt og man kan dermed heller ikke forvente et signifikant resultat siden parametriske tester som denne egentlig forutsetter normalfordelt data (Lund Research Ltd, 2013). Et lignende problem oppstod med eksperimentgruppen i eksperiment 2. Siden applikasjonen hadde lang responstid, særlig på den eldre av de to mobilene 8 som ble brukt. Vi håndterte dette gjennom å dele ut mobiltelefonene tilfeldig til deltakerne. Det vi ikke regnet med var at noen av deltakerne ble usikre grunnet den langsomme responsen og dermed trykket for mange ganger, noe som gjorde at det ble feil og at de måtte begynne på nytt. Det forårsaket at det tok mye lengre tid for enkelte deltakere å gjennomføre denne oppgaven. Dette burde derimot ses mer som en systematisk feil (Lazar, Feng & Hochheiser, 2010 : 57-63) Resultater fra observasjon For å analysere data vi samlet inn fra observasjon under eksperimentet diskuterte vi og noterte de mest sentrale punktene. Noen ting som gikk igjen var at flere av deltakerne prøvde å snu telefonen og forventet at kartet skulle snu samme vei, at skriften var for liten, og at mange av deltakerne ble utålmodige av den lange responstiden til applikasjonen, noe som førte til at de gjorde feil og måtte starte oppgaven på nytt igjen. Training sessionen som ble holdt før eksperimentet var altså ikke tilstrekkelig for at brukerne skulle bli vant til applikasjonen. I eksperiment 1 der deltakerne skulle finne rom kom kontrollgruppen mye raskere i gang med å lete etter rommet. De som brukte applikasjonen derimot sjekket alltid den først for å se på kartet hvor rommene var, noe som gjorde at de brukte mer tid på å komme i gang med letingen. Ingen av de som brukte applikasjonen gikk feil vei, mens noen av deltakerne i kontrollgruppen gjorde det Pålitelighet Etter å ha planlagt og gjennomført eksperimentene innså vi hvor vanskelig dette var uten at målingene ble påvirket av fluktuasjoner i form av både tilfeldige og systematiske feil (Lazar, Feng & Hochheiser, 2010 : 57-63). De tilfeldige feilene, som diskuteres i punkt , hadde sannsynligvis kunnet reduseres gjennom flere målinger. Dette hadde derimot ikke vært nok for å hevde pålitelige resultater siden vi også oppdaget en del systematiske feil. En av disse var valg av sted, siden vi gjennomførte eksperimentet i omgivelser som ikke var kontrollerte. Ettersom området ikke var avstengt for andre, kunne det skje at deltakerne ble distrahert av bekjente de møtte på, eller at de måtte gå korte omveier på grunn av at det 8 Vi brukte en iphone 4s og en iphone 5s siden de var de eneste mobilene vi hadde med en ios- versjon som støttet applikasjonen. Side 16 av 20

17 var mange andre som gikk i gangen. Det er også mulig at noen av deltakerne kan ha sett andre gjennomføre eksperimentet, eller at de som kjente hverandre snakket med sammen om eksperimentet i etterkant, noe som kan ha ført til at de visste hele eller deler av oppgavene på forhånd. Vi kunne ha motvirket mye av dette gjennom å gjennomføre eksperimentet på kveldstid eller over en helg, men da ville det sannsynligvis ha vært vanskeligere å rekruttere deltakere. Bygningens arkitektur påvirket også deltakernes valgmuligheter. Siden etasjen var rektangulær hadde de maksimalt to valg når de skulle finne rom og kun et valg når de skulle møte hverandre. Dette hadde ikke vært tilfelle hvis man introduserer flere etasjer eller ganger i miljøet. Derfor skiller dette seg mye ifra virkeligheten, noe som gjør at det er vanskelig å gjenta eksperimentet i andre miljøer. Dermed burde vi kanskje heller ha benyttet oss av andre rom eller flere etasjer for å få mer representative målinger. Valg av rom påvirket også målingene siden noen deltakerne kjente til rommene godt fra før av. Illustrasjon over 3. etasje på OJD For å minimere bias fra oss som ledet eksperimentet prøvde vi å unngå å snakke med deltakerne under selve eksperimentet. Likevel tok vi oss selv på å kommentere responstiden til applikasjonen eller å svare på spørsmål som deltakerne stilte. I ettertid ser vi at det kunne vært nyttig med flere omfattende pilottester før vi gjennomførte eksperimentet. Da kunne flere systematiske feil vært unngått. Vi fikk likevel samlet inn mye data under eksperimentene, og det var en lærerik prosess for oss. 5. Etiske aspekter ved prosjektet I dette kapittelet diskuterer vi etiske aspekter som integritet og informert samtykke i forbindelse med prosjektet. 5.1 Integritet At vi deler informasjon med hverandre på en helt annen måte enn for år siden er ikke helt uten komplikasjoner. På samme måte som at internett forenkler vårt daglige liv gjør det det også enklere for folk med uetiske hensikter. En slik hensikt som er spesielt relevant i forhold til prosjektet vårt er et fenomen som kalles cyberstalking (Hamid & Maple 2013). Allerede tidlig i designprosessen la vi derfor vekt på beskytte integriteten og privatlivet til brukerne. Undersøkelsene våre viste også at brukerne prioriterte dette høyt, så vi Side 17 av 20

18 implementerte en funksjon som gjorde det mulig å skjule sin egen posisjon ved å sette status til inkognito. Vi besluttet også at kun brukernes kontakter skulle kunne se informasjonen deres slik at dette var noe som måtte godkjennes av begge parter. Dette for at brukerne selve skulle ha kontrollen over sin eksponering i applikasjonen. Dessverre er ikke dette nok til å beskytte brukerne helt fra cyberstalking. Forskning viser at mange som faller offer for denne typen av krenkelse har, eller har hatt en nære relasjon med forbryteren, for eksempel en partner eller ekspartner (U.S. Department of Justice 1998). Noen er dessuten kanskje helt uvitende om at de forfølges. Hvis et slikt offer blir overvåket av en kontakt i applikasjonen er det veldig vanskelig, til og med umulig å forhindre dette. En annen, ganske uforutsett konsekvens er at inkognito- funksjonen kanskje kan anvendes til fordel for stalkers. De ville kunne utnytte dette til å se informasjon om offeret og samtidig være helt usynlige. 5.2 Informert samtykke Siden vi jobbet mye med mennesker gjennom hele prosessen la vi stor vekt på at de skulle føle seg trygge og at verdien av deltakelsen deres skulle reflekteres i hvordan de ble behandlet. For å sikre at de kunne gjøre et meningsfylt valg om å delta i studiene laget vi samtykkeskjemaer der vi informerte om formålet med undersøkelsen, anonymitet og frivillighet (Lazar, Feng & Hochheiser 2010). For at et samtykkeskjema innen forskning skal være gyldig, må skjemaet også oppfylle visse nasjonale krav. Vi har derfor undersøkt NSD sine krav til samtykke (NSD, 2012) og forholdt oss til disse i forbindelse med prosjektet. 6. Videre muligheter I vårt studie har vi hatt fokus på studenter ved Institutt for Informatikk, men vi ser mange muligheter for å implementere MeetIn i andre kontekster. I løpet av prosjektperioden har det vært begrenset med tid, men vi skulle gjerne jobbet videre med utvikling og design av applikasjonen. 6.1 Overførbarhet I og med at vi hadde et samarbeid med Accenture var det ønskelig at løsningen skulle være overførbar til en setting der de kunne gjenbruke den. Accenture ønsker for eksempel å teste dette på kontorene sine i Fornebu. Selv om vårt fokus var på studenter ved Institutt for Informatikk, er konseptet fullt mulig å overføre til en andre settinger. Andre potensielle use- cases kunne vært på konserter og festivalområder hvor mange mennesker befinner seg over et stort område der det er mye lyd og støy. Dette kan gjøre det utfordrende å finne og kontakte sine venner ved å for eksempel ringe. Ved hjelp av MeetIn vil man kunne se sine venners lokasjoner på et kart over konsert- eller festivalområdet. Med denne løsningen vil kan man finne og møte de på en enklere måte Side 18 av 20

19 6.2 Veien videre Et naturlig steg videre ville ha vært å bruke resultatene fra eksperimentet for å videreutvikle applikasjonen og deretter jobbe videre med å implementere flere funksjoner fra backlogen (se punkt 3.3). Eksempel på slike funksjoner er push notifikasjoner og flere kart. Videre utvikling av applikasjonen ville også medført bedre muligheter for tilrettelegging mot WCAG- kravene. En viktig forbedring ville vært å følge punkt 1.4.8, Visuell presentasjon, ved å velge en tydeligere font med mulighet for å gjøre tekstene større. Punkt 1.3.3, Sensoriske egenskaper, ville vært relevant til implementering av en instruksjon for hvordan man betjener applikasjonen slik at nye brukere raskere kan lære seg funksjonaliteten. Etter dette ville det vært interessant å teste applikasjonen med brukere i naturlige omgivelser. En slik studie ville vært nyttig for å få en detaljert forståelse for hvordan brukere ville benyttet applikasjonen i spesifikke kontekster og finne eventuelle svakheter ved produktet (Lazar, Feng & Hochheiser, 2010 : 144). 7. Konklusjon Etter gjennomføringen av dette prosjektet sitter vi igjen med mye nyttig kunnskap. Samarbeidet med Accenture ga oss mulighet til å jobbe smidig gjennom Scrum og ga oss et unikt innblikk i hvordan det er å jobbe med interaksjonsdesign i praksis. Utviklingen av applikasjonen samt at vi fikk testet ny teknologi som ibeacons ga oss ny teknisk erfaring. Å jobbe tett med brukere gjennom evalueringsprosessen viste seg å være lærerikt for å forstå hvordan brukere tenker, og eksperimentet ga oss en smakebit av hvor utfordrende og omfattende slike studier kan være. Side 19 av 20

20 Sett opp mot målet i punkt 1.1, og scenarioet vi definerte i punkt 3.1, har vi et produkt som oppfyller dette ved at man kan lokalisere sine kontakter på en effektiv måte. De viktigste funksjonene fra kravspesifikasjonen er implementert og evaluert av brukere. Som en high fidelity prototype har applikasjonen vært brukbar til evaluering i form av summativ testing og eksperiment. Alt i alt er vi veldig fornøyde med dette prosjektet og det gode samarbeidet som vi har hatt med Accenture. Kilder Trykte Hamid, T. & Maple, C. (2013) Online Harassment and Digital Stalking: International Journal of Computer Applications, 2013 (Volume 76- No.12) August. Houde, S. & Hill, C. (1997) Hanbook of Human- Computer Interaction: What do prototypes prototype. 2. utg. Amsterdam, Elsevier. Kopetz, H. (2011) Real- Time System: Design Principles for Distributed Embedded Applications. 2. utg. Springer. Lazar, F. Feng F. & Hochheiser F. (2010) Research Methods in human- computer interaction, 1. utgave. West Sussex, John Wiley & Sons Ltd. Maeda, John (2006) The Laws of Simplicity, 1. utg. Massachusetts, MIT Press. Makkonen, J.Avdouevski, I. Kerminen, R. & Visa, A. (2009) Human Computer Interaction: Context Awareness in Human- Computer Interaction, Inaki Maurtua utg. Tampere, InTech. Rogers, F. & Sharp, F. & Preece F. (2011) Interaction Design: beyond human- computer interaction, 3. utg. West Sussex, John Wiley & Sons Ltd. Sommerville, I. (2014) Software Engineering, 9. utgave. Pearson Education Limited Toftøy- Andersen & Wold (2011) Praktisk brukertesting, 1 utgave. Cappelen Damm. U.S Department of Justice (2013) Stalking and Domestic violence. Violence Against Women, :03 Washington, D.C, Office of Justice Programs U.S Department of Justice. Internett Apple Inc. (2014) Getting started with ibeacons [Internett], Apple Inc. Tilgjengelig på: < Started- with- ibeacon.pdf> [Lest 1. september 2014] Apple Inc. (20. oktober 2014) ios Human Interface Guidelines [Internett], Apple Inc. Tilgjengelig på: < [Lest 10. september 2014] Lund Research Ltd (2013) Independent t- test using Stata [Internett], Lund Research Ltd. Tilgjengelig på: < tutorials/independent- t- test- using- stata.php >[Lest 13. november 2014] Norsk Samfunnsvitenskapelige Datatjeneste (2014) Krav til samtykke [Internett], NSD. Tilgjengelig på: < [Lest 15. oktober 2014] World Wide Web Consortium (11. desember 2008) Web Content Accessibility Guidelines (WCAG) 2.0 [Internett] W3C. Tilgjenlig på: < [Lest 11. september 2014] Side 20 av 20