SUPPLERENDE KOMMUNIKSJONS ASSISTENT

Transkript

1 SUPPLERENDE KOMMUNIKSJONS ASSISTENT Stian Åsen Anton Ilchenko Ole Johnny Wahlstrøm Shanmugarajah Senthilkumaran Høgskolen i Oslo og Akershus

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Supplerende kommunikasjon assistent DATO ANTALL SIDER / BILAG 100 PROSJEKTDELTAKERE Stian Åsen s Anton Ilchenko s Ole Johnny Wahlstrøm s Shanmugarajah Senthilkumaran s INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Kirsten Ribu KONTAKTPERSON Kirsten Ribu SAMMENDRAG Prosjektet er bestilt av Kirsten Ribu som en del av hennes forskning på velferdsteknologi. Oppgaven går ut på å utvikle en alternativ og supplerende kommunikaskons app for smarttelefoner. Denne skal kunne benyttes av personer med språkvasker av ulike grader. For å få til dette har vi funnet brukergrupper som har behov for kommunikasjonshjelpemidler. Løsningen er utviklet ved hjelp av prototyping og brukertester. 3 STIKKORD Prototyping Brukertesting Språkvansker 1

3 1 Sammendrag Kirsten Ribu har gitt en oppgave som er relevant for forskingen hennes innenfor velferdsteknologi. Da spesielt alternativ og supplerende kommunikasjon. Oppgaven baserer seg på utvikling av et digitalt hjelpemiddel for smarttelefoner. Det ble ikke gitt spesielle rammebetingelser og men hun kom med forslag og sine preferanser underveis. Under utviklingen av prosjektet har vi funnet forskjellige brukergrupper innenfor personer med talevansker. For å dekke de fleste har vi delt oppgaven i tre deler. De tre delene vil kunne brukes sammen eller hver for seg, alt etter brukerens preferanser. Blissmodulen er for personer som bruker symbolspråk for å kommunisere eller som et læringsverktøy. MYOmodulen er for personer som bruker tegnspråk. Denne modulen gir brukerne mulighet til å bruke tegnspråk til å kommunisere via smarttelefonen. Dialogmodulen er en tekst til tale og tale til tekst funksjon for personer uten taleevne. Prototypene vi har utviklet kan testes ut på linkene under. Dialogmodul: Blissmodul: MYO-Modul: 2

4 Innhold 1 Sammendrag Innledning Oppgavetekst Mål Utfordringer Rammebetingelser Oppdragsgiver Gruppen Organisering av rapporten Produktet Ide Brukergrupper Beskrivelse Installeringsprosess Utfordringer Moduler Bliss Innledning Symbolspråk Hva er Bliss Hvem bruker bliss? Språkvansker Cerebral parese Hodeskader Autisme Dysleksi Dagens løsninger BlissOnline Misterbliss BlissType Problemer

5 Metode Prototype Idemyldring Skisser Brukertesting Intervju Observasjon Resultat Prototype v Mål Kravspesifikasjon Funksjonelle krav Ikke funksjonelle krav Skisser Forkastede ideer Prototypen Utfordringer Løsning utfordringer Resultat Tastaturfelt Symbolfelt Utskriftfelt Brukertester Konklusjon Kravspesifikasjon v Funksjonelle krav Ikke funksjonelle krav Prototype v Mål Skisser Utfordringer Resultat Ikke implementert

6 Brukertester Resultat Kravspesifikasjon Funksjonelle krav Ikke funksjonelle krav Modulbeskrivelse Bruksområde Diagrammer Flytdiagram USE CASE Diskusjon Gyldighet Oppdragsgiverstilbakemelding Kunne gjort annerledes Databasen Brukertesting Programmeringsspråk Videreutvikling Flere funksjoner Konklusjon MYO-Modul Innledning Målgruppen Lignende Enable Talk MotionSavvy's UNI TDD&TTY Prosess og metoder Forskning Observasjon Rollespill UML Aktivitets diagrammer

7 Design Skisser Prototyper Intervjuer og brukertesting Resultat Tegnspråk Bruk av Tegnspråk Døvhet Stumhet Cerebral parese Løsning forslag Observasjon Kravspesifikasjoner versjon Funksjonelle kravspesifikasjoner Ikke funksjonelle kravspesifikasjoner Skisser Prototyping Prototype v Formål med prototype v Tilbakemeldingene Prototype v Utfordringene Formål med prototype v Utvikling Tilbakemeldingene Prototype v Formål med prototype v Utviklingen av prototype v Tilbakemeldingene Diskusjon Gyldighet Veien videre Avsending

8 Frihet i bevegelser Alternativ for MYO Bruk av bliss tastatur modul Mottak av meldingene Konklusjon Dialogmodul Innledning Brukergrupper Metoder Prototype Kravspesifikasjon Kravspesifikasjon Kravspesifikasjon Kravspesifikasjon Kravspesifikasjonen 0.4 (resultat av versjonene 0.1, 0.2 og 0.3) Skisser og bilder av prototype Brukertester: Resultat Analyse av brukertester Resultat av brukertester Prototypen Konklusjon Prosessen Om gruppen Oppdragsgiver og veileder Oppgavetekst Oppgavens formål Faglig bakgrunn Grunnleggende programmering Webprosjekt Prototyping Systemutvikling Menneske Maskin Interaksjon

9 4.5.6 Universell utforming Informasjonsarkitektur Gruppens mangfold Styringsdokumenter Risikoanalyse Milepælsplan Arbeidsmetoder Valg av leder Arbeidsfordeling Utviklingsmetode Vår metode Logg Informasjonsinnhenting Mål Utfordringer Resultat Splitting Modul informasjonsinnhenting Ideutvikling, skisser samt papirprototyper Mål Utfordringer Resultat Prototyping Mål Utfordringer Resultater Brukertesting Mål Utfordringer Resultater Videreutvikling av prototype Mål Utfordringer

10 Resultat Dokumentasjon (Rapportskriving) Diskusjon Gyldighet Oppdragsgivertilbakemelding Alternativ prosess Videreutvikling Brukertester Flere moduler Utvikling av SKA APP Konklusjon Oppdragsgivers nytte av prosjektet Egenevaluering Videre arbeid Referanser Vedlegg Testdokumentasjon Blissmodulen Første blissmodultest Om testen Testpersoner Gjennomføringen Testperson Resultat av test Observasjoner tilbakemeldinger Testperson Resultat av test Observasjoner tilbakemeldinger Testperson Resultat av test Observasjoner

11 tilbakemeldinger Andre blissmodultest Om testen Testpersoner Gjennomføringen Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger MYOmodulen Test av prototype v Identifikasjon Sammendrag Avvik i forhold til testplan Avvik i produktet Resultat Testperson

