BLISS FOR NETTBRETT. Høyskolen i Oslo og Akershus. Arild Spersrud Frode H. Wesenberg Magnus H. Hansen Migjen Hakaj

Transkript

1 BLISS FOR NETTBRETT Høyskolen i Oslo og Akershus Arild Spersrud Frode H. Wesenberg Magnus H. Hansen Migjen Hakaj

2 1

3 Sammendrag Vi har jobbet som en del av Kirsten Ribus forskingsprosjekt vedrørende alternativ og supplerende kommunikasjon. Oppgaven vår baserer seg på prototyping av et kommunikasjonsverkøy for nettbrett på språket Bliss. Hovedformålet med oppgaven har vært å utvikle en kravspesifikasjon via denne prototypingsprosessen. For å gjøre dette måtte vi finne de aktuelle brukergruppene, hvilke interaksjonsmetoder som skulle brukes og definere en kravspesifikasjon for videre utvikling til et fullverdig produkt. Bliss er et fullverdig alternativt språk basert på geometriske grunnformer. Det er et komplett språk med tilhørende grammatiske klasser og en offisiell standard. Språket er i konstant utvikling og består av ca 5000 offisielle ord i skrivende stund. Det har blitt brukt flere arbeidsmetoder gjennom prosjektets livstid. Det har vært hovedsaklig prototypingsteknikker og generell systemutvikling. Spørsmålene som skulle besvares utviklet seg i løpet av oppgaven. Ny informasjon ble gitt sporadisk som gjorde det krevende og tilpasse idèer, prototyper og testing. Forord Prosessdokumentasjon: Prosessdokumentasjonen beskriver hele prosessen rundt prosjektet fra start til slutt. Det beskriver hvordan vi kom frem til og løste problemer og utfordringer som oppsto. Produktdokumentasjonen: Produktdokumentasjon er en beskrivelse av oppgavens sluttprodukt. Testdokumentasjon: Testdokumentasjon skildrer våre testmetoder, testresultater og evalueringer. Takk til: Takk til Kirsten Ribu, vår oppdragsgiver og veileder som tilbød oss denne oppgaven og lot oss ta del i dette forskningsprosjektet. Takk til medstudenter ved HIOA som har vært behjelpelig med testing. Takk til Statped som har hjulpet oss med ekspertise innen ASK og Bliss. 2

4 Hovedindeks 1. Prosessdokumentasjon Produktdokumentasjon Vedlegg 1: Testdokumentasjon Vedlegg 2: Møtereferat Statped

5 Prosessdokumentasjon 4

6 Indeks 1. Innledning Om gruppen Oppdragsgiver og Veileder Oppgavens formål Statped Gruppens faglige bakgrunn: Webprosjekt Prototyping Systemutvikling Menneske Maskin Interaksjon Universell utforming Informasjonsarkitektur Oppgavetekst Problemområde Mål Om ASK Om bliss Opphavsrett Styringsdokumenter Prosjektskisse og forprosjektrapport Arbeidsavtale Risikoplan Prosjektdagbok

7 2.5 Milepælsplan Dokumentstandard Verktøy Skype Facebook Google Drive Microsoft Office Dropbox Google Scholar HIOA Databaser MS Paint FluidUI Axure Violet UML Arbeidsmetoder Gruppestruktur og ansvarsfordeling Arbeidsfordeling Dokumenthåndtering Utviklingsmetode Teknikker Idevegg Personas Teknikker for prototyping Skissering Wizard of Oz / smoke and mirrors

8 4.6.3 Papir Prototype Informasjonsinnhentning Nettsider Isaac.no Blissymbolics.org Statped.no Databaser Statped Sprint 1 - Informasjonsanking Oppgavetekst Rammebetingelser Kravspeksifikasjonen og dens rolle Funksjonelle krav Ikke funksjonelle krav Brukergruppe Mål for sprinten Arbeidsmetode Hvem er brukergruppene? Afasi Cerebral Parese Dysleksi Bliss Resultat Egenvurdering Sprint 2 - Første prototype Mål

9 7.2 Utfordringer Hurtighet Plassmangel Bruker skal ikke ha mulighet til å lage egne symboler Det skal være enkelt å kunne rette opp en feil Motoriske ferdigheter Input-løsning Valg/løsninger Forkastede ideer Kinesisk tastatur Talestyring Airdraw/fingermotion Skisser Forkastede ideer Drag and drop Dropdown Ordringer Swipe Møte med oppdragsgiver Prototype Brukertest med personas Endringer i kravspek og rammer Ordbok Funksjonelle krav Ikke funksjonelle krav Funksjonelle krav som blir fjernet

10 7.8 Resultat Posisjoneringsproblemer Sprint 3 - Idemyldringsfase Mål Reevaluering av tidligere interaksjonsmetoder Posisjoneringsproblemet Hurtighet Plassmangel Tegning Minimalisere sjansen for feiltolkning av tegn Møte med statped Blisstavlen Ny skisserprosses Ny kravspesifikasjon Funksjonelle krav Ikke funksjonelle krav Forandring i brukergruppen Tilbakemeldinger fra oppdragsgiver Egenvurdering Sprint 4 - Prototype Mål De ni grunntegnene Skissering Papirprototype Brukertest med papirprototype Konklusjon til test

11 9.5 Prototype Axure Ny iterasjon etter papirtest Positive sider med programmet: Negative sider: (begrensninger) Hvordan fungerer prototypen Gjennomgangstest oppdragsgiver Test på medstudenter Tilbakemeldinger Ny kravspesifikasjon Funksjonelle krav Ikke funksjonelle krav Resultat Sprint Rammer Mål Fikset tilbakemeldinger Kamera Fungerende farger Test Endelig kravspesifikasjon Evaluering Kilder

12 1. Innledning 1.1 Om gruppen Gruppen består av Magnus Hjelmervik Hansen, Arild Spersrud, Frode Wesenberg og Migjen Hakaj fra Anvendt Datateknologi på høyskolen i Oslo og Akershus. Et studie med mye prosjektarbeid og mange relevante fag som gav gruppen et solid faglig utgangspunkt til å utføre oppgaven. Gruppen har samarbeidet på flere tidligere prosjekter. 1.2 Oppdragsgiver og Veileder Oppdragsgiver og veileder for hovedoppgaven er Kirsten Ribu. Oppgaven er en del av et forskningsprosjekt vedrørende alternativ og supplerende kommunikasjon. Ribu er førstelektor ved Høgskolen i Oslo og Akerhus ved fakultetet for teknologi, kunst og design på instituttet for informasjonsteknologi. 1.3 Oppgavens formål Bacheloroppgaven er bestilt av oppdragsgiver for sitt forskningsprosjekt rundt Blisspråk og askmetoder. Arbeidet vi gjør med research, utvikling, informasjonsinnhenting og testing er bestilt på bakgrunn av oppdragsgivers utvikling og samarbeid med Statped for videre forskning til sitt prosjekt. 1.4 Statped Statlig spesialpedagogisk tjeneste vil bistå med rådgivning. 1.5 Gruppens faglige bakgrunn: Under beskrives de mest relevante fagene gruppemedlene har hatt i løpet av studieforløpet. 11

13 1.5.1 Webprosjekt Web og internett har i dag en viktig og sentral samfunnsmessig rolle og er av fundamental betydning for de som skal ha databehandling og IT som profesjon. I dette emnet vil web være en plattform for å etablere kunnskap om og ferdigheter i ideer, teknologi og metodikk som er sentrale for yrkesområdet data og IT. (Øye, 2012a) I Webprosjekt lærte gruppen om styringsdokumenter, prosjektstyring og gruppearbeid i større prosjekter Prototyping I dette emnet skal studentene tilegne seg kunnskaper og grunnleggende ferdigheter innen prototyping av IT-systemer og utvikle forståelse av brukeres medvirkning i utviklingen av gode grensesnitt mellom en maskin og en bruker.(øye, 2012b) I Prototyping lærte gruppen om utforming av idèer igjennom flere iterasjoner med brukertesting og hvordan bruker og miljø bør være med på utformingen til et produkt. Dette faget var veldig relevant til vår oppgave Systemutvikling I dette emnet skal studentene utvikle forståelse, kunnskap og ferdigheter knyttet til utvikling av programvaresystemer, og tilegne seg innsikt i hvordan systemets egenskaper defineres, hvilke rammer som gjelder for utviklingen, og hvordan utviklingsprosessen styres. Videre skal studentene kunne forstå noe av kompleksiteten i samspillet mellom programvare og ulike bruker- og interessegrupper (inkludert smidige) og tradisjonelle metoder og teknologier for systemutvikling. (Øye, 2012c) I Systemutvikling lærte gruppen hvilke utviklingsmetoder som egner seg for forskjellige utviklingsprosjekter og hvilket som bør benyttes i denne oppgaven. Gruppen har også fått erfaring innen utforming av kravspesifikasjoner. 12

14 1.5.4 Menneske Maskin Interaksjon Studenten skal tilegne seg kjennskap til den terminologien, problemstillinger og teknikker som brukes i forbindelse med utvikling og evaluering av brukergrensesnitt med hovedvekt på grensesnitt for web. Studenten skal utvikle ferdighet i å analysere systemer fra en brukers ståsted, og argumentere for om systemer vil fungere eller feile i lys av menneskelig mangfold.(øye, 2012d) Menneske Maskin Interaksjon har lært gruppen om forskjellige evalueringsteknikker og analyser som har blitt benyttet til å utforme prototypene. Det har også lært gruppen å sette bruker i førersetet slik at han/hun kan få best utnyttelse av applikasjonen Universell utforming Studentene skal kunne designe, evaluere og teste hverdagsteknologi utformet etter prinsipper for almen tilgjengelighet. De skal kjenne norsk og internasjonalt lovverk om inkludering av alle brukergrupper i samfunnet. Studentene skal tilegne seg kunnskap om ulike funksjonshemmende IKT-barrierer, og kunne designe universelt utformede IKT-løsninger sammen med brukere. (Øye, 2012e) I Universell utforming har gruppen lært å ta hensyn til flere brukergrupper med forskjellige behov under utviklingsfasen og ta hensyn til at flere av disse kan benytte seg av eksterne hjelpemidler Informasjonsarkitektur Studenten skal tilegne seg kunnskap og innsikt i grunnleggende begreper og anvendelser for informasjonsarkitektur. De skal også tilegne seg praktiske ferdigheter for å kunne vurdere og designe informasjonsarkitektur for nettsteder. (Øye, 2012f) Informasjonsarkitektur har hjulpet gruppen til å sortere informasjon, bygge den opp i lag samt bruk av riktige labels. Dette for at applikasjonen skal bli intuitiv og oversiktlig slik at brukeropplevelsen blir god. 13

