Sluttdokumentasjon. Hovedprosjekt i Anvendt Datateknologi Høgskolen i Oslo og Akershus Våren 2013

Transkript

1 Sluttdokumentasjon Hovedprosjekt i Anvendt Datateknologi Høgskolen i Oslo og Akershus Våren 2013 Prosjektnummer Simon Pettersen Nguyen Richard Olav Rud

2 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Prosjektnummer Tilgjengelighet Åpen Telefon: Telefaks: Hovedprosjekt Hovedprosjektets tittel eyecatch Dato Antall side / Bilag 92 Prosjektdeltakere Simon Pettersen Nguyen Richard Olav Rud Intern veileder Kirsten Ribu Oppdragsgiver Lars Klintwall Kontaktperson Lars Klintwall Sammendrag Hensikten med dette prosjektet er å lage en applikasjon til nettbrett for barn med autisme. Applikasjonen skal trene barn med autisme til å følge blikk. Innen atferdsforskning kalles prinsippet felles oppmerksomhet. Applikasjonen benytter seg av metodene i Discrete Trial Teaching til å forbedre deres evne innen felles oppmerksomhet. I dette prosjektet ble behovet til oppdragsgiver kartlagt og analysert og resultatet er en applikasjon med navet eyecatch. De ulike prosessene er dokumentert i denne sluttdokumentasjonen. Stikkord Applikasjon Atferdsvitenskap Autisme 2

3 Forord Denne sluttrapporten dokumenterer et hovedprosjekt for to studenter i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Vi vil spesielt takke oppdragsgiver Lars Klintwall for å ha gitt oss muligheten til å jobbe med dette prosjektet. En stor takk går også til veileder Kirsten Ribu som gjorde oss oppmerksom på prosjektet og som samtidig har veiledet oss igjennom prosjektprosessen. 3

4 Sammendrag Psykolog og stipendiat Lars Klintwall er oppdragsgiver for dette hovedprosjektet. Hensikten med dette prosjektet har vært å utvikle en applikasjon til nettbrett med Android som operativsystem. Applikasjonen er utviklet ved bruk av rammeverket Apache Cordova. Oppdragsgiver ønsker med denne applikasjonen å trene felles oppmerksomt hos barn med autisme. Applikasjonen baserer seg på en intervensjonsmetode innen atferdsvitenskap som kalles Discrete Trial Teaching, hvor man benytter belønninger som motivator for trening. Oppdragsgiver vil kunne bruke denne applikasjonen til å teste intervensjonsmetoden i stort omfang og kartlegge nytteverdien ved å benytte Discrete Trial Teaching i form av en applikasjon på nettbrett. 4

5 Innholdsfortegnelse Forord... 3 Sammendrag... 4 Innholdsfortegnelse... 5 Figurliste Kapittel 1 Introduksjon Innledning Oppdragsgiver Oppgavebeskrivelse Prosjektgruppen Dagens situasjon Kapittel 2 Mål og rammebetingelser Mål for oppdragsgiver Mål for prosjektgruppen Rammebetingelser Kapittel 3 Bakgrunn Hva er Autisme Hvilken sammenheng står arbeidet i, og hva kan man sammenligne med? Atferdsanalyse Diagnose og intervensjon Tidligere fremgangsmetode og arbeider Felles oppmerksomhet Intervensjon Positive forsterkere Discrete Trial Teaching Nytteverdi Kapittel 4 Kravspesifikasjon Systemkrav Funksjonskrav Spillsekvens

6 4.2.2 Generelle funksjonskrav Tekniske krav Krav til design Krav til kode Krav til dokumentasjon Fremtidig utvidelse av systemet Samsvar mellom kravspesifikasjon og produkt Nye krav: Ikke oppfylte krav: Kapittel 5 Teknologier Utviklingsplattform Utviklingsteknologier Apache Cordova Lagring: W3C Web SQL Database og W3C Web Storage Twitter Bootstrap JavaScript, jquery og jquery Mobile HTML5 og CSS Google Chart API YouTube API Utviklingsverktøy Eclipse og Android SDK Git Samsung Galaxy Tab Tekniske hjelpemidler Dropbox Google Drive Prototyping: Microsoft Power Point og Libre Office Presentation Google Scholar Adobe Photoshop Colour Contrast Check

7 Kapittel 6 Prototyping Papirprototype Interaktiv prototype Kapittel 7 Designvalg og brukergrensesnitt Håndbasert input - touch teknologi Layout, utforming og generell struktur Gjenkjennbarhet og mentale modeller Tilbakemelding til brukeren Menyvalg Tekstvalg Fargevalg Bilde og ikonvalg Lyd Universell utforming Brukermanual Logovalg- EyeCatch Design av spillsekvensen Design prinsipp for intervensjonsmetoden Discrete Trial Teaching Valg av objekt - hvorfor er objektet en boks? Valg av ansikt Valg av video som positiv forsterker Mestringskriterium Tid per forsøk Ulike nivåer Tester Trykktrening Kapittel 8 Testdokumentasjon Planlegging av hvem, hva, hvor og når Testresultater - Problemer og løsningsforslag Test utført av oppdragsgiver

8 8.2.2 Brukertesting på voksene utført av prosjektgruppen Resultat av brukertester Kapittel 9 Produktdokumentasjon Formål Omfang Brukere av produktdokumentasjonen Ekstern dokumentasjon Program Beskrivelse Applikasjonens struktur Applikasjonens oppbygning index.html selectuser.html newuser.html deleteuser.html selectvideo.html touchtraining.html statisticstests.html og statisticslevels.html userguide.html test.html levela.html til levelh.html (nivåer) done.html Systemkrav Plattform Operativsystem Lagring Installasjonsveiledning Kapittel 10 Prosjektprosessen Planlegging og forberedelser Valg av oppdragsgiver Analyse og kartlegging

9 Forkunnskaper Arbeidsmetode Arbeidsplan og fremdriftsplan Risikohåndtering Tilegnelse av ny kunnskap Utviklingsprosessen Produksjon av kravspesifikasjon Utfordringer Evaluering av prosjektprosessen Kapittel 11 Konklusjon og videre arbeider Kilder og litteraturliste Vedlegg Vedlegg 1: Brukermanual Vedlegg 2: Interaktiv prototype Vedlegg 3: Task Cards Vedlegg 4: Testresultater Vedlegg 5: Intervju Vedlegg 6: Samtykkeerklæring Vedlegg 7: Arbeidsplan Vedlegg 8: Fremdriftsplan Vedlegg 9: Risikoplan Vedlegg 10: Avtale med oppdragsgiver Vedlegg 11: YouTube-kode

10 Figurliste Figur 1: Illustrasjon av felles oppmerksomhet s.17 Figur 2: Utdrag fra papirprototypen s.31 Figur 3: Eksempelbilder fra den interaktive prototypen s.32 Figur 4: Input validering s.35 Figur 5: Menyvalg s.36 Figur 6: Resultat fra Color Contrast Checker s.37 Figur 7: Filhåndtereren s.38 Figur 8: Brukermanual s.39 Figur 9: Før og etter bilde av treffområdet s.40 Figur 10: Ansiktet uklart utenom øynene s.41 Figur 11: Applikasjonens lagdelte struktur s.47 Figur 12: Applikasjonens oppbygning s.47 Figur 13: Menyvalg s.48 10

11 Kapittel 1 Introduksjon 1.1 Innledning Dette er en sluttrapport for et hovedprosjekt i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus (HiOA), Fakultet for teknologi, kunst og design. Hovedprosjektet er gjennomført av Richard Olav Rud og Simon Pettersen Nguyen våren Denne sluttrapporten omhandler i korte trekk kartleggingen, utviklingen og brukertestingen av prosjektet og applikasjonen. 1.2 Oppdragsgiver Oppdragsgiver Lars Klintwall er psykolog og doktorgradsstipendiat ved Institutt for atferdsvitenskap ved HiOA. Klintwall forsker på barn med autisme og jobber for tiden med en doktorgrad i atferdsvitenskap. Han har også tidligere samarbeidet med studenter ved HiOA ved Fakultet for teknologi, kunst og design, med utvikling av en applikasjon for å påvise autisme i tidlig alder. Klintwall befinner seg for tiden på Yale University i USA hvor han har et forskningsstipend ved Yale Child Study Center. Klintwall vil befinne seg der frem til sommeren Oppgavebeskrivelse Det skal utvikles et spill til nettbrett som skal brukes i intervensjon av barn med autisme. Spillet bygger på prinsipper innenfor for atferdsforskning og skal trene barn med autisme innenfor det som kalles felles oppmerksomhet. Felles oppmerksomhet omhandler evnen til å dele oppmerksomhet med andre mennesker i forhold til et objekt. 1.4 Prosjektgruppen Denne prosjektgruppen består av to personer henholdsvis Simon Pettersen Nguyen og Richard Olav Rud. Begge studerer Anvendt Datateknologi ved HiOA og har samarbeidet på tidligere prosjekter under studiene. Vi har begge interesse for utvikling av applikasjoner på mobile enheter og har gjennom dette prosjektet bygget videre på tidligere kunnskaper innen blant annet webutvikling, databaser og menneske-maskin-interaksjon. 11

12 1.5 Dagens situasjon Klintwall har tidligere samarbeidet med studenter ved HiOA våren Det ble utviklet en applikasjon for å prøve å påvise autisme hos barn i tidlig alder. Denne applikasjonen testes i dag av studenter med tilknytning til fakultet. Klintwall ønsker nå å utvikle et spill på nettbrett for å prøve å trene barn med autismes evne til å følge blikk og dele oppmerksomheten med andre mennesker i forhold til et objekt (felles oppmerksomhet). 12

13 Kapittel 2 Mål og rammebetingelser 2.1 Mål for oppdragsgiver For oppdragsgiver har målet med dette prosjektet vært: Å utvikle en applikasjon for barn med autisme. Applikasjonen skal være et verktøy for å forbedre atferden i forhold til felles oppmerksomhet. Applikasjonen som skal utvikles skal inneholde interaktive bikkøvelser som barn med autisme kan bruke til å trene opp blikk-kontakt mellom seg selv og andre personer, slik at de lettere kan dele oppmerksomheten i forhold til et objekt i den virkelige verden. Applikasjonen skal benytte seg av intervensjonsmetoden Discrete Trial Teaching til å forbedre barn med autismes evne til felles oppmerksomhet. Applikasjonen skal gjøre det mulig å skaffe testresultater i stort omfang. Applikasjonen skal enkelt kunne distribueres. 2.2 Mål for prosjektgruppen Som prosjektgruppe har vi hatt følgende mål: Tilegne oss kunnskaper innen webteknologier og applikasjonsutvikling samt bygge videre kunnskaper innen menneske-maskin-interaksjon. Skaffe til veie prosjekterfaring hos en ekstern oppdragsgiver. Avslutte en bachelor i Anvendt Datateknologi. 2.3 Rammebetingelser Prosjektet hadde følgende rammebetingelser: Applikasjonen skulle utvikles for Android. Applikasjonen skulle i hovedsak utvikles til Samsung Galaxy Tab 2. Prosjektet skulle ferdigstilles 28. mai. 13

14 Kapittel 3 Bakgrunn 3.1 Hva er Autisme Autisme er en utviklingsforstyrrelse og finnes i ulike former og alvorlighetsgrader. Mennesker med autisme har en annen opplevelse av verden rundt, enn det som i dag regnes som vanlig. Sett ut i fra et biologisk perspektiv, så mener Bongard og Røskaft (2010) at autisme kan være skader i modulen som prosesserer inntrykk ment for bevisstheten og/eller underbevisstheten. Dette fører til at bevisstheten forsøker å ta inn for mye eller for lite informasjon per sekund. Vi er helt avhengige av å kunne sile ut inntrykkene vi mottar i det daglige til det minimale, slik at bevisstheten kan behandle disse inntrykkene. Gal siling av informasjon, som for eksempel for mye eller for lite, kan koble assosiasjoner som ikke gir mening. Dette kan føre til overdreven interesse for spesielle detaljer som igjen ofte fører til distansering og uoppmerksomhet. Vårt prosjekt går ut på å lage et spill for barn med autisme, og vi vil derfor fokusere på barn med autisme når vi videre i dette kapittelet redegjør for den teoretiske bakgrunnen. Barneautisme defineres som:...en alvorlig og gjennomgripende utviklingsforstyrrelse som preger barnet i alle livets situasjoner. Autisme preges særlig av avvikende utvikling innenfor kommunikasjon, sosial interaksjon og begrensede og repetitive interesser. (Hernes og Larsen 2012, 28) Barneautisme kategoriseres i ICD 10. ICD 10 er en liste laget av World Health Organization (WHO) over ulike sykdommer og forstyrrelser. Autisme og da spesielt barneautisme som vi fokuserer på i denne oppgaven regnes som en utviklingsforstyrrelse som defineres i kapittel F80-F89, nærmere bestemt F84.0 (Helsedirektoratet 2013). Nærmere karakteriseres barneautisme av WHO (oversatt av Helsedirektoratet) som: F84.0 Barneautisme Gjennomgripende utviklingsforstyrrelse som defineres ved: a) Avvikende eller forstyrret utvikling som er manifestert før tre års alder. 14

