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

Transkript

1 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT PROSJEKT NR. TILGJENGELIGHET Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL EEGBliss DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE INTERN VEILEDER Thor Hasle OPPDRAGSGIVER Larsen Development AS KONTAKTPERSON Sigve Larsen SAMMENDRAG 3 STIKKORD Hjelpemiddel EEG Bliss 1

2 2

3 SAMMENDRAG Et open source prosjekt som kombinerer Blissymbolics og hjernestyring. Jan Ole Lysen Andersen, Tobias Andersen, Nina Bauge, Raymond Wilhelmsen Holthe og Emilie Thomassen EEGBLISS Hovedprosjekt Anvendt Datateknologi, HiOA

4 4

5 FORORD Denne bacheloroppgaven konkluderer vårt arbeid med å bygge opp grunnmuren for EEGBliss systemet. Vi har gjennom flere iterasjoner med brukertesting, forskning og programmering av prototyper kommet fram til et brukergrensesnitt, en systemarkitektur og et konsept som åpner opp en ny form for Menneske- Maskin Interaksjon for sluttbrukerne. Rapporten tar for seg prosessen med å utvikle denne løsningen, hvilke resultater vi har fått og tilbakemeldingene fra de mange interesseorganisasjonene vi har vært i kontakt med underveis. Denne hovedprosjektrapporten konkluderer et bachelorprosjekt ved Anvendt Datateknologi på HiOA, avgangskullet Rapporten er skrevet for veileder og sensorer ved HiOA, Interessenter i prosjektet og Oppdragsgiver. Hovedprosjektrapporten omfatter omtale av rapporter og dokumentasjon på aktiviteter fra forprosjektperioden og prosjektperioden. Rapporten belyser utgangspunkt for prosjektet og hvilke vurderinger som er gjort underveis. Vi har redegjort for hvilken status prosjektet har per i dag og hvordan vi har tilrettelagt for at det kan videreføres etter denne prosjektperioden. Problemstillingen bak prosjektet ble utviklet sommeren 2013, og vi valgte å jobbe videre med den som hovedprosjekt etter oppfordring fra forelesere og Daniel Scheidegger i NAV Tilde. Vi har fått med oss en erfaren utvikler i vår veileder Thor Hasle og vår oppdragsgiver Sigve Larsen. Vi vil takke dem begge for all støtte i prosjektet. Vi vil også takke Torhild Kausrud i StatPed, Daniel Scheidegger i Nav Tilde, Klaus Miesenberger og Gunnar Michelsen for alle innspill underveis. 5

6 6

7 Innhold Forord... 5 Sammendrag Innledning Problemstilling Mål og avgrensninger Bakgrunn for prosjektet Erkjennelse og sondering Strategianalyse Faglige forutsetninger Om utviklingsprosessen Kravspesifikasjonen og dens rolle Metode Brukerinvolvering Prosjektstyring Analyse Utvikling Prosjektstyring Resultater Brukerinvolvering Utvikling Resultater fra testing av GUI Prosjektstyring Diskusjon Visjon Konklusjon Problemstilling Mål Testrapport Prosessrapport Kommentert kildekode Kravspec Personas Behovsanalyse Papirprototype

8 Wireframe Produktdokumentasjon Erling Open Source utvikling Dagbok Gantt YRC... 2 Siterte verk

9 9