15 1.6 Oppgavetekst Oppgaven går ut på: Sette oss inn i ASK og lære grunnleggende Bliss. Indentifisere brukergruppene og finne ut hvilke avgrensninger og rammer de setter. Utvikle en prototype for en nettbrettapplikasjon som kan benyttes som et kommunikasjonsverktøy for Bliss. Arbeide oss frem til en high fidelity prototype igjennom flere iterative faser med brukertesting og faglitteratur. Utvikle en kravspesifikasjon igjennom prototyping som kan brukes til videreutvikling av applikasjonen. På grunn av manglende kunnskap hos både oppdragsgiver og gruppen ved prosjektets oppstart ble rammebetingelser satt under forbehold om at endringer vil forekomme underveis. Det vil si at kravspesifikasjoner og rammebetingelser vil konstant endres. Det er gruppens oppgave å imøtekomme disse underveis. Gruppen har pliktige møter med oppdragsgiver for å samarbeide om prosjektets retning. 1.7 Problemområde For Bliss brukere er det et svært begrenset utvalg av verktøy til kommunikasjon på nettbrett. De løsningene som er tilgjengelige er ikke utformet med tanke på kommunikasjon, men heller mer som en ordbok eller læreverktøy. Dette gjør at applikasjonene ikke har nytteverdi som kommunikasjonsløsninger og brukerne av disse ikke vil kunne kommunisere direkte med personer som ikke kan Bliss. Et eksempel på eksisterende løsninger er en applikasjon ved navn ibliss Symbols og en gratis versjon ibliss symbols lite. Denne applikasjonen fungerer ikke godt som et kommunikasjonsverktøy, men mer 14

16 som et oppslagsverk for generelle Blissord. Gratisversjonen har en database på ca 30 eksempler det er mulig å se på. Figur 1: Skjermdump 1 Her ser vi hvordan ibliss lite organiserer oppslagsverket. Det kommer tydelig frem at dette bare en applikasjon som viser 36 av rundt 5000 Blisstegn. Figur 2: Skjermdump 2 Går man inn på en kategori ser vi videre hvordan du kan velge et ord og få Blissformen av dette ordet opp. 15

17 Figur 3: Skjermdump 3 Går man inn på et valg får man mer detaljert informasjon i form av en fargekode. Applikasjon er generelt sett veldig kronglete å manøvrere og lite selvforklarende. Det er klart at behovet for et fullbyrdig kommunikasjonsverktøy behøves fremfor bare et oppslagsverktøy. Denne er heller ikke til noe nytte for en Blissbruker da oppslagsverket er kategorisert i form av det latinske alfabetet. 1.8 Mål Målet med oppgaven er å lage en hi-fi prototype og en kravspesifikasjon for videre utvikling av en applikasjon for kommunikasjon med Bliss på nettbrett. 1.9 Om ASK I følge ISAAC kan ASK sies å være alt som hjelper en person til å kommunisere effektivt, når tradisjonelle måter å kommunisere på ikke strekker til. (Isaac, U.Å) ASK, eller alternativ og/eller supplerende kommunikasjon, er alle hjelpemidler som hjelper en person som har begrenset eller ingen taleevne til å utrykke seg mer effektivt. Dette er alt fra enkle hjelpemidler som bilder og håndbevegelser til teknologiske hjelpemidler som kommunikasjonsbøker og talemaskiner. 16

18 I forhold til vår oppgave gjelder dette primært teknologiske hjelpemidler og progamvarer som hjelper bruker å kommunisere med omverdenen Om bliss I følge (Blissymbolics Communication International,U.Å) er Bliss: Blissymbolics is a communication system originally developed by Charles K. Bliss ( ) for the purpose of international communication. It was first applied to the communication of children with physical disabilities by an interdisciplinary team led by Shirley McNaughton at the Ontario Crippled Children's Centre (now the Bloorview MacMillan Centre) in The Blissymbolics language is currently composed of over 5,000 graphic symbols. Each symbol or Blissword is composed of one or more Bliss-characters which can be combined and recombined in endless ways to create new symbols. Bliss-words can be sequenced to form many types of sentences and express many grammatical capabilities. Simple shapes are used to keep the symbols easy and fast to draw and because both abstract and concrete levels of concepts can be represented, Blissymbolics can be applied both to children and adults and are appropriate for persons with a wide range of intellectual abilities. Blissymbolics is a language with a wide vocabulary, a grammar which allows for sentences in past, future and present tenses, and markers for possession, plurality, questions and commands. (Blissymbolics Communication International,U.Å) Figur 4: Blisstegn (statped, U.Å) 17

19 Over ser man et eksempel på hvordan ord i Bliss kan bygges opp. Et symbol tilhører en ordklasse og alle ordklassene har bestemte farger. Gult representerer objekter, grønt representerer subjektiver, rødt representerer verb, blå representerer subjekter og hvit representerer de resterende ordklassene. Figur 5: Bliss verb I figur 5 viser vi tre bøyninger av verbet å være. Først i infinitiv, så i nåtid og til slutt fortid: å være, er og var Opphavsrett Blissymbolic Communication International (heretter referert til som BCI) eier og vedlikeholder opphavsretten til The Blissymbol graphic communication system etter at C.K. Bliss overførte opphavsretten i årstall (Blissymbolics Communication international, 2010) BCI styrer en standard kjent som BCI-Authorized Vocabulary (heretter referert til som BCI-AV), dette er den offisielle standarden. Alt av Bliss symboler og oversettelsen av disse i oppgaven kommer fra BCI-AV. Gruppen benytter seg av disse symbolene under Creative Commons Attribution-Share Alike 3.0 Unported License. (Creative commons, 2014) 18

20 2 Styringsdokumenter Gruppen benyttet seg av en rekke styringsdokumenter for å planlegge og strukturere arbeidet i dette prosjektet. 2.1 Prosjektskisse og forprosjektrapport Prosjektskissen ble ikke skrevet og levert inn da gruppen ikke hadde funnet en oppgave da firsten gikk ut. Forprosjektrapporten ble skrevet og levert til oppdragsgiver innen leveringsfristen. 2.2 Arbeidsavtale En arbeidsavtale ble satt svært tidlig i prosjektet. Denne inneholdt informasjon om hvor ofte gruppen skulle møte, forventet arbeidsmoral og holdninger, krav til egen innsats og initiativ og hvordan konflikter skulle håndteres. 2.3 Risikoplan Det ble laget en risikoplan for å kartlegge eventuelle risikoer som kunne påvirke prosjektet negativt. Når risikoene var kartlagt ble en plan om hvordan man kunne forminske risikoene og eventuelle konsekvenser av risikoene formulert. Et utdrag fra risikoplanen er vist i figur 6. 19

21 Figur 6: Risikoplan eksempel 2.4 Prosjektdagbok Etter hvert møte ble det ført opp et møtereferat hvor informasjon om dagens arbeid ble oppført for lettere å kunne se tilbake på viktig informasjon og få et overblikk over prosjektets gang i etterkant. 2.5 Milepælsplan En svært enkel milepælsplan over fristene til de viktigste tilstandene i prosjektet, denne ble brukt til å holde oversikt over sprintene og for å sørge for at prosjektet holdt fristene vi hadde satt. 2.6 Dokumentstandard Malen til rapporten er basert på Dokumentasjonsstandard for bachelor-prosjekter (hovedprosjekt) for Institutt for informasjonsteknologi Høgskolen i Oslo og Akershus. Den er tilpasset vår oppgave for å bedre passe til vår oppgaves utforming. For formatering av dokumentet ble APA style-6 benyttet. 20

22 3 Verktøy Under er en rask oversikt over alle verktøy, tjenester og programmer som er tatt i bruk under prosjektets gang. 3.1 Skype Skype er et ip-telefoni program som lar deg snakke, skrive, sende filer og dele skjerm i sanntid med andre brukere. Ved bruk av Skype premium kan skjerm deles med flere personer i gruppesamtaler, dette er noe gruppen har benyttet seg av ofte. Gruppen har brukt Skype aktivt for kommunikasjon innenfor og utenfor satte møtetider. Tjenesten har blitt brukt mest i samkjør med Google Drive for bedre kommunikasjon og samarbeid de gangene fysiske møter var ugunstig. 3.2 Facebook Facebook har blitt brukt til å organisere møter innad i gruppen og informere om avvik, slik at gruppemedlemmer har hatt mulighet til å gi beskjed i god tid, hvis de ikke har mulighet til å møte har blitt brukt til å kommunisere med veileder og oppdragsgiver. 3.4 Google Drive Google Drive er en cloud tjeneste hvor flere personer kan editere et dokument samtidig. Her tilbys alle dokument typer som er innkludert i MS Office. Alle dokumentene lagres i skyen og er tilgjengelige fra alle terminaler med internett tilkobling. Dette gjorde at tjenesten ble benyttet som både backup og til teksteditering. 21

23 3.5 Microsoft Office Ble benyttet til tider for eget arbeid og arbeid når internett tilkobling var ustabil eller utilgjengelig. Ble også brukt til cropping av bilder og figurer ved siden av tekst. 3.6 Dropbox Dropbox er en sky-lagrings tjeneste som kan spesifiseres til å lagre kun i skyen eller både sky og lokalt. Gruppen benyttet seg av dette på en måte som gav en kopi av alt arbeidet i skyen og på en datamaskin lokalt hos hvert gruppemedlem. Dropbox har også versjonhåndtering slik at hvis noen data ved uhell ble overskrevet eller slettet kan man gjennopprette dokumentet til en tidligere versjon.alt av gruppens arbeid ble digitalisert og lagret i Dropbox. 3.7 Google Scholar Google Scholar ble brukt til å finne forskningsdokumenter vedrørende Bliss, ASK, interaksjon med nettbrett, brukergrensesnitt og brukergrupper. 3.8 HIOA Databaser Vi har brukt ulike databaser vi har fått tilgang til gjennom hioa. Vi har hovedsaklig holdt oss til de tekniske databasene for informatikk: ACM digital library Science directo IEEEE explore 3.9 MS Paint Microsoft Paint er et tegneprogram som er standard i alle windows operativsystemer og har i 22

24 hovedsak blitt benyttet til å skissere og illustrere i et digitalt format. Dette har i hovedsak blitt benyttet fordi det er et standard gratis program som alle gruppemedlemme har hatt tilgang til FluidUI FluidUI er et prototypingsverktøy for mobile enheter som opererer med IOS og Android operativsystemer Axure Axure er et meget omfattende prototypingsverktøy for applikasjoner og websider Violet UML Violet UML er et program som tillater oss å lage diverse UML diagrammer som usecaser, usecasediagrammer aktivitetsdiagrammer og andre systembeskrivelsesdiagrammer. Det kan lastes ned eller kjøres fra browser uten å måtte installere det på egen klient. 4. Arbeidsmetoder Dette punktet beskriver de arbeidsmetodene gruppen tok i bruk for å løse oppgaven. 4.1 Gruppestruktur og ansvarsfordeling Gruppen har ikke hatt en hierarkisk struktur der vi har hatt en utnevnt leder. Det har vært fordeling av arbeid etter evne, lyst og erfaring. Migjen har fungert som kontaktperson for henvendelser utad og innad. 23