15 b) Karakteristisk unormal fungering som ytrer seg ved forstyrrelser i sosialt samspill og kommunikasjon samt begrenset, stereotyp, repetitiv atferd. I tillegg til disse spesifikke diagnostiske trekkene er det vanlig med en rekke andre ikke-spesifikke problemer, som fobier, søvn- og spiseforstyrrelser, raserianfall og selvdestruktiv atferd. Inkludert: Autistisk forstyrrelse i barndommen Infantil autisme Infantil psykose Kanners syndrom Ekskludert: Autistisk psykopati, kjent som Aspergers syndrom (F84.5). 3.2 Hvilken sammenheng står arbeidet i, og hva kan man sammenligne med? Atferdsanalyse Før 1970-tallet hadde man liten tro på at det var mye som kunne forbedres ved utviklingspotensialet til barn med autisme. På 70-tallet ble det derimot brukt prinsipper fra atferdsanalyse til å prøve å endre atferden til personer med autisme (Hernes og Larsen 2012, 19). Atferdsanalyse defineres som: Atferdsanalyse prøver å forstå atferd ved å bruke analyseprinsipper som baserer seg på læringspsykologisk forskning. Prinsippene brukes for å forebygge og behandle atferd. (Skre, Ingunn B. Store norske leksikon ) I følge Lovaas (1987) er atferdsanalyse i dag det beste verktøyet for å kunne behandle og tilby barn med autisme opplæring (sitert av Hernes og Larsen 2012, 20). 15

16 3.2.2 Diagnose og intervensjon Når det gjelder autisme er det viktig å identifisere diagnosen tidlig (Hernes og Larsen 2012, 28), dette er viktig for å komme tidlig i gang med intervensjoner. I følge Hernes og Larsen (2012) viser tidlig intervensjon gode resultater hos barn med autisme som også underbygges av atferdsanalytikeren Gina Green et al. (sitert av Hernes og Larsen 2012), som også peker på god effekt ved intervensjon i tidlig alder. For barn med autisme er det vanskelig å forstå sosial interaksjon, noe som også gjør det vanskelig å delta i sosiale situasjoner i følge Volkmar et al. og Dawson et al. (sitert av Hernes og Larsen 2012, 23). Barn med autisme har også ofte vanskeligheter med å lære språk. Ifølge Hernes og Larsen (2012) er det derfor ofte nødvendig at barn med autisme læres med intensiv og forsterkende atferd og tydelig respons fra omgivelsene. Mye tyder på at respons fra foreldre og personer nært knyttet til barnet har en stor effekt i forbindelse med tidlig intervensjon. Tidligere forskning har vist at de fleste barn i tidlig alder følger voksene personers blikk og at denne atferden er en viktig faktor for tidlig utvikling hos barnet (Matsuda og Omori 2001). Som følger av dette vil det å stimulere barnet til å opprette blikk-kontakt med andre mennesker være en viktig del av intervensjon i tidlig alder Tidligere fremgangsmetode og arbeider Eye tracking har tidligere blitt mye brukt for å kartlegge blikk-kontakt hos mennesker som befinner seg innenfor autismespekteret og deres mangel på felles oppmerksomhet (Boraston og Blakemore 2007). Oppdragsgiver har sett på eye tracking som et verktøy innen opptrening av felles oppmerksomhet. Dette er dyrt og krever spesielt utstyr. Derfor har noe av tanken bak prosjektet vært å lage en applikasjon som kan lastes ned på et Android-nettbrett. Andre prosjekter har vært gjort på området med elektroniske hjelpemidler og felles oppmerksomhet. I forhold til dette så ble det gjort en studie av Cheng og Huang (2012) hvor det ble brukt elektroniske hansker i et virtuelt miljø for å lære barn felles oppmerksomhet, hvor barna brukt den virtuelle hansken som pekeredskap. Dette prosjektet var vellykket da de som deltok i undersøkelsene vist fremgang i sosiale ferdigheter og felles oppmerksomhet. Her ble det spesielt fremhevet at moderne datateknologi i mange tilfeller har vist positive effekter når det gjelder opplæring av barn med autisme (Cheng og Huang 2012). 16

17 Det har tidligere også vært utviklet en applikasjon til nettbrett hvor målet er å påvise autisme hos små barn. Applikasjonen ble laget våren 2012 av studenter ved HiOA, Fakultet for teknologi, kunst og design for Lars Klintwall, og skulle påvise autisme i tidlig alder ved å bruke ulike stimuli i form bilder og video. 3.3 Felles oppmerksomhet Felles oppmerksomhet kjennetegnes i korte trekk ved å dele oppmerksomhet med andre mennesker i forhold til et objekt og er en sentral komponent i mellommenneskelig kommunikasjon. Å trene barn med autisme til å følge blikk for å hente informasjon fra andre mennesker er ofte en prioritet. Mye av informasjonen hentes i blikket til andre personer og gode ferdigheter innen dette området er viktig i all type kommunikasjon, samhandling og opplæring, og er sentralt gjennom hele livet (Hernes og Larsen 2012, 98). Felles oppmerksomhet er en viktig forutsetning for å lære språk. Eksempelvis skjer dette ved at foreldre oppretter blikk-kontakt med barnet, for deretter å se på et objekt samtidig som den voksene gir uttrykk for hva dette objektet heter eller hva som er funksjonen til dette objektet. Denne handlingen utføres som regel ubevisst av foreldre, mens foreldre av barn med autisme ofte ville måtte tydeliggjøre slike handlinger. Figur 1: Illustrasjon av felles oppmerksomhet 17

18 Et konkret eksempel for å beskrive figur 1: 1. Den voksene personen ser på den oransje puslespillbrikken. 2. Deretter oppretter den voksene personen blikk-kontakt med barnet og sier Se, der er en oransje puslespillbrikke. 3. Hvis barnet deler felles oppmerksomhet i forhold til det felles objektet (puslespillbrikken), vil barnet assosiere objektet med dets beskrivelse. Felles oppmerksomhet er en grunnleggende sosial egenskap som fremmer læring. Manglende evne innenfor felles oppmerksomhet har en negativ innvirkning på menneskers evne til å kommunisere med andre og å fungere i sosiale sammenhenger (Hernes og Larsen 2012). Initiativ til og reaksjon på felles oppmerksomhet er nært knyttet opp mot utviklingen i sosiale ferdigheter for alle barn. Barn med autisme mangler i varierende grad denne evnen og vil derfor ha vanskeligheter med å forstå intensjonen bak kroppsspråk og kartlegge den mentale tilstanden til andre mennesker (Hernes og Larsen 2012). Studier viser at barn uten autisme utvikler evnen til felles oppmerksomhet i alderen 6 til 12 måneder. Da barn med autisme vanligvis mangler den naturlige utviklingen av denne evnen anses det av mange som sentralt å intervenere i tidlig alder hos barn med autisme (Hernes og Larsen 2012). 3.4 Intervensjon Som nevnt tidligere er det stor enighet om at intervensjon i tidlig alder er viktig ettersom evnen til felles oppmerksomhet typisk utvikles i alderen 6 til 12 måneder. Det skal nevnes at det er visse usikkerheter rundt tidlig intervensjon, da spesielt før barnet har fylt 2 år (Hernes og Larsen 2012), men forskning viser positive effekter av tidlig intervensjon i følge Dawson et al. (2010) (sitert av Hernes og Larsen 2012). Som følger av dette hersker det liten tvil om at intervensjon før barnet begynner på skolen har særlig positiv effekt for de fleste barn med autisme (Hernes og Larsen 2012). Det er en rekke behandlingsmuligheter for barn med autisme og ulike måter å tilnærme seg trening i forhold til atferd for barn med autisme. Det skal nevnes at trening av barn med autisme er et virkemiddel for å forbedre hverdagen til barnet og øke livskvaliteten til både barnet og omsorgspersonene rundt barnet. Trening av barn med autisme har som utgangspunkt å gjøre barnet mer selvstendig og gjøre det slik at barnet ikke trenger betydelig mer oppsyn av foreldre og personer rundt enn barn uten autisme. 18

19 Det er mer eller mindre felles enighet i fagmiljøet om at autisme ikke er noe som kan kureres (Hernes og Larsen 2012), og på bakgrunn av dette vil spillet vi har utviklet i samarbeid med oppdragsgiver, kun være et hjelpemiddel som skal hjelpe barnet med å trene opp atferden i sammenheng med felles oppmerksomhet. Hernes og Larsen (2012) anbefaler at det brukes etablerte intervensjonsmetoder. Metoder som har vist positive effekter og vært utprøvd i større grad har vært kartlagt av NAC - National Autism Center (2009) (sitert av Hernes og Larsen 2012). NAC nevner i sin rapport felles oppmerksomhetsintervensjon, noe som er utgangspunktet i denne oppgaven og teorien som ligger bak det spillet vi har utviklet Positive forsterkere Barn som ikke har en tilstrekkelig atferds strategi kan lære dette ved at man benytter inputsignaler og tilbyr barnet små belønninger som på fagspråket kalles positive forsterkere (Matsuda og Omori 2001). Positive forsterkere fungerer slik at hver gang barnet utfører det som regnes som riktig atferd så tildeles en belønning. Belønningen (den positive forsterkeren) kan for eksempel være i form av ros eller godteri. For at den positive forsterkeren skal ha en effekt forutsettes det følgende: Når det gjelder positive forsterkere er det viktig med variasjon og det bør kartlegges hvilke forsterkere som egner seg som opplæringsmaterialet for det enkelte barnet (Hernes og Larsen 2012). Dette er viktig fordi barn vil ha ulike preferanser når det kommer til hva de foretrekker som belønning. Vi har derfor fokusert på at den positive forsterkeren i dette prosjektet lett kan varieres. Barn med autisme lærer ofte dårligere og/eller saktere enn barn uten autisme under samme forhold. Lovaas (2003) (sitert av Hernes og Larsen 2012) nevner at det ved opplæring av barn med autisme ofte trengs flere repetisjoner for å mestre de ulike atferdsområdene. Vi har derfor fokusert på å skape et spill hvor det er rom for et stort antall repetisjoner under intervensjon. Det anbefales i dag at barn med autisme bør ha trening i timer per uke (Eldevik et al Sitert av Hernes og Larsen 2012). Ettersom dette er mange timer trening anbefales det at treningen er med på å skape motivasjon hos barnet (Hernes og Larsen 2012). Som 19

20 følger av dette er det et behov for trening som kan utføres av barnet selv, for eksempel når man er ute å kjører bil med barnet, er på kjøkkenet eller i lignende situasjoner Discrete Trial Teaching En sentral og ofte brukt opplæringsmetode hos barn med autisme er det som kalles Discrete Trial Teaching også kalt Discrete Trial Training. Discrete Trial Teaching (DTT) består av en oppgave som skal fremprovosere en atferd hos barnet. Innen DTT kan man for eksempel vise et bilde, komme med en instruksjon eller stille spørsmål. Deretter skal barnet utføre en respons på oppgaven som presenteres. Hvis responsen er feil i forhold til den gitte oppgaven, skal oppgaven presenteres på nytt for barnet, og deretter skal barnet få hjelp av en voksen til å løse oppgaven. En annen mulighet i DTT er å benytte seg av ulike mestringsnivåer hvor oppgavene blir vanskeligere ettersom barnet mestrer de ulike oppgavene. Vi har utviklet et spill som har ulike mestringsnivåer og som kontinuerlig kan utfordre barnet etterhvert som barnet mestrer de ulike nivåene. Fokuset på mestring tilsier at barn med autisme kun skal gjøre én feil før de får nok hjelp til å mestre oppgaven. Når barnet løser oppgaven uten hjelp, skal barnet få belønning i form av en positiv forsterker. At barnet får en positiv forsterker er viktig for å motivere barnet og har effekt på barnets atferd. En kort stund får barnet mulighet til benytte seg av den positive forsterkeren, for deretter og presenteres for en ny oppgave (Hernes og Larsen 2012, 104). DTT brukes spesielt i forbindelse med; opplæring av imitasjon, språkforståelse, talespråk, samtale og grammatikk. Det kan også nevnes at mange barn med autisme selv liker denne formen for opplæring, ettersom den er strukturert (Hernes og Larsen 2012, 104). Ved DTT vil treningen av barnet forgå på kun ett av de overnevnte områdene om gangen, i motsetning til i det virkelige liv hvor læring forgår som en sammensetning av de ulike områdene. Grunnen til at man lærer barnet en ting av gangen er for at barnet skal kunne lære seg områdene raskere og få en mestringsfølelse under treningen. Barn med autisme er en variert gruppe med individuelle forskjeller, noe som gjør det viktig å tilrettelegge opplæringen. Opplæringen bør tilpasses ferdighetsnivå og behov da barn med autisme har enkelte områder de er sterke på og andre som de er svake på (Hernes og Larsen 2012). 20