10 EEGBliss En Interaksjonsløsning med Blissymbols og EEG Tobias Andersen, Nina Bauge, Jan Ole Lysen Andersen, Emilie Thomassen og Raymond Holthe Hovedprosjekt Anvendt Datateknologi ved HiOA, Vår 2014 SAMMENDRAG Vi har presentert målgruppens behov og dokumentert at hjelpemiddelindustrien ikke har produkter som kan hjelpe dem per i dag. Vi har introdusert markedet for en løsning som kombinerer bruk av EEG og Ideografiske symboler og sannsynliggjort at dette er en ny retning innen hjelpemiddelutvikling. Vi har presentert testresultater som viser at teorien bak løsningen er gjennomførbar og redegjort for hva vi mener må til for å videreutvikle konseptet til beste for målgruppen; kvantitativ kartlegging av brukererfaringer i etisk forsvarlige rammer. Økonomisk og strategisk forpliktelse i organisasjoner som bistår målgruppen. Vi har argumentert for at vi har grunn til å forvente bidrag fra en internasjonal folkebevegelse av programmerere med insentiver til å skape allsidige interaksjonsverktøy med åpen kildekode. INNLEDNING Denne rapporten er organisert i åtte kapitler. I Innledningen vil vi deretter presentere Problemstilling, Mål og avgrensninger. I kapittelet Bakgrunnen for prosjektet vil vi gå gjennom hva som motiverte disse ambisjonene og kickstartet prosjektet, sammen med en redegjørelse for state of the art for de involverte teknologiene. I Metoder vil vi introdusere våre fremgangsmåter og hvordan de henger sammen med målsetningene. Der presenterer vi også vår prosjektorganisering og hvordan vi har kvalitetssikret prosjektet. I Analyse vil vi gjøre rede for hvilket materiale vi har tilgjengelig for å analysere. I Resultater presenterer vi resultatene vi har oppnådd. I Diskusjon drøfter vi hva som gjenstår, hvilke tråder som ikke er tatt tak i og hva som eventuelt kan gjenstå for å oppnå våre mål. I Konklusjonen vil vi redegjøre for hva vi har oppnådd og oppsummerer prosjektstatus. Til sist i denne rapporten deler vi Visjonen. Her inviterer vi likesinnede til å finne sin rolle i en spennende utvikling. Deretter følger Referanseliste og vedlegg. For de mest dedikerte leserne har vi lagt ved en stikkordsliste helt bakerst i rapporten, til hjelp for den som går grundigere gjennom materialet. Problemstilling Studiens overordnede problemstilling er; Hvordan utvikler vi et kommunikasjonsverktøy for brukere med uten motorisk funksjonsevne? Denne hovedproblemstillingen er nærmere presisert i tre underproblemstillinger, som utforskes i oppgavens tre analysedeler, for henholdsvis Brukerinvolvering og Projekstyring. Hvordan utvikle for vår målgruppe? Hvordan utvikle en integrasjonsløsning som binder sammen funksjonalitet fra eksisterende programvare? Hvordan tilrettelegge for videre utvikling etter prosjektperiode? 10

11 Mål og avgrensninger I dette avsnittet vil vi presentere mål og avgrensninger. Vi deler målene inn i læringsmål, prosessmål og produktmål og presenterer dem punktvis. Etter at vi har presentert målene kommer vi inn på avgrensninger, der vi forteller kort om hvilke ambisjoner vi har for dette prosjektet og hva vi vil overlate til en eventuell videreutvikling av prosjektet. Mål Læringsmål Lære å skrive Abstract og presentere oss i en akademisk kontekst Programmering i Kivy [1] og Python [2] Prosjektstyring Involvere interessenter og sluttbrukere Prosessmål Tilrettelegge for at oppdragsgiver kan etablere seg som en aktør i hjelpemiddelmarkedet Tilrettelegge for videre utvikling av et produkt gjennom open source Produktmål Kravspec API Funksjonell prototyp Avgrensninger I dette avsnittet vil vi omtale våre avgrensninger for hovedprosjektet, og drøfte ambisjonene. I dette prosjektet har vi reist vår problemstilling for å sette en bestemt målgruppe på dagsordenen. Vi har store ambisjoner; Vi ønsker å gjøre en forskjell. Vi ønsker at vår løsning skal kunne heve livskvaliteten for målgruppen; Vi ønsker at den skal lindre isolasjonen syke og deres familier, sikre de sårbare og realisere restarbeidsevnen til de arbeidsføre. Som vi har blitt gjort veldig klar over; innstillingen er større enn ett enkelt bachelorprosjekt. Derfor er våre ambisjoner begrenset til én viktig prioritering; at vårt arbeid skal kunne bygges videre. I prosessrapporten har vi presentert en inndeling av våre langsiktige ambisjoner, i ni implementajonsfaser. De ni fasene representerer hvilke funksjonaliteter vi ønsker å introdusere til hvilken «avdeling» i organisasjonen, og hvilken rekkefølge vi vil introdusere dem. Der presenterer vi denne modellen. Hovedprosjekt våren 2014 er ment å dekke Fase 1 og Fase 2.0 Vi vil komme mer inn på dette på side 13, i «Om utviklingsprosessen». BAKGRUNN FOR PROSJEKTET Her vil vi presentere det historiske bakteppet for prosjektet, forklare den faglige strategiske forankringen for prosjektet og redegjøre for våre teorier og forutsetninger før prosjektstart. 11