25 Ansvarsfordelingen i gruppen ble delt opp slik at alle gruppemedlemmene hadde et hovedansvar og et delansvar. På denne måten var det alltid to personer som hadde oversikt over hver hoveddel av prosjektet slik at fremgangen ikke stoppet ved sykdom og lignende. Ansvar Kommunikasjons Teknisk Produkt Prosess Hoved Migjen Frode Arild Magnus Del Arild Magnus Frode Migjen Tabell 1: Ansvarsfordeling 4.2 Arbeidsfordeling Arbeidsfordelingen har hovedsaklig fulgt ansvarsfordelingen, men har blitt tilpasset etter arbeidslyst og vilje for å holde moralen oppe i et så langt prosjekt. Dette også for at hvert gruppemedlem skal tilegne seg nogenlunde lik kunnskap på de forskjellige områdene. 4.3 Dokumenthåndtering Alt av dokumenter skal lagres i enten Google Drive eller Dropbox kontinuerlig for å forhindre tap av arbeid og data. 4.4 Utviklingsmetode Da vi ikke hadde en håndfast og konkret kravspesifikasjon i startfasen av prosjektet, kom vi fram til at det ville være lite hensiktsmessig å benytte oss av en plandrevet utviklingsmetode. Vi tok i bruk en smidig utviklingsmetode for å kunne bedre takle forandringer og nye utfordringer som dukket opp underveis i prosjektet. Vi brukte scrum som inspirasjon. Det ble holdt presentasjoner av alt arbeid som hadde blitt gjort siden forrige møte ved oppstart av hver nye arbeidsesjon. Disse møtene var 24

26 da korte og stående. Problemer ble raskt drøftet og videre arbeidsplan ble satt. Arbeidet ble gjort i flere sprinter. Hver sprint ble planlagt etter de største utfordringene i starten av hver fase. Vi opererte i tre til fire uker lange intervaller. 4.5 Teknikker Det har blitt tatt i bruk ulike teknikker i utviklingen av prototypene Idevegg Denne metoden ble brukt tidlig for å få oversikt over mulige idèer. Dette er en metode som setter terskelen lavere for å komme med forslag. Vi skrev ned alle våre tanker på post-it lapper, hang de opp på en vegg for å så gå igjennom hva som var tanken bak hver lapp. På denne måten luket vi ut mange forslag og fikk samtidig mange nye impulser til hvordan vi skulle løse diverse utfordringer Personas Personas ble brukt for å kunne sette forutsetninger for prototypene våre basert på informasjonen vi hadde om de aktuelle brukergruppene. Vi satt opp seks fiktive personer med reele utfordringer som våre brukergrupper møter til daglig. Ved bruk av disse personasene kunne vi luke ut elementer som viste seg å ikke ha tilstrekkelig funksjonalitet i forhold til disse brukergruppene. 4.6 Teknikker for prototyping Under nevnes teknikker som går direkte på prototypene Skissering Her ble det brukt penn og papir for å få frem alle idèene. Dette gjorde at vi effektivt kunne bruke og forkaste ulike idèer. Teknikken var svært nyttig for oss i startfasen der det var mange ulike tanker om forskjellige løsninger. 25

27 4.6.2 Wizard of Oz / smoke and mirrors Her ble det brukt forskjellige web-baserte utviklingsmetoder for å gi en illusjon av et fungerende produkt der det egentlig var enkel htmlkode som genererte et høyere nivå av interaktivitet enn andre low-fi teknikker som papirprototyper og stop-motion Papir Prototype Dette ble brukt for å lett kunne simulere interaksjon mellom bruker og system. 5. Informasjonsinnhentning Før gruppen kunne starte utviklingen av prototypene var det mye informasjon som skulle hentes. Gruppen måtte lære seg om og grunnleggende Bliss, ASK, om aktuelle brukergrupper, funksjonalitet og begrensninger i forhold til på nettbrett. Dette var en tidkrevende prosess som krevde at alle gruppemedlemmene la ned en betydelig innsats, slik at alle satt med nogenlunde lik kompetanse når avgjørelser skulle tas. Siden applikasjonen hovedsaklig fokuserer på Bliss, var det viktig at gruppen som en helhet hadde basiskunnskaper innenfor ord, oppsett og bøying av disse. Gruppen har hatt begrenset informasjonsflyt angående Blisspråket. Bliss er et språk som ble utviklet av Charles K. Bliss og patentert i Det er ikke et bredt spekter av informasjon tilgjengelig rundt språket. Informasjonkildene nevnt under har hatt en sentral rolle i informasjoninnhentingen rundt Bliss. 5.1 Nettsider Det er noen sentrale internettsider for informasjonen og kunnskapen rundt Bliss som har blitt benyttet i prosjektet Isaac.no ISAAC er en internasjonal organisasjon for alle som bruker og legger til rette for alternativ og 26

28 supplerende kommunikasjon (ASK). ISAAC har mye generell informasjon angående våre brukergrupper. Organisasjonsen spesialiserer seg innen for ASK og har mye informasjon om de ulike metodene for ASK. Dette har hjulpet oss å få et større innblikk over forskjellige metoder og teknikker som tas i bruk. Informasjonen vi har hentet fra Isaac har gitt oss et større overblikk over hvor det er rom for forbedringer. Isaac informerer også om nyttig informasjon om diverse arrangementer vedrørende Bliss og andre ASK teknikker Blissymbolics.org Blissymbolics er nettstedet til BSI, organisasjonen som eier Bliss. Siden tilbyr en enkel innføring i Bliss, dokumenter med grunnreglene til Bliss og oppgir forskningsartikler som omhandler Bliss. Man finner også nyheter om Bliss, spill og en rekke andre nyttige ressurser Statped.no Statens spesialpedagogisk tjeneste er en nasjonal etat som gir spesialpedagogiske tjenester til kommuner og fylkeskommuner.(statped, U.Å) Siden tilbyr en del informasjon rundt Bliss fra et spesialpedagogisk standpunkt. 5.2 Databaser Gruppen benyttet seg av søk i diverse forskningsdatabaser for å finne artikler som omhandlet Bliss, interaksjon og design på nettbrett. 5.3 Statped Da Statped engasjerer seg i tilrettelegging av læring har de vært interessert i dette forskningprosjektet og stilt seg til disposisjon i forhold til råd, informasjon og tilgang til testperson. Vår representant fra Statped (Kirsten M. Bjerkan) ga oss indikasjoner på de faktiske forholdene for brukergruppene slik at vi kunne sette spesifikke forutsetninger for bruk av applikasjonen/prototypen vår. Vi fikk fikk også mye ny 27

29 informasjon angående oppsettet av Blisspråket som grammatikk og illustrasjoner av de faktiske symbolene. Statped avholdt også et Blisskurs som vår veileder og oppdragsgiver deltok på. Dessverre kunne ikke medlemmene i gruppen delta på dette Blisskurset på grunn av manglende økonomisk støtte. 6. Sprint 1 - Informasjonsanking 27. januar februar I første omgang hadde gruppen et stort behov for informasjon som måtte oppfylles. Derfor ble fokuset i første sprint informasjonsinnhenting og kompetanseoppbygning. 6.1 Oppgavetekst I starten av denne sprinten var oppgaven veldig løst definert. Gruppen skulle finne ut hvilke brukergrupper som kunne ha behov for en applikasjon for Bliss på nettbrett og hvor store brukergruppene var. Gruppen skulle også utvikle en prototype med tastetur som input-metode og en Bliss-til-tale output som kunne brukes til å utvikle en kravspesifikasjon i samarbeid med oppdragsgiver Rammebetingelser Rammebetingelsene ble løst formulert på første møte med oppdragsgiver. De beskriver i generelle trekk hva utgangspunktet til oppgaven går ut på. Ved oppstart av prosjektet skulle gruppen ta hensyn til alle brukergrupper uavhengig av motoriske ferdigheter. Det er en forutsetning at brukergruppen som skal bruke applikasjonen har gjort seg kjent med blisspråket fra før. Det skal være et kommunikasjonverktøy, ikke læringsmiddel. Applikasjonen skal utvikles på nettbrett, derfor skal også prototypen være skalert for nettbrett. Applikasjonen skal utvikles primært for voksne brukere, men ikke ekskludere andre aldersgrupper. Det kan utvikles for bruk med cutting-edge teknologiformer. 28

30 Det skal tas hensyn til motoriske utfordringer. 6.3 Kravspeksifikasjonen og dens rolle Oppgavens mål er å utforme en kravspesifikasjon. Det innebærer at den ville bli endret etterhvert som gruppen tilegnet seg mer informasjon om brukergrupper, kunnskap om språket Bliss, brukertester fra tidligere sprinter og tilbakemeldinger fra oppdragsgiver. Første kravspesifikasjon ble basert på rammebetingelsene og utviklingen av kravspesifikasjonen blir utdypet videre i dette dokumentet. Den endelige versjonen blir presentert i produktdokumentasjonen Funksjonelle krav Prototypen skal ha et taleoutput som skulle gjøre det mulig for bruker å kommunisere direkte med personer som ikke kan Bliss. Systemet skal ha et tastatur oppsett. Systemet skal ta høyde for brukere som benytter eksterne hjelpemidler som EEG og eye-trackers Ikke funksjonelle krav Skal være hurtig 6.4 Brukergruppe Brukergruppene var på dette punktet ukjent annet enn at brukere er personer som har enten mistet eller er født uten taleevne. Disse kan ha mistet taleevnen ved medfødt hjerneskade, ulykke eller sykdom. Etter en operasjon i hjernen kan språket bli borte enten forbigående eller varig, uten at dette påvirker intellektet eller kognitive evner. Vi skulle fokusere på voksene brukere, og stilte krav til at brukerne har gode nok motoriske evner i hendene til å kunne benytte seg av nettbrettet. 29