12 Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger Vurdering av produktet som er testet Test av prototype v Identifikasjon Avvik i forhold til testplan Avvik i produktet Resultat Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test Observasjoner Tilbakemeldinger Vurdering av produktet som er testet Test av prototype v Identifikasjon Avvik i forhold til testplan Avvik i produktet Resultat Testperson Resultat av test Observasjoner Tilbakemeldinger Testperson Resultat av test

13 Observasjoner Tilbakemeldinger Vurdering av produktet som er testet Dialogmodulen

14 2 Innledning 2.1 Oppgavetekst Gruppen vår ønsker å hjelpe personer uten taleevne til å lettere kommunisere. I kurset Menneske, maskin og interaksjon fikk vi som oppgave å utvikle et alternativt kommunikasjonsmiddel for mennesker med redusert kommunikasjons evne. Vi har valgt å videreføre dette prosjektet til vår bacheloroppgave. Vi skal utvikle et kommunikasjonshjelpemiddel for mennesker som har problemer med å kommunisere med andre mennesker via tale. For å løse problemstillingen, vil vi utvikle moduler som dekker deler av brukergruppen. De modulene vil vi samlet i ett ferdig produkt Mål Funksjoner vi ønsker å utforske er: - Utvikle en applikasjon som gir en dialogflyt mellom to brukere. Vi ønsker å integrere tekst-til-tale og tale-til tekst i applikasjonen. - Bruke bevegelsessensoren MYO til å konvertere tegnspråk om til tale. - Integrere symbolspråket Bliss inn i en applikasjonen Utfordringer Det finnes mange hjelpemidler til personer med nedsatte taleevner. Og bakgrunnen for denne funksjonsnedsettelsen er mange, det kan være medfødt eller oppstått på grunn av sykdom og eller en skade. Det at denne brukergruppen som har nedsatte taleevner er så bred gjør at løsningen vår må være fleksibel nok til å dekke alle behovene deres. 13

15 2.1.3 Rammebetingelser Det ble ikke gitt noen konkrete rammebetingelser fra oppdragsgiver uten om at det skulle utvikles for smarttelefoner. Dette skulle gi oss friheten til å finne smarte ideer og løsninger. 2.2 Oppdragsgiver Vår oppdragsgiver er Kirsten Ribu. Hun arbeider som professor på Høyskolen i Oslo og Akershus. Hun har også vært vår veileder under bacheloroppgave. Normalt sett når man ikke bruker en reel arbeidsgiver i forbindelse med bacheloroppgave, så er det vanlig at oppdragsgiver utformer en problemstilling som gruppen skal løse. Vi sendte heller Kirsten en prosjektbeskrivelse som hun godkjente. Vi ble enige om å gjøre det slik da dette gav oss frie tøyler. 2.3 Gruppen Gruppen vår består av Senthil, Ole, Anton og Stian. Alle sammen begynte i 2012 på studiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. I løpet av de snart tre årene vi har studert så har vi tilegnet oss faglig bakgrunn og tilstrekkelige forutsetninger til å kunne løse denne oppgaven. 2.4 Organisering av rapporten Rapporten er bygd opp på følgende måte. Først presenterer vi ideen og produktet vi har utviklet. Her beskriver vi produktet vårt og presenterer brukergruppen. Vi kartlegger også problemene vi møtte på og hvordan vi vil løse dem. Deretter presenterer vi de forskjellige modulene til produktet vårt. Vi delte oppgaven vår inn i tre deler og her går vi dypere inn hver modul. 14

16 Etter det så følger prosessrapporten. Her har vi dokumentert hvordan prosessen har vært fra en enkel ide til å sitte igjen med en ferdig sluttrapport. Diskusjon etterfølger prosessrapporten. Her drøfter vi veien videre til prosjektet. Deretter framlegger vi konklusjonen i rapporten vår. Her svarer vi på problemstillingen vi har satt oss i prosjektet. Etter konklusjonen så har vi satt opp en referanseliste og inkludert vedlegg som er relevant for prosjektet. 3 Produktet Produktet gruppen har utviklet er en applikasjon til smarttelefoner som skal hjelpe brukere som har behov for alternativ og supplerende kommunikasjon (ASK videre i testen). Navnet til vår app er SKA som er en forkortelse av supplerende kommunikasjon assistent. 3.1 Ide SKA er en app som fungerer som en kommunikasjonshjelpemiddel for personer uten eller reduserte taleevner. Vår ide var å lage en løsning som var fleksibel nok til å dekke hele brukergruppen. 15

17 3.2 Brukergrupper SKA skal kunne brukes av alle som har nedsatte taleevner. I denne gruppen er det mange forskjellige personer. Grunnen til talevanskene er mange og kompliserte. Dette gjør at SKA må være svært fleksibel og brukervennlig for å dekke det brede spekteret av brukergrupper. Brukergruppene vil bli bedre og mer nøye forklart etter hvert som vi presenterer løsninger for de diverse brukergruppene. 3.3 Beskrivelse SKA er en app med mange moduler bygget inn. Meningen med modulene er at de skal gi brukerne stor grad av fleksibilitet. Dette gjør at brukeren velger modulene som passer deres behov og da får dekket deres behov og kun det. De blir på denne måten ikke forstyrret av funksjoner de ikke trenger. I tillegg vil dette redusere bruk av lagringskapasitet og minnebruk på mobilen Installeringsprosess 16

18 3.4 Utfordringer Oppgaven er bred, og vil kreve mye ressurser å utvikle til et ferdig produkt. Vi måtte derfor avgrense oppgaven til noen brukergrupper. Ved å gjøre dette har vi kunnet utvikle løsninger med høyere kvalitet enn om vi hadde gått for bredt ut. 3.5 Moduler Nedenfor så finner man presentasjoner av de tre forskjellige modulene som har blitt utviklet av oss i følgende rekkefølge: - Bliss - Myo - Dialog Bliss Innledning Det å kunne kommunisere digitalt, er i dagens samfunn ett viktig verktøy og en svært viktig del av hverdagen til de fleste mennesker. Men ikke alle har muligheten til å delta i dette. Det er ikke på grunn av mangel på vilje, men mangelen på systemer utviklet eller tilpasset personer som trenger assisterende og supplerende kommunikasjon. 17

