Denne siden er blank med hensikt.

Transkript

1

2 1 Denne siden er blank med hensikt.

3 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR TILGJENGELIGHET Offentlig BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Dagsplanapplikasjon for nettbrett DATO ANTALL SIDER 130 PROSJEKTDELTAKERE Kristoffer Hagen Steffen Engebretsen Harald Sletten Adamsen David Meisund INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Oslo Universitetssykehus Avdeling for nevrohabilitering. KONTAKTPERSON Morten Berger Vidar Antonsen SAMMENDRAG Prosjektet går ut på å lage en dagsplanapplikasjon for Androidbaserte nettbrett som viser ukens og dagens gjøremål. Applikasjonen er rettet mot brukere med kognitive funksjonsnedsettelser, der gjøremålene kan settes opp av bistandsytere, og foresatte. Dette skal gjøres i en administrasjonsdel hvor det også skal være mulig å tilpasse funksjoner for personalisering. Målet er at applikasjonen skal bidra til økt selvstendighet blant brukere, og på den måten forenkle hverdagen til både brukerne og bistandsytere på institusjoner. For å løse dette har vi gjennom prosessen arbeidet med informasjonsinnhenting, prototyping, brukertesting og implementering. 3 STIKKORD Universell utforming Android-applikasjon Brukermedvirkning 2

4 3 Denne siden er blank med hensikt.

5 1 Forord Denne rapporten beskriver arbeidsprosessen med vårt hovedprosjekt, fra planlegging til sluttprodukt. Rapporten er optimalisert for å leses elektronisk. Vår veileder Kirsten Ribu inkluderte oss i et samarbeidsprosjekt med Avdeling for nevrohabilitering ved Oslo universitetssykehus (OUS). Hensikten med dette prosjektet har vært å bidra til at brukere på institusjoner skal få en bedre hverdag ved hjelp av økt selvstendighet. Vi vil takke vår veileder Kirsten Ribu på Høgskolen i Oslo og Akershus (HiOA) som har fulgt oss opp hele veien. Med sitt positive vesen, gode tilbakemeldinger og tips til forbedringer, har hun vært en god støtte i prosessen. Hun har også skaffet oss tiltrengt utstyr og ordnet opp når vi har trengt hjelp. Vidar Antonsen og Morten Berger har vært våre kontaktpersoner og samarbeidspartnere hos oppdragsgiver. De har vært veldige positive til vårt arbeid og hjulpet oss med alt fra lån av utstyr til å skaffe testpersoner til brukertesting. Deres faglige kompetanse og tilbakemeldinger har hjulpet oss på veien mot et bedre sluttprodukt. De skal derfor ha en stor takk. Vi vil også takke brukertestere som villig stilte opp. Til slutt vil vi takke HiOA for å gitt oss mulighet til å dra på velferdsteknologikonferansen CareWare i Aarhus. 4

6 5 Denne siden er blank med hensikt.

7 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Innledning Bakgrunn Mål og rammebetingelser Kravspesifikasjon Samsvar med kravspesifikasjonen Funksjonelle krav Endelig kravspesifikasjon Systemkrav Krav til grensesnitt Generelle designkrav Brukervennlighet Dokumentasjonskrav Løsninger på markedet dag MemoAssist careplan (e-mergency) Pictoplan Produktbeskrivelse Brukerdel Ukesmodus Dagsmodus Handlingskjede Sjekkliste Bistand via Skype Navigasjonsfelt Sveip Fargekoder Kontekstmeny for handlingskjeder Nedteller Tilleggsfunksjoner for brukeren Administrasjonsdel

8 7.4.1 Opprettelse av førstegangsbruker Hovedside Endre plan Endre eller slette aktivitet Innstillinger Brukere Kommunikasjon med brukeren Meldinger som krever interaksjon Meldinger som ikke krever interaksjon Meldinger som er informasjon Brukertest og intervju Personvern Generelt om brukertester Generelt om våre intervjuer Brukertest av prototype på OUS-ansatte Gjennomføring og resultat Konklusjon Brukertest ikoner Gjennomføring og resultater Konklusjon Brukertest brukerdelen Gjennomføring og resultater Intervju Konklusjon Brukertest med 5-åring Brukertest admindelen Gjennomføring og resultater Konklusjon Endringer som følge av brukertest Brukertest av prototype - brukerdel Brukertest av ikoner Brukertest av brukerdel Brukertest av administrasjonsdel Utviklingsprossen Smidig utviklingsmetodikk Utviklingsverktøy

9 9.2.1 Android Studio Redmine Git Draw.io DB Browser for SQLite Google Dokumenter Dropbox Adobe Creative Cloud Microsoft Powerpoint Prosjektdagbok Fra skisse til ferdig løsning Idémyldring Utviklingsprosess for ukesmodus Utviklingsprosess for dagsmodus Utviklingsprosess for administrasjonsmodus Utvikling av logo CareWare Universell utforming og interaksjon WCAG Brukervennlighet Tilbydelser Tilbakemeldinger Metaforer Synlighet Sperring av ugyldige handlinger Lyd Visuell kommunikasjon (Design) Gestaltlovene Forgrunn og bakgrunn Nærhet Kontinuitet Form og det gylne snitt Likhet Tilordninger Tekst og lesbarhet Navngivning

10 Farger Kognitiv belastning Minnekapasitet Lese- og skrivevansker Toleranse for feil Organiseringsstruktur Konklusjon Nytteverdi Videre utvikling Vedlikehold av planen Motivasjonssystem Fjernadministrering og monitorering Støtte for flere medier Påminnere/notifications Personalisert design Bekreftelse av fullførte aktiviteter Valg av «pauseaktiviteter» Plasseringstjenester Implementering og brukertesting Teknisk spesifikasjon Teknologi Java XML SQLite Kodeoptimalisering Prosjektstruktur Manifests Programlogikk (java) Adapter for ListView Skype-integrasjon Liste over java-filer Database Databasetabeller Logisk skjema for lagring av aktiviteter Ressurser Drawable

11 Raw Values Systemkrav Tillatelser/permissions Tillatelse til å lagre data Tillatelse til å bruke kameraet Tillatelse til å bruke internett Sikkerhet SQL-injections Krypterte passord Tilgjengelighet (accessibility) Opplesing av tekst og bilder Hint for tekstfelt Navigering med tastatur Testing Velkomstmodus Ukesmodus Dagsmodus Adminmodus Resultater fra testing Referanser Brukerveiledning Brukerdel Navigering Hvordan komme til neste steg i en handlingskjede? Hvordan gå tilbake et steg i en handlingskjede? Hvordan fullføre en delhandling i sjekkliste? Hvordan angre fullføring av delhandling i sjekkliste? Nedteller Hvordan ringe bistandsytere, familie eller venner? Administrasjonsdel Aktiviteter Innstillinger Vedlegg Vedlegg 1: Attest fra oppdragsgiver Vedlegg 2: Risikoplanlegging

12 16.3 Vedlegg 3: Samtykkeskjema for brukertest

13 3 Innledning Vi er fire studenter som går anvendt datateknologi på HiOA. Vår oppgave har vært å utvikle en prototype til en dagsplanapplikasjon for personer med kognitive funksjonsnedsettelser. Den skal være tilpasset Androidbaserte nettbrett og brukes som et utgangspunkt for en ferdig løsning. Applikasjonen skal gi oversikt over dagens og ukens gjøremål, og skal i tillegg hjelpe brukeren med å utføre aktiviteter. Gjøremålene skal kunne settes opp av bistandsytere, foresatte og brukeren selv. For å øke utfordringen og omfanget av oppgaven valgte vi å utvikle en funksjonell applikasjon istedenfor en prototype. Dette tok betydelig lengre tid, men slik vi ser det har erfaringen gjort at det lønner seg. Gruppen hadde ikke tidligere erfaringer med utvikling av applikasjoner eller det helsefaglige aspektet. Vi har derimot god erfaring med universell utforming. Dette gir oss faglig tyngde om viktige aspekter som design, brukergrensesnitt, brukervennlighet og brukertesting. Ved å forene teknologi og velferd fikk vi sjansen til å jobbe med to forskjellige fagområder, noe som har vært svært spennende. Gjennom testing har forskere funnet ut at sosiale applikasjoner på for eksempel nettbrett kan hjelpe brukeren med å lettere utrykke seg og generelt forbedre sin sosiale adferd (Hourcade, Bullock-Rest & Hansen, 2012). Det er derfor svært viktig å utvikle applikasjoner som utnytter dette og øker brukernes selvstendighet. Da vil flere mennesker bli inkludert i samfunnet og få ta del i den teknologiske utviklingen. 12