31 6.5 Mål for sprinten Målet for sprinten var at gruppen skulle tilegne seg grunnleggende kunnskap og informasjon om Bliss, ASK, brukergrupper, støtteteknologier og nettbrett som plattform. 6.6 Arbeidsmetode Vi hadde hovedsaklig gruppemøter på skolen. Disse møtene var planlagt på forhånd med satt agenda. Vanligvis startet møtene med en stående oppdatering om hva slags arbeid som var gjort, hvilke problemer som oppstod og hva planen var videre. Det ble gitt hjemmearbeid i mellom hvert møte som hvert gruppemedlem selv var ansvarlig for å utføre og presentere for resten av gruppen på neste møte. På denne måten kunne gruppemedlemmene utveksle informasjon effektivt, som bidro til å høyne kompetansen i gruppen. Hjemmeleksene omfattet primært å finne artikler og resurser rundt Bliss og ASK, men også tekniske artikler rundt interaksjon med nettbrett. Gruppen hadde også sittende møter med fokus på plenum læring og forståelse av Bliss. Møter med oppdragsgiver og veileder på dette tidpunktet i prosjektet omhandlet informasjon, forståelse og diskusjon om oppgaven. 6.7 Hvem er brukergruppene? Vi forsøkte å kontakte ISAAC Norge sin Bliss-gruppe for å forhøre oss om konkrete tall rundt Blissbrukere i Norge, men fikk ikke svar fra ISAAC eller andre organisasjoner vi tok kontakt med. Vi lette videre men fant ingen tall rundt hvor mange Bliss brukere der er i Norge eller internasjonalt. De tallene vi fant derimot var tall på de potensiale brukergruppene i Norge. Siden dette var første gang vi kartla forskjellige brukergrupper var alle potensielle brukere inkludert, uavhengig av motoriske ferdigheter eller størrelse på gruppen. 30

32 6.7.1 Afasi Afasi kom tidlig frem som en av brukergruppene. Det er ca 5000 afasirammede hvert år (Statped, 2011). Dette er en aktuell brukergruppe da mange blir rammet av afasi som følger av sykdom og ulykker. Dette kan medføre enten midlertidige eller permante skader som påvirker språkevnen til personen. I denne brukergruppen varier motoriske ferdigheter fra normal motorikk til fullstendig lammelse Cerebral Parese Uttalelser fra Cerebral Parese forbundet tilsier at det er rundt 8000 med Cerebral Parese i Norge i dag. Som med afasi er ikke alle disse 8000 like kraftig rammet og det er ikke alle som vil være like aktuelle for bruk av et alternativt språk. (Katrine cerebral parese forening representant, 2010) Dysleksi Det var mange faktorer å ta hensyn til her som for eksempel hvilke sykdommer vi skulle ta høyde for og hva slags limitasjoner hver sykdom innebar. Dysleksi var en de aktuelle sykdommene vi så på, siden de har vansker med å lære seg skriftspråk. Dysleksiforbunded skriver at ifølge norske forskere er det grunn til å tro at om lag 5% av befolkningen har dysleksi i alvorlig grad. (Dysleksi Norge, U.Å). 6.8 Bliss Det var en tidkrevende prosess å sette seg inn i Bliss språket, da det eneste kurset tilgjengelig for gruppen var et halvferdig online kurs på BCI sine nettsider. Dette kurset hadde store mangler og døde linker som gjorde at det ikke var gjennomførbart. Gruppen løste dette ved å lese igjennom språkets grunnregler fra et ikke pedagogisk synspunkt, men dette førte til at gruppen hadde begrenset mestring over språket. 31

33 6.9 Resultat Siden vi ikke fant konkrete tall på antall eksisterende brukere av Bliss tok vi forbehold om at prototypen var aktuell for en ukjent andel av disse brukergruppene. Brukergruppene blir som følger : Afasi - Opptil ca 5000 potensielle brukere per år. Denne gruppen er ikke permanent. (Statped, 2011) Cerebral Parese - ca 8000 mennesker med ulik motoriske ferdigheter. (Katrine cerebral parese forening representant, 2010) Dysleksi - ca 5% av befolkningen av befolkningen har dysleksi i alvorlig grad. (Dysleksi Norge, U.Å) Egenvurdering Gruppen følte de tilegnet seg tilstrekkelig med informasjon til å begynne og utforme første prototype etter endt sprint. Alle gruppemedlemmene bidro og informasjonsflyten bidro til at alle endte på samme kunnskapsnivå rundt bakgrunnstoffet. Det hadde vært ønskelig med mer tid satt av til å lære Bliss med gode ressurser tilgjengelig. Men på grunn av tidsrammen til prosjektet så gruppen seg nødt til å jobbe med løsninger. Gruppen forsatte å lære seg Bliss og sanke relevant informasjon igjennom hele prosjektet. 7. Sprint 2 - Første prototype 24. februar- 17. mars Denne sprinten bygde på forrige sprint. Brukergruppe og rammebetingelsene er de gruppen kom frem til i sprint Mål Utforme første prototype på grunnlag av kravspesifikasjon og gitte rammebetingelser. 32

34 7.2 Utfordringer Gruppen møtte på utfordringer i henhold til restriksjoner i rammebetingelsen, nettbrettets fysiske form og begrensede interaksjonsalternativer. Samtidig ønsket gruppen at det skulle være en oversiktlig løsning som krevde få interaksjoner med systemet for å lage ønsket ord. Dette medførte at selve applikasjonen måtte oppfylle de kravene som var satt i oppgaveteksten, men også de kravene gruppen satt selv Hurtighet En applikasjon for kommunikasjon stiller krav til hurtighet for å kunne brukes i sanntidskommunikasjon. Hvis det tar for lang tid å danne et svar eller en enkel setning kan både bruker og samtalepartner oppleve samtalen som kunstig og rask miste interessen. Derfor er hurtighet et vitalt punkt for at løsningen skal være attraktiv for brukere Plassmangel Siden nettbrettet har en fysisk begrensing på skjermplass og med det stiller krav til presisjon, så måtte gruppen utforme prototypen med dette i fokus Bruker skal ikke ha mulighet til å lage egne symboler Det skal ikke være mulig for bruker å lage egne tegn siden Bliss-språket har en offisiell standard. Denne standaren bør følges for at språket skal forbli universalt og slik at et symbol ikke får forskjellige meninger. Det har allerede ca 5000 offisielle tegn og ord Det skal være enkelt å kunne rette opp en feil. Hvis bruker gjør en feil med for eksempel å bruke feil ord eller lignende, skal bruker raskt kunne endre eller fjerne dette. Hvis bruker ofte må slette noe han har skrevet og skrive det på nytt, går dette hardt utover hurtigheten. 33

35 7.2.5 Motoriske ferdigheter Motoriske ferdigheter kom raskt frem som et potensielt stort problem i forhold til interaksjon med liten skjerm og touch teknologi. I noen av brukergruppene er det brukere med svært lite motorikk Input-løsning Hvordan dele opp Bliss slik at man kan sette sammen ord og symboler korrekt? Hvordan kunne Bliss kartlegges til et tastatur som kan takle gramatiske regler, bøyninger og former? 7.3 Valg/løsninger For å imøtekomme kravene satt av oppgaven og utfordringene drøftet over delte gruppemedlemmene seg og skrev ned de funksjonene som kunne bidra til å effektivisere applikasjonen. Idèene ble så skrevet ned på post-it lapper og hver enkelt gruppemedlem forklarte til de andre hvorfor han mente at dette var en løsning som kunne passe. Terskelen i den første runden var lav: gruppen ville få flest mulig ideer opp på tavlen. 34

36 Figur 7: Her vises idèene som ble lagt til grunne for første skisse. De løsningene som ble som ble sett på som ugunstige ble fjernet en etter en til gruppen sto igjen med noen gode ideer til å bygge en løsning rundt Forkastede ideer Under står det om noen av ideene som ble forkastet før de kom til skisseringsfasen og litt om hvorfor de ble forkastet Kinesisk tastatur Kinesisk tastatur virket først aktuell fordi de hadde en løsning som håndterte mange symboler på et tastatur, men siden det virker ut i fra ordlyd og ikke tegnsett passet det dårlig for bruk med Bliss Talestyring Talestyring ble droppet da sjansen for feiltolkninger var for høy og primærbrukere av applikasjonen har mistet taleevnen. 35

37 7.3.4 Airdraw/fingermotion Er en meget futuristisk ide som ble forkastet fordi gruppen ønsket å utvikle en prototype som kunne brukertestes på en realistisk måte. 7.4 Skisser Da alle i gruppen var enige om hvilke funksjoner som var mest aktuelle å ha med i første iterasjon av prototypen, satt alle gruppemedlemmene for seg selv og tegnet skisser. Etter en rask presentasjon av skissene i plenum ble det diskutert hvilke skisser som best løste utfordringene nevnt over Forkastede ideer Under står det litt om ideene som ble forkastet etter første runde med skisseringer og hvorfor de ble forkastet Drag and drop Drag and drop ble forkastet da det stilte høye krav til motoriske ferdigheter. Det var også lite gunstig i forhold til antall knapper på skjermen. Dette ville krevd høy presisjon av brukeren Dropdown Dropdown for bøyning av ord ble forkastet da noen ord har veldig mange bøyninger og denne ville ikke egnet seg godt med skjermplass tilgjengelig Ordringer Ordringer for bøyning av ord ble forkastet da noen ord har veldig mange bøyninger og denne ville ikke egnet seg godt med skjermplass tilgjengelig. 36

38 7.4.5 Swipe Swipe for bøyning av verb ble forkastet da det ville vært for små skiller i graden som bestemte hvilken bøying som skulle velges, og dermed stilte for store krav til presisjon Møte med oppdragsgiver Før gruppen kunne gå videre med skisseringen av løsninger ønsket gruppen et møte med oppdragsgiver angående rammebetingelsene og kravspek. Gruppen klarte ikke gi en løsning med både hurtighet og samtidig tilrettelegge for brukere med lav motorikk. Gruppen kom fram til, i samsvar med oppdragsgiver, at kravet til motorikk skulle høynes til brukere med normal motorikk i en pekefinger. Dette var primært på grunn av at nettbrettet er bærbart og hovedbruken til nettbrett var da tiltenkt til å være et hjelpemiddel man kunne ta med seg og bruke for å kommunisere med omverden, også uten å ha med seg en hjelper som et mellomledd. Arbeidsgiver ønsket at prototypen først og fremst skulle fokuseres på tilnærmet normal motorikk, og eventuelt tilpasset i ettertid til de med lavere motorikk. På dette møte la også gruppen fram de første skissene til oppdragsgiver. Det kom også frem at EEG, Eyetrackers og lignende hjelpeteknologier ikke skal tas høyde for, men kanskje implementeres i fremtiden når applikasjonen er i et mer utviklet stadie. 37

39 Figur 8: Skisse 1 Skissen viser en enkel fordeling av skjermen med hovedkomponentene til funksjonen. Vi så for oss et geometrisk tastatur, ordbok, tegneområde og et outputområde. Gruppens største utfordring på dette tidspunktet var hvordan layoutet til tastaturet mappes. Skissen var ment mest for å samle gruppen og oppdragsgiver rundt en idè, se at gruppen var på rett spor og se hvordan brukergruppene kunne interagere med nettbrett. 38