19 Som en del av vår app, som skal gjøre det mulig for personer med behov for assisterende og supplerende kommunikasjon å kommunisere via smarttelefonen. Ønsker vi å utvikle en løsning som vil gi personer som bruker symbolspråk til å kunne kommunisere via smarttelefonen Symbolspråk Det finnes flere typer symbolspråk, og de er forskjellige på mange måter. Forskjellen er da ofte hvor komplekse setninger det er mulig å lage med dem. Noen er veldig enkle og kan nesten sammenlignes med rebusoppgaver. Andre er mer komplekse og gir brukeren muligheten til å bruke verb og proporsjoner osv. Bliss er et fullverdig språk, med syntaks og grammatikk. Dette gjør at brukerne av språket kan utrykke seg på en nyansert måte. Det er også mulig å utrykke abstrakte ting og følelser. Noe som ikke er vanlig i andre symbolspråk. Vår oppdragsgiver Ribu, forsker på velferdsteknologi, inkludert Bliss. Når gruppen fortale om planene om å utvikle en løsning for personer som benytter seg av symbolspråk. Ønsket hun at vi skulle utvikle løsningen for språket Bliss Hva er Bliss Statped (Statped, 2012) forteller at Bliss er ett internasjonalt, grafisk system der ord og begreper representeres av logiske tegn i stedet for bokstaver. Dette er en del av alternativ og supplerende kommunikasjon. Tegnene er laget slik at de skal oppfattes på samme måte uansett erfaringsbakgrunn, alder, språk, kjønn og kulturelle forskjeller. Bliss kan også brukes som ett hjelpemiddel for å lære språklige strukturer og grammatikk. Samt for å en dypere forståelse av ordene. Bliss kan være nyttig permanent, men blir også brukt midlertidig. Bliss består av over 100 grunnsymboler som sammen utgjør symbolene. Ved å kombinere dem kan man lage nye ord og utrykk. I 2012 var det 4500 offisielle blissymboler, og det kommer flere hele tiden. 18

20 Hvem bruker bliss? Det er flere grupper som bruker Bliss, noen benytter seg av det permanent, mens andre bruker språket i midlertidig i undervisning av språk. Vår veileder har informert oss om at bruken av bliss i Norge ikke er spesielt utbredt, men at det er et potensielle brukergrupper som vil kunne benytte seg av det. Bruken er mer utbrett i utlandet, for eksempel i Sverige Språkvansker Ifølge Statped (Statped, 2012) brukes Bliss som ett hjelpemiddel i begrepsopplæring, grammatikkopplæring og språklig bevissthetstrening. Bliss brukes da som et supplerende alternativ. For noen kan bliss også fungere som et permanent lese og skrivesystem Cerebral parese Cerebral parese er en fellesbetegnelse av en gruppe sykdommer. Felles for sykdommene er at pasientene har sviktende kontroll av muskelbevegelse, som følge av skader i hjernen. Skadens årsak og symptomer er mange. (Seip, 2009) Hodeskader Hodeskader kan føre til mange typer diagnoser, men en stor årsak til skaden er hjerneslag. Det er hvert år ca pasienter med hjerneslag i Norge hvert år. Slaget påvirker pasientene i forskjellig grad, men ofte ledsaget afasi (Nyberg-Hansen, 2012) Autisme Personer med Autisme har ofte nedsatt språkevner. Vanlige pedagogiske metoder kan være utfordrende å gjennomføre. Bliss kan brukes som et hjelpemiddel i språkopplæring av personer med autisme (Kausrud & Bangstad). 19

21 Dysleksi I møter med vår oppdragsgiver, gjort oss oppmerksom på at personer med kraftig dysleksi kan bruke bliss som et hjelpemiddel Dagens løsninger Her vil vi liste opp digitale blissløsninger. Målet er å se hva som finnes og lære av de forskjellige løsningene BlissOnline Nettsiden tilbyr brukerne å laste ned egendefinerte blisstavler. De har også en leksikonfunksjon der det er mulig å finne alle symboler og forklaringer. Den siste funksjonen de tilbyr er en tekstbehandler. Her kan brukeren skrive på norsk og teksten blir oversatt til blisstegn. BlissOnline tilbyr dette mot en lisens på 43Euro. Det er mulig å prøve produktene, men da er funksjonaliteten svært redusert Misterbliss ser ut som ett lovende program for å skrive digitalt med Bliss. Problemet er at det bare er på italiensk. Denne videoen viser hvordan programmet fungerer: BlissType BlissType er en prototype av en bliss tekstbehandler. Denne løsningen fungerer slik at symbolene blir delt opp i grunnleggende former. Som Horisontal strek, vertikal strek, trekant og sirkel osv. Så klikker man på den formen som er i symbolet du er på jakt etter. Da oppdateres tastaturet og inneholder nå bare symboler med denne grunnleggende formen. Dette gjentas til symbolet et funnet. Når man har funnet symbolet får man muligheten til å legge til indikatorer for verb og adjektiver. 20

22 Problemer Med alle programmene som er utviklet for å kommunisere med bliss, ser vi en del svakheter som går igjen. De er alle utviklet enten for datamaskiner eller for nettbrett. De er ofte veldig kompliserte og fungerer mer som at brukeren må lage symbolet. Vi ønsker å forenkle løsningen ved at vår løsning skal fungere med færre klikk og ha et mer simpelt arkitektur Metode Oppgaven om å lage en digital løsning for bruk av bliss symbolspråk er ganske bred. Med tanke på dette er det mange måter å løse oppgaven på. For at vår løsning skal bli best mulig er det viktig at vi bruker gode metoder for å hente ut data Prototype For å teste om løsningen vi utvikler har de riktige funksjonene og tilpasningene. Utvikler vi prototyper slik at vi kan teste dem på brukerne. Ved å gjøre dette kan vi videreutvikle kravspesifikasjonen og løsningen vår får bedre kvalitet Idemyldring Da vi begynte utviklingen av løsningen, trengte vi å få noen ideer vi kunne utforske. Dette ble gjennomført med Post-it metoden. Den ble gjennomført ved at alle skrev sine ideer på lapper og la dem i en bolle. Vi gjennomgikk alle lappene i felleskap og diskuterte ideene. Lappene ble så plassert i en av to bunker, dårlig og bra. Lapper som kom i bra bunken ble med videre i utviklingen av løsningen Skisser Før vi startet å lage prototyper, laget vi skisser. Dette gjør vi fordi de er billige i både ressurser og tid. Vi tegnet skisser hver for oss, og presenterer dem for hverandre. Vi 21

23 diskuterer løsningene, og fikk avdekket eventuelle problemområder. Når det ble oppdaget problemer, måtte de utbedres før neste arbeid med prototypen kan begynne Brukertesting Brukertestene er en viktig del av oppgaven. Det er i denne delen vi finner ut om prosjektet er på riktig vei. Det er brukerne som avgjør om løsningen er bra eller ikke. Hvis brukertestene viser negative resultater, betyr det at prototypen har forbedringspotensialet. Da må prototypen utbedres og testes på nytt. Brukertestene ble utført på personer som ikke er i brukergruppen. Dette er på grunn av at personer i brukergruppen ikke er lett å få kontakt med. Men dette hindret ikke oss i å få testet funksjonaliteten til prototypen Intervju Fokuserte intervjuer ble utført etter at testpersonen har gjennomført oppgaven. Med denne metoden ønsket vi å få positive og negative svar fra testpersonene. Det er også være nyttig å høre hva dem syntes kunne vært løst på en annen måte Observasjon Observasjon er en metode som vi brukte under brukertestene. Ved å bruke denne metoden, fant vi ut hvordan testpersonene gjennomfører brukertesten. For eksempel om brukeren gjør feil eller noe uventet Resultat Prototype v Mål 22