21 Som nevnt tidligere har nylige studier funnet ut at mange barn med autisme var mer interessert i å lære datamaskinbaserte oppgaver, og at datateknologi tilbyr muligheten til å trene ferdigheter med repetitive funksjoner (Cheng og Huang 2012). Forskning viser også at små barn kan oppfatte øye retning fra digitale bilder av voksene personer, og at barna kan skifte oppmerksomhet i forhold til hvilken øyeretning de digitale bildene fremviser (Matsuda og Omori 2001). 3.5 Nytteverdi Kommunikasjon er et viktig element i dagliglivet hos alle mennesker, og vi er alle avhengig av kommunikasjon for å kunne delta på alle nivåer i samfunnet. Kommunikasjon er viktig for å kunne fungere sammen med andre, for å forstå hvordan verden rundt oss fungerer, og hva andre mennesker ønsker å formidle til oss og omverden (Hernes og Larsen 2012, s.20). Prinsippene som vi benytter oss av i spillet er ikke nyskapende, men nytteverdien ligger i en overføring av disse prinsippene til en applikasjon som kan brukes av alle som har tilgang til et nettbrett. Dette vil føre til at mange enkelt har tilgang til et hjelpemiddel, samtidig som store mengder av data enkelt kan samles inn fra alle steder rundt om i verden. Dette betyr at prinsippene kan testes ut i stor skala, og gi en indikasjon på om denne formen for intervensjon underbygger eksiterende forskning. Videre kan det påvises om applikasjonen har nytteverdi i seg selv i form av at den bidrar til å bedre barn med autisme sin evne til felle oppmerksomhet. Nytteverdien av et spill som er spennende å bruke for barn med autisme samtidig som det har effekt på barnets atferd, ligger først og fremst i muligheten for intervensjon. Videre viser prosjektet hvordan moderne teknologi kan hjelpe til med forskning innen for medisin og psykologi i det som er et tverrfaglig prosjekt. 21

22 Kapittel 4 Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig å endre på krav og legge til krav underveis. Som følger av dette foreligger det revideringer til denne kravspesifikasjonen som det kan leses om i avsnitt 4.8, Samsvar mellom kravspesifikasjon og produkt. 4.1 Systemkrav Android som operativsystem. Samsung Galaxy Tab 2 som utgangspunkt for nettbrett. 4.2 Funksjonskrav Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav Spillsekvens Generelt: Spillet skal ha et ansikt plassert på midten av skjermen. Ansiktet kan se rett frem eller på en boks. Spillet skal være delt inn i tester og nivåer. Tester: Spillet skal starte og slutte med en test. Det skal være en test mellom hvert nivå. Tester skal ha åtte bokser i en sirkel rundt ansiktet på skjermen. I tester skal ansiktet automatisk se på en av de åtte boksene. Et forsøk skal starte i det ansiktet ser på en av boksene. Mulighet til å bestemme hvor lang tid man har på å trykke på boksen ansiktet ser på før forsøket blir registret som feil. Ved å trykke på en boks som ansiktet ikke ser på skal registreres som feil. Ved feil skal skjermen bli hvit i ett sekund før et nytt forsøk starter. Ved å trykke på boksen ansiktet ser på skal forsøket registreres som riktig. Skjermen skal deretter bli hvit i ett skund før et nytt forsøk starter. 22

23 Nivåer: Spillet skal ha åtte nivåer med forskjellig antall bokser på skjermen. De to første nivåene skal ikke ha noen bokser på skjermen. For å registrere et korrekt forsøk skal man klikke på øynene til ansiktet på skjermen. På nivåene med bokser på skjermen skal man kunne trykke på øynene til ansiktet på skjermen. Etter at man har trykket på ansiktet skal ansiktet se på en av boksene på skjermen. Hvis man trykker på boksen ansiktet ser på, skal dette registreres som riktig. Når man har trykket på riktig boks skal dette føre til en tilbakemelding i form av en video. Det skal være mulig å velge hvor langt tid barnet har på å trykke på boksene som ansiktet ser på før forsøket blir regnet som feil. Ved å trykke på en boks som ansiktet ikke ser på skal dette registreres som feil. Ved feil skal skjermen bli hvit i ett skund før et nytt forsøk starter. Det skal være mulig å velge antall mulig riktig klikk brukeren må ha på rad for å gå videre til neste nivå. Det skal være mulig å velge hvor mange riktige forsøk man må ha før man går over til neste nivå Generelle funksjonskrav Mulighet til å lage nye brukere. Mulighet til å velge eksisterende brukere fra en database med brukere. Mulighet til å slette eksisterende brukere. Man skal kunne fortsette treningen der den ble avbrutt neste gang man starter ved å velge samme bruker ved oppstart av spillet. 4.3 Tekniske krav Skal utvikles ved hjelp av rammeverket Apache Cordova 2.0. Programmet Eclipse med Android SDK skal brukes til utviklingen. JavaScript skal brukes som programmeringsspråk. HTML5, CSS3 og SQL skal brukes til å utforme applikasjonen. En Samsung Galaxy Tab 2 skal brukes til testing og applikasjonen skal optimaliseres for dette nettbrettet. Git og Dropbox skal brukes til versjonshåndtering, back-up og deling av kildekode. 23

24 4.4 Krav til design Kun nødvendige informasjon skal vises. Videoen skal vises i fullskjerm. Når brukeren har valgt riktig boks, skal det gis tilbakemelding i form av lyd. Alt språklig innhold skal være på norsk. 4.5 Krav til kode Metoder og variabler skal navngis i samsvar med deres hensikt. Koden skal være på engelsk. 4.6 Krav til dokumentasjon Prosjektprosessen skal dokumenteres skriftlig i form av en sluttrapport. Det skal skrives under på en skriftlig avtale med oppdragsgiver. Dokumentasjonen skal fremlegges i form av en prosjektrapport som skal leveres Det skal utformes en brukermanual som skal distribueres sammen med applikasjonen. 4.7 Fremtidig utvidelse av systemet Hente ut statistikk fra de ulike brukerne. Mulighet for brukeren å velge 10 YouTube-videoer som barnet ønsker å se på, som vil bli valgt ut tilfeldig når et nivå er fullført. Muligheten til å bytte ut ansiktet med en video av et ekte menneske-ansikt som ser på boksene. 24

25 4.8. Samsvar mellom kravspesifikasjon og produkt Kravspesifikasjonen har blitt revidert underveis i prosjektet og det har blitt gjort endringer fra den originale spesifikasjonen. Enkelt krav har blitt fjernet, mens en rekke krav har blitt lagt til under utviklingen av spillet Nye krav: Statistikk skal lagres. For hvert forsøk skal ansiktet se rett frem før det ser på en av boksene etter 0,5 sekunder. Det skal være mulig å velge hvor lenge videoen varer og hvilken video som vises i applikasjonen. Alt språklig innhold skal være på engelsk Ikke oppfylte krav: Mulighet for brukeren å velge 10 YouTube-videoer som barnet ønsker å se på, som vil bli valgt ut tilfeldig når et nivå er fullført. Muligheten til å bytte ut ansiktet med en video av et ekte menneske-ansikt som ser på boksene. 25

26 Kapittel 5 Teknologier 5.1 Utviklingsplattform Applikasjonen har blitt utviklet til Android etter ønske fra oppdragsgiver om å bruke en åpen plattform. Android er verdens største operativsystem for mobile plattformer, og er i dag eiet av Google. Operativsystemet er basert på åpen kildekode, og er laget for mobile enheter i all hovedsak smarttelefoner og nettbrett. 5.2 Utviklingsteknologier Apache Cordova 2.0 Apache Cordova er et rammeverk som gjør det mulig å utvikle mobile applikasjoner til ulike mobile operativsystemer som; ios, Android, Symbian, Blackberry OS, Windows Phone blant flere andre. Apache Cordova er et sett av API-er som gjør det mulig å få tilgang til innebygde funksjoner som filhåndtering, lagring, kamera, media, med mer, ved å bruke JavaScript. Apache Cordova gjør det mulig å utvikle applikasjoner til mobile enheter ved hjelp av kun HTML, CSS, og JavaScript. Applikasjoner som benytter seg av rammeverket Apache Cordova kan kjøres som vanlige applikasjoner på ulike enheter ved å bruke de ulike plattformenes SDK-er. Applikasjoner laget i Apache Cordova kan distribueres på de ulike plattformenes applikasjonsbutikker og i vårt tilfelle kan vi distribuere applikasjonen som en apk-fil som gjør det mulig med distribusjon av applikasjonen uten å måte gå via Android sin applikasjonsbutikk. Vi har valgt å benytte oss av Apache Cordova da vi ikke innehar kompetanse innen Java. Vi vurderte det som for tidkrevende å sette oss inn i dette programmeringsspråket i løpet av et semester. I tillegg har Apache Cordova alle funksjonene vi hadde behov for. Vi har brukt følgende Apache Cordova API-er: Lagrings (Storage) API en API som tillater lagring både over lengere tid (SQL database) og kortere tid (Lokal lagring). Fil (File) API - en API som leser, skriver og navigerer i filsystemet. 26

27 5.2.2 Lagring: W3C Web SQL Database og W3C Web Storage Vi har benyttet Apache Cordova sin API til lagring, som er basert på W3C Web SQL Database og W3C Web Storage. Vi har først og fremst valgt å benytte oss av denne muligheten ettersom det tilbys av Apache Cordova og gjør det enkelt å håndtere lagring over både lengre (W3C Web SQL Database) og kortere tidsperioder (W3C Web Storage) Twitter Bootstrap Twitter Bootstrap er et open source rammeverk for front-end-utvikling. Rammeverket inneholder HTML og CSS-baserte design maler for skrift, skjemaer, diagrammer, knapper, navigasjon, bildegallerier og andre design elementer samt muligheten for ulike JavaScript-utvidelser. Vi har brukt Twitter Bootstrap i sammenheng med utforming av applikasjonens utseende ettersom det gir et fint brukergrensesnitt uten å måtte bruke for mye tid på design ettersom elementene er ferdig designet og utformet fra før av JavaScript, jquery og jquery Mobile Vi har benyttet oss av JavaScript som programmeringsspråk. Vi har valgt dette ettersom det er nødvendig i forbindelse med rammeverket vi bruker, og fordi som nevnt tidligere valgt å benytte oss av webteknologier ettersom vi ikke har Java kunnskaper. Videre har vi brukt jquery, som er et JavaScript-bibliotek. jquery gjør event-håndtering, animasjoner og AJAX enklere ved hjelp av en API. Vi har også brukt jquery Mobile som er et JavaScript-bibliotek optimalisert for berøringsskjermer HTML5 og CSS3 Vi har brukt HTML5 som markeringsspråk og CSS3 for å definere utseende på filer skrevet i HTML Google Chart API Google Chart API er en gratis API som gjør det enkelt å visualisere informasjon som ulike diagrammer og tabeller ved hjelp av JavaScript. Vi har valgt å bruke Google Chart til å visualisere statistikken i vår applikasjon da den er enkel i bruk og har grundig dokumentasjon når det gjelder utvikling og implementering. 27