40 Figur 9: Skisse 2 Skisse to er bare en videreutvikling av skisse 1, med tegneområdet fremme. 7.5 Prototype Protoypen vi lagde i denne sprinten, var mest en digitalisert versjon av skissen. Dette var for å bli kjent med FluidUi og hvilke interasjonsmuligheter programmet tilbød. 39

41 Figur 10: Oversikt over første prototype. I figur 10 ser man hvordan flere skjermdumper av et html layoutet var koblet sammen via hyperlinking. Det var slik programmet simulerte tastetrykk. FluidUI er et verktøy som er lett å bli kjent med. Desverre er det for enkelt. Det har mange standardoppsett man kan forholde seg til i prototypingsprosessen, men det var ikke mulig å lage egendefinerte knapper og eller bruke egne bilder. I tillegg var den laget på en måte som gjorde at visning av en prototype ble hakkete og lite sømløs, som også førte til at gruppen forkastet dette verktøyet. 40

42 7.6 Brukertest med personas For å være sikre på om brukergruppene kunne benytte seg av en applikasjon lignende den som ble skisset tok gruppen i bruk personas for å kjøre en teoretisk test på interasksjonen mellom bruker og systemet. Denne testen var primært ment for gruppen selv. For fullstendig informasjon rundt brukertesten se vedlegg 1 testdokumentasjon. 7.7 Endringer i kravspek og rammer I løpet av denne sprinten kom gruppen og oppdragsgiver frem til følgende endringer i kravspesifikasjonen Ordbok Det skal være en bliss-ordbok som skal virke som et oppslag for Blissbrukere. Denne funksjonen skulle ikke prototypes etter tilbakemelding fra oppdragsgiver, men skulle tas med som en ekstern funksjon og det skulle legges av plass til denne. Det er viktig å presisere at det ikke er gruppen som skulle utvikle denne ordboken ettersom det er en omfattende oppgave og krever avanserte Blisskunnskaper og erfaring Funksjonelle krav Systemet skal ha taleoutput Systemet skal ha en funksjon som gir brukeren mulighet til å fjerne et enkelt ord eller deler av et symbol på en enkel og ryddig måte Systemet skal ha en tegnefunksjon Systemet skal ha en oversetter som legger til alfabetet under Blisstegn Systemet skal ha en ordbok med Blisstegn 41

43 7.7.3 Ikke funksjonelle krav Systemet skal være hurtig Systemet skal kunne brukes med en finger Funksjonelle krav som blir fjernet Systemet skal ta høyde for hjelpemidler som EEG og eye-trackers 7.8 Resultat Siden kravet om motorikk i sprint to ble forandret til tilsvarende bruk av keivhendt finger ble fokuset på forbedring av prototypen hurtighet og intuitivitet. Gruppen forkastet første prototypen på grunn av at kravspesifikasjonen ble endret. Det var også noen hull i oppsettet til den første løsningen som ble vanskelig å løse. Vi tilegnet oss også ny kunnskap via prototypingen i sprint to som ga oss innsyn i manglene i den første løsningen vår. Det største problemet drøftes under Posisjoneringsproblemer Hvordan reglene for hvordan de geometriske formene bygges settes sammen? Figur 11: Posisjoneringsproblemeet 42

44 I figur 11 kan du til venstre i gult se et tilfeldig Bliss tegn. Til høyre kan man se resultatet av å ha delt dette opp i geometriske former uten å ha hatt et ordentlig posisjoneringsløsning. Vår prototype kunne ikke effektivt sette sammen symbolene. Hvis vi ikke hadde separert symbolene til deres geometriske grunnformer ville det blitt et tastatur med ekstremt mange tegn. Vi så for oss at posisjonering kunne løses med for eksempel keyboard input (piler), men det ville vært svært langsomt, tungvindt og bestått av mange tastetrykk for hver del av et symbol. Dette ville blitt en langsom kommunikasjonsmetode. En måte å løse det på hadde vært å gjøre f.eks. de tre horisontale strekene (figur 11) til tre separate symboler. Dette hadde gjort at det hadde blitt veldig mange alternative symboler som måtte vises og dette ville ført til nye problem med plassmangel i brukergrensesnittet. Det hadde heller ikke løst posisjonering av overlappende symboler. De geometriske formene skal kunne posisjoneres på fem hovedlinjer: himmel linje, bakkelinje og tre linjer i mellom de to. Tall skal kunne posisjoneres på bakkelinjen og indikatortegn skal kunne possisjoneres på en linje over himmellinjen. 8. Sprint 3 - Idemyldringsfase 17. mars april Etter gruppen forkastet den første ideen så vi primært etter en ny løsning som var både rask og håndterte posisjonerings problemet nevnt i sprint to. 8.1 Mål Lage en hurtig løsning som håndterte posisjoneringsproblemet. 8.2 Reevaluering av tidligere interaksjonsmetoder Da kravene til motorikk ble forhøyet, førte det til at gamle idèer som var blitt forkastet kunne gjennopplives. En ny diskusjonsrunde rundt gamle idèer ble gjennomført for å komme frem til en hurtig interaksjonsmetode. Tidlig i sprint to ble drag and drop forkastet på grunn av at kravet til motorikk var 43

45 for høyt. Dette var ikke lenger tilfelle ettersom forutsetningen for motorikk nå var full funksjonalitet i en finger. Interaksjonsmetoden som skulle brukes for applikasjonen var en stor del av denne oppgaven. Hvordan dette skulle løses intuitivt og på en måte der man kunne få opp tempoet i språket som har vært en utfordring med andre ASK applikasjoner. Løsningen ble Drag and drop. Med innføringen av drag and drop førte det til forbedringer i tidligere deklarerte problemområder: Posisjoneringsproblemet For å løse posisjoneringsproblemet tok vi i bruk Drag and drop funksjonen. Denne jobbet i sammenarbeid med ankerpunkter som skal være lagt til på symbolene og linjene i editeringsflaten som tar tak i objektene. Dette vil føre til at det ikke blir tilfeldig hvor figurer blir plassert og det blir lettere å sette symboler og tegninger på riktige steder selv om man kanskje ikke har en stødig finger Hurtighet Med denne metoden eliminerte vi tegning av fulle tegn, noe som reduserte tiden brukt på å generere et tegn. Dette effektiviserte prosessen slik at vi følte det kom til et aksepabelt nivå av hurtighet Plassmangel Posisjoneringsmetoden i drag and drop gjorde at færre symboler trengtes i inputløsningen. Man trengte for eksempel ikke like mange variasjoner av samme tegn, det behøves ikke en sirkel hver for posisjonering over og under, men samme sirkel tilpasset seg utifra hvor bruker slapp tegnet. På denne tiden var det tiltenkt at systemet skulle autogenerere de riktige størrelsene ut i fra hvilken posisjon tegnet ble sluppet i. 44

46 8.2.4 Tegning Hvis Bliss ord og setninger skulle bygges fra symboler alene ville det krevet veldig mange grunnsymboler og mye tid ville gå tapt i leting blandt disse symbolene. Med tegninger kunne små ting som bøyninger av ord enkelt tegnes på en grunnstruktur. På denne måten økes hastigheten og bruker kan lettere håndtere de små elementene uten å måtte slå opp disse i en eventuell tastaturløsning Minimalisere sjansen for feiltolkning av tegn Ved å bruke drag and drop slipper brukeren å tegne fullverdige symboler fra bunnen av. Dette vil hindre sjansen for feiltolkningen og ikke gjenkjenning av tegn. Ved å hente inn et standardsymbol eller variasjon av dette vil man sette rammen for tegnet som er lettere å editere enn å tegne hele selv. 8.3 Møte med statped I møte med Kirsten. M. Bjerkan fra statped og oppdragsgiver ble statped brukt som ekspertråd og rådgiving angående ideene og retningen utviklingen av applikasjonen hadde tatt siden prosjektets start. Her presenterte gruppen det nye konseptet for både oppdragsgiver og statped. Løsningen som involverte drag and drop av symbol maler. Posisjonering var ikke et problem da man droppet symbolet der man ønsket. Disse blir så huket tak i av anchorpoints for å hindre tilfeldig plassering. For å få opp hurtigheten var også en tegnefunksjon involvert slik at små streker og tegn lett kunne føres på, for eksempel ved bøying av ord. Denne ideen skulle også ha en prediksjonmodel som tok inn de tegnene som allerede var lagt inn/tegnet og foreslo ord basert på det som allerede var laget. Drag and drop ble diskutert og tatt i mot av oppdragsgiver og stadped som en veldig lovende løsning. Møtet med statped ga oss en ny ressurs i form av Blisstavlen. Den ble brukt for å lære gramatisk oppbyggning, hvordan bygge opp enkle ord og settninger. Det var her vi lærte at de forskjellige gramatiske klassene blir skilt på farger. 45

47 Figur 12: Blisstavlen Figur 13: Gruppert på farger Blisstavlen Blisstavlen er som vist i Figur 12. Den har mange ord som brukes i dagligtalen, men mangler bøyningsformer av ord. I den aller øverste raden viser den noen ferdiglagde setninger og noen indikatorer (fortid, nåtid, fremtid, eindomspronomen m.f.). Resten av ordene grupperes etter ordklasser vist ved farger (figur 13): Rød = Verb Grønn = Adjektiv Gul = Substantiv Blå = Personer og personlige pronomen Hvit = Småord som spørreord, konjeksjoner, subkonjeksjoner, farger og tall. 46

48 8.4 Ny skisserprosses Etter å ha fått postiv tilbakemelding på den nye interaksjonformen fra både Bliss-kyndig i møte med statped og oppdragsgiver, startet gruppen en skisseringsprosess for en ny prototype. Den største utfordringen på dette tidspunktet var hvordan Bliss skulle presenteres på tastaturet. Da oppdragsgiver skulle på Bliss kurs med en offisell instruktør fra Statped sendte gruppen med oppdragsgiver en rekke spørsmål om oppsettet til Bliss. Et av disse spørsmålene var hva som var det minste antallet tegn Bliss kunne deles opp i uten å miste deler av språket. Mens gruppen avventet svar på dette skisserte gruppen nye potensielle brukergrensesnitt. Figur 14: Skisse Her utforsket vi muligheten ved å ha editeringsflaten i midten av prototypen og de forskjellige symbolene var på begge sider, dette var for å minimalisere avstanden et symbolen måtte dras. Øverst er da outputlinjen med en knapp som gjorde om tekst til tale representert ved bilde av en høytaler. 47