24 Målet for er å utvikle prototypen til å oppfylle kravene i kravspesifikasjon. Prototypen skal da være klar til å testes på testpersoner Kravspesifikasjon Med informasjonen vi har hentet inn, har vi fått laget en kravspesifikasjon. Denne vil vi da bruke til å utvikle prototypen vår. Kravspesifikasjon vil naturligvis endre seg under prosjektet, etter oppdagelser som gjøres Funksjonelle krav Brukeren skal kunne finne ett bestemt blissymbol. Brukeren skal kunne velge symbol Ikke funksjonelle krav Systemet må være hurtig. Systemet må være stabilt Skisser Gruppemedlemmene laget skisser individuelt, for å ikke forurense ideene. Når alle hadde laget ferdig sine skisser, presenterte personen skissene for resten av gruppen. Etter hver presentasjon diskuterte vi forslaget. Etter at alle hadde fått vist frem sin ide. Tegnet vi en felles skisse som prototypen skulle bygges på. Denne er som vist under. Vi ønsket å gjøre det så enkelt som mulig, og heller bygge videre på den. 23

25 Utskrift delen av skissen er bare ment som en oppbevaring av alle valgte symboler. Slik at man kan bruke symbolene til å kommunisere med samtalepartneren. Tastatur delen viser at noen av tegnene vi mener ofte brukes i symbolene til bliss. Meningen er å lage en database der vi deler opp alle tegnene inn i grunnsymboler. For eksempel symbolet for bilde: Dette symbolet har grunntegnene sirkel, prikk og forkant. På denne måten ønsker vi å kunne sortere hvilke tegn som blir vist for brukeren. Velg symbol delen av skissen, er feltet der brukeren kan velge ønsket symbol. For å minimere antall symboler som blir presentert, må brukeren bruke tastaturet. Da vil listen med symboler oppdatere seg med symboler som har grunntegnene som er valgt. 24

26 Forkastede ideer Vi undersøkte hvordan kinesiske tegn blir skrevet på datamaskiner. Vi fant ut at det ikke lot seg gjøre på samme måte med bliss. Det på grunn av at de skriver utalen til ordet i det latinske alfabetet, og velger da riktig kinesiske tegn ut i fra dette. Dette skriftspråket heter Pinyin Prototypen Utfordringer Ved utformingen av prototypen fikk gruppen problemer med å implementere kravene til kravspesifikasjonen. Tanken var å utvikle en papirprototype, slik at den skulle være rask og enkel å lage. Vi ønsket ikke å bruke mye tid på den, da det var stor mulighet for at den ville bli forkastet. Funksjonen med å finne riktig tegn var spesielt vrien å få til i en papirprototype. Nå som vi skjønte at vi måtte lage prototypen digitalt, kom det flere problemer. Det finnes ingen Bliss Unicode font, som gjør at man kan bruke bliss digitalt uten å bruke simuleringer. Det var ett problem å finne bilder av symbolene vi kunne til prototypen Løsning utfordringer Vi valgte da å lage prototypen i HTML, CSS og PHP. HTML og CSS ga oss muligheten til å gi prototypen oppsette vi ønsket og PHP ga oss funksjonaliteten vi ønsket. For å skaffe oss alle blissymbolene fant vi et stort bilde av en bliss tavle. Ved å klippe ut hvert enkelt symbol fra denne tavlen fikk vi 528 symboler i størrelsen 90 x 90px. Bilde inneholdt også ordet for symbolet, noe som var viktig for oss da, ingen i gruppen kan lese blissymboler Resultat Prototypen vi har utviklet består av tre deler, en utskriftdel, tastatur og en liste med symboler. Den har ett ganske enkelt design uten farger. Det eneste er at den har svarte skillelinjer mellom de ulike funksjonene. 25

27 Tastaturfelt Tastaturet er bygget opp av 13 grunntegn, som vi mener er de mest vanlige formene i ett blissymbol. Vi har da lagd alle grunntegnene inn i en mappe kalt tastatur. En Funksjon i PHP, leser alle filene i mappen og skriver ut tastaturet på skjermen. Når man trykker på et grunntegn, er det som å klikke på en lenke. Men det er med en variabel i den nye url adressen. For eksempel Her er sirkel verdien til variabelen tast. Den nåværende listen med symboler som blir vis i feltet symbolfelt, blir nå sammenlignet med alle tegn med grunntegn sirkel. Alle symboler som ikke inneholder grunntegn sirkel blir slettet fra listen. 26

28 Symbolfelt Som standard viser listefeltet alle symbolene som er lagret i databasen. Denne listen er alltid organisert etter alfabetisk rekkefølge, dette kommer av navnet på bilde som er lagret i databasen. Når brukeren trykker på ett symbol i listen vil symbolet bli sendt til område for utskrift og listen vil resette seg selv og igjen vise alle symbolene Utskriftfelt Denne delen av prototypen har ingen annen funksjon enn å vise hvilke symboler som har blitt valgt av brukeren Brukertester For å finne ut funksjonaliteten til prototypen testet vi den ut på noen medstudenter. Testen ble utført ved at de fikk se symbolene til setningen «jeg vil på kino». Etter en kort gjennomgang om hvordan tastaturet med grunntegnene virket begynte testen. Under brukertestene observerte vi brukerne og tok tiden på hvor lang tid de brukte på å finne symbolene. Etter testen intervjuet vi testpersonen, for å høre deres meninger. Vi var spesielt interessert i mulige forbedringer. Testdokumentasjonen ligger i vedlegg 1, under kapittel Første blissmodultest Konklusjon Alle personene klarte å gjennomføre testen på en tilfredsstillende måte. Noe som beviser at det er mulig å bruke bliss digitalt. Testpersonene ga oss mange gode forslag til å forbedre prototypen. De ønsket flytte tastaturet og utskriftfeltet nederst på skjermen. Gjøre systemet tolerant for feil Sortere symbollisten etter farge eller antall grunntegn i symbolet. 27

