SUPPLERENDE KOMMUNIKSJONS ASSISTENT

Størrelse: px
Begynne med side:

Download "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: https://www.youtube.com/watch?v=6r-3izxeh1c 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

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Supplerende Kommunikasjon Assistent (SKA) Bachelorprosjektet går

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Forprosjektrapport MetaView

Forprosjektrapport MetaView Forprosjektrapport MetaView BACHELOROPPGAVE VÅREN 2014 Presentasjon Tittel: MetaView Oppgave: Utvikle en Windows 8 applikasjon som skal forenkle en liten del av MetaVision. Et verktøy for sykehus, leger

Detaljer

Brukerveiledning WordPress. Innlogging:

Brukerveiledning WordPress. Innlogging: Brukerveiledning WordPress Her er en liten guide for hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging Lage en side Lage et innlegg Innlogging: For å logge

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Innføring i bruk av Klikker 4

Innføring i bruk av Klikker 4 www.normedia.no Postboks 24 1451 Nesoddtangen. Tlf 66915440 Fax 66912045 e-post: kontakt@normedia.no www.cricksoft.com Innføring i bruk av Klikker 4 Det vil bare ta deg noen få minutter å lese denne lille

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre Læringsmål og pensum Mål Lære å lage større og sammensatte programmer Pensum Pythonboka kap. 1-9, 12 Teorikapitlet

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

Prosjekt «Lære å lytte på ipad»

Prosjekt «Lære å lytte på ipad» Prosjekt «Lære å lytte på ipad» Prosjektnummer Extrastiftelsen: 2011/3/0322 Sluttrapport, desember 2012 Sammendrag Møller Trøndelag kompetansesenter (MTK) har tidligere utviklet et lytteprogram på PC for

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Testdokumentasjon Innholdsfortegnelse

Testdokumentasjon Innholdsfortegnelse Testdokumentasjon Innholdsfortegnelse Brukertesting... 2 Hva er brukertesting?... 2 Formål med brukertesten... 2 Brukertest 1:... 3 Sjekkliste på testdagen:... 3 Kjøreplan... 3 Testteamet... 4 Hvordan

Detaljer

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

En enkel lærerveiledning

En enkel lærerveiledning En enkel lærerveiledning ~ 1 ~ Innhold INNLEDNING... 3 Hva?... 3 Hvorfor?... 3 INN- og UTLOGGING... 4 Innlogging... 4 Utlogging... 5 Lærerinnlogging/-utlogging... 5 OUTLOOK / EPOST... 6 Skrive epost...

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Grafisk løsning av ligninger i GeoGebra

Grafisk løsning av ligninger i GeoGebra Grafisk løsning av ligninger i GeoGebra Arbeidskrav 2 Læring med digitale medier 2013 Magne Svendsen, Universitetet i Nordland Innholdsfortegnelse INNLEDNING... 3 GRAFISK LØSNING AV LIGNINGER I GEOGEBRA...

Detaljer

BlindShell bruksanvisning

BlindShell bruksanvisning Dato: 1.6.2015 BlindShell bruksanvisning BlindShell er en smarttelefon for blinde og svaksynte brukere. Enheten betjenes med enkle bevegelseskommandoer, talemeldinger leses opp ved hjelp av kunstig tale

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

GC4AXWG [WHERE DO YOU WANT TO GO TODAY?] av thomfre. En introduksjon til Wherigo og Wherigo-cacher

GC4AXWG [WHERE DO YOU WANT TO GO TODAY?] av thomfre. En introduksjon til Wherigo og Wherigo-cacher GC4AXWG av thomfre [WHERE DO YOU WANT TO GO TODAY?] En introduksjon til Wherigo og Wherigo-cacher [EN INTRODUKSJON TIL WHERIGO].--.....-... --. --- Innholdsfortegnelse Hva er Wherigo?... 2 Wherigo-moduler...

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Administrering av SafariSøk

Administrering av SafariSøk Administrering av SafariSøk Administrering av SafariSøk Revisjonshistorie Revisjon $Revision: 1.6 $ $Date: 2003/08/05 12:44:02 $ Innholdsfortegnelse 1. Om programmet... 1 Generelt... 1 2. Fremgangsmåter...

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

Med Evernote opplever du raskt noen digitale funksjoner som monner Lær deg noe av det grunnleggende i bildebehandling