12 Erkjennelse og sondering Erkjennelsen av behovet for vår løsning oppsto tilfeldig sommeren 2013, som reaksjon på en rekke omstendigheter som inntraff samtidig. Prosjektgruppen jobbet med et prosjekt som kombinerte Facebook-chat og Blissymbolics [3]-symboler, der vi lærte noe om hvor viktig kommunikasjon er for menneskers livskvalitet. Gruppemedlemmene bevitnet den sjokkerende utviklingen til en ALS-rammet familiefar i sin beste alder, gjennom vår utvidede familie. Prosjektgruppen reagerte på hvordan hjelpemidler kommer til kort i møte med disse utfordringene [4] [5]. Prosjektgruppen dyrket TED Talks som sommerunderholdning [5]. Et par av gruppemedlemmene fikk tak i Nekomimi [6] Neurowear-leketøy på ferie. Illustrasjon 1 MRI-scan Utover sensommeren begynte prosjektgruppen å leke med ideer for å kombinere teknologien bak Nekomimi Neurowear med Bliss-chatten som et hjelpemiddel for ALS-pasienter. Da oppdaget vi Emotivpresentasjonen på TED. Med dette utgangspunktet begynte vi å sondere for å avdekke om en integrasjonsløsning kan bære med seg det potensialet vi håpet på. Underveis i denne prosessen ble vi gjort oppmerksomme på et viktig strategisk poeng; Vi så presentasjonen Could future devices read images from our brains? av Mary Lou Jepsen fra 2013 [7], bestemte gruppa seg for å satse på EEG [8, pp ] med Blissymbolics. Grunnen til dette var en studie Mary presenterte som konstanterte at hjerneaktiviteten som oppstår når man ser et bilde, er den samme som når man forsøker å forestille seg bildet i hodet [9]. Se Illustrasjon 1. Gruppa ønsket ut ifra denne studien å utvikle programvare som kombinerer EEG-headsettet fra Emotiv med symbolspråket Blissymbolics. Som et siste ledd i sonderingsfasen fikk vi hjelp av Sigve Larsen i utviklingsselskapet Larsen Development med å kartlegge hva slags teknisk kompetanse man trenger for utvikling av en potensiell applikasjon. I en samtale med gjesteforeleser Daniel Scheidegger fra NAV Sikte [10] i en gjesteforelesning ble det foreslått at vi så nærmere på disse mulighetene som et hovedprosjekt våren Strategianalyse Vi har analysert de strategiske forutsetningene for prosjektet sammen med oppdragsgiver. Vi ser for oss at teknologien vi ønsker å utvikle foreløpig er ung, men at den er på vei inn i markedet. Vi anser EEGkontroll som en utappet kilde for integrasjonsdesignere med nye uutforskede utfordringer. Vi mener teknologien har et stort potensiale som kommer til å få større betydning de neste årene. Vi ser for oss at vi kan bygge et solid faglig nettverk. Vi anser Open Source-utvikling som en bæredykttig ramme for utvikling, der produktet er gratis for brukere, og monetær verdiskapning kan skje gjennom SLA-avtaler med distributører, som Hjelpemiddelsentralen og interesseorganisasjoner. 12