29 Kravspesifikasjon v2 På bakgrunn av brukertestene har vi kunne utformet en ny kravspesifikasjon. Vår neste prototype vil være utformet for å imøtekomme kravene til denne Funksjonelle krav Brukeren skal kunne finne ett bestemt blissymbol. Brukeren skal kunne velge symbol. Brukeren skal kunne fjerne valgt grunntegn. Systemet skal sortere symbolfelt etter antall grunntegn i symbolet. Brukeren må kunne fjerne valgt symbol. Systemet må gi tilbakemelding om valgt grunntegn Ikke funksjonelle krav Systemet må være hurtig. Systemet må være stabilt. Det må være mulig å se symbolene samtidig som man bruker tastaturet Prototype v Mål Etter å ha brukertestet den førsteversjonen av prototypen, har vi funnet flere funksjonelle og ikke funksjonelle krav til løsningen. Vi har da utviklet prototypen til å imøtekomme de nye kravene Skisser Vi startet videreutviklingen av prototypen med å skissere ideene våre. På dette tidspunktet var vi allerede ganske sikre på hvilke forandringer vi ønsket å gjøre. 28

30 Utfordringer Kravet om å sortere symbolene i listen etter antall grunntegn i symbolet viste seg å være utfordrende å implementere. Databasesystemet som prototypen var bygget på lot seg ikke enkelt implementere dette kravet. Andre krav gjorde at mye av koden til prototypen måtte forandres. Dette førte til at det oppsto feil i koden, som vi brukte tid på å fjerne Resultat I den nye versjonen av prototypen har vi lagt til en del nye funksjoner som: Muligheten til å fjerne valgt symbol fra utskriftfelt. Dette er med på øke tolerangen for feil, da man kan redigere utskriftfeltet. Før måtte prototypen restertes når brukeren trykket på feil symbol. 29

31 Når man trykker på ett grunntegn, blir dette tegnet 40% mindre synlig. Dette illustrerer at symbolet er valgt. Denne funksjonen er svært nyttig da brukeren har trykket på flere grunntegn. Uten en tilbakemelding om hvilke tegn som er aktive, glemmer brukeren dette og gjør oftere feil. Ved å trykke på ett symbol som allerede er valgt, vil dette grunntegnet ikke lenger være med i symbolisten. Dette er nyttig da brukeren trykker på feil grunntegn eller at brukeren ikke finner ønsket symbol. Feltene tastaturfelt og utskriftfelt er flyttet nederst på skjermen. Dette er en bedre plassering for tommelen, og det er mulig å se symbolisten samtidig om man bruker tastaturet. Bedre optimalisert for mobile skjermer. Da spesielt Samsung s4, på grunn av at brukertestene ble gjennomført på en slik smarttelefon. Under vises ett skjermbilde av prototypen. Her kan man se at Symbolet «jeg» er valgt og er plassert i utskriftfeltet. Tastaturet har to aktive knapper, åpen trekant og hjerte. Denne vises ved at de vises svakere enn de andre grunntegnene. Symbolfeltet er da oppdatert etter de to aktive grunntegnene. 30

32 Ikke implementert Kravet «Systemet skal sortere symbolfelt etter antall grunntegn i symbolet», ble ikke implementert i denne versjonen av prototypen. For å implementere denne må hele databasen til prototypen lages på nytt. Dette ville tatt for lang tid, og ville ikke blitt ferdig i tide. Vi droppet derfor å dette kravet under denne versjonen. Men kravet vil fortsatt stå i kravspesifikasjonen, slik at den kan bli implementert på et senere tidspunkt Brukertester Brukertestene ble gjennomført på samme måte som forrige test, med noen forandringer. Denne gangen forklarte vi funksjonene til prototypen mer nøye. Under observasjonsdelen var vi spesielt interessert i om tiden for å finne tegnene ble lavere. Samt å se om de nye 31

33 funksjonene hjalp brukerne på ønsket måte. Dokumentasjonen finnes i testdokumentasjonen blissfunksjon test to Resultat Under den andre brukertesten av modulen fant vi ut at tiden for å finne symbolet ikke ble noe lavere. Men dette skyldes at funksjonen for å sortere symbolfeltet ikke ble implementert i prototypen. Dette på grunn av mangel på tid. Prototypen var nå mer tolerant for feil, på grunn av at feil testpersonene gjorde unne rettes opp. De ønsket også en sterkere visualisering av aktivgrunntaster Kravspesifikasjon På bakgrunn av brukertestene har vi kunne utformet en ny kravspesifikasjon. Vår neste prototype vil være utformet for å imøtekomme kravene til denne Funksjonelle krav Brukeren skal kunne finne ett bestemt blissymbol. Brukeren skal kunne velge symbol. Brukeren skal kunne fjerne valgt grunntegn. Systemet skal sortere symbolfelt etter antall grunntegn i symbolet. Brukeren må kunne fjerne valgt symbol. Systemet må gi tilbakemelding om valgt grunntegn Ikke funksjonelle krav Systemet må være hurtig. Systemet må være stabilt. Det må være mulig å se symbolene samtidig som man bruker tastaturet. Systemet må være tolerant for feil fra brukeren. Eventuelle feil må ikke være fatale. 32

34 Modulbeskrivelse Prototypen vi har utviklet har bevist at det er mulig å bruke smarttelefonen til blissymbolspråk. På bakgrunn av dette ønsker vi å beskrive noen av bruksområdene til modulen Bruksområde Prototypen har bevist at det er mulig å skrive med blissymboler på smarttelefonen. Ved å bruke funksjonene i prototypen kan man gjøre mye med teksten brukeren skriver. Smarttelefonen er et kommunikasjonsmiddel som gir brukerne funksjoner som ring, SMS, E- post og nett surfing. Under er det en illustrasjon på hvordan brukere kan sende SMS med blissmodulen. 33

35 I bilde til venstre ser du brukeren har skrevet inn fire symboler med teksten «Jeg vil på kino». Grunntegnene pil og sirkel er valgt for å skrive neste symbol. Listen med 528 symboler er da redusert til 18 symboler. Angrer brukeren på et valg, trykker man på aktiv grunntegn eller symbol og det bil bli borte. For å sende meldingen trykker man på pilen i utskriftfeltet. Bilde til høyere ser vi samtaleloggen. Øverst ser vi brukerens melding og under er det et svar. I svaret står det «ikke i dag, kanskje i morgen». Nederst er det en knapp det står «Svare». Vi ser for oss at blissmodulen kan også brukes i sammen med dialogmodulen. Samt at brukeren får muligheten til å bruke de andre kommunikasjons metodene til smarttelefoner Diagrammer For å beskrive hvordan modulen virker har vi utarbeidet et USE CASE og flytdiagram som viser hva som skjer på de ulike stadiene i modulen. Diagrammene tar utgangspunkt i eksempelet beskrevet over med å sende SMS. 34

36 Flytdiagram 35

37 USE CASE Diskusjon Gyldighet Resultatet av utviklingen til blissmodulen viser at modulen er på rett vei. Brukertestene viser at modulen kan brukes av personer uten behov for assisterende og supplerende kommunikasjon. Dette betyr at funksjonaliteten til modulen virker. Videre må modulen testes på personer i brukergruppen for å tilpasse funksjonaliteten til deres behov. 36