49 Figur 15: Skisse 2 Her hadde vi et hjul med geometriske former, der man kunne trykke på de forskjellige formene og få variasjoner av disse i feltet til venstre. Her utforsket vi ideene med å kategorisere de geometriske formene. Den utvalgte variasjonen skulle så dras opp til output/editeringsflaten øverst. Problemet her var at denne prototypen ikke skilte mellom editering og output. Et annet problemet var at vi ikke viste hvordan vi skulle dele inn og kategorisere Bliss på en god måte. Figur16: Skisse 3 48

50 i denne prototypen så vi på mapping av tegn til et tastatur. Det var mening at man kunne skille mellom flere forskjellige tastatur basert på fargekoder. Ved å velge mellom tre forskjellige farger kunne man få opp 3 ulike tastaturer. Dette var noe som ville gi oss flere lag og plass til flere knapper. Dette ble luket ut ettersom kompleksiteten av dette tasturet ble for høy. Vi hadde ingen god måte å kategorisere tegnene på. Det ble for mye trykking frem og tilbake for å få frem fullbyrdige ord og lite rom til variasjoner av tegn. Figur 17: QoC Andel skjermplass En utfordring var hvor mye skjermplass vi skulle bruke til bearbeiding av symboler. Etter å ha skissert opp noen varianter kom gruppen frem til at vi trengte rundt 50% av skjermplassen til bearbeiding av symboler noe QoC modellen over viser. 8.5 Ny kravspesifikasjon Etter å ha tilegnet oss ny kunnskap ble kravspesifikasjonene endret Funksjonelle krav Systemet skal ha en drag n drop funksjon Systemet skal ha en prediksjonsmodell Systemet skal ha en oversetter som legger til alfabetet under Blisstegn Systemet skal ha taleoutput 49

51 Systemet skal ha en funksjon som gir brukeren mulighet til å fjerne et enkelt ord eller -deler av et symbol på en enkel og ryddig måte Systemet skal ha en tegnefunksjon Systemet skal ha en ordbok med Blisstegn Ikke funksjonelle krav Systemet skal være hurtig Systemet skal kunne brukes med en finger Prediksjonsmodellen skal være rask 8.6 Forandring i brukergruppen I møte med statped dukket en ny brukergruppe opp. Denne baserer seg på de som skal kommunisere med brukergruppene våres. Foreldre, nære venner og hjelpearbeidere rundt brukerne kan også ønske å benytte seg av applikasjonen. 8.7 Tilbakemeldinger fra oppdragsgiver Arbeidsgiver var svært fornøyd med den nye ideen og ønsket at gruppen videre utviklet denne. Gruppen fikk også tilbakemelding fra oppdragsgiver som hadde vært på Blisskurs at Bliss symbolene kunne deles inn i 9 grunntegn, hvor da alle tegn kunne kategoriseres inn i. 8.8 Egenvurdering Etter tilbakemelding fra oppdragsgiver om at det eksisterte ni grunntegn, fant gruppen ut at de ville at det skulle være en essensiell del av prototypen. Derfor ble neste prototype utviklet basert på gjeldende kravspesifikasjon og de ni grunntegnene. 50

52 9. Sprint 4 - Prototype april - 6. mai Fokuset i denne sprinten var å utvikle en ny prototype. 9.1 Mål Utvikle en testbar prototype basert på ideen fra sist sprint. Finne et nytt prototype verkstøy. 9.2 De ni grunntegnene Da gruppen fikk tilbakemeldingen om at Bliss kunne kategoriseres inn i ni symboler falt siste puslespillbrikke på plass. Inputproblemet og posisjoneringsproblemet som har fulgt med hele prosjektet ble løst på en enkel og oversiktlig måte. Dette gjorde at gruppen kunne tegne mer detaljerte skisser med en input løsning som fungerte. I steden for at tastaturet skulle ta mellom forskjellige symboler (kun estimater gjort av gruppen) kunne en liten del av brukergrensesnittet settes av til dette. Dette førte til at gruppen kunne ha større arbeidsflater. Dette var også hva gruppen trengte for å kunne lage en prototype basert på den nye ideen med drag and drop som kunne brukertestes. 9.3 Skissering Med kunnskap om at Bliss kunne deles inn i ni kategorier og dette var nok til å kunne skrive alle Bliss symboler, startet gruppen å skissere med input delen av prototypen mye mer nøyaktig enn tidligere. Da vi hadde hadde problemer med plassmangel tok vi i bruk visualiseringsprinsippet om suppression av informasjon. Dette mest hensiktsmessig å bruke ettersom vi hadde store mengder tegn og symboler som skulle være store og tydelige. Ved bruk av denne teknikken unngikk vi cluttering. Dette har vi løst ved å bruke ni standardsymboler der de ulike 51

53 variasjonen er skjult under hver knapp. For eksempel hvis du trykker på linje symbolet vil alle variasjonene av en linje vises nedenfor standardsymbolene. På denne måten får vi frem alle variasjonene uten at alle vises til en hver tid. Figur 18: Skisse 4 Her er designet preget av informasjonen om at det finnes ni grunnformer. Vi kunne derfor avgrense hvor mange knapper vi trengte i layouten og hvordan vi skulle kategorisere de forskjellige variasjonene av alle tegnene. Ved å trykke på sirkel fikk man så opp alle variasjonene av en sirkel i boksen under. Når man fant den riktige variasjonen kunne man så dra symbolet til editeringsflaten og tegne videre på symbolet eller innhente flere støttetegn. I denne sprinten kom prediksjonsmodellen virkelig til liv ved å ha et område under editeringsflaten som kom med spesifikke forslag til tegn etterhvert som tegnet ble utformet. Det ble også lagt inn kategorisering i form av farger. Dette hjalp prediksjonsmodellen å gjøre mer effektive søk etter riktig tegn. 52

54 Figur 19: Skisse 5 Her er skissen inndelt i forskjellige deler. Til høyre har man fire valg som vil påvirke hva som vises der hvor de ni tegnene er vist. Her har du valg som standard, tall/tegn, egendefinerte og ordbok som er representert ved en bok. Til venstre i skissen er det et hjerte med firkanter på forskjellige områder. Disse er ankerpunkter som andre symboler kan hektes på slik at symbolet vil endres og dermed gi en annen betydning. Over hjertet er predikasjonsmodellen som skal vise forslag til ord som stemmer med de symbolene som er lagt inn og under er tegn som ofte blir brukt. Nederst til venstre var tanken at man kunne ved et tastetrykk endre om et symbol skulle ligge vannrett, loddrett eller på skrå i forskjellige retninger. Øverst i prototypen er outputlinjen som ordet blir sendt opp til når riktig ord er valgt i predikasjonsmodellen, og ved å trykke på høytalerknappen vil dette gjøres om fra tekst til tale. En ny funksjon vi tok med på denne skissen var en mulighet til å lagre setninger og ord i en liste vi kalte egenlagde (vist som tab 3 i figur 19). Der man kan for eksempel legge til ord man synes er vanskelig å skrive eller ord man bruker ofte, eller hele setninger man ofte har bruk for. Dette vil åpne opp for en hurtigere kommunikasjonsprosess. For eksempel dagligdagse setninger som : jeg må på do, jeg er sulten, jeg trenger hjelp, er setninger som kan vært aktuelle. 53

55 Figur 20: Skisse 6 Her designet litt renere enn i de tidligere skissene. Den viser en outputlinje øverst med en tilbakeknapp og en outputknapp. Farger, prediksjonsmodell og editeringsmeny har flitt flyttet på slik at brukergrensesnittet ser mer helhetlig ut. De geometriske formene samt menyknappene for standard (definerte), tall/tegn, egendefinerte og ordbok er fremdeles på høyre side av skjermen. 9.4 Papirprototype Etter å ha skissert oss frem til den endelige ideen, digitaliserte gruppen denne for å kunne teste flyten og logikken i ideen. Papirprototype teknikken egnet seg da godt da man kan simulere interaksjon og kompliserte funksjoner uten å investere for mye tid eller energi i ideen. Denne prototypen var revolusjonær, som vil si at den er kun ment til å brukes også kastes. Designet av prototypen er preget av universell utforming. Det er fokus på tydelighet, tilstrekkelig størrelse på knapper og intiuitivitet har kommet fremfor estetiske elementer. Vi har brukt klare farger for å hindre utydelig tekst. Der editeringsflaten har hvit bakgrunn og svart hjelpelinjer. Fargevalget valgt i prototypen er satt av BCI standard. 54

56 Figur 21: Papirproto grunnmodel Figur 22: Spesialtegn Her ser vi at området der de geometriske formene er plassert er et dynamisk område påvirket av hvilket valg man har tatt av fire forskjellige knappene på høyre side. Her er tall og spesialtegn valgt og dermed vises det i området. 55

57 Scroll benyttes i ordbok, spesialtegn og egenlagde tegn. Scrolling gjorde at vi kunne opprettholde størrelsen på knapper der det ikke var plass til å vise alle variasjonene ettersom dette var noe som var essensielt for vår brukergruppe. Dette vil være tidbesparende kontra og ha flere sider man skal trykke seg igjennom for å lete etter variasjonen man ønsker. Det er ment at man skal bruke fingeren til å dra skjermen opp og ned. Hvis dette er utfordrende er det lagt til pilknapper som ekstra funksjonalitet. Figur 23: Qoc Antall symboler Qoc Etter å ha prøvd ut litt forskjellige antall i prediksjonsmodellen kom gruppen frem til at seks forslag bør vises da dette øker sannsynligheten for at ønsket symbol vises uten at symbolene blir for små. Som igjen fører til at bruker raskere finner ønsket tegn Brukertest med papirprototype Denne prototypen ble utviklet med formålet om å brukerteste på medstudenter ved bruk av papirprototype. Det skulle det klippes og limes med flere lag for å simulere forskjellige hendelsesflyter. Til papirprototype testen brukte vi enkle metoder for å simulere flyten for å skrive et Blissord. Det ble printet opp flere eksemplarer av prototypen som vi klippet opp og hadde klare til å legge oppå bakgrunnsbildet (figur 21) når bruker trykket på en knapp. Bruker startet med bakgrunnsbildet. Når 56

58 bruker trykket på en knapp la vi papirklippet(ene) som passet oppå bagrunnsbildet for å simulere riktig flyt i prototypen. Gruppen viste testerne en setning i Bliss som de måtte lage Konklusjon til test Konklusjonen er at både plassering og størrelse på knapper var godt løst. Tastefeil er ikke bom på knapper men det er feil i form av forståelse av hvordan man skal gå videre. Disse tastefeilene ble generert på bakgrunn av lite forståelse for Bliss Kommentar Nesten alle tastefeil ble gjort på grunn av brukernes forståelse av Bliss. For eksempel ville mange bruke den geometriske formen V som indikatortegn, noe vi registrerte som feiltrykk. Veiledning refererer til hvor mye hjelp testere trengte for å fullføre testen. Veiledning ble gitt verbalt. Dette førte til at gruppen planla en mer omfattende innføring i Bliss for testerne før neste brukertest blir gjennomført. For fullstendig informasjon rundt brukertesten se vedlegg 1 testdokumentasjon. 9.5 Prototype Axure Gruppen var hele tiden på utkikk etter et nytt prototypingsverktøy som kunne simulere de funksjonene vi ønsket. Arbeidsgiver introduserte gruppen til programmet Axure som gruppen tok i bruk. 57

59 9.5.1 Ny iterasjon etter papirtest Figur 24: Ny iterasjon på prototype Etter papirprototype testen lagde vi neste iterasjon av prototypen i Axure. Prediksjonsmodell og editeringsmeny ble her videre utformet. Figur 25: Editeringsmeny Her ser vi editeringsmenyen med knappene frem, tilbake, viskelær, forkast og en pil som viser til fremtidige funksjoner. De bruker velkjente metaforer i form av tegn/labels som universelt representerer den funksjonen knappene har. 58

60 Da vi lagde prototypen merket vi at det var noen begresninger i forhold til interaksjonsformene vi så for oss. Drag and drop og scrolling kunne ikke simuleres. Gruppen måtte da komprimere med at hvis man trykket på et symbol ble denne automatisk plassert i editeringsflaten. Og en pil ned knapp der det var aktuelt med scrolling. Denne prototypen kunne heller ikke håndtere tegning Positive sider med programmet: Lett plassering av bilder og wireframes. Lett egendefinering av funksjoner. Mulighet til å gjemme/vise bilder og wireframes. Mulighet til å bruke egne bilder. Mulighet til å laste opp på midlertidig side (Axshare.com) Negative sider: (begrensninger) Kunne ikke simulere drag and drop. Kunne ikke simulere scroll i elementer. 9.6 Hvordan fungerer prototypen For å få prototypen til å fungere som vi ville brukte vi MS Paint til å lage bilder av alle knappene. Alle knappene ble så tillagt funksjoner som viste de knappene og bildene de skulle samt skjulte andre knapper og bilder som ikke lenger skulle være synlige. Det ble laget 220 unike bilder for å få prototypen til å fungere. Hvis det for eksempel ble trykket på en geometrisk form ble de alternative geometriske formene (heretter AGF) synlige og lagt foran de andre. Ble et av de AGFene valgt ble tilhørende editeringsbilde gjort synlig og alle de andre editeringsbildene gjort usynlige. Predikasjoner fra alle ordklassene med den AGFen som lå i editeringsflaten i tegnet ble så gjort synlige og lagt foran alle de andre prediksjonene. Når det så ble trykket på et av tegnene i prediksjonsmodellen ble den tidligere prediksjonsmodellen og 59

61 editeringsflaten gjort usynlige, bildene som ble vist da programmet åpnet ble gjort synlige og lagt foran. I outputlinjen ble et nytt bilde vist, det gamle skjult og outputknappen lagt over outputlinjen. 9.7 Gjennomgangstest oppdragsgiver Vi gjennomførte en brukertest på oppdragsgiver for å se hvilke tilbakemeldinger vi fikk. Vi filmet denne med et screencaptureprogram og et klipp fra denne testen ligger tilgjengelig på: Test på medstudenter Testen viste at det er en høy læringskurve. Hastighet og feiltrykk ble drastisk forbedret jo mer kjennskap man hadde til språket og prototypen. Ved å introdusere brukeren for generelle funksjoner i programmet og en kort innføring i hvordan Bliss fungerte, ble det en merkbar forskjell i hvor hurtig brukeren gjennomførte testen og antall feilklikk. For fullstendig informasjon rundt brukertesten se vedlegg 1 testdokumentasjon. 9.9 Tilbakemeldinger Tilbakemeldinger fra oppdragsgiver var positive. Det var ønskelig å legge opp til flere test scenarioer og legge til en kamerafunksjon for å ta bilder og vise dette til personer i nærheten. Dette er en mye brukt måte å kommunisere på mellom Blissbrukere og oppdragsgiver ønsket at dette skulle implementeres i prototypen. Det var også ønskelig å implementere en setning til i prototypen, slik at to setninger kunne skrives. Tilbakemeldingene fra medstudenter gikk ut mest ut på at et ord ble bygget på en annen måte en strukturen i prototypen tillot, men dette ville ikke vært et problem i det faktiske produktet, bare en hindring i Axure. 60

62 9.10 Ny kravspesifikasjon Tilbakemeldingene fra de to testene førte til en ny kravspesifikasjon Funksjonelle krav Systemet skal ha en drag and drop funksjon Systemet skal ha en prediksjonsmodell Systemet skal ha en oversetter som legger til alfabetet under Blisstegn Systemet skal ha taleoutput Systemet skal ha en funksjon som gir brukeren mulighet til å fjerne et enkelt ord eller deler av et symbol på en enkel og ryddig måte Systemet skal ha en tegnefunksjon Systemet skal kunne lagre setninger til gjenbruk senere Systemet skal kunne ta bilder og legge disse i egendefinerte Systemet skal ha en ordbok med Blisstegn Ikke funksjonelle krav Systemet skal være hurtig Systemet skal kunne brukes med en finger Prediksjonsmodellen skal være rask Prediksjonsmodellen skal vise 6 ordforslag Prediksjonsmodellen skal dele inn forskjellig type ord i farger Tegnefunksjonen skal interagere med drag and drop 9.11 Resultat Sprint fire ga oss flere svar. Ved å utvikle fra ståstedet om at de ni grunnsymbolene skulle stå i fokus klarte vi å implementere et samarbeid mellom disse og drag and drop teknikken som løste interaksjonsmetoden på en god måte. Vi fikk gode svar på at vi var på rett vei ved hjelp av brukertesten. 61

63 Det var klart at jo mer erfaring man hadde med bruk av prototypen desto mer eskalerte hastighet og brukeropplevelse. Tatt i forutsetning at det påkreves at brukerne skal kunne Bliss fra før er dette et meget godt utgangspunkt. 10. Sprint mai mai Fokus i denne sprinten var primært rapportskriving og en ny iterasjon av prototypen Rammer Rammene var uendret fra forrige sprint, men oppdragsgiver ønsket også en funksjon hvor det er mulig å ta bilder av gjenstander og legge disse inn sammen med teksten Mål Skrive ferdig dokumentasjon Legge til ny funksjon i prototypen for å ta bilder og legge disse i egenlagde setninger. Legge til en setning til i prototypen slik at man kan skrive to setninger i den Fikset tilbakemeldinger Sprint fem handlet mest om små forandringer av prototypen og legge til ekstrafunksjonalitet som oppdragsgiver ønsket etter siste evaluering. Det var ønskelig å gjøre prototypen enda mer realistisk ved å legge til en simulering på fungerende fargevalg i prediksjonen Kamera Oppdragsgiver ønsket å komme med en tilleggsfunksjon som ville tillate brukerne å legge til bilder til tegnene. Dette for å gi produktet en ekstra dimensjon som vil være behjelpelig for kommunikasjon med ikke Blissbrukere. 62

64 Figur 26: Prototype med kamerafunskjon Kamera knappen finner man ved å scrolle ned i actionmenyen på bunnen. Ved å trykke på denne vil man aktivere kamerafunksjonen innebygd i nettbrettet som direkte skal mate applikasjonen med bildet som blir tatt Fungerende farger For å få prototypen til å virke mer realistisk måtte vi ha en prediksjonsmodell som fungerte med fargevalgene. For å få til dette lagde vi tegn i alle de 5 fargene som inneholdt den geometriske formen som ble lagt i editeringsflaten. Det ble deretter laget et komplisert system som viste og skjulte prediksjonene etterhvert som editeringsflaten ble fylt og farger ble valgt. Valgte man ingen farger viste prediksjonsmodellen fra alle ordklassene. For å få til dette ble alle bildene i prediksjonsmodellen (farger inkludert) tillagt funksjoner som viste og skjulte andre bilder for at programmet skulle virke sømløst. For eksempel: når en geometrisk form har blitt lagt i editeringflaten viser prediksjonsmodellen ord fra alle ordklassene. Hvis en farge så blir valgt blir prediksjonene for AGFen i editeringsflaten vist, men kun i den ordklassen fargen representerer. Blir en annen farge valgt for samme AGF blir de forrige fargene skjult og predikasjonene tilhørende ordklassen fargen representerer lagt foran de andre og gjort synlige. 63

65 Når et ord har blitt valgt og lagt opp i outputlinjen beholder predikasjonsmodellen fargevalget. Det vil si at predikasjonene for den ordklassen fremdeles er synlige, men lagt bak et hvitt bilde siden editeringsflaten er tom og predikasjonsmodellen derfor ikke har noen tegn å predikere. En gjennomgang av prototypen ligger tilgjengelig på: Her vises prediksjonsmodellen med farger og lagre setning/bruke lagrede setninger Test Det var planlagt og ønskelig å gjøre en kvalitativ test på den aktuelle brukergruppen. Dette var desverre ikke gjennomførbart ettersom tilgang på testobjekter ikke var tilstrekkelig. Utdypet i testdokumentet Endelig kravspesifikasjon Endelig versjon av kravspesifikasjon presenteres i produktrapporten Endelig Prototype Endelig versjon av prototypen presenteres i produktrapporten Evaluering Vi følte vi kom godt i målene satt for sprinten. Både kamerafunksjon og ytterlige funksjnalitet ble lagt til i prototypen. I likhet med andre sprinter fikk vi endringer, ny informasjon og elementer som skulle implementere. Dette var noe vi alltid tok til rette og utviklet produktet og idèen i den retningen som var ønsket. 64

66 11. Kilder Benyon, D. (2010). Designing interactive systems. London: Pearson Education Limited. Blissymbolics communication international. (U.Å). About Blissymbolics. Hentet , fra Blissymbolics communication international.(u.å). Why is Bliss used. Hentet , fra Buxton, B. (2007). Sketching User Experiences. San Francisco: Elsevier. Dysleksi Norge.(U.Å). Statistikk. Hentet , fra Isaac Norge. (U.Å). Hva er ASK?. Hentet , fra Katrine, Cerebral parese forening.(2010). Informasjon angående antall cp tilfeller i Norge. Hentet , hentet fra Morville, P., Rosenfeld, L.(2007). Information Architecture for the World Wide Web, Third Edition. California: O Reilly. Spence, R. (2007). Information Visualization Design for interaction. London: Pearson Education Limited. Statped. (2011). Afasi. Hentet , fra Statped.(U.Å). Blisstegn. Hentet fra 65

67 Øye, O.J. (2012a). Informasjon om web prosjekt. Hentet , fra Øye, O.J. (2012b). Informasjon om prototyping. Hentet , fra Øye, O.J. (2012c). Informasjon om systemutvikling. Hentet , fra Øye, O.J. (2012d). Informasjon om menneske maskin interaksjon. Hentet , fra Øye, O.J. (2012e). Informasjon om universell utforming. Hentet , fra Øye, O.J. (2012f). Informasjon om informasjonsarkitektur. Hentet , fra Blissymbolics Communication International.(2010). Licensing. Hentet , fra Creative commons. (2014). License. Hentet , fra ( Statped. (U.Å). Om statped. Hentet , fra 66

68 Produktdokumentasjon 67

69 Indeks 1. Forord Hensikten med prototypen Kort beskrivelse av prototypen Beskrivelse av prototypen Endelig kravspesifikasjon Generelt Hvordan kravspesifikasjonen er organisert Hvem kravspesifikasjonen er for? Krav til prototype: Funksjonelle krav: Ikke funksjonelle krav: Design krav Samsvar mellom kravspesifikasjon og produkt Prototypens oppbygning Outputlinjen - punkt Sammenheng med andre komponenter Funksjoner og muligheter Fargevalg - punkt Sammenheng med andre komponenter Funksjoner og muligheter Editeringsflaten - punkt Sammenheng med andre komponenter

70 4.3.2 Funksjoner og muligheter Prediksjonsmodellen -punkt Sammenheng med andre komponenter Funksjoner og muligheter Editeringsmeny - punkt Sammenheng med andre komponenter Funksjoner og muligheter Tegnflate - punkt Sammenheng med andre komponenter Funksjoner og muligheter Outputknappen - punkt Sammenheng med andre komponenter Funksjoner og muligheter Blissmeny - punkt Sammenheng med andre komponenter Funksjoner og muligheter Instruksjoner Instruksjoner for hver del Tegne selv Bruke de geometriske formene Egenlagde setninger/ord/bilder Ordbok Angre Gå frem Slett manuelt Fjern alt innhold i editeringsflaten (punkt 3)

71 Endring av ord i outputlinjen (punkt 1) Ta et bilde Lagre setning Flyt for å skrive jeg vil på kino i Bliss Velg streker Velg stor vertikal strek Velg jeg fra prediksjonsmodell Trykker på hjerte Velg hjerte variant Gå til tall og spesialtegn Scroll ned Velg støttetegn til hjerte Velg vil fra predikasjonsmodell Gå tilbake til grunnsymboler Velg trekant Velg trekant variant Velg på fra predikasjonsmodell Trykk på firkant Velg hus fra firkantvarianter Trykk på sirkel Velg liten sirkel med prikk Velg kino fra predikasjonsmodell Trykk på lyd-output Diagrammer Usecase Usecase diagram

72 4.3 Tekstlig flyt Tabel 1: Tekstlig flyt Aktivitetsdiagram Avsluttende del Fremtidige utviklingsmuligheter Ordbok Opplæring Internasjonal brukergruppe Kommunikasjon Konklusjon

73 1. Forord I dette dokumentet vil vi presentere prototypen og den endelige kravspesifikasjonen. Forutsetningen for å lese dette dokumentet er å ha satt seg inn i all informasjon i prosessrapporten. 1.1 Hensikten med prototypen Hensikten med prototypen er å teste at de løsningene vi har kommet frem til oppfyller de kravene som er satt av brukergruppen og oppgaven. Den skal også fungere som en ledelinje mot en endelig kravspesifikasjon. 1.2 Kort beskrivelse av prototypen Produktet er bygget opp som et kommunikasjonsverktøy, ikke en tekstbehandler eller læreverktøy. Prototypen åpner ikke opp for lagring eller lesing av lengre tekster. Dette er ikke et ferdig produkt, men en prototype for å vise hvordan vi løser de ulike problemstillingene som blir satt i oppgaven. Vi ser for oss at sluttproduktet skal være godt nok til å erstatte bruk av fysiske bilder, miming og eksisterende nettbrettsløsninger. 2. Beskrivelse av prototypen Produktet som er laget skal være en prototype til en applikasjon for bliss på nettbrett. Hovedessensen til applikasjonen er at det skal være et kommunikasjonsverktøy for personer som har mistet eller ikke har hatt taleevne. Produktet brukes primært som et tegne-/skrive-program som konverterer ord og setninger fra Bliss til audio-output. Dette vil tillate brukere som ikke er kapable til å bruke taleevne til å effektivt kommunisere med andre. Det kan for eksempel erstatte miming og bilder av mat for å vise at man er sulten. 72

74 3. Endelig kravspesifikasjon 3.1 Generelt Kravspesifikasjonen skal definere prototypen og sluttproduktets funksjonalititet og mål. Kravspesifikasjonen ble utviklet etter hvert som som kunnskap og ferdigheter ble innhentet. På grunn av manglende informasjon om brukergrupper og forutsetninger for bruk var kravspesifikasjonen i konstant utvikling. 3.2 Hvordan kravspesifikasjonen er organisert Spesielt for denne bacheloroppgaven er at det ikke ble utdelt en kravspesifikasjon eller laget en i sammarbeid med oppdragsgiver da oppgaven ble startet. Vi skulle prototype oss frem til den endelige kravspesifikasjonen gjennom arbeid og informasjonsinnhenting over flere sprinter. Det var ikke mulig for verken oss eller oppdragsgiver å sette krav når vi ikke hadde informasjon om forutsetninger og rammekrav for bruk av det ferdige produktet. 3.3 Hvem kravspesifikasjonen er for? Kravspesifikasjonen og prototypen er laget for oppdragsgiver slik at den kan brukes til videreutvikling senere. 3.4 Krav til prototype: Prototypene skal kunne brukertestes på Skal utvikles igjennom flere iterasjoner med brukertesting Skal kunne simulere touch teknologi via prototype teknikker. Skal utvikles fra low-fidelity til high-fidelity Funksjonalite t skal utvikles med tanke på dybde; bredde kommer i senere steg. 73

75 3.5.1 Funksjonelle krav: Skal benytte seg av touch. Skal kunne ta i mot Bliss innput Skal konvertere Bliss til tale Systemet skal ha en prediksjonsmodell Systemet skal ha en tegnefunksjon Systemet skal ha en ordbok med Blisstegn Det skal være mulig å slette elementer i editeringsflaten. Det skal være mulig å slette elementer i outputlinjen. Systemet skal ha en funksjon som gir brukeren mulighet til å fjerne deler av et symbol på en enkel og ryddig måte Det skal være mulig å viske ut elementer fra editeringsflaten. Systemet skal kunne konvertere fra bliss til latinske alfabet i outputlinjen. Systemet skal kunne gjøre mer spesifikke sorteringer i prediksjonsmodellen ved bruk av grammatiske fargekoder. Det skal være mulig å hente ord ned fra outputlinjen tilbake til editeringsflaten. Det skal være mulig å hente ord direkte fra ordboken til outputlinjen eller editeringsflaten. Systemet skal fungere uavhengig av en internettforbindelse. Systemet skal ha ankerpunkter som tar tak i figurene. Knapper skal gi feedback ved utheving av valgt knapp Systemet skal kunne ta bilder og lagre disse Systemet skal ha en drag n drop funksjon Systemet skal kunne lagre setninger til gjenbruk senere Prediksjonsmodellen skal vise 6 ordforslag Prediksjonsmodellen skal dele inn forskjellig type ord i farger Ikke funksjonelle krav: Systemet krevet at bruker forstår og kan skrive bliss. Det forutsettes at bruker setter seg inn i programmet og bygger seg opp erfaring, for å utnytte potensialet. 74

76 Det skal være 99,9% oppetid. På grunn av stor variasjon i kognitive evner hos brukergruppen er det ikke satt maks antall handlinger/trykk for å skrive et ord. Dette er på grunn av varierende kompleksitet i tegnene. Bruker er avhengig av innføring av programmet for bruk. Applikasjonen skal bruke maksimum et sekund på oppstart. Oppslag mot ordbok/blissdatabasen skal bruke maksimum 0.5 sekunder Systemet skal være hurtig Prediksjonsmodellen skal være rask Systemet skal kunne brukes med en finger Design krav Knapper skal ha tilstrekkelig størrelse for å veie opp for unøyaktigheter Fargekontraster skal være tydelige. Plassering av knapper skal ligge naturlig i forhold til hverandre. 3.6 Samsvar mellom kravspesifikasjon og produkt Etterhvert som vi har utviklet prototypen har vi kravspesifikasjonen endret seg. Normalt ville en kravspesifikasjon satt standarden for hvordan produktet skal utvikle seg, men i vårt tilfelle har det vært produktet som har banet vei for hvordan kravspesifikasjonen skulle se ut. Kravspesifikasjonen er skrevet med tanke på både prototypen og hvordan vi ser for oss at det endelige produktet skal være. Ettersom vi er på et stadiet der produktet er en prototype er ikke alle funksjoner fungerende og implementert. Det har ikke vært mulig å teste på alle ikke-funksjonelle krav. 75

77 4. Prototypens oppbygning Figur 1: Applikasjonsmenyen 1. Outputlinje 2. Fargevalg 3. Editeringsflate 4. Predikasjonsmodel 5. Editeringsmeny 6. Tegnflate 7. Outputknapp 8. Blissmeny 76

78 Figur 2 - Oversikt over flyt Figuren over viser hvordan de forskjellige delene kommuniserer med hverandre. Dette blir forklart punkt for punkt under. 77

79 4.1 Outputlinjen - punkt Sammenheng med andre komponenter Figur 3: Sammeheng outputlinjen Editeringsflaten, Prediksjonsmodellen, Editeringsmeny, Outputknapp og Tegnflaten Funksjoner og muligheter Når et ord har blitt valgt fra prediksjonsmodellen havner det i outputlinjen. Du kan dra et ord herfra ned i editeringsflaten eller i søppelbøtten. På forespørsel frigir outputlinjen informasjon til outputknappen for avspilling. Den mottar informasjon direkte fra egenlagde setninger og komplette ord fra ordbok fra Tegnflaten. 78

80 Mottar kommandoer fra editeringsmenyen. Lagreknappen lagrer setningen som er i outputlinjen i egenlagde setninger segmentet. Slettknappen interagerer med outpulinjen kun hvis editeringsflaten er tom: da vil den slette et og et ord fra outputlinjen. Hvis et bilde ligger i outputlinjen, vises dette på skjermen samtidig som setningen blir spilt av. 4.2 Fargevalg - punkt 2 Her vises fem forskjellige farger som hver representerer en ordgruppe (verb, adjektiv, substantiv osv) Sammenheng med andre komponenter Figur 4: Sammeheng fargevalg Prediksjonsmodel Funksjoner og muligheter Når man velger en farge fører dette til at prediksjonsmodellen kun viser forslag med tilsvarende farge. 79