28 5.2.7 YouTube API YouTube tilbyr en API som gjør det mulig å kontrollere YouTube-avspilleren ved hjelp av JavaScript slik at den kan brukes på forskjellige nettsider, applikasjoner og lignende. Dette ble brukt i den originale løsningen, men mot slutten av prosjektet revidert bort Utviklingsverktøy Eclipse og Android SDK Eclipse er et utviklingsmiljø som kan brukes til å utvikle applikasjoner i en rekke forskjellige programmeringsspråk som blant annet Java, JavaScript, Perl, PHP, C og C++. Vi har fra før av vært vant med å bruke NetBeans til utvikling, men har valgt å bruke Eclipse som utviklingsverktøy ettersom Apache Cordova har god dokumentasjon med utgangspunkt i Eclipse. Android SDK er et verktøy som tilbyr API biblioteker og en rekke utviklingsverktøy for å bygge, teste og feilsøke applikasjoner for Android Git Git er et versjonskontrollsystem som håndterer kildekode. Git holder orden på ulike versjoner av kildekoden og gjør det mulig for flere personer å jobbe på et og samme prosjekt. Vi har brukt Git som et verktøy for å holde kontroll på kildekoden slik at vi har oversikt over de ulike versjonene av koden. Dette gjør at vi unngår å overkjøre hverandres kode. Git gjør det også enkelt å gå tilbake i tid og se hvilke endringer som er gjort til hvilket tidspunkt, dette gjør det mulig å rekonstruere tidligere arbeider som har vært gjort de gangene vi har overkjørt hverandres kode eller oppdaget feil i koden. Vi har også brukt Dropbox som server til vårt Git-repository Samsung Galaxy Tab 2 Applikasjonen har vært laget med utgangspunktet i en Samsung Galaxy Tab 2 etter ønske fra oppdragsgiver. All testing under utviklingen av applikasjonen, og testing av applikasjonen på barn har vært gjort på en Samsung Galaxy Tab 2. 28

29 5.4. Tekniske hjelpemidler Dropbox Dropbox er en gratis nettskytjeneste som kan brukes til å synkronisere filer på flere datamaskiner og mobile enheter. Vi har hatt en felles mappe som vi har brukt til å dele dokumenter som fagartikler, prosjektnotater, gruppesideinformasjon og i forbindelse med Git Google Drive Google Drive er et verktøy som gjør det mulig å bruke ulike kontorprogammer via en nettleser i sanntid sammen med andre. Dette gjør arbeidet med dokumentasjon enklere og mer fleksibelt ettersom man ikke er avhengig av en enkelt enhet, samt sørger for at det blir tatt back-up til enhver tid Prototyping: Microsoft Power Point og Libre Office Presentation Vi har benyttet presentasjonsverktøyene Microsoft Power Point og Libre Office Presentation til å lage dynamiske prototyper av applikasjonen. Ved å benytte presentasjonsverktøy som et verktøy i forbindelse med å lage prototyper har vi hatt mulighetene til å gjøre raske endringer, samtidig som vi har hatt muligheten til å benytte oss av mye av den funksjonaliteten som ligger i denne typen programvare Google Scholar Google Scholar tilbyr en søkemotor for faglitteratur. Gjennom Google Scholar kan man søke på ulike fag disipliner og velge ulike kilder som artikler og bøker. Vi har valgt Google Scholar til å søke på ulik artikler som omhandler autisme. Google Scholar tilbyr sammendrag som gjør det enklere å finne relevant informasjon. Det er også mulig og se antall sitering av en artikkel, noe som gir en god indikasjon på artikkelens faglige integritet Adobe Photoshop Adobe Photoshop er et profesjonelt bilderedigeringsprogram som i dette prosjektet har blitt brukt til å redigere bilder Colour Contrast Check Colour Contrast Check er verktøy for å finne ut om fargene gir tilstrekkelige kontrast for fargeblinde eller på svarthvitt skjerm. 29

30 Kapittel 6 Prototyping Under prosjektet har prototyping vært en sentral metode for utvikling av applikasjonen. Spesielt har prototyping gjort det mulig for oss å sette oss inn i konseptet bak intervensjonsmetoden som er foreslått av oppdragsgiver, og har dannet grunnlaget for utformingen av kravspesifikasjonen. Eika Sandnes (2011) definerer en prototype som: En prototype er en konkretisert dokumentasjon på vår forståelse av brukerens behov og våre ideer til hvordan brukergrensesnittet skal utformes for å dekke disse behovene. Motivasjon for å bruke prototyping: Bekrefter om brukerens behov er dekket. Sparer tid og innsats ved at man unngår å bruke ressurser på å programmere. Man unngår å bruke tid på å programmere en idé som ikke dekker brukerens behov. Unngår å lage et produkt som er vanskelig å bruke. Tidlig tilbakemelding gjør det mulig å enkelt justere produktet underveis. Man unngår større grad av feil i utviklingsprosessen. (Eika Sandnes 2011) Prototyping har vært en viktig del av vårt utviklingsprosjekt. Tidlig tilbakemelding har gjort det mulig for oss å gjøre de nødvendige justeringene og vi har i tett dialog med arbeidsgiver fått tilbakemelding på prototypen som har gjort det enkelt å justere designet til applikasjonen. 6.1 Papirprototype Tidlig i prosjektet brukte vi papirprototyper som metode for å forstå de sentrale delene av prosjektet til oppdragsgiver. Papirprototyping kjennetegnes ved at man tegner de forskjellige stegene av interaksjon på forskjellige ark (Eika Sandnes 2011). Motivasjonen til å ta i bruk prototyping på papir er det at den enkelt kan produseres, forkastes og endres (Eika Sandnes 2011), og er derfor vært et sentralt første ledd i utviklingsprosessen til vårt prosjekt. I første omgang hadde vi et møte med oppdragsgiver hvor selve hovedprinsippet bak spillsekvensen ble skissert på ark. Vi tok utgangspunktet i denne papirprototypen og kom med tilbakemeldinger til oppdragsgiver etter hva vi så som gjennomførbart samt innspill til hva som kunne forbedre applikasjonen. I figur 2 er et utdrag fra papirprototypen for å illustrere hvordan papairprototypingen har funnet sted. 30

31 Figur 2: Utdrag fra papirprototypen 31

32 6.2 Interaktiv prototype Som tidligere nevnt har vi valgt å benytte oss av interaktiv prototyping ved hjelp av presentasjonsverktøy. Motivasjon for å prototype ved hjelp av presentasjonsverktøy: De fleste har tilgang til presentasjonsverktøy, enten i form av Office pakken eller fri programvare. Presentasjonsverktøy gjør det mulig å lage mer avanserte prototyper som er interaktive. Presentasjonsverktøy tilbyr innebygde komponenter for brukersnitt. Kan enkelt skrive ut skjermbilder. Gjør det mulig å tegne egne komponenter ved behov som kan brukes i prototypen. (Eika Sandnes 2011) Ikke lenge etter vi hadde jobbet med papirprototypen ble vi tilsendt en interaktiv Microsoft PowerPoint prototype av oppdragsgiver. Denne interaktive prototypen ble brukt som utgangspunkt i vår egen interaktive prototype som var mer detaljert (se vedlegg 2). Figur 3: Eksempelbilder fra den interaktive prototypen 32

33 Den interaktive prototypen gjorde det mulig å forstå konseptet bak spillsekvensen tydeligere, og satt rammene for hvordan spillsekvensen måtte utformes for å dekke behovet til intervensjon. Den interaktive prototypen har blitt brukt flittig under hele utviklingsprosessen og vært utgangspunktet for justeringer i brukergrensesnittet underveis. 33

34 Kapittel 7 Designvalg og brukergrensesnitt I denne delen av oppgaven skal det begrunnes for valg av design og brukergrensesnitt. Vi har illustrert sentrale designelementer i spillet med bildeutsnitt og kommenterende tekst hvor vi har funnet det nødvendig. Videre har vi skilt mellom generelle designprinsipper og designet bak selve spillsekvensen. 7.1 Håndbasert input - touch teknologi Vi har benyttet oss av touch teknologi etter ønske fra arbeidsgiver. Dette tilbyr muligheten til å trene repetitive funksjoner i stort omfang samtidig som det er rom for variasjon og motivasjon. Moderne touch teknologi på nettbrett er en intuitiv form for klikk og pek som kan brukes av barn i ung alder. Studier gjort ved Universitetet i Stavanger viser at berøringsskjermer er en teknologi som små barn behersker uten problemer (Hapnes Strand 2013). Som følge av dette vil det være et viktig steg å prøve ut denne teknologien ved intervensjon hos barn med autisme. 7.2 Layout, utforming og generell struktur Spillet vi har laget skal brukes til intervensjon av barn med autisme i tidlig alder. På den andre siden skal spillet brukes i samråd med blant annet foreldre, forskere, psykologer og andre omsorgspersoner knyttet til barnet. Derfor vil det generelle designet rettes mot disse. Selve spillet utføres av barnet, men alle andre funksjoner som å legge til brukere, vise statistikk, samt andre administrative handlinger utføres av voksene personer. På bakgrunn av dette har det vært viktig å utforme et gjenkjennbart brukergrensesnitt, vi har derfor valgt å etterstrebe følgende prinsipper: Visibility Det skal være åpenbart hva en kontroll brukes til. Affordance Det skal være tydelig hvordan en kontroll er brukt. Feedback Det skal være tydelig når en kontroll har blitt benyttet. (Stone, Jarret, Woodroffe, Minocha, 2005) Gjenkjennbarhet og mentale modeller For å gjøre navigeringen i spillet enkelt, har vi fokusert på gjenkjennbarhet og mentale modeller. Vi ønsker å ta utgangspunkt i brukerens tidligere kunnskap i forhold til lignende applikasjoner og mobile enheter. Meny, innhold og plassering av knapper er gjort i mest mulig lik andre applikasjoner på markedet. Vi tar forbehold om at de voksene som bruker applikasjonen har kjennskap til systemer basert på mobile enheter og har dette som utgangspunkt i forhold til den mentale modellen. Som følger av 34

35 dette vil navigeringen i systemet, ved både førstegangsbruk og videre bruk være enklest mulig. Det har også vært et ønske å unngå fargene rød og grønn med tanke fargeblinde brukere Tilbakemelding til brukeren Mangel på tilbakemelding er et av de mest vanlige problemene i brukergrensesnitt (Eika Sandnes 2013). Vi har i løpet av utvikling av prosjektet lagt vekt på å minimere muligheten for at brukeren skal kunne gjøre feil ved hjelp av tilbakemeldinger. Det sentrale ved tilbakemeldinger er at når brukeren har utført en handling, så bør brukergrensesnittet gi en tilbakemelding som viser at handlingen har hatt en effekt på systemet og at dette skjer i form av en tilstandsendring. Brukeren bør oppfatte systemet i en annen tilstand etter at handlingen ble utført (Eika Sandnes 2011). Vi har brukt tilbakemelding ved: Innsetting av brukernavn. Innseting av alder for å sørge for at alder er numerisk. Hindre at brukeren ikke har valgt video før spillsekvensen starter. Sørge for at brukeren har valgt en bruker å vise statistikk for. Hindre at brukeren avslutter spillet ufrivillig. Hindre at brukeren ufrivillig sletter en bruker. Gjøre brukeren klar over at bruker er opprettet og at spillet starter. I figur 4 finnes et eksempel på input validering av alder: Figur 4: Input validering 35

36 7.2.3 Menyvalg Vi har valgt å utforme menyen i applikasjonen etter George Millers teori 7+-2, som er teorien om hvor mye informasjon mennesker kan huske (Miller 1955). Vi har valgt å benytte oss av 7 menyvalg som illustrerte i figur 5. Figur 5: Menyvalg Tekstvalg Bevisste designvalg knyttet til formatering av tekst, fontvalg, tekststørrelse og fargevalg på tekst kan bidra til å bedre lesbarheten og brukeropplevelsen (Eika Sandnes 2011). Tekst brukes kun til å formidle nødvendig informasjon i forhold til de innstillinger og oppgaver som må utføres utenfor selve spillsekvensen. Designvalg i tekstsammenheng: Vi har i all hovedsak brukt Helvetica som skrifttype for å skape et helhetlig utseende i applikasjonen, samtidig som denne skrifttypen skaper et moderne utseende som er lett å lese for brukeren. Vi har valgt å benytte oss av en kombinasjon av små og store bokstaver for å øke lesbarheten. Vi har valgt å ha tilstrekkelig med marg på alle kanter og godt mellomrom mellom linjer i teksten for å øke lesbarheten. Overskrifter har større tekststørrelse for å skape god oversikt. Lettfattelig språk og minimalt med tekst for å skape enkelhet. Linjer og avstand er blitt brukt som virkemidler for å gruppere informasjon. Vi har gjort teksten mer leselig ved å skille teksten fra bakgrunn ved å benytte kontraster 36