13 Faglige forutsetninger I denne delen skal vi redegjøre for hvilke teorier og forutsetninger vi bygde på. Vi vil redegjøre for vår kompetanse fra utdannelsen og hva vi har måttet lære underveis og hvor vi har brukt kompetanse fra annen utdanning. I dette prosjektet har vi i all hovedsak foretatt våre vurderinger på grunnlag av pensumet gjennom tre år på Anvendt Datateknologi. Vi har valgt metoder fra fagene Prototyping, IT i praksis, IT-tjenester, Systemutvikling, Menneske- og Maskininteraksjon, Informasjonsarkitektur, Visualisering og Universell utforming. To av gruppemedlemene valgte å lære Python og Kivy underveis i prosjektet. Begge har tatt Programmering og Programutvikling som valgfag og har noe bakgrunn fra Java. Ingen av gruppemedlemmene har bakgrunn fra omsorgsyrker eller medisinsk bakgrunn. Der vi har hatt behov for å analysere brukeres behov på grunnlag av medisinske tilstander har vi utført research. Vi kan ikke ta ansvar for forskningsmetodene på dette feltet, annet enn å redegjøre for våre kilder og våre konklusjoner. Om utviklingsprosessen I denne delen vil vi begynne med å redegjøre for vår problemformulering, hvordan vi tenkte i starten om prosjektet og hvordan dette har utviklet seg. Vi vil vise faser, problemer og løsninger. Vi vil også forklare hvilke utviklingsfaser prosjektet har hatt og hvordan vi har reflektert over de faglige utfordringene. Vi vil redegjøre for hvilke valg vi har gjort om oppbygging og funksjon i programmet. Vi vil redgjøre for utfordringer i prosessen og samarbeidet med oppdragsgiver. Faser Denne utviklingsprosessen har, i organisasjonssammenheng, omfattet Strategi- og modningsprosessen og Valgfasen. Kravspesifikasjonen og dens rolle I de følgende avsnittene vil vi redegjøre for rollen Kravspesifikasjonen hadde i utviklingen av løsningen i vårt prosjekt. Vi vil redegjøre for hvordan den har blitt laget og hvordan den har blitt en del av kvalitetssikringen. Kravspesifikasjonen er også presentert på side 27 i Prosessrapporten, og lagt til som et eget vedlegg, se Kravspec_ Kravspesifikasjonen ble utarbeidet i Valgfasen, som en del av den research som har blitt utført her. Den ble utarbeidet på bakgrunn av Behovsanalyse og faglige prinsipper fra Prototyping, IT i praksis, ITtjenester, Systemutvikling, Menneske- og Maskininteraksjon, Informasjonsarkitektur, Visualisering og Universell utforming. Kravspesifikasjonen ble utarbeidet parallelt med utviklingen. Når vi har blitt kjent med nye krav og ønsker til funksjonalitet har vi lagt det inn i Kravspesifikasjonen fortløpende. Vi kan vanskelig påstå at løsningen vår er et produkt av kravene. I vårt arbeid kan vi like gjerne hevde at kravene er et produkt av de erfaringer som er gjort gjennom innledende designfaser. Kravene har derimot blitt brukt og referert til i vår Evalueringsmodell, side 27 i Prosessrapporten. Denne Evalueringsmodellen ble brukt og rapporter på side 28-33, samme dokument. 13

14 Kravspesifikasjonen inneholder krav som er svært spesifikt utarbeidet for målgruppen. METODE I dette kapittelet vil vi vise hvilke metoder vi har benyttet for å besvare problemstillingen og nå våre mål. Vi vil vise hvordan vi planla og hvordan planleggingen fungerte i prosessen. Vi vil redegjøre for hvilke verktøy som ble brukt, til hva og hvorfor. Vi vil forklare hva vi måtte lære, hvordan vi arbeidet og hvordan vi jobbet med oppdragsgiver og andre aktører. Vi vil også redegjøre for hvordan prosjektet ble organisert. Vi vil begynne med å vise til metoder for research til bakgrunnen for prosjektet, der vi kommer inn på kildekritikk. Deretter omtaler vi metoder brukt for utvikling. Til slutt omtaler vi organisering av prosjektet. Brukerinvolvering Behovsanalyse En omfattende Behovsanalyse er et godt utgangspunkt for ethvert utviklingsprosjekt. Vi har researchet målgruppen og designet Personas med eklektiske funksjonsbegrensninger. Vi har deretter benyttet Scenarioer i form av Use-Cases [11, pp ] til å utvikle brukerkrav [12, p. 59]. Utvikling Vi har utviklet løsningen vår med utgangspunkt i en smidig utvikling [13]. Løsningen har blitt stilt til prøve ved testing av fire prototyper. Papirprototype, Wireframe, Konseptprototype og «Proof of concept [11]» prototype.vi har benyttet akseptansetesting [12, pp. 61, ,318,343], Wizard of Oz-testing [8, p. 297] og komponenttesting [13] [14, p. 9]. All testing ble dokumentert med videoopptak. Vi ivaretok testpersonenes personvern med samtykkeskjemaer [15, pp. 98,609,740]. GUI-metoder Vi har hatt idémyldinger med skisser av skjermbilder og GUI-komponenter. Vi har foredlet løsningene med storyboards av Scenarioer og use-case. Vi har dokumentert oppbygningen av informasjonsarkitekturen med blueprint av GUI. Papirprotptype Vi i har laget en Low Fidelity, revolusjonær, bruk-og-kast, papir prototype [16] [17] med horisontal utforming [8, p. 283]. Komponentene til Papirprototypen er skissert for hånd på papir, på en datamaskin, og med ulike papirmaler som er printet og klippet ut. Samtlige av teknikkene er masseprodusert for å kunne benyttes i flere av versjonene på et tidlig- og senere stadium i løpet av testene. Dette er gjort ved å produsere et grovt overskudd av komponenter og holde dem tilgjengelige i plukkebakker. Samtlige metoder er gode kost- og tidsbesparende teknikker for idébidrag til grensesnitt. Wireframe Wireframeing [8, pp ] er en metode som ofte blir brukt innenfor webdesign [18], men er også like verdifull innenfor applikasjonsutvikling. En Wireframe betraktes som en teknisk tegning [8, p. 267] for å visualisere hvordan elementene i de forskjellige skjermbildene vil se ut i det ferdige grensesnittet. Den inneholder ikke design, men fokuserer på dimensjonering, utforming og plassering. Mange velger å bruke enkle grå bokser for å unngå visuelle distraksjoner. 14