14 4 Bakgrunn Avdeling for nevrohabilitering ved Oslo universitetssykehus (OUS) har spesialisert kompetanse overfor mennesker med tidlig ervervede hjerneskader, utviklingsforstyrrelser, sammensatte funksjonsvansker, utviklingshemming, epilepsi, autisme og/eller multifunksjonshemming. Avdelingen jobber for å fremme forutsigbarhet, selvstendighet og gi den enkelte brukeren mulighet til å påvirke sine omgivelser. I dag brukes analoge dagsplaner på veggtavler eller i permsystemer, som krever omfattende opplæring og kontinuerlig tilstedeværelse av tjenesteytere. Det er også nødvendig med utstyr for å produsere bilder, tekst eller symboler til bruk i planene. Til sammen utgjør dette et vesentlig ressursbruk for avdelingen. Brukere/pasienter som er hjemmeboende i foreldrehjemmet eller mottar begrensede timebaserte tjenester har i mindre grad struktureringsverktøy. Denne gruppen har ikke kontinuerlig tilgang til bistandsytere. Problemet med verktøyene som finnes i dag er at de er lite sosialt valide og at enhetene er lite tilpasset et familiehjem. I denne brukergruppen finnes det i dag svært liten grad av velferdsteknologi, og det er derfor en stor etterspørsel etter dette. En rekke potensielle brukere har meldt interesse for prosjektet. For å gjøre det lettere å planlegge hverdagen for denne målgruppen har OUS initiert et prosjekt der målet er å ende opp med en universelt utformet dagsplanapplikasjon for nettbrett. Dette skal gi brukeren økt forutsigbarhet og selvstendighet, økt deltakelse i eget liv og mer hensiktsmessig bruk av bistandstid. Nettbrett er valgt fordi det er et mobilt verktøy som har langt høyere sosial validitet enn tradisjonelle dagsplaner på papir eller tavle. Det er meningen at applikasjonen skal kunne administreres av bistandsytere og familiemedlemmer. HiOA og OUS samarbeider for å samle det beste fra habiliteringstjenestens kompetanse og erfaringsgrunnlag med dagens teknologiske muligheter. Dette skal bidra til at avdelingen raskere og mer effektivt kan yte tjenester av høy kvalitet til sin målgruppen. Prosjektet har som mål å ende opp som en universelt utformet applikasjon for Android- og ios-brukere. Flere i vår målgruppe har autisme og andre utviklingsforstyrrelser med lignende symptomer. Autisme er et vidt begrep som representerer alt fra lavtfungerende til høytfungerende mennesker og er en veldig individuell sykdom. Sykdommen kjennetegnes ofte av svekket kommunikasjon, problemer med sosial interaksjon og begrensede interesser. Dette resulterer ofte i konsentrasjonsvansker og vanskeliggjør muligheten til å bygge seg opp et selvstendig liv. I april 2013 utførte forskerne ved Kennedy Krieger Institute en studie på syv unge studenter med autisme (O'Malley, Patricia, Lewis & Donehower, 2013). Forskerne ville finne ut om nettbrett kunne bidra til høyere grad av selvstendighet. Resultatet viste at selvstendigheten til brukerne økte. Dette var et viktig mål for oss, og ved å få en bekreftelse på at det hjelper å bruke nettbrett, er vi sikre på at vi bruker riktig plattform. 13

15 4.1 Mål og rammebetingelser Målgruppen er unge voksne med gjennomgripende utviklingsforstyrrelser og/eller kognitive funksjonsnedsettelser som bor i foreldrehjemmet eller som mottar timebaserte tjenester i egne eller samlokaliserte boliger. Prosjektets overordnede mål er å: Utforme en allment tilgjengelig, individuelt tilpasset applikasjon som kan muliggjøre at målgruppen i større grad kan nyttiggjøre seg av dagens teknologiske muligheter. Utforme og prøve ut en applikasjonsløsning som kan bidra til større grad av forutsigbarhet, selvstendighet og valgmuligheter for målgruppen og på den måten forenkle hverdagen til både brukerne og bistandsytere på institusjoner. Utvikle en dagsplanapplikasjon som på en fullverdig måte kan erstatte dagens analoge struktureringsverktøy for målgruppen. 14

16 5 Kravspesifikasjon Kravspesifikasjonen er en detaljert beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den skal virke som en rettesnor der rammer og retningslinjer blir definert for utviklerne. Kravspesifikasjonen er utarbeidet i samarbeid med oppdragsgiver, og er med på å sikre at begge parter får klarlagt betingelsene for prosjektet. For oss har dette vært et levende dokument gjennom hele arbeidsperioden. 5.1 Samsvar med kravspesifikasjonen I dette kapittelet vil vi ta for oss kravene i kravspesifikasjonen og hvordan sluttproduktet vårt samsvarer med kravene. Ved oppstart av prosjektet fikk vi klare krav fra vår oppdragsgiver. Disse var ment for en prototype. Siden vi utviklet en fungerende applikasjon, var det ikke forventet at alle fastsatte krav skulle gjennomføres. Vi fikk forholdsvis frie tøyler i utviklingsprosessen, og kunne utforme applikasjonen i vår egen retning. Likevel ville oppdragsgiver at de mest essensielle kravene skulle utvikles. Dette har gjort at applikasjonen som er laget ikke har fulgt alle de opprinnelige kravene, og kravspesifikasjonen er derfor revidert underveis Funksjonelle krav Oppdragsgiver krevde at løsningen skulle ha en brukerdel med ukes- og dagsmodus. Det skulle også være en administrasjonsdel med mulighet til legge til, endre og slette aktiviteter. Disse funksjonene er nødvendig for å bruke og administrere dagsplanen. Krav for ukesmodus I ukesmodus var det få, men viktige krav som skulle utføres. Alle gjøremålene for den aktuelle uken måtte vises i en kronologisk oversikt. Aktivitetene skulle beskrives med et bilde eller ikon, og det måtte vises om gjøremålet er fullført eller ikke. I tillegg til de fastsatte kravene har vi gjort det mulig å sette på et navigasjonsfelt med ukenummer. Vi har også implementert en sveipefunksjon. Krav for dagsmodus Oppdragsgiver ønsket at det skulle være mulig å se både bilde og tekst av gjøremålene. Mulighet til å bekrefte aktiviteter og deloppgaver var også et krav. Her har vi i tillegg gjort det mulig å angre fullførte handlinger. Dette valgte vi å prioriterte på brukerdelen siden det er viktig for god brukervennlighet i applikasjonen. Et annet krav oppdragsgiver ønsket var bruk av nedteller. Dette ble implementert fordi vi mente det var nødvendig for å forenkle enkelte aktiviteter. Det skulle også være mulig å velge pauseaktiviteter, utsette eller velge bort aktiviteter og spille av video. Dette har vi ikke laget enda, fordi vi har valgt å prioritere andre funksjoner. Vi har i stedet lagt til funksjoner som bedrer helheten i applikasjonen, for eksempel bistand via Skype. 15

17 Oppdragsgiver ønsket at det skulle være mulig for brukeren å få hjelp til å utføre enkelte aktiviteter, via en sjekkliste eller en handlingskjede. Dette er noe mange i målgruppen vår vil trenge og var derfor viktig for oss å utvikle. Som en ønsket tilleggsfunksjon ville oppdragsgiver at det skulle være mulig for brukeren å be om bistand. Vi valgte å implementere denne funksjonen fordi vi mener det kan gjøre brukeren mer selvstendig. Krav for administrasjonsmodus Det viktigste kravet på administrasjonsdelen var å kunne legge til, endre og slette aktiviteter. Utføres ikke dette, vil brukerdelen være verdiløs og det var derfor det første vi implementerte i administrasjonssiden. Til gjøremålene skulle administrator kunne legge til bilder, beskrivelse, nedteller og sjekkliste eller handlingskjede. For å komme inn på adminmodus var det krav om passordbeskyttet innlogging. Alt dette er lagt til i applikasjonen. Vi har derimot ikke lagt til egen innlogging for ikke-administratorer, der man får en begrenset administratortilgang. Til gjengjeld har vi gitt administratorer store muligheter for å tilpasse applikasjonen individuelt. Dette er gjort ved å legge til muligheter for å skru av og på funksjoner som navigasjonsfelt, fargekoder, kontekstmeny og sveiping. Krav for tilleggsfunksjonalitet I tillegg til kravene hadde oppdragsgiver ønsker om funksjonalitet som skulle implementeres dersom det ble tid til det. Vi valgte å fokusere på brukertesting og optimalisering av grunnstrukturen i brukerdelen, og fikk derfor ikke tid til å implementere så mye av den ønskede tilleggsfunksjonaliteten. Vi valgte å implementere bistand via Skype fordi vi i samarbeid med oppdragsgiver vurderte dette som den viktigste tilleggsfunksjonaliteten. Tekniske krav Alle de tekniske kravene er oppfylt. Applikasjonen er utviklet for Android-enheter og fungerer godt for alle testede enheter med versjon eller nyere. Passord blir lagret kryptert i databasen. Krav til brukergrensesnitt Designkravene går blant annet ut på at kun funksjoner som har nytteverdi for brukeren skal være synlige. Applikasjonen måtte være universelt utformet og navigasjonen enkel og intuitiv. Dette har vi jobbet mye for å sikre, blant annet gjennom skissering. Med tanke på brukervennlighet måtte ikoner være beskrivende for gjøremålet. Språket skulle være norsk bokmål, uten fremmedord og fagspråk. Det skulle være tilstrekkelig å kun ha en liten opplæring på forhånd for å kunne bruke applikasjonen. De fleste av disse kravene er ikke målbare, og det er derfor vanskelig å si med sikkerhet at alt er oppfylt. Gjennom brukertesting og tilbakemeldinger opplevde vi at kravene har blitt fulgt. 16

18 Dokumentasjonskrav Det var ønskelig for oppdragsgiver at applikasjonen ble nøye dokumentert. Siden mye av oppgaven gikk ut på å finne brukernes behov og ideer til løsninger, var det viktig for oppdragsgiver å få tilgang til innsamlet og bearbeidet informasjon. Dokumentasjonskravet er oppfylt fordi designvalg og hva som bør gjøres i den videre utviklingen er beskrevet i sluttrapporten. 5.2 Endelig kravspesifikasjon Dette dokumentet viser vår endelige kravspesifikasjon. Punkter markert i grønt er nye krav som er lagt til, mens punkter markert i gult er krav vi ikke ferdigstilte. Tekst uten eller med grønn markering er fullført Systemkrav Kundens krav til funksjonalitet Applikasjonen skal ha tre ulike sider; ukesmodus, dagsmodus og administrasjonsmodus. Ukesmodus skal vise en oversikt over hvilke aktiviteter som skal gjøres en aktuell uke. Dagsmodus skal i kronologisk rekkefølge liste opp alle aktiviteter som skal gjøres den aktuelle dagen. Administrasjonsmodus skal brukes for å legge til/endre/fjerne aktiviteter fra planen. Under følger en oversikt over hvilke funksjoner hver side må inneholde. Ukesmodus: Vise kronologisk oversikt over alle gjøremål den aktuelle uken. Vise bilde/ikon til hvert gjøremål. Vise tekstlig beskrivelse til hvert gjøremål. Vise om et gjøremål er fullført eller ikke. Mulighet for å navigere mellom dagene via sveip. Mulighet for å navigere mellom dagene via navigasjonsfelt. Dagsmodus: Mulighet til å spille av lydklipp. Mulighet til å se bilder av gjøremålet. Mulighet til å se tekstlig beskrivelse av gjøremålet. Mulighet til å vise nedteller som viser hvor lenge det er igjen til aktiviteten er fullført. Mulighet til å utsette/velge eller velge bort aktivitet. Mulighet til å bekrefte at aktivitet er fullført. Mulighet til å bekrefte at deloppgave er fullført. Mulighet til å avkrefte fullført handling/deloppgave. Mulighet til å velge pauseaktiviteter. Mulighet for å se sjekkliste. Mulighet for å se handlingskjede. 17

19 Mulighet for å vise oversikt over alle gjøremål for den aktuelle dagen. Mulighet for å navigere mellom dagene via sveip. Mulighet for å navigere mellom dagene via navigasjonsfelt. Administrasjonsmodus: Passordbeskyttet innlogging. Mulighet for å registrere ny bruker. Mulighet for å endre brukerinformasjon. Mulighet for å slette bruker. Mulighet for å legge inn/endre/slette gjøremål. Mulighet for å legge til sjekkliste. Mulighet for å legge til handlingskjede. Mulighet for å legge inn/endre/fjerne tekstlig beskrivelse av gjøremål. Mulighet for å se ukeplan. Mulighet for å sette på navigasjonsfelt. Mulighet for å sette på sveip. Mulighet for å sette på kontekstmeny. Mulighet for å sette på navigasjonsfelt. Mulighet for å sette på fargekoder. Mulighet for å legge til og slette deloppgaver i sjekklister. Mulighet for å legge til og slette deloppgaver i handlingskjeder. Mulighet for å laste inn eksempelplan. Mulighet for å slette alle aktiviteter. Mulighet til å velge/fjerne tilhørende bilde til et gjøremål. Mulighet til å ta bilder med kameraet. Egen innlogging for brukeren, der «faste gjøremål» ikke kan endres. Begrenset administratortilgang. Mulighet til å sette på Skype. Mulighet til å sette på nedteller til enkeltaktiviteter. Mulighet til å se informasjon om tilleggsfunksjonalitet. Ønsket tilleggsfunksjonalitet Følgende krav er tilleggsfunksjoner som er ønsket av oppdragsgiver. Disse er ikke regnet som krav, men er funksjonalitet som ønskes implementert dersom det bli nok tid til det: Belønning/motivasjonssystem der man samler poeng ved å utføre oppgaver. Poengene kan brukes til selvvalgte aktiviteter. Synkronisering til smarttelefon der man kan ha oversikt over planen for dagen. Mulighet for innlogging / synkronisering mot server, slik at man ikke mister dagsplanen om man mister nettbrettet. Fjernadministrering/monitorering for bistandsytere. Påminner/timer (også dersom applikasjonen ikke er åpen). Mulighet for å be om bistand gjennom Skype. 18

20 Tekniske krav Applikasjonen skal utvikles i Java, XML og SQLite. Applikasjonen skal utvikles for Android versjon «Jelly Bean». Alle nettbrett med versjon eller høyere skal kunne kjøre applikasjonen. Passord skal lagres kryptert. Krav til koden Koden skal implementeres og struktureres slik at det vil være lett å legge til ny funksjonalitet i fremtiden. Navn på klasser, metoder og variabler skal være selvforklarende. 5.3 Krav til grensesnitt Generelle designkrav Applikasjonen skal være universelt utformet. Bare funksjoner som har nytteverdi for den enkelte brukeren skal være synlig. Navigasjonen skal være enkel og intuitivt. Ikoner skal være beskrivende for gjøremålet Brukervennlighet Språket i applikasjonen skal være norsk bokmål. Språket skal inneholde minst mulig fremmedord og fagspråk. Bruker skal kunne bruke systemet kun ved å ha erfaring med nettbrett samt en avgrenset opplæring. 5.4 Dokumentasjonskrav Gjennom prosjektet skal det utvikles flere dokumenter. All dokumentasjon skal skje jevnlig under hele prosjektperioden. Dokumentasjonen skal følge standarden for hovedprosjekter ved HiOA. Dokumentene skal skrives på norsk bokmål med en formell språkbruk. Ved eventuelle endringer i kravspesifikasjonen skal dette rapporteres til oppdragsgiver, som ønsker å få all sluttdokumentasjon. Sluttdokumentasjonen er spesielt viktig for oppdragsgiver. 19

21 6 Løsninger på markedet dag Det finnes en del lignende løsninger på markedet i dag, men kvaliteten er veldig varierende. Mange av applikasjonene bærer preg av dårlig brukervennlighet og mye støy. Dette kan komme av lite brukertesting eller utviklere som ikke har satt seg ordentlig inn i brukerens ferdighetsnivå og livssituasjon. Det viktigste med velferdsløsninger er at de må være enkle nok til at brukerne ønsker og klarer å bruke de. Dette virker det som mange har glemt. I denne delen vil vi ta for oss tre lignende løsningene som finnes på markedet i dag. Danmark har lenge satset på velferdsteknologi, og alle applikasjonene beskrevet under er derfra. 6.1 MemoAssist MemoAssist har som hensikt å skape struktur i hverdagen for brukerne og er rettet mot mennesker med blant annet ADHD, Alzheimers, demens og andre hjerneskader. Applikasjonen er tilgjengelig for ios-enheter. FIGUR 2: UKESMODUS I MEMOASSIST. FIGUR 1: DAGSMODUS I MEMOASSIST. Fordelen med MemoAssist er at forsiden er behagelig å se på. Det er lite støy og derfor lett å få oversikt over gjøremålene. Applikasjonen har mulighet for lydavspilling for å beskrive gjøremål, noe som kan være en stor fordel for enkelte brukere. Det er enkelt å sette opp aktiviteter og det er mulig å lage både handlingskjeder og sjekklister. 20

22 Man har ikke en separat adminmodus der man kan legge til aktiviteter. Man legger inn aktiviteter direkte fra ukesmodus. Dette kan virke støyende da det gjøres ved pop-up-vinduer som går over hverandre. Til gjengjeld kan man administrere applikasjonen fra en ekstern app som kalles MemoRemote. I figur 3 vises et eksempel på å sette opp en aktivitet. Her har man mulighet til å legge ved bilde, skrive beskrivende tekst, spille av en egendefinert lyd og sette på en nedteller. Alt dette er veldig enkelt å gjøre, noe som er meget bra. Et stort minus er at det ikke er noen lagreknapp, i stedet er det en stor «slett»-knapp som mest sannsynlig vil forvirre mange. For å lagre aktiviteten må man trykke på tilbakeknappen, noe som er en uvanlig fremgangsmåte. FIGUR 3: FIGUR 3: OPPRETTELSE AV AKTIVITET I MEMOASSIST. Vår oppdragsgiver ønsker at brukermodus skal være så enkel som mulig, uten distraherende støy. Derfor er det ønskelig at funksjonalitet for å legge til, endre og slette aktiviteter er skilt ut til en egen side. Oppdragsgiver er også veldig opptatt av at aktiviteter skal sorteres kronologisk, men ikke nødvendigvis til bestemte tider. MemoAssist er basert på klokkeslett. Dersom man ikke utfører en aktivitet til riktig tid vil planen «gå videre», selv om aktiviteten ikke er fullført. Det var vanskelig å finne frem til funksjoner, og applikasjonen inneholdt mye unødvendig støy som kan forvirre brukere. 6.2 careplan (e-mergency) CarePlan er en informasjon- og kommunikasjonsplattform som er utviklet hovedsakelig for å gjøre eldre og mennesker med kognitive nedsettelser mer selvstendige. Den skal også forbedre kommunikasjonen mellom ansatte, hjelpetrengende og pårørende. CarePlan har over 25 standardmoduler som gjør at det er enkelt å tilpasse planen for ulike brukere. Modulene dekker alt fra fjernstyring av lys til dagsplanlegging for mennesker med kognitive funksjonsvansker. Designmessig virket det veldig bra, med store knapper og god struktur. De tar også i bruk NFC 1, der de lar brukeren skanne klistremerker med enheten. Det kan for eksempel være et klistremerke med bilde av en kaffekopp på kjøkkenbenken. Etter man har scannet koden kommer det opp hvordan 1 Near Field Communication er en trådløs overføringsmetode som lar enheter kommunisere med hverandre. Gjør det også mulig å lese av NFC-brikker som i dette tilfellet er klistremerkene. 21

23 man koker en kopp kaffe i applikasjonen. Dette er en enkel og rask måte å se hvordan man utfører oppgaver uten å måtte navigere seg fram i applikasjonen. Som figur 4 viser er applikasjonen også optimalisert for mobil. Nederst på bildet kan man se noen eksempler på klistremerkene man kan skanne inn. FIGUR 4: CAREPLAN INNEHOLDER MANGE NYTTIGE FUNKSJONER, MEN ER TREG Å BRUKE. Den største ulempen til CarePlan er tregheten. Det tar alt for lang tid å bruke applikasjonen. Det virker som det er lagt inn for mye innhold og at applikasjonen ikke klarer å prosessere valgene man tar raskt nok. Dette vil nok for mange være svært frustrerende, spesielt for målgruppen vår som kan slite med konsentrasjonen og ha dårlig tålmodighet. En annen stor ulempe med applikasjonen er at den er avhengig av internett. Disse to problemene alene gjør at vi ikke kan anbefale denne applikasjonen for målgruppen vår. 6.3 Pictoplan Pictoplan er et struktureringsverktøy for ios som er utformet og testet på mennesker med kognitive utfordringer som ADHD og syndromer innenfor autismespekteret. FIGUR 5: PICTOPLAN BRUKER MANGE FARGER OG KAN DERFOR OPPLEVES SOM URYDDIG. De største fordelene med applikasjonen er at den har et stort bibliotek med beskrivende bilder, enkel struktur for å redigere aktiviteter og er forholdsvis rask å bruke. Problemet med Pictoplan er at ukesmodus kan oppfattes som visuelt uryddig, og den gir ikke mulighet for fullskjerm i dagsmodus eller ved sjekklister. Den mangler også en del viktige funksjoner, som for eksempel handlingskjeder. Planen har valgt å bruke ikoner istedenfor bilder, og har tatt i bruk svært mange farger. Dette ødelegger en del av det estetiske og kan være med på å forvirre brukeren. 22

24 7 Produktbeskrivelse I dette kapittelet vil produktet bli beskrevet med skjermbilder og tekst. Meningen er å få en detaljert forståelse av applikasjonens utforming. Produktbeskrivelsen er delt inn i en brukerdel og en administrasjonsdel. 7.1 Brukerdel Brukerdelen består av ukesmodus og dagsmodus. Ukesmodus viser en oversikt over alle gjøremål som skal utføres en bestemt uke og er forsiden i applikasjonen. Dagsmodus gir brukeren oversikt over alle aktiviteter for en bestemt dag. 7.2 Ukesmodus FIGUR 6: VISER HVORDAN UKESMODUS KAN SE UT FOR BRUKEREN. Forsiden viser ukens gjøremål fordelt på de ulike dagene. Ukedagene er organisert horisontalt og aktivitetene vertikalt. Den blå vertikale bakgrunnen viser hvilken dag det er, i dette tilfellet tirsdag. Det øverste grå feltet viser ukenummeret, og pilene gjør det mulig å navigere mellom ukene. Nøkkelen øverst til høyre leder videre til administrasjonssiden. Dersom en dag inneholder flere aktiviteter enn hva høyden på skjermen tillater, dukker en scrolle-funksjon opp. For å signalisere at en aktivitet er fullført, vises en hake over aktiviteten. Et eksempel på dette er «Stå opp» på tirsdag. Trykkes en aktivitet i planen ledes brukeren videre til dagsmodus. 23

25 7.3 Dagsmodus Topplinjen i dagsmodus inneholder et hjem-ikon som leder tilbake til ukesmodus. Det grå feltet viser hvilken dag det er, og gir brukeren mulighet til å navigere til andre dager. Listen på venstre side viser en oversikt over aktiviteter som skal utføres den aktuelle dagen. I oversikten kan brukeren navigere mellom de ulike gjøremålene uavhengig av rekkefølgen. Den valgte aktiviteten er fremhevet med lyseblå bakgrunn. Fullførte gjøremål vises i listen med en hake. FIGUR 7: VISER HVORDAN DAGSMODUS KAN SE UT FOR BRUKEREN. For den utvalgte aktiviteten i listen vises overskrift, beskrivelse og et bilde. Det brukes en stor grønn knapp for å markere at et gjøremål er fullført. For å fjerne fullført- status brukes en mindre rød knapp. Hvis aktiviteten fullføres vil brukeren ledes videre til neste gjøremål. Det er ikke mulig å igangsette aktiviteter på andre dager enn i dag, men det er mulig å se informasjon om de Handlingskjede En handlingskjede egner seg til aktiviteter der delhandlinger må gjøres i en bestemt rekkefølge. Delaktivitetene vises med overskrift, bilde og beskrivelse. FIGUR 8: VISER HVORDAN EN HANDLINGSKJEDE MED KONTEKSTMENY SKRUDD PÅ KAN SE UT. Til høyre i figur 8 er det en kontekstmeny som viser alle stegene som må utføres for å fullføre aktiviteten. Under kontekstmenyen er det en beskrivelse av hver delaktivitet. Ved å bekrefte at en delhandling er gjort ledes man automatisk videre til neste steg. Har man ved en feiltakelse trykket seg forbi en delhandling, kan man angre og gå tilbake til forrige steg. 24

26 7.3.2 Sjekkliste Dersom en aktivitet inneholder en sjekkliste, dukker denne opp i stedet for aktivitetsbilde. Til høyre for sjekklisten er det en tekstlig beskrivelse. I sjekklister er knappene deaktivert. Grunnen til at de ikke er helt skjult er for å opprettholde et konsistent brukergrensesnitt. FIGUR 9: VISER ET EKSEMPEL PÅ EN SJEKKLISTE. Sjekklisten består av delaktiviteter som kan hukes av etterhvert som de blir gjort. Det stilles ingen krav til hvilken rekkefølge aktivitetene skal utføres i. For hver aktivitet vises aktivitetsnavn og et bilde. Dersom sjekklisten inneholder flere ledd enn det er plass til å vise, kan man scrolle i listen for å se resten av aktivitetene. Utføres et ledd ved en feiltakelse, kan avhukingen fjernes ved å trykke på aktiviteten igjen. Når alle oppgavene er huket av vil man automatisk ledes til neste oppgave Bistand via Skype Bistand via Skype 2 gir brukeren mulighet til å kontakte bistandsytere. Dette kan være ansatte i omsorgsboliger eller familie og venner. Ved å tilby videosamtaler gjennom applikasjonen, kan brukeren motta bistand direkte under gjennomføring av aktiviteter. FIGUR 10: EN OVERSIKT OVER TILGJENGELIGE KONTAKTER DUKKER OPP OM BRUKEREN TRYKKER «HJELP». For at brukeren skal slippe å tenke på at det er Skype som brukes for å ringe, er knappen for å åpne bistandsdialogen navngitt som «Hjelp». Administratorer får informasjon om at det er Skype som brukes, fordi de må oppgi sin Skype-id. Bistandsmodulen blir ikke vist til brukeren dersom ikke Skype er installert på enheten. For å skjule tekniske detaljer er det opp til administrator å laste ned og installere Skype. 2 Skype er et videokonferanseverktøy med chat-funksjon. 25

27 7.3.3 Navigasjonsfelt Navigasjonsfeltet gjør det mulig å navigere mellom dager og uker. Venstre pil navigerer en side bakover, høyre pil navigerer en side fremover. Mellom pilene vises hvilken dag eller uke det er. FIGUR 11: VISER NAVIGASJONSFELTET FOR DAGSMODUS ØVERST. UNDER VISES NAVIGASJONSFELT FOR UKESMODUS Sveip Sveip-funksjonaliteten gjør det mulig å navigere mellom dager eller uker ved å føre fingeren til venstre eller høyre i det horisontale feltet øverst i brukerdelen. FIGUR 12: VISER SVEIPEFUNKSJONALITETEN Fargekoder Fargekoder brukes for å gi hver dag en unik farge. Dette lar brukerne forbinde ukedagene med bestemte farger, og gjør det mulig å kjenne igjen samme dag i dagsmodus som i ukesmodus. FIGUR 13: VISER ET UTDRAG AV FARGEKODENE I APPLIKASJONEN. 26

28 7.3.6 Kontekstmeny for handlingskjeder Kontekstmenyen er en liste på høyre side i dagsmodus som viser en oversikt over delaktiviteter i handlingskjeder. Den skal gjøre det enkelt for brukeren å følge med på fremdriften. Man har oversikt over hvilke delaktiviteter som er fullført, hvilken aktivitet som skal fullføres neste gang og en oversikt over alle andre steg som må utføres for at hovedaktiviteten kan regnes som fullført Nedteller Nedtelleren ligger under bildet til valgt aktivitet. FIGUR 14: KONTEKSTMENYEN VISER TYDELIG AT BRUKEREN ER PÅ DEN SISTE AKTIVITETEN I HANDLINGSKJEDEN. Administratorer kan legge til nedtelling for bestemte aktiviteter. I dagsmodus får brukeren mulighet til å starte og stoppe nedtelleren selv. Når tiden har gått ut høres en alarm. FIGUR 15: NEDTELLEREN I DAGSMODUS BLIR LYSEGRØNN ETTERHVERT SOM TIDEN TELLER NEDOVER Tilleggsfunksjoner for brukeren Administrator kan legge til og fjerne funksjoner som benyttes i brukerdelen. Disse påvirker både funksjonaliteten og designet, og gjør at planen kan tilpasses individuelt. Nedenfor vises ukesmodus, med og uten tilleggsfunksjoner. I figur 16 er det fargekoder under navnene på ukedagene. På toppen er det et navigasjonsfelt som gjør det mulig å skifte uke. FIGUR 16: TIL VENSTRE: UKESMODUS UTEN TILLEGG SKRUDD PÅ. TIL HØYRE: UKESMODUS MED ALLE TILLEGG SKRUDD PÅ. 27

29 Nedenfor vises dagsmodus med og uten tilleggsfunksjoner. I figur 17 har listen over aktiviteter samme farge som er brukt i ukesmodus. På toppen er det et navigasjonsfelt som gjør det mulig å skifte dag. Denne har et omriss i samme farge. Til høyre for navigasjonsfeltet er det en «Hjelp» - knapp som gjør det mulig å ringe etter bistand. Mellom aktivitetsbildet og knappene er det en nedteller. Til høyre for aktivitetsbildet er det en kontekstmeny for handlingskjeder. FIGUR 17: TIL VENSTRE: DAGSMODUS UTEN TILLEGG SKRUDD PÅ. TIL HØYRE: DAGSMODUS MED ALLE TILLEGG SKRUDD PÅ. 7.4 Administrasjonsdel Administrasjonsdelen gir bistandsytere mulighet til å sette opp, endre og slette aktiviteter fra dagsplanen. For å individuelt tilpasse applikasjonen kan funksjonene nevnt i forrige kapittel skrus av og på. I tillegg kan man legge til, endre og slette administratorbrukere Opprettelse av førstegangsbruker Første gang brukeren åpner applikasjonen må det opprettes en administratorkonto. FIGUR 18: VELKOMSTSKJERM VISES FØRSTE GANG APPLIKASJONEN STARTES. 28

30 FIGUR 19: VISER REGISTRERINGSSKJEMAET FOR OPPRETTELSE AV NY BRUKER. I registreringsskjemaet må brukeren ta bilde og fylle inn nødvendig informasjon. Tekstfeltene viser hva som skal fylles inn. Sjekkboksen til høyre viser om kravene til feltet er oppfylt. Godkjente felt er markert med en grønn hake. Ved å trykke på sjekkboksene gis det informasjon om hvilket krav det tilhørende tekstfeltet har. Feltet hvor Skype-brukernavn skal fylles inn er valgfritt, men avgjør om brukeren vil være tilgjengelig som bistandsyter via «Hjelp» -menyen. Når alle krav er oppfylt kan administratorkontoen opprettes. Ved innlogging bruker administrator brukernavnet og passordet som ble opprettet i registreringsskjemaet. Ved feil inntasting av brukernavn eller passord gis en tilbakemelding. FIGUR 20: INNLOGGINGSSKJEMAET FOR ADMINMODUS Hovedside Til venstre i administrasjonsdelen vises en vertikal meny med fire valg; «Vis ukeplan», «Endre plan», «Brukere» og «Innstillinger». Den uthevede knappen viser hvilken side man er på. Hovedsiden er «Vis ukeplan». Denne har likt grensesnitt som i ukesmodus og gir en oversikt over alle aktiviteter for en bestemt uke. På denne siden FIGUR 21: VISER UKESOVERSIKT I ADMINMODUS kan administratorer endre, legge til eller slette gjøremål. Under hver ukedag er det en «Legg til» -knapp som lar administrator legge til aktiviteter. Gjøremål som blir lagt til legger seg under den siste aktiviteten på valgt dag. For å endre eller slette opprettede gjøremål, trykker man på en aktivitet i planen. Dette leder videre til «Endre plan», der aktiviteter opprettes. Til høyre i topplinjen er det en «Logg ut» -knapp som fører tilbake til brukerdelen. 29

31 7.4.3 Endre plan Administrator må fylle ut aktivitetsnavn og legge til bilde for å opprette en ny aktivitet. Det er valgfritt å beskrive aktiviteten. Å legge til hjelpeliste 3 og/eller nedteller er også en valgmulighet. I hjelpelisten må administrator huke av om den skal utføres i rekkefølge eller ikke (se figur 23). Velger man å huke av, vil hjelpelisten opprettes som en handlingskjede. Ellers opprettes den som en sjekkliste. For å legge til felter i hjelpelisten trykker man på «Legg til», for å fjerne brukes «Fjern siste». FIGUR 22: OPPRETTELSE AV NY AKTIVITET I ADMINMODUS. Hjelpelisten settes opp ved å gi deloppgaver et bilde og aktivitetsnavn. Ved å skru på nedtelleren, får valgt aktivitet en tidsbegrensning. Hvis nedtelleren skrus på, dukker det opp et «pop-up»-vindu. Her bestemmer brukeren hvor lenge nedtelleren skal vare. Man har mulighet til sette på nedtelling helt opp til ett døgn. Hvis informasjonen fra brukeren ikke er tilfredsstillende utfylt, gir applikasjonen en beskrivende tilbakemelding. Lagret aktivitet legger seg i bruker- og administrasjonsdelen, på den valgte dagen. FIGUR 23: ANGIR OM EN HJELPELISTE SKAL VÆRE EN HANDLINGSKJEDE ELLER EN SJEKKLISTE. For å velge tidspunkt må brukeren trekke i tallene. FIGUR 24: NEDTELLEREN KOMMER OPP SOM ET POP-UP-VINDU. 3 En hjelpeliste er en fellesbetegnelse for handlingskjede og sjekkliste. 30

32 Alle aktiviteter som opprettes blir lagret som en mal. Dersom man endrer en mal som brukes andre dager, må man velge om man skal oppdatere kun for en bestemt dag eller for alle dager som bruker aktiviteten i databasen. FIGUR 25: DIALOG-BOKS FOR Å FÅ SVAR FRA BRUKEREN Endre eller slette aktivitet En opprettet aktivitet kan endres og slettes. All informasjon om aktiviteten er synlig, og oppsettet er likt som i «legg til aktivitet». Administrator kan lagre eventuelle endringer, men det er også mulig å slette hele aktiviteten. FIGUR 26: VED ENDRING AV AKTIVITETER BRUKES SAMME DESIGN SOM FOR OPPRETTELSE AV NYE. Dersom brukeren ønsker å slette en aktivitet dukker det opp en dialogboks 4. Der må brukeren bekrefte at aktiviteten virkelig skal slettes. FIGUR 27: BRUKEREN MÅ GI EN BEKREFTELSE OM EN AKTIVITET SKAL SLETTES Innstillinger I innstillinger kan administrator velge hvilke funksjoner som skal være aktiverte. Enkelte brukere har ikke behov for tilleggsfunksjonalitet som fargekoder, og det er her administrator kan sette opp hva som skal vises. Ved å trykke på funksjonsnavnet kommer det opp et bilde og en beskrivende tekst som skal hjelpe administratoren med å avgjøre om dette er aktuelt å bruke for en bestemt bruker. 4 En dialogboks er et lite vindu som ber brukeren ta en beslutning eller angi tilleggsinformasjon. 31

33 FIGUR 28: I «INNSTILLINGER» KAN ADMINISTRATOR INDIVIDUELT TILPASSE DAGSPLANEN TIL EN BESTEMT BRUKER. Under avanserte innstillinger kan administrator laste inn en eksempelplan eller slette alle aktiviteter. Eksempelplanen oppretter en uke fylt med aktiviteter, som gir administrator mulighet til å teste ut applikasjonen uten å jobbe med virkelige aktiviteter. I tilfelle man skulle trykke feil eller angre, krever begge valgene en bekreftelse. Dette gjøres med en dialogboks Brukere Brukersiden viser en oversikt over alle brukere. Administrator kan legge til en ny bruker ved å trykke på «Lag ny bruker»-knappen. En bruker kan endres ved å trykke på bildet eller navnet til den aktuelle brukeren. For å slette en bruker benyttes «Slett»-knappen. Denne handlingen kan ikke angres, og krever derfor en bekreftelse fra brukeren. FIGUR 29: VISER EN OVERSIKT OVER ALLE REGISTRERTE BRUKERE. 7.5 Kommunikasjon med brukeren Applikasjonen kommuniserer med brukeren på ulike måter avhengig av hvilket behov det er for interaksjon og meldingens viktighet. Nedenfor er det beskrevet tre ulike måter tilbakemeldinger blir gitt til brukeren. 32

34 7.5.1 Meldinger som krever interaksjon Meldinger som krever at administrator tar et valg vises som en dialogboks. Dette kan eksempelvis være når en bruker skal slette en aktivitet (se figur 30) eller går ut av en ny aktivitet uten å lagre (se figur 31). I dagsmodus brukes ikke dialogbokser for å kommunisere med brukeren. Dette er fordi dialogbokser krever at brukeren tar et valg, og det er ofte ikke hensiktsmessig å tvinge brukere i Digitus målgruppe til å velge. FIGUR 30: DIALOGVINDU SOM MÅ BEKREFTES FOR Å SLETTE EN AKTIVITET. FIGUR 31: DIALOGVINDU SOM MÅ BEKREFTES FOR Å FORLATE EN SIDE Meldinger som ikke krever interaksjon Enkelte meldinger kan gi nyttig informasjon uten at det kreves interaksjon fra brukeren. Disse meldingene blir vist som en toast 5, og kan for eksempel vise om brukernavn eller passord er skrevet inn feil (se figur 32). Disse meldingene brukes ikke i dagsmodus, da de kun vises en begrenset periode. I Digitus målgruppe er det mange som har lese- og skrivevansker, og da er det ikke riktig å bruke meldinger som kun vises i noen sekunder. FIGUR 32: INFORMASJONSMELDINGER SOM SKRIVES UT KREVER IKKE INTERAKSJON Meldinger som er informasjon FIGUR 33: GIR NYTTIG INFORMASJON OG KREVER IKKE INTERAKSJON. Meldinger som gir nyttig informasjon til brukeren som ikke krever interaksjon, blir vist i form av et TextView 6. Dette brukes for eksempel under Innstillinger, for å informere om funksjoner på siden. 5 Et vindu som viser tekstlig tilbakemelding til brukeren. 6 Et tekstfelt som viser tekst til brukeren, uten mulighet for redigering. 33

35 8 Brukertest og intervju Vi har gjennomført brukertesting på brukerdelen og administrasjonsdelen. Oppdragsgiver ønsket at det skulle legges størst vekt på brukerdelen, og vi har derfor gjort mer omfattende brukertesting her. Vi har gjort fem uavhengige brukertester av følgende: Brukertest av ikoner Brukertest brukerdel av oppdragsgiver Brukertest brukerdel av beboere på omsorgsbolig Brukertest brukerdel av femåring Brukertest administrasjondelen av oppdragsgiver (kolleger ved OUS) 8.1 Personvern Datainnsamling er en viktig del av analysen for dagsplanapplikasjonen vår. Vi har derfor jobbet for å sikre at dataene vi samler inn er riktige, relevante og samtidig beskytter personvernet til intervjuobjektene. I personvernlovens 1. paragraf står følgende: «Formålet med denne loven er å beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger. Loven skal bidra til at personopplysninger blir behandlet i samsvar med grunnleggende personvernhensyn, herunder behovet for personlig integritet, privatlivets fred og tilstrekkelig kvalitet på personopplysninger.» For å sikre at personvernloven følges har vi valgt å fokusere på følgende punkter: Det er helt frivillig å delta på våre undersøkelser og intervjuer. Informasjon om formålet med datainnsamlingen gis tydelig. Intervjuobjektet kan lese gjennom innlevert data før publisering. Intervjuobjektet har mulighet til å trekke seg på hvilket som helst tidspunkt. Opplysningene skal være korrekte, og eventuelle feil skal korrigeres. Vi har valgt ikke å samle inn opplysninger om navn eller spesifikk alder, slik at ingen kan identifisere individuelle personer ut ifra brukertestene eller spørreundersøkelsene. Da slipper vi også å søke om konsesjon fra datatilsynet. Alle deltakere i våre brukertester/intervjuer har skrevet under på et samtykkeskjema. Skjemaet ligger som vedlegg i denne rapporten. 8.2 Generelt om brukertester En brukertest går ut på å observere hvordan en bruker benytter ulike funksjoner i et system, og er en av de beste metodene for å avdekke svakheter i brukergrensesnittet. Gjennom brukertesting får man tilbakemeldinger fra brukerne av systemet, noe som kan hjelpe med å forbedre løsningen. En svakhet 34

36 ved brukertesting er at resultatene blir basert på et representativt utvalg av testpersonene sine subjektive ferdigheter og meninger. Når testpersonen utfører oppgavene i testen er det viktig at vi som observerer forsøker å påvirke minst mulig. Dette er for at testpersonene ikke skal miste fokus og utføre oppgaven annerledes enn hvordan de vanligvis ville gjort det. Det er viktig å la testpersonene gjennomføre brukertesten på egenhånd. Hvis de blir usikre eller har spørsmål knyttet til systemet, er jobben vår å få dem til å gjøre det de ville ha gjort om vi ikke var tilstede. Siden vi har jobbet tett med OUS har vi funnet gode testpersoner innenfor vår målgruppe, både til brukerdelen og administrasjonsdelen. Dette gir oss relevante resultater og gjør det lettere å utvikle en løsning som målgruppen kan nyttiggjøre seg av. 8.3 Generelt om våre intervjuer Etter hver brukertest har vi hatt et intervju for å samle inn informasjon fra testpersonene. Fordelen med dette er at det er fleksibelt ved at man kan bygge videre på spørsmål og svar. Når man gjennomfører et intervju er det viktig å legge til rette for den man intervjuer. Vi må gjøre testpersonen oppmerksom på at dette er et intervju og hva det skal dreie seg om. 8.4 Brukertest av prototype på OUS-ansatte Det er svært viktig at brukeren faktisk kan bruke løsningen vi har laget. Derfor har vi latt oppdragsgiver prøve ut løsningen kontinuerlig gjennom utviklingsprosessen. De har faglig kunnskap om brukerens behov, noe som vil gjøre det lettere for oss å lokalisere og fjerne flest mulig tilgjengelighets- og brukervennlighetsproblemer. Dette har også gitt oppdragsgiver oversikt over utviklingen vår og muligheten til å komme med tilbakemeldinger og korrigeringer. I starten av prosjektet gjennomførte de en brukertest vi hadde laget i PowerPoint. Dette var en hi-fi prototype 7 med lite funksjonalitet. Denne hadde som hensikt å hjelpe oss med å få et godt utgangspunkt før vi skulle teste på personer i målgruppen vår Gjennomføring og resultat Gjennomføringen av brukertesten foregikk ved at våre tre testere fikk fire oppgaver som gikk ut på å utføre fire forskjellige handlinger ved å følge instrukser i dagsplanen. Poenget med testen var at de som brukertestet ikke hadde forutsetninger for å klare oppgavene som ble gitt uten hjelp fra applikasjonen. Hvis de klarte oppgavene ville dette bekrefte, eventuelt avkrefte, om brukergrensesnittet var enkelt og forståelig. 7 En hi-fi prototype inneholder en del funksjonalitet og tilbyr noe interaksjon. 35

37 FIGUR 34: EKSEMPEL PÅ EN AV OPPGAVENE TESTPERSONENE FIKK. Tilbakemeldingene var hovedsaklig at det visuelle designet var bra og det blir tydelig vist hvilken dag det er. Testpersonene opplevde at det var lett å navigere seg rundt i applikasjonen og synes sjekklistene er satt opp på en enkel måte. Vi fikk tilbakemeldinger om at vi burde benytte plassen bedre uten å la det gå utover layouten. Dette kan gjøres ved å øke bildestørrelsen. Klokkeikonet kunne være litt diffust og gi lite mening for noen. Generelt mente de at ikonene kunne være vanskelig å forstå for noen i målgruppen. De presiserte at brukerne har veldig ulikt modenhetsnivå, og at det må være muligheter for individuell tilpasning Konklusjon Etter brukertesten fant vi ut at det vil være fordelaktig å gi hovedinnholdet mer plass. Dette kan gjøres ved å fjerne alle mellomrommene. Ved å gjøre dette vil både tekst og bilder bli mer synlige, samtidig som mindre plass blir kastet bort. 8.5 Brukertest ikoner Gjennomføring og resultater På bakgrunn av brukertesten med OUS var vi i tvil om ikonene var tydelige nok, og vi valgte derfor å utføre to brukertester for å finne ut hva andre brukere mente om de. I den første brukertesten samlet vi en testgruppe på fem personer bestående av medstudenter som gjennomgikk alle ikonene våre. Resultatene fra denne testen viste at noen av ikonene i appen var tvetydige. Siden det er viktig med gode ikoner valgte vi å utvikle nye versjoner av alle ikonene testerne mislikte. 36

38 Deretter gjennomførte vi en ny brukertest med personer som var ukjente for oss. Testen ble gjort på nettstedet OptimalWorkshop 8, og vi fikk inn totalt 30 svar. De nye ikonene la vi ut som en klikktest. Der kunne testerne trykke på det ikonet de mente passet best til en gitt beskrivelse. Resultatene fra testen kunne vi lese fra et gråskala varmekart. Dette viste tydelig hvor brukerne hadde trykket. Figur 35 viser eksempler på varmekartet. FIGUR 35: EN KLIKKTEST VISTE HVILKET IKONER EN TESTGRUPPE MENTE VAR MEST BESKRIVENDE. DET ER TYDELIG AT IKONENE SOM INNEHOLD BÅDE HUND OG POSE/BÅND BLE FORETRUKKET Konklusjon Etter samtaler med oppdragsgiver ble vi enige om at vi skulle gå bort fra ikoner og heller bruke bilder til å beskrive gjøremålene. Det er for eksempel lettere for brukeren å kjenne igjen et bilde av sin egen seng enn et ikon av en seng. Med mer brukergenerert innhold vil administrator kunne ta mer beskrivende bilder og dermed forenkle vedlikeholdet av planen. Fordelen med å ha utført disse brukertestene er at vi har fått bedre innsikt og bredere erfaring i bruk av ikoner. Selv om det ikke brukes ikoner sammen med gjøremålene, er det fortsatt ikoner andre steder i applikasjonen, for eksempel «hjem»- og «slett»-knapper. Det vil senere være ønskelig med brukertesting av disse ikonene, og dermed har vi gitt oss selv et klart fortrinn. 8.6 Brukertest brukerdelen Gjennomføring og resultater I mars utførte vi en brukertest på to beboere ved en omsorgsbolig i Oslo. Brukerne er innenfor vår målgruppe, men på grunn av personvern kan vi ikke oppgi nøyaktige diagnoser. Vår veileder og en representant fra OUS var med på testen. Brukertesten av brukerdelen ble gjennomført av to potensielle brukere som behersker digitale applikasjoner. Bruk av hjelpemiddelteknologi 9 vil derfor ikke være nødvendig i denne omgang. De utførte oppgaver knyttet til de viktigste funksjonene; sjekkliste og handlingskjede. Brukerne fikk like oppgaver. 8 OptimalWorkshop er et nettsted som brukes for å sjekke brukervennlighet. Ikonene ble testet med et verktøy kalt «Chalkmark». 9 Kompenserende teknologi som lar mennesker bruke teknologiske løsninger de ellers ville vært utelatt fra. Eksempler kan være øyestyring og tekst til tale/tale til tekst. 37

39 FIGUR 36: APPLIKASJONEN BRUKERNE TESTET, HER VISES «HANDLE» MED SJEKKLISTE. Den første oppgaven var å handle matvarer ved hjelp av applikasjonen. Testerne fikk en predefinert handleliste med fire forskjellige produkter som skulle kjøpes. Handlelisten var satt opp som en sjekkliste der varene skulle hukes av etterhvert som de ble funnet. To av prosjektmedlemmene var med i butikken for å observere brukerne. Etter handlingen skulle vannkokeren startes, og mens vannet kokte skulle bordet dekkes. Testpersonene ble trinnvis forklart hva som skulle settes på bordet gjennom en handlingskjede, se figur 37. Etter dette kom det en ny handlingskjede hvor det skulle lages kakao. Til slutt skulle de spille et selvvalgt spill. FIGUR 37: PÅ BILDET VISES HANDLINGSKJEDEN SOM BLE BRUKT FOR Å HJELPE BRUKEREN TIL Å HUSKE HVA SOM SKAL DEKKES PÅ. 38

40 Person 1 Person 1 er en høytfungerende beboer i omsorgsboligen som er godt vant med smarttelefoner og nettbrett. Derfor gikk vi bare igjennom applikasjonen en gang, slik at det fortsatt skulle være en viss vanskelighetsgrad. Under handlingen i butikken brukte person 1 svært kort tid, men krysset ikke av i sjekkboksene etter hvert som varene ble funnet. Person 1 så bare på bildene for å finne riktig vare. Bortsett fra dette var utførelsen slik vi ønsket. Testeren trykket seg gjennom applikasjonen uten problemer og virket å ha forstått hvordan den fungerer. FIGUR 38: TESTPERSON 1 I BUTIKKEN. TESTPERSONEN ER ANONYMISERT ETTER EGET ØNSKE. Når det skulle dekkes på ble testeren usikker siden det var fire tallerkener på bildet og fem personer som deltok på testen. Dette løste vi ved å utelate en av observatørene. Under pådekkingen glemte brukeren å trykke «fullfør» i starten, og brukte bare miniatyrbildene i handlingskjeden som hjelp. Etter litt veiledning brukte person 1 planen som tiltenkt, altså ved å «fullføre» hver delaktivitet i planen. Under oppgaven «lage kakao» virket det som at handlingskjeden stanset arbeidsflyten. Det var for mange steg og person 1 visste allerede hvordan man lager kakao. Steg blir derfor hoppet over og vi må igjen oppfordre brukeren til å følge handlingskjeden slavisk. 39

41 Person 2 Person 2 er også en høytfungerende beboer i omsorgsboligen, som er vant med å bruke både mobil og nettbrett i hverdagen. Vi ga derfor i likhet med person 1 kun en kort introduksjon av applikasjonen. Person 2 brukte noe lengre tid i butikken, men fant alt uten store problemer. Brukeren huket ikke av i sjekkboksene etter hvert som varene ble funnet. Videre i testen ble vannkokeren satt på, men testeren skjønte ikke hvor man skulle trykke for å komme seg videre i planen. Vi forklarte dette slik at testeren kunne komme til neste steg. FIGUR 39: TESTPERSON 2 I BUTIKKEN. TESTPERSONEN ER ANONYMISERT ETTER EGET ØNSKE. Dekking av bordet gikk forholdsvis greit, men det ble noe forvirring. Det virket som om person 2 kun brukte bildene for å utføre oppgaven. I tillegg måtte vi stadig minne testeren på å fullføre oppgavene i handlingskjeden. Det ble også forvirring da brukeren skulle hente glass. Testeren hadde hentet kopper tidligere, og tenkte at det allerede var gjort. Den andre handlingskjeden, «lage kakao», gikk bedre. Person 2 skjønte hvor man skulle trykke etter hver utførte deloppgave, og jobbet seg raskt gjennom handlingskjeden. Det var noe usikkerhet rundt hvordan man skulle «fullføre» aktiviteter i handlingskjeden, men etter litt prøving og feiling fant brukeren ut av det. 40

42 Etter testen lot vi brukeren navigere seg gjennom applikasjonen på nytt. Det er da tydelig at person 2 allerede har fått en mye bedre forståelse Intervju Intervjuet fungerte som en avslutning til brukertesten. Her stilte vi spørsmål om gjennomføringen og om hva testpersonene syntes om applikasjonen. Vi valgte å ha få spørsmål for at det skulle være så uformelt og lett for intervjuobjektet som mulig. Under intervjuet deltok de samme som var med på brukertesten. Dette ble gjort for at alle skulle få mest mulig kunnskap om systemet. Vi hadde en som stilte spørsmål og en som skrev ned stikkord mens resten observerte eller kom med innspill. Dette ga oss god kvalitetssikring av gjennomføringen. Det var et åpent, formelt intervju, hvor spørsmålene var laget på forhånd. Dette er nyttig når det er behov for å innhente brukerens oppfatning av systemet. Vi begrenset bruken av lukkede spørsmål, og dermed unngikk vi at intervjuobjektet utelukkende svarte ja eller nei. Intervjuet av person 1 utførte vi under den avsluttende delen av brukertesten. Spørsmålene stilte vi samtidig som vi spilte yatzy for at intervjuet ikke skulle virke så formelt. En ulempe med dette var at person 1 ble ukonsentrert da spillet virket mer spennende enn spørsmålene. Det var derfor litt vanskelig å få utdypende svar selv om vi kom med oppfølgingsspørsmål. Intervjuet av person 2 valgte vi å ta etter vi hadde spilt ludo for å unngå at personen skulle være ukonsentrert. Vi stilte de samme spørsmålene, men det var igjen vanskelig å få utdypende svar Konklusjon Resultatene fra begge brukertestene viste svært liknende problemområder, og vi har derfor valgt å samle konklusjonene. I dette avsnittet går vi også gjennom resultatene fra intervjuene. Det viktigste vi oppdaget gjennom brukertestene og intervjuet var at vi fikk bekreftet at applikasjonen vår har en nytteverdi for brukerne og at de er positive til å ta den i bruk. Dette er givende og gir oss motivasjon til å jobbe videre. Brukerne opplevde at det var for lette oppgaver, noe som ødela flyten og kun virket forstyrrende. I butikken haket ikke brukerne av i sjekklisten etterhvert som varer ble funnet. Dette kan komme av flere grunner. Det ble blant annet gitt lite opplæring, og vårt nærvær kan ha skapt stress og usikkerhet. Det er også mulig at brukerne ville imponere oss ved å fullføre oppgavene raskt. Sjekklisten fungerte likevel bra, siden oppgavene kan utføres i vilkårlig rekkefølge. Vi så gjennomgående under testen at det var bildene som ble mest brukt, og testerne så knapt på teksten. Dette til tross for at begge hadde gode leseferdigheter. Hos en av brukerne var bildene til spesielt stor hjelp, da personen var dårlig med tall. Det hjalp testeren at bildene viste antall glass og skjeer som skulle dekkes på. Dette viser at om bildene er gode nok kan de beskrive bedre enn ord. 41

43 Den viktigste delen vi må ta tak i er enkelhet. Vi har mye å forbedre både på design og brukervennlighet. Navigasjonsmulighetene må forenkles slik at det ikke er tvil om hva som leder hvor. Plasseringen av knapper må være konsistente og tydelige. Brukeren skal ikke være usikker på hva knappene har som hensikt. Vi må også fjerne unødvendig støy som kan forvirre brukeren og prøve å optimalisere fargene for å skape best mulig harmoni i designet. Navigering i applikasjonen skjer uten problemer, og det manøvreres lett mellom dag- og ukesplan. En ulempe er at applikasjonen opplevdes som treg for brukerne. Det tok et par sekunder fra en aktivitet ble trykket til den ble vist. Begge personene er svært positive til å bruke dagsplanen, men ville gjerne hatt mer krevende oppgaver. Med litt mer opplæring ville planen fungert godt. Testerne vil gjerne bli med videre i utviklingsprosessen og har vist stor interesse for å bruke fremtidige løsninger. 8.7 Brukertest med 5-åring FIGUR 40: BRUKERTEST MED ET BARN VISTE AT NAVIGASJONEN FUNGERTE GODT. Vi utførte en liten brukertest på om navigeringen i dagsplanen var enkel for barn. Dette ble gjennomført ved å legge inn bilder av dyr i kalenderen, og det var altså ikke kalenderfunksjonaliteten som ble testet. Navigering virket veldig intuitivt for barnet, og det var ingen større problemer som ble oppdaget. For å få bildet stort trykket barnet i venstremenyen, og trakk den opp og ned for å se flere elementer. Femåringen syntes det var veldig gøy å bruke, fordi barnet selv kunne velge hvilke 42

44 dyr som skulle vises. Dette var en vellykket test som viste at personer med liten/middels erfaring med nettbrett kan overføre kunnskapene sine til vår løsning. 8.8 Brukertest admindelen Gjennomføring og resultater Administrasjonsdelen ble brukertestet av to ansatte tilknyttet OUS, som er vant med å sette opp analoge planer. Deres teknologiske ferdighetsnivå kan kategoriseres som lavt, men begge var kjent med smartenhenter. For å teste om applikasjonen er lett å bruke valgte vi å kun gi opplæring til en av testerne. Brukertesten bestod blant annet av å legge til, endre og slette aktiviteter. Til slutt ble det gjennomført et uformelt intervju om brukeropplevelsen. Begge brukerne slet med integrerte funksjoner på nettbrettet, blant annet hadde de problemer med å lukke tastaturet etter bruk. Dette gjøres enten ved å trykke «Ok» på tastaturet eller trykke den fysiske tilbake-tasten på nettbrettet. Brukerne prøvde å trykke på «hjem»-ikonet i applikasjonen for å lukke tastaturet, noe som førte til at dagsplanen ble avsluttet. Dette skapte stor frustrasjon for brukeren, fordi de måtte logge inn på nytt. Brukerne hadde også problemer med å få bort en liste over kjørende applikasjoner. Denne dukket opp da testpersonen kom nær en av de trykkfølsomme knappene på nettbrettet. Testperson 1 syntes det var veldig enkelt å navigere i applikasjonen. Brukeren opplevde at oppgavene var enkle, og testeren er svært positiv til nyttigheten av dagsplanen. Videre fortalte brukeren at applikasjonen kan forenkle dagen for bistandsytere ved at man slipper å skrive ut og laminere bilder. Personen mener det ikke skal mye opplæring til for å bruke planen. Likevel var brukeren usikker på hvordan man administrerer nedtelleren, og ønsker mulighet for å skrive inn tall manuelt. Med nåværende løsning må man trekke tallene opp eller ned for å stille nedtelleren. Nedtelleren er vist i figur 41. FIGUR 41: MAN MÅ TREKKE I TALLENE FOR Å ENDRE TID FOR NEDTELLEREN. Testperson 2 var veldig positiv til at det var raskt å opprette aktiviteter. Brukeren slet med å finne igjen gjøremål som nettopp har blitt opprettet, siden de havner nederst på dagen. Planen var allerede full, så brukeren måtte scrolle nedover på dagen for å finne aktiviteten. Brukeren ønsket å få en tydeligere indikasjon på om det er flere «usynlige» aktiviteter i aktivitetslisten. Brukeren forstod ikke umiddelbart hvor man må trykke for å komme til administrasjonssiden, men presiserer at dette kun har med opplæring og hva man er vant med å gjøre. 43

45 Begge brukerne forstod opprettelse og endring av hjelpelister godt. En av brukerne klarte ikke umiddelbart å gjøre om fra handlingskjede til sjekkliste, men oppdaget etterhvert informasjonsknappen som står plassert like over hjelpelisten. Brukeren trykket på denne og fikk opp en pop-up-melding med informasjon om forskjellen mellom handlingskjede og sjekkliste. Etter å ha lest denne endret brukeren enkelt fra handlingskjede til sjekkliste. Personen som ikke fikk opplæring stoppet litt opp på oppgaven der en sjekkliste skulle settes FIGUR 42: FOR Å TA BILDE MÅ MAN TRYKKE PÅ NUMMER 1. UNDER TESTEN TRYKKET BRUKEREN PÅ 2. opp. Brukeren forsøker å legge til bilder for delaktiviteter ved å trykke på bilderammen (nummer 2 i figur 42). For å legge til bilder må man trykke på kameraikonet (nummer 1 i figur 42). Brukeren fant ikke «administrasjonsknappen» umiddelbart, men logget inn uten problemer etter å ha funnet den. Da brukeren skulle legge til en aktivitet i planen trykket testeren «endre plan» i menyen uten at noe skjedde. Årsaken til dette var at «endre plan» allerede ble vist på skjermen. Testeren fant ut hvordan man legger inn aktiviteter uten vanskeligheter. Under testen var det tydelig at innføringen hadde stor betydning for resultatet. Brukeren som fikk opplæring utførte oppgavene vesentlig raskere, og opplevde få problemer under testingen. Testpersonene så ut til å slite mer med nettbrettet enn selve applikasjonen. Gjennomføringen av brukertesten var vellykket, og brukerne presiserer at oppgavene ville blitt utført raskere neste gang. Begge testerne var positive til å bruke dagsplanen, og ser frem til en endelig løsning Konklusjon På sikt er målet er at man ikke skal trenge opplæring for å bruke applikasjonen. Frem til dette målet er nådd må man nok ha en kort innføring i applikasjonens funksjoner og muligheter. Problemet som gikk mest igjen var fjerning av tastaturet etter bruk. Dette vil variere fra nettbrett til nettbrett, men er mulig for oss å gjøre lettere. Vi ser for oss at tastaturet kan forsvinne når man trykker utenfor tekstfeltet. Brukertesten avdekket at de integrerte hjelpemidlene på nettbrettet var forstyrrende. For å løse dette kan admindelen låses slik at man ikke kan komme til brukerdelen ved feiltrykking. Det er kjedelig å måtte logge inn på nytt dersom man trykker feil. Brukertesten viste at nedtelleren kunne vært mer intuitiv, noe som kan gjøres ved å legge til mulighet for å skrive inn tall ved hjelp av tastaturet. Brukeren trykket på bildet i hjelpelisten for å ta bilde til en delaktivitet. For å tydeliggjøre at dette ikke er en knapp, men kun et ikon for å vise at det enda ikke er lastet opp et bilde, kan kanten rundt markeres med rødt. 44

46 8.9 Endringer som følge av brukertest Brukertesting har vært en viktig del av vårt arbeid gjennom hele prosjektperioden. På bakgrunn av testresultatene har vi gjort mange endringer som har ført til en mer brukervennlig og effektiv løsning Brukertest av prototype - brukerdel Etter brukertesten av prototypen med oppdragsgiver ble det gjort store endringer. Vi fikk tilbakemeldinger på at vi burde utnyttet plassen bedre uten å la det gå ut over layoutet. Selv følte vi at både ukesmodus og dagsmodus i applikasjonen virket lite dynamisk og det var alt for sterk fargebruk (se figur 43). Vi valgte derfor å endre hele designet (se figur 44). FIGUR 43: PROTOTYPE-DESIGN. FIGUR 44: DESIGN FOR FERDIG LØSNING. Endringene førte til et langt penere og mer levende design. Ved å flytte hovedinnholdet nærmere kantene og samtidig fjerne de store mellomrommene, ble plassen utnyttet bedre. Aktivitetsfeltene fikk avrundede hjørner og ble dermed mer dynamiske. De sterke fargene valgte vi å fjerne. De virket tunge og var ubehagelige å se på, derfor fant vi mer harmoniske fargenyanser med mørke og lyse farger Brukertest av ikoner Som nevnt i konklusjonen for denne brukertesten gikk vi bort fra ikoner som bilder. Vi valgte å forstørre aktivitetsfeltet slik at bilder og tekst blir tydeligere. Vi åpnet også for at bistandsytere kan velge bilder selv. 45

47 8.9.3 Brukertest av brukerdel Brukertesten med brukere fra omsorgsboligen førte til flere endringer i dagsmodus. Under listes de viktigste endringene opp. Sjekkliste Sjekklisten ble flyttet fra høyre til midt på siden (se figur 45), slik at den blir vist som hovedinnhold. Dette fjernet mye støy og siden ble mer oversiktlig for brukeren. FIGUR 45: SJEKKLISTE FØR OG ETTER ENDRINGER. Handlingskjede Det ble også avgjort at det måtte være mulig å fjerne kontekstmenyen i handlingskjeder, noe vi implementerte kort tid senere. Mange brukere vil oppleve denne menyen som forstyrrende, noe som kan føre til at de mister flyten i aktiviteten. Når menyen er fjernet, trenger brukeren kun å forholde seg til ett bilde av gangen. Figur 46 viser en handlingskjede med og uten kontekstmeny. Menyen kan skrus på av administratorer dersom brukeren ønsker det. FIGUR 46: HANDLINGSKJEDE FØR OG ETTER ENDRINGER. Knapper Vi endret også plassering av knapper siden «utført»-knappen var forvirrende og dårlig plassert. Vi la også til en «angre»-knapp, og ga de farger som er enkle å forstå. Grønn for «ferdig», rød for «ikke ferdig». Endringen vises i figur

48 Skalering av bilder Under brukertesten oppdaget vi at testerne syntes innlasting av aktiviteter tok lang tid. Innlasting av bilder er en krevende operasjon, og applikasjonen består av mange bilder. Vi forsøkte å fjerne alle bilder, noe som resulterte i at applikasjonen ble meget rask. Derfor konkluderte vi med at bildestørrelsen måtte reduseres for å oppnå en god brukeropplevelse. For å skalere bilder brukte vi Bitmap-funksjonen createscaledbitmap i Java. Her får man mulighet til å skru på filter. Eksempel på hvordan filter ser ut er vist i figur 47. Dersom man skrur på filter skal kanter bli jevne, uten blir de blokkaktige og pixelerte. Filter gir som regel best bilder 10. For å finne det rette forholdet mellom filstørrelse og kvalitet er to forskjellige komprimeringer utprøvd. Testen ble utført på en Samsung Galaxy Tab SM-T700, og bildene ble tatt på stativ for å sikre et så likt bilderesultat som mulig. FIGUR 47: TIL VENSTRE: UTEN SKALERING. MIDTEN: SKALERING MED FILTER. TIL HØYRE: SKALERING UTEN FILTER. Alternativ 1 (uten skalering) gav en bildefil på 2030 KB, og bildestørrelsen var 3264 px * 1836 px. Vi fant ut at dette ga den klart beste bildekvaliteten, men tok lengst tid å laste inn. Alternativ 2 og 3 (med skalering) gav en bildefil på mellom KB, og bildestørrelsen var 1000 px * 563 px. Alternativ 2 (med filter) hadde nest best kvalitet, og var den raskeste å laste inn. Fargene var ikke like klare som alternativ 1, og bildet var også litt uskarpt. Alternativ 3 (uten filter) var midt i mellom de andre alternativene på innlastingstid. Bildet hadde dårligst bildekvalitet, og hvis man ser nøye på kabelen ser man at det er mye mer pikslete enn de andre alternativene. Vi valgte å gå for alternativ 2, som gir god kvalitet og lav filstørrelse. Vi mener det er viktigere at appen laster raskt enn at bildekvaliteten er på topp. Samtidig er det en fordel at bildene er mindre, for da blir ikke nettbrettets lagringskapasitet brukt opp så fort Brukertest av administrasjonsdel Brukertesten av administrasjonsdelen førte til flere endringer som forenklet adminmodus. Forenklet fjerning av tastatur Begge testerne slet med å få bort tastaturet når de var ferdig med å bruke det. Vi har derfor sørget for at det er mulig å trykke utenfor tastaturet for å fjerne det

49 Forbedret ikon i bilderamme Vi endret ikonet i bilderammene i hjelpelisten for å unngå forvirring. Dette gjorde vi ved å legge til en rødfarge på bilderammen(e) og ikonet i midten. Meningen var å vise at det ikke kan klikkes der for å legge til et bilde, men dette ga et inntrykk av at det var gjort en feil eller at det ikke var mulig å legge til et bilde. Vi gikk derfor tilbake til det gamle ikonet. «Info»-knappen for hjelpeliste var vanskelig å oppdage for testerne. Derfor flyttet vi på den og gjorde den tydeligere med en beskrivende tekst. 48

50 9 Utviklingsprossen I dette kapittelet vil vi forklare og vise prosessen fra skissestadiet til endelig løsning. Her beskrives hovedsaklig skissering, prototyping og implementering. Vi tar også for oss arbeidsmetoder, verktøy og brukertesting. 9.1 Smidig utviklingsmetodikk Smidig utvikling har de siste årene blitt en svært populær utviklingsmetodikk, særlig innenfor IT. Den tar høyde for at de funksjonelle kravene til systemet kan endres underveis i utviklingsperioden. Dette gjør det lettere å utføre endringer og kan redusere risikoen for større feil og mangler. Selv om vi hadde fastsatte krav fra starten, dukket det opp flere krav underveis. Ved å bruke elementer fra Scrum 11 har det vært enkelt å tilpasse seg endrede krav fra oppdragsgiver. Metodene går ut på å utvikle systemet bit for bit og gi oppdragsgiver hyppige leveranser gjennom prosessen. Dette inkluderte oppdragsgiveren i mye større grad, og ga dem muligheten til å være med på å forme utviklingsprosessen. Hovedfordelen med smidig utvikling er at vi får testet løsningen gjennom hele utviklingsprosessen. Vi har jobbet i iterasjoner på to uker med totalt ti sprinter 12. Annenhver fredag har vi fullført en iterasjon. Mellom hver sprint har vi vist fram arbeidet som er gjort for oppdragsgiver, slik at vi unngikk å utvikle noe annet enn det som var ønsket. For oss var det viktig å ha en tett dialog med oppdragsgiver, og gjennom hyppige møter kunne vi få tilbakemeldinger på fremgangen og rette oss etter deres ønsker. Vår product backlog 13 har vært lagret i et prosjektstyringsverktøy kalt Redmine. For hver sprint satte vi over oppgaver fra produktkøen til en sprint backlog 14. Hvilke saker som ble prioritert for hver sprint ble bestemt i samarbeid med oppdragsgiver. I starten var det mest rettet mot brukerdelen av applikasjonen, siden denne skulle brukertestes først. Hver sprint har hatt mellom saker, avhengig av kompleksitet og omfang. I starten kunne vi ikke Android-programmering, og det var derfor få saker i hver sprint. Utover i prosessen økte antall saker for hver sprint. Vi hadde daglige stand up-møter innad i gruppen hvor vi presenterte hva vi hadde gjort det siste døgnet for hverandre. Dette gjorde at alle fikk større faglig tyngde, og vi fikk diskutert mulige løsninger på utfordringer vi hadde. 11 Scrum er en smidig utviklingsmetodikk som i hovedsak brukes for å utvikle informasjonssystemer. 12 En sprint er et bestemt tidsaspekt, vanligvis mellom 1-4 uker. 13 Product backlog er en liste over all funksjonalitet som skal utvikles. 14 Sprint backlog er en liste over all funksjonalitet som skal utvikles i en bestemt sprint. 49

51 9.2 Utviklingsverktøy I denne delen tar vi for oss verktøyene vi har benyttet til planlegging, prosjektstyring og utvikling Android Studio Android Studio har blitt brukt for å utvikle applikasjonen. Programmet har WYSIWYG 15 -editor, som vil si at man umiddelbart kan se resultatet fra utvikling av brukergrensesnittet. Kodefeil blir markert og det tilbys syntaksfremheving. Lint, som tilbyr verktøy for å optimalisere ytelse, brukervennlighet, versjonskompabilitet og unngå andre problemer, er innebygget Redmine For å holde styr på arbeidsutviklingen har vi benyttet Redmine som prosjektstyringsverktøy. Redmine har funksjoner som veikart, kalender og dokumentoversikt. Redmine har blitt brukt daglig, og har vært til stor hjelp for oss gjennom hele prosjektperioden. Vi mener at dette har bidratt til en effektiv arbeidsrutine i hovedprosjektet. Redmine er satt opp på en server hjemme hos en av prosjektdeltakerne. Programmet er brukt til å logge tid, holde oversikt over hvilken funksjonalitet som mangler, og hvem som har ansvaret for ulike arbeidsoppgaver. Oppgaver blir tilordnet ulike milepæler, som det kan genereres et gantt-diagram fra. Dermed har det vært lett å holde oversikt over fremgangen i prosjektet Git Git er brukt som versjonskontrollsystem. Git tar vare på all historikk, slik at det er enkelt å gå tilbake til tidligere versjoner. Et Git-tillegg er installert på Redmine-serveren, slik at man kan se all kildekode direkte fra prosjektstyringsverktøyet. Man har også mulighet til å lukke saker i Redmine direkte fra Android Studio via Git Draw.io For å designe databasemodellen har vi benyttet draw.io. Dette er et modelleringsverktøy som gjør det enkelt å opprette databasemodeller, slik at vi har fått oversikt over hva som skal lages. Verktøyet er brukt hver gang vi har oppdatert databasemodellen i applikasjonen DB Browser for SQLite DB Browser for SQLite er brukt for å utforske databasen som brukes i applikasjonen. Programmet er nyttig ved feilsøking, fordi man har mulighet til å se all informasjon som er lagret i databasen. 15 What You See Is What You Get. 50

52 9.2.6 Google Dokumenter Vi har benyttet oss av Google Dokumenter for at flere på gruppen kunne skrive på det samme dokumentet samtidig. Dette har bidratt til en effektiv arbeidsflyt der vi slapp å bekymre oss for å overskrive hverandres arbeid. Dokumentene blir automatisk lagret i Google sin lagringstjeneste Google Drive Dropbox Alle på gruppen har tidligere brukt Dropbox, og det falt derfor naturlig å bruke det som skylagringstjeneste. Ved å bruke Dropbox har vi hatt tilgang til felles kataloger og filer til enhver tid, både på PC og mobil. Dropbox regnes som en relativ trygg lagringsplass, men vi har likevel jevnlig tatt lokal backup av informasjonen Adobe Creative Cloud Adobe Creative Cloud er en pakke med ulik programvare som kan brukes for å utforme grafiske elementer og brukergrensesnitt. Vi benyttet Adobe Photoshop for å designe noen av de første digitale skissene. Photoshop er også brukt for å finne ut hvilke fargekombinasjoner som passer sammen. Adobe Illustrator ble brukt for å utvikle ikonene som brukes i applikasjonen Microsoft Powerpoint Powerpoint er brukt til å lage prototyper av applikasjonen vår. Programmet er et godt prototypingsverktøy fordi man kan gjøre sidene interaktive med hyperlenkefunksjonalitet Prosjektdagbok Vi har brukt en prosjektdagbok til å loggføre arbeidet vi har gjort i prosjektperioden. I denne har vi hver dag skrevet ned hva den enkelte har gjort. Viktige beskjeder og gjøremål ble lagt inn her. 9.3 Fra skisse til ferdig løsning I denne delen av dokumentasjonen tar vi for oss hvordan applikasjonen har utviklet seg, fra skisser til ferdig programmert løsning Idémyldring I idémyldringsfasen lette vi på nettet og i applikasjonsbutikker for å finne ut hvilke løsninger som allerede eksisterte. For å utvinne tanker og ideer til hvordan løsningen skulle være brukte vi et tankekart. All relevant informasjon ble skrevet opp, og dette dannet en basis for det videre arbeidet. Ved å samle alle tanker i et tankekart var det enkelt å omdanne disse til forslag til ulike utforminger. 51

53 FIGUR 48: TANKEKART SOM BLE LAGET TIDLIG I UTVIKLINGSPROSESSEN Utviklingsprosess for ukesmodus Vi skisserte mange ulike alternativer for å finne den beste løsningen for ukesmodus. I ukesmodus skal alle aktiviteter for en bestemt uke vises, og vi var derfor nødt til å finne ut hvordan vi kan utnytte plassen best mulig. Vi startet å skissere på et stort whiteboard for at alle på gruppen skulle kunne tegne og komme med innspill samtidig. Poenget var å finne de beste løsningene for hvordan aktivitetene skulle organiseres, og det var uvesentlig hvordan designet ellers skulle være. I figur 49 vises de designutkastene vi ønsket å jobbe videre med. FIGUR 49: VISER NOEN UTKAST TIL OPPSETT. 52

54 FIGUR 50: VISER DEN FØRSTE LO-FI PROTOTYPEN VI UTVIKLET FOR UKESMODUS. Ideen vi var mest fornøyd med utviklet vi videre til en lo-fi prototype. Denne vises i figur 50. Poenget med å lage en prototype så tidlig i prosessen var for å finne ut om dette er en løsning som kan videreutvikles eller ikke. Prototypen ble laget ved at vi tegnet en ramme rundt hver ukedag, og plasserte ikoner med tilhørende tekst på innsiden. Ikonene ble funnet via Google bildesøk, og alle er lisensiert på en måte som gjør at vi har lov til å bruke de 16. Vi viste fram prototypen for oppdragsgiver, som mente vi var på rett spor. De synes det var litt vanskelig å si mye om løsningen fordi den var så uferdig, men de kunne se et potensiale i ideen. Selv om oppdragsgiver var positiv til vår første prototype, slo vi oss ikke til ro med dette. Samtidig som vi utviklet en digital prototype av papirprototypen, lagde vi også en annen variant. Vår første prototype hadde aktivitetene plassert under hverandre. Vi ønsket å prøve å ha aktivitetene etter hverandre i stedet, for å tydeliggjøre hvilken rekkefølge aktivitetene skal utføres i. Både den første prototypen og den nye varianten lagde vi digitale skisser av i Photoshop. Disse er vist i figur Ikonene er markert som «lov å bruke kommersielt, også i endret form». 53

55 FIGUR 51: TIL VENSTRE VISES EN DIGITAL VERSJON AV DEN FØRSTE PROTOTYPEN. TIL HØYRE ER AKTIVITETENE PLASSERT ETTER HVERANDRE FOR Å TYDELIGGJØRE HVILKEN REKKEFØLGE DE MÅ UTFØRES I. Vi mente at den første prototypen var mer oversiktlig enn å vise aktivitetene etter hverandre. I tillegg er brukeren vant med å se aktiviteter under hverandre, så vi valgte å fokusere på den første prototypen. Vi laget en digital prototype av papir-prototypen i PowerPoint. Her fokuserte vi på å skape et harmonisk design som var fint å se på. For å tydeliggjøre hvilken dag det er i dag, brukte vi en stor toppmeny som buer ned mot «i dag». Denne prototypen brukertestet vi på oppdragsgiver. De var svært fornøyd med løsningen, så vi valgte derfor å forkaste alle andre alternativer. FIGUR 52: VISER UKESMODUS I APPLIKASJONEN. Den nye prototypen satset vi fullt på, og valgte derfor å programmere den i Android Studio. Vi beholdt det samme designet, men gjorde noen mindre justeringer. Blant annet fjernet vi den blå buen, da den tok veldig stor plass. I stedet viser vi hvilken dag det er ved hjelp av en blåfarge bak «i dag». Av andre merkbare endringer er plassbruken effektivisert ved at tomrom er fjernet. I tillegg er det lagt til muligheter for å navigere mellom uker og en nøkkel for å logge inn i administratormodus. 54

56 9.3.3 Utviklingsprosess for dagsmodus FIGUR 53: VISER FIRE ULIKE SKISSER FOR DAGSMODUS. I dagsmodus har vi forsøkt mange forskjellige måter å vise aktiviteter på. Fire av alternativene er vist i figur 53. Gjennomgående for alle variantene er at sjekklisten får større plass enn hovedaktiviteten. Av ulikheter er det verdt å merke seg skissen øverst til høyre. Vi forsøkte å plassere listen over aktiviteter for en bestemt dag på toppen av skjermbildet. Tanken bak dette er at det ligner på en slags «kø-ordning», der de første aktivitetene må gjennomføres før de som kommer senere i listen. Dette ble ikke tatt med videre, da vi ønsket å ha plass øverst for å implementere tilleggsfunksjonalitet. Vi ønsket å planlegge frem i tid, og da ville det være dumt å bruke toppmenyen til dette. Ved å holde toppmenyen ren beholder vi en grunnstruktur det er lett å bygge videre på senere. I skissen nederst til venstre prøvde vi å plassere listen over aktiviteter i midten av skjermbildet. Dette var uheldig fordi det skapte et skille mellom hovedaktiviteten og delaktiviteter. Det er viktig å tydeliggjøre for brukeren at delaktivitetene henger sammen med hovedaktiviteten. Nederst til høyre vises designet vi brukte videre. Den har en ryddig struktur der delaktivitetene er plassert nærme hovedaktiviteten. I tillegg har den stor plass til tilleggsfunksjonalitet i toppmenyen. 55

57 FIGUR 54: VISER POWERPOINT-PROTOTYPE TIL VENSTRE, FERDIG APPLIKASJON TIL HØYRE. Designet vi foretrakk ble opprettet i Android Studio. Gjennom brukertesting og samtaler med oppdragsgiver kom vi fram til designet som vises til høyre i figur 54. Blant annet er det lagt til en handlingskjede i stedet for sjekkliste. Knapper for å fullføre/fjerne fullført er lagt til. Det er også funksjonalitet for å bytte uke og ringe etter hjelp fra applikasjonen. Designmessig er hovedforskjellen at innholdet har fått større plass, blant annet ved at den store bakgrunnen fra prototypen er erstattet med innhold. I prototypen er det et tydelig skille mellom hoved- og delaktiviteter, mens de i den ferdige løsningen er knyttet nærmere til hverandre. Den store tilbakeknappen ble også erstattet med et mindre «hjem»-ikon. Tidsrepresentasjon Oppdragsgiver ønsket ikke at applikasjonen skulle basere seg på tid. Likevel kan det være nyttig for brukeren å vite om en aktivitet skal utføres på morgenen, midt på dagen eller på kvelden. Vi prøvde derfor ulike måter å representere tid på uten at man trenger å forholde seg til tid. De fleste variantene inneholdt en pil som beveget seg fra topp til bunn, avhengig av når på døgnet man ser den. Vi forsøkte også å bruke sol og måne. FIGUR 55: SKISSEN VISER TIDSREPRESENTASJON HELT TIL VENSTRE. 56

58 Tidsrepresentasjon krever at brukerne må utføre en aktivitet på en bestemt tid på døgnet. Oppdragsgiver var usikker på om dette vil være til hjelp eller kun være støy for brukerne, og vi jobbet derfor ikke videre med denne ideen. Likevel mener vi at tidsrepresentasjon kan være nyttig for enkelte brukere, og ser for oss at dette bør være med i en ferdig løsning. Ved å gi brukeren et hint om når en aktivitet skal utføres, kan det være lettere å planlegge dagen. Man kan da enkelt se hvilke tider man ikke har noen bestemte gjøremål. Vi ser for oss at tidsrepresentasjon kan innføres som et frivillig tillegg som skrus på ved behov. Det forutsetter at funksjonen utvikles på en slik måte at den passer naturlig inn i applikasjonen og ikke tar opp for stor plass. FIGUR 56: ULIKE FORSLAG FOR TIDSREPRESENTASJON Utviklingsprosess for administrasjonsmodus Oppdragsgiver hadde i utgangspunktet få meninger om hvordan forsiden skal være i adminmodus. Det eneste kravet var at det må finnes en hensiktsmessig måte å administrere brukerens plan på. En av våre første skisser av adminforsiden inneholdt en oversikt over de viktigste funksjonene i toppen og en månedsoversikt under. Til venstre hadde vi en meldingsboks, der hensikten var å lagre FIGUR 57: ADMINMODUS MED MENY PÅ VENSTRE SIDE. FIGUR 58: ADMINMODUS MED LINKER TIL MEST BRUKTE HANDLINGER ØVERST. 57

59 meldinger fra bistandsytere til andre bistandsytere. Dette utkastet vises i figur 57. Tanken bak denne skissen var å skape et kontrollpanel der alle tilgjengelige funksjoner vises. Ulempen var at det ikke er noen meny her. Det gjør at man er nødt til å gå tilbake til kontrollpanelet mellom hver funksjon som skal brukes. Derfor la vi til en meny på venstre side og flyttet «beskjeder» nederst på siden. Dette vises i figur 58. Menyen gjør det mulig å navigere til alle de ulike sidene i adminmodus. I tillegg er de mest brukte alternativene flyttet til toppen for enkel tilgang. Månedsoversikten er flyttet fra forsiden til menyalternativet «Planlegg». I den videre utviklingen bestemte vi oss for å flytte månedsoversikten tilbake til forsiden. Kravet fra oppdragsgiver var at det skal være lett å administrere aktivitetene, og vi mente derfor det var riktig å rydde bort meldinger og andre funksjoner fra forsiden. Meldinger tok vi ikke med videre i utviklingen. Både oppdragsgiver og vi mente det var en flott funksjon, men at det ikke har høy prioritet med det første. På den nye forsiden fylles mesteparten av plassen opp med en oversikt over aktiviteter for en bestemt tidsperiode. Man har mulighet for å velge om man vil vise aktiviteter for en dag, en uke eller en måned. FIGUR 59: OVERSIKT OVER EN BESTEMT MÅNED I ADMINMODUS. Vi valgte å bruke figur 59 som utgangspunkt for å lage en digital skisse. Den første digitale skissen vises i figur 60. Vi valgte å kun lage en ukesoversikt for enkelthetens skyld. I dagsmodus brukes ukesoversikt, og vi vurderer det som hensiktsmessig at man kan se gjøremålene på samme måte som i dagsmodus. Månedsoversikten er ikke tatt med videre i utviklingen fordi vi har fokusert på at ukesoversikten skal være best mulig. Likevel mener vi at månedsvisning bør implementeres på et 58

60 senere tidspunkt, da den gir administratoren bedre oversikt og gjør det lettere å planlegge aktiviteter lenger frem i tid. I skissen brukes store piler for å navigere mellom ulike uker. FIGUR 60: EN AV DE FØRSTE DIGITALE SKISSENE FOR ADMINMODUS. FIGUR 61: SKISSE DER UNØDVENDIGE MELLOMROM ER FJERNET. Under ukesoversikten innførte vi to nye knapper; «Hent mal» og «Lagre uke som mal». Dette ble lagt til for å forenkle vedlikehold av dagsplanen. Det er meningen at man skal kunne lagre hele uker som maler, slik at man enkelt kan lage identiske ukeplaner. Da slipper bistandsytere å sette opp aktiviteter som er like hver eneste uke, og kan fokusere på å tilpasse den enkelte uken. Figur 61 er en videreutvikling av figur 60. Her utnyttes plassen bedre ved at ukesvisningen går helt ut i kantene. Pilene for å navigere mellom ukene er fjernet, fordi de tok opp for stor plass. Menyen er gjort firkantet for å gi et mer seriøst uttrykk. Ukemaler FIGUR 62: UKEMALER KAN EFFEKTIVISERE VEDLIKEHOLD AV DAGSPLANEN. Skissene som inneholdt maler i adminmodus (figur 60 og 61) ble vist til oppdragsgiver. De var svært positive til løsningen, da det er et viktig mål med applikasjonen at bistandstid skal brukes bedre. Ved å frigjøre tid fra vedlikehold av dagsplaner kan mer tid brukes på sosiale aktiviteter. Vi jobbet derfor videre med ideen om maler. Figur 62 viser hvordan vi så for oss at maler kan implementeres. Man kan hente en bestemt aktivitet, en hel dag eller en uke. Maler er ikke implementert i den digitale løsningen enda, men det er et viktig tillegg som må på plass for at administrasjonsdelen skal være effektiv. 59

61 Endre plan Oppdragsgiver ønsker at det skal være enkelt og effektivt å legge til gjøremål. I en tidlig skisse for opprettelse av aktiviteter satt vi opp en side med de ulike elementene vi ønsket å ha med. Dette ukastet vises i figur 63. Med denne skissen prøvde vi å finne ut hvordan de ulike funksjonene kunne plasseres og vises på en hensiktsmessig måte. Oppsettet vi kom fram til virket FIGUR 63: SKISSE FOR Å ENDRE/LEGGE TIL AKTIVITET. rotete fordi det var for mange elementer og de virket tilfeldig plassert. Derfor valgte vi å fjerne de som ikke skulle utvikles i prosjektperioden, og heller fokusere på å forbedre de vi skulle ha med videre. Tankene bak hakene var at de skulle indikere om hjelpebetingelser som sjekkliste, handlingskjede og nedteller var lagt til i oppgaven. Endringene vi gjorde resulterte i skissen vist i figur 64. FIGUR 64: FJERNER ELEMENTER FRA FORRIGE DESIGN. Endringene frigjorde mye plass og ga oss mulighet til å eksperimentere mer med plasseringen. Det var først meningen at hver hjelpebetingelse skulle lages i et eget pop-up-vindu, men vi fant senere ut at dette var unødvendig og ga for mange tilleggssider. Vi gikk derfor bort i fra det og begynte å tenke på om det var mulig at alt opprettes på samme side. Figur 65 viser hvordan vi løste det. Skissen viser hvordan vi valgte å plassere elementene. Det ga mye plass på høyresiden, og vi valgte derfor at sjekklister og handlingskjeder skulle opprettes der. I tillegg la vi til en tekstboks for beskrivelse av aktiviteter og en bryter for å skru av og på nedtelleren. Figur 66 viser hvordan siden ser ut i applikasjonen. FIGUR 65: VIDEREUTVIKLING AV FIGUR

62 FIGUR 66: VISER HVORDAN DEN ENDELIGE «LEGG TIL AKTIVITET»-SIDEN SER UT Utvikling av logo Det har vært viktig for oss å ha en logo som gjenspeiler produktet vårt. Vi har derfor brukt en del tid på å utvikle en logo vi mener står i stil til løsningen vi har utviklet. Logoen er viktig for at brukere skal finne applikasjonen vår blant titalls andre apper som gjerne ligger lagret på et nettbrett. FIGUR 67: VISER NOEN AV PAPIRSKISSENE FOR LOGO. 61

63 I startfasen ville vi få med så mange elementer vi klarte for å vise hva Digitus representerer. De viktigste aspektene vi ville logoen skulle få frem var at produktet vårt var både en kalender og en planlegger. Navnet på produktet mente vi også det var viktig å få frem. I figur 67 vises noen av papirskissene vi lagde. Vi var veldig opptatt av å få frem at man «setter sammen sin egen hverdag». Dette prøvde vi å representere ved å bruke sammenkoblede puslespillbiter. Som vist i figur 68 inneholder logoene det meste av det vi ønsket å få med. Likevel var vi ikke fornøyde med logoene. Selv om de hadde alle elementene vi ville ha med, gjenspeilet de ikke produktet vårt, og vi skjønte derfor at vi måtte tenke annerledes. Vi forsøkte å overføre tankegangen vi hadde fra utviklingsprosessen med løsningen vår ved å forenkle. I applikasjonen starten vi med å ta med mest mulig, men gjennom arbeidsprosessen la vi mer vekt på enkelthet. FIGUR 68: FIRE FORSKJELLIGE DIGITALE LOGOER BLE TESTET UT. Vi bestemte oss derfor for å starte på nytt, og begynte igjen på skissestadiet. Vi ville fortsatt ha med navnet vårt i logoen og tok derfor utgangspunkt i det. Vi ønsket at logoen skulle være så enkel som mulig, derfor forenklet vi den kraftig. I figur 69 vises de nye logoene. FIGUR 69: FIRE NYE LOGOFORSLAG SOM ER KRAFTIG FORENKLET. Det ligger mye mer arbeid i utviklingen enn det som vises her, men man kan se hvordan vi endret formen på logoen og la på en hake over den siste i-en. Denne haken er vår måte å representere at en aktivitet er fullført i løsningen vår. Meningen er kanskje litt dyp, men den viser på en enkel designmessig måte at produktet vårt handler om å fullføre noe. 62

64 Det neste stadiet var å finjustere logoen og finne riktig fargekombinasjon. Under kan man se noen av utkastene fra utviklingen. FIGUR 70: VISER ULIKE FARGEVARIANTER LOGOEN BLE TESTET MED. Haken vi brukte over i-en følte vi kunne minne litt om en pipe, derfor gjorde vi den spissere. Ved å gjøre den spissere mener vi den blir mer estetisk riktig for løsningen vår, selv om det finnes «fullført»-haker i alle slags former. Fargene var vanskelig å bestemme, og vi prøvde ut mye forskjellig. Til slutt gikk vi for den hvite, som er den enkleste. I figur 71 kan man se forsiden på et Android-nettbrett. I forhold til de andre logoene synes vi ikke at vår skiller seg nevneverdig ut. Siden enkelhet var målet vårt føler vi at vi har klart å lage en logo som er enkel og i tillegg representerer løsningen vår på en god måte. Under logoen har vi lagt inn en tekst som beskriver hva applikasjonen er slik at man ikke kan ta feil. FIGUR 71: VISER DIGITUS-LOGOEN SAMMEN MED ANDRE ANDROID- APPLIKASJONER. Prosessen vi hadde gjennom logoene kan sies å oppsummere store deler av resten av utviklingsprosessen; vi har hele tiden forsøkt å forenkle så mye som mulig. 63

65 9.4 CareWare 2015 Onsdag deltok hele gruppen på en velferdskonferanse kalt CareWare i Aarhus i Danmark. CareWare har som hensikt å koble velferd sammen med teknologi. Både de som har bruk for hjelp og de som skal hjelpe er med på å utvikle de velferdsteknologiske løsningene. På denne måten får alle brukerne tatt del i utviklingsprosessen og sjansen for at løsningen vil kunne brukes økes betraktelig. Under beskrives innholdet og hva vi fikk ut av konferansen. FIGUR 72: CAREWARE 2015 HER VISES PRISUTDELINGEN I MUSIKKHUSET I AARHUS. Hovedgrunnen til at vi ville dra på konferansen var at våre og CareWare s mål og tankemåte er veldig like. På hjemmesiden til CareWare står det blant annet: «Velferdsteknologi gir først mening når mennesket og velferden kommer før teknologien. Når teknologiske redskaper blir ufarlige og ukompliserte hjelpemidler som blir brukt på en måte som gir frihet og overskudd. Når det gagner mennesker som har bruk for teknologi for å trygt kunne klare hverdagen i hjemmet sitt selv. Og når teknologien skaper et bedre arbeidsmiljø og mer tid til omsorg for de mennesker som arbeider med velferdsteknologi. Derfor setter CareWare mennesket først». Første del av konferansen bestod av foredrag fra initiativtakeren og litt om bakgrunnen til CareWare. Andre del bestod av «stands» hvor 16 forskjellige løsninger ble presentert. Alle deltagerne ble delt opp i grupper med en guide som viste oss rundt. Åtte av presentasjonene hadde fokus på teknologi til pleie og omsorg av mennesker i pleieboliger og eldre mennesker på sykehus. De åtte andre hadde 64

66 fokus på teknologi for økt livskvalitet og selvhjelp for mennesker med fysisk, psykisk, sosial og/eller kognitiv funksjonsnedsettelse. Det var det siste fokusområde som var mest relevant for oss, men det var uansett svært spennende å få med seg begge. De som presenterte produktet sitt fikk ti minutter hver på å vise frem hva de hadde. Etter her fjerde presentasjon fikk vi en pause hvor vi kunne gå tilbake til stands vi hadde vært tidligere. Da benyttet vi anledningen til å prate med utviklerne av både careplan og MemoAssist. Begge disse applikasjonene er beskrevet i «Løsninger på markedet i dag» i denne rapporten. Tredje del fant sted i musikkhuset i Aarhus. Her ble det holdt flere foredrag, blant annet om hvordan innovasjon skal kunne bli en suksess. Ordføreren i Aarhus sa også noen ord om hvor viktig velferdsteknologi er og hvor stolt han var over konferansen og dens utvikling. Til slutt ble det delt ut premier for de beste ideene. Siste del var middag med nettverksbygging. Dette var en viktig del av agendaen, da vi fikk vist fram og diskutert løsninger på utfordringer vi har hatt. FIGUR 73: FRA VENSTRE: GLORIA MUNDI CARE JDOME BIKEAROUND, HART DESIGNS HUSKETAVLEN OG E- MERGENCY CAREPLAN. Vi lærte veldig mye om hvordan mennesker tenker annerledes på og så også viktigheten av hjelpemiddelteknologi for mennesker som virkelig trenger det. Vi fikk god utbytte av konferansen, både i form av styrket samarbeid i gruppen og økt motivasjon. Det var svært motiverende å se hva andre har laget og å høre om hvor mye de ulike løsningene hjelper sine målgrupper. 65

67 10 Universell utforming og interaksjon En universelt utformet løsning skal kunne nå ut til alle målgrupper uavhengig av kunnskapsnivå og funksjonsnedsettelser. For å sikre universell utforming er det viktig med god planlegging. Man må ha klarhet i hvordan applikasjonen skal brukes og hvilke aspekter ved brukervennlighet som er viktig. Alle mennesker er ulike, og det er derfor ingen fasit for hvordan en teknologisk løsning skal være. Det finnes derimot retningslinjer og prinsipper man kan følge for å utvikle et best mulig produkt. Vi har som mål at Digitus skal være enkel og intuitiv å ta i bruk. Det skal ikke være nødvendig med lang erfaring, kunnskaper, språkferdigheter eller et høyt konsentrasjonsnivå for å bruke applikasjonen. Vi har brukt GAP- modellen for å inspirere oss i utviklingen av løsningen. En funksjonshemning defineres som gapet mellom forutsetninger og krav (Sandnes, 2014, s. 24). Den nordiske GAPmodellen måler graden av funksjonshemming ut fra den enkeltes fysiske forutsetninger, og hva samfunnet bidrar med for å tilrettelegge for de ulike fysiske utgangspunktene (Grue, 2011, s. 14). Modellen har som hensikt å nedbygge funksjonshemmende barrierer gjennom tilrettelegging, slik at avviket mellom individets forutsetninger og samfunnets krav reduseres. Dette kan gjøres ved å forbedre omgivelsene til individet, blant annet gjennom universell utforming av teknologiske hjelpemidler. FIGUR 74: ILLUSTRASJON AV DEN NORDISKE «GAP-MODELLEN» 17. Videre i kapittelet vil vi forklare hvilket arbeid som er utført for å sikre universell utforming av dagsplanen, og dermed også minsket gapet som oppstår. 17 Illustrasjon fra Arbeids- og inkluderingsdepartementet ( Gjengitt med tillatelse. 66

68 10.1 WCAG 2.0 WCAG er retningslinjer for hvordan man gjør innhold tilgjengelig for mennesker uavhengig av funksjonsnedsettelser. Vi vil bruke noen av retningslinjene for å forbedre brukervennligheten til dagsplanen. WCAG består av fire hovedprinsipper som danner grunnlaget for tilgjengelighet. Selv om dette alene ikke vil sikre universell utforming, kan det gjøre dagsplanen mer tilgjengelig. Under gjennomgås noen eksempler på hva som er gjort for å oppfylle kravene. For at innholdet skal være mulig å oppfatte har vi tekstalternativer til ikke-tekstlig innhold. For å gjøre innholdet forståelig har vi brukt korte, konsise setninger og unngått fagterminologi. Alle steder der det kreves inndata fra brukeren er det brukt tydelige ledetekster som forteller hva som skal skrives inn. Alle handlinger er reversible slik at det er lett å rette opp feil. Applikasjonen er robust ved at den har støtte for kompenserende teknologi, blant annet skjermleser. Mulig å betjene løser vi ved at man kan bruke både trykking, sveiping og tastatur Brukervennlighet God brukervennlighet er viktig for at brukerne kan bruke dagsplanen. Da vi utformet designet i applikasjonen tok vi hensyn til flere av Don Normans designprinsipper (Preece, Rogers & Sharp, 2002, s. 21). Norman er en anerkjent forsker på brukervennlighet og prinsippene hans blir ofte brukt under utviklingen av design, til tross for at de ble skrevet for over 20 år siden. Under gjennomgås de prinsippene som er mest relevant for Digitus; tilbydelser, tilbakemeldinger, ugyldige handlinger og synlighet Tilbydelser Vi har brukt virtuelle tilbydelser for å hjelpe brukeren til å vite hvordan man utfører handlinger i applikasjonen. I dagsplanen har vi blant annet brukt store knapper som innbyr til trykking, som vist i figur 75. Grensesnittet gir et hint om hva som kan trykkes på, slik at man ikke trenger noen instruksjoner eller opplæring for å skjønne hvordan de brukes. Knappene er tydeliggjort ved gradering av farger og tillagte 3D-effekter. Om man trykker på knappen oppfører den seg som en fysisk knapp ved at den «blir dyttet innover». FIGUR 75: FERDIG-KNAPPEN INNBYR TIL TRYKKING GJENNOM TILLAGTE 3D-EFFEKTER Tilbakemeldinger En tilbakemelding er informasjon som blir gitt til brukeren etter en handling er utført. Tilbakemeldinger kan fungere som en komplettering av tilbydelsene, og kan formidles både visuelt og auditivt. Dersom man ikke registrerer noen umiddelbare konsekvenser av en handling vil vi anta at 18 Web Content Accessibility Guidelines 2.0, forkortet WCAG

69 noe er galt. Smertegrensen for å få tilbakemelding på en utført handlinger er ifølge Bouch, Kuchinsky og Bhatti (2000) åtte sekunder. På grunn av den teknologiske utviklingen de siste 15 årene er nok dette betydelig redusert i dag. FIGUR 77: FULLFØRTE AKTIVITETER BLIR TONET NED, NOE SOM GIR EN TYDELIG TILBAKEMELDING OM AT DE ER FULLFØRT. FIGUR 76: BRUKEREN FÅR UMIDDELBART TILBAKEMELDING OM INFORMASJONEN SOM ER SKREVET INN ER GODKJENT. Når brukeren utfører handlinger i applikasjonen er det viktig at vedkommende raskt kan se endring i tilstanden. Dette vil spare brukeren for tid og man unngår unødvendig frustrasjon. Digitus bruker «grå haker» for å indikerer at et steg er utført, også kalt framdriftsindikatorer. Dette kan man se i figur 76. Ved opprettelse eller endring av brukere blir tekstfeltene validert. Dersom informasjonen er godkjent, gir brukergrensesnittet umiddelbart tilbakemelding i form av en grønn hake. Brukeren får da en bekreftelse på om det er handlet riktig Metaforer Ideen bak metaforer i brukergrensesnitt er at man utnytter et konsept brukeren allerede er kjent med, og overfører dette til en ny situasjon. Dette kan i enkelte situasjoner lette forståelsen og redusere kompleksitet (Sandnes, 2011, s. 54). Metaforer som er brukt i Digitus er blant annet piler, start- og stopptegnet på nedtelleren og kameraikonet. Dette lar brukerne benytte tidligere erfaringer for å lettere forstå brukergrensesnittet. FIGUR 78: ET KAMERA BRUKES SOM METAFOR FOR Å TA BILDE. 68

70 Synlighet Synlighet er en viktig faktor for god oversikt. Et godt utformet brukergrensesnitt vil kunne synliggjøre for brukeren alle handlingene som kan utføres. På de viktigste funksjonene har dagsplanen gjennomgående store knapper og alle trykkbare flater er tydelig markert. Dette gir brukeren bedre oversikt og minsker behovet for opplæring. FIGUR 79: ALLE TILGJENGELIGE MENYALTERNATIVER VISES TYDELIG Sperring av ugyldige handlinger Ugyldige handlinger kan skape forvirring og bør ikke tilbys. Alle aktiviteter i dagsmodus har likt grensesnitt, og det kan være forvirrende for brukeren om designet endres. Derfor er irrelevante komponenter grået ut istedenfor å fjerne dem helt. FIGUR 80: UGYLDIGE HANDLINGER BLIR SPERRET, SOM VIST TIL VENSTRE I FIGUREN Lyd Lyd kan være helt avgjørende for at enkelte mennesker kan bruke dagsplanen. Dette gjelder for eksempel personer med nedsatt syn eller de som har dysleksi. Skjermlesere er den vanligste kompenserende teknologien basert på lyd. Denne har til oppgave å tolke innholdet som vises på skjermen, og formidle dette til brukeren gjennom syntetisk tale eller punktskrift. Android har en innebygd skjermleser som kan lese opp både på norsk og engelsk. Ifølge Sandnes (2011, s.129) går prosessering av lyd tregere enn visuell prosessering. Derfor brukes ikke lyd alene i dagsplanen. Lyd brukes for å signalisere at tiden har gått ut i nedtelleren, i tillegg til at hele nedtelleren blir grønn. Dermed kan man visuelt se om tiden har gått ut, selv om man ikke oppfatter lydsignalet Visuell kommunikasjon (Design) Den visuelle utformingen avgjør om et grensesnitt er godt eller dårlig. For å unngå støy er det lagt vekt på enkelhet og god struktur. I dette kapittelet gjennomgås hva som er gjort for å oppnå best mulig visuell kommunikasjon i dagsplanen. 69

71 Gestaltlovene Gestaltlovene omhandler hvordan mennesker oppfatter helhetlige visuelle inntrykk. For å gi en best mulig visuell formidling til brukerne har vi valgt å legge vekt på de gestaltlovene som er spesielt nyttig for design Forgrunn og bakgrunn Vi har prøvd å skape et klart skille mellom forgrunn og bakgrunn ved å bruke større arealer som bakgrunn og mindre arealer som forgrunn. Dette gir mer dybde i skjermen og gjør innholdet mer «levende». Dette gjør også at vi unngår tvetydighet i brukergrensesnittet. Et eksempel på dette vises i figur 81. FIGUR 81: DET ER ET KLART SKILLE MELLOM FORGRUNN OG BAKGRUNN Nærhet For å skape nærhet i brukergrensesnittet er overskrifter og tilhørende tekst/bilder plassert sammen. Dermed dannes grupperinger som gjør det lettere for brukeren å skille elementer. Mellom de ulike grupperingsblokkene er det brukt større distanse slik at de ikke blandes. Siden alle aktiviteter under hver dag er plassert nærme hverandre, skaper de en gruppering. I tillegg er aktivitetene rammet inn med en tynn, grå kant. Dette tydeliggjør hvilke aktiviteter som skal gjøres de ulike dagene. FIGUR 83: NÆRHET SKAPER GRUPPERINGER. FIGUR 82: GRÅ KANTER BRUKES SOM INNRAMMING. 70

72 Kontinuitet Ved å følge kontinuitetsloven fremheves strukturen i den visuelle fremstillingen (Sandnes, 2011 s. 74). Aktivitetene i dagsplanen er plassert rett under hverandre, noe som skaper «usynlige linjer» på hver side av aktiviteten. Ved å plassere like store elementer rett under hverandre, vil brukeren oppfatte linjer selv om de ikke eksisterer. I applikasjonen utnyttes dette virkemiddelet for å skape et ryddigere grafisk design. I figur 84 vises de usynlige linjene. FIGUR 84: USYNLIGE LINJER ER MARKERT MED RØDT Form og det gylne snitt Det gylne snitt brukes for å designe estetiske former. Kort sagt handler det gylne snitt om å dele opp en linje i to deler, en lang og en kort. Ifølge Brady & Phillips (2003) er design som utnytter det gylne snitt behagelig å se på for øyet. Skillet mellom hovedaktiviteteten og delaktiviteter i dagsmodus ligger midt i det gylne snitt. Som vist i figur 85 får hovedaktiviteteten nøyaktig dobbelt så stor plass som delaktivitetene. FIGUR 85: SKILLET MELLOM AKTIVITET OG DELHANDLINGER LIGGER MIDT I DET GYLNE SNITT. 71

73 Innenfor hovedaktiviteteten benyttes det gylne snitt for knappene. Ulike farger har ulik vekt. Ifølge Niki Fulton 19 oppleves rødt som en tyngre farge enn grønt. For å oppnå likevekt er derfor den grønne knappen dobbelt så stor som den røde. Ferdig-knappen er den som fører brukeren videre, og er den som brukes mest. Derfor er det naturlig at den er størst. I tillegg er den plassert midt i det gylne snitt på høyre side. Det gylne snitt blir ofte lagt raskt merke til, og det er derfor viktig å plassere essensiell informasjon her. Et utklipp av knappene vises i figur 86. FIGUR 86: DEN GRØNNE KNAPPEN ER PLASSERT MIDT I DET GYLNE SNITT Likhet Det er brukt likhet for å vise at elementer hører til i samme gruppe. Knapper og bokser har samme form, og dette tydeliggjør at de er relaterte. Selv om teksten er ulik får applikasjonen en tydelig struktur. Elementene har faste plasser på ulike sider, og sammen med nærhet gjør dette at dagsplanen oppleves ryddigere. Brukerne får dermed raskere oversikt. FIGUR 87: ALLE KNAPPER FOR UKEDAGER HAR LIKT DESIGN FOR Å VISE AT DE ER RELATERT. UNNTAKET ER «MANDAG», SOM HAR EN ANNEN FARGE. FARGEN SIGNALISERER AT DET ER MANDAG I DAG Tilordninger En tilordning beskriver forholdet mellom en kontroll og det kontrollen styrer. Et eksempel på en tilordning som brukes i dagliglivet er lysbryteren (Sandnes, 2011: 79). Det er viktig at tilordningen samsvarer med brukerens forventninger, ellers kan det bli forvirrende. FIGUR 88: KAMERAIKONET ER EN DIREKTE TILORDNING SOM KONTROLLERER KAMERAET. Direkte tilordninger er plassert i umiddelbar nærhet til det kontrollen styrer. Dette er intuitivt for brukeren ved at det fjerner all tvil om hva tilordningen styrer. Dette benyttes i hjelpelisten, der det er tydelig at kameraikonet er en direkte tilordning til «ta bilde»- funksjonen

74 Tekst og lesbarhet For å bedre tekst og lesbarhet brukes marg og økt avstand mellom bokstavene. Viktig tekst, for eksempel overskrifter, er venstrestilt. Små bokstaver er konsekvent brukt, siden de er mer lesbare enn store. Dette er fordi de har forskjellig høyde og det er dermed lettere å kjenne igjen ordene. Teksttypen som brukes i dagsplanen er «Roboto Regular». Den er standard for Android, ser moderne ut og er laget spesielt for å oppfylle kravene til skjermer med høy oppløsning. Tekststørrelsen i applikasjonen er mellom 12 og 40 sp 20. Skiftstørrelsen kan justeres i Android-innstilingene. Teksttypen er sans-serif 21 og halvfet, noe som gir god lesbarhet på skjermer. Teksten er kvalitetssikret i en kontrastsjekker. Mer informasjon om dette finnes under «Fargekontraster» i denne rapporten. Fordi teksten skalerer på en god måte, er den godt tilpasset for mobile enheter. Vi har testet applikasjonen på nettbrett med skjermstørrelser mellom 8-12, og kan derfor si med sikkerhet at den passer til både middels og store mobile enheter Navngivning Navngivning blir brukt for å beskrive informasjonsblokker og navigering i applikasjonen. Det finnes to måter å navngi på; tekstlig og ikonisk. Tekstlig er den den mest brukte formen. Mennesker oppfatter ikoner hurtigere enn tekst fordi vi lettere relaterer oss til bilder (Carney & Levin, 2002). På grunn av dette har det blitt vanlig å bruke ikoner som et supplement til tekst. Tekstlig navngiving Tekstlig navngivning kan være vanskelig siden man blant annet må ta hensyn til synonymer og homonymer. For å gjøre navngivningen så enkel som mulig har oppdragsgiver bistått i valg av navngivningstekster. God navngivning vil effektiviserer navigeringen og få applikasjonen til å se mer ryddig ut. Det er derfor viktig at navngivningen representerer det den beskriver og er konsistent gjennom hele applikasjonen. Ved å navngi informasjonsblokkene som inneholder aktivitetene for en bestemt dag, er det ikke tvil om hvilke aktiviteter som skal utføres til hvilke dager. Dette kan gi brukeren en følelse av trygghet og kjennskap til dagsplanen. 20 Scale-independent Pixels (SP) brukes i Android for å sette tekststørrelse. Størrelsen justerer seg både etter skjermoppløsning og brukerinnstillinger for tekststørrelse. 21 Sans-serif betyr at teksttypen ikke bruker seriffer. 73

75 FIGUR 89: VISER NAVNGIVNING FOR UKEDAGENE. Ikonisk navngivning Ikoner kan gjøre det lettere for brukeren å forstå betydningen av navigasjonen. I tillegg tar ikoner ofte mindre plass enn tekst. I brukergrensesnittet til Android brukes ofte ikoner uten tekst, blant annet i kameraet. Ikonene i Digitus har lav kompleksitet, er unike og lett gjenkjennbare ved at de skiller seg ut med hvit farge. Det behøves derfor liten eller ingen opplæring for å forstå ikonene. Dagsplanen bruker få og enkle ikoner. Dette gjør det lettere for brukeren å ha kontroll på hensikten til ikonene. Ikonene er piktogrammer 22 som viser en visuell framstilling av de faktiske objektene. De følger konvensjoner på grafiske symboler som er allment kjent. Blant annet brukes et bilde av et hus for å representere «Gå til forsiden» i applikasjonen. FIGUR 90: ET HUS REPRESENTERER «GÅ TIL FORSIDEN» I APPLIKASJONEN Farger Bruk av farger kan gi brukeren visuell oversikt ved å tydeliggjøre informasjon i applikasjonen. Fargene i dagsplanen er satt sammen for å skape stabilitet og harmoni. Ved å benytte en monokromatisk 23 fargeharmoni blir det visuelle designet mer konservativt og behagelig å se på. Fargebruken i applikasjonen er begrenset. Det er anbefalt å bruke maks fire farger i ett skjermbilde, og ikke mer enn syv farger i brukergrensesnittet som helhet (Shneiderman & Plaisant, 2005, s. 511). Erfarne brukere kan ha nytte av flere farger, men for nybegynnere kan for mange farger skape forvirring. Derfor har brukergrensesnittet svært få farger, men man har mulighet til å skru på flere. Spesielt fargekoder for de ulike dagene innfører nye farger, og denne funksjonen er derfor kun tiltenkt brukere som allerede er vant med å bruke fargekoder fra analoge dagsplaner. Dersom alle tillegg er skrudd av, inneholder applikasjonen færre farger enn det anbefalte maksnivået. Under er det listet opp flere enn syv farger, men flesteparten er kun ulike fargenyanser av den samme fargen. 22 Pliktogram er et forenklet bilde som symboliserer et ord, en gjenstand eller et begrep. 23 En monokromatisk fargeharmoni bruker kun én farge for å oppnå maksimal effekt. Intensiteten og fargetonen kan varieres ved å tilsette sort eller hvit. 74

76 Fargene er delt opp i tre kategorier; farger for ukedager, basisfarger og knappefarger. Under vises alle farger som er brukt i dagsplanen. FIGUR 91: OVERSIKT OVER UKEDAGFARGER. Fargekoder brukes som color mapping, altså for å representere en bestemt dag. Fargene for de ulike ukedagene følger den norske standarden 24. Dette er spesielt nyttig for brukere som ikke kan lese, men det kan også hjelpe de som har gode leseferdigheter. Dersom man kjenner til hvilken farge hver ukedag har, er det svært raskt å se hvilken dag det er kun basert på fargen. I dagsmodus vises det hvor langt man har kommet i uken ved hjelp av fargene. FIGUR 92: OVERSIKT OVER BASISFARGER. Blå brukes som basisfarge med varierende metnings- og lyshetsgrad. Fargen kan ses av mennesker med fargeblindhet, og den gir en følelse av ro. Fargen symboliserer lojalitet, styrke, visdom og tillit. Blå benyttes ofte av virksomheter innenfor helsesektoren 25. For å skape et enkelt og ryddig design er det brukt få farger. FIGUR 93: OVERSIKT OVER KNAPPEFARGER. Knappene for å fullføre aktiviteter i dagsmodus bruker ikke standard Android-design. Det er svært viktig at disse knappene er tydelige for brukeren, og for at de skal skille seg ut brukes grønt og rødt. Grønt brukes for «Ferdig/Gå videre», rødt brukes for «Ikke ferdig/gå tilbake». Grunnen til dette er at vi er vant med disse fargene i hverdagen, blant annet fra trafikklys. Fargene finnes i tre nyanser, der 24 Ifølge Magnus Skou Andersen, utvikler av Husketavlen, er det forskjellige standarder for Norge, Sverige og Danmark

77 den lyseste brukes for å signalisere at knappen er deaktivert. Den midterste er normal farge for knappen, og den mørkeste brukes for å vise brukeren at knappen er «trykket». Fargeblindhet Fargeblindhet er en utbredt synshemning blant mennesker. Omtrent 7 % av alle menn og 0,5 % av alle kvinner har en eller annen form for fargeblindhet (Sandnes, 2011, s. 113). Med fargeblindhet oppleves mange farger annerledes, og forskjellen vil variere avhengig av farge og type fargeblindhet. Rød og grønn er brukt som knappefarger, og for å unngå misforståelser for fargeblinde har vi lagt ved en beskrivende tekst og gitt knappene forskjellig størrelse. I figur 94 kan man se et eksempel på hvordan applikasjonen vår blir seende ut for en person som er fargeblind. FIGUR 94: TIL HØYRE VISES HVORDAN DAGSPLANEN SER UT FOR EN SOM ER RØD/GRØNN-FARGEBLIND. Fargekontraster For å sikre at brukeren skal kunne skille mellom forskjellige elementer er det brukt tilstrekkelig kontrast i metning og lyshet. Fargene er kvalitetssikret i en «Color Blindness Simulator», som vises hvordan fargene oppleves for fargeblinde. Testen viste at lesbarheten skal være god selv for svaksynte. Lys/mørk-kontrast er brukt i forgrunns- og bakgrunnsfargene for å skape best mulig lesbarhet. FIGUR 95: ILLUSTRASJONEN VISER DE ULIKE FARGENE SOM ER BRUKT FOR TEKST OG BAKGRUNN. 76

78 Tabellen viser fargekoder (RGB heksadesimalt) 26 for bakgrunn og forgrunn. Kontrastratioen for fargene som er brukt i appen vises også. Nummer Bakgrunn Forgrunn Kontrastratio Tekst 1 # #ffffff 7.48 : 1 Tekst 2 #43bdfc # : 1 Tekst 3 #ffffff # : 1 Tekst 4 #1fd238 # : 1 Tekst 5 #f57b7f # : 1 Tekst 6 #d9d9d9 # : 1 Lov om universell utforming av IKT-løsninger 27 krever at tekst skal ha en fargekontrast mot bakgrunnen minst i samsvar med nivå AA i WCAG. For å oppnå det høyeste nivået i WCAG (AAA) kreves det at normal tekst har en kontrastratio på minst 7:1. Stor tekst krever 4.5:1. Som vist i tabellen over oppfyller all tekst i dagsplanen denne regelen. Det eneste unntaket er for knapper som er grået ut. Denne er på 5.98:1, noe som er rett under grensen for AAA normal tekst. Direktoratet for forvaltning og IKT mener dette kan være akseptabelt i gitte situasjoner 28, og vi vurderer det som greit at denne teksten kun oppfyller AA Kognitiv belastning Mange innenfor vår målgruppe kan ikke lese, og vil derfor ikke trenge tekstlig innhold i applikasjonen. I Digitus er dette noe administrator enkelt kan tilpasse etter brukerens behov, enten ved å fjerne eller skru på opplesning av tekst. Andre kognitive vansker som dårlig hukommelse, lav konsentrasjon og skrive- og lesevansker er viktige faktorer man må ta høyde for når man utformer brukergrensesnittet. Et dårlig utformet brukergrensesnitt kan i verste fall fungere som en barriere for brukerne. I denne delen vil vi forklare hva vi har gjort for å optimalisere brukergrensesnittet Minnekapasitet Mennesker har lettere for å kjenne igjen noe enn å hente det frem fra hukommelsen. Visuelle hint i et brukergrensesnitt kan redusere hukommelsesbelastningen for brukeren. Miller (1956) fant ut at unge voksne mennesker sitt korttidsminne i gjennomsnitt klarer å huske syv elementer på en gang. Dette kalles «7+-2»-regelen eller Millers lov. Ved å ha et lavt antall kategorier i applikasjonen vil det være enklere for brukeren oppfatte alle valgene man kan ta. Digitus inneholder alle dagene i en uke, 26 Fargekoder brukes for å kunne vise nøyaktig den samme fargen

79 noe som gir syv trykkbare kategorier. Venstremenyen i dagsmodus gir oversikt over mellom fire og fem aktiviteter. Dermed overholdes Millers lov Lese- og skrivevansker Mange mennesker sliter med lese- og skrivevansker. Vi har ikke noen klare tall om vår målgruppe, men på landsbasis er det rundt 10 % som opplever problemer med lesing og/eller skriving. En form for lese- og skrivevansker kalles dysleksi. Personer med dysleksi har ofte også nedsatt arbeidsminne, lav konsentrasjonsevne, nedsatt motorikk og sekvensieringsvansker 29. Fordi vi vet at disse symptomer også forekommer innenfor vår målgruppe, var dette et problem vi måtte ta alvorlig. For å bedre opplevelsen av brukergrensesnittet er informasjonsmengden begrenset. For mye informasjon kan gjøre at brukeren mister motet og gir opp. Bilder er brukt som hovedbeskrivelse, med tekst som supplement. Det er derfor ikke nødvendig å se på teksten for å forstå hva som skal gjøres. Bruk av lange ord er unngått, siden det kan være vanskelig å lese. FIGUR 96: BILDET HAR HOVEDFOKUS, MEN MAN HAR OGSÅ ET TEKSTLIG ALTERNATIV Toleranse for feil Brukergrensesnittet skal være utformet slik at faren for feil reduseres. Likevel hender det at brukeren gjør feil, og da er det viktig at det er mulig å angre utførte handlinger. Feiltoleranse er implementert på to forskjellige måter. Dersom en aktivitet markeres som «Ferdig», er det mulig å fjerne fullført-statusen. I adminmodus får man en advarsel dersom man prøver å forlate «Opprett aktivitet» uten å lagre. På den måten unngår man at brukeren ved en feiltagelse mister arbeid. FIGUR 97: FOR Å REDUSERE FAREN FOR AT BRUKEREN UTILSIKTET FORLATER UTEN Å LAGRE, MÅ BRUKEREN BEKREFTE HANDLINGEN. 29 Sekvensieringsvansker er at man har vanskelig for å vite rekkefølge for hvordan ting skal gjøres. Et eksempel på dette er å ta på seg skoene før buksen. 78

80 Organiseringsstruktur Applikasjonen har en hierarkisk top-down organiseringsstruktur 30. Ved å følge denne innordningen kan brukeren lettere danne seg en mental modell 31 av strukturen, og dermed øke forståelsen av applikasjonen. For at hierarkiet skal opprettholde sin verdi, er ikke informasjon lagret redundant 32. Ifølge Miller (1981) er det viktig at dybden i applikasjonen er så liten som mulig uten at det går utover bredden. Med mange nivåer kan det bli forvirrende og tungvint for brukerne. Ved å ikke ha for dypt hierarki, blir det kortere vei til viktig informasjon. Digitus har en god balanse mellom dybde og bredde i sin taksonomi, der mesteparten av innholdet kan nås gjennom 3-4 trykk. 30 Rangordning hvor den viktigste informasjonen kommer først. 31 En mental modell kan defineres som en forklaring på en persons tankeprosess rundt hvordan noe virker (Sandnes, 2011, s. 56). 32 Redundans kan være unødvendig dobbeltlagring. 79

81 11 Konklusjon Vi har alle ønsket å tilegne oss ny kunnskap og utfordre oss selv. Det har derfor vært et stort privilegium å få sjansen til å jobbe med noe så givende og lærerikt. Ved å kombinere teknologi med velferd fikk vi sjansen til å jobbe med to forskjellige fagområder, og det var derfor aldri noen tvil om at dette prosjektet var riktig for oss. Vi var så heldige å få brukertestet løsningen på den faktiske målgruppen vår, og her fikk vi mye positivt tilbake. Testpersonene ønsket å bruke den endelige løsningen, og dette har vært en stor motivasjonsfaktor for å gjøre dagsplanen best mulig. Samarbeidet i gruppa har vært godt. I prosessen har vi fått relativt frie tøyler, og har derfor vært veldig selvstendige i arbeidet vårt. Vi har hatt månedlige møter med oppdragsgiver og veileder, og kommunikasjonen mellom oss har vært bra. Alle har vært tilgjengelige når vi har trengt hjelp eller tilbakemeldinger. Vi har tilegnet oss mye ny kunnskap om applikasjonsutvikling, designutvikling og brukertesting. Dette vil komme godt med når vi skal ut i relevante jobber. Vi har også erfart at planlegging og dokumentasjon underveis er svært viktig i prosjekter av denne størrelsen. Skulle vi ha gjentatt prosessen ville vi derfor vært mer grundig med disse fasene. Oppdragsgiver var redd vi ikke skulle forstå hva slags løsning de ønsket, men dette fikk de bekreftet at vi gjorde allerede i oppstartsfasen av prosjektet. Dette var en lettelse for begge parter. Selv om vi ikke implementerte alle kravene til oppdragsgiver, var de veldig imponert over løsningen og positive til all tilleggsfunksjonalitet vi har utviklet. Siden vi har laget en funksjonell applikasjon, har vi gitt oppdragsgiver mye mer enn de forventet. Dette gjør at de allerede nå i mye større grad kan teste ut løsningen i praksis. Oppdragsgiver har gått langt i å antyde at de ønsker å ha oss med videre for å ferdigstille løsningen. Dette er en stor tillitserklæring og bekrefter den positive vurderingen vi selv har av arbeidet som er gjort. Får vi jobbe videre med applikasjonen vil vi implementere flere krav og ønsker fra oppdragsgiver. I tillegg har vi utviklet en rekke tanker og ideer gjennom utviklingsperioden, som trolig vil være med på å øke kvaliteten på en fremtidig løsning. Vi ønsker også å lære mer om målgruppen, blant annet gjennom brukertesting og økt faglig kompetanse. Det er vanskelig å si om vi har oppfylt målene vi satte oss i starten av prosjektperioden. Et av målene var å utforme en individuelt tilpasset applikasjon som kan muliggjøre at målgruppen i større grad kan nyttiggjøre seg av dagens teknologiske muligheter. Oppdragsgiver ønsker å teste ut applikasjonen over tid blant en brukergruppe, og dette skal inngå i et større forskningsprosjekt. Etter at forskningsprosjektet er over vil vi vite mer om målene er nådd. For oss har ikke den største utfordringen vært den tekniske delen av applikasjonsutviklingen, men å finne ut hva som er den beste løsningen for målgruppen vår. Å sette seg inn i behovene til en brukergruppe vi kan lite om fra før har vært utfordrende, men vi mener vi har løst det ganske godt. Alt i alt er vi fornøyd med gjennomføringen, og vi er alle enige om at dette har vært en svært lærerik prosess. 80

82 11.1 Nytteverdi Dagsplanen kan gjøre brukeren mer selvstendig, ved at den tilbyr en digital kalender med funksjoner som kan gi forutsigbarhet og hjelp i hverdagen. Å klare oppgaver på egenhånd gi mestringsfølelse og økt selvtillit. For de ansatte kan applikasjonen bidra til å forenkle deres hverdag. Dagsplanen digitaliserer den analoge planen de er vant til å bruke, noe som kan spare de ansatte for tid ved at den forenkler opprettelse og vedlikehold av ukesplanen. Nytteverdien for OUS er at de får en Android-applikasjon som er utviklet etter deres krav. Denne kan de velge å utvikle videre eller hente relevante elementer fra. Nytteverdien for oss som har laget applikasjonen har vært veldig stor. Vi har tilegnet oss ny kunnskap både når det gjelder design av brukergrensesnitt og programmering. Vi har også erfart hvordan man jobber i prosjekter på tvers av forskjellige fagområder. Dette har vært en god erfaring som vi vil få god nytte av i arbeidslivet. 81

83 12 Videre utvikling I denne oppgaven har fokuset vært å utvikle en testbar applikasjon. Det har også vært en del av oppgaven å finne ut hvilke behov brukere og bistandsytere har. Gjennom samtaler med utviklere av lignende apper på CareWare, med brukere og bistandsytere har nye ønsker for funksjonalitet dukket opp underveis i utviklingsprosessen. Det som er utviklet hittil en er grunnstruktur, og mye annen funksjonalitet er ønsket lagt til. Under følger en liste utarbeidet i samarbeid med oppdragsgiver over det viktigste arbeidet som gjenstår for å forbedre dagsplanen. Funksjonaliteten er listet i tilfeldig rekkefølge Vedlikehold av planen Alle aktiviteter som blir opprettet legger seg kronologisk på valgt dag i ukeplanen. Foreløpig er det ingen mulighet til å endre rekkefølgen på aktivitetene, med mindre man sletter de og legger de til på nytt i en annen rekkefølge. Dette er svært tungvint og kan løses ved å legge til en «drag-and-drop»- funksjon 33. Denne vil fungere ved at administrator kan holde fingeren på en valgt aktivitet, og flytte den rundt på planen etter eget ønske. Den samme funksjonen bør også implementeres i hjelpelisten, der samme problemet ligger. For å gjøre det enkelt å vedlikeholde planen skal maler/templates utvides. Det skal være mulig å lagre og laste inn hele ukesmaler. I tillegg skal man kunne bruke ferdiglagde maler for enkeltaktiviteter. Hvordan det kan fungere er illustrert i figur 98. FIGUR 98: ILLUSTRERER HVORDAN «DRAG-AND-DROP»-FUNKSJONALITET KAN FUNGERE FOR Å FORENKLE VEDLIKEHOLD AV PLANEN. 33 «Drag-and-drop» er en pekegest der man velger et virtuelt objekt ved å «ta tak» i det og dra det til et annet sted. 82

84 Ved opprettelse av aktiviteter er det flere funksjoner som bør implementeres. Det skal blant annet være mulig å legge til bilder som allerede ligger i galleriet/fotoalbumet på nettbrettet. Nå er man nødt til å ta bilder med det innebygde kameraet Motivasjonssystem Det skal etterhvert implementeres et individuelt tilpasset motivasjonssystem. Dette kan innebære at brukeren opparbeider seg poeng, stjerner eller liknende som er knyttet til gjennomførte oppgaver. Poengene kan på et senere tidspunkt veksles inn i attraktive aktiviteter, gjenstander eller tjenester. Det finnes en rekke norske studier som dokumenterer effekten av slike motivasjonssystemer (Andresen, Løkke & Løkke, 2013) og (Finstad, 2001) Fjernadministrering og monitorering Det skal gjøres mulig å administrere og monitorere applikasjonen fra et annet geografisk sted. Dette vil gi anledning til å yte tjenester på en mer hensiktsmessig og kostnadseffektiv måte. Monitorering vil gi foreldre eller bistandsytere mulighet til å gi bistand på de tidspunktene, eller under de aktivitetene, der behovet er størst Støtte for flere medier Administrator skal ha mulighet til å spille inn og legge ved lydklipp sammen med hoved- og delaktiviteter. Denne funksjonen kan være svært nyttig, spesielt for brukere som ikke kan lese. Lydklippet kan hjelpe til med å forklare hele eller deler av oppgaven som skal utføres. Det skal også være mulig å legge ved videoer til aktivitetene. En video kan eksempelvis gi brukeren en mer nøyaktig beskrivelse av hvordan oppgaven skal gjøres, og kan dermed fungere som et godt hjelpemiddel. Det skal også være mulig å legge ved linker (URL-er) til nettsider under de ulike aktivitetene. Linken kan for eksempel være relatert til en oppgave, og hjelpe brukeren med utførelsen Påminnere/notifications Til tross for planen ikke er tidsavhengig skal det være mulig å sette påminnere knyttet til enkelte oppgaver. Dette vil fungere som en alarmfunksjon og kan for eksempel sørge for at brukeren ikke glemmer enkelte aktiviteter i planen. Det skal også være mulig å få påminnelsen som en «notification» 34 dersom ikke applikasjonen er åpen Personalisert design Det er avgjørende at planen kan tilpasses individuelt. Med tanke på at dette er en løsning brukeren skal benytte over lengre tid, er det viktig å kunne personliggjøre den. Dette kan løses ved å ha et utvalg av forskjellig design eller farger som brukeren kan velge mellom. 34 En melding som vises til brukeren utenfor brukergrensesnittet til et program. 83

85 12.7 Bekreftelse av fullførte aktiviteter Det skal være mulig at enkelte aktiviteter må bekreftes fullført for å åpne tilgang til andre aktiviteter. Dette kan være aktuelt for aktiviteter som er definert som obligatoriske, som for eksempel å ta medisiner. Ved å legge inn slike forutsetninger øker sannsynligheten for at slike aktiviteter ikke faller bort ved at brukeren går videre i planen. Aktiviteter som ikke er satt opp med en slik forutsetning skal være mulig å utsette eller velge bort fra planen Valg av «pauseaktiviteter» Dagsplaner og andre struktureringsverktøy kan for enkelte oppleves som statiske og lite fleksible. Derfor skal det være mulig å tilrettelegge for valg i planen. Brukeren kan da enkelt medvirke til valg av aktiviteter og dermed påvirke sin egen hverdag. For enkelte brukere kan pauser være en utfordring. Ved å erstatte pauser med valg av en «pauseaktivitet» kan brukeren ta reelle valg over aktiviteter som er tilgjengelig i perioden. Dette kan eksempelvis være passive aktiviteter som å høre på musikk og se på TV, eller andre aktiviteter som brukeren ønsker å fylle fritiden med Plasseringstjenester Det skal på sikt legges til funksjoner som innebærer GPS. En slik funksjon vil eksempelvis muliggjøre differensiering av hjelpebetingelser avhengig av hvor brukeren befinner seg. Det skal også være mulig at hele eller deler av løsningen kan brukes og administreres via smarttelefoner. Da kan for eksempel handlelister eller andre sjekklister synkroniseres med smarttelefoner, noe som vil gjøre verktøyet ytterligere mobilt og tilgjengelig Implementering og brukertesting Når det foreligger en betaversjon av planen skal denne utprøves av et utvalg brukere og deres familie eller tjenesteytere over tid. Det er et mål at dette utvalget består av brukere med ulike behov, livssituasjon og funksjonsnivå. Utprøvningen utføres etter samtykke fra brukere og deres representanter. 84

86 13 Teknisk spesifikasjon I dette kapittelet er Digitus beskrevet fra et teknologisk ståsted. Teknologier som er brukt og hvordan programmet er bygget opp gjennomgås i detalj. Kapittelet er skrevet for videreutviklere og det forutsettes kompetanse i programmering og systemutvikling. Den kan også brukes som et oppslagsverk til utenforstående for å gi innsikt i oppbygging og funksjonalitet Teknologi Java Java er et objektorientert programmeringsspråk som kjøres på milliarder av enheter rundt i verden 35. Java-programmer kan kjøre på alle plattformer som har støtte for JVM (Java Virtual Machine). Java er det mest brukte programmeringsspråket for Android-utvikling, og kjøres på en virtuell maskin kalt Dalvik i Android. Applikasjonens logikk er programmert i Java XML XML 36 er et markeringsspråk for visning av strukturert informasjon. I Android brukes XML-filer for å sette opp grafisk design, men det kan også brukes for å lagre informasjon som tekststrenger og fargekoder. All data lagres i en hierarkisk struktur som er lesbar for både mennesker og maskiner. Designet blir skilt fra logikken, noe som gjør det enkelt å endre designet uten å måtte endre programlogikken SQLite SQLite er en åpen-kildekode relasjonsdatabase, innebygget i Android-enheter. Den krever lite ressurser for å kjøre og brukes for lagring og administrering av SQL-databaser. Databasen blir lagret lokalt i en fil på Android-enheten Kodeoptimalisering For at applikasjonen skal virke så raskt og responsiv som mulig er det gjort mange grep. Under er en oversikt over kodeoptimaliseringsteknikker som er brukt. Retningslinjer for god objektorientert programmering er fulgt i applikasjonen. Kode som er brukt flere stedet, både i samme klasse og i applikasjonen generelt, er skilt ut i egne metoder for å hindre redundans. Det er lagt stor vekt på å forhindre redundans som nødvendigvis øker størrelsen og kompleksiteten til applikasjonen. Alle klassevariabler er private med mindre spesielle forhold tilsier at de må være public. Unntak fra denne regelen er datafelt for innstillinger i DBHandler.java, da dette er felt som brukes statisk fra andre klasser. Variabler som har konstant verdi er satt til final, da det er en god vane å deklarere static final der det er mulig. Grunnen til dette er at kompilatoren genererer en egen metode kalt <clinit> som Extensible Markup Language. 85

87 brukes hver gang man skal bruke en variabel som ikke er final. Hvis man deklarerer variabelen som final slipper man dette, og sparer derfor ressurser. Alle metoder som ikke tar i bruk klassevariabler er gjort static. Det er normalt å bruke get/set-metoder for å hente/sette data internt i en datastruktur. Set- og getmetoder brukes for å innkapsle data. I stedet for å bruke klassevariabler direkte definerer man egne metoder som får tilgang til disse feltene. Da får man full kontroll over endring av dataen slik at det er lett å endre virkemåte internt i klassen. I Android er det ikke anbefalt å bruke get/set-metoder internt i klassen. Grunnen til det er at virtuelle metodekall krever mye større ressurser enn å kun sjekke datafeltet. Alle datafelt som skal endres eksternt bruker get/set-metoder, men internt brukes alle felt i datastrukturen direkte. For å sjekke prosjektfiler for potensielle bugs og forbedringspotensiale for riktighet, sikkerhet, ytelse, brukervennlighet og tilgjengelighet, er Android lint brukt. Programmet kjøres automatisk hver gang kildekoden kompileres, og kommer med tips til forbedringer dersom det finnes. Den ferdige løsningen er gjennomgått med lint uten noen spesielle bemerkninger Prosjektstruktur Ved opprettelse av et nytt Android-prosjekt setter Android SDK opp en forhåndsbestemt prosjektstruktur. Det er anbefalt å følge denne strukturen videre i utviklingen. For å unngå konflikter med andre applikasjoner er det anbefalt å bruke pakkenavn i omvendt rekkefølge av domenet for organisasjonen. Det vil si at digitusplan.no blir til no.digitusplan. Alle pakkenavn må være unike. For at det skal være lett å finne fram i filene har vi valgt å dele opp programmet i flere pakker. Vi har fulgt Androids retningslinjer for navngiving, og endte dermed opp med følgende navngivingsregel: no.digitusplan.<delpakkenavn>. FIGUR 99: VISER OVERSIKT OVER PROSJEKTSTRUKTUREN I ANDROID STUDIO. I Android skilles javafiler fra ressurser. Javafilene inneholder programlogikken, mens ressursene kan være alt fra layout til bilder og lydfiler. Man har også en manifests-mappe som inneholder innstillinger. 86

88 13.4 Manifests Alle Android-apper må ha en AndroidManifest.xml-fil. Den er plassert i Manifests-mappen. Filen brukes for å gi informasjon om applikasjonen til Android-systemet 37. Den bestemmer hvilken Androidversjon som kreves for å kunne kjøre appen og hva slags tilganger applikasjonen trenger. Mer informasjon om hva slags tilganger appen trenger står det om under «Tillatelser». Det er i Manifestsfilen man bestemmer hvilken logo som skal vises og hvilken fil som skal starte når applikasjonen startes. Alle filer som skal vise noe på skjerm må oppgis i denne filen. I Digitus brukes AndroidManifest.xml for å sørge for at applikasjonen kun kan brukes i landskapsformat. Applikasjonen er spesielt tilpasset landskapsformat, og derfor vil ikke portrettformat fungere bra. For at man skal kunne bruke nettbrettet i omvendt landskapsformat, bruker vi «sensorlandscape», som vist i koden under. Dersom man kun bruker «landscape», vil appen være låst i en retning. 1. <activity 2. android:name="no.digitusplan.<delpakkenavn>.<klasse>" 3. android:screenorientation="sensorlandscape"> 4. </activity> Kodesnutt 1: SensorLandscape gjør at applikasjonen fungerer både i normal og omvendt landskapsformat Programlogikk (java) Det vil være for omfattende å gjennomgå hver eneste fil detaljert, derfor blir kun det mest essensielle beskrevet. Skype-integrasjon skiller seg fra resten av koden ved at det benytter eksterne data. Hoveddelen av applikasjonen består av ListViews og derfor gjennomgås også hvordan rådata blir gjort om til ferdige ListViews. I tillegg finnes det en komplett oversikt over javafiler med en kort beskrivelse av hver enkelt nederst i dette kapittelet. FIGUR 100: VISER ALLE PAKKER OG JAVAFILER PROGRAMMET BESTÅR AV

89 Adapter for ListView Mesteparten av visning av aktiviteter i applikasjonen skjer via ListViews 38. For å fylle inn data i ListViews brukes en adapter, som fungerer som et bindeledd mellom dataene og visningen. Hvert element i en ListView er et View, og det er adapteret som er ansvarlig for å opprette dette 39. I figur 101 vises et eksempel på hvordan data hentet fra databasen blir gjort om til et ListView. FIGUR 101: VISER HVORDAN KODE BLIR TIL FERDIG DESIGN VIA ET ADAPTER Skype-integrasjon For å legge til mulighet for videosamtaler er Skype-applikasjonen brukt. Skype tilbyr funksjonalitet for å sjekke om en bestemt Skype-bruker er pålogget. Dette gjøres ved å sjekke en bestemt URL, der påloggingsstatus skrives ut. Status som returneres kan være en av følgende: Unknown Offline Online Away Do Not Disturb Invisible Skype Me 1. Kodesnutt 2: Adressen over kan brukes for å sjekke påloggingsstatus for en bestemt Skype-bruker. 38 ListView viser en liste over elementer

90 I applikasjonen blir alle andre statuser enn «Online» behandlet som ikke tilgjengelig. Dermed er det kun to statuser å forholde seg til for brukeren - pålogget eller ikke pålogget. Skypefunksjonalitet er plassert i SkypeHandler.java. Klassen har fire funksjoner, der de tre førstnevnte er hentet fra Skype URI Tutorial 40 : initiateskypeuri(context, String): void Har ansvar for å lage en Intent 41 som starter en Skypesamtale med en bestemt bruker. String-en som kommer inn som parameter inneholder brukernavn og informasjon om man ønsker tekst-, lyd-, eller videosamtale. isskypeclientinstalled(): boolean Funksjonen sjekker om Skype-applikasjonen er installert på enheten og returnerer en boolsk variabel av resultatet. gotomarket(context): void Funksjonen starter en Intent som går til Google Play 42. Der er Skype forhåndsvalgt, slik at man kun trenger å trykke installer for å laste ned Skype. setonline(string, TextView, ImageView): void FIGUR 102: VISER HVILKE DELER BRUKER-BISTAND BESTÅR AV. Sjekker om en bestemt bruker er pålogget på Skype ved hjelp av linken som er vist i kodesnutt 2. TextView og ImageView er referanser til tekst- og bildefelt som vises sammen med brukernavnet. Funksjonen har ansvar for å oppdatere disse. Dersom brukeren er pålogget blir en grønn telefon vist, ellers vises en rød telefon. Statusen blir også skrevet ut tekstlig. Sjekk av om en bruker er pålogget gjøres i en ny thread. Dette er for at ikke hele applikasjonen skal vente på å få svar fra Skype sin nettjeneste. Applikasjonen lastes altså inn samtidig som nettstatusen hentes, slik at man ikke må vente på dette I dagsplanen brukes Intent til å starte eksterne applikasjoner. 42 Google Play er en digital butikk for Android-applikasjoner. 89

91 Liste over java-filer Under blir alle javafiler i applikasjonen listet opp. Filene er delt opp etter hvilken pakke de er i, og hovedfunksjonaliteten til hver enkelt fil er beskrevet. no.digitusplan.adapter: Adapter-klassene tar seg av å gjøre om fra rådata til View. Denne prosessen er mer detaljert beskrevet i «Adapter for ListView» i dette kapittelet. ActivityAdapter Fyller ListView for aktiviteter med data fra databasen. NewChecklistAdapter Fyller ListView for nye sjekklister (ved opprettelse i adminmodus) med data fra databasen. UserAdapter Fyller ListView for brukere med data fra databasen. no.digitusplan.admin: Denne pakken inneholder java-filer som brukes i forbindelse med administrasjonssiden. Admin Abstrakt klasse som brukes for å styre navgasjonen for adminsidene. Login Innlogging til administrasjonssidene, krever brukernavn og passord. Bruker handler.dbhandler for å sjekke om brukernavn/passord finnes i databasen. Hvis login er vellykket blir man sendt til admin.weekoverview. ManageActivity Gjør det mulig å opprette, endre og slette aktiviteter fra databasen. ManageSettings Gjør det mulig å skru av/på funksjoner i applikasjonen. Man kan også tømme planen eller laste inn standardaktiviteter. ManageUsers Gjør det mulig å opprette, endre og slette brukere fra databasen. WeekOverview Viser en oversikt over aktiviteter som er lagret i planen. Ved å trykke på en aktivitet blir man sendt til admin.manageactivity. 90

92 no.digitusplan.dayplan: Denne pakken inneholder java-filer som brukes i forbindelse med brukermodus. DayMode Viser en bestemt dag til brukeren. WeekMode Viser en bestemt uke til brukeren. Welcome Viser en velkomstskjerm første gangen applikasjonen starter. no.digitusplan.dialog: Dialog-pakken håndterer popup-vinduer som inneholder funksjonalitet. AssistanceDialog Viser en oversikt over registrerte brukere. Gir også mulighet til å ringe til bistandsytere. ManageTimerDialog Pop-up som gjør det mulig å velge tidspunkt for varighet av nedteller. ManageUserDialog Pop-up som gjør det mulig å legge til/endre eksisterende brukere. no.digitusplan.handler: Handler-pakken inneholder forskjellig funksjonalitet for å behandle en spesiell type data. Flesteparten av funksjonene er static 43. CameraHandler Starter kameraet og lagrer en midlertidig bildefil. DateHandler Tar seg av behandling av datoer. DBHandler Tar seg av behandling av databasen. ImageHandler Tar seg av behandling av bilder. InternetHandler Sjekker om brukeren har tilgang til internet. MessageHandler Tar seg av behandling av utskrift av meldinger til skjerm. SkypeHandler Sjekker om Skype er installert og foretar oppringninger. 43 Metoder som er static kan brukes uten å instansiere et objekt. 91

93 UserHandler Tar seg av brukerhåndtering - tar inn data, validerer og lagrer til database via handler.dbhandler. ValidateHandler Sjekker om en bestemt verdi er godkjent til et bestemt bruk. For eksempel sjekker den om et brukernavn er gyldig. no.digitusplan.misc: Misc-pakken inneholder diverse funksjonalitet som ikke har noen annen naturlig plassering. CalendarTemplate Abstrakt klasse som inneholder funksjonalitet for å opprette en ukesoversikt over aktiviteter. ExamplePlan Inneholder eksempelaktiviteter til dagsplanen. Disse kan lastes inn for å se et eksempel på hvordan en full dagsplan vil se ut. NumberPickerTimer Gjør det mulig å sette min- og maksverdier for timere. Brukes for at ikke skal kunne velge ulovlige verdier. OnSwipeTouchListener Lytter etter sveip/gestures 44. no.digitusplan.object: Object-pakken inneholder klasser det er mulig å instansiere objekter fra, både brukere og aktiviteter. Activity Brukes for aktivitet-objekter. ActivityPart Brukes for delaktivitet-objekter. ActivityTemplate Brukes for aktivitetsmal-objekter. User Brukes for bruker-objekter

94 13.6 Database For lagring av data i applikasjonen er SQLite brukt Databasetabeller FIGUR 103: VISER EN OVERSIKT OVER ALLE TABELLER I DATABASEN. I figur 103 vises alle databasetabellene som brukes i applikasjonen. Under listes alle tabellene opp, der hvert enkelt attributt blir forklart. ActivityTemplate templateid Unik id som identifiserer en bestemt mal. name Navn for aktiviteten. description Beskrivelse av aktiviteten. timer Hvor mange sekunder nedtelleren eventuelt skal telle ned fra. image Inneholder filsti for hvor aktivitetsbildet er lagret. Activity activityid Unik id som identifiserer en bestemt aktivitet. activitytemplateid Angir hvilken mal (templateid) aktiviteten skal benytte. Fremmednøkkel til ActivityTemplate.templateId. date Angir hvilken dato aktiviteten skal vises. position Angir hvilken rekkefølge på dagen aktiviteten skal vises. Brukes dersom det er flere aktiviteter samme dag. checklist Angir om aktiviteten inneholder en sjekkliste (true/false). 93

95 activitychain Angir om aktiviteten inneholder en handlingskjede (true/false) finished Angir om aktiviteten er fullført eller ikke. PartActivity partactivityid Unik id som identifiserer en bestemt delaktivitet. templateid Angir hvilken mal (ActivityTemplate.templateId) delaktiviteten skal benytte. usedbytemplateid Angir hvilken mal (ActivityTemplate.templateId) delaktiviteten inngår i. PartActivityFinished partactivityid Er identifikator for om en delaktivitet for en bestemt aktivitet er fullført, sammen med activityid. Fremmednøkkel til PartActivity.partActivityId. activityid Er identifikator for om en delaktivitet for en bestemt aktivitet er fullført, sammen med partactivityid. Fremmednøkkel til Activity.activityId. finished Angir om en delaktivitet som inngår i en bestemt aktiviteten er fullført eller ikke. Settings name Angir navnet på en bestemt funksjon. enabled Angir om funksjonen angitt i name skal vises for brukeren (true/false). User userid Unik id som identifiserer en bestemt bruker. fullname Brukerens fulle navn. username Brukernavn som brukes ved innlogging. 94

96 password Passord som brukes ved innlogging. skypeid Brukernavn for innlogging i Skype. image Inneholder filsti for hvor bilde av brukeren er lagret Logisk skjema for lagring av aktiviteter For å lagre aktiviteter i databasen brukes fire ulike tabeller. Relasjonen mellom disse er vist i figur 104. Årsaken til at det er nødvendig med fire tabeller er for å kunne lagre (del)aktiviteter som maler. Delaktiviteter hører til en bestemt mal, slik at det er mulig å opprette nye aktiviteter som inneholder samme delaktiviteter. For å lagre om en delaktivitet er fullført for en bestemt aktivitet, brukes PartActivityFinished. FIGUR 104: LOGISK SKJEMA FOR AKTIVITETER I DATABASEN. 95