Med Evernote opplever du raskt noen digitale funksjoner som monner Lær deg noe av det grunnleggende i bildebehandling Denne fila er laget for å gi en antydning om den tilnærmingen som er brukt i boka. Med et noe beskjedent blikk på noen av illustrasjonene, tror vi dette kan gi deg et greit innblikk i hvordan boka er bygd

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Hvordan gjøre fjernhjelp til noen som ønsker hjelp med Hageselskapets portal? Av Ole Petter Vik, Asker Versjon 1.2-27.09.2012

Hvordan gjøre fjernhjelp til noen som ønsker hjelp med Hageselskapets portal? Av Ole Petter Vik, Asker Versjon 1.2-27.09.2012 Hvordan gjøre fjernhjelp til noen som ønsker hjelp med Hageselskapets portal? Av Ole Petter Vik, Asker Versjon 1.2-27.09.2012 Mange får spørsmål om å hjelpe noen med å bruke Hageselskapets portal. Enkle

Detaljer

Bytte til OneNote 2010

Bytte til OneNote 2010 I denne veiledningen Microsoft OneNote 2010 ser helt annerledes ut enn OneNote 2007, så vi har laget denne veiledningen for å gjøre det så enkelt som mulig for deg å lære forskjellene. Les videre for å

Detaljer

Lotus Traveler - Manual for installasjon

Lotus Traveler - Manual for installasjon Lotus Traveler - Manual for installasjon Innholdsliste Nedlasting...2 Installasjon...3 Konfigurering...4 Problemer...5 Nedlasting 1) Åpne nettleseren på mobilen din. På de fleste Nokia-telefoner har denne

Detaljer

Communicate SymWriter: R5. Brett og knapper

Communicate SymWriter: R5. Brett og knapper Communicate SymWriter: R5. Brett og knapper Innhold R5.1 Hva er et brett - en oversikt...2 R5.2 Lage et brett....................................................2 R5.3 Endre utseendet på et brett....6

Detaljer

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING 1 Word 1.1 Gjør ting raskt med Fortell meg det Du vil legge merke til en tekstboks på båndet i Word 2016 med teksten Fortell meg hva du vil gjøre.

Detaljer

Midtveisrapport Mobilt prosjekthådteringsverktøy

Midtveisrapport Mobilt prosjekthådteringsverktøy Midtveisrapport Mobilt prosjekthådteringsverktøy Nirojah Melina Balagumar Tor-Erik Askildsen Neethi Warman Rasalingam Innholdsfortegnelse Innledning... 2 Beskrivelse av Mobilt prosjekthåndteringsverktøy...

Detaljer

Pong. Oversikt over prosjektet. Steg 1: En sprettende ball. Plan. Sjekkliste. Introduksjon

Pong. Oversikt over prosjektet. Steg 1: En sprettende ball. Plan. Sjekkliste. Introduksjon Pong Introduksjon Pong er et av de aller første dataspillene som ble laget, og det første dataspillet som ble en kommersiell suksess. Selve spillet er en forenklet variant av tennis hvor to spillere slår

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

SMART Ink 3.0 BRUKERVEILEDNING FOR MAC OS X-OPERATIVSYSTEMET

SMART Ink 3.0 BRUKERVEILEDNING FOR MAC OS X-OPERATIVSYSTEMET SMART Ink 3.0 BRUKERVEILEDNING FOR MAC OS X-OPERATIVSYSTEMET Merknad om varemerker SMART Ink, SMART Meeting Pro, smarttech, SMART-logoen og alle SMART-slagord er varemerker eller registrerte varemerker

Detaljer

WordPress. Brukerveiledning. Kjære kunde. Innlogging:

WordPress. Brukerveiledning. Kjære kunde. Innlogging: Brukerveiledning WordPress Sist oppdatert: 26.02.2014 Kjære kunde Her er en liten guide for å hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging - s.1 Kontrollpanel

Detaljer

PBL Barnehageweb. Brukerveiledning

PBL Barnehageweb. Brukerveiledning PBL Barnehageweb Brukerveiledning 1 1. Innledning Gratulerer med valget av nye PBL Barnehageweb! Med PBL Barnehageweb skal det være enkelt å lage en brukervennlig, moderne og profesjonell nettside for

Detaljer

What designers know. Rune Simensen, 04hbmeda Designhistorie og designteori Høgskolen i Gjøvik, våren 2006

What designers know. Rune Simensen, 04hbmeda Designhistorie og designteori Høgskolen i Gjøvik, våren 2006 Rune Simensen, 04hbmeda Designhistorie og designteori Høgskolen i Gjøvik, våren 2006 Innledning Oppgaven omfatter: skriv et fortellende resymé av Bryan Lawsons bok What Designers Know Oxford England :

Detaljer

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

Detaljer

Slik tar du i bruk nettbanken

Slik tar du i bruk nettbanken NETTBANK Slik tar du i bruk nettbanken For nybegynnere 1 Enklere hverdag med nettbank Innledning I nettbanken kan du selv utføre en rekke banktjenester når som helst i døgnet. Fordeler med nettbank Full

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

SymWriter: R6 Innstillinger, preferanser og verktøylinjer

SymWriter: R6 Innstillinger, preferanser og verktøylinjer SymWriter: R6 Innstillinger, preferanser og verktøylinjer Innhold R6.1 Startinnstillinger og utseende...3 R6.2 Tekst og bilder...................................................4 R6.3 Tale og staving...5

Detaljer

Forord... 3. Introduksjon til studentresponssystem... 3. Hva er et studentresponssystem?... 3. Hvorfor bruke SRS?... 3

Forord... 3. Introduksjon til studentresponssystem... 3. Hva er et studentresponssystem?... 3. Hvorfor bruke SRS?... 3 Innholdsfortegnelse Forord... 3 Introduksjon til studentresponssystem... 3 Hva er et studentresponssystem?... 3 Hvorfor bruke SRS?... 3 Hvordan blir undervisningen ved bruk av SRS?... 3 Hva slags enhet

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

Veileder for opplæring i å bruke iphone. ved hjelp av instruksjonsfilmer

Veileder for opplæring i å bruke iphone. ved hjelp av instruksjonsfilmer Veileder for opplæring i å bruke iphone ved hjelp av instruksjonsfilmer Forfattere: Mari Digernes Gro Marit Rødevand Prosjekt: Mestring med mobil Dato: 15.10.2014 Innhold 1. Innledning 3 Hvorfor lære å

Detaljer

King Kong Erfaren Scratch PDF

King Kong Erfaren Scratch PDF King Kong Erfaren Scratch PDF Introduksjon I dette spillet inspirert av historien om King Kong, skal vi se hvor lett det er å bruke grafikk som ikke allerede ligger i Scratchbiblioteket. I spillet styrer

Detaljer

Brukte studieteknikker

Brukte studieteknikker Brukte studieteknikker Forfattere Celine Spjelkavik Michael Bakke Hansen Emily Liane Petersen Hiske Visser Kajsa Urheim Dato 31.10.13! 1! Innhold 1. Problemstillinger...3 2. Innsamlingsstrategi.4 2.1 Metode..4

Detaljer

Brukerveiledning for SMS fra Outlook

Brukerveiledning for SMS fra Outlook Brukerveiledning for SMS fra Outlook Grunnleggende funksjonalitet Med SMS fra Outlook kan du enkelt sende både SMS og MMS fra Outlook. Programmet er integrert med din personlige Outlookkontaktliste og

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

www.mentalhelse.no Vårt nettsted En håndbok for lokale nettredaktører i fylkes- og lokallag

www.mentalhelse.no Vårt nettsted En håndbok for lokale nettredaktører i fylkes- og lokallag www.mentalhelse.no Vårt nettsted En håndbok for lokale nettredaktører i fylkes- og lokallag Introduksjon Gratulerer Mental Helse! Våre nettsider har fått en oppfriskning og fremstår i ny drakt. Design

Detaljer

- reklamebannere mobil og tablet

- reklamebannere mobil og tablet Spesifikasjoner - reklamebannere mobil og tablet FINN.no Versjon 2.4 Sist oppdatert 16.08.2013 1. Innhold Innhold Introduksjon Målsetning Spesifikasjoner HTML Fysisk størrelse 225 px* Eksempler Størrelser

Detaljer

Kort brukerveiledning for Smartboard

Kort brukerveiledning for Smartboard Kort brukerveiledning for Smartboard For å slå på (og av) prosjektøren, benytt kontrollpanelet ved siden av Smartboardet: OBS! Dette er ikke en whiteboard, så ordinære tusjer må ikke brukes (kun de som

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

Kjørehjelperen Testdokumentasjon

Kjørehjelperen Testdokumentasjon 2013 Kjørehjelperen Testdokumentasjon Høgskolen i Oslo og Akershus Henrik Hermansen og Lars Smeby Gruppe 8 26.05.2013 Forord Dette dokumentet tar for seg to forskjellige ting. Først forklares det hvordan

Detaljer

Tillit og troverdighet på nett. Tillit. troverdighet. på nett. Cato Haukeland, 2007

Tillit og troverdighet på nett. Tillit. troverdighet. på nett. Cato Haukeland, 2007 Tillit og troverdighet på nett Tillit OG troverdighet på nett Bacheloroppgave ibacheloroppgave nye medier i nye medier av Cato Haukeland, Universitetet i Bergen 2007 Cato Haukeland, 2007 1 Innhold 1 Forord

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Sluttrapport NMT-Pekeboka Signe Torp

Sluttrapport NMT-Pekeboka Signe Torp Sluttrapport NMT-Pekeboka Signe Torp Prosjektet er finansiert med midler fra Extrastiftelsen Prosjektnummer 2012/3/0092 Forord Sammendrag Kap. 1: Bakgrunn og målsetting for prosjektet Kap. 2: Prosjektgjennomføring

Detaljer

BLISSTAVLE for Rolltalk Designer. Veiledning

BLISSTAVLE for Rolltalk Designer. Veiledning BLISSTAVLE for Rolltalk Designer Veiledning Innhold Installasjon av Blisstavla... 3 Blisstavla forside... 3 Teste programmet... 3 Lage en snarvei til programmet fra skrivebordet... 4 Blisstavla med ordforslag...

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549 Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste

Detaljer

Presentasjon. Kristian Hewlett- Packard 29.05.2012

Presentasjon. Kristian Hewlett- Packard 29.05.2012 2012 Presentasjon Kristian Hewlett- Packard 29.05.2012 1 Innledning Denne innledningen inneholder informasjon om gruppen, samt bakgrunn og mål for oppgaven og en introduksjon til temaet. 1.1 Gruppen Vår

Detaljer

Hva er Smartbok? Hva er Smartbok- PLUSS? Hvordan får jeg tilgang til Smartboka? Hvor kan jeg bruke Smartboka? Kan jeg miste min Smartbok?

Hva er Smartbok? Hva er Smartbok- PLUSS? Hvordan får jeg tilgang til Smartboka? Hvor kan jeg bruke Smartboka? Kan jeg miste min Smartbok? En introduksjon til Hva er Smartbok? Smartbok er en digital utgave av Gyldendals kjente læreverk som kan brukes på PC og Mac, på nettbrett og kan lastes ned og brukes offline. Hva er Smartbok- PLUSS? I

Detaljer

Versjonsbrev. for Extensor05 versjon 1.16

Versjonsbrev. for Extensor05 versjon 1.16 Versjonsbrev for Extensor05 versjon 1.16 Bodø, 28. desember 2011 Innhold Viktig informasjon... 3 Generelt... 3 Extensor Kode Oppdatering... 4 Personalia... 4 Pårørende... 4 Serieinfo... 5 Rom... 5 EKG

Detaljer

Look what I say. Imagetalk Symbol Writer Håndbok. Norsk. Håndbok Side 1

Look what I say. Imagetalk Symbol Writer Håndbok. Norsk. Håndbok Side 1 Look what I say Imagetalk Symbol Writer Håndbok Norsk Håndbok Side 1 Håndbok for Imagetalk Symbol Writer Innhold Hva er Imagetalk Symbol Writer?... side 3 Hvordan denne håndboken skal brukes... 3 Funksjonaliteten

Detaljer

Steinkjer, 13. april 2016

Steinkjer, 13. april 2016 Hanne Almås Steinkjer, 13. april 2016 Hei. Ipad til S. har kommet!! Hva gjør vi videre, rent konkret? Bruk av nettbrett/ipad Kan være et godt pedagogisk hjelpemiddel Mange kjenner til og kan bruke nettbrett

Detaljer

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009 Nettside, Webshop og Beregningsmodell Hovedprosjekt våren [Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document

Detaljer

Et forsøk på definisjon. Eksempel 1

Et forsøk på definisjon. Eksempel 1 Et forsøk på definisjon [Kurssidene] [ ABI - fagsider bibin ] Michael Preminger (michael.preminger@hioa.no) 19/08-15 Engelsklignende språk, med rigid syntaks, som kan brukes til å skrive instruksjoner

Detaljer

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

Detaljer