1. No category

Denne siden er blank med hensikt.
1
PROSJEKT NR.
2015 – 28
Studieprogram: Informasjonsteknologi
Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo
Besøksadresse: Holbergs plass, Oslo
TILGJENGELIGHET
Offentlig
Telefon: 22 45 32 00
Telefaks: 22 45 32 05
BACHELORPROSJEKT
HOVEDPROSJEKTETS TITTEL
DATO
Dagsplanapplikasjon for nettbrett
26.05.2015
ANTALL SIDER
129
PROSJEKTDELTAKERE
INTERN VEILEDER
Kirsten Ribu
Kristoffer Hagen
Steffen Engebretsen
Harald Sletten Adamsen
David Meisund
OPPDRAGSGIVER
KONTAKTPERSON
Oslo Universitetssykehus – Avdeling for nevrohabilitering.
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
Denne siden er blank med hensikt.
3
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
Denne siden er blank med hensikt.
5
2 Innholdsfortegnelse
1
Forord .............................................................................................................................................. 4
2
Innholdsfortegnelse......................................................................................................................... 6
3
Innledning ...................................................................................................................................... 11
4
Bakgrunn ....................................................................................................................................... 12
4.1
5
Mål og rammebetingelser ..................................................................................................... 13
Kravspesifikasjon ........................................................................................................................... 14
5.1
Samsvar med kravspesifikasjonen......................................................................................... 14
5.1.1
5.2
Endelig kravspesifikasjon....................................................................................................... 16
5.2.1
5.3
7
Systemkrav .................................................................................................................... 16
Krav til grensesnitt................................................................................................................. 18
5.3.1
Generelle designkrav ..................................................................................................... 18
5.3.2
Brukervennlighet ........................................................................................................... 18
5.4
6
Funksjonelle krav ........................................................................................................... 14
Dokumentasjonskrav ............................................................................................................. 18
Løsninger på markedet dag ........................................................................................................... 19
6.1
MemoAssist ........................................................................................................................... 19
6.2
carePlan (e-mergency) .......................................................................................................... 20
6.3
Pictoplan ................................................................................................................................ 21
Produktbeskrivelse ........................................................................................................................ 22
7.1
Brukerdel ............................................................................................................................... 22
7.1.1
Ukesmodus .................................................................................................................... 22
7.1.2
Dagsmodus .................................................................................................................... 23
7.1.3
Tilleggsfunksjoner for brukeren .................................................................................... 24
7.2
Administrasjonsdel ................................................................................................................ 27
7.2.1
Opprettelse av førstegangsbruker ................................................................................ 27
7.2.2
Hovedside ...................................................................................................................... 28
7.2.3
Endre plan...................................................................................................................... 29
7.2.4
Endre eller slette aktivitet ............................................................................................. 30
7.2.5
Innstillinger .................................................................................................................... 30
7.2.6
Brukere .......................................................................................................................... 31
7.3
Kommunikasjon med brukeren ............................................................................................. 31
7.3.1
Meldinger som krever interaksjon ................................................................................ 32
6
8
7.3.2
Meldinger som ikke krever interaksjon ......................................................................... 32
7.3.3
Meldinger som er informasjon ...................................................................................... 32
Brukertest og intervju.................................................................................................................... 33
8.1
Personvern ............................................................................................................................ 33
8.2
Generelt om brukertester ..................................................................................................... 33
8.3
Generelt om våre intervjuer .................................................................................................. 34
8.4
Brukertest av prototype på OUS-ansatte .............................................................................. 34
8.4.1
Gjennomføring og resultat ............................................................................................ 34
8.4.2
Konklusjon ..................................................................................................................... 35
8.5
8.5.1
Gjennomføring og resultater ......................................................................................... 35
8.5.2
Konklusjon ..................................................................................................................... 36
8.6
Brukertest brukerdelen ......................................................................................................... 36
8.6.1
Gjennomføring og resultater ......................................................................................... 36
8.6.2
Intervju .......................................................................................................................... 40
8.6.3
Konklusjon ..................................................................................................................... 40
8.7
Brukertest med 5-åring ......................................................................................................... 41
8.8
Brukertest admindelen .......................................................................................................... 42
8.8.1
Gjennomføring og resultater ......................................................................................... 42
8.8.2
Konklusjon ..................................................................................................................... 43
8.9
9
Brukertest ikoner................................................................................................................... 35
Endringer som følge av brukertest ........................................................................................ 44
8.9.1
Brukertest av prototype - brukerdel ............................................................................. 44
8.9.2
Brukertest av ikoner ...................................................................................................... 44
8.9.3
Brukertest av brukerdel................................................................................................. 45
8.9.4
Brukertest av administrasjonsdel .................................................................................. 46
Utviklingsprossen .......................................................................................................................... 48
9.1
Smidig utviklingsmetodikk ..................................................................................................... 48
9.2
Utviklingsverktøy ................................................................................................................... 49
9.2.1
Android Studio ............................................................................................................... 49
9.2.2
Redmine......................................................................................................................... 49
9.2.3
Git .................................................................................................................................. 49
9.2.4
Draw.io .......................................................................................................................... 49
9.2.5
DB Browser for SQLite ................................................................................................... 49
9.2.6
Google Dokumenter ...................................................................................................... 50
9.2.7
Dropbox ......................................................................................................................... 50
9.2.8
Adobe Creative Cloud .................................................................................................... 50
7
9.2.9
Microsoft Powerpoint ................................................................................................... 50
9.2.10
Prosjektdagbok .............................................................................................................. 50
9.3
Fra skisse til ferdig løsning..................................................................................................... 50
9.3.1
Idémyldring.................................................................................................................... 50
9.3.2
Utviklingsprosess for ukesmodus .................................................................................. 51
9.3.3
Utviklingsprosess for dagsmodus .................................................................................. 54
9.3.4
Utviklingsprosess for administrasjonsmodus ................................................................ 56
9.3.5
Utvikling av logo ............................................................................................................ 60
9.4
10
CareWare 2015 ...................................................................................................................... 63
Universell utforming og interaksjon .......................................................................................... 65
10.1
WCAG 2.0 .............................................................................................................................. 66
10.2
Brukervennlighet ................................................................................................................... 66
10.2.1
Tilbydelser ..................................................................................................................... 66
10.2.2
Tilbakemeldinger ........................................................................................................... 66
10.2.3
Metaforer ...................................................................................................................... 67
10.2.4
Synlighet ........................................................................................................................ 68
10.2.5
Sperring av ugyldige handlinger .................................................................................... 68
10.2.6
Lyd ................................................................................................................................. 68
10.3
Visuell kommunikasjon (Design) ........................................................................................... 68
10.3.1
Gestaltlovene................................................................................................................. 69
10.3.2
Forgrunn og bakgrunn ................................................................................................... 69
10.3.3
Nærhet........................................................................................................................... 69
10.3.4
Kontinuitet ..................................................................................................................... 70
10.3.5
Form og det gylne snitt.................................................................................................. 70
10.3.6
Likhet ............................................................................................................................. 71
10.3.7
Tilordninger ................................................................................................................... 71
10.3.8
Tekst og lesbarhet ......................................................................................................... 72
10.3.9
Navngivning ................................................................................................................... 72
10.3.10
10.4
Farger......................................................................................................................... 73
Kognitiv belastning ................................................................................................................ 76
10.4.1
Minnekapasitet.............................................................................................................. 76
10.4.2
Lese- og skrivevansker ................................................................................................... 77
10.4.3
Toleranse for feil............................................................................................................ 77
10.4.4
Organiseringsstruktur .................................................................................................... 78
Konklusjon ................................................................................................................................. 79
11
11.1
Nytteverdi .............................................................................................................................. 80
8
Videre utvikling.......................................................................................................................... 81
12
12.1
Vedlikehold av planen ........................................................................................................... 81
12.2
Motivasjonssystem ................................................................................................................ 82
12.3
Fjernadministrering og monitorering .................................................................................... 82
12.4
Støtte for flere medier........................................................................................................... 82
12.5
Påminnere/notifications........................................................................................................ 82
12.6
Personalisert design .............................................................................................................. 82
12.7
Bekreftelse av fullførte aktiviteter ........................................................................................ 83
12.8
Valg av «pauseaktiviteter» .................................................................................................... 83
12.9
Plasseringstjenester .............................................................................................................. 83
12.10
Implementering og brukertesting ..................................................................................... 83
Teknisk spesifikasjon ................................................................................................................. 84
13
13.1
Teknologi ............................................................................................................................... 84
13.1.1
Java ................................................................................................................................ 84
13.1.2
XML ................................................................................................................................ 84
13.1.3
SQLite............................................................................................................................. 84
13.2
Kodeoptimalisering ............................................................................................................... 84
13.3
Prosjektstruktur ..................................................................................................................... 85
13.4
Manifests ............................................................................................................................... 86
13.5
Programlogikk (java) .............................................................................................................. 86
13.5.1
Adapter for ListView ...................................................................................................... 87
13.5.2
Skype-integrasjon .......................................................................................................... 87
13.5.3
Liste over java-filer ........................................................................................................ 89
13.6
Database ................................................................................................................................ 92
13.6.1
Databasetabeller ........................................................................................................... 92
13.6.2
Logisk skjema for lagring av aktiviteter ......................................................................... 94
13.7
Ressurser ............................................................................................................................... 95
13.7.1
Drawable ....................................................................................................................... 95
13.7.2
Raw ................................................................................................................................ 99
13.7.3
Values ............................................................................................................................ 99
13.8
Systemkrav .......................................................................................................................... 101
13.9
Tillatelser/permissions ........................................................................................................ 101
13.9.1
Tillatelse til å lagre data............................................................................................... 102
13.9.2
Tillatelse til å bruke kameraet ..................................................................................... 102
13.9.3
Tillatelse til å bruke internett ...................................................................................... 102
13.10
Sikkerhet .......................................................................................................................... 103
9
13.10.1
SQL-injections .......................................................................................................... 103
13.10.2
Krypterte passord .................................................................................................... 104
13.11
Tilgjengelighet (accessibility) ........................................................................................... 104
13.11.1
Opplesing av tekst og bilder .................................................................................... 104
13.11.2
Hint for tekstfelt ...................................................................................................... 105
13.11.3
Navigering med tastatur .......................................................................................... 105
13.12
Testing ............................................................................................................................. 106
13.12.1
Velkomstmodus ....................................................................................................... 107
13.12.2
Ukesmodus .............................................................................................................. 107
13.12.3
Dagsmodus .............................................................................................................. 107
13.12.4
Adminmodus ........................................................................................................... 108
13.12.5
Resultater fra testing ............................................................................................... 109
14
Referanser ............................................................................................................................... 110
15
Brukerveiledning ..................................................................................................................... 111
15.1
Brukerdel ............................................................................................................................. 111
15.1.2
Navigering.................................................................................................................... 113
15.1.3
Hvordan komme til neste steg i en handlingskjede? .................................................. 114
15.1.4
Hvordan gå tilbake et steg i en handlingskjede? ......................................................... 114
15.1.5
Hvordan fullføre en delhandling i sjekkliste? .............................................................. 115
15.1.6
Hvordan angre fullføring av delhandling i sjekkliste? ................................................. 115
15.1.7
Nedteller ...................................................................................................................... 116
15.1.8
Hvordan ringe bistandsytere, familie eller venner? .................................................... 117
15.1
Administrasjonsdel .............................................................................................................. 118
15.1.2
Aktiviteter .................................................................................................................... 122
15.1.3
Innstillinger .................................................................................................................. 125
Vedlegg .................................................................................................................................... 126
16
16.1
Vedlegg 1: Attest fra oppdragsgiver .................................................................................... 126
16.2
Vedlegg 2: Risikoplanlegging ............................................................................................... 127
16.3
Vedlegg 3: Samtykkeskjema for brukertest ........................................................................ 129
10
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.
11
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.
12
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.
13
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.
5.1.1 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.
14
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 4.0.3 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.
15
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.
5.2.1 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.
16



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.
17
Tekniske krav