38 Oppdragsgiverstilbakemelding Oppdragsgiveren har fått testet prototypen, og sett på funksjonaliteten. RIbu virket veldig overrasket over simpelheten til modulen. Ribu mener også et modulen fint kan videreutvikles som en del av vår app, eller som en egen app Kunne gjort annerledes Nå som prosjektet er ferdig og resultatet er klart. Ser vi at det er flere ting vi kunne gjort annerledes. Under vil vi diskutere hva vi kunne gjort for å forbedre resultatene til modulen Databasen Databasen i prototypen er laget på en simpel måte. Den er bygget opp av mapper, som har navnet på grunntegnene. Alle symboler som har grunntegnet firkant er lagret i mappen firkant. Så vis et symbol har tre grunntegn, er symbolet lagret i tre mapper. Det er også en mappe med alle tegnene. Symbolenebildene er lagret med navnet på symbolet. Det vil si symbolbildet for «Hei» har navnet hei.png. I en ferdig løsning er dette et veldig dårlig metode på grunn av dobbellagring og resurskrevende PHP funksjoner. Men det ga oss en lettere måte å lage databasen på. På grunn av at kravspesifikasjonen forandret seg etter første brukertest. Ønsket vi implementere en måte å sortere symbolene etter antall grunntegn de inneholder. Men med mappedatabasen vår ville ikke dette la seg gjøre. Vis vi hadde hatt mer tid, ville vi laget en database med SQL eller laget en database med objekt orientert PHP database. På denne måten kunne vi lagret mer informasjon om hvert symbol enn navn og grunntegene Brukertesting Brukertestene vi gjennomførte var bare gjennomført med funksjonsfriske personer. Dette gjorde at dataene fra brukertestene ikke er særlig nøyaktige. Vi vet ikke om personene i brukergruppen forstår ideen med å velge grunntegnene for å sortere symbollisten. 37

39 Det tok litt tid før vi begynte å lete etter testpersoner fra brukergruppen. Dette var på grunn av at vi ønsket at prototypen skulle være god nok. Vi var redde for at mulige testpersoner ville bli demotiverte vis vi presenterte et mindre funksjonell prototype Programmeringsspråk Prototypen er programmert i PHP, HTML og CSS. Dette er vanlige språk for å lage nettsider. Men måten PHP virker på ved å oppdatere nettsiden, gjør at prototypen ble tregere enn vi hadde ønsket. Vis vi hadde laget funksjonaliteten til prototypen i JavaScript, ville det vært brukerens enhet som oppdaterte nettsiden og ikke serveren. På denne måten ville vi økt responstiden til prototypen Videreutvikling Neste del av utviklingen ville være å lage en ny prototype. Da med funksjonaliteten kodet i JavaScript og en SQL database. Dette må gjøres på grunn av at nåværende prototype har noen store begrensinger, da spesielt i database delen. Vi vil da prioritere funksjonen med å sortere symbolene etter antall grunntegn i dem. Vi har stor tro på at denne funksjonen vil redusere gjennomsnittstiden med å finne ønsket symbol. Brukertesting må også gjennomføres på personer i brukergruppen. Vi må få tilbakemeldinger som er mer relevante og som kan si noe om tilgjengeligheten og brukervennligheten til løsningen Flere funksjoner For å gjøre det lettere å finne ønsket symbol vil vi også se på muligheten for å legge til en predikasjonsfunksjon. Denne vil da gjette på ordet brukeren ønsker. Dette er da ord som ofte blir brukt. Samt at når tastatur funksjonen starter vises det en liste med ofte brukte eller nyttige setninger. Som for eksempel «Jeg heter NAVN» og «Jeg er sulten». 38

40 Konklusjon Etter å ha laget en prototype og testet ut funksjonene i denne to ganger. Kan vi konkludere med at løsningen vår vil fungere som en Bliss tekstbehandler. Vi har bevist at ved testpersonene klarte å skrive setningen «Jeg vil på kino» med blissymboler. Ved å sammenligne vår løsning med andre, er løsningen vår enklere og mer effektiv. Dette på grunn av at brukeren bare kan velge mellom 13 grunntegn. I de andre løsningene var det veldig lett å rote seg bort i systemet. Vi har også gjort løsningen svært tolerant for brukerfeil. Ved å klikke på et aktiv grunntegn vil symbollisten oppdatere seg, som om grunntegnet aldri var trykket. Det er også mulig å fjerne valgte symboler fra utskriftfeltet ved å klikke på dem. Symbolene våre har samme farge som de har på en blisstavle. Dette gjør at brukeren kjenner igjen fargen og lettere finner riktig symbol. Alle andre løsninger var utviklet for nettbrett og datamaskiner. Mye av grunnen til det er nok at løsningen deres er mer komplisert og krever mer skjermplass. Vår løsning er simpel og krever ikke skjermstørrelsen til nettbrett for å fungere. Løsningen vår er ikke ferdig utviklet, selv ikke prototypstadiet er ferdig. Løsningen er bare testet på personer utenfor brukergruppen. Dette har bare gjort at vi kunne teste funksjonaliteten og ikke brukervennligheten i ønsket grad MYO-Modul Innledning I dag er brukere av tegnspråk lukket i eget miljø. Det er problematisk å komme i kontakt med dem i hverdagen. Det som skal avgjøre om løsningsforslag blir god eller ikke er kontakt med sluttbrukere. Om vi tar ikke kommunikasjon mellom oss og sluttbrukere på alvor risikerer vi at andre brukere blir steng ute. Derfor blir det spesielt viktig å definere hvem sluttbrukere er og hvilket behov de har. 39

41 Problemstilling for dette modul er «Hvordan kan mennesker med nedsatt høre og/eller taleevner bruke mobil telefon og ringe private og offentlige aktører ved hjelp av nye teknologier?» Målgruppen Målgruppen for denne modul er mennesker som bruker tegnspråk og har den som morsmål. Tegnspråk gruppen er ulik alle andre grupper vi har møtt i våre tidligere prosjekter. Det som gjør den så annerledes er at representanter fra målgruppen lever i et «lukket» miljø. Det er ikke alle menneskene som kan snakke eller forstå tegnspråk. Om en person kan tegnspråk betyr at han har venner eller familiemedlemmer som bruker det. Eller skjer det ganske skjeden at man lærere det for moro skyld. Menneskene som bruker tegnspråk er ganske forskjellige. De er på forskjellig alder, kjønn, kultur og interesser. Derfor måtte vi utarbeide løsningen ut fra at alle fra barn til de eldste skal kunne bruke denne modul Lignende Det finnes konsepter og forslag alternativer til dette modul. Under gir vi noen eksempler Enable Talk Det er en prosjekt som ble presentert på Microsoft Imagine Cup i 2012 og har vunnet første plass. Prosjekt er presentert av studenter og hoved formål for den er å oversette tegnspråk til tale. Konseptet består av 2 hansker med sensorer og en mobil enhet som har ansvar for å oversette. På nettsiden til prosjektet står det at utviklere er i stadiet av undersøkelse. 40