15 Programmeringsmetoder For å teste systemdesignet, benyttet vi en «proof of concept» prototype [11]. Denne prototypen er ikke et fullverdig produkt, men skal brukes for å verifisere at systemdesignet vårt vil fungere i praksis. 1 Denne ble programmert i Python [2] med rammeverket Kivy [1], som var et krav fra oppdragsgiver. Kivy ble valgt fordi Kivy har den fordelen at programmer kan kodes én gang og deretter distribueres på Windows [19], Mac [20], Linux [21], Android [22], ios [23] og Raspberry Pi [24], for å nevne noen. Å lage programmer med Kivy sitt rammeverk vil dermed kunne gjøre distribusjon på flere plattformer enklere enn med andre rammeverk. 2 Vi måtte implementere bibliotekene til Emotiv SDK i systemdesignet vårt for å kunne benytte EPOC EEG headsettet fra Emotiv [25]. Emotiv sitt SDK [26] er offisielt sett ikke er laget for programmering med Python [27], vi måtte derfor finne en løsning på dette. Vi lærte oss å programmere i både Python og Kivy. Det å lære seg Kivy var spesielt utfordrende, siden dette er et helt nytt rammeverk (første stabile versjon kom 30 Januar 2014 [28]) med lite dokumentasjon. 3 Ingen i gruppa hadde noen forkunnskaper om Python, Kivy eller Emotiv SDK. Vi har programmert i Eclipse [29] og Sublime Text 2 [30]. Prosjektstyring I denne delen vil vi redegjøre for metoder som er benyttet for å organisere aktiviteter i prosjektperioden. Vi vil redegjøre for kildekritikk, risikoplanlegging og organisasjonsbygging. Kildekritikk Her har vi benyttet oss av pensumbøker, artikler fra artikkeldatabaser og nettsidene til interesseorganisasjoner. Når vi har benyttet oss av artikler har vi vært nøye med å påse at artikkelforfatterne skal referere til artikler forfattet av forskere innen relevante felt, helst ved andre institusjoner enn deres egen, utgitt av anerkjente institusjoner og at de ikke skal henvise til egne, tidligere arbeider. Vi har benyttet interesseorganisasjoners nettsteder for å få innsikt i hvilke hjelpemidler som brukes av målgruppen i dag. 4 Research har blitt dokumentert som kildehenvisninger. Vi har benyttet kilder fra faglitteratur, artikler fra høgskolens databaser og diverse eksterne nettsider fra relevant organisasjoner. Vi har researchet utfordringer underveis i programmeringen ved å oppsøke videobloggere, dokumentasjon på programmeringsspråket og utviklerblogger. Underveis har vi også oppsøkt kontekstrelevante løsninger på chatlogger og forum. Prosjektstyring Vi har benyttet et rammeverk for å dokumentere utvikling og implementering av bransjestandard utformet av Bo Hjorth Christensen [31]. All testing er dokumentert i rapporter utformet i IEEE-standard [32]. Vi har også benyttet en modell for organisering av alle interessenter og aktører, se Illustrasjon 1 [33, p. 12]. 1 Jamfør våre avgrensninger for prosjektet. 2 Omfordele disse opplysningene hvs vi får tid 3 Bør egentlig flyttes til resultater 4 Se situasjonsanalyse, vedlegg prosessrapport 15