Applikasjonen skal utvikles i Java, XML og SQLite.
Applikasjonen skal utvikles for Android versjon 4.2.2 «Jelly Bean».
Alle nettbrett med versjon 4.2.2 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
5.3.1 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.
5.3.2 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.
18
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: DAGSMODUS I MEMOASSIST.
FIGUR 1: UKESMODUS 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.
19
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.
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
FIGUR 3: OPPRETTELSE AV AKTIVITET I
aktiviteter er skilt ut til en egen side. Oppdragsgiver er
MEMOASSIST.
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 NFC1, 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.
20
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.
21
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.1.1 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.
22
7.1.2 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.
FFIGUR
IGUR 8:
8: V
VISER
ISER HVORDAN
HVORDAN EN
EN
HANDLINGSKJEDE
HANDLINGSKJEDE MED
MED KONTEKSTMENY
KONTEKSTMENY
SKRUDD PÅ
PÅ KAN
KAN SE
SE UT
SKRUDD
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.
23
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.
IGUR 9:
9: V
VISER
ISER ET
ET EKSEMPEL
EN SJEKKLISTE
SJEKKLISTE..
FFIGUR
EKSEMPEL PÅ
PÅ EN
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.
7.1.3 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 10 er det fargekoder under
navnene på ukedagene. På toppen er det et navigasjonsfelt som gjør det mulig å skifte uke.
FIGUR 10: TIL VENSTRE: UKESMODUS UTEN TILLEGG SKRUDD PÅ. TIL HØYRE: UKESMODUS MED ALLE TILLEGG SKRUDD
PÅ.
Nedenfor vises dagsmodus med og uten tilleggsfunksjoner. I figur 11 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.
24
FIGUR 11: TIL VENSTRE: DAGSMODUS UTEN TILLEGG SKRUDD PÅ. TIL HØYRE: DAGSMODUS MED ALLE TILLEGG
SKRUDD PÅ.
Bistand via Skype
Bistand via Skype2 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.
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.
FIGUR 12: EN OVERSIKT OVER TILGJENGELIGE
KONTAKTER DUKKER OPP OM BRUKEREN TRYKKER
«HJELP».
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.
2
Skype er et videokonferanseverktøy med chat-funksjon.
25
FIGUR 13: VISER NAVIGASJONSFELTET FOR DAGSMODUS ØVERST. UNDER VISES NAVIGAJSONSFELTET 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 14: 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 15: VISER ET UTDRAG AV FARGEKODENE I APPLIKASJONEN.
26
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.
FIGUR 16: KONTEKTSMENYEN VISER
TYDELIG AT BRUKEREN ER PÅ DEN SISTE
AKTIVITETEN I HANDLINGSKJEDEN.
Nedteller
Nedtelleren ligger under bildet til valgt aktivitet.
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 17: NEDTELLEREN I DAGSMODUS BLIR LYSEGRØNN ETTERHVERT SOM TIDEN TELLER NEDOVER.
7.2 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.
7.2.1 Opprettelse av førstegangsbruker
Første gang brukeren åpner
applikasjonen må det opprettes en
administratorkonto.
FIGUR 18: VELKOMSTSKJERM VISES FØRSTE GANG APPLIKASJONEN
STARTES.
27
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.
7.2.2 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
kan administratorer endre, legge til
FIGUR 21: VISER UKESOVERSIKT I ADMINMODUS
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.
28
7.2.3 Endre plan
Administrator må fylle ut
aktivitetsnavn og legge til bilde for å
opprette en ny aktivitet. Det er
valgfritt å beskrive aktiviteten. Å
legge til hjelpeliste3 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
FIGUR 22: OPPRETTELSE AV NY AKTIVITET I ADMINMODUS.
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».
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 FIGUR 23: ANGIR OM EN HJELPELISTE
SKAL VÆRE EN HANDLINGSKJEDE ELLER
skal vare. Man har mulighet til sette på nedtelling helt opp til ett
EN SJEKKLISTE.
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.
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.
29
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.
7.2.4 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
dialogboks4. Der må brukeren bekrefte
at aktiviteten virkelig skal slettes.
FIGUR 27: BRUKEREN MÅ GI EN BEKREFTELSE OM EN AKTIVITET SKAL
SLETTES.
7.2.5 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.
30
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.
7.2.6 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.3 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.
31
7.3.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.
7.3.2 Meldinger som ikke krever interaksjon
Enkelte meldinger kan gi nyttig informasjon uten at det kreves interaksjon fra brukeren. Disse
meldingene blir vist som en toast5, 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.
7.3.3 Meldinger som er informasjon
FIGUR 33: GIR NYTTIG INFORMASJON OG KREVER IKKE INTERAKSJON.
5
6
Et vindu som viser tekstlig tilbakemelding til brukeren.
Et tekstfelt som viser tekst til brukeren, uten mulighet for redigering.
32
Meldinger som gir nyttig
informasjon til brukeren som ikke
krever interaksjon, blir vist i form
av et TextView6. Dette brukes for
eksempel under Innstillinger, for
å informere om funksjoner på
siden.
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
33
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
prototype7 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.
8.4.1 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.
34
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.
8.4.2 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
8.5.1 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.
35
Deretter gjennomførte vi en ny brukertest med personer som var ukjente for oss. Testen ble gjort på
nettstedet OptimalWorkshop8, 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.
8.5.2 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
8.6.1 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 hjelpemiddelteknologi9 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.
36
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Å.
37
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.
38
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.
39
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.
8.6.2 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.
8.6.3 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.
40
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
41
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
8.8.1 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.
42
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
opp. Brukeren forsøker å legge til bilder
FIGUR 42: FOR Å TA BILDE MÅ MAN TRYKKE PÅ NUMMER 1.
for delaktiviteter ved å trykke på
UNDER TESTEN TRYKKET BRUKEREN PÅ 2.
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.
8.8.2 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.
43
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.
8.9.1 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.
8.9.2 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.
44
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 46.
45
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 bilder10.
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 365-396 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.
8.9.4 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.
10
http://stackoverflow.com/questions/2895065/what-does-the-filter-parameter-to-createscaledbitmap-do
46
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.
47
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
Scrum11 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 sprinter12. 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 backlog13 har vært lagret i et prosjektstyringsverktøy kalt Redmine. For hver sprint satte
vi over oppgaver fra produktkøen til en sprint backlog14. 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 15-60 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.
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.
12
48
9.2 Utviklingsverktøy
I denne delen tar vi for oss verktøyene vi har benyttet til planlegging, prosjektstyring og utvikling.
9.2.1 Android Studio
Android Studio har blitt brukt for å utvikle applikasjonen. Programmet har WYSIWYG15-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.
9.2.2 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.
9.2.3 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.
9.2.4 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.
9.2.5 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.
49
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.
9.2.7 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.
9.2.8 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.
9.2.9 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.
9.2.10 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.
9.3.1 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.
50
FIGUR 48: TANKEKART SOM BLE LAGET TIDLIG I UTVIKLINGSPROSESSEN.
9.3.2 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.
51
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 de16. 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 51.
16
Ikonene er markert som «lov å bruke kommersielt, også i endret form».
52
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.
53
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.
54
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.
55
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.
9.3.4 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 58: ADMINMODUS MED LINKER TIL MEST
BRUKTE HANDLINGER ØVERST.
FIGUR 57: ADMINMODUS MED MENY PÅ VENSTRE SIDE.
56
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
57
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 61: SKISSE DER UNØDVENDIGE MELLOMROM ER
FJERNET.
FIGUR 60: EN AV DE FØRSTE DIGITALE SKISSENE FOR
ADMINMODUS.
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.
58
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.
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
rotete fordi det var for mange elementer
FIGUR 63: SKISSE FOR Å ENDRE/LEGGE TIL AKTIVITET.
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.
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.
FIGUR 64: FJERNER ELEMENTER FRA FORRIGE DESIGN.
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 59.
59
FIGUR 66: VISER HVORDAN DEN ENDELIGE «LEGG TIL AKTIVITET»-SIDEN SER UT.
9.3.5 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.
60
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.
61
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 ANDROIDAPPLIKASJONER.
62
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.
9.4 CareWare 2015
Onsdag 15.04.2015 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
63
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 EMERGENCY 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.
64
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 (http://ndla.no/nb/node/14938). Gjengitt med
tillatelse.
65
10.1 WCAG 2.0
WCAG 2.018 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.
10.2 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.
10.2.1 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.
10.2.2 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 2.0.
66
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.
10.2.3 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.
67
10.2.4 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.
10.2.5 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.
10.2.6 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.
10.3 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.
68
10.3.1 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.
10.3.2 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.
10.3.3 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.
69
10.3.4 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.
10.3.5 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.
70
Innenfor hovedaktiviteteten benyttes det gylne snitt for knappene. Ulike farger har ulik vekt. Ifølge
Niki Fulton19 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.
10.3.6 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.
10.3.7 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.
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.
FIGUR 88: KAMERAIKONET ER EN DIREKTE TILORDNING SOM
KONTROLLERER KAMERAET.
19
https://unifiedspace.wordpress.com/2012/03/20/why-do-colours-have-a-visual-weight/
71
10.3.8 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 sp20. Skiftstørrelsen kan justeres i Android-innstilingene.
Teksttypen er sans-serif21 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.
10.3.9 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.
72
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
piktogrammer22 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.
10.3.10
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 monokromatisk23
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.
En monokromatisk fargeharmoni bruker kun én farge for å oppnå maksimal effekt. Intensiteten og fargetonen
kan varieres ved å tilsette sort eller hvit.
23
73
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 standarden24. 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 helsesektoren25. 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.
25
http://www.farvernesbetydning.dk/farven-bla/
74
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.
75
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
#195790
#ffffff
7.48 : 1
Tekst 2
#43bdfc
#000000
9.92 : 1
Tekst 3
#ffffff
#000000
21 : 1
Tekst 4
#1fd238
#000000
10.33 : 1
Tekst 5
#f57b7f
#000000
8.02 : 1
Tekst 6
#d9d9d9
#000000
14.88 : 1
Lov om universell utforming av IKT-løsninger27 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 situasjoner28, og vi vurderer det som greit
at denne teksten kun oppfyller AA.
10.4 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.
10.4.1 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.
https://lovdata.no/dokument/SF/forskrift/2013-06-21-732
28
http://uu.difi.no/veiledning/nettsider/uu-skolen/kontrast
27
76
noe som gir syv trykkbare kategorier. Venstremenyen i dagsmodus gir oversikt over mellom fire og
fem aktiviteter. Dermed overholdes Millers lov.
10.4.2 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 sekvensieringsvansker29. 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.
10.4.3 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.
77
10.4.4 Organiseringsstruktur
Applikasjonen har en hierarkisk top-down organiseringsstruktur30. Ved å følge denne innordningen
kan brukeren lettere danne seg en mental modell31 av strukturen, og dermed øke forståelsen av
applikasjonen. For at hierarkiet skal opprettholde sin verdi, er ikke informasjon lagret redundant32.
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.
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.
31
78
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.
79
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.
80
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.
12.1 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»funksjon33. 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.
81
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.
12.2 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).
12.3 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.
12.4 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.
12.5 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.
12.6 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.
82
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.
12.8 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.
12.9 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.
12.10
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.
83
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.
13.1 Teknologi
13.1.1 Java
Java er et objektorientert programmeringsspråk som kjøres på milliarder av enheter rundt i verden35.
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.
13.1.2 XML
XML36 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.
13.1.3 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.
13.2 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
35
36
https://www.java.com/en/about/
Extensible Markup Language.
84
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.
13.3 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.
85
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-systemet37. 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.
13.5 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.
37
http://developer.android.com/guide/topics/manifest/manifest-intro.html
86
13.5.1 Adapter for ListView
Mesteparten av visning av aktiviteter i applikasjonen skjer via ListViews38. 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 dette39. 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.
13.5.2 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. http://mystatus.skype.com/<brukernavn>.txt
Kodesnutt 2: Adressen over kan brukes for å sjekke påloggingsstatus for en bestemt Skype-bruker.
38
39
ListView viser en liste over elementer.
http://developer.android.com/reference/android/widget/Adapter.html
87
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 Tutorial40:
initiateSkypeUri(Context, String): void
Har ansvar for å lage en Intent41 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 Play42. 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.
40
https://msdn.microsoft.com/en-us/library/office/dn745884.aspx
I dagsplanen brukes Intent til å starte eksterne applikasjoner.
42
Google Play er en digital butikk for Android-applikasjoner.
41
88
13.5.3 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.
89
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 static43.
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.
90
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/gestures44.
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.
44
http://developer.android.com/design/patterns/gestures.html
91
13.6 Database
For lagring av data i applikasjonen er SQLite brukt.
13.6.1 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).
92
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.
93
password
Passord som brukes ved innlogging.
skypeId
Brukernavn for innlogging i Skype.
image
Inneholder filsti for hvor bilde av brukeren er lagret.
13.6.2 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.
94
13.7 Ressurser
13.7.1 Drawable
Drawable inneholder alle bildefiler som trengs for at applikasjonen skal kjøre. Her ligger blant annet
ikoner og grafikk. Mappen inneholder et førtitalls filer, og man kan ikke dele inn drawable i flere
undermapper. For å holde orden her er det brukt prefixer45 for navnene. Det vil si at alle bildefiler
som brukes som ikoner heter «icon_xx». Det samme gjelder for grafikk og knapper.
FIGUR 105: OVERSIKT OVER ALLE DRAWABLE-FILER.
XML-filene i drawable-mappen genererer grafikk, og under vises et eksempel på hvordan dette
foregår. I kodesnutt 3 oppgis det at en rektangel med 3 px svart omriss skal lages. Videre skal den
være avrundet med 10 dp, og den skal ha en gradient-farge46. Det oppgis også at gradienten skal ha
en vinkel på 270 grader, noe som resulterer i en form som er lys øverst, mørk underst. Resultatet av
koden vises i figur 107.
1. <?xml version="1.0" encoding="utf-8"?>
2. <shape xmlns:android="http://schemas.android.com/apk/res/android"
3.
android:shape="rectangle">
4.
5.
<gradient
6.
android:startColor="@color/button_green_light"
7.
android:endColor="@color/button_green"
8.
android:angle="270" />
9.
10. <corners android:radius="10dp" />
11. <stroke android:width="3px" android:color="@color/black" />
12. </shape>
Kodesnutt 3: Kodeeksempel for å generere en grønn knapp som er lys på toppen, mørkere nederst.
45
46
http://developer.android.com/design/style/iconography.html#DesignTips
En gradient er en gradvis overgang fra en farge til en annen.
95
FIGUR 106: EKSEMPEL PÅ GENERERING AV DRAWABLE-FIL GJENNOM XML-KODE.
Layout
I layout-mappen lagres utseendet til applikasjonen. Det er for omfattende å beskrive hver enkelt fil
detaljert, men en oversikt over alle filene er inkludert. De viktigste designfilene, ukesmodus og
dagsmodus blir beskrevet mer detaljert.
Ved utvikling av designet kan man velge mellom ulike Layouts47, som definerer den visuelle
strukturen for brukergrensesnittet.
RelativeLayout, som er vist i
figur 107, gjør det mulig å sette
opp elementer relativt til
hverandre. For eksempel ser
man i figuren at 1 er plassert
over 2 og 3. Element 2 er
plassert til venstre for element
3. Alle elementer i strukturen er
satt opp i relasjon til hverandre.
RelativeLayout er valgt som
Layout i hele applikasjonen
fordi det er mulig å holde
hierarkiet flatt, noe som øker
ytelsen48.
FIGUR 107: VISER ET EKSEMPEL PÅ HVORDAN RELATIVE-LAYOUT KAN SETTES
OPP.
47
48
http://developer.android.com/guide/topics/ui/declaring-layout.html
http://developer.android.com/guide/topics/ui/layout/relative.html
96
Ukesmodus
Ukesmodus (week_view.xml) består av en rekke ulike XML-filer. Figur 108 viser de viktigste.
1.
2.
3.
4.
5.
date_picker.xml
style.xml (weekTextWeekDay)
style.xml (weekListView)
single_activity_list_item.xml
icon_key.png
FIGUR 108: VISER HVILKE FILER UKESOVERSIKTEN BESTÅR AV.
For videreutviklere er det viktig å raskt få innblikk i
størrelsesforhold i applikasjonen. I fremtiden er det mulig
at størrelsen for bilder eller tekst for aktiviteter må
justeres. Siden ukesmodus består av flere ulike XML-filer,
er størrelsesforholdene samlet og vist i figur 109.
FIGUR 109: VISER STØRRELSER SOM BRUKES
FOR AKTIVITETER I UKESMODUS.
97
Dagsmodus
Dagsmodus (day_view.xml) består av en rekke ulike komponenter. Figur 110 viser de viktigste.
Dersom en aktivitet inneholder en sjekkliste, blir punkt 6 (day_view_normal.xml) byttet ut med
day_view_checklist.xml.
1.
2.
3.
4.
5.
6.
7.
8.
icon_home.png
date_picker.xml
Button - åpner day_view_assistance.xml
single_activity_list_item.xml
ListView
day_view_normal.xml
ListView
single_activity_chain_item.xml
FIGUR 110: VISER DE ULIKE KOMPONENTENE DAGSMODUS BESTÅR AV.
Liste over layout-filer
Under følger en komplett liste over layout-filer:












admin_add_checklist.xml
admin_home_button.xml
admin_login.xml
admin_manage_activity.xml
admin_manage_activity_timer.xml
admin_manage_users.xml
admin_manage_users_form.xml
admin_menu.xml
admin_settings.xml
admin_week_overview.xml
date_picker.xml
day_view.xml
98












day_view_assistance.xml
day_view_checklist.xml
day_view_normal.xml
download_skype.xml
part_activity_field.xml
single_activity_admin_list_item.xml
single_activity_chain_item.xml
single_activity_list_item.xml
single_user_overview.xml
week_view.xml
welcome.xml
welcome_add_first_user.xml
13.7.2 Raw
I raw-mappen lagres råfiler som ikke er bearbeidet. I Digitus lagres to lydklipp her: alarmlyd for å
signalisere at nedtelleren er ferdig og en feilmeldingslyd dersom administrator ikke har fylt inn alle
felt tilstrekkelig godt nok.
13.7.3 Values
I values-mappen finnes color.xml, strings.xml og styles.xml. Alle disse filene er til for å unngå at
informasjon er lagret redundant. Under blir hver enkelt fil gjennomgått.
Strings.xml
Strings.xml inneholder alle tekststrenger i applikasjonen. Fordelen med å bruke strings.xml er å
gjøre det lett å oversette teksten til forskjellige språk. Da er alle tekster samlet og organisert på ett
sted, slik at det er lett å oppdatere eller oversette. Ved å ha flere strings-filer for ulike språk vil
språket som brukes på enheten automatisk brukes. Dersom applikasjonen skal oversettes til andre
språk holder det altså å oppdatere strings.xml.
1. <?xml version="1.0" encoding="utf-8"?>
2. <resources>
3.
<string name="activityAdded">Aktiviteten er opprettet.</string>
4.
<string name="activityDeleted">Aktiviteten er slettet.</string>
5. </resources>
Kodesnutt 4: Utdrag fra strings.xml-fil.
99
Color.xml
Color.xml inneholder en oversikt over alle farger
som brukes i applikasjonen. Denne filen ligger
under res/values og alle fargene har fått et navn.
Dermed slipper man å forholde seg til fargekoder i
resten av applikasjonen, da holder det å huske for
eksempel «blue». Det finnes mange forskjellige
fargenyanser, men ved å bruke color.xml har man
enkelt oversikt over alle farger. Det finnes mange
ulike fargenyanser, og dersom man senere finner ut
at man vil gjøre en farge lysere, trenger man kun å
endre fargen i color.xml. Da vil fargen bli
oppdatert alle steder i applikasjonen. Der fargen
vises er det kun lagret en referanse til color.xml,
mens selve fargekoden lagres i color.xml. Fargene
er organisert etter hvor det er brukt; knappefarger,
generelt og farger for ukedager.
Hver enkelt ukedag har sin egen farge, og for å
gjøre det lettere å finne fram er de navngitt etter
ukedag, ikke hvilken farge de faktisk er. Alle farger
som er brukt i applikasjonen er beskrevet i
«Universell utforming/Farger»
FIGUR 111: VISER ALLE FARGEKODER SOM BRUKES I
APPEN.
1. <color name="blue">#43bdfc</color>
2. <color name="blue_light">#5f9dd6</color>
3. <color name="blue_dark">#07324f</color>
Kodesnutt 5: Viser hvordan fargekoder er organisert i Color.xml. Her knyttes kodeordet «blue» opp
mot fargekoden #43bdfc. Dermed holder det å huske «blue» dersom man senere trenger å bruke
fargen.
Styles.xml
I styles.xml setter man opp en designmal som kan brukes flere ganger. Ved å skille ut designspesifikke XML-tags, er det enkelt å oppdatere alle filer samtidig, og man er da sikrer at alle knapper
og tekstfelt har likt design. Et eksempel på bruk av styles.xml er ListView-en som brukes for å vise
en oversikt over alle aktiviteter som skal utføres en bestemt dag. Planen overskriver standard
ListView, blant annet for å posisjonere aktiviteter ved å legge til padding. Den legger også til et
mellomrom mellom hvert element i listen. For å unngå at denne koden er repetert for hver eneste
dag er den skilt ut i styles.xml, som vist i kodesnutt 6.
100
1. <style name="weekListView" parent="@android:style/Widget.ListView">
2.
<item name="android:layout_width">183dp</item>
3.
<item name="android:layout_height">match_parent</item>
4.
<item name="android:scrollbars">none</item>
5.
<item name="android:background">@android:color/transparent</item>
6.
<item name="android:divider">@android:color/transparent</item>
7.
<item name="android:dividerHeight">5.0sp</item>
8.
<item name="android:paddingLeft">6dp</item>
9.
<item name="android:paddingRight">6dp</item>
10. <item name="android:paddingTop">10dp</item>
11. </style>
Kodesnutt 6: Eksempel på style av ListView for aktiviteter i styles.xml.
13.8 Systemkrav
Det stilles en del krav til enheten for å kunne bruke Digitus.
Applikasjonen i seg selv bruker kun 3.61 MB lagringsplass. Databasen, mellomlager og bildefiler er
det som tar opp mest plass. Det er vanskelig å beregne hvor mye plass man trenger til dette, men
databasen og mellomlageret tar ikke spesielt stor plass. Eksempelvis tar en plan med 30 aktiviteter
og fire administratorer i underkant av 80 KB. Bildefilene derimot kan ta opp mye plass. Etter
komprimering kan man regne med at bildefilene ligger på omtrent 200-400 KB per bilde.
For at applikasjonen skal kunne kjøre kreves minimum Android versjon 4.0.3 (API 15, Ice Cream
Sandwich). Det er også påkrevd at enheten har innebygget kamera. Skype-applikasjonen må være
installert for at bistandsdelen av dagsplanen skal fungere.
13.9 Tillatelser/permissions
En sentral tankegang i Androids
sikkerhetsarkitektur er at ingen
applikasjoner har tilgang til å gjøre noen
operasjoner som kan påvirke andre apper,
operativsystemet eller brukeren selv som
standard. Man har altså ikke tilgang til å lese
eller lagre brukerens private informasjon
som for eksempel kontakter, meldinger eller
mailer. Man har heller ikke tilgang til
internett, mulighet til å sende meldinger og
lignende. Kort sagt kan man si at
applikasjonen ikke kan påvirke
brukeropplevelsen eller noen informasjon på
enheten.
FIGUR 112: OVERSIKT OVER TILLATELSENE DIGITUS KREVER.
101
For å få tilgang til funksjonalitet som påvirker enheten må man oppgi dette i AndroidManifest.xml.
Da får brukeren opp hva slags tillatelser applikasjonen krever før man får installert. Digitus krever få
tillatelser for å fungere, og under er en liste over alle.
13.9.1 Tillatelse til å lagre data
Digitus spør om tillatelse til WRITE_EXTERNAL_STORAGE. Denne tilgangen trengs for å lagre bilder til
enheten. Alle bilder som blir tatt i applikasjonen må lagres, og derfor må brukeren tillate lagring.
1. <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
Kodesnutt 7: I AndroidManifest.xml oppgis det at applikasjonen krever tilgang til lagringsplass.
13.9.2 Tillatelse til å bruke kameraet
Digitus starter kameraet som en Intent49, og bruker derfor aldri kameraet direkte50. Det vil si at man
strengt tatt ikke trenger å be om tillatelse til å bruke kameraet, da den originale
kameraapplikasjonen allerede har tillatelse til det. For ordens skyld og for å gjøre brukeren
oppmerksom på at kameraet faktisk blir brukt ber applikasjonen likevel om tillatelse til å bruke
kameraet.
1. <uses-permission android:name="android.permission.CAMERA" />
Kodesnutt 8: I AndroidManifest.xml oppgis det at applikasjonen krever tilgang til kameraet.
13.9.3 Tillatelse til å bruke internett
Applikasjonen krever tilgang til internett for å sjekke om bistandsytere er pålogget på Skype. Internet
brukes for å hente ned et kort kodeord fra Skype sin nettside. For å finne ut om brukeren er tilkoblet
internett eller ikke, må applikasjonen ha tilgang til nettverkstilstand. Nettverkstilstand brukes for å
skrive ut en melding til brukeren dersom Skype-modulen åpnes uten at enheten har tilgang til
internett. Da får brukeren tilbakemelding om at internett må være tilgjengelig og tilkoblet for å bruke
Skype.
1. <uses-permission android:name="android.permission.INTERNET" />
2. <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
Kodesnutt 9: I AndroidManifest.xml oppgis det at applikasjonen krever tilgang til internett og
informasjon om nettverkstilstand.
49
50
http://developer.android.com/guide/topics/media/camera.html#intents
http://developer.android.com/guide/topics/media/camera.html#manifest
102
13.10
Sikkerhet
Androids operativsystem har mange sikkerhetssystemer innebygget51. Systemet er bygget opp slik at
man som utvikler skal unngå mye sikkerhetsproblematikk. Blant annet brukes et kryptert filsystem
for å beskytte data, man har systemer for å sikre minnehåndteringsfeil og Android Application
Sandbox52. De to viktigste sikkerhetsområdene som er aktuelt for Digitus er å hindre SQL-injections
og å kryptere passord.
13.10.1
SQL-injections
SQL-injections er angrep som utnytter metategn53 i SQL. Dette kan endre spørringen slik at
angriperen kan endre eller generere nye databasespørringer. Dersom input fra brukeren blir sendt
direkte til databasetjeneren uten å håndtere metategn kan angriperen få tilgang til å lese, endre eller
slette data. Ifølge OWASP54 er SQL-injections den mest kritiske sikkerhetsrisikoen.
For å unngå SQL-injections benytter applikasjonen ContentValues i stedet for rene SQL-spørringer
ved innsetting av data. ContentValues bruker variabelbinding55, noe som forhindrer SQL-injections56
(Burns, J. 2008:20). ContentValues kan gi kortere kode og er mer oversiktlig enn lange SQLspørringer. Ved henting av data fra databasen brukes prepared statements57, som gir både
sikkerhet og er mer effektiv enn normale spørringer58. Ved oppdatering og sletting av data brukes
paramtriserte spørremetoder; update() og delete().
1.
2.
3.
4.
5.
ContentValues values = new ContentValues();
values.put(COLUMN_ACTIVITY_ID, activity.getActivityID());
values.put(COLUMN_ACTIVITY_POSITION, activityPosition);
values.put(COLUMN_ACTIVITY_FROM_TEMPLATE_ID, activity.getActivityTemplateID());
values.put(COLUMN_ACTIVITY_DATE, DateHandler.getStringFromCalendar(activity.getActiv
ityDate()));
6. values.put(COLUMN_ACTIVITY_FINISHED, false);
7.
8. db.insert(TABLE_ACTIVITY, null, values);
Kodesnutt 10: Eksempel på ContentValues for innsetting av data. Her legges det inn informasjon om
en ny aktivitet.
51
http://developer.android.com/training/articles/security-tips.html
Android Application Sandbox isolerer forskjellige apper fra hverandre.
53
Eksempler på metategn er ‘#--.
54
https://www.owasp.org/index.php/Top_10_2013-Top_10
55
http://androidxref.com/4.4.2_r1/xref/frameworks/base/core/java/android/database/sqlite/
SQLiteDatabase.java#1537
56
http://thecodist.com/article/sql-injections-how-not-to-get
57
http://tutorials.jenkov.com/jdbc/preparedstatement.html#preparedstatement-performance
58
http://developer.android.com/training/articles/security-tips.html#ContentProviders
52
103
1. String query =
2.
"SELECT " + COLUMN_ACTIVITY_ID +
3.
" FROM " + TABLE_ACTIVITY +
4.
" WHERE " + COLUMN_ACTIVITY_DATE + " = ?" +
5.
" AND " + COLUMN_ACTIVITY_POSITION + " = ?";
6.
7. String[] values = {DateHandler.getStringFromCalendar(date), String.valueOf(position)
};
Kodesnutt 11: Eksempel på prepared statement for henting av data. Det første spørsmålstegnet blir
erstattet med verdien på posisjon 0 i values-arrayen, det andre med posisjon 1.
13.10.2
Krypterte passord
For å unngå at brukernes passord skal kunne leses av direkte dersom noen får tilgang til databasen,
blir passord lagret kryptert i databasen. Hash-funksjonen SHA-25659 brukes for kryptering, og som
vist i kodesnutt 12 brukes MessageDigest i java-koden. Klassen har sikre «enveis-hash»-funksjoner60.
1. MessageDigest md = null;
2. md = MessageDigest.getInstance("SHA-256");
3. return byteArrayToHexString(md.digest(password));
Kodesnutt 12: Utdrag fra kode for å konvertere byte-array til en kryptert String.
13.11
Tilgjengelighet (accessibility)
Et viktig mål med applikasjonen er at den skal være så tilgjengelig som mulig. For å teste at
applikasjonen er tilgjengelig er Androids sjekkliste for brukervennlighet61 fulgt. Under gjennomgås de
viktigste stegene som er nødvendig for å gjøre appen brukbar for personer med
funksjonsnedsettelser.
13.11.1
Opplesing av tekst og bilder
TalkBack er en tilgjengelighetstjeneste som hjelper blinde og synshemmede brukere ved å legge til
tale-, lyd- og vibrasjonstilbakemelding på enheten62. Appen er forhåndsinstallert på de fleste
Android-enheter. Dagsplanapplikasjonen er testet med TalkBack aktivert, og alle essensielle
elementer blir lest opp for brukeren når de blir trykket på.
ContentDescription er en tagg man setter på bilder og grafikk. Konsekvent bruk av taggen har
sikret at applikasjonen kan brukes selv om man ikke klarer å lese tekst eller bilder. Alle elementer blir
beskrevet tekstlig, og dermed kan man forstå innholdet uten å se for eksempel bildet. Dersom man
har aktivert TalkBack, vil innholdet i bildet bli lest opp hvis man trykker på det. ContentDescription
er lagt til alle ImageButton, ImageView og CheckBox som tilbyr funksjonalitet eller viktig informasjon
59
SHA-256 (Secure Hash Algorithm) hører til «SHA-2»-familien, og de ferdige hash-verdiene blir på 256 biter.
http://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest.html
61
http://developer.android.com/tools/testing/testing_accessibility.html
62
https://support.google.com/accessibility/android/answer/6007100
60
104
i applikasjonen. Bilder som kun er brukt som dekorativ grafikk inneholder ikke ContentDescription.
Tekstfelt blir automatisk tolket av TalkBack, og de inneholder derfor heller ikke taggen.
13.11.2
Hint for tekstfelt
For EditText-felt brukes android:hint i stedet for ContentDescription. Årsaken til dette er at
man skal gi brukeren informasjon om hva som skal fylles inn i feltet. Dette blir lest opp når tekstfeltet
er tomt. Etter at informasjon er fylt inn i feltet, blir innholdet lest opp i steden for hint-teksten63.
Siden hint-teksten havner i tekstfeltet blir det mer brukervennlig selv for personer som ikke bruker
TalkBack. Årsaken til dette er at beskrivelsen av hva som skal fylles inn i tekstfeltet havner midt i
feltet, og det er da ingen tvil om hva som skal fylles inn.
FIGUR 113: ANDROID:HINT SØRGER FOR AT DET TYDELIG VISES HVA SOM SKAL FYLLES INN I EDITTEXT-FELT.
13.11.3
Navigering med tastatur
For at applikasjonen skal være tilgjengelig for personer som ikke bruker touch-skjermen er alle
navigasjonssystemer gjort tilgjengelig for bruk med tastatur. Brukere med begrenset syn eller som
har motoriske problemer kan ha god nytte av å bruke tastatur i stedet for den trykkbare skjermen.
Appen er testet med tastatur for å sikre at det fungerer optimalt. For å gjøre et element tilgjengelig
med tastatur, legger man til XML-taggen android:focusable="true"64.
FIGUR 114: VISER UTDRAG FRA ADMIN-INNSTILLINGER, DER SWITCH FOR NAVIGASJONSFELT HAR FOKUS.
Android har en innebygget algoritme for å styre hva som skal få fokus hvis brukeren trykker
opp/ned/venstre/høyre. For innstillinger i adminmodus fungerer ikke dette, siden en switch er
plassert foran en TextView. Ved å trykke til høyre i «Navigasjonsfelt» havner man ikke på switch, og
omvendt havner man ikke på «Navigasjonsfelt». Løsningen på dette er å overstyre Android, ved å
bruke android:nextFocusLeft og android:nextFocusRight. Figur 115 viser hvordan dette er gjort i
koden. Som bildet viser, blir man ført til switch ved å trykke til høyre i «Navigasjonsfelt», og man
kommer tilbake igjen ved å trykke til høyre. Dette er gjort for alle innstillinger-felt, og er helt
nødvendig for at man skal kunne endre innstillinger med tastatur.
63
64
http://developer.android.com/guide/topics/ui/accessibility/apps.html#label-ui
http://developer.android.com/guide/topics/ui/accessibility/apps.html#focus-nav
105
FIGUR 115: VISER HVORDAN TASTATUR-NAVIGERING ER IVARETATT VED Å OVERSTYRE ANDROIDS
STANDARDOPPFØRSEL.
For at brukeren skal slippe å navigere innom elementer som ikke kan endres, fjernes fokuset fra
knapper som blir merket som deaktivert. Android vet ikke om en knapp med selvlagd design skal ha
fokus eller ikke, og derfor må man selv oppgi det. I dagsplanen deaktiveres knappen «Ikke ferdig» om
en oppgave ikke er fullført, som vist i figur 116. I java-koden brukes setFocusable(false) for å la
tastaturet «hoppe over» knappen. Dermed blir navigeringen raskere.
FIGUR 116: «IKKE FERDIG» ER DEAKTIVERT. DA KAN MAN IKKE NAVIGERE TIL KNAPPEN MED TASTATURET.
13.12
Testing
I dette kapittelet blir det beskrevet hva slags testing som er utført og en oversikt over
testresultatene. Dette er gjort for å kvalitetssikre produktet og meningen er å avdekke feil som ikke
ble funnet under utviklingen. Testingen er utført på det produktet som er levert til oppdragsgiver.
Digitus er testet med fire ulike nettbrett:




Samsung Galaxy Tab S 8.4" (SM-T700)
Samsung Galaxy Tab 10.1" (GT-P7510)
Samsung Galaxy Tab 4, 10.1" (SM-T530)
Samsung Galaxy Note Pro 12.2" (SM-P900)
I tillegg til de fysiske nettbrettene er dagsplanen testet med Android-emulatoren som følger med i
Android SDK. Følgende Android API-versjoner er testet:







API 15
API 16
API 17
API 18
API 19
API 20
API 21
Android 4.0.3-4.0.4 (Ice Cream Sandwich)
Android 4.1-4.1.2 (Jelly Bean)
Android 4.2-4.2.2 (Jelly Bean)
Android 4.3-4.3.1 (Jelly Bean)
Android 4.4-4.4.4 (KitKat)
Android 4.4W-4.4W.2 (KitKat)
Android 5.0-5.0.2 (Lollipop)
106
13.12.1
Velkomstmodus
Funksjonalitet
Test
Resultat
Opprette ny bruker
Opprett en ny bruker og logg inn med den i adminmodus.
OK
13.12.2
Ukesmodus
Funksjonalitet
Test
Resultat
Vise ukesoversikt
Sjekk at ukesoversikt, inkludert oversikt over hvilke aktiviteter
som er fullført og ikke vises.
OK
Navigasjon
Navigere til forrige/neste uke og til ukesmodus.
OK
Vise hvilken dag som
er i dag
Sjekk at «i dag» er markert med annen bakgrunnsfarge.
OK
13.12.3
Dagsmodus
Funksjonalitet
Test
Resultat
Navigasjon
Navigere til forrige/neste dag og tilbake til ukesmodus.
OK
Fullføre aktivitet
Sjekke at aktivitet blir markert som ferdig og at man blir flyttet til
neste aktivitet.
OK
Fjern fullført
aktivitet
Sjekke at en aktivitet som er markert som fullført kan bli «ikke
fullført» ved å trykke på «Ikke ferdig»-knappen.
OK
Bistand
Sjekke at bistand-vindu dukker opp, at tilgjengelig-status er riktig
og at det er mulig å ringe til kontakter.
OK
Sjekklister
Sjekke at det er mulig å huke av/fjerne avhukninger for
delhandlinger.
OK
Handlingskjeder
Sjekke at det er mulig å navigere fram/tilbake i handlingskjeder via OK
«Fullført»/«Ikke fullført»-knapper.
107
13.12.4
Adminmodus
Funksjonalitet
Test
Resultat
Logge inn
Logge inn med brukernavn og passord.
OK
Navigasjon
Navigere til «Innstillinger», «Brukere» og «Endre plan».
OK
Legge til aktivitet
Legge til aktivitet i dag, med overskrift, beskrivelse og bilde.
OK
Legge til
handlingskjede
Legge til handlingskjede med tre delhandlinger.
OK
Legge til sjekkliste
Legge til sjekkliste med tre delhandlinger.
OK
Endre eksisterende
aktivitet
Skift ut overskrift, beskrivelse og bilde for eksisterende
aktivitet. Slett eksisterende handlingskjede, gjør om til
sjekkliste. Legg til tre delhandlinger.
OK
Slette aktivitet
Slett en aktivitet, sjekk at den forsvinner fra planen.
OK
Aktivere/deaktivere
funksjoner
Sjekk at bistand via Skype, navigasjonsfelt, sveip, fargekoder,
kontekstmeny for handlingskjeder og nedtelling kan skrus på
via adminmodus og fungerer som det skal.
OK
Last inn eksempelplan
Last inn eksempelplan og sjekk at alle eksisterende aktivteter
forsvinner, og eksempelplan lastes inn.
OK
Fjern alle aktiviteter
Fjern alle aktiviteter fra databasen (via knapp i
«Innstillinger»), sjekk at alle aktiviteter forsvinner fra planen.
OK
Legg til ny bruker
Legg til en ny bruker med alle felt, inkludert bilde, utfylt.
OK
Endre bruker
Endre bilde, fullt navn, brukernavn, passord og Skype-id.
OK
Slett bruker
Slett bruker via brukeradministrasjon.
OK
Logge ut
Logge ut fra adminmodus.
OK
108
13.12.5
Resultater fra testing
Testingen ga en bekreftelse på at all hovedfunksjonalitet fungerer uten feil på de testede Androidversjonene. Applikasjonen skalerte godt på alle de forskjellige skjermstørrelsene, og kravet om at
applikasjonen skal fungere på 8"-12"-skjermer er dermed oppfylt. Applikasjonen oppførte seg
identisk uavhengig av skjermstørrelse og Android-versjon.
109
14
Referanser
Andresen, M. L., Løkke, J. A., & Løkke, G. E. (2013). Tegnøkonomi og påvirkning av
oppmøte etter friminutt i en barneskoleklasse.
Bouch, A., Kuchinsky, A., & Bhatti, N. (2000, April). Quality is in the eye of the beholder: meeting
users' requirements for Internet quality of service. In Proceedings of the SIGCHI conference
on Human Factors in Computing Systems (pp. 297-304). ACM.
Brady, L., & Phillips, C. (2003). Aesthetics and usability: A look at color and balance. Usability News,
5(1), 2003.
Burns, J. (2008). Developing secure mobile applications for Android.
Finstad, J. (2001). Avtalestyring - en beskrivelse. Diskriminanten, 28, 2, 39–55.
Hourcade, J. P., Bullock-Rest, N. E., & Hansen, T. E. (2012). Multitouch tablet applications
and activities to enhance the social skills of children with autism spectrum
disorders. Personal and ubiquitous computing, 16(2), 157-168.
Miller, G. A. (1956). The magical number seven, plus or minus two: some limits on our capacity for
processing information. Psychological review, 63(2), 81
O'Malley, P., Lewis, M. E. B., & Donehower, C. (2013). Using Tablet Computers as Instructional Tools
to Increase Task Completion by Students with Autism. Online Submission.
Preece, J., Rogers, Y., Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, New
York: Wiley, p.21
Sandnes, F. E. (2011) Universell utforming av IKT-systemer: brukergrensesnitt
for alle. Oslo: Universitetsforlaget.
Shneiderman, S. B., & Plaisant, C. (2005). Designing the user interface 4 th edition. ed: Pearson
Addison Wesley, USA.
110
15
Brukerveiledning
I denne brukerhåndboken blir det trinnvis beskrevet hvordan man tar i bruk Digitus Dagsplan og dens
funksjoner. Applikasjonen er designet for å brukes horisontalt og støtter alle Androidbaserte
nettbrett med versjon 4.0.3 eller høyere. Brukerhåndboken består av to deler; en brukerdel som er
beregnet for brukere, og en administrasjonsdel som er beregnet for bistandsytere.
15.1 Brukerdel
Under beskrives navigasjonen for ukes- og dagsmodus i applikasjonen.
1. Brukes for navigering mellom
uker.
2. Velges for å komme til
administrasjonsdelen.
3. Viser oversikt over en
ukeplan.
4. Viser oversikt over en
dagsplan.
5. Viser et gjøremål.
1. Velges for å komme til
ukeplanen.
2. Brukes for navigering mellom
dager.
3. Velges for å ringe etter
assistanse.
4. Viser oversikt over dagens
aktiviteter.
5. Brukes for å fullføre/fjerne
fullført-status.
6. Viser oppgavene i
handlingskjeden og hvor du
befinner deg.
111
Hvordan fullføre gjøremål?
Trykk «Ferdig» etter å ha fullført et
gjøremål.
Hvordan angre utført gjøremål?
Etter å ha valgt det gjøremål som
skal angres, trykk «Ikke ferdig».
Avhukingen for gjøremålet vil
forsvinne, og det blir igjen mulig å
trykke på «Ferdig»-knappen.
112
15.1.2 Navigering
Hvordan bytte uke?
Dra fingeren langs det blå
toppfeltet i ukesmodus for å bytte
uke. Man kan også bruke pilene
som står ved siden av
ukenummeret.
Hvordan bytte dag?
Dra fingeren langs det blå
toppfeltet i dagsmodus for å bytte
dag. Man kan også bruke pilene
som står ved siden av ukedagnavnet, i dette tilfellet «Onsdag».
Hvordan navigere mellom gjøremål?
Bruk den venstre menyen for å
navigere til et annet gjøremål.
113
15.1.3 Hvordan komme til neste steg i en handlingskjede?
Trykk på den grønne knappen
«Ferdig», for å fullføre
deloppgaven. Ved å trykke her blir
du sendt til neste deloppgave.
15.1.4 Hvordan gå tilbake et steg i en handlingskjede?
Dersom du ønsker å gå tilbake i
handlingskjeden må du trykke «Ikke
ferdig».
114
15.1.5 Hvordan fullføre en delhandling i sjekkliste?
Trykk på teksten eller bildet for en
delhandling for at den skal bli
fullført.
Ved fullføring vises et sjekk-symbol
over bildet.
15.1.6 Hvordan angre fullføring av delhandling i sjekkliste?
Du kan angre i sjekklisten ved å
trykke på et gjøremål som allerede
er huket av.
115
15.1.7 Nedteller
Hvordan starte nedtelleren?
Trykk på «Start»-ikonet i
nedtellingsfeltet for å starte
nedtelleren.
Applikasjonen vil lage en lyd når
nedtellingen er fullført.
Hvordan pause nedtelleren?
Nedtellingen kan settes på pause
ved å trykke på «Pause»-ikonet.
116
15.1.8 Hvordan ringe bistandsytere, familie eller venner?
Trykk på «Hjelp»-knappen øverst i
høyre hjørne i dagsmodus.
Trykk på bildet av den du vil ringe.
Da vil kontakten umiddelbart ringes
opp.
Grønn telefon viser at personen kan
ringes.
Rød telefon viser at personen ikke
kan ringes.
117
15.1 Administrasjonsdel
Trykk for å komme til forsiden
av administrasjonen - ukeplan
Trykk for å logge ut
Trykk for å se ukeplan
Trykk for å legge til/endre aktivitet
Trykk for å se/endre brukere
Trykk for å endre
innstillinger
Første gang Digitus Dagsplan startes må en
brukerkonto for en bistandsyter opprettes. For
å komme til opprettelsessiden må du trykke
«Lag ny bruker».
For å opprette en administrator må skjemaet
vist i bildet til venstre utfylles. Alle felt unntatt
«Skype-brukernavn» må utfylles. Sjekkboksene
til høyre for tekstfeltene blir grønne når de er
godkjent. For å se kravene kan sjekkboksene
trykkes.
Når all informasjon er fylt ut må «Lag ny
bruker» trykkes for å lagre.
118
Hvordan logge inn?
For å komme til innloggingssiden
må du trykke på nøkkelen øverst til
høyre i ukesmodus.
Skriv inn ditt brukernavn og
passord i feltene og trykk deretter
«Logg inn».
Hvordan logge ut?
Øverst til høyre i hver side i
adminmodus er det en «Logg ut»knapp. Ved å trykke på denne blir
du logget ut og sendt til
ukesmodus.
119
Hvordan opprette ny administrator?
Velg brukere i venstremenyen,
deretter trykk «Lag ny bruker»
nederst på siden.
Ta et bilde av brukeren ved å trykke
«Ta bilde». Alle felt unntatt «Skypebrukernavn» må utfylles.
Sjekkboksene til høyre for
tekstfeltene blir grønne når de er
godkjent. For å se kravene kan
sjekkboksene trykkes.
Når all informasjon er fylt ut må
«Lagre bruker» trykkes.
Hvordan endre administratorbruker?
Velg den brukeren du vil endre ved
å trykke på bildet eller tilhørende
tekst.
120
Endre informasjonen som skal
rettes, deretter trykk «Lagre
bruker».
Hvordan slette en administratorbruker?
Trykk «Slett»-knappen for å slette
brukeren.
Bekreft «Ja» på spørsmål om du vil
slette brukeren.
121
15.1.2 Aktiviteter
Hvordan opprette en aktivitet?
Opprett en aktivitet ved å trykke
«Legg til» under ønsket dag nederst
i ukeplanen.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Skriv inn navn for aktivitetet.
Skriv inn en beskrivelse for aktiviteten.
Ta et bilde for aktiviteten ved å trykke «Ta bilde»-knappen.
Velg «Legg til»-knappen om du vil legge til en hjelpeliste sammen med aktiviteten.
Trykk «Slett siste» for å fjerne den siste delaktiviteten i hjelpelisten.
Trykk på «Info om hjelpelister» for å lese mer om forskjellen på en handlingskjede og en
sjekkliste.
Ved å huke av vil delaktivitetene vises som en handlingskjede, ellers vises den som en
sjekkliste.
Trykk for å ta et bilde av delaktiviteten.
Legg til overskrift for delaktiviteten.
Trykk «Lagre» for å opprette aktiviteten.
122
Hvordan endre en aktivitet?
Trykk på aktiviteten du vil endre fra
ukesoversikten.
Her kan du endre aktiviteten, likt
som for opprettelse av aktiviteter.
Endre ønskede felter og trykk
«Lagre»-knappen.
Dersom det finnes flere identiske
aktiviteter plassert på ulike dager
må du bestemme om du ønsker å
endre for kun en bestemt dag eller
alle aktiviteter.
123
Hvordan slette en aktivitet?
Trykk på den aktiviteten du vil
slette.
Trykk på den røde «Slett»-knappen.
Bekreft med «Ja» for å slette
aktiviteten.
124
15.1.3 Innstillinger
Hvordan skru av/på funksjoner?
Skru på ønsket funksjonalitet ved å
dra bryteren til høyre. Skru av ved å
trekke til venstre.
Ved å trykke på funksjonsnavnet
dukker det opp en beskrivelse av
hva funksjonen gjør.
Hvordan laste inn en eksempelplan?
Trykk på knappen «Last inn
eksempelplan» for å laste inn en
uke med eksempelaktiviteter.
Disse kan brukes for å prøve seg
fram i planen uten å ha virkelige
aktiviteter å jobbe med.
Ved å laste inn eksempelplanen
blir alle eksisterende aktiviteter i
planen slettet. Handlingen må
derfor bekreftes ved å trykke «Ja»
i en dialogboks som dukker opp.
Hvordan slette alle aktiviteter?
Trykk på knappen «Slett alle
aktiviteter» for å slette alle
aktiviteter fra planen.
Handlingen må bekreftes ved å
trykke «Ja» i en dialogboks som
dukker opp.
125
16
Vedlegg
16.1 Vedlegg 1: Attest fra oppdragsgiver
126
16.2 Vedlegg 2: Risikoplanlegging
Alle prosjekter har en risiko og det er evnen til å løse problemer før de oppstår som er med på å
definerer et godt gjennomført prosjekt. Ved å lage en risikoplan kan vi forebygge problemer som
oppstår eller allerede har oppstått. Vi mener at fravær, tekniske problemer, gratispassasjerer og
tidsmangel er de største farene for dette prosjektet.
Risiko
Beskrivelse av risikoen
Hvor stor er
Sannsynligheten?
Hva er
konsekvensen?
Hvordan
forebygger vi?
Tap av
gruppemedlem
Ett eller flere
gruppemedlemmer trekker
seg fra gruppa eller studiet.
Lav
Færre tanker og ideer
om prosjektet. Mer
jobbing på de
gjenværende.
Ha god
kommunikasjon
gjennom hele
prosessen.
Dersom dette
oppstår må vi ha
en plan B og
omfordele
arbeidet for å
forhindre store
opphold i
arbeidet.
Gratispassasjer
En eller flere
gruppemedlemmer bidrar i
svært liten grad eller ikke
møter opp på gruppemøter.
Lav/moderat
Dårlig stemning i
gruppa. De som bidrar
får mer å gjøre, men
lærer også mer. De
som ikke deltar har
lite læringsutbytte.
Ha en utfyllende
samarbeidsavtal
e som er klar på
at alle må bidra.
Hvis ikke vil det
bli
konsekvenser.
Tekniske
problemer
Tekniske problemer som
harddiskkrasj og tap av
internettforbindelse.
Moderat
Ting må gjøres om
igjen. Arbeidet blir
utsatt.
Lagre alt
arbeidet på
Dropbox, slik at
alle har en lokal
kopi av arbeidet.
Tap av tid og
ressurser.
Dårlig
kommunikasjon
Dårlig kommunikasjon innad
i gruppa, for eksempel
krangler eller uenigheter.
Lav/moderat
127
Ting tar generelt
lenger tid, spesielt
møter.
Lytte til
hverandre,
komme med
konstruktiv
kritikk. Ha
Tidsmangel
Fravær
For lite kunnskap og/eller tid
til å fullføre oppgaver til
fastsatte tider.
Lav/moderat
Sykdom, ferie og andre ting
som gjør at en eller flere ikke
kan møte eller utføre
oppgavene sine innen
fastsatt tidsfrist.
Moderat
Dårlig stemning i
gruppa.
respekt for
andres
menigheter.
Mye stress og intensiv
jobbing.
Starte å jobbe
med arbeidsoppgaver tidlig.
Fordele
oppgavene mest
mulig likt.
Stort press på hver
enkelt for å bli ferdig.
Det blir skjev
arbeidsfordeling.
Ikke planlegg
ferier eller andre
tidkrevende ting
i arbeidsperioden.
Gi beskjed god
tid i forveien.
128
16.3 Vedlegg 3: Samtykkeskjema for brukertest
Brukertest for å undersøke et mulig grensesnitt for en dagsplanapplikasjon for nettbrett, laget av
studenter ved Høgskolen i Oslo og Akershus i samarbeid med Oslo universitetssykehus. Prosjektet er
vår hovedoppgave på Høgskolen i Oslo og Akershus våren 2015.
Testundersøkere:
Kristoffer Hagen
Steffen Engebretsen
Harald S. Adamsen
David Meisund
epost: [email protected]
epost: [email protected]
epost: [email protected]
epost: [email protected]
Formålet med brukertesten er å få tilbakemeldinger på en prototype for dagsplanapplikasjon for
nettbrett som gruppen har laget i samarbeid med avdeling for nevrohabilitering ved Oslo
universitetssykehus. Det er viktig å presisere at det ikke er du som blir testet, men grensesnittet til
prototypen. Hovedhensikten med testen er å få tilbakemelding på utformingen og eventuelt finne
feil og mangler i applikasjonen.
Gjennomføringen av brukertesten vil foregå på HiOA (iLab, rom P35-PS323), ______________(dato).
Testen går ut på å teste et brukergrensesnitt for dagsplanapplikasjonen, og sammenligne dette med
det som brukes i dag. Du vil bli gitt fire oppgaver, der det eneste hjelpemiddelet du kan bruke er
applikasjonen. Vi ønsker også å vise noen alternative løsninger på utforming for å få tilbakemelding
på hvordan det oppleves. All deltakelse i testen er frivillig, og du kan når som helst velge å trekke
deg. Dersom du ikke ønsker å foreta en oppgave eller trekke tilbake informasjon som er gitt under
testen er dette mulig. Det vil bli tatt bilder under brukertesten.
Fordelen med å delta i brukertesten er at det vil hjelpe oss i det videre arbeidet med applikasjonen,
noe som kan resultere i en bedre tilpasset app for deg som bruker.
Taushetsplikt. All informasjon som blir samlet inn under brukertesten vil være konfidensiell. Ingen
publikasjoner vil inneholde informasjon som kan identifisere hvem du er. Eventuelle bilder som blir
tatt under brukertesten vil ikke kunne identifisere deg. Innhentet informasjon vil bli behandlet etter
Personopplysningsloven, § 8 (behandling av personopplysninger) og § 9 (behandling av sensitive
personopplysninger).
Jeg har lest og forstått informasjonen over og gir mitt samtykke til å delta i brukertesten:
_
___
Deltaker/foresatt signatur
Dato
129
Testleders signatur
.