42 MotionSavvy's UNI UNI er et annet løsning som oversetter tegnspråk til tale og i tillegg har funksjon for å oversette språk til tekst. UNI er et brett som oppfatter hendene og alle 10 fingere på den. Produkt kommer ut på markedet på slutten av TDD&TTY Telekommunikasjon enhet for døve (Telecommunications Device for the deaf) er en teleprinter som er skapt for kommunikasjon via telefonlinjer. TDD er utviklet for menneskene med høre/tale nedsettelse. Den har også andre navn som for eksempel teletypewriter(tty) textphone og minicom. Slike enheter hadde størrelse på en bærbarpc og hadde tastatur, en LED skjerm og i noen modeller innebygd printer hvor meldingene ble skrevet ut Prosess og metoder Forskning For å lage et godt produkt som dekker målgruppen sine behov må vi studere den. Det er viktig å vite hva slags vanskeligheter gruppen har. Under forskning ønsket vi å finne grunner til at mennesker mister en av sansene, måten de kommuniserer med friske mennesker og hjelpemidler de bruker får dette Observasjon Observasjon blir en ganske viktig del av forskning. Ved å observere målgruppen vil vi lære mer om hvordan kommunikasjon mellom menneskene skjer, hvordan skjer bruk av datamaskiner og mobiltelefoner, hvilket utfordringer gruppen møter opp i hverdagslivet Rollespill Vi hadde ikke noen sikkert informasjon om målgruppen bruker mobilen til å ringe andre menneskene. Derfor kan rollespill hjelpe oss å observere målgruppen som bruker mobiltelefon for å ringe offentlige og private aktører. 41

43 UML Det finnes forskjellige typer av UML diagrammer. Noen av disse skal vi bruke for å designe denne løsning Aktivitets diagrammer Aktivitets diagrammer vil visualisere aktiviteter for å lettere gjøre implementasjon og utvikling. En slik visualisering vil også hjelpe oss å unngå problemer i design Design Skisser Skissering blir en del av vår designprosess. «Skissene er billige, kan lages på kort tid og sender signaler om uferdighet» (Buxton, 2007). Vi planlegger å bruke skisser på papir fordi at de er godt tilgjengelig for alle gruppemedlemmer, kan inspirere folk til nye ideer og skape diskusjoner rund løsningsforslag. Etter at vi blir ferdig med papir skissene lager vi noen digitale skisser som vil representere mer detaljer og beskrivelser og forslag til det ferdig design. Skissene skal vare ganske enkelt og minimalistisk, skal skapes under diskusjoner og brainstorming. Det er også viktig å gjøre disse vage for at de skal antyde nye forslag og ideer. (Sanders, 2011) Prototyper Prototyping er en godt instrument for utvikling av nytt system. Ved hjelp av prototyping metode får vi bekreftelse på inntrykkene av brukerens behov stemmer med virkeligheten. Metoden vil gjøre det lettere å velge mellom forskjellige ideer som dukker opp under diskusjons fasen. Gruppen skal kjøre flere runder med testing av prototyper for å avløse om vår ideen dekker brukeren sin behov. Grundig tilbakemeldinger fra testpersoner på en tidlig stadie av utvikling vil hjelpe oss å velge det riktig veien i utvikling. 42

44 I tillegg krever ikke metoden noen spesielle kunnskaper som for eksempel programmering. Derfor blir alle gruppemedlemmene involvert i prosessen uten noen begrensninger Intervjuer og brukertesting Intervjuene ble valgt på grunn av gruppen har ikke fått takke i stor antall testpersoner. Derfor ble vi enig om å ha intervjuer for å samle mest mulig informasjon fra de personer vi kunne teste på. Til og med kan intervjuer gi oss bredere svar på våre spørsmål. Brukertesting skal gjennomføres for å teste prototypene. Gruppen skal kjøre flere runder med brukertesting av løsningsforslag vi kommer på. Det vil hjelpe oss å se svakheter i løsningene å forbedre prototyper Resultat Tegnspråk Tegnspråk er språk som er basert på visuell kommunikasjon, og det finnes mange forskjellige og det finnes ikke noe sikker tall på hvor mange av dem finnes. Grunnen til det vær at tegnspråk har utviklet seg akkurat like naturlig som talespråk. Det er egen grammatikk i tegnspråk som baserer seg på kombinering av håndformer, plassering og bevegelser til hendene, armene, eller kroppen og ansiktuttrykk. For å begrense løsning tar vi i fokus det norske tegnspråk. Alle løsningsforslag skal baseres på at målgruppen bruker den. (Simonsen, 2013) Bruk av Tegnspråk Det finnes ikke noen sikre tall på hvor mange personer i Norge som bruker tegnspråk, men anslag fra Norges Døveforbund sier at det finnes omtrent brukere. Det er både døve, tunghørte og hørende som bruker tegnspråk. Årsaken til slike nedsettelse eller fyll tap av disse kan vare forskjellig. Alt fra genetiske problemer til skader kan føre til det. Noen ganger blir det midlertidig nedsettelse/tap, og andre ganger må man bare leve med det. 43

45 Siden det er en bredt variasjon av årsaker blir kommunikasjons måten forskjellig. Noen mennesker går tapt av taleevner og har ikke noen andre sensoriske, kognitive og motoriske problemer. Mens hos andre kommer dette problemet i sammenhengen med kognitive eller motoriske nedsettelse eler begge deler samtidig Døvhet Døvhet kan være medfødt eller oppstå senere i livet av forskjellige grunner. Trafikkulykker eller andre skader kan vare årsaken til at mennesker mister høreevner. Hvis person er født døv blir det vanligvis slik at lesing og skriving blir problematisk Stumhet Stumhet er manglende evne til å tale (Gjerstad, 2015). Det er også forskjellige årsaker til det bl.a. skade eller sykdommer i teleområdene. Døvhet kan også være årsaken til stumhet særlig hvis person er tyng hørende eller ikke hørende Cerebral parese Cerebral parese kan vare en av årsaken til at person mister stemmen eller snakker utydelig. Men i dette tilfelle blir det kanskje vanskelig å bruke en vanlig tegnspråk. Da blir det snakk om et alternativ tegnspråk som er tilpasset dette målgruppen Løsning forslag Under brainstorming og ide forlag hadde vi endt opp med 3 ideer. Den første vær å lage hansker som skal lese av hånd og finger posisjon og oversette tegn til tale. Det andre forslag var å lage en løsning hvor brukeren kan ringe et annet person og bruke tastatur for å skrive tekst. Teksten som ble skrevet av brukeren oversettes til tale og sendes til den han hadde ringt til. 44