37 Kontraster mellom linjeskift i alle tabeller for å skape oversikt. (Eika Sandnes 2011) Fargevalg Farger er brukt for å: Skille ulikt innhold. Skape oppmerksomhet. Gi et attraktivt utseende. Skape en brukervennlig og avslappet formidling av informasjon og innhold. Det har blitt tatt følgende fargevalg: Vi har valgt en lysegrå bakgrunn med myk blåfarge for å skape kontraster og legge til rette for avslappet lesning. Skille mellom lysegrå og hvit ved linjeskift i filhåndtereren for enklere lesning. Vise status ved handlingsvalg. Som nevnt tidligere har vi brukt Colour Contrast Checker for å finne ut om fargene gir nok kontrast slik at de ikke skaper problemer for fargeblinde eller ved bruk på svarthvit skjerm. Resultatet viser at applikasjonen tilfredsstiller WCAG2 AA. Figur 6: Resultat fra Color Contrast Checker 37

38 7.2.6 Bilde og ikonvalg I filhåndtereren har ikoner blitt brukt for å benytte assosiasjoner brukeren har i sin mentale modell. Figur 7: Filhåndtereren Lyd Det har ikke vært utstrakt bruk av lyd i applikasjonen. Det har kun blitt brukt lyd i spillsekvensen som indikerer riktig eller galt svar ved valg av bokser Universell utforming Det er ofte vanlig ved utforming av applikasjoner å tilrettelegge for ulike brukergrupper med spesielle behov. Spillet er for barn med autisme, men disse skal kun benytte seg av selve spillsekvensen. Ved bruk av innstillinger og funksjoner som håndteres av den voksene personen er det ikke tatt stilling til spesielle behov. Dette har blitt vurdert til å falle utenfor prosjektets omfang, samtidig som denne applikasjonen ikke skal brukes av andre behovsgrupper enn barn med autisme Brukermanual Brukermanualen til selve applikasjonen er lagt ved i denne prosjektrapporten (se vedlegg 1), samtidig som den også er tilgjengelig i selve applikasjonen. Dette er gjort slik at brukeren kan finne all den nødvendige informasjonen som trengs, selv om vi har prøvd å etterstrebe en selvforklarende applikasjon. 38

39 Lengden på linjene i teksten påvirker hastigheten vi leser. Lengere linjer leses raskere enn korte linjer ettersom øyet ikke må hoppe mellom linjene så ofte (Eika Sandnes 2011). Et eksempel på bruk av lengere linjer er ved produksjon av brukermanualen (User Guide), her har vi tekst som fyller hele skjermen. Figur 8: Brukermanual Logovalg- EyeCatch Vi har valgt å kalle applikasjonen eyecatch, som på norsk betyr blikkfang. Logoen symboliserer prosjektets innhold. Under utformingen av logoen har det vært viktig med et enkelt design, og en tydelig skrifttype. Logoen har to øyne som symboliserer prosjektets funksjon ved at det skal trene opp barn med autisme til å følge blikk. 7.3 Design av spillsekvensen Oppdragsgiver har gitt oss en rekke retningslinjer når det gjelder utforming. Disse har vært viktig å følge ettersom intervensjonsmetoden baserer seg på prinsippene til Discrete Trial Teaching Design prinsipp for intervensjonsmetoden Discrete Trial Teaching Et ansikt er presentert i midten av skjermen sammen med flere ulike objekter som er plassert rundt på maksimalt 8 forskjellige steder (opp, ned, høyre, venstre, og mellom alle disse). Hvis barnet trykker i øyeregionen på nettbrettet vil ansiktet bytte blikk fra å se rett frem til å se på et av objektene. Hvis barnet oppfatter riktig boks som ansiktet ser på og trykker på denne boksen så vil barnet få en belønning i form av en film, som er den positive forsterkeren. 39

40 7.3.2 Valg av objekt - hvorfor er objektet en boks? Felles oppmerksomhet foregår ved at man deler oppmerksomhet med andre mennesker i forhold til et objekt. Objektet i vårt tilfelle er bokser. Valget har falt på bokser ettersom dette var det opprinnelig forslaget fra oppdragsgiver. Boksene symboliserer det som skal være det felles objektet mellom barnet og personen på bildet. Objektet kunne i utgangspunktet vært hva som helst, men ettersom bokser er et anonymt objekt mener vi dette var en god løsning. Samtidig symboliserer en boks et innhold - at det er noe inne i boksen. Etter at oppdragsgiver testet spillet på barn med autisme ved Yale University fant han ut at boksene var vanskelig å treffe. Vi gjorde derfor områdene som kan trykkes på rundt boksene større som illustrert i figur 9. Figur 9: Før og etter bilde av treffområdet. Fargene rødt/blått er kun for å illustrere treffområdet Valg av ansikt Ansiktet symboliserer mennesket som man i virkeligheten ville delt oppmerksomheten i forhold til et objekt med. Ettersom forskning (Matsuda og Omori 2011) har vist at små barn kan oppfatte øyeretning fra digitale bilder av voksene sine ansikter og skifte oppmerksomhet i forhold til dette, har vi valgt bilder. På det første nivået er ansiktet noe uklart utenom øynene for å fremprovosere barnet til å trykke på øynene som illustrert i figur

41 Figur 10: Ansiktet uklart utenom øynene Valg av video som positiv forsterker Som tidligere nevnt er video valgt som positiv forsterker. Bruk av video som positiv forsterker var den opprinnelige ideen fra oppdragsgiver. Videoen skal være en belønning som skal motivere barnet til å bruke spillet og til å fortsette treningen slik at den har en effekt på barnets atferd. Barnet kan få se video fra 1 til 30 sekunder, dette velger man samtidig som man velger video. Hensikten med tidsbegrensningen er å motivere barnet til å fortsette treningen for å se mer av videoen. Videre har det vært et ønske fra oppdragsgiver at tiden på videoen som vises for hvert korrekte trykk skal kunne varieres. Ved bruk av positive forsterkere er det som tidligere nevnt viktig med variasjon, og det bør identifiseres hvilken video barnet ønsker å se. Vi har derfor gjort det mulig å velge video ettersom barnets preferanse kan variere. Etter som denne typen opplæring er tidsomfattende, er muligheten til å kunne velge video til enhver tid en viktig del av designet Mestringskriterium Applikasjonen er delt inn i ulike nivåer hvor hvert enkelt nivå har et valgfritt mestringskriterium fra 1 til 30 riktig på trykk på rad. Det er hensiktsmessig at mestringskriteriet kan varieres for å tilpasse vanskelighetsgraden, ettersom behovet for antall repetisjoner vil variere fra barn til barn. 41

42 7.3.6 Tid per forsøk Hvor lang tid barnet har til å trykke på rett boks etter at ansiktet har skiftet blikk kan settes ved opprettelse av bruker. Dette har vært forspurt fra oppdragsgiver da han ønsket muligheten til å variere vanskelighetsgraden Ulike nivåer Treningen består av ulike nivåer hvor antall bokser øker for hvert nivå. Dette er gjort for å øke vanskelighetsgraden etter hvert som barnet lærer å mestre de ulike nivåene Tester Før det første nivået og etter det siste nivået, samt mellom de ulike nivåene, blir det utført en test. Testen tilsvarer det vanskeligste og siste nivået i spillet, og gir ingen form for positiv forsterker. Det gis ingen positiv forsterker ettersom testene ikke er en del av selve treningen, men kun et verktøy for å se om barnet viser progresjon underveis Trykktrening Trykktrening består av kun en boks som vises et vilkårlig sted på skjermen. Hvis barnet trykker på boksen vil det vises en video. Trykktrening er en del av spillet som skal lære barnet å treffe boksen samt se om barnet liker videoen som er valgt. 42

43 Kapittel 8 Testdokumentasjon Brukertesting innebærer innhenting av tilbakemeldinger fra brukere på systemet og er sentralt for å se om systemet løser de riktige oppgavene på en tilfredsstillende måte (Eika Sandnes 2011). I denne delen av oppgaven vil vi redegjøre for brukertestingen som er utført samt forslag til endringer basert på testresultatene. Testingen har blitt utført av oppdragsgiver og prosjektgruppen. Oppdragsgiver har testet intervensjonsprinsipper og applikasjonen på barn, mens prosjektgruppen har testet applikasjonen på voksene personer i sammenheng med generell funksjonalitet og design. 8.1 Planlegging av hvem, hva, hvor og når Applikasjonen har i all hovedsak tre brukergrupper: Barn med autisme. Voksene/Omsorgspersoner til barn med autisme. Fagpersoner som psykologer, leger og sykepleiere. Ettersom applikasjonen har tre ulike brukergrupper avhengig av hvilke funksjoner som brukes, har vi valgt å dele testene inn i to deler: Test av spillsekvensen utført av oppdragsgiver på barn. Test utført av prosjektgruppen på voksene personer angående generell funksjonalitet og design. I følge Stone et al. (2005) er det vanlig å starte med fem testpersoner, og eventuelt gå videre med flere deltakere etterhvert som behovet blir større. Samtidig er det viktig med en variert testgruppe (Stone et al. 2005). Derfor har vi testet det generelle designet på fem varierte personer. Videre har vi valgt å benytte oss av «Task Cards» (Stone, Jarret, Woodroffe, Minocha, 2005) (se vedlegg 3). Dette er en liste med oppgaver som brukeren skal utføre i systemet. Vi tok notater underveis i testprosessen for å se om det var områder brukeren opplevde problematisk. Vi har også laget et intervju som vi brukte i etterkant for å kartlegge brukerens opplevelse av systemet (Stone, Jarret, Woodroffe, Minocha, 2005). 43

44 8.2 Testresultater - Problemer og løsningsforslag Test utført av oppdragsgiver Oppdragsgiver har utført en rekke tester underveis for å sikre at applikasjonen vi har utviklet imøtekommer oppdragsgivers behov. Spesielt har det vært en rekke justeringer underveis med tanke på selve spillsekvensen. Det har vært viktig at spillet følger intervensjonsprinsippene i spillsekvensen. Videre har oppdragsgiver testet applikasjonen på barn ved Yale Child Study Center i Connecticut for å avdekke om applikasjonen kan anvendes på barn. Nedenfor er forslag til forbedringer etter at applikasjonen har vært testet av oppdragsgiver, og ved Yale Child Study Center: Ved trykk på feil boks burde det spilles en feilmeldingslyd. Før hvert forsøk burde skjermen bli hvit i ett sekund. For hvert nivå starter videoen på nytt. Videoen burde fortsette der den stoppet nivået før. Android sin tilbakeknapp burde alltid føre tilbake til hovedmenyen. Lengde på video som vises for hvert riktig trykk burde kunne velges. Områdene rundt boksene som regnes som gyldig ved trykk er for små, disse burde være større. Tidtakeren burde starte av seg selv og ikke når man trykker på øynene. Det burde ta 0,5 sekunder før et nytt forsøk starter. Ønske om å ikke ha noen lyd ved feil eller riktig valg i testene. Ønske om å endre skriftspråket i spillet fra norsk til engelsk. Lage et alternativ i hovedmenyen som heter Touch Training hvor det kun skal vises en boks et vilkårlig sted på skjermen. Ved riktig trykk skal det vises en film, og boksen skal skifte posisjon Brukertesting på voksene utført av prosjektgruppen Det ble mot slutten av prosjektprosessen besluttet å utføre brukertester på voksene personer og se om designet utenom selve spillsekvensen var brukervennlig. Det har etter brukertestingen blitt avdekket følgende punkter som kan forbedres. Testresultatene finnes i vedlegg 4. Intervjuet som ble brukt under testing finnes i vedlegg 5. Det ble også utformet en samtykkeerklæring (se vedlegg 6) som testpersonene måtte signere før testene ble utført. 44

45 Nedenfor følger forslag til forbedringer som er utarbeidet som følge av testene: Avkrysningsboksene for å vise graf burde stå ved siden av brukernavnet. Det burde eventuelt være mulig å trykke på selve brukernavnet i stedet. Knappene i menyen kunne ha vært større og burde ha ikoner. Det burde gis tilbakemelding ved opprettelse av bruker. Avkrysningsboksene burde vært større i statistikk. Endre tekst i tekstboksen fra kun å være «age», til «age in months». Samle funksjonalitet i færre knapper. Minimere bruken av tomrom. Filer som ikke er mapper eller video burde ikke vises i filhåndtereren. Elementene i filhåndtereren burde være større da de kan være vanskelig å trykke på. 8.3 Resultat av brukertester Utviklingsprosessen har vært drevet iterativt og applikasjonen har blitt revidert under hele utviklingsprosessen etterhvert som den har blitt testet og det har blitt funnet mangler og områder med rom for forbedring. Spesielt er testingen og tilbakemeldingene fra oppdragsgiver og hans tester utført på barn ved Yale Child Study Center ved Yale School of Medicine hatt stor nytteverdi. Oppdragsgivers testing har vært sentral under hele utviklingsprosessen og resultatene av disse testene har i stor grad formet applikasjonen. Test på voksene personer i forhold til brukergrensesnittet utenfor selve spillsekvensen kom sent ut i prosjektprosessen og vi ser i dag at dette burde vært gjort tidligere. Samtidig har disse testene ført til mindre justeringer av brukergrensesnittet og validering av brukervennlighet. 45

46 Kapittel 9 Produktdokumentasjon 9.1 Formål Dette dokumentet forklarer oppbyggingen, virkemåten og funksjonene til applikasjonen eyecatch. 9.2 Omfang Denne applikasjonen har som hensikt å benytte tradisjonelle treningsmetoder innen atferdsvitenskap til å lære barn med autisme å respondere på felles oppmerksomhet ved bruk av nettbrett og håndbasert input. 9.3 Brukere av produktdokumentasjonen Denne dokumentasjonen er i all hovedsak beregnet til vedkommende som skal vedlikeholde og modifisere applikasjonen. Det forutsettes at vedkommende innehar kompetanse innen HTML5, CSS3, JavaScript og SQL. Videre bør vedkommende ha satt seg inn i rammeverket Apache Cordova. 9.4 Ekstern dokumentasjon Apache Cordova: Android: Google Chart API: Program Beskrivelse Applikasjonen eyecatch tilbyr hovedsakelig: Spillsekvens basert på Discrete Trial Teaching. Mulighet til å velge video som positiv forsterker i spillsekvensen. Sett inn og slette brukere i en database. Vise statistikk. 9.6 Applikasjonens struktur Applikasjonen benytter seg av rammeverket Apache Cordova som kjører på et Android operativsystem. Det er blitt benyttet webteknologier som JavaScript, HTML5 og CSS3. Figur 11 illustrer den lagdelte strukturen til applikasjonen. 46

47 Figur 11: Applikasjonens lagdelte struktur 9.7 Applikasjonens oppbygning Figur 12 illustrer de ulike filene i applikasjonen. Figur 12: Applikasjonens oppbygning 47

48 9.7.1 index.html Denne filen inneholder hovedmenyen som består av en eyecatch-logo samt 7 menyvalg. Figur 13: Menyvalg Menyelementene er strukturert ved bruk av Twitter Boostrap sitt scattfolding-rutenett og knappene er anchor-tagger stylet av en Twitter Bootstrap-klasse. Følgende HTML plasser en klikkbar Bootstrap knapp på skjermen: Videre i samme filen benyttes Apache Cordova Storage API hvor en database og en tabell opprettes ved hjelp av JavaScript og SQL. Følgende JavaScript-kode illustrerer opprettelsen av en tabell (koden er ikke fullstendig og er kun ment for å illustrere): 48

49 9.7.2 selectuser.html Denne filen inneholder en liste over brukernavnene til brukerne i databasen. Listen er stylet via en Twitter Boostrap-klasse og brukernavnene blir tatt ut av databasen ved hjelp av Apache Cordova Storage API. Følgende kode trekker ut brukernavnene fra databasen og setter disse i en liste: Når brukernavnet er trykket på vises en knapp på skjermen. Denne knappen inneholder en link som sender brukeren til det nivået brukeren befinner seg på. Videre så sjekker filen om brukeren har valgt en video før spillet starter. Hvis en video ikke er valgt, blir brukeren sendt til selectvideo.html. Valgt brukers ID blir lagret i minnet på enheten via Apache Storage API. Dette er gjort for å vite hvilken bruker som er valgt: newuser.html Denne filen inneholder et skjema for opprettelse av en ny bruker. Skjemaet er stylet ved bruk av jquery Mobile og Twitter Boostrap. If-tester validerer skjema input og gir en JavaScript-alert ved feil. Hvis informasjonen fylles inn korrekt, lagres dette i databasen ved hjelp av Apache Storage API. Etter at brukeren er opprettet sendes brukeren direkte til test. Videre så sjekker filen også her om brukeren har valgt en video før spillet starter. Hvis en video ikke er valgt blir brukeren sendt til selectvideo.html. 49

50 9.7.4 deleteuser.html Denne filen inneholder en liste over brukernavnene til brukerne i databasen. Listen er stylet via en Twitter Boostrap-klasse og brukernavnene blir tatt ut av databasen ved hjelp av Apache Cordova Storage API. Når brukernavnet er trykket på vises en knapp på skjermen med teksten «Delete User». Ved å trykke på denne knappen vises en JavaScript-alert som ber brukeren om å bekrefte sletting av brukeren. Ved bekreftelse kjøres det en spørring mot database ved hjelp av Apache Cordova Storage API som sletter valgt bruker fra databasen selectvideo.html Denne filen inneholder en filhåndterer strukturert i en Twitter Bootstrap-tabell. Apache Cordova File API benyttes til å liste ut filene på enheten. Kun mapper og mp4-videoer listes ut, som vist i følgende kode: Ved å trykke på mappenavnet blir innholdet i denne mappen listet ut på skjermen. Trykker man på navnet til en video vil en dialogboks vises på skjermen. Denne dialogboksen gir muligheten til å angi varigheten av videoen som vises i spillet. Deretter blir filstien til videoen og varigheten lagret lokalt på enheten. Følgende linje med kode lagrer filstien til valgt video:0 Følgende linje med kode lagrer varigheten som er satt: I spillsekvensen blir variablene hentet ved bruk av følgende kode: 50

51 9.7.6 touchtraining.html Denne filen viser en boks på et av åtte områder på skjermen ved å benytte seg av JavaScript sin innebygde funksjon for å hente ut et tilfeldig tall. Det tilfeldig tallet vil være fra null til syv og vil bestemme hvilket av de åtte områdene boksen skal vises på. Følgende kode viser et utdrag av funksjonen: Videre brukes en HTML5 video-tag til å spille av en video ut i fra hvor mange sekunder videoen er satt til i selectvideo.html. Dette skjer hver gang det trykkes på boksen. Videoen blir stoppet når tidtakeren går ut og videoen blir flyttet ut av skjermbildet som vist ved følgende kode: Videoen kommer tilbake når det har blitt trykket på en boks statisticstests.html og statisticslevels.html I disse to filene blir brukerdata hentet ut av databasen og listet i en Twitter Boostrap-tabell. Ved å trykke på avkryssingsboksene på samme linje som navnet til brukeren for deretter å trykke på «Display Graph»-knappen vil en graf bli tegnet på følgende måte ved benyttelse av Google Chart API: Data blir hentet fra databasen for alle brukere som er valgt og deretter satt inn i separate matriser 51

52 Data blir hentet fra databasen for alle brukere som er valgt og deretter satt inn i separate matriser userguide.html Denne filen inneholder brukermanualen utformet i HTML5 og CSS test.html Denne filen består av et bilde av et ansikt med åtte bokser i en sirkel rundt. En tidtaker vil etter 0,5 sekunder kalle på en funksjon som henter ut et tilfeldig tall mellom null og syv. Bilder av ansiktet som ser i ulike retninger er satt inn i en matrise. Gjeldene bilde vil bli byttet ut med bildet som har tilsvarende plass i matrisen som det tilfeldige tallet: En variabel som teller antall forsøk vil øke med én når dette skjer. En annen tidtaker vil nå gi brukeren x antall sekunder (antall sekunder på tidtakeren er satt ved opprettelse av brukeren) til å trykke på den rette boksen før ansiktet ser frem og et forsøk er over. Hver boks på skjermen har en funksjon knyttet til seg. Når boksen blir trykket på vil denne funksjonen sjekke om det tilfeldige nummeret tilsvarer boksens nummer. Hvis den gjør det har brukeren trykket på rett boks. Følgende kode er et eksempel på dette: 52

53 Hvis brukeren trykker på rett boks før tiden går ut, vil en variable som teller korrekte trykk øke med én. Denne prosessen vil fortsette helt til antall forsøk tilsvarer antall ønskede tester satt ved opprettelse av bruker. Når denne prosessen er ferdig vil antall forsøk og antall korrekte trykk lagres i databasen på gjeldene bruker: Brukeren vil deretter bli videresendt til neste nivå levela.html til levelh.html (nivåer) Denne filen er tilsvarende test. Det er tre hovedmomenter som skiller de ulike nivåene fra test: 1. Antall bokser varierer. 2. Man må trykke på øynene for at ansiktet skal skifte blikk. 3. En video på samme måte som i «Touch Training» (se avsnitt 9.7.6) done.html Når brukeren kommer til denne filen betyr det at han eller hun har fullført alle nivåene og det gis en tilbakemelding til brukeren om at treningen er fullført sammen med en knapp som lar brukeren gå videre til statistikk. 53

54 9.8 Systemkrav Plattform Applikasjonen er hovedsakelig utviklet for Samsung Galaxy Tab 2, men et hvert nettbrett med Android som operativsystem kan potensielt kjøre applikasjonen Operativsystem Applikasjonen er kun utviklet for Android Lagring Applikasjonen krever 6 mb ledig lagringsplass for å kunne installeres. 9.9 Installasjonsveiledning Denne applikasjonen installeres ved å kjøre filen com.simonandrichard.eyecatch.eyecatch.apk på nettbrettet. Filen ligger på vedlagt CD. 54

55 Kapittel 10 Prosjektprosessen 10.1 Planlegging og forberedelser Valg av oppdragsgiver Vi ble informert om dette prosjektet gjennom vår tidligere foreleser i faget Universell Utforming, Kirsten Ribu som også har vært vår veileder gjennom hele prosjektet. Ribu tok kontakt med oppdragsgiver sent høsten 2012 og informerte nåværende oppdragsgiver Lars Klintwall om vår interesse. I november 2012 arrangerte vi et møte med oppdragsgiver. Her ble vi informert om behovet til oppdragsgiver og hva han ønsket å få ut av prosjektet. Vi anså prosjekt som interessant og gjennomførbart og inngikk en avtale med Klintwall om å utvikle applikasjonen. Prosjektet fikk navnet eyecatch Analyse og kartlegging Andre møte med Lars Klintwall analyserte vi oppgaven og skissert en løsning for prosjektet. I denne fasen ble prosjektet illustrert av oppdragsgiver gjennom papirprototyper og vi så på det tekniske aspektet og hvilke verktøy som burde benyttes til å lage applikasjonen Forkunnskaper Ingen av gruppens medlemmer hadde tidligere utviklet en applikasjon for nettbrett før prosjektet startet, men begge hadde kunnskaper innen webteknologier som kunne brukes til å utvikle en slik applikasjon ettersom vi valgte å benytte oss av rammeverket Apache Cordova. Spesielt har forkunnskapene innen menneske-maskin-interaksjon, universell utforming, systemutvikling, databaser, JavaScript, HTML og CSS vært benyttet Arbeidsmetode Vi har vært to stykker som har jobbet med dette prosjektet, og som følge av dette har kommunikasjonen vært enkel og oversiktlig. Vi satte tidlig av faste arbeidstider mellom mandag til fredag. Arbeidstiden har for det mest blitt brukt til programmering og prototyping. Ut over dette har vi jobbet hver for oss, spesielt med rapportskriving, selvopplæring og lesing av litteratur om autisme og intervensjonsmetodene som benyttes i applikasjonen. Selv om vi kun er to personer som har jobbet med dette prosjektet har vi valgt å bruke versjonskontroll i form av Git for å håndtere koden, unngå feil og overkjøringer. 55

56 Når det gjelder kontakt med oppdragsgiver har vi hatt kontinuerlige møter. Vi har hatt en rekke fysiske møter før april. Møtene har deretter blitt holdt via Skype. All annen kommunikasjonen har funnet sted via e-post ettersom arbeidsgiver var i USA denne perioden. Kommunikasjonen med oppdragsgiver har vært tilfredsstillende, men en rekke tekniske momenter har vært noe problematisk å forstå på begge hold ettersom både gruppen og oppdragsgiver opererer innenfor ulike fagfelt. Vi har også hatt kontinuerlig kontakt med veileder Kirsten Ribu ved behov, både via møter og e- post Arbeidsplan og fremdriftsplan Arbeidsplan (se vedlegg 7) og fremdriftsplan (se vedlegg 8) ble utarbeidet på nyåret Arbeidsplanen har vært utgangspunktet for hva vi skal gjøre, mens vi fremdriftsplanen har blitt brukt som tidskjema. Vi har hatt mindre avvik i forhold til både arbeidsplanen og fremdriftsplanen, men begge har hjulpet oss til å bevege prosjektet fremover Risikohåndtering I starten av prosjektprosessen gjorde vi en risikoanalyse og utarbeidet en risikoplan. Risikoplanen inneholdt mulige risikoer og mottiltak (se vedlegg 9). Videre ble det også etablert vi en avtale med oppdragsgiver (se vedlegg 10) Tilegnelse av ny kunnskap Vi har i dette prosjektet bygget videre på tidligere kunnskaper i programmering, systemutvikling, menneske maskin interaksjon, webteknologier og databaser. Ut over dette har vi vært nødt til å sette oss inn i en rekke nye teknologier for å utvikle applikasjonen. Spesielt har vi satt oss inn i følgende teknologier: Apache Cordova Vi har brukt rammeverket Apache Cordova som utgangspunkt for utviklingen av vår applikasjon. I utgangspunktet utvikles applikasjoner for Android i programmeringsspråket Java, men ettersom vi ikke har tilstrekkelige kunnskaper i Java så valgte vi Apache Cordova som rammeverk. Vi fant ut at dette rammeverket hadde de nødvendige komponentene til vårt prosjekt. Med Apache Cordova kan applikasjoner utvikles til Android med bruk av HTML5, CSS og JavaScript. Dette er teknologier som vi fra før av har kjennskap til, men det skal nevnes at vi har brukt en del tid til å sette oss inn i JavaScript og jquery. 56

57 Eclipse og Android SDK Vi har benyttet Eclipse og Android SDK som utviklingsprogram. Vi hadde ikke brukt Eclipse fra før av, men valgte dette ettersom dokumentasjonen til Apache Cordova tok utgangspunkt i Eclipse og Android SDK. Vi brukte en del tid på å få Eclipse, Android SDK og Apache Cordova til å fungere som et integrert utviklingsmiljø. Twitter Bootstrap Vi har brukt Twitter Bootstrap som front-end rammeverk med tanke på designet. Dette har vi gjort fordi Twitter Bootstrap tilbyr ferdig designede knapper, skjemaer, blant mange andre ting. Ettersom vi ikke hadde noen særlig kunnskap innen grafisk design, fant vi dette som en god løsning. Twitter Bootstrap er et enkelt front-end rammeverk som vi har brukt mye, men som ikke har vært spesielt tidkrevende å sette seg inn i. API-er Vi har brukt Google Chart API for å utforme grafer som vi har brukt til statistikken. Vi så på flere muligheter for fremstille data grafisk ved hjelp av JavaScript, men de fleste løsningene kostet penger. I tillegg har Google Chart API en god dokumentasjon på nettet. I utgangspunktet skulle vi bruke YouTube-videoer som belønning. Vi brukte nærmere tre uker på å utforme denne løsningen (se vedlegg 11). Denne løsningen var avhengig av stabile trådløse nettverk og YouTube-filmene krevde til tider lang innlastningstid. Ettersom applikasjonen var avhengig av hurtig visning av video ønsket oppdragsgiver at vi forkastet denne løsningen og heller laget en løsning som benyttet seg av lokallagrede videoer. Videre så har vi brukt Apache Cordova API for filhåndtering og lagring. Det som er positivt med disse er den omfattende og grundige dokumentasjonen som foreligger, som gjør det enkelt å sette seg inn i de ulike komponentenes virkningsområde. 57

58 10.2 Utviklingsprosessen Produksjon av kravspesifikasjon Etter flere møter med oppdragsgiver i desember 2012 og januar 2013 startet vi med utformingen av kravspesifikasjonen. Kravspesifikasjonen ble utarbeidet med utgangspunkt i prototypen som oppdragsgiver ga oss tidlig i prosessen. Prototypen og samtalene med oppdragsgiver dannet grunnlaget for kravspesifikasjonen. Kravspesifikasjonen ble revidert under utviklingen av applikasjonen ettersom den ble testet av oppdragsgiver og testpersoner underveis Utfordringer Dette prosjektet har i all hovedsak hatt tre større utfordringer. Disse har vært: 1. Programvarefeil var en utfordring å løse ettersom vi ikke hadde tilgang til noen ressurspersoner som kjenner til den tilnærmingsmetoden vi valgte til applikasjonsutvikling. Feilretting av programvarefeil har ofte vært problematisk og tidskrevende ettersom internett ofte har vært eneste kanal til løsning. 2. Kommunikasjon med oppdragsgiver har også vært en utfordring ettersom han mesteparten av prosjektperioden befant seg i utlandet. Kommunikasjon på e-post og Skype har fungert greit i forhold til de fleste avklaringer, men det har vært tilfeller hvor oppdragsgiver har testet applikasjonen og feil har oppstått. I disse tilfellene har vært vanskelig for oss å finne ut hva som er feil, når vi selv har hatt et program som kjører feilfritt på vårt nettbrett. 3. Når det gjelder testing av applikasjonen har det vært utfordrende å finne barn med autisme som kan delta i testingen Evaluering av prosjektprosessen Gjennom dette prosjektet har vi først og fremst tilegnet oss kunnskap om bruken av webteknologier og rammeverket Apache Cordova for utvikling av mobile applikasjoner. Vi har forbedret kunnskap innen webteknologier, da spesielt JavaScript. Vi har også hatt lært mye om API-er generelt. Etter å ha evaluert prosjektprosessen ser vi at kommunikasjonen har fungert bra med oppdragsgiver og veileder. Tidsomfanget har vært tilstrekkelig til å lage en god løsning. Vi har opplevd utfordringer underveis i prosessen, men vi har klart å levere det produktet som har vært ønsket av oppdragsgiver. 58

59 Kapittel 11 Konklusjon og videre arbeider Dette har vært et interessant, utfordrende og lærerikt prosjekt. Det har først og fremst vært interessant å sette seg inn atferdsvitenskap og autisme. Å utvikle et potensielt samfunnsnyttig produkt, som kan hjelpe mennesker i deres hverdag, har vært en motiverende faktor. Det har også vært motiverende å utvikle en applikasjon for nettbrett ettersom dette er en trend innen moderne datateknologi. Det har også vært interessant å bruke kunnskaper fra vårt studie Anvendt Datateknologi, som fokuserer på mennesker med ulike behov i datasammenheng. Samarbeidet har foregått på tvers av fagfeltene psykologi og datateknologi. Det har vært en utfordring å sette seg inn i faglige termer og forstå behovet til brukergruppen. Det har også været en utfordring å formidle teknologiske begrensninger overfor oppdragsgiver ettersom han ikke har kunnskap om utvikling av programvare. Prosjektgruppen og oppdragsgiver operer innenfor ulike fagfelt noe som til tider har ført til kommunikasjonsbrister. Gjennom dette prosjektet har vi først og fremst tilegnet oss kunnskap om bruken av webteknologier og rammeverket Apache Cordova for utvikling av mobile applikasjoner. Vi har økt vår kompetanse innen webteknologier, da spesielt JavaScript. Videre har vi skaffet oss innsikt i atferdsvitenskap og spesielt autisme. Etter å ha evaluert prosjektprosessen ser vi at kommunikasjonen har fungert bra med oppdragsgiver og veileder. Tidsomfanget har vært tilstrekkelig til å lage en god løsning. Vi har opplevd utfordringer underveis i prosessen, men vi har klart å levere det produktet som har vært ønsket av oppdragsgiver. Applikasjonen vil forhåpentligvis bli et symbol på hvordan datateknologi kan hjelpe mennesker i deres hverdag. Dette har vært et lærerikt prosjekt og vi sitter igjen med kunnskap som kan brukes videre i arbeidslivet. Når det gjelder veien videre for eyecatch finnes det en rekke muligheter til forbedring. Det er tre ting som spesielt kan forbedres: Hvilken boks ansiktet i applikasjonen ser på kan fremstå som noe uklart. I en fremtidig versjon burde det være mulig å velge bilder av andre ansikter, som for eksempel barnets mor eller far. For hvert nivå starter videoen på nytt. Videoen burde fortsette der den stoppet nivået før. Dette er et teknisk problem vi har jobbet lenge med som bør løses i fremtiden. Det kunne også være hensiktsmessig å samle alle brukeradministrerende funksjoner i et menypunkt for å skape en bedre oversikt. 59

60 Prosjektet har resultert i et produkt som først og fremst skal brukes til videre og mer omfattende testing. Applikasjonen fungerer nå slik oppdragsgiver ønsker at den skal fungere, og det planlegges videre testing av applikasjonen med studenter som studerer Læringspsykologi ved Høgskolen i Oslo og Akershus samt en masterstudent ved universitetet i Stockholm. Prosjektet vil også være en del av forskningen til Lars Klintwall. Oppdragsgiver har uttrykket et ønske om at vi fortsetter med utviklingen av applikasjonen etter at prosjektet nå er avsluttet. Dette er noe vi må vurdere, men som vi stiller oss positive til. 60

61 Kilder og litteraturliste Bongard T., og Røskaft E. (2010). Det biologiske mennesket individer og samfunn i lys av evolusjon. Trondheim: Tapir Akademisk Forlag. Boraston Z., og Blakemore S.-J. (2007). The application of eye-tracking technology in the study of autism. The journal of Physiology, 581: The Journal of Physiology. Cheng., og Huang R. (2012). Using virtual reality environment to improve joint attention associated with pervasive developmental disorder. Research in Development Disabilities. Volume 33, Issue 6, November-December 2012, page Elsevier. Eika Sandnes, F. (2011). Universell utforming av IKT-systemer. Oslo: Universitetsforlaget. Hapnes Strand, H. (2012). Nettbrett gjør forskning til en lek. Hentet fra Helsedirektoratet. (2013). Utviklingsforstyrrelser(F80-F89). Hentet fra Hernes M., og Larsen K. (2012). AUTISME OG ATFERDSANALYSE til evigheten og forbi. Oslo: Gyldendal Akademisk. Matsuda G., og Omori T. (2001). Learning of joint visual attention by reinforcement learning. In E.M.Altmann & A. Cleeremans (Eds.), Proceedings of the fourth international conference on cognitive modeling (pp ). Mahwah, NJ: Lawrence Erlbaum Associates. Miller, G. A. (1955). The Magical Number Seven, Plus og Minus Two Some Limits on Our Capacity for Processing Information. Psychological Review Vol. 101, No. 2, American Psychological Association. Skre, I. B. (2013). Atferdsterapi. Hentet fra Stone, D. Jarret, C. Woodroffe, M. Minocha, S. (2005). User Interface Design and Evaluation. San Francisco: Elsevier, Inc. Figur 1: Rita O. (2012). Illustration of caregiver and child engaging in joint attention. Hentet fra ntion.jpg. 61

62 Vedlegg Vedlegg 1: Brukermanual User guide 62

63 Preface This is a user manual for eyecatch, an Android game for children with autism. The game is a tool to improve the behavior in relation to joint attention - the ability to divide attention of other people in relation to an object. The game contains interactive gaze exercises that children with autism can use to train their eye-contact between themselves and other people, so they can easily share attention in relation to an object. All the administrative tasks are to be performed by an adult supervisor and the game sequence to be played by the child. 63

64 Table of contents 1. Main menu 2. Variables 3. Instructions 3.1 Administrative tasks Starting the game with a new user Continuing the game with an existing user Deleting a user Selecting a video to show when correct answer is given Touch training Displaying test score statistics Displaying level score statistics Displaying the user guide 3.2 Game sequence Tests Levels 4. Error messages and feedback 4.1 Insert username! 4.2 Username can not contain space! 4.3 Insert age! 4.4 Age has to be numeric! 4.5 You need to select a video before starting the game! 4.6 You must select minimum one user to display graph! 4.7 Are you sure you want to exit the game? 4.8 Are you sure you to delete this user? 4.8 User created! Game starting 64

65 1. Main menu Upon starting the game the main menu is displayed. From the main menu following tasks can be performed: 1. Start the game with a new user (see section 3.1.1) 2. Continuing the game with an existing user (see section 3.1.2) 3. Deleting a user (see section 3.1.3) 4. Selecting a video to show upon correct answer (see section 3.1.4) 5. Touch training - to test if the child is able to press a box and if the child likes the selected video (see section 3.1.5) 6. Displaying test score statistics of one or more users. Also offers the possibility to display the statistics in a graph (see section 3.1.6) Displaying level score statistics of one or more users. Also offers the possibility to display the statistics in a graph (see section 3.1.7) 7. Displaying the user guide (see section 3.1.8) Notice: Before starting the game a video must have been selected. 65

66 2. Variables The game contains several variables that can be set and changed by the user s preference. Time per trial Number of trials in tests Mastery criteria Duration of video to show for each correct The amount of time to press the correct box in game before the timeout and the trial is registered as a wrong answer. To set this variable see section paragraph 4. The amount of trials in tests between each level. To set this variable see section paragraph 5. The amount of correct boxes pressed in a row in levels before the level is registered as complete. To set this variable see section paragraph 6. Duration of video to show for each correct box pressed in levels. To set this variable see section paragraph 4. 66

67 3. Instructions 3.1 Administrative tasks Starting the game with a new user 1. From the main menu, press the New User button. 2. Insert username in the box below Username. The username can not contain space. 3. Insert the users age in months in the box below Age. 4. Adjust the time per trial below Timer per trial. The time can be adjusted by inserting a number in the box or dragging the slider. 5. Adjust the number of trials in test below Number of trials in tests. Number of trials in test can be adjusted by inserting a number in the box or dragging the slider. 6. Adjust the mastery criteria below Mastery criteria. Mastery criteria can be adjusted by inserting a number in the box or dragging the slider. 7. Press the Start Game button to start the game. 67

68 3.1.2 Continuing the game with an existing user 1. From the main menu, press the Existing User button. 2. Press the name of the user you wish to continue the game with. 3. Press the Start Game button to start the game. 68

69 3.1.3 Deleting a user 1. From the main menu, press the Delete User button. 2. Press the name of the user you wish to delete. 3. Press the Delete User button and confirm by clicking the OK button in the pop-up window. 69

70 3.1.4 Selecting a video to show when a correct answer is given 1. From the main menu, press the Select Video button. 2. Navigate to the folder containing the video by pressing the folders you wish to browse. 3. Select the MP4 video you wish to select. 4. Adjust the duration of the video to show for each correct by inserting a number in the box or dragging the slider in the pop-up. 5. Press the Select Video button. 70

71 3.1.5 Touch training 1. From the main menu, press the Touch training button. 2. Press the box which will appear on a random location on screen to test the user s ability to press the box and to check if the user likes the selected video Displaying test score statistics 1. From the main menu, press the Statistics button. 2. To display a graph containing the score of one or more users, check the checkbox on the row containing the user s statistics. 3. Press the Display Graph button. 71

72 3.1.7 Displaying level score statistics 1. From the main menu, press the Statistics button. 2. Press the Level Scores above the statistics table. 3. To display a graph containing the score of one or more users, check the checkbox on the row containing the user s statistics. 4. Press the Display Graph button Displaying the user guide 1. From the main menu, press the User Guide button. 72

73 3.2 Game sequence Tests The game will start and end with a test. There will also be a test between each level. Tests always have eight boxes displayed on the screen. In the tests, the face displayed on the screen will automatically gaze on one of the eighth boxes on the screen after 0.5 seconds upon starting the game. The trial will timeout after the time set by the time per trial variable upon creation of the user. A timeout will be registered as a wrong answer. Pressing a box that the face is not gazing upon will be registered as a wrong answer. Upon wrong answer the screen turns white for 1 second to indicate that a new trial is starting. A new trial will start 0,5 seconds after the white screen disappears. By pressing the box that the face is gazing on the trial will be registered as correct. The screen will turn white for 1 second to indicate that a new trial is starting. A new trial will start 0.5 seconds after the white screen disappears. 73

74 3.2.2 Levels The game contains eight levels with different amount of boxes displayed on the screen. The first two levels have no boxes on the screen. In order to register a correct trial the user has to press the eyes of the face displayed on the screen. In the levels containing boxes the users has to press the eyes of the face displayed on the screen, which will make the face gaze upon one of the boxes. The user now has to press the box the face is gazing upon in order to register a correct answer. A correct answer will display the selected video for the duration set upon selection of the video. The trial will timeout after the time set by the time per trial variable upon creation of the user runs out. A timeout will be registered as a wrong answer. Pressing a box that the face is not gazing upon will be registered as a wrong answer. Upon a wrong answer the screen turn white for 1 second to indicate to the user that a new trial is starting. In order to pass a level the user need to have an amount of correct answers in a row equal to the master criteria. The master criterion is set upon creation of the user. 74

75 4. Error messages and feedback 4.1 Insert username! This error message appears while creating a new user without inserting a username. To resolve this error insert a username. 4.2 Username can not contain space! This error message appears while creating a new user with a username containing a space. To resolve this error insert a username not containing space. 4.3 Insert age! This error message appears while creating a new user without inserting age. To resolve this error insert age. 4.4 Age has to be numeric! This error message appears while inserting the user s age not using numbers. To resolve this error insert an age with a number value. 4.5 You need to select a video before starting the game! This error message appears while trying to start the game before a video is selected. Upon receiving this error message, you will automatically be sent to the Select Video page. To resolve this error navigate to the folder containing the video by pressing the folders you wish to browse and select the mp4 video of your choice. 4.6 You must select minimum one user to display graph! This error message appears while trying to display a graph without having selected one or more users. To resolve this error, check the checkbox on the row containing the user s statistics and then press the Display Graph button. 4.7 Are you sure you want to exit the game? This feedback is given after pressing the back button while in the game. This feedback is given to confirm the action, preventing the user from exiting the game by mistake. 4.8 Are you sure you want to delete this user? This feedback is given when the user tries to delete a user. This feedback is given to confirm the action, preventing user from deleting a user by mistake or deleting the wrong user. 75

76 4.8 User created! Game starting This feedback is given when a user is successfully created and the game will start. 76

77 Vedlegg 2: Interaktiv prototype 77

78 78

79 79

80 80

81 Vedlegg 3: Task Cards Task Cards Oppgave 1. Lag en ny bruker Oppgave 2. Velg en video Oppgave 3. Velg brukeren din og start et nytt spill Oppgave 4. Finn grafer over statistikk for din bruker Oppgave 5. Start Touch Training Oppgave 6. Slett din bruker 81

82 Vedlegg 4: Testresultater 82

83 Vedlegg 5: Intervju Intervju Effektivtet a. Var det lett å finne hva du er ute etter? b. Synes du brukergrensesnittet (skjermbildene) var intuitivt? Tidsbruk a. Oppsto det situasjoner som du mener burde vært unngått? b. Brukte du mye tid på å utføre oppgavene dine? c. Har du noen tanker om hvordan oppgaven kunne været utført enklere og/eller raskere? Engasjement a. Synes du applikasjonen har et tiltrekkende design? b. Finner du den informasjonen du trenger for å utføre oppgavene dine? 83

84 Toleranse a. Hva gjør du når feil oppstår? b. Hva gjør applikasjonen (systemet) når feil oppstår? Enkelhet a. Var applikasjonen enkel å ta i bruk? b. Føler du at det er behov for en bruksanvisning? c. Finner du ikonene som selvforklarende i filbehandleren? d. Var det enkelt å skille mellom ulikt innhold? e. Var det enkelt å mestre oppgavene du ble gitt? Forslag til forbedringer a. Har du noen forslag til forbederinger? 84

85 Vedlegg 6: Samtykkeerklæring Samtykkeerklæring for test av applikasjonen eyecatch Hvem er vi? Vi er en studentgruppe som jobber med hovedprosjekt i Anvendt Datateknologi ved avdeling for Teknologi, Kunst og Design ved Høgskolen i Oslo og Akershus. Prosjektgruppen består av Richard Olav Rud og Simon Pettersen Nguyen. Oppdragsgiver er Lars Klintwall ( lars.klintwall@hioa.no ). Veileder er Kirsten Ribu ( kirsten.ribu@hioa.no). Beskrivelse av prosjektoppgaven og brukertesting Vårt prosjekt går ut på å lage et interaktivt spill for barn med autisme for å trene deres evne til å følge blikk- det som på fagspråket kalles felles oppmerksomhet. Manglende evne til følge blikk er ofte noe som manglende hos barn med autisme. Spillet vi har laget skal brukes av barn med autisme sammen med voksene og fagfolk. Hensikten med denne brukertesten er å kartlegge hvordan den generelle menyen og innstillingene er å bruk for voksene personer. Vi ønsker å avdekke eventuele forbedringer i selve designet. Selve brukertesten består av en rekke oppgaver som skal utføres i applikasjonen. Etter oppgavene er utført vil du bli stilt en rekke sprøsmål om applikasjonen. Frivillig deltakelse All deltakelse er frivillig. Det vil bli tatt notater underveis av testingen, men all informasjon vil bli gjort anonymt. Du kan når som helst avslutte testingen på vegne av barnet eller trekke tilbake informasjon som er gitt under testingen. Anonymitet Informasjonen fra intervjuet vil være anonymt og brukt som informasjon i prosjektoppgaven til å analysere bruken av systemet. Det vil si at ingen andre enn prosjektgruppen vil vite hvem som er blitt intervjuet, og informasjonen vil ikke kunne tilbakeføres direkte til deg. Før intervjuet begynner, ber vi deg samtykke i deltagelsen ved å undertegne på at du har lest og forstått informasjonen som er gitt og ønsker å delta. Samtykke Jeg har lest og forstått informasjonen over og gir som foresatt for barnet samtykke til å delta i testen. Sted og dato Signatur Testperson Sted og dato Signatur Testansvarlig 85

86 Vedlegg 7: Arbeidsplan Arbeidsplan Aktivitet Beskrivelse Ferdig Innledene Statusrapport Beskrivelse av gruppen og prosjektet Prosjektskisse Presiserer prosjektet Prosjektdagbok Beskrivelse av hva vi har gjort etter hver arbeidsdag Prosjektnettside Nettside for prosjektet Forarbeid og forretningsmodellering Forprosjektrapport Beskrivelse av prosjektet Arbeidsplan Plan over hva som må gjøres i prosjektet Fremdriftsplan Hvor mye tid som er satt av til de ulike delene i prosjektet Kravspesifikasjon Datainnsamling Samle inn informasjon fra oppdragsgiver Dataanlyse Analysere innsamlet informasjon og vurdere denne Kravspesifikasjon Beskrive detaljert hva systemet skal gjøre Analyse og design Utvikle prototype Se på kravene og lage en prototype ut i fra dette Implementering Design av brukergrensesnitt Produsere brukergrensesnitt for systemet Koding Produsere de ulike delene i systemet Testing Intern testing Test systemet internt i prosjektgruppen Ekstern testing Oppdragsgiver får testet systemet Finepusse kode FInpusse kode og rette resterende feil Utrulling Ferdigstille sluttprodukt Gjøre ferdig systemet for frislipp Dokumentasjon Brukermanual Legge ved dokumentasjon vedrørende bruk av systemet Prosjektrapport Levering av ferdigstillt prosjektrapport Avsluttning Produsere presentasjon Lage presentasjon Presentasjon Prensentasjon av prosjektet i auditorium

87 Vedlegg 8: Fremdriftsplan 87

88 Vedlegg 9: Risikoplan Risiko Sannsynlighet Konsekvens Strategi Tekniske problemer Meget høy Alvorlig Sikkerhetskopier, Git Sykdom og skade Moderat Akseptabel Rask omorganisering av oppgaver Konflikter Liten Moderat God dialog, bruk veileder som megler Forsinkelser Moderat Alvorlig Planlegge arbeidet nøye, ha regelmessige møter med alle innvolverte parter, følge opp fremdriftsplanen Dårlig samarbeid Liten Alvorlig Jevn fordeling av oppgaver, god dialog Mister kontakt med oppdragsgiver Liten Katastrofal Holde kontinuerlig dialog 88

89 Vedlegg 10: Avtale med oppdragsgiver 89