16 Illustrasjon 2 Aktører og interessenter Vi har operert med en organisasjon sammensatt av en rekke aktører og interessenter. De er redegjort for i vedlegg. Organisasjonen omfatter representanter fra BCI [3], StatPed [34], ICCHP [35], Isaac Norge [36], Mesh Norway [37] og NAV Sikte [10]. Vi har foretatt en risikoanalyse som omfatter organisatoriske og finansielle forhold, samt våre ambisjoner og avgrensninger. Med utgangspunkt i denne risikoanalysen har vi jobbet målrettet med å forebygge risikofaktorer, blant annet ved å etablere eierskap til prosjektet i alle ledd i organisasjonen. Vi har hatt en underskrevet samarbeidsavtale med oppdragsgiver og en intern samarbeidsavtale i prosjektgruppen. Prosjektgruppen har også vært organisert med individuelle ansvarsområder, og har vært organisert i to fraksjoner med hvert sitt hovedansvar. 5 Vi har søkt å komme i kontakt med målgruppen, utføre brukerundersøkelser og kvalitetssikre gjennom å bygge et faglig nettverk og få tilbakemeldinger på arbeid underveis. Vi har levert to Abstracts til ICCHP, henholdsvis til SS12-Competition [38] og Young Researchers Consortium [39]. Vi deltok med en stand på Isaac Norges messe på Hovseter 8. april. Vi har vært i kontakt Prosjektleder (Prosjekteier) Tobias med utviklermiljøet Mesh Norway og fått noe veiledning i å profilere oss mot eventuelle samarbeidspartnere. Oppdragsgiver GUI-del Emilie Jallis Raymond Illustrasjon 3 Gruppeorganisering Programmeringsdel Nina Tobias ANALYSE Her følger en oversikt over alt materiale vi har lagt til analyse mot konklusjonen av prosjektet. Materialet omfatter rapporter vi har produsert gjennom aktiviteter underveis; Sammendrag av vår research, utvikling og tilrettelegging. Dette materialet er tilgjengelig i rapporten som vedlegg. Analysene er organisert i tre hovedkategorier; Brukerinvolvering, Utvikling og Styringsdokumenter. Dette materialet vil vi bruke til å redegjøre for den nåværende posisjonen til prosjektet, overlevere dokumentasjon til oppdragsgiver og 5 Referer til vedlegg Prosessrapport, Organisering av prosjektet. 16

17 vurdere kvaliteten av vårt eget arbeid. Fra dette materialet kan vi også konkludere ved hvorvidt metodene har egnet seg for å nå våre mål. Brukerinvolvering For å vurdere vår grad av Brukerinvolvering vil vi analysere materiale som stammer fra vår research og brukerkontakt. Dette materialet omfatter Personas, Behovsanalyse og Kravspesifikasjon. Gjennom disse dokumentene kan vi formidle vår forståelse av målgruppene. Materialet bør analyseres samlet, med utgangspunkt i om målgruppen er tilstrekkelig involvert; Har vi lykkes med å ha en brukerstyrt utvikling? Er det sannsynlig at målgruppen har fått satt sitt preg på utviklingsprosessen? Dette arbeidet er ikke så lett å analysere med et kvanitifiserbart resultat. Derimot vil vi kunne reflektere over brukerinvolveringen i kapittelet Diskusjon. Utvikling Beskrivelser av prototypene, Testdokumentasjon og Kildekode. Materialet fra utviklingen bør derimot analyseres med tanke på å dokumentere den tekniske løsningen; Hvordan er den bygget opp og hvordan kan en programmerer bruke den videre? Hvilke krav er oppfylt og hvilke må jobbes mer med? Fra disse dokumentene vil vi legge frem en hel del resultater. Fra beskrivelsene av prototypene vil vi presenter løsningsforslaget vårt gjennom de modeller og beskrivelser vi har produsert i materialet. Fra Testdokumentasjonen vil vi legge frem testresultater. Kildekoden vil bli analysert med tanke på hvor tilrettelagt den er for videre utvikling. Prosjektstyring Til sist vil vi redegjøre for styringsdokumenter og kvalitetssikring av prosessen; Prosessrapport, Dagbok og tilbakemeldinger fra henholdsvis ICCHP og Erling Andersen. Styringsdokumenter analyseres for å vurdere prosjektets levedyktighet og prosjektgruppens gjennomføringsevne. Prosessrapporten inneholder materiale og notater fra prosjektstart, gjennom aktiviteter, research og redegjørelser for strategiske valg. Dagboken redegjør noe for hva som ble gjort når. Fra prosessrapporten og Dagboken vil vi analysere risikohåndteringen i prosjektet. Blant annet vil vi kunne analysere hvorvidt planlegging ble fulgt opp og om tidsrammene holdt. ICCHP har stilt et panel på ti kvalifiserte fagpersoner til å vurdere innsendte Abstract opp mot en rekke kriterier, henholdsvis Scientific Quality, Relevance to Conference, State of the Art, Originality/Novelty, Readability and Organisation of the Paper, User Involvement and User Centred Approach samt Impact and Importance for the Field. Vi vil presentere hvilken score vi fikk fra deres vurdering og reflektere over prosjektets faglige levedyktighet. Det blir også naturlig å reflektere over en epost vi fikk fra en kontakt i Mesh Norway. Underveis i prosjektet var vi i kontakt med mer tradisjonelle utviklingsmiljøer og næringslivet. Vi ble oppfordret til å presentere oss for eventuelle samarbeidspartnere med en PowerPoint-presentasjon. Fra tilbakemeldingene på denne vil vi vurdere prosjektets modenhet for markedsføring. 17

18 RESULTATER I dette kapittelet vil vi samle viktige punkter fra vedleggene for å gi et kort og godt bilde av utviklingen vi har gjennomgått. Vi tar utgangspunkt i dokumentene som er nevnt i Analysen. Brukerinvolvering Resultatet av brukerinvolveringen. Vi har produsert et forslag til brukergrensesnittet og funksjonalitet i henhold til våre faglige vurderinger. Disse vurderingene er gjort med utgangspunkt i vår research om målgruppen, se Vedlegg 002 Prosessrapport, side 12. Fremgangsmåter for design Koble designprosessen med konseptuelle idé Utgangspunkter for å Analysere og beskrive et design Relevante metoder for å prototype Metoder for å dokumentere resultatene Metoder vi brukte Use-Case Idémyldring Skisse Storyboards Designprinsipper Visjon Personas Scenarioer Organisering Layout Posisjon Universell tilgjengelighet Papirprototype Wireframe Aktivitetsdiagrammer Blueprint Kravspesifikasjon Prosessdokumentasjon Metoder vi ikke brukte QOC Tabell 1 Designmetoder Gruppering Labeling Metaforer Rikt bilde Utvikling GUI, beskrivelse I arbeidet med brukergrensesnittet har vi identifisert tilsammen 25 relevante metoder fra pensum. Av disse har vi benyttet 18 metoder i utviklingen. I Feil! Fant ikke referansekilden. gir vi en kort oversikt over hvilke metoder vi har brukt, og hvilke vi ikke har brukt. De metodene vi ikke har benyttet, har sentrert rundt beskrivelse, analyse og kritiske vurderinger av løsninger. Prioriteringen er tydelig; Vi har prioritert en uavbrutt fremmarsj i utviklingen mot en «God nok» og «Brukbar» løsning. I denne settingen ser vi at redegjørelse for designprinsipper og tilgjengelighet er prioritert. Illustrasjon 4 Blueprint, fra Vedlegg _008 På den annen side har vi helt tydelig benyttet et rikt utvalg av metoder for kommunikasjon av ideer og dokumentasjon; Vi har produsert 14 scenarioer, 13 aktivitetsdiagrammer og 1 blueprint over informasjonsarkitekturen. Vi har produsert tilsammen 36 krav til kravspesifikasjonen, parallelt med denne utviklingen. Gjennom kapittelet vil vi gjengi noen av disse, med henvisninger til de ulike delene av rapporten, for å gi et godt bilde av bredden i utviklingen. 18

19 Illustrasjon 5 Global meny Gjennom utviklingen i prosjektet har vi både evaluert, valgt ut og programmert egne komponenter. Noen av tankene vi har gjort oss underveis kan beskrives med de følgende; Illustrasjon 7, Illustrasjon 4, Feil! Fant ikke referansekilden.. Konsept-beskrivelse Konseptet er bygget som en integrasjonsløsning, av komponenter fra ulike systemer som vanligvis ikke blir brukt sammen. Se gjerne Feil! Fant ikke referansekilden. Resultater av konseptprototype-test Testen ga oss 16 av 20 korrekte svar fordelt på de to testpersonene i målgruppen vi testet på. Dette tilsvarer 80% korrekte besvarelser, med bare 5 innlesninger for hver testperson av Blissymbolene for Ja, og 5 innlesninger for Nei. Illustrasjon 7 Modell, fra Vedlegg _004Kravspesifikasjonen Illustrasjon 6 Arkitektur, Vedlegg _004Kravspesifikasjonen 19

20 Resultater fra testing av GUI Resultatene er basert på analyser av adferd og muntlige tilbakemeldinger fra testpersonene. Resultater Papirprototype-test: Vi fikk ingen positive tilbakemeldinger under testene av papirprototypen. Fokuset hos testpersonene lå på det de var ufornøyde med. Alle testpersonene hadde forskjellige problemer, men noen pekte seg ut spesielt. 3 av 4 testpersoner stoppet opp i den samme oppgaven. Etter oppgavene Brukeroppretting og Innlogging, som ikke bød på stor motgang, var det hovedsakelig funksjonene under symboltreningen alle testpersonene hadde vanskeligheter med å forstå konseptet bak. Det var uklart hva knappene gjorde før testpersonene hadde testet dem ut og testpersonene nølte med å gå videre. Det ble klaget på ulogisk tegnbruk og treig navigasjon. Manglende feedback gjorde det også forvirrende å vite hvilke symboler som var valgt, trent og ikke trent for testpersonene. Indikasjon for start av symboltreningen ble etterspurt. Logg ut knappenble testet av to personer uten at de ble bedt om det på forhånd. Vi fikk forslag til forbedringer fra alle testpersonene etter at deres økt var over. Resultater wireframeprototype-test: Det var generelt bedre stemning under wireframe-testene sammeliknet med den forrige testen. Det kom en klage på plasseringen av hjelpeteksten nederst på sidene slik at den ikke ble oppdaget med en gang. Tespersonene leste hjelpetekster når de ble forvirret. Hjelpeteksten hjalp.en testperson klaget over to museklikk for mye under testing av inntrent symbol og ville heller ha mulighet for å teste direkte på ferdig-menyen. To knapper kunne oppfattes tvetydig. Vi fikk tilbakemelding om forvirrende gruppering. En testperson savnet tydeligere feedback på task. Det var tre tilfeller av uviktige feil basert på glemsomhet under utformingen av wireframen, hvor det som var mest alvorlig var at alt var skrevet i comic sans. Dette vil ha første prioritet hos neste versjon av wireframen. Det var muligheter for alternative ruter under noen av scenarioene. De fleste testpersonene tok som regel den korteste veien.hjelpefunksjonen som var tilgjengelig ble ikke enset av noen av testpersonene. Alle testpersonene hadde positive tilbakemeldinger. Funksjonaliteten var lett å gjette seg fram til og veide opp for manglende hjelpetekst. Det vakte mye ros for et intuitivt, kjent og simplistisk design som ble godt likt. Knappene var godt forklarende, med kun et par steder hvor tvetydighet oppstod. Statistikk mellom papir og wireframe: Gjennomgang av alle scenarioer på papirprototyp 20min i gjennomsnitt gjennomgang av alle scenarioer på wireframe 10min i gjennomsnitt. Wireframe ikke avhengig av manuell bytting av skjermbilder, men mer enn dobbelt så mange scenarioer. Inntrykk av at wireframe testene gikk mye raskere til tross for forskjellig hastighet for selve mediumet. 20