46 Det siste ideen var å bruke MYO bevegelse kontroller for å oversette tegnspråk til tale. Den ligner litt på det første forslag, men har litt annet teknisk løsning. I tillegg til gyroskoper og akselerometer bruker MYO elektromyografi, det vil si at den leser av elektrisitet som går gjennom musklene. Gruppen ble også enig om at brukeren må kunne bruke begge hendene sine fritt uten at noe hindrer bevegelser eller gjør det ukomfortabelt. Til slutt hadde vi nektet til det første ideen med hanske på grunn av at det er ikke komfortabelt å bruke hansker. Brukeren vil alltid ha behov for å ta disse av og på igjen. I tillegg blir de såpass store at transportering av disse blir problematisk. Gruppen ble enig om at det beste løsningen blir å kombinere de to andre. Det vil være en godt alternativ å kombinere disse av forskjellige grunner Observasjon Gruppen hadde prøvd å komme i kontakt med døveforbund for å få takke i testpersoner eller presentasjon av ideen vår for ledelsen av forbund, men vi fikk negativ svar. Derfor hadde vi ikke brukt personer med funksjonshemninger og istedenfor ble alle testene gjennomført på friske personer. Gruppen har laget en del personas som testbrukere skulle bruke under testing for å få mest mulig relevant svar på spørsmålene våre Kravspesifikasjoner versjon 1 Vi har kommet med noen forslag til kravspesifikasjoner under diskusjonfasen. Det er imidlertid ikke slutte spesifikasjoner som skal brukes i ferdig løsning og skal forandres etter at vi får nok brukertester Funksjonelle kravspesifikasjoner Modul må oversette tegn minst 85% presis. Modul skal oversette tekst til tale og sende til mottaker. Modul skal oversette tale til tekst og vise det på skjermen. 45

47 Modul skal ha tilgang til kontaktliste. Brukeren må kunne starte og avslutte samtalen. Modul må kunne informere samtalepartner om at svar kan komme med forsinkelse Ikke funksjonelle kravspesifikasjoner Modul må virke uten feil. Modul må ha en god og forståelig brukergrensesnitt. Det skal vare lett å lære og navigere Skisser Forslagløsningen vår er ganske likt en vanlig ringe og sms funksjon. Derfor har vi søkt inspirasjon i eksisterende løsninger fra forskjellige operativ systemer, men det er viktig å implementere nye prosesser i anrop prosessen. For eksempel må vi implementere kobling til MYO kontroller og feilhåndtering hvis noe går galt før anrop kommer. Et annet ting vi må tenke på er avsending og mottak av meldinger. 46

48 Prototyping Utfordring med å lage en prototype vær å skape en prototype som kan illustrere tankegangen vår. Gruppen ble enig om at vi skal ikke bruke papir prototyper på grunn av at det er ganske mye som skal gjøres av veilederen til testen og trollmannen. Vi hadde valgt å lage evolusjonær prototype fordi at vi vær ikke helt sikkert på at det løsning vi skal teste på ville fungere i det opprinnelig form. Om gruppen blir fornøyd med brukertester vil prototypen brukes videre til å lage en hi-fi prototype og så videre til en ferdig produkt. Siden det er en modul vi skal utvikle bestemte vi oss for å teste bare funksjoner modul skal ha og det vil si at vi skal bruke vertikal prototype for å gjennomføre testing av funksjonalitet. 47

49 48

50 Prototype v1 Modul bilde 1: Prototype 1 Etter at skisser og diskusjon om disse ble ferdig kom vi i gang med å lage første revolusjonær prototypen Formål med prototype v1 Tanken vær å se på om brukere forstår konseptet, derfor har vi laget den ganske enkelt og det vær ikke mening i å bruke den til neste prototypene. Gruppen begynte utviklingen av en lo-fi prototypen med enkle instrument «Balsamiq Mockups». Denne versjonen var ganske likt skisser vi har kommet til Tilbakemeldingene Testbrukere ble spurt om å synkronisere mot MYO kontroller og sende et melding med tegnspråk. Gruppen har laget en representasjon av MYO kontrollere som skal bæres på armbåndene. Resultat av testene viste at testbrukere hadde forstått konseptet og ga positive tilbakemeldinger om den. Men det vær spørsmål om hvor stor MYO kontroller er og hva skjer hvis MYO kobler seg fra under samtalen? 49

51 Prototype v2 Etter at gruppen hadde fått bekreftelse på at konsept fungerer kom vi i gang med det evolusjonær prototypen som skal leve videre og utvikles Utfordringene Gruppen hadde kommet i diskusjoner om hvilket verktøy og prototypingmetode vi skal bruke for å teste brukerscenarier. Siden første testene viste at testbrukere forstår konseptet med oversettelse av tegn, kunne de ikke forstå helt hvordan tegn skal oversettes til tale og bli brukt i samtalen. De hadde ikke møt opp slike løsningene tidligere og første versjon av prototypen kunne ikke demonstrere dette Formål med prototype v2 Hoved formål vær å teste en situasjon løsningen kunne brukes i. Her har vi tatt situasjon når man skal ringe restaurant og bestille et bord. Ved hjelp av prototype 2 kunne testpersonen slå på applikasjon, velge kontakt han vil ringe til, koble til MOY og gjennomføre samtalen ved hjelp av tegnspråk. Det vær også viktig at testpersoner skal kunne oppleve den som en fungerende produkt. 50

52 Utvikling For å lage prototypen valgte vi å bruke et nettbasert verktøy som heter «Prototshare». Den tillat oss å manipulere prototypen og simulere funksjonaliteten i større grad en det vær mulig med prototype 1. Vanskelighet med utviklingen av prototype 2 vær simulering av oversettelse «tegn-til-tale», «tekst-til-tale» og «tale-til-tekst». Det måtte gjøres slik, at testbrukere skulle ikke oppfatte at det er trollmanen som styrer. Med «Protoshare» vær det ikke mulig å implementere lyd i prototypen, derfor hadde vi valgt å bruke trollmanen for å lese av meldingene. I tillegg fant gruppen ut at det finnes funksjon som oversetter tekst-til-tale men ikke noe godt til å oversette «tegn-til-tekst». Modul bilde 2: Prototype 2 - dialog vindu Derfor bestemte gruppen for å bruke trollmanen Tilbakemeldingene Testing ble gjennomført på PC ved hjelp av en observatør og trollmanen. Resultatene hadde vist oss noen svakheter med prototypen. Det første vær at når brukeren hadde valgt kontak han skal ringe til, kom det opp en melding der brukeren ble informert om at nå gjennomføres det tilkobling til MYO kontroller. Øverst på skjermen hadde vi satt informasjonen om hvem som man ringer til og diverse 51