BACHELORPROSJEKT. SeniorPost PROSJEKT NR. Studieprogram: Anvend Datateknologi. Offentlig. Telefon: Telefaks: DATO

Transkript

1

2 PROSJEKT NR. 13 Studieprogram: Anvend Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT TILGJENGELIGHET Offentlig Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL SeniorPost PROSJEKTDELTAKERE Kristian Aamodt Grande Henning Corneliussen Mohammed Bilal Khan DATO ANTALL SIDER / BILAG 162 INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Seniornett KONTAKTPERSON Tore Langemyr Larsen SAMMENDRAG Vi har utviklet et testmiljø av digipost.no som skal benyttes til å lære opp seniorer og hjelpe seniorbrukere med å føle seg trygge på internett. 3 STIKKORD Digipost Opplæringsplattform Seniorer 2

3 Link til nettside: Forord Dette dokumentet er en endelig sluttrapport av vårt hovedprosjekt ved Høgskolen i Oslo og Akershus våren Sluttrapporten er utarbeidet i forbindelse med utviklingen av et testmiljø av Digipost.no som skal benyttes til opplæring av seniorer i samfunnet. Leserveiledning Dette dokumentet inneholder følgende delrapporter i denne rekkefølgen: - Presentasjon: her kan en raskt sette seg inn i hvem oppdragsgiver er, hvem gruppen er og hva bakgrunnen for oppgaven har vært. - Prosessdokumentasjon: her beskrives prosessen gjennom prosjektperioden. - Produktdokumentasjon: her beskrives sluttproduktet. - Testdokumentasjon: her dokumenteres all testing av produkt som er blitt gjennomført. 3

4 Innholdsfortegnelse Link til nettside:... 3 Forord... 3 Leserveiledning... 3 Innholdsfortegnelse... 4 Presentasjon... 1 Startsfase... 8 Systembeskrivelse Innholdsfortegnelse Prosessdokumentasjon Innholdsfortegnelse Produktdokumentasjon Innholdsfortegnelse Testdokumentasjon Innholdsfortegnelse Kilder... i Vedlegg:... iii 4

5 Presentasjon Innledning Prosjektgruppen består av Henning Corneliussen, Mohammed Bilal Khan og Kristian Aamodt Grande. Alle medlemmene er fra studieprogrammet Anvendt datateknologi ved Høgskolen i Oslo og Akershus. Medlemmene har fordypet seg innenfor programmering, universell utforming, systemutvikling og evaluering av datasystemer gjennom studieløpet. Gruppen har tidligere jobbet sammen i andre fag. Gruppens leder er Henning Corneliussen. Vi skal i samarbeid med Seniornett og TurboDevs utforme et testmiljø av digipost sine nettsider. Dette skal brukes til å gi opplæring til eldre i samfunnet. Grensesnittet skal gi en identisk brukeropplevelse som den man får ved å bruke det opprinnelige nettstedet. Her skal feil testes og forkastes uten form for konsekvenser. 1

6 Prosjektets deltakere Studentgruppen Gruppen ble kjent med hverandre i løpet av første semester, og er nå gode venner både i og utenfor skolesammenheng. Gjennom disse tre årene har vi arbeidet sammen på flere prosjekter i flere fag og kjenner hverandres styrker og svakheter godt. I den sammenheng falt det naturlig å fortsette med samarbeidet på hovedprosjektet. Vi har alle likt ambisjonsnivå og like tanker om hvor stor arbeidsmengde vi ønsker å legge ned i prosjektet. I tillegg har vi både felles og forskjellige interessefelter, noe som gjør at vi passer godt sammen i prosjektsammenheng. Henning er prosjektleder og har ved tidligere prosjekter også innehatt denne rollen i gruppen. Han har hovedansvaret for utforming og planlegging av testmiljøet samt grafiske elementer prosjektet trenger. 2

7 Kristian har hovedansvaret for å lese igjennom og strukturere dokumenter. Videre skal han ha hovedansvar for å konstruere og gjennomføre brukertesting og holde kontakten med aktuelle interessenter. Bilal har hovedansvaret for at alt blir gjennomført i henhold til arbeidsplanen samt at loggboken blir holdt oppdatert. Han skal ha hovedansvar for utviklingen av en Androidapplikasjon og ta notater på vegne av gruppen når det er nødvendig samt at han skal sørge for innhenting av nødvendige artikler og pensum. Han skal også sørge for at tidsfrister overholdes og at innleveringer skjer til tide. Oppdragsgiver Seniornett jobber med opplæring av eldre databrukere i hele landet. Seniornett ble startet opp i 1997, og har vunnet flere priser inkludert folkeopplysningsprisen i (Seniornett, ). Seniornett består av totalt 217 foreninger hvor 215 er i Norge og to er utenlandske foreninger som holder til på feriesteder i Spania, slik som Gran Canaria. (Seniornett, udatert) Formålet til Seniornett er å bidra til at seniorer (55+) deltar aktivt i informasjons- og kommunikasjonssamfunnet. Seniornett holder kurs for nybegynnere, og videregående kurs for de som allerede har blitt litt kjent med data som verktøy. Deres erfaringer viser at mange brukere kan ha nytte av å lære seg bruk av dataverktøy gjennom å prøve og feile. Alt fra elementær innføring, opplæring og støtte, til å hjelpe hobbybrukere innen områder som for eksempel digital bildebehandling og bruk av sosiale medier. 3

8 Bakgrunn for prosjektet Bakgrunnen for at prosjektet skal gjennomføres er at gruppens medlemmer er i ferd med å avslutte en bachelorgrad i Anvendt datateknologi. I den forbindelse skal gruppen i samarbeid med Seniornett og TurboDevs utforme et testmiljø av digipost sine nettsider. Digipost er en digital postkasse hvor man mottar post i en egen sikker digital postkasse. Digipost brukes av bedrifter, offentlige virksomheter og privatpersoner. Seniornett ønsker at flere og flere eldre skal ta i bruk de digitale tjenestene som benyttes i samfunnet i dag. På bakgrunn av det ønsker de å utvikle et testmiljø av digipost der de eldre kan prøve og feile. Den eldre generasjonen kan ansees som veldig forsiktig med håndtering av persondata, så det vil derfor være viktig at det utformes et testmiljø der man klarer å overbevise brukerne om at dataene de skriver inn ikke blir misbrukt. Det skal lages et enkelt grensesnitt som er mest mulig like de ordinære sidene. Grensesnittet vil kun bli brukt til opplæring og testing, så det kan utvikles som ønsket av prosjektgruppen og oppdragsgiveren. Det vil bli rettet spesiell oppmerksomhet mot registrering og innloggingsdelen, slik at eldre enklere kan få størst mulig nytte ut av testmiljøet. 4

9 Beskrivelse av TurboDevs TurboDevs AS ble grunnlagt av gruppen bak bachelorprosjektet EEGBliss på Høgskolen i Oslo og Akershus Selskapet har som mål å videreutvikle konseptet bak EEGBliss til et ferdig produkt. TurboDevs har fire ansatte, hvor alle er tidligere studenter ved HiOA. TurboDevs har ved en tidligere anledning jobbet sammen med to av gruppemedlemmene på et prosjekt for HiOA. Gjennom dette prosjektet ble bachelorprosjektet Seniornett presentert. Våre kontakter hos Turbodevs er Nina Bauge og Jan O.L Andersen. De har begge vært i samme situasjon som vi befinner oss i nå og skrev selv bacheloroppgaven sin for noen år tilbake. Dette gir dem god innsikt til å bistå der det er behov for det, samt komme med gode ideer og forslag. Mål Norge har i dag over 1.3 millioner seniorer og nesten en tredjedel av disse har ingen kjennskap til PC eller internett. Ca mennesker i Norge har for svake IKT ferdigheter (Seniornett presentasjon, Vedlegg 8). Hovedmålet med prosjektet for er at det utformes et testmiljø av digipost der de eldre helt uten bekymringer kan prøve og feile. Dette produktet skal benyttes i opplæring av seniorer i bruk av digipost. På digipost kan alle brukere åpne og lese posten sin både på egen datamaskin, nettbrett eller smarttelefon. Brukeren vil kun trenge tilgang til internett, og kan når som helst få tilgang til all offentlig post gjennom denne trygge tjenesten. For å kunne bruke digipost må en bruker selv opprette en digital postkasse gjennom digipost.no. Dokumentene du har fått tilsendt digitalt blir lagret i den digitale postkassen som i et arkiv, og kan senere leses eller slettes slik som et vanlig e-post system. Denne tjenesten kan bli benyttet av bedrifter, offentlige virksomheter, banker og privatpersoner. Alle brukere kan legge til flere postkasser under et og samme fødselsnummer, for eksempel hvis man har en postkasse privat og en for bedrift. 5

10 Fra 20. januar 2015 begynner NAV å sende ut utbetalingsblanketter digitalt til alderspensjonister og uføretrygdede som brukte digital postkasse (Regjeringen, ). Dette ble sagt i en pressemelding fra regjeringen som ble sendt ut Her var det uttalte målet at i løpet av 2015 skulle store deler av staten begynne å sende brev digitalt til landes innbyggere. Videre vedtok regjeringen og besluttet at staten, og statlige etater som da sendte ut papirpost, skulle ta i bruk digital post senest i I løpet av 2015 ville om lag 30 offentlige etater bli med, og i dag har flere små og store bedrifter begynt med det samme. Årlig sender staten 125 millioner brev og bruker én milliard kroner på porto. Dette i selv er en av de store årsakene for at regjeringen ønsker at flere etater, skoler og andre offentlige institusjoner tar i bruk digital postkasse. (Regjeringen, ). Etter at bachelorprosjektet hadde blitt startet, vedtok HiOA at også de skulle starte å sende ut post elektronisk til studenter og tilsatte. Innen 1. juni 2016 skal HiOA og andre offentlige organer benytte seg av digital kommunikasjon som hovedkanal for å kommunisere med innbyggerne. I første omgang gjelder dette derimot ikke vitnemål eller karakterutskrift. Når alt vil bli tatt i fullt bruk er ennå ukjent for oss, men dette er også en del av Digitaliseringsstrategi til regjeringen som ble vedtatt i 2015, og HiOA har altså blitt en del av det (Høgskolen i Oslo og Akershus, ). Dette vil gjøre vårt prosjekt veldig aktuelt, da det er store krefter i gang med å endre vårt dagligliv, når vi ikke lenger må sjekke postkassen for brev. Vi skal gjennom prosjektet utvikle en nettbasert løsning basert på digipost.no og teste dette på eldre brukere. Dette vil være med på å lære opp flere i den eldre generasjonen med å bruke digipost og digital postkasse, og hjelpe til med å få flere seniorbrukere til å føle seg trygge på internett. Det at seniornett får tilgang på et slikt testmiljø gjør at de kan starte opp flere kursaktiviteter for å hjelpe seniorer på nett. Når samfunnet nå kun går i den retningen hvor alt sakte men sikkert blir digitalisert, er det viktig at man ikke glemmer de menneskegruppene som ikke er like vant til, og komfortable med at alt digitaliseres, slik som den yngre generasjon er. 6

11 Kort presentasjon av sluttproduktet Det er utviklet et testmiljø som er mest mulig lik digipost.no sine websider. Testmiljøet vil være spesielt rettet mot eldre mennesker som har svake IKT ferdigheter og ikke føler seg trygge på internett. Det er derfor viktig å utvikle gode feilmeldinger og enkle steg for steg prosedyrer. Med tanke på at eldre ikke føler seg trygge med å gi bort persondataene sine vil det ideelt sett ikke bli lagret noe som helst informasjon. Sluttproduktet består av et web-basert testmiljø, som også er tilpasset til bruk på mobile enheter, og en applikasjon. Applikasjonen er ikke tilgjengelig på det åpne markedet, men vil bli vist frem under presentasjonen torsdag 09. Juni I tillegg til dette har vi skrevet denne rapporten for å beskrive systemet og arbeidet som er blitt lagt ned under utviklingen av systemet. 7

12 Startsfase Fremdriftsplan Arbeids og fremdriftsplan Gruppe 13, Bachelorprosjekt ved HiOA 2016 Planen har vært veiledende og er blitt endret underveis i prosjektet. Fase Varighet Faktisk varighet Beskrivelse Oppstart 13/01 13/01 Oppstartfasen, møte med gruppemedlemmer og arbeidsgiver skal gjennomføres. Starte arbeidet med prosjektplan og forprosjektrapport. Forprosjekt 13/01-22/01 Rapportskriving Startsfase 25/01-14/02 Utviklingsfase 1 15/02-06/03 13/01-22/01 22/01-18/05 04/02-08/02 09/02-24/02 Utforme og levere forprosjektrapport. Møte med veileder. Skriving av rapport fortløpende gjennom hele prosjektet. Møte med Seniornett. Oppsamling av informasjon i samarbeid med arbeidsgiver. Utforming av papirprototyper. Planlegging av brukerundersøkelse. Starte med utforming av nettbaserte løsningen. Brukertesting med Seniornett personal. Brukertestingsfase 1 07/03-08/03 25/2 Brukertesting av den nettbaserte løsningen på eldre brukere. Utviklingsfase 2 09/03-21/03 Påskeferie 22/03-29/03 07/03-06/04 Utvikling av nettløsningen basert på brukertestingsfase 1. - Brukertestingsfase 2 30/03-31/03 07/04 Brukertesting av den nettbaserte løsningen del 2 Utviklingsfase 3 01/04-22/04 Avsluttende fase 25/04-15/05 Ferdigstilling 16/05-23/05 08/04-29/04 02/05-13/05 16/05-20/05 Bugfiksing ol. Fasen er stor for å ta høyde for andre valgemner og rapportskriving. Gjennomgang av all kode, dokumentasjon og rapportskriving Siste finpuss på kode og dokumentasjon 8

13 Gantt diagram Figur 1 - Gantt diagram av fremdriftsplanen Ovenfor har vi satt fremdriftsplanen inn i et Gantt diagram. Dette diagrammet har vi oppdatert underveis i prosjektperioden. Diagrammet viser når vi har planlagt oppstart av de ulike aktivitetene, planlagt varighet, når vi faktisk startet aktivitetene og hvor lenge aktivitetene faktisk varte. De forskjellige fargene på en søyle har forskjellige betydninger. Der hvor søylene er fylt med farge, enten lilla eller oransje, viser hvilke uker som det faktisk er blitt arbeidet med de ulike aktivitetene. Den oransje fargen er der for å vise når vi har oversteget den planlagte tiden, eller om vi har startet før planlagt. Den lilla fargen viser tiden vi har arbeidet innenfor den planlagte tiden. Videre finnes det felter i søylene som ikke er fylt med hel farge, men kun består av delvis fylt farge. Disse feltene viser områder hvor vi hadde planlagt å arbeide med aktiviteter, men hvor det ikke er blitt arbeidet med de forskjellige aktivitetene. 9

14 For eksempel hvis man ser på aktiviteten utviklingsfase 1. Her planla vi å starte opp i uke 6 og arbeide i 3 uker. Vi hadde faktisk oppstart med aktiviteten i uke 5, og arbeidet i 2.5 uker. Dermed er det i blitt lagt til en oransje bit på fronten av søylen, som viser hvor vi faktisk startet arbeidet, før det kommer en lilla bit. Den oransje og lilla biten sammen viser når vi faktisk arbeidet med prosjektet. Etter den lilla delen kommer det så en del som kun er delvis fylt med farge. Dette er for å vise tiden vi egentlig hadde planlagt å arbeide med aktiviteten, men hvor det ikke er blitt arbeidet med aktiviteten. 10

15 Risikoanalyse Risikofaktor Indikator Risiko Konsekvens Tiltak for å redusere risiko Får ikke kontakt med Seniornett Sykdom/ fravær Seniornett svarer ikke på mail og er vanskelige å få tak i Noen av medlemmene blir syke i løpet av prosjektperioden Lav Alvorlig Må forsøke å holde jevnlig kontakt med Seniornett Lav Ubetydelig Gruppemedlemmet skal kunne jobbe hjemmefra om mulig. Hvis dette ikke lar seg gjøre, må medlemmets ansvarsområder fordeles på resten. Tap av data Seniornett nedprioriterer gruppen TurboDevs nedprioriterer gruppen Turbodevs trekker seg ut Seniornett trekker seg ut Data det har blitt arbeidet med bli borte Seniornett involverer seg minimalt i prosjektet TurboDevs arbeider med mange andre prosjekter samtidig TurboDevs har for mye annet å drive med Seniornett ønsker ikke lenger å være en del av prosjektet Lav Katastrofal Data Lagres på cloud og rapporten lagres flere steder. Moderat Tolererbart Ikke legge for mye press på Seniornett Moderat Tolererbart Må bruke veileder og TurboDevs aktivt Lav Tolererbart - Moderat Alvorlig/tolererbart Hvis Seniornett trekker seg ut før vi tar et møte, blir konsekvensen mer alvorlig. 11

16 Får ikke tilgang på brukergruppe Konflikter innad i gruppen Frafall av gruppemedlem Gruppen får ikke tilgang på brukergruppe til brukertesting Noen av gruppens medlemmer har uenigheter Et medlem av gruppen avslutter trekker seg fra bachelorprosjekt før ferdigstillelse. Lav Alvorlig Gjøre gode forberedelser før brukertesting Lav Tolererbart Være ærlige og møte opp til oppsatte tider. Lav Katastrofal Opprettholde god moral innad i gruppen. Viktig med god kommunikasjon. Katastrofal konsekvens siden gruppen bare har 3 medlemmer. 12

17 Systembeskrivelse 13

18 Innholdsfortegnelse Sitemap Rammekrav Sikkerhet Sikkerhet rundt appen Mulige fremtidige utvidelser eller endringer Brukervennlighet Brukerhistorier Use case Use case beskrivelse Aktivitetsdiagram registrering Registreringssekvens

19 Sitemap Figur 2 - Sitemap over testmiljøet 15

20 I figur 2 har vi lagd et sitemap for å vise hvordan testmiljøet er bygd opp og hvordan ulike sider henger sammen. Brukeren starter på indexsiden, som er forsiden i testmiljøet. Derfra har brukeren mulighet til å gå til enten registeringssiden eller siden for innlogging. Dersom brukeren går til registeringssiden vil brukeren følge de angitte stegene nedover i testmiljøet og gjennom BankID stegene før brukeren til slutt etter å ha fullført registreringen ender opp på innloggingssiden. Hvis brukeren derimot allerede er registrert og velger å gå rett til innloggingssiden, har man tre ulike valg man kan gjøre. Man kan enten velge å logge inn med eller uten BankID, eller så kan man, om man har glemt passordet sitt eller ønsker å trene på å endre passordet, velge glemt passord funksjonen for å endre passordet sitt. Om brukeren velger å logge inn uten bruk av BankID vil brukeren autentisere seg via fødselsnummeret sitt og passordet man lagde seg da man registrere. Når brukeren er autentisert vil brukeren komme til sin personlige postkasse. Velger man innlogging med BankID eller glemt passord, så vil man gå igjennom de samme stegne på begge funksjonene. Gjennom innlogging med BankID logger man seg naturlig nok inn via BankID og kommer til sin personlige postkasse. Det som skjer om man velger glemt passord er at brukeren logger inn med BankID, men etter at man har logget inn gjennom å trykket på glemt passord, vil man ende opp på siden for å endre passord. 16

21 Rammekrav Sikkerhet Siden gruppen tidlig oppdaget at seniorer var veldig opptatt av sikkerhet, var det viktig at nettsiden ble laget med sikkerhet i tankene. På den første brukertesten skal ingen data lagres, og all data skal være fiktiv. I løpet av de andre brukertestene skal data lagres, men den skal slettes etter brukertesten er ferdig. Innloggings- og registreringsinformasjonen testbrukeren fikk oppgitt under brukertestingen var allerede lagret i databasen og informasjonen som de benyttet ble bare brukt for å verifisere at riktig data var skrevet. Når data blir hentet fra skjemaene på nettsiden blir det brukt POST i HTML skjemaet og superglobalen $_POST i PHP. Når POST blir brukt i PHP vil den hente/oppdatere dataene som blir sendt inn til prosessering, POST vil heller ikke vise dataene bakerst i URL-en i motsetning til GET. Superglobalen $_SESSION blir brukt for å videreføre data fra en side til en annen. Superglobal betyr at man alltid har adgang til verdiene som er lagret, uansett hvilken funksjon, klasse eller fil man befinner seg i. Når brukerne skal registrere seg via registeringssiden må dataene fra første side være tilgjengelig frem til brukeren er ferdig med registreringen og autentiseringen, slik at det kan settes inn i databasen. Etter brukeren er logget inn vil også $_SESSION videreføre dataene, slik at brukeren ikke blir logget ut når de trykker på en annen side (W3schools, udatert, PHP 5 Global Variables Superglobals). Når brukeren er logget inn og er inne på mailsiden vil det være muligheter for å logge ut av brukerkontoen, og komme tilbake til innloggingssiden. Knappen for utlogging vil terminere $_SESSION og all data som er midlertidig lagret i variabelen. Visse sider, for eksempel mailsiden, vil ha en sjekk om det er opprettet en $_SESSION variabel med riktig verdier, hvis ikke blir brukeren sendt tilbake til innloggingssiden. For å unngå at en bruker glemmer å logge av eller forlater PC-område, er det lagt inn en funksjon som logger brukeren ut automatisk etter 10 minutter med inaktivitet for å unngå eventuell misbruk. 17

22 Cookies har blitt standarden for midlertidig lagring av data, men nettsiden ble laget med $_SESSION for økt sikkerhet. $_SESSION lagrer data på serversiden slik at informasjonen er gjemt. Siden cookies lagres som en liten fil på klient siden, kan en bruker manipulere informasjonen i filen for å så sende en forespørsel på nettsiden. Noen ulemper med $_SESSION er at den validerer dataene basert på brukerens IP, dette kan føre til overskriving av session data når flere brukere er satt opp på samme nettverk. Nettsiden er lagt opp med forskjellige sikkerhetsnivåer. For vanlig autentisering kreves fødselsnummer og passord, dette gir lavt sikkerhetsnivå. Her har ikke brukeren adgang til å lese brev fra det offentlige. Ved sterk autentisering kreves det autentisering gjennom BankID og gir høyt sikkerhetsnivå, hvor brukeren kan lese all post. Sikkerhet rundt appen. Slik som på nettsiden, har vi også tenkt på sikkerheten rundt Android applikasjonen. Siden applikasjonen kun skal brukes for å logge inn og lese epost, har vi enkelt satt opp slik at ingen sensitiv informasjon blir lagret i applikasjon, uavhengig om dette er i form av navn, fødselsnummer eller passord. Applikasjonen ber kun om fødselsnummer og passord, som har blitt registrert gjennom nettsiden. Det finnes dermed ikke mulighet for å lagre fødselsnummeret eller passordet, og når du logger inn, får du kun opp menyer og test-mailene som vi selv har opprettet. Av backend, med tanke på sikkerheten, blir fødselsnummer og passord kalt på gjennom en.php-fil som autentiserer brukeren igjennom databasetabellen den er lagret i. Her blir verken $_SESSION eller cookies brukt, slik som på nettsiden, men kun en enkel database query som sjekker om brukeren eksisterer eller ikke. Passordet som brukeren selv har laget under registreringen, blir heller ikke på noen måter avslørt i databasetabellen, når alle passordene har blitt hashet med sha512. Dette vil dermed skjule det originale passordet, om tabellen i databasen faller i gale hender. 18

23 Mulige fremtidige utvidelser eller endringer Databasen som blir brukt til lagring og henting av informasjon er laget i phpmyadmin. Phpmyadmin ble brukt fordi det var et verktøy gruppen tidligere har erfaring med, men det kan være ønskelig for oppdragsgiver å bruke et annet verktøy, slik som MySQL, for bedre oversikt av tabellrelasjoner. Det ble først utviklet en database på en av gruppens PC'er, men denne databasen viste seg å være vanskelig å koble til, så det ble kjøpt opp hosting via freemysqlhosting.net. Denne er bare betalt i et år, så hvis arbeidsgiver ønsker å fortsette brukertesting og opplæring etter denne tidsperioden vil oppdragsgiver bli nødt til å fornye abonnementet, eller overføre databasen til en annen hosting. På grunn av mangel på tid vil ikke visse deler av nettsiden være ferdigutviklet. Flere funksjoner på mailsiden er ikke laget og knappene er ikke satt til å gjøre noe. Siden oppdragsgiver har satt fokus på innlogging og registrering vil disse funksjonene være tilgjengelige, men oppdragsgiver vil ha mulighet til å legge flere funksjoner senere. Brukervennlighet Oppdragsgiver har eksplisitt sagt flere ganger at de ønsker nettsiden så lik digipost sine nettsider som mulig. Brukervennligheten blir da identisk til den som finnes på digipost, med et unntak. Feilmeldingene i vårt testmiljø er satt opp slik at de kommer opp ved siden av de feltene hvor det er skrevet feil. Hvis en bruker skriver feil i passordfeltet vil en feilmelding komme opp til høyre for feltet, i stedet for på toppen av nettsiden, slik det er på digipost. Det er også satt fokus på gode feilmeldinger som både er deskriptive og ikke virker skremmende for brukeren. 19

24 Brukerhistorier Som en Ønsker jeg å Slik at Akseptansekriterie 1 Bruker Registrere meg Brukeren kan få posten digitalt 2 Bruker Lese e-post Man kan lese offentlige brev Registreringen fungerer og bruker blir opprettet. Brukeren er logget inn og får lest epost. 3 Bruker Logge inn uten BankID 4 Admin Å logge ut brukeren automatisk etter inaktivitet. 5 Admin Generere fiktive persondata 6 Ansatt At nettsiden skal kun ta for seg privatkunder 7 Bruker Få enkle og forståelige tilbakemeldinger 8 Ansatt Et universelt utformet grensesnitt 9 Ansatt Å ha en enkel brukermanual 10 Bruker Logge inn med BankID Brukeren får tilgang til digital postkasse Man øker tryggheten ved bruken Man ikke trenger å benytte seg av reelle personlige data Man ikke har med funksjoner som ikke trengs til det systemet er ment å brukes til. Lett kan prøve og feile. Alle har lik mulighet til å benytte seg av systemet Brukerne kan få hjelp hvis de setter seg fast. Brukeren får tilgang til digital postkasse Passord og personnummer blir validert mot en database og bruker blir logget inn hvis informasjonen er riktig. Nettsiden har en automatisk logg ut-funksjon Brukeren får utdelt forhåndsgenererte data. Tar ikke med bredriftsrammeverket i løsningen. Det utformes gode og forståelige tilbakemeldinger når det gjøre feil Passe på at grensesnittet likner på digipost og gjøre minimale endringer på fargevalg. Det utformes en enkel og forståelig brukermanual med bilder Passord og personnummer blir validert mot en database og bruker blir logget inn med høy sikkerhetsklarering hvis informasjonen er riktig. 20

25 11 Bruker Å logge inn via en applikasjon 12 Bruker Å ha mulighet til å endre et glemt passord 13 Bruker Å se hvor sterkt passordet mitt er 14 Bruker Å bruke en lett forståelig og intuitivt nettside 15 Bruker Teste Digipost uten å bruke personlige data 16 Ansatt Lære opp seniorer i bruk av Digipost Man kan øve seg på å logge inn via mobil Man ikke blir stengt ute fra kontoen Man kan føle seg trygg på at man har et sikkert passord Man ikke setter seg fast og lett kan navigere på nettsiden Man kan prøve seg frem uten konsekvenser Man har en opplæringsplattform for seniorer i bruk av Digipost Passord og personnummer blir validert mot en database og bruker blir logget inn hvis informasjonen er riktig. Ha med en glemt passord funksjon som tilbakestiller passordet Implementere en dynamisk passordstyrke funksjon Holde nettstedet så likt digipost som mulig Informere testbrukerne om at ingen personlig informasjon vil lagres. Testmiljøet fungerer og lagrer ikke personlig informasjon om testbrukerne. Vi har valgt å dele opp tabellen med farger for å vise når de ulike brukerhistoriene er blitt arbeidet med. Brukerhistoriene som er farget med grønn bakgrunn er de historiene vi arbeidet med først, i første iterasjon. Videre er brukerhistoriene som ble arbeidet med i andre iterasjon markert med blå bakgrunn. Brukerhistoriene som ikke har noen bakgrunnsfarge er brukerhistorier som har blitt arbeidet jevnt med under hele prosjektperioden. 21

26 Use case Figur 3 - Use case diagram Use case diagrammet ovenfor illustrerer interaksjonen mellom de ulike aktørerene og testmiljøet. Aktørene, bruker og admin, har forskjellige måter å tilnærme seg testmiljøet på. Der hvor primæraktøren, bruker, har som mål å bruke testmiljøet, vil sekundæraktøren, admin, hjelpe primæraktøreren med å oppnå sine mål. Videre hvor det er sammenheng mellom ulike hendelser, har vi inkludert <<extend>>, som brukes for å vise sammenhengen mellom to eller fler hendelser i et use case. 22

27 Use case beskrivelse Use Case Aktør Trigger Pre-betingelser Post-betingelser Normal Hendelsesflyt Variasjoner Registrere seg Bruker Brukeren ønsker å lære hvordan man registrerer seg hos digipost Brukeren er inne på siden for registrering 1. Brukeren registreres Eller 2. Systemet rapporterer om feil 1. Systemet ber om E-post, mobilnummer, passord og gjenta passord 2. Brukeren fyller inn E-post, mobilnummer, passord og gjenta passord 3. Brukeren godtar vilkårene 4. Systemet validerer at all informasjon er korrekt, og sender brukeren videre til siden for samtykke. 5. Brukeren samtykker 6. Systemet validerer at samtykke er gitt 7. Systemet sender brukeren videre til BankID-siden 8. Brukeren velger BankID til å registrere seg 9. Systemet sender brukeren videre til BankID-siden for fødselsnummer 10. Systemet ber om fødselsnummer 11. Brukeren fyller inn fødselsnummer 12. Systemet kobler til aktuell database og tabell, og validerer fødselsnummer 13. Systemet sender brukeren videre til BankID-siden for engangskode 14. Systemet ber om engangskode 15. Brukeren fyller inn engangskode 16. Systemet kobler til aktuell database og tabell, og validerer engangskode 17. Systemet sender brukeren videre til BankID-siden for personlig kode 18. Systemet ber om personlig kode 19. Brukeren fyller inn personlig kode 20. Systemet kobler til aktuell database og tabell, og validerer personlig kode 21. Systemet varsler brukeren om at den nå er registrert 3a. Brukeren har ikke godtatt vilkårene og får beskjed om at dette er obligatorisk 4a. All informasjon er ikke korrekt og brukeren får beskjed om hva som må rettes opp 5a. Brukeren huker ikke av på samtykke og får beskjed om at dette er obligatorisk 11a. Brukerens fødselsnummer er ikke korrekt og brukeren får beskjed om at dette må rettes opp i 16a. Brukerens engangskode er ikke korrekt og brukeren får beskjed om at dette må rettes opp i 20a. Brukerens personlige passord er ikke korrekt og brukeren får beskjed om at dette må rettes opp i 21a. Brukeren ble ikke registrert og brukeren varsles om dette 23

28 Use Case Aktør Trigger Pre-betingelser Post-betingelser Normal Hendelsesflyt Logge inn uten BankID Bruker Brukeren ønsker å lære seg hvordan man logger inn Brukeren er registrert i testmiljøet 1. Brukeren logges inn Eller 2. Systemet rapporterer om feil 1. Systemet ber om fødselsnummer og passord 2. Brukeren fyller inn fødselsnummer og passord som det spørres etter 3. Systemet kobler til aktuell database og tabell, og validerer at all informasjon er korrekt 4. Systemet sender brukeren til den digitale postkassen Variasjoner 3a. Fødselsnummeret er ikke korrekt og brukeren må skrive inn på nytt 3b. Passordet er ikke korrekt og brukeren må skrive inn på nytt 24

29 Aktivitetsdiagram registrering Figur 4 - Bilde over bevegelsene en bruker kan foreta seg når man registreres 25

30 Aktivitetsdiagrammet ovenfor viser brukerens bevegelser når man skal registrere seg som bruker i testmiljøet. På toppen befinner brukeren seg på registreringssiden og er klar til å fylle inn informasjon om hvem man er. Etter at informasjonen er fylt inn er det to mulige utfall. Enten så er informasjonen som er fylt inn korrekt, eller så er den ikke korrekt. Om informasjonen ikke er korrekt så vil brukeren være nødt til å enten endre den informasjonen som ikke var korrekt eller avbryte registreringen. Om informasjonen er korrekt vil brukeren fortsette nedover i systemet og gjennomføre de nødvendige stegene for å fullføre registreringen. Når brukeren har kommet til punktene BankID fødselsnummer, BankID engangskode og BankID personlig kode kan brukeren velge å avbryte registreringen om man ikke ønsker å registrere seg allikevel. Det er altså to ulike mulige utfall av registreringsprosessen. Enten så blir registreringen fullført og man registreres som bruker i testmiljøet, eller så blir registeringen avbrutt av brukeren og man registreres ikke som en bruker i testmiljøet. Vi valgte kun å lage et aktivitetsdiagram av registreringsprosessen da dette er en av de aktivitetene vi anser som blant de viktigste av de ulike aktivitetene en bruker kan gjennomføre i testmiljøet. 26

31 Registreringssekvens Figur 5 - Registreringssekvens Dette diagrammet viser hvordan registreringssekvensen foregår og hvilke data samt funksjoner som settes i spill når brukeren registrerer seg på testmiljøet. Regex(!OK) betyr at brukeren har skrevet inn informasjon i feltene som ikke stemmer overens med regexen som er skrevet inn i valideringen. Her går det en pil tilbake for å indikere at brukeren blir værende på siden hvor det ble skrevet feil. $_SESSION variablene visere hvilke verdier som ble sendt videre etter at valideringen ble vellykket. Den alternative flyten viser hva som skjer hvis en bruker allerede eksisterer i systemet med samme fødselsnummer. Til slutt vil systemet hente et navn fra navndatabasen for så å sette variablene inn i user-databasen. 27

32 28

33 Prosessdokumentasjon 29

34 Innholdsfortegnelse Forord Innledning Teknologier og verktøy Valg av oppgave Definering av oppgave/omfang Bruk av utviklingsmetodikk Extreme Programming Scrum Kanban Arbeidsprosess og møter Møte med veileder Møte med oppdragsgiver Logg Arbeidsverktøy Oppstart Startfase Første iterasjon Utviklingsfase Utfordringer Andre iterasjon Utviklingsfase Wave webaim Tool Hva sier lovverket Utførelse og feilmeldinger Utfordringer IOS Utfordring

35 Tredje iterasjon Utviklingsfase Rapportskriving Oppsummering av arbeidet

36 Forord Den delen av dokumentasjonen som nå følger er ment å beskrive hvordan gruppen har arbeidet med prosjektet, om hvordan man gått frem fra oppstart og planlegging, og helt frem til det endelige resultatet er ferdigstilt. Hensikten er å vise og forklare beslutninger som gruppen har fattet og forklare hvorfor man har arbeidet slik som man har. Dette gjøres med det formål å forenkle forståelsen av arbeidsprosessene som gruppen har vært igjennom. I hovedsak er prosessdokumentasjonen rettet mot de som skal sensurere oppgaven. Dette fordi at man skal kunne få innsikt og oversikt over det arbeidet som er lagt ned av studentene mens de arbeidet med prosjektet Innledning Verktøyet som skal utvikles er et testmiljø som skal kunne benyttes til å lære opp seniorer i hvordan man registrerer seg hos Digipost for å kunne motta post i en digital postkasse. Hovedmålet er at det utformes en løsning der de eldre helt uten bekymringer kan prøve og feile ved å gjenta de samme prosessene flere ganger. Det er viktig at det ikke skal vises sensitiv informasjon, og all data som lagres skal bli slettet etter brukertesting er ferdig. Prosjektet kan være med på å gi Seniornett solid erfaring med hva som er mulig å få til ved bruk av grensesnitt og fiktive data til opplæring. Det kan gjøre at de vil kunne trappe opp sitt arbeid med å få på plass enda flere testmiljøer på lik linje med det som utformes i dette prosjektet slik at man kan få seniorgenerasjonen mer involvert i den teknologiske utviklingen. 32

37 Teknologier og verktøy Netbeans Netbeans er et tekst- og kilderedigeringsprogram som har blitt brukt av gruppemedlemmene fra første semester ved Anvendt Datateknologi. Derfor har vi valgt og fortsette å bruke dette i hovedprosjektet. Her ble all kode for PHP, HTML, CCS skrevet. Outlook Ble brukt for å holde kontakt med oppdragsgiver og veileder angående spørsmål om hovedprosjektet, brukertesting og avtale av møter. Google Docs til rapportskriving Gjennom prosjektperioden har vi benyttet oss av Google Docs til å ha oversikt over alle nødvendige dokumenter. Google Docs er et tekstbehandlingsprogram på lik linje med Word, bare at Google Docs bruker man via en nettleser. Her kan alle på gruppen være inne på et dokument samtidig og gjøre endinger uten å påvirke de andre. Facebook Facebook er et sosialt nettverk. Vi har brukt Facebook til å kommunisere med hverandre når vi ikke har hatt møter. Dropbox Dropbox er en fillagrings- og synkroniseringstjeneste som tilbyr å lagre store og små filer som man kan dele med andre gjennom felles mapper. Vi benyttet Dropbox til å lagre rapportdokumenter, bilder, vedlegg, kildekode, pensumbøker og andre filer. Trello Trello er et gratis web-basert prosjektverktøy. Gjennom Trello kan man opprette mange lister bestående av mange underoppgaver. Dette hjelper til med å ha struktur i arbeidet og gir en god oversikt over aktuelle oppgaver. 33

38 Draw.io Draw.io er et gratis redigeringsverktøy på nett, som ble brukt for å lage diverse diagrammer. Web sequence diagrams Web sequence diagrams er et annet gratis redigeringsverktøy som også ble brukt for å lage diagrammer. Paint.net Paint.net er et gratis bilderedigeringsverktøy, her ble logoen for prosjektoppgaven laget samt andre grafiske elementer til applikasjonen og nettsiden. PhpMyAdmin For å kunne lage en database med tabeller, hvor vi kunne ha tilgang både på skolen og utenfor, brukte vi PhpMyAdmin. Dette er et gratis open source verktøy som brukes til databasehåndtering. Her kan man opprette databaser og tabeller for så å sette inn, endre og slette verdier. AndroidStudio Vi valgte å bruke Android Studio som vårt utviklingsmiljø når vi skulle lage en app til Android enheter. To av gruppemedlemmene har tidligere brukt dette utviklingsverktøyet i et valgfag (Apputvikling), og dermed med ble det en enkel avgjørelse å bruke dette. Vi benyttet oss også av en emulator. Dette ga oss mulighet til å kontinuerlig teste hvordan grensesnittet så ut på de forskjellige enhetene, i vårt tilfelle en Samsung Galaxy tab Java og XML Java og XML er to vel utbredte programmeringsspråk som ble brukt til all programmering for front- og backend på android-applikasjonen. Html, Css og Javascript biblioteker Html er et markeringsspråk som brukes til å opprette nettsider ved bruk av hypertekst. HTML brukes til å strukturere nettsiden og angi elementer. 34

39 CSS beskriver all design, farger og annen stilinformasjon for de elementene som er angitt i HTML-koden. Alle elementene kan defineres rett i HTML-koden, men vi har lagd egne CSS stilark og inkludert disse i HTML-koden. JavaScript er et skriftspråk som tilbyr muligheten for å ha dynamiske elementer på nettsider. JavaScript ble blant annet brukt for å validere inputfelter på registeringssiden, innloggingssiden og for å vise feilmeldinger. PHP og MySQL PHP er et programmeringsspråk som gruppen har lært om fra første semester. Derfor valgte vi i hovedsak å benytte oss av PHP til utviklingen av prosjektet. PHP ble brukt til skjemautfylling, inn-/utlogging, databasekobling, validering og legge til/oppdatere brukere. PHP ble også brukt til å inkludere enkelte PHP sider på flere andre PHP sider. Ved å bruke <include> ville vi slippe å skrive samme kode på flere undersider. Vi bestemte oss for å bruke MySQL som programmeringsspråk til databasen. Dette er noe vi har vært borti før og alle har blitt kjent med bruken av det i faget databaser. Med bruk av MySQL og PHP var det enkelt å kunne lagre, slette og endre data i feltene i databasen. XAMPP XAMPP er et program som fungerer som en lokal webserver på maskinen. Denne tjenesten gir en mulighet til å bruke Apache, MySQL og PHP, samt teste ut nettsiden kontinuerlig. Ved bruk av XAMPP, kan man kjøre alle PHP og MySQL operasjoner lokalt på maskinen og forenkler det å teste ut et prosjekt kontinuerlig uten å måtte laste prosjektet på en webserver. 35

40 Valg av oppgave Gruppen hadde tidlig på høsten, i semester fem, fått vite om en potensiell oppdragsgiver hos et familiemedlem hos en på gruppen. Da dette falt igjennom etter kort tid, måtte man starte søket etter oppdragsgiver på nytt. Vi hadde vært i kontakt med noen ferdigutdannede bachelorstudenter som har startet et eget selskap, TurboDevs, og det viste seg at de hadde flere mulige prosjekter. Etter å ha fått et innblikk i hvilke typer prosjekter som var tilgjengelige, bestemte vi oss for å gå inn i et samarbeid med TurboDevs. Vi fikk opprinnelig tre valgmuligheter for prosjektet, og etter å ha gått igjennom de ulike alternativene endte vi opp med å velge prosjektet som handlet om Seniornett. Vi valgte denne oppgaven da det var denne oppgaven vi fant mest interessant og relevant med tanke på de ferdighetene og kunnskapen vi allerede satt på og for å videreutvikle disse. Definering av oppgave/omfang Det var opprinnelig noe forvirring rundt hva omfanget til oppgaven var, ettersom at kommunikasjon mellom TurboDevs og Seniornett tok lang tid, men etter juleferien falt alt på plass. Det skulle utvikles et testmiljø av digipost sine nettsider, til opplæring av seniorer. Oppdragsgiver la vekt på at testmiljøet skulle ligne så mye så mulig på digipost, for å gi mest mulig realistisk brukertesting og opplæring. All informasjon om oppgaven ble fremlagt i løpet av første møte med seniornett, og gruppen hadde et klart overblikk over hva som skulle gjøres. Med tanke på at digipost er en profesjonelt designet nettside og ønskene som ble gitt av oppdragsgiver, var det nødvendig å kutte ned på antall funksjonaliteter da alt skal lages i løpet av et semester. 36

41 Bruk av utviklingsmetodikk Når det kommer til bruk utviklingsmetodikk vi har brukt i løpet av prosjektperioden, så har dette vært en blanding som er inspirert av flere typer metoder. Grunnen til at vi har arbeidet på en måte som er inspirert av flere ulike metoder er at ingen av de klassiske arbeidsmetodene passet skikkelig til måten vi ønsket å arbeide på. Vi har tatt utgangspunkt i en plan-drevet prosess hvor vi har gjort oppgaver i en spesifikk rekkefølge etter hva som har vært nødt til å være ferdig før man har gått videre på nye oppgaver. Men ettersom at vi har benyttet oss av flere metoder, har vi i tillegg brukt smidige metoder. Vi har arbeidet i iterasjoner hvor vi på forhånd av hver iterasjon har kartlagt det som skal gjøres og i hvilken rekkefølge vi skal løse oppgavene satt i iterasjonen. Til å håndtere og kartlegge alle de nødvendige oppgavene har vi benyttet oss av Trello til å holde oversikt. Figur nummer 6 viser et utklipp av hvordan det så ut på et tidspunkt i Trello, mens vi arbeidet med iterasjon nummer to. Figur 6 - Skjermbilde av Trello for iterasjon 2 37

42 Som nevnt har vi arbeidet med inspirasjon fra flere metoder. De ulike metodene vi har hentet inspirasjon fra er: Extreme Programming Scrum Kanban Extreme Programming Fra Extreme Programming startet vi med å benytte oss av user stories til å utrykke de kravene som var satt for systemet. Når vi da skulle kartlegge de ulike iterasjonene og hvilke oppgaver som skulle løses når, tok vi utgangspunkt i de user stories som var lagd. Grunnen til at vi ønsket å benytte oss av user stories er at vi tidligere har vært borti det å lage user stories. Våre erfaringer med dette har vært positive og vi synes at user stories gir en god og oversiktlig oversikt over alle krav og funksjoner som skal være med i systemet. Scrum Inspirasjonen vi hentet fra scrum startet med at vi ikke ønsket å ha en spesifikk person som skulle ha i oppgave å være prosjektleder, selv om et av gruppe medlemmene er satt opp som prosjektleder. Med dette tenkte vi at vi ikke ønsket at en person var den som hadde siste ord i diskusjoner og avgjørelser som gruppen kom til å ha. Vi ønsket at alle skulle ha lik myndighet når gruppen sto ovenfor diskusjoner og avgjørelser som måtte fattes. Vi har ikke hatt de klassiske stand-up møtene som man typisk benytter seg av i scrum, men vi har hentet inspirasjon fra dette. Ved starten av alle møter vi har hatt har vi gått i gjennom det som er blitt gjort siden sist og loggført hva som er planen for dagens møte. Vi har også loggført etter alle møter hvor vi har notert eventuelle problemer vi har støtt på og hva som skal arbeides med til neste gang. Dette har vært nyttig og sørget for at alle på gruppen hele tiden har vært klar over hvor langt gruppen har kommet og man har hatt mulighet til å hjelpe hverandre med eventuelle problemer. 38

43 Kanban Som vist i figur nummer 6 av Trello, hadde vi satt opp lister med hva som skulle gjøres. Dette hentet vi inspirasjon fra gjennom Kanban, og den metodens måte å benytte Kanban Board på. Kanban Boards går ut på at man for eksempel skriver opp oppgaver som må gjøres på lapper og henger de opp på en tavle slik at alle kan se hva som må gjøres, hva som er under arbeid og hva som er ferdigstilt. Videre flytter de personene som arbeider med de ulike oppgavene, lappene fra punktet hva som må gjøres, og til punktet at de er under arbeid og videre til ferdigstilling, ettersom hvilken fase de befinner seg i. Ved at vi da satt opp lister med alt som måtte gjøres så hadde hele gruppen oversikt over hvilke oppgaver vi hadde igjen å løse. Vi anså den måten man benytter Kanban Board på som veldig smart, hvor gruppemedlemmer som var ferdig med en oppgave tok for seg den neste. Der man i klassisk Kanban typisk arbeider slik at man tar den lappen som står øverst først, bestemte vi at gruppemedlemmene selv kunne velge oppgaver etter hva som var nødvendig å gjøre, og ikke nødvendigvis måtte ta den oppgaven som sto øverst på lista. Så ettersom et gruppemedlem ble ferdig med en oppgave, sto det medlemmet fritt til å velge hvilken oppgave man skulle ta for seg som neste oppgave. Det måtte da selvfølgelig være en oppgave som var klar til å løses, som da ikke var avhengig av en annen oppgave som fortsatt var under arbeid. Når oppgavene så var løst ble de lagt i listen over løste oppgaver. Istedenfor at vi flyttet lapper fra en fase og til en annen etter hvor langt man var kommet, benyttet vi oss heller av fargekoding, hvor hvert gruppemedlem hadde sin egen farge og markerte den posten man arbeidet med. Arbeidsprosess og møter Gjennom hele prosjektperioden har vi stort sett arbeidet på samme måte. Gruppen har møttes på skolen tre til fire dager i uken litt avhengig av hvilke oppgaver som var under arbeid. Stort sett har vi arbeidet med front-end og back-end når vi har hatt møter på skolen, mens vi har jobbet en del hjemme når vi har skrevet på rapporten. Dette har vi gjort fordi at når vi har arbeidet med front/back-end så har det vært greit å kunne sitte på samme sted og ta for seg problemer man støtte på sammen, for så å få løst disse raskest mulig. Når vi har hatt dager hjemme med rapportskriving har vi 39

44 delt ut ulike deler som hver person skulle skrive for så å gå igjennom dette sammen senere. Møte med veileder Videre har vi hatt jevnlige møter med veileder og kontakt per epost for å kunne få avklart spørsmål og for å få hjelp til det vi har måttet ha behov for. Disse møtene har funnet sted enten i område rundt veileders kontor eller på grupperom som gruppen har hatt tilgjengelig. Møte med oppdragsgiver Vi har også hatt møter med oppdragsgiver. I starten av prosjektet var det TurboDevs som skulle være oppdragsgiver og vi hadde et møte med de den 25. Oktober 2015 for å gå igjennom de ulike oppgavene de kunne tilby. Etter at vi valgte oppgave skulle TurboDevs ta kontakt med seniornett for å få arrangert et møte mellom gruppen, veileder og seniornett. Dette viste seg etter hvert å være litt komplisert. TurboDevs ble som et slags mellomledd mellom gruppen og seniornett, og kommunikasjonen gikk fra gruppen til TurboDevs for så å gå til seniornett. Dette gjorde at gruppen slet med å få ordentlig kontakt med seniornett og det endte med at veileder tok tak i saken og kontaktet seniornett per telefon og fikk avtalt et møte. Vi hadde så et møte med seniornett den 04. Februar 2016, hvor vi fikk kartlagt hva de ønsket at testmiljøet skulle brukes til. Både i tiden før og etter dette møtet hadde vi liten til ingen kontakt med TurboDevs. Dette fordi at både vi og TurboDevs hadde mye å gjøre, og vi trengte egentlig ikke noe mer fra TurboDevs etter at vi hadde vært i møte med seniornett direkte. Etter litt tid ble vi enige med veileder om at vi skulle forhøre oss med seniornett om de kunne tenke seg å stille som oppdragsgiver. Dette ble raskt avklart med seniornett, og de sa seg villige til å kunne være oppdragsgiver. Etter at dette var avklart så har ikke TurboDevs hatt noen offisiell rolle i vårt prosjekt. Kontakten har derfor gått direkte med seniornett, noe som har vært mye enklere enn det var i starten da kommunikasjonen foregikk gjennom TurboDevs. Etter at vi hadde oppnådd direkte kontakt med seniornett har kommunikasjonen vært grei, det har vært 40

45 noen perioder hvor det har vært vanskelig å få kontakt, men det har løst seg til slutt. Så møtene vi har hatt med seniornett har vært det første møtet 04. Februar, samt at vi har hatt to brukertester som har blitt avholdt i deres lokaler. Logg Som en del av prosessdokumentasjonen har vi gjennom hele prosjektperioden ført loggbok. Dette for å forenkle arbeidet og for å kunne gå tilbake å se på saker som vi senere i prosjektløpet har hatt et behov for å gå tilbake å se på. Loggen som har blitt ført gjennom hele prosjektperioden er lagt ved som vedlegg, og er vedlegg nummer 1. Arbeidsverktøy Alle gruppemedlemmene har stort sett arbeidet på Windows maskiner under arbeidet med prosjektet. Unntaket har vært når vi skulle forsøke å utvikle en applikasjon for operativsystemet til Apple, og da har det blitt benyttet en Mac-maskin for å gjøre dette. Oppstart Oppstarten av selve prosjektet startet den 13. Januar. I denne fasen som foregikk frem til 4. februar, da vi hadde møte med seniornett, ble benyttet til å utforme og levere forprosjektrapport, starte med å strukturere et prosjektdokument, starte med litt rapportskriving, opprette kontakt med veileder, lage en samarbeidsavtale innad i gruppen og mange andre småoppgaver. Startfase Etter at vi hadde vært i møte med seniornett anså vi oppstartsfasen som ferdig og gikk i gang med startfasen av prosjektutviklingen. Denne fasen gikk ut på at vi etter møtet med seniornett skulle kartlegge og få samlet så mye informasjon som var mulig på det tidspunktet til å kunne sette i gang med utviklingen. 41

46 Første iterasjon Utviklingsfase 1 Den første utviklingsfasen startet med at vi skulle sette i gang arbeidet med utviklingen av testmiljøet seniornett ønsket seg. Med oppstart den 09. Februar startet vi med front-end, back-end, samkjøring av kode og opprette database. I utgangspunktet skulle vi benytte oss av GitHub til å samkjøre kode, men vi endte opp med å benytte oss av NetBeans i kombinasjon med Dropbox. I perioden fra 09. Februar frem til vi skulle ha vår første brukertest, den 25. Februar, handlet det meste om å fortsette utviklingen og ha en jevn progresjon slik at vi kunne stille opp med et førsteutkast av testmiljøet som var klart til å testes på (brukertesten er beskrevet i testdokumentasjonen). Vi startet med å bestemme oss for hvilke brukerhistorier vi skulle utvikle først. Vi besluttet da å ta for oss brukerhistorie nummer en, to, tre, fire, fem, seks og sju. Grunnen til at vi startet med disse brukerhistoriene var at da vi hadde møte med seniornett formidlet de at det var disse funksjonene de kunne tenke seg å teste på under den første brukertesten. Vi startet først med å dele opp alle brukerhistoriene inn i mindre deler slik at vi fikk en best mulig oversikt over alt som måtte gjøres på de ulike brukerhistoriene. Vi kom også underveis i arbeidet opp med flere underoppgaver til brukerhistoriene enn de vi først hadde satt opp. Før vi satte i gang i med alle underoppgavene vi hadde lagt frem, opprettet vi en database som vi skulle benytte gjennom prosjektet. Etter at vi hadde undersøkt litt forskjellige muligheter av tilgjengelige databaser endte vi opp 42

47 med å benytte oss av databasehosting fra freemysqlhosting (Free MySQL Hosting, udatert). Figur 7 - Skjermbilde av database i phpmyadmin hostet fra freemysqlhosting.net For å oppnå en best mulig progresjon valgte vi som nevnt å fordele ulike oppgaver mellom oss slik at noen arbeidet med back-en og andre arbeidet med front-end. Til å begynne med var det en person som arbeidet med front-end, mens to arbeidet med back-end. Underveis i arbeidsprosessen gikk denne fordelingen litt frem og tilbake basert på hvilke oppgaver det var nødvendig å gjøre først. Det var i starten et behov for oss å sette oss inn i hvordan digipost fungerte for å best mulig måte kunne utvikle et velfungerende testmiljø. På bakgrunn av det tok vi kontakt med digipost for å undersøke om det var noen muligheter for å få tilgang på en testbruker uten at vi selv måtte registrere oss. Vi kom i kontakt med en person som arbeidet med digipost, men vi fikk beskjed derfra om at det ikke var mulig å få en testbruker, da det ikke eksisterte noen løsning for det. De tilbød seg derimot å sende oss testmail etter at vi hadde registrert oss hvis vi ønsket det. Vi tok kontakt på et senere tidspunkt for å få tilsendt noen testmail, men vi fikk aldri noe svar på dette. Så 43

48 alle på gruppen registrerte seg på digipost.no for å kunne sette oss inn i funksjonalitetene. Figur 8 - Et øyeblikksbilde fra Trello på et tidspunkt under første iterasjon 44

49 Utfordringer Under oppbyggingen av testmiljøet støtte vi naturlig nok på små og store utfordringer. Den første store utfordringen vi støtte på var et problem GitHub. Vi hadde i utgangspunktet sett for oss å samkjøre GitHub med NetBeans, men dette viste seg å være komplisert og etter mye frem og tilbake med prøving og feiling valgte vi å droppe GitHub. Det som gjorde at GitHub ikke fungerte var at vi ikke fikk lagt kode direkte fra GitHub og inn i NetBeans slik at det oppdaterte seg i GitHub når vi gjorde endringer i NetBeans. Vi fant da ut at det gikk an å legge et prosjekt direkte fra Dropbox og inn i NetBeans. Det fungerte slik at når en person lagret en endring i prosjektet i NetBeans på sin maskin så ble Dropbox mappen oppdatert. Da ble prosjektet i NetBeans oppdatert hos de andre gruppemedlemmene slik at alle hadde de nyeste oppdateringene. Dette fungerte veldig bra og vi valgte derfor å samkjøre koden gjennom Dropbox og NetBeans, istedenfor å bruke masse tid på å finne ut av hvordan GitHub fungerte. Under utviklingen hadde vi sett for oss å bruke Xampp til å kjøre og teste prosjektet på våre lokale maskiner mens vi utviklet. Men dette fungerte ikke gjennom samkjøringen med Dropbox fordi Xampp kjører prosjekter fra en lokal mappe. Figur 9 - Skjermbilde av feilmelding når man kjører prosjektet gjennom Xampp Så når vi ønsket å teste ut noe vi hadde utviklet ble vi nødt til å laste opp de nye endringene på vårt eget hjemmeområde, på skolens server, for så undersøke endringene vi hadde gjort på den måten. Det har også gjort at det har vært problematisk å teste prosjektet hjemmefra uten å ha VPN tilkobling til skolen da man må være på skolens nett for å få tilgang til hjemmeområdet, eller ha lastet ned Viscosity (Høgskolen i Oslo og Akershus, ). Dette har vært en litt tungvint metode å bruke, men det har gått greit. I de tilfeller hvor vi har arbeidet med koding hjemme har vi enten vært tilkoblet VPN, eller kopiert hele prosjektet fra Dropbox og 45

50 opprettet et lokalt prosjekt i NetBeans, for så å laste opp i Dropbox igjen når man er ferdige. Da har det vært viktig med god kommunikasjon innad i gruppen så ikke en person jobber i Dropbox og en person på et lokalt prosjekt som da vil overskrive de endringene som er gjort direkte i Dropbox filene når man laster opp i Dropbox igjen. Den neste utfordringen vi støtte på var i forbindelse med databasen vi hadde opprettet. En uke etter at vi hadde opprettet en PHPMyAdmin database mistet vi plutselig tilgang til databasen. Det viste seg da at vi kun hadde hatt en prøveperiode og at hvis vi fortsatt ønsket å bruke denne løsningen ble vi nødt til å betale 20 dollar for å kunne bruke løsningen videre i ett år. Vi besluttet at dette en grei pris for en velfungerende database og derfor valgte å betale 20 dollar. Etter samtaler med veileder har vi også søkt om refusjon fra skolen for det utlegget vi måtte ut med og fått dette godkjent. Når en bruker skal registrere seg hos digipost, er man nødt til å benytte seg av enten BankID, BankID på mobil eller Buypass. I møtet med seniornett hadde vi blitt enige om at det kun var aktuelt å lage en løsning i testmiljøet som tok for seg bruk av BankID, da dette var det flest seniorer har tatt i bruk. Vi ble derfor nødt til å komme opp med en løsning på hvordan vi skulle få til dette, da hensikten er at man ikke skal trenge å benytte seg av en reell BankID-konto. Som beskrevet i testdokumentasjonen delte vi ut lapper med informasjonen som testbrukerne skulle benytte seg av når vi brukertestet. Disse lappene inneholdt informasjon om hvilken BankID de skulle benytte. I første omgang løste vi dette ved at vi hadde lagt all informasjonen inn i databasen, hvorpå vi testet at det brukerne skrev inn stemte overens med det som lå i databasen. De nødvendige BankID-stegene man er nødt til å fylle ut er fødselsnummer, engangskode og personlig kode. 46

51 Andre iterasjon Utviklingsfase 2 Etter at vi hadde gjennomført og evaluert den første runden med brukertest var det på tide å sette i gang med utviklingsfase to. I begynnelsen av iterasjon to startet vi med å skrive på rapporten. Vi startet med å skrive på hva vi hadde gjort i første iterasjon, beskrive brukertestingen vi hadde gjennomført og skrive på andre diverse punkter i rapporten. Etter en ukes tid hvor fokuset lå på rapportskriving måtte vi tilbake til å fortsette utviklingen av nettstedet. I denne runden med utvikling skulle vi ta for oss brukerhistorie nummer 8, 9, 10, 11, 12 og 13. Vi startet også her med å dele opp alle brukerhistoriene i underoppgaver, slik som vi gjorde i første iterasjon. Etter dette startet vi i hovedsak med brukerhistorie 10 og 12. Her skulle vi på brukerhistorie 10 utvikle innlogging ved bruk av BankID (ID-porten). Denne funksjonen var det viktig å komme godt i gang med da dette er en funksjon som er essensiell når det kommer til bruken av digipost.no. Dette er en viktig funksjon fordi, som tidligere nevnt, om man ikke kan logge inn med BankID vil man ikke bli autentisert på høyeste sikkerhetsnivå, og man får ikke tilgang til alle eposter. Figur 10 - Valg om å logge inn med BankID 47

52 Brukerhistorie nummer 12 handlet om å gi brukeren en mulighet til å øve seg på å endre passord når man har glemt passord. Denne funksjonen var viktig å ha med da Seniornett ønsket dette og at det er naturlig å anta at brukere vil kunne glemme passordet sitt på et tidspunkt og da er det fint å ha vært igjennom denne prosessen før. Figur 11 - Funksjonene Glemt passord og logg inn med ID-porten er nå tilgjengelige De neste brukerhistoriene vi arbeidet med var nummer 8, 9, 11 og 13. Brukerhistorie 13 handlet om å la brukerne få se hvor sterk passordet de opprettet for kontoen var. Brukerhistorie 11 gikk ut på at vi skulle utvikle en applikasjon lik den som digipost benytter seg av. Denne applikasjonen ble utviklet for Android enheter. Utenom brukerhistoriene gjorde vi noen endringer i testmiljøet i løpet av iterasjonen. Vi måtte endre på måten vi hadde løst BankID på (dette står nærmere beskrevet i produktdokumentasjonen), vi måtte forbedre feilmeldinger og tilhørende css. Videre måtte vi sørge for at informasjon ikke forsvant fra feltene i registreringsprosessen hvis brukeren hadde skrevet noe feil, for så å trykke på videre-knappen. Her forsvant informasjonen etter første iterasjon og dette viste seg å være veldig tungvint og irriterende for brukerne under brukertesten. Vi måtte også gjøre litt små endringer her og der for å få nettsiden til å være universelt uformet. 48

53 Wave webaim Tool Vi tok i bruk verktøyet Wave for å evaluere om vårt testmiljø brøt diverse retningslinjer i WCAG 2.0 nivå A og AA. Wave er et tilgjengelig verktøy som hjelper webutviklere med å gjøre deres nettside mer universelt utformet for alle type nettbrukere. Det gjør den ved å evaluere kodestrukturen og grensesnittet til nettsiden opp mot diverse retningslinjer i Wave databasen. Wave vil ikke gi et fasit svar, men hjelper å evaluere nettsiden og hvorvidt den er universelt utformet. Hensikten vår var å sjekke om diverse funksjoner vi hadde med brøt noen retningslinjer. Selv om vi hadde gjort to ulike brukertester, hvor vi har testet testmiljøet på både nettbrett og datamaskin, og på forskjellige testdeltagere med ulik tilnærming til IKT-bruk, ønsket vi å bruke Wave for å finne feil som ikke hadde blitt oppdaget ved de tidligere brukertestene. Hva sier lovverket Lovverket sier at alle nettsider nå skal utformes etter WCAG 2.0 nivå A og AA (Lovdata, udatert, Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger, 4) med noen unntak. Med andre ord skal en virksomhet nå selv ha ansvar for å sørge for at nettløsninger er universelt utformet. Difi (direktoratet for forvaltning og IKT) kan også nå kreve dokumentasjon og foreta eventuelle undersøkelser for å sørge for at nettsiden holder alle krav for å være universell utformet. Når det gjelder nettløsninger som er publisert etter 1.Juli 2014, må de forholde seg til det lovverket rundt universell utforming som er vedtatt. Mens eksisterende løsninger skal være universell utformet innen 1.Januar 2021, det vil si eldre nettsider som er utformet før 1.Juli (Lovdata, udatert, Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger, 11 ) 49

54 Utførelse og feilmeldinger For å kunne utføre testen, måtte nettløsningen legges ut på internett. Siden vi ikke hadde tilgang til et domene, og fordi Wave ikke støtter webserver som XAMPP, brukte vi en av hjemmeområdene våre og la det ut på skolens server. Første gang vi kjørte denne testen fikk vi opp enkelte errors og noen alerts. De fleste errorene da gikk på at vi ikke hadde med alternativ tekst på bilder. Av feilmeldinger som dukket opp, stammet de fleste fra at nettløsningen hadde for lav kontrast mellom bakgrunn og forgrunnsfargene. Noen av disse kontrast alertmeldingene handlet om steder på siden hvor det ikke var nødvendig å endre kontrasten. Slik som på figur 13, hvor samtykkeskriften er grå med det formål om at dette punktet ikke enda er gjennomført. Sammen med skriften befinner det seg også en fremdriftslinje som Figur 12 - Feilmeldinger fra Wave viser hvor langt brukeren er kommet. Da det er slik det ser ut på digipost sine sider og at det ikke er noe essensiell informasjon som forsvinner med dårlig kontrast, har vi valgt å heller gjøre det så likt som digipost som mulig fremfor å endre skriftfargen. Figur 13 - Skjermbilde av et sted vi fikk kontrast-error Kjører man samme test på digipost, får man langt flere feilmeldinger. Både på antall alerts og feilmeldinger på strukturelementer samt kontrast. Forskjellen på antall feilmeldinger kan skylde at vi ikke har tatt med like mye innhold på nettløsningen som digipost.no. Når vi har valgt å utelukke enkelte menyvalg, undersider og lengden på selve forsiden. Dette har resultert med mindre alerts og errors, men dette er igjen en del av kravspesifikasjon vår. Videre har vi heller ikke, som tidligere nevnt, endret på farge eller kontrasten på overskriftene og menyvalgene på nettløsningen, når dette skulle se tilnærmet lik ut som digipost.no. 50

55 Utfordringer I starten av iterasjon to hvor fokuset sto på rapportskriving, arbeidet vi slik at alle skrev på sine tildelte emner, hvorpå vi i neste møtet leste igjennom det som var skrevet. Dette viste seg at var veldig tidkrevende. Vi innså at om vi skulle arbeidet slik ville rapportskrivingen og gjennomgangen ta ufattelig lang tid. Derfor besluttet vi heller at et av gruppemedlemmene sto for å lese igjennom, for så å forhøre seg med de andre på gruppen om det behøvdes. For å øke kompleksiteten på vårt provjekt og vår bruk av BankID til registrering og innlogging, ønsket vi egentlig i iterasjon to å utvikle en funksjon for å sende SMS med engangskode til brukeren når man skulle logge inn og registrere seg. Dette viste seg derimot å være betydelig vanskeligere enn hva vi hadde sett for oss og krevde ressurser vi ikke hadde tilgjengelig i prosjektperioden. I utgangspunktet hadde vi også sett for oss å utvikle en applikasjon for Apple enheter: IOS Utfordring Under planlegging av iterasjon 2 bestemte vi oss, i samarbeid med veileder, for å utvikle en applikasjon på plattformene IOS og Android. Dette ønsket vi fordi vi ville gi seniornett enda en mulighet til å lære opp eldre brukere som aldri før har brukt Digipost-applikasjonen, samt at vi i samråd med veileder ønsket å utvide prosjektet vårt med litt ekstra kompleksitet. Ingen på gruppen hadde tidligere utviklet en IOS-app før, så dette var nytt for oss og en utfordring vi måtte forsøke å løse. Det viste seg at for å kunne utvikle en applikasjon på IOS plattformen, trengte man tilgang til Mac OSX operativsystemet og programvaren Xcode. Siden ingen av gruppemedlemmene hadde en Mac til disposisjon på dette tidspunktet planlagte vi å løse dette med bruk av virtualisering. Virtualisering er en enkel løsning for å installere og bruke flere operativsystemer på en og samme PC. 51

56 Figur 14 - Skjermbilde av Xcode I gjennom faget operativsystemer, hadde vi tidligere tatt i bruk en slik teknikk for å kjøre Linux Ubuntu på våre Windows maskiner. Etterhvert fikk vi lånt en Macbook Air fra et familiemedlem, og valgte derfor å heller utvikle IOS appen på den istedenfor gjennom en virituell løsning. Under utviklingen møtte vi på problemer rett fra start. Her var alternativet å programmere enten i C eller Swift på Xcode, noe som var helt ukjent for oss. Å lære seg programmering på så kort tid, er både tidskrevende og vanskelig. Programvaren Xcode i selv var heller ikke lett for en førstegangsbruker å bruke og man var nødt til å benytte en del tid på å sette seg inn i det. Figur 15 - Skjermbilde av mac OSX 52

57 Etter tips fra veileder, ble vi gjort oppmerksomme på at Phonegap kanskje kunne hjelpe oss. Phonegap blir i hovedsak brukt i apputvikling ved hjelp av HTML og CSS. Her klarte vi å lage grensesnittet for applikasjonen uten store problemer, men under backend-programmeringen støtte vi på problemer igjen. Siden Phonegap ikke er en webserver klarte vi ikke å koble til PHP og MySQL. For å forhindre at gruppemedlemmet som skulle utvikle dette ikke satte seg fast for lenge, valgte vi å sette en tidsfrist. Dette ble gjort for å overholde tiden som var satt i fremdriftsplanen slik at vi ikke oversteg den tiden vi hadde tilgjengelig. Når tidsfristen utløp og gruppemedlemmet ikke hadde kommet noe særlig på vei, ble vi nødt til å ta en avgjørelse om at vi i denne omgang måtte legge oppgaven med å utvikle en IOS app på is og heller fokusere på Android applikasjonen og nettløsningen. Så istedenfor at vi utviklet en ios applikasjon bestemte vi oss for at vi skulle tilpasse nettløsningen vi hadde utviklet til å være mobilvennlig. For å få til en mobilvennlig løsning måtte vi gjøre endringer i CSS filene. Vi må tilpasse CSS filene slik at når man besøker nettsiden via mobile enheter, med mindre skjermer, så vil det være et eget tilpasset grensesnitt for disse enhetene. 53

58 Tredje iterasjon Utviklingsfase 3 Den tredje utviklingsfasen startet etter at vi hadde gjennomført andre runde med brukertesting. I denne fasen var planen at vi skulle ta med oss tilbakemeldingene vi fikk fra brukertesten, og gjøre de nødvendige endringene i testmiljøet. Etter at de nødvendige endringene var foretatt var det på tide å for alvor sette i gang med rapportskriving. Den tredje utviklingsfasen startet den 08.04, dette var en uke etter den opprinnelige datoen vi hadde planlagt å starte utviklingsfasen. Bakgrunnen for at vi ble en uke forsinket var at vi slet litt med å få kontakt med oppdragsgiver, for å avtale den andre brukertesten. Tilbakemeldingene fra testbrukerne, sammen med noen småfeil vi oppdaget under brukertesten, utgjorde ikke en betydelig mengde oppgaver. Endringer vi ble nødt til å gjøre i etterkant av brukertesten besto for det meste av småoppgaver hvor vi var nødt til å gjøre litt endringer her og der. Rapportskriving Store deler av tredje iterasjon gikk med til rapportskriving. Etter vi hadde gjort de nødvendige endringene i testmiljøet ble vi nødt til å endre fokus fra utvikling av testmiljøet og over på rapportskrivingen. Ettersom at vi hadde skrevet jevnt og trutt på rapporten fra vi startet på prosjektet hadde vi kommet godt i gang med skrivingen. Vi hadde etter første og andre iterasjon beskrevet de ulike iterasjonene mens det fortsatt lå friskt i minne. Det samme gjorde vi etter brukertestene. Dette har vært til stor nytte når vi skulle sette i gang med å skrive på resten av rapporten. Den viktigste delen å komme i gang med var nå produktdokumentasjonen. Her hadde vi så langt skrevet lite, til nesten ingenting, så det var viktig at vi kom raskt og godt i gang med dette. I produktdokumentasjonen har vi beskrevet mange av komponentene som er med på å gjøre testmiljøet til et velfungerende system. 54

59 Oppsummering av arbeidet Etter å ha arbeidet med bachelorprosjektet i noen måneder har vi fått erfare hvordan det er å arbeide med et stort prosjekt fra start til mål. Vi har igjennom denne perioden kommet i mange situasjoner hvor vi har måttet fatte avgjørelser og finne ulike løsninger på de problemene vi har støtt på underveis. Dette har gitt oss verdifull erfaring i hvordan man kan arbeide i prosesser hvor man er nødt til å løse diverse utfordringer. Når vi nå ser tilbake på arbeidet vi har lagt ned er det ulike ting vi ser at kunne vært gjort annerledes om vi skulle gjort prosjektet på nytt. Det første vi bet oss merke i når vi tenkte tilbake var at vi kunne hatt en bedre start på prosjektet. Det var en litt trå start ettersom at det tok litt tid før vi ordentlig visste hva oppdragsgiver ønsket seg. Videre ser vi for oss at vi kunne ha startet enda tidligere med applikasjonsutvikling. Om vi startet tidligere med dette hadde vi hatt mer tid til å sette oss inn i hvordan man utvikler en applikasjon for andre enheter enn Android-enheter. Som et ledd i brukertestingen hadde vi sett for oss å gjennomføre en akseptansetest med oppdragsgiver under den siste brukertesten. En akseptansetest er den siste testen man gjennomfører sammen med oppdragsgiver. Under en slik test kan oppdragsgiver komme med tilbakemelding på om de er fornøyde med produktet som er utviklet (Christensen, 2009). Vi ønsket å gjennomføre dette for å få bekreftet at systemet oppfylte de ønskene som var satt for prosjektet. Vi fikk ikke gjennomført dette som planlagt da vår kontakt i seniornett ikke var tilstede under den siste brukertesten. Til slutt kan vi konkludere med at dette utvilsomt har vært en veldig lærerik periode for oss alle på gruppen. Det å arbeide i en gruppe over en betydelig lengde tid har gjort at vi har lært mye om hvordan man må arbeide med store prosjekter. Vi har fått kjenne på hvor viktig det er å arbeide strukturert og ryddig slik at man hele tiden har oversikt over de arbeidsoppgavene som må gjøres. For å få til dette har bruken av Trello til å ha oversikt over oppgaver vært veldig nyttig. 55

60 Produktdokumentasjon 56

61 Innholdsfortegnelse Forord Innledning Validering Ferdigutfylte felter Hashing SQL-injection PHP include session_destroy() Glemt passord er egentlig knapp Databasetilkobling SQL-spørringer til database Kodegenerering Engangskode Personlig kode JQuery sterk passord BankID Skille mellom trykte knapper Glemt passord/innlogging med BankID Innlogging med/uten BankID Automatisk utlogging Forstørrelse av skrift Tilfeldige navn Kan ikke aksessere uten å være logget inn Admin sidene Design

62 Adminpanelet Design for håndholdte enheter Mobilvennlige sider Forsiden Login Mailside Registrering Engangskode og personlig kode Applikasjon Mål for applikasjonen Beskrivelse av applikasjonen Funksjoner som er med på applikasjonen Designvalg og valg av funksjoner Meny og innlogging Menyvalg Profil Mailside og postkasse Menyknapper og tilbakeknapp Databasekobling og begrensning

63 Forord Den delen som nå følger er ment å beskrive produktet som gruppen har utviklet gjennom prosjektperioden. Her skal ulike deler av testmiljøet bli beskrevet, fra hva de ulike delene benyttes til og hvordan de fungerer. Hensikten er å vise frem de ulike egenskapene og funksjonene som er blitt benyttet og utviklet for å få testmiljøet til å fungere. Produktdokumentasjonen er rettet mot personer med kompetanse innen JavaScript, PHP, CSS, JQuery, SQL og Android programmering (Java og XML). Innledning Testmiljøet som er blitt utviklet er ment å benyttes til opplæring av eldre brukere og være en del av Seniornett sitt arbeid med å få flere eldre til å ta i bruk digitale tjenester. Testmiljøet gir Seniornett en mulighet til å holde kurs i bruk av Digipost, uten at de eldre faktisk trenger å registrere seg før de føler seg trygge på tjenesten. Gjennom testmiljøet kan brukere øve seg på å registrere seg, logge inn med, og uten, BankID, brukere kan øve på å glemme passord og få en innsikt i hvordan postkassen ser ut og fungerer. 59

64 Validering Under utviklingen av testmiljøet ble det i hovedsak benyttet HTML og PHP-kode til å utforme nettstedet. Det har også blitt benyttet JavaScript-kode samt at det ble benyttet Java til å utvikle en Android applikasjon. PHP-koden er det som skal ta imot den informasjonen som brukerne skriver inn i html koden. PHP-koden skal sjekke dette opp mot flere ulike faktorer. Det skal sjekkes opp mot databasen som hadde blitt opprettet. Det skal sjekkes opp mot PHPvalideringen vi hadde produsert, slik at man kan forsikre seg om at brukerne skriver inn riktig informasjon. Det skal også sjekkes opp mot JavaScript validering. Valideringen gjorde vi ved hjelp av regulære uttrykk(regex), hvor man lager en streng, bestående av en kombinasjon av tegn, som det skal være tillatt for brukerne å bruke. Figur 16 - Skjermbilde av PHP validering med regex Som vist i figur 16 har vi lagd en funksjon for å validere at passordet som brukerne fyller inn inneholder de nødvendige tegnene for å opprette et passord. Regex strengen, i figur 16, sier at brukeren må ha med små bokstaver fra a-å og store bokstaver fra A-Å. Videre sier strengen man må ha med et tall mellom 0-9. Alle tegnene som kommer etter 0-9 er spesialtegn som tillates. Til slutt sier, {9,30}, at passordet må bestå av minst 9 tegn, og ikke mer enn 30 tegn. Funksjonen tar imot det brukerne fyller inn og sjekker om det IKKE matcher med de obligatoriske tegnene og den nødvendige minimumslengden. Hvis IKKE passordet matcher med de obligatoriske tegnene og minimumslengden så vil funksjonen 60

65 returnere false, og skrive ut en feilmelding til brukeren. Denne feilmeldingen skrives ut ved hjelp av JavaScript-kode. Det er på denne måten alle PHP-valideringsfunksjonene er bygd opp. Funksjonen tar imot input og sjekker det opp mot den angitte regexen. Vi benyttet oss også av JavaScript validering, hvor vi også der benyttet regex, til å gi brukerne en dynamisk validering av feltene mens de fyller inn informasjon. Dette gjør at med en gang brukerne er ferdig med å fylle ut et felt, vil man få tilbakemelding på om de har fylt inn informasjon som samsvarer med det tillatte formatet. Figur 17 - Skjermbilde av JavaScript validering med regex Ferdigutfylte felter Etter første brukertest kom det frem at det var veldig tungvindt for brukerne å måtte fylle inn all informasjon på nytt hvis man hadde gjort noe feil i registreringsfasen. For å løse dette benyttet vi oss av JavaScript til å sette verdier i feltene. Så om en bruker har fylt ut e-post og mobilnummer, men ikke skriver inn to identiske passord så vil feltene for e-post og mobilnummer bli automatisk utfylt når etter at brukeren har klikket på registreringsknappen. Brukeren vil da måtte fylle ut de to passordfeltene på nytt, men slipper å fylle ut de to første feltene. Figur 18 - JavaScript for automatisk utfylling av felter 61

66 Hashing Når brukerne i registreringsprosessen er nødt til å opprette et passord et det viktig at dette passordet ikke misbrukes og behandles med respekt ovenfor brukerne. For å gjøre dette har vi hashet passordet via sha-512 hashing. Sha-512 består av 512 bits og produserer en hash verdi på 512 bits (Stallings & Brown, 2011, side 53). Figur 19 - Hashing av passord og SQL-injection Vi valgte å benytte sha-512 da det er denne versjonen av sha hashingene som produserer den største hashede verdien av de ulike sha hashingene. Ved siden av sha-512 finnes også sha-1, sha-256 og sha-384 (Stallings & Brown, 2011, side 658). SQL-injection For å forhindre at noen forsøker seg på SQL-injection med et ønske om å ødelegge databasen, har vi benyttet oss av en SQL-injection funksjon for å forhindre at dette skjer. SQL-injection går ut på at noen uønskede personer forsøker å skrive inn SQLkommandoer i input feltene på et nettsted i håp om at de kan kontakte databasen og gjøre det de måtte ønske. For å forhindre dette har vi benyttet oss av PHP mysql_real_escape_string funksjonen (figur 19). Denne funksjonen legger til escape tegn foran databasespørringer for å forhindre at skadelig kode blir benyttet i inputfeltene. Som man kan se i figur 19 har vi lagt til mysql_real_escape_string($_post[ passord ]. PHP-funksjonen vil da sørge for at man ikke kan gjøre noe SQL-spørring gjennom inputfeltet for passord. 62

67 PHP include Vi har ofte gjort endringer underveis i testmiljøet, og mange steder bruker vi de samme kodesnuttene. Vi har derfor valgt å bruke PHP include på de delene av testmiljøet som blir brukt flere steder. Ved å legge en kodesnutt i et eget PHP-ark vil vi kunne inkludere dette arket på flere undersider. Dette gjør at vi kan ha samme innhold på flere sider og lar oss gjøre endringer på flere sider samtidig. Når brukeren er logget inn på mailsidene, vil headeren ha samme informasjon på alle sidene etter innlogging. Ulempen med dette er hvis en side krever noen små forskjeller, det er derfor viktig å planlegge godt hvilke deler av sidene som skal se identiske ut. session_destroy() Session blir brukt til, for eksempel, å sjekke om brukeren er logget inn eller ikke. Hvis brukeren vil logge ut, trykker brukeren på logg ut knappen. Når brukeren gjør dette vil session_destroy() slå inn og slette session variablene som har blitt opprettet under innloggingen. For å bruke session igjen etter session_destroy() må session_start() bli tilkallet. Glemt passord er egentlig knapp Figur 20 - Skjermbilde av hvordan glemt passord knappen ser ut før styling 63

68 For å ta med informasjon videre fra en side til en annen, fant vi ut at den enkleste måten er å bruke isset i PHP for å sjekke om en knapp har blitt trykket på. Det ble derfor kronglete å få videresendt informasjon via en link, siden dette ikke testes på i PHP. Vi tok derfor en vei rundt, ved å gjøre disse linkene om til knapper, og så style dem for å se ut som vanlige linker. Dette gjør at vi kan videresende informasjon på den måten vi er best kjent med, uten at det går på bekostning av utseende til websiden. I eksemplet (figur 20) over ser vi glemt passord knappen, som har blitt til en link ved bruk av styling i CSS. Her sender vi informasjon videre til IDporten-sidene om brukeren kommer fra glemt passord knappen, eller innloggingsknappen. Databasetilkobling Som vi tidligere har skrevet så benytter vi phpmyadmin som vert for vår database. Men for å kunne skrive inn og hente data fra databasen er vi nødt til å koble til databasen. For å gjøre dette benytter vi oss av PHP-funksjonen mysqli_connect. Denne funksjonen kobler oss til databasen og lar oss gjøre SQL spørringer mot databasen. Figur 21 - Skjermbilde av databasetilkobling Som man kan se i figur 21 består funksjonen av diverse ulike parametere som er plassert i mellom to parenteser, hvor hvert parameter er innenfor to anførselstegn. Det første parametere er adressen til verten hvor databasen befinner seg. Det andre parametere er brukernavnet til kontoen hos verten. Det tredje parametere er passordet til brukerkontoen (i figur 21 er passordet satt til XXXXXXX så ikke vi avslører hva passordet til kontoen er). Det siste parametere i tilkoblingen er navnet til selve databasen hvor man har opprettet tabeller. 64

69 Som man kan se i figur 21 har vi lagt funksjonen inn i en $db variabel. Dette har vi gjort fordi dette gir oss muligheten til å kun skrive $db istedenfor hele tilkoblingen hver gang vi trenger å koble til databasen. I tillegg til dette har vi også lagt koden i figur 21 i et eget PHP-ark slik at vi kun trenger å inkludere dette arket på de sidene hvor det er nødvendig å ha med databasetilkobling, fremfor å måtte skrive koden på hver side. SQL-spørringer til database Etter å ha opprettet tilkobling til databasen så må denne tilkoblingen brukes når man skal gjøre spørringer mot databasen. Når man skal gjøre dette så skriver man først en vanlig SQL-spørring, deretter benytter man PHP-funksjonen mysqli_query til å utføre spørringen mot databasen. Figur 22 - Skjermbilde av SQL-spørring mot database Som vist i figur 22 så skriver vi en spørring om å sette inn noen verdier i databasen og legger denne spørringen inn i $sql variabelen. Etter dette så kjører vi mysqli_query funksjonen. Her legger vi da ved $db som kobler til den riktige databasen og $sql som inneholder den spørringen vi ønsker å gjøre mot databasen. Denne måten å gjøre spørringer på går igjen i hele testmiljøet på alle spørringer som gjøres mot databasen, uavhengig om man skal skrive eller hente ut noe. Kodegenerering Når brukerne går igjennom BankID prosessen, enten ved innlogging eller ved registrering, er de på stegene for engangskode og personlig kode nødt til å benytte seg av en kode for å verifisere seg. Ettersom at vi lagde vår egen BankID-prosess var vi nødt til å finne måter å generere de nødvendige kodene på. 65

70 Engangskode For å generere en engangskode benyttet vi oss av en random funksjon i PHP (figur 23). Denne funksjonen genererer et tilfeldig tall mellom to forhåndsgitte tall. Da engangskoden består av seks siffer satte vi at vi ønsket å få generert et tall mellom og Koden som PHP funksjonen genererer blir så lagt i en session variabel som igjen blir benyttet når engangskoden skal vises til brukeren. Figur 23 - Skjermbilde av random funksjon Personlig kode Den personlige koden er i virkeligheten en kode som man har lagd i banken sin når man har registrert seg som nettbank bruker. Ettersom at vi utvikler et testmiljø som ikke er koblet opp mot noen banker eller den reelle BankID tjenesten ble vi på samme måte som med engangskoden nødt til å generere en kode for personlig kode. Da den personlige koden kan bestå av tall og bokstaver, kunne vi ikke benytte oss av random funksjonen til PHP. Figur 24 - Skjermbilde av funksjon for å generere personlig kode Det vi gjorde her (figur 24) var at vi lagde en funksjon bestående av en variabel ($pf) som inneholdt alle bokstaver, store og små, samt tall fra 0-9. Denne variabelen ble så satt i en tilfeldig rekkefølge av en PHP shuffle funksjon. I tillegg til at shuffle funksjonen satte variabelen i tilfeldig rekkefølge, så hadde vi angitt at vi ikke ønsket at strengen, som shuffle funksjonen genererte, skulle være mindre eller større enn syv tegn. Grunnen til at vi valgte at strengen skulle bestå av syv tegn var at vi anså dette som en lengde som ikke var for kort eller for lang for testbrukerne. Etter at strengen så var opprettet ble den lagd i en session variabel som igjen ble kalt på når den personlige koden skulle vises til brukeren. 66

71 JQuery sterk passord På både registeringssiden og glemt passord-siden skal brukeren skrive inn passordet to ganger, en gang for å lage passordet og en gang for å verifisere passordet. Den første gangen passordet blir skrevet blir det foretatt en sjekk med JQuery om hvor sterkt passordet er. Det ble brukt JQuery fordi vi ville at brukeren skulle få tilbakemelding mens de lagde passordet, og ikke etter de forlater feltet, slik som skjer med JavaScript valideringen. Valideringen ble gjort ved bruk av regex. Koden sjekket om visse symboler var skrevet inn, samt antallet. Når brukeren hadde skrevet inn visse symboler eller et visst antall symboler går en poengsum oppover. Denne poengsummen vises i form av en liten strek på siden av passord feltet (figur 25). Når poengsummen øker vil streken bli lengre, samt skifte farge. Til høyre for inputfeltet vil det vises en liten utskrift som sier hvor sterkt passordet er. Koden er lagt opp slik at hvis det er skrevet inn mindre enn 9 symboler, vil ikke streken bevege seg. Figur 25 - Skjermbilde av JQuery passordstyrke 67

72 BankID Når brukerne av testmiljøet går igjennom stegene for å registrere seg og innlogging via ID-porten, så benytter de seg av BankID. Vi hadde i første iterasjon kommet opp med en løsning til hvordan vi skulle kunne konstruere en fungerende BankIDprosess. Denne gikk ut på at vi allerede hadde lagt data inn i databasen for så å sjekke om det brukerne, under den første brukertesten, fylte inn stemte overens med det som lå i databasen. Seniornett ønsket å ha BankID-prosessen så likt den reelle BankID-prosessen som mulig. Vi syntes også den løsningen vi allerede hadde laget egentlig var en dårlig løsning. Dette fordi den var avhengig av at det lå data i databasen for å verifisere brukerne, så derfor ble vi nødt til å finne en ny måte å gjøre dette på. Vi ønsket da å forenkle den BankID løsningen vi allerede benyttet i registreringsfasen. Det vi gjorde var å skrive ut den nødvendige koden på skjermen til brukeren når man er inne på steget for engangskode og personlig kode (figur 26). Figur 26 - Skjermbilde av når brukeren er inne på BankID steget for engangskode Videre sjekker vi det som brukeren har skrevet inn mot koden som ble skrevet ut på skjermen (figur 27). Om brukeren fyller inn korrekt kode vil det bli generert en ny kode som skal brukes på BankID steget for personlig kode. Koden blir generert før man blir sendt videre til siden hvor man skal fylle inn den personlige koden. 68

73 Figur 27 - Sjekk om brukeren har skrevet inn koden som ble skrevet ut på skjermen Vi droppet altså å sjekke mot databasen om engangskoden var korrekt. Vi gjorde dette fordi at, som tidligere nevnt, ville vi vært nødt til å ha data i databasen om vi skulle sjekket mot denne. På siden for personlig kode gjøres det på akkurat samme måte. Da skrives koden som ble generert i funksjonen Pkode(figur 27) ut på skjermen og deretter sjekkes det brukeren fyller inn mot den koden som er skrevet ut på skjermen. Dette var altså i registreringsfasen. Så når det da kommer til innlogging med BankID så gjør vi det på samme måte når det kommer til engangskode, og tilnærmet det samme når det gjelder personlig kode. Det vi måtte sørge for ved den personlige koden var at man fikk opp samme personlige kode som man fikk i registreringsfasen, da det er slik det fungerer i realiteten. Etter at registeringen var fullført ble det personlige passordet skrevet til databasen. Så når brukeren da ønsker å logge inn med BankID blir den personlige koden hentet fra databasen og skrevet ut på skjermen til brukeren (figur 28). Dette gjorde vi fordi at det er slik det fungerer i virkeligheten, så for å skape en mest mulig lik og realistisk 69

74 opplevelse for brukeren valgte vi denne løsningen. Figur 28 - Skjermbilde av personlig kode ved innlogging Skille mellom trykte knapper Glemt passord/innlogging med BankID Når brukeren klikker på glemt passord linken så vil man måtte logge inn via ID-porten og benytte seg av BankID. Det samme vil brukeren gjøre om man velger å klikke på linken for å logge inn via ID-porten. Forskjellen ved disse to handlingene er at man skal ende på to forskjellige sider etter at man har logget inn via ID-porten. Når man klikker på glemt passord ender man på siden hvor man kan endre passord, mens når man har valgt å logge inn via ID-porten skal man ende opp ved postkassen. For å skille hvilken knapp som er blitt trykket på så har vi valgt å sette en session variabel, $_SESSION[ login ], hvis brukeren trykker på glemt passord linken. Etter at bruken så har gjennomført innloggingen sjekker vi på om denne session variabelen er satt. Om den er satt blir brukeren sendt til siden for glemt passord. Hvis den ikke er satt blir man sendt til postkassen. Figur 29 - Sjekk for å se om session variabelen for glemt passord er satt 70

75 Innlogging med/uten BankID På samme måte som med glemt passord og innlogging med ID-porten er vi nødt til å sjekke om brukeren har logget inn med eller uten BankID. Dette må vi sjekke ettersom at det er forskjellige sikkerhetsnivåer på brevene man kan motta i postkassen. Dette løser vi på samme måte som med glemt passord, hvor vi igjen har satt en session variabel. Denne gangen sjekker vi på om den variabelen er lik TRUE for å se om brukeren er logget inn med BankID. Hvis brukeren er logget inn via BankID vil man ha tilgang på alle mail på alle sikkerhetsnivå. 71

76 Automatisk utlogging Figur 30 - Funksjon for automatisk utlogging Som en tilleggssikkerhetsfunksjon har vi lagt til automatisk utlogging, som logger ut brukeren etter 10 min inaktivitet. Denne ekstra sikkerheten har en forhåndsbestemt tid, som er stilt inn på millisekunder. I vårt tilfellet er den stilt på millisekunder, som tilsvarer 10 minutter. Bruken av dette vil hindre uautorisert tilgang, når man enkelte ganger kan glemme å logge ut. Dette ble løst med JavaScript kode som er inkludert i alle undersider som kun kan aksesseres ved å være innlogget. For at denne funksjonen skal slå inn, så må det ikke være noen form for musbevegelser eller tastaturtrykk i den bestemte fanen testmiljøet er open på. Med andre ord, hvis man har minimert fanen med testmiljøet, men arbeider med en annen fane i nettleseren, vil den slå inn uavhengig om man er aktiv på den nåværende fanen. Ved utlogging blir man logget ut, og sendt til en ny side (figur 31). Her har man to valg, enten å gå til forsiden eller å logge inn på nytt. Figur 31 - Skjermbilde av at en bruker er automatisk logget ut 72

77 Forstørrelse av skrift Man vil på digipost.no finne en funksjon som viser en tekstboks med informasjon om hvordan brukeren kan justere skriftstørrelse. Denne funksjonen er svært nyttig for både personer med lese eller skrivevansker og synshemmede. Funksjonen viser hvilke hurtigtaster man kan benytte for å endre skriftstørrelse til den som passer en best for en selv. Funksjonen i seg selv er ideel for oss, når nettsiden skal være tilgjengelig for alle, og det er i hovedsak eldre brukere som gjerne har litt nedsatt syn som skal benytte seg av testmiljøet. Ved å legge musen over AA, vil det vises en melding om hvordan endre tekststørrelse. Denne funksjonen er lagd ved bruk av CSS-kode slik at den aktiveres når brukeren fører musen over. Figur 32 - Meldingen som vises når brukeren fører musen over AA tegnet Tilfeldige navn Figur 33 - Skjermbilde av det tilfeldige fornavnet en bruker har fått tildelt For å bevare brukerens anonymitet i vårt testmiljø har vi lagt til en funksjon som genererer tilfeldige navn. Funksjonen tar for seg et fornavn og etternavn vi selv har lagt inn i databasen for så å tildele dette til brukeren når man registrerer seg. Dette fungerer slik at alle navnene i databasen er tildelt et ID-nummer. Videre har vi lagt inn alle ID-numrene inn i et array (1-14). Dette arrayet blir så stokket om gjennom PHP-funksjonen shuffle. Etter at arrayet er stokket om henter vi ut verdiene som nå ligger på plass nummer 0 og 1 i arrayet og legger disse i to ulike variabler. 73

78 Derfra så henter vi ut fornavnet til plass nummer 0 i arrayet og etternavnet fra plass nummer 1. Dette vil videre bli lagt inn i databasen sammen fødselsnummeret, og vil ved neste innlogging være deres nye anonyme navn. Figur 34 - Funksjonen som tildeler brukere tilfeldige navn Kan ikke aksessere uten å være logget inn For å hindre at uautoriserte brukere får tilgang til enkelte undersider, har vi lagt til en funksjon som forhindrer dette. Selve funksjonen vil sjekke om $_SESSION[ id ] er blitt startet. Denne variabel blir startet ved at brukeren logger seg inn via innloggingssiden. Kun på denne måten vil $_SESSION[ id ] starte og man får tilgang til undersidene. Samtlige undersider som trenger en slik funksjon, har fått dette lagt til via include funksjonen. Det er også andre $_SESSION variabler som startes på utvalgte steder, som så blir sjekket på andre undersider om de er aktiverte. Figur 35 - Skjermbilde av om $_SESSION["id"] er startet 74

79 Admin sidene I løpet av prosjektet merket vi at det ofte var vanskelig å navigere videre på visse sider på grunn av restriksjonene vi satt. Noen sider krever at du er logget inn, eller kommet via andre sider for å få tilgang. Dette viste seg å være veldig tidskrevende og frustrerende siden hver gang vi, for eksempel, skulle se hvordan mailsiden så ut etter en endring i koden, måtte vi først logge inn via innloggingssiden. Etter en kjapp idemyldring og inspirasjonshenting kom vi fram til at en type admin panel ville øke produktiviteten til gruppen, samt være nyttig for oppdragsgiver etter levering. Adminsidene består av to sider. En side som består av muligheten for å aksessere hver eneste side i testmiljøet, uten å måtte være logget inn eller komme via de riktige sidene, samt innlogging til et adminpanel hvor man kan redigere databasen. Adminpanelet er skjult bak et innloggingssystem for å unngå misbruk av ukjente personer som har funnet siden. Dette ble gjort fordi testbrukerne lagrer dataene sine i databasen og vi har ansvar for at ingen får tilgang til disse. Adminpanelet gir en enkel måte å se og redigere innholdet i databasen på, eller legge til og slette brukere. Design Det visuelle designet på adminpanelet er veldig minimalt, og vi fokuserte mest på funksjonaliteten ettersom at ingen brukere skal se disse sidene, bare administrerende brukere. Linkene på siden for å logge inn på adminpanelet er egentlig knapper, stylet som linker. Dette ble gjort for hver knapp ettersom de tar med seg en rekke verdier videre slik at den kan aksessere de forskjellige sidene. 75

80 For eksempel så tar engangskode knappen under registrering med seg disse verdiene: $_SESSION['funker ] = true; Denne sjekker om brukeren har gjennomført stegene på registeringssiden. Om brukeren forsøker å aksessere en side og denne variabelen ikke eksisterer blir brukeren sendt til innloggingssiden. Figur 36 - Skjermbilde av innloggingssiden til adminpanel $_SESSION["passord"] = "testpassord123"; Variabelen over setter et passord og aktiverer $_SESSION["passord"] variabelen. Dette gjør slik at man komme til en nødvendig side fra adminsiden uten å måtte ha gjort de opprinnelige oppgavene. Dette skulle brukeren ha satt på registeringssiden. 76

81 $_SESSION['persnr'] = " "; På samme måte som $_ SESSION["passord"] variabelen så setter variabelen ovenfor et personnummer. Dette skulle også brukeren ha satt på registreringssiden. $_SESSION["ek"] = rand(100000,999999); Variabelen over kjører en random funksjon som videre blir satt inn i kodebrikken. Dette ble egentlig gjort på siden før engangskode. Adminpanelet På Adminpanelet lister siden opp brukerne som er registrert i systemet. Den lister ikke opp informasjon om passord, og bare de seks første sifrene i fødselsnummeret. Dette gjør at ingen personlig informasjon blir vist. Hvis en administrator vil gjøre endringer på en bruker må man først fylle inn ID, så fylle inn de feltene som skal bli endret på. Dette står også forklart øverst på nettsiden for å unngå forvirring. Hvis en administrator vil slette en bruker må man bare fylle inn hvilken ID som skal slettes, så bli brukeren slettet fra systemet. Vil en administrator legge til en bruker, så man fylle inn alle feltene. Figur 37 - Skjermbilde av adminpanelet 77

82 En oppdater knapp ble lagt til på siden da man må oppdatere siden for å se endringene som er gjort. De fleste nettlesere krever at du omgjør alle handlinger hvis du oppdaterer en side (som innsending av nytt skjema). Det vil man ikke gjøre når man skal oppdatere administrator siden, siden det kan føre til at man gjør uønskede handlinger, så knappen gjør at ingen handlinger blir gjengjort, bortsett fra henting av databasen. Ingen javascript/php validering gjøres på siden, så det er opp til administrator å passe på at riktig data blir skrevet inn. Siden har fortsatt SQL injection prevention for å forhindre at det benyttes SQL kommandoer. På slutten av hver brukertest er det viktig å opprettholde personvernet ved å slette alle brukere, utenom admin brukeren, permanent fra databasen. For å gjøre denne prosessen så enkel så mulig ble det lagt til en knapp som gjorde et SQL kall opp mot databasen som sletter alle brukere med id større enn 0. For å passe på at alle brukere ikke blir slettet ved uhell, er det lagt til en "alert boks" hvor admin må trykke ok for å slette eller avbryt for å gå tilbake. Figur 38 - Skjermbilde av alert boks for å godkjenne sletting 78

83 Design for håndholdte enheter Før smarttelefoner med avansert internettkapasitet ble dagligdags, trengte webdesignere bare tenke på en brukergruppe, nemlig PC-brukere. Nå som stadig flere tar i bruk nye digitale verktøy som smarttelefoner og nettbrett har man møtt på utfordringer når det kommer til utviklingen av nettsider. Interaksjonen mellom en webside og smarttelefoner/håndholdte enheter er ikke det samme som interaksjonen med en PC. Faktorer som trykking vs. touch, skjermstørrelse, oppløsning og hvilke type teknologier som er tilgjengelig gjør det viktig å designe websider som bruker responsive design. Hva er så responsive design? Responsivt design betyr at websiden har et oppsett som gjør at den kan brukes på flere plattformer og forskjellig oppløsning (W3schools, udatert, HTML Responsive Web Design). Websiden skal være like enkel i bruk på alle de mest populære plattformene. Det er derfor viktig at tekst, bilder, menyer, lyd/video og andre elementer er skalerbare og har muligheten for å flytte på seg. Websider blir ofte bygd med responsivt design i tankene fra starten av, og med riktig bruk av css, html og javascript vil det koste minimalt å designe "mobilvennlig" eller "PC-vennlig" websider. Når vi designet testmiljøet designet vi for datamaskin, siden vi hadde tatt utgangspunkt i at det skulle bli brukt PC under brukertestingen. Det viste seg derimot at det nesten kun ble brukt håndholdte enheter, men det var heldigvis ikke et problem siden mesteparten av testbrukerne brukte IPad med høy nok oppløsning. Men det var også en bruker som tok i bruk en smarttelefon hvor det ikke var en passende oppløsning. Vi besluttet derfor å designe testmiljøet for å gjøre det mer "mobil vennlig". Dette gjort ved bruk av CSS Media Queries. Media queries gjør det mulig å se etter, for eksempel, høyde og bredde på skjermen som websiden vises på. Dette gjør det mulig å legge inn endringer som skjer hvis skjermen overstiger maksgrensen som er satt. I vårt testmiljø satt vi maksgrensen på hvor smal skjermstørrelsen kunne være, på 500 piksler før siden gikk over til å bli tilpasset enheter med formater mindre enn 79

84 dette. Dette gjør at de fleste smarttelefoner ser den "mobil vennlige" nettsiden, mens PC og tablets ser den vanlige. Mobilvennlige sider Nå kommer det en liten gjennomgang av hvordan testmiljøet ser ut med oppløsningen 360X640. Vi har valgt denne oppløsningen da det er en av de vanligste oppløsningene for smarttelefoner (mydevice, udatert). Alle undersider som ikke blir nevnt er blitt implementert med media queries og endret slik at de er "mobil vennlige". Forsiden Figur 39 På forsiden ble digipost logoen flyttet helt opp til venstre hjørnet. Testmiljø skriften ble fjernet fra headeren på grunn av plassmangel. Header teksten og sub teksten fikk skygge for å øke lesbarhet. 80

85 Login Figur 40 Bredden ble krympet, og satt til prosent for øke tilgjengeligheten for flere oppløsninger. Zoom funksjonen i header ble fjernet (Dette gjennomgår på de fleste sidene). Mindre "luft" mellom elementene. 81

86 Mailside Figur 41 Menyen til venstre ble fjernet på grunn av plassmangel og at den ikke har noen funksjon utenom at man kunne klikke på postkassen. Testmiljø skriften ble fjernet fra headeren på grunn av plassmangel. Mindre "luft" mellom elementene. Hjelp-knappen ble fjernet på grunn av plassmangel og at den ikke har noen funksjon. 82

87 Registrering Figur 42 Bredden ble krympet, og satt til prosent for øke tilgjengeligheten for flere oppløsninger Feilmeldinger kommer ikke med en gang på grunn av plassmangel, kommer nå på toppen av nettsiden etter brukeren har trykket på "videre" knappen (hvis det er feil) Språkknappene fjernet siden de ikke har noen funksjon 83

88 Engangskode og personlig kode Figur 43 Bredden ble krympet, og satt til prosent for øke tilgjengeligheten for flere oppløsninger. Skjermbilde av kodebrikken/tankeboblen ble flyttet slik at brukeren ikke trenger å scrolle sidelengs. Bildet ligger over elementer som bare er visuelle hjelpemidler. Teksten som dukker opp på kodebrikken/tankeboblen ble flyttet for å komme på linje med bildet. 84

89 Applikasjon Mål for applikasjonen Mulighet til å teste ut testmiljøet gjennom en applikasjon La brukere øve seg på innlogging med fødselsnummer og passord Åpne og lese brev og andre dokumenter Eldre kan få testet ut hvordan det er å bruke en applikasjon hvis de ikke har gjort dette før Beskrivelse av applikasjonen Applikasjonen skal gi eldre brukere med Android-enheter mulighet til å teste og lære seg hvordan den opprinnelige applikasjonen til Digipost fungerer. Denne skal brukes på samme måte som den nettbaserte løsningen, hvor brukeren har rom for å prøve og feile, uten å miste eller gi fra seg sensitiv informasjon. Funksjoner som er med på applikasjonen Logge inn Lese e-post Disse to funksjonene er de som er med i den reelle applikasjonen til digipost og derfor har vi også med disse to sentrale funksjonene. Designmessig har vi valgt å gjenspeile brukergrensesnittet slik som den reelle android-applikasjonen til Digipost. Dette har vi gjort for å gi brukeren den samme opplevelsen som de får når de skal ta i bruk applikasjonen til digipost. Under utvikling ble Java brukt til all back-end programmering. Java håndterer alle aktiviteter og verifisering av inputfeltene for fødselsnummer og passord. 85

90 All front-end ble gjort via Xml. Dette er et html og CSS lignende språk, med semantiske klasser og attributter. Her ble klassene og attributtene gitt verdier, som for eksempel: hva som skulle være bakgrunnsbilde på hovedsiden, skriftstørrelse og posisjonen på alle knappene. Android-applikasjon ble ferdig utviklet ved hjelp av Android Studio. Designvalg og valg av funksjoner Meny og innlogging I hovedmenyen får brukeren to valg (figur 44): Logg inn i Digipost Lag ny bruker Valgene er tilsvarende de du får på applikasjon til Digipost. Ved å trykke på den første knappen, logg inn, blir brukeren sendt til neste aktivitet som er å logge inn. På innloggingsaktiviteten vil det være to datafelt som brukeren trenger å fylle inn, fødselsnummer og passord. Det er ikke med en glemt passord funksjon i appen, da det ikke finnes en slik funksjon på digipost-applikasjonen idag ( ). For å ha mest mulig likhet, har vi ikke lagt til andre funksjoner og menyer enn det som finnes fra før. Figur 44 - Skjermbilde av frontsiden på applikasjonen 86

91 Menyvalg Profil Her vil brukeren se sin egen profil etter å ha logget inn i applikasjonen. Denne siden er egentlig ment for å vise brukeren alle brukerkontoene som er registrert i digipost under deres fødselsnummer (privat og bedrift). Vi har kun en bruker per innlogget bruker fordi at Seniornett ikke har ønsket å ha bedriftsløsningen av digipost med i testmiljøet. Informasjonen blir presentert i to bokser (figur 45): Den første viser fornavn og etternavn og den andre hvor mange uleste mail brukeren har. Det vil bli gitt tilfeldige navn når man logger seg inn i applikasjon, Figur 45 - Skjermbilde av profilside for å bevare anonymiteten til brukeren, noe som har vært sentralt i vår hovedprosjekt. Mailside og postkasse Under mailsiden vil brukeren få opp en postkassen, her vil det være mulighet for å lese testmail. Disse testmailene er opprettet av bachelorgruppen og inneholder ingen sensitiv informasjon. I postkassen er testmailene til brukeren presentert i en liste, med informasjon om emnet til testmailen og hvem avsender er. Figur 46 - Skjermbilde av postkassen 87

92 Menyknapper og tilbakeknapp Figur 47 - Skjermbilde av tilbakeknapp For å alltid ha en mulighet for å gå tilbake til start eller til menyen/aktivititen før, har vi lagt til en tilbakeknapp. Denne knappen vil være tilgjengelig på actionbaren, på alle de fleste menyene. En slik knapp er vist oppe til høyre i figur 46. Applikasjon til Digipost har ikke en slik knapp på android-versjonen, men vi har lagt til dette for å gi brukeren en mulighet til å navigere frem og tilbake i de ulike menyene. Databasekobling og begrensning For å kunne verifisere fødselsnummer og passord, har vi gjennom backend koden i Java referert til en.php-fil. Denne PHP-filen inneholder databasekobling samt en query som sjekker om fødselsnummer og passord stemmer overens. Under utvikling har vi begrenset antall funksjonaliteter samt menyvalg i forhold til Digipost sin opprinnelige applikasjon. Her har vi sett bort ifra å legge til funksjoner som å sende epost, søk epost og flere brukere per fødselsnummer. Dette har vi gjort med hensyn til at dette skal være en opplærings applikasjon for å logge inn og lese av epost. Figur 48 - Databasekobling for app 88

93 Testdokumentasjon 89

94 Innholdsfortegnelse Brukertesting Personvern Brukertesting 25/ Pre-Research og forventninger til brukertesten Gjennomføring Metoder Observasjon Spørreskjema Resultat av brukertesting Konklusjon Brukertesting 07/ Formål og forventninger til brukertesten Gjennomføring Metoder Observasjon Spørreskjema Resultat av brukertesting Konklusjon Brukertest av Brukermanual Oppgavesettet bestod av tre oppgaver Tilbakemeldinger Konklusjon Brukertesting av applikasjon Oppgaver Fire oppgaver: Oppfølgingsspørsmål

95 Resultat av brukertesting Svar på oppfølgingsspørsmål Analyse av brukertestingen

96 Brukertesting Personvern Datainnsamling er en viktig del av analysen for vår brukertest. Vi har derfor jobbet for å sikre at dataene vi samler inn er riktige, relevante og samtidig beskytter personvernet til testdeltagerene. I jamfør personvernlovens 1 står blant annet: «Formålet med denne loven er å beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger...» (Lovdata, udatert) For å sikre at personvernloven følges har vi valgt å fokusere på følgende punkter: Det er helt frivillig å delta på brukertesten og svare på spørreskjema. Det informeres tydelig om formålet med brukertesten før igangsetting. Testdeltagere kan lese igjennom utlevert samarbeidsavtale før deltagelse i brukertesten. Testdeltagere har mulighet til å trekke seg på hvilket som helst tidspunkt. Vi har valgt å ikke samle inn opplysninger om navn eller alder, slik at man ikke kan identifisere personene ut ifra brukertestene eller spørreskjemaene. Vi gjorde det klart at ingen data vil bli publisert i forbindelse med utfylling av spørreskjemaet. Resultatet som ble samlet inn under prosjektperioden vil også kun brukes til dette prosjektet og for utforming av sluttrapporten. Alle deltakere i våre brukertester har undertegnet på en samarbeidsavtale som ble utlevert før vi startet. I første runde med brukertesting undertegnet deltagerne på vedlegg 6 og i brukertesting runde to undertegnet de på vedlegg 7. 92

97 Brukertesting 25/ Vi har gjennomført brukertesting på registreringsdelen og innloggingsdelen av systemet. Oppdragsgiver ønsket at det skulle legges størst vekt på disse to delene, for å kunne gi opplæring i de to mest sentrale funksjonene en bruker må igjennom for å kunne ta i bruk Digipost. Under brukertestingen tok oppdragsgiver del i å prøve ut løsningen samtidig som det ble utført brukertesting på testbrukerne. Dette for å avdekke mulige endringer eller forbedringer, samt få deres innspill på den foreløpige løsningen. Oppdragsgiver har kunnskap om brukerens behov og fikk ordnet med passende testbrukere for brukertestingen, som gjorde det lettere for oss å få gjennomført brukertesten. Under brukertesten fikk vi testet ut testmiljøet som var basert på første iterasjon av nettsiden. Dette var et grensesnitt som skulle gi en identisk brukeropplevelse som den man får ved å bruke den opprinnelige nettsiden, digipost.no. Av funksjoner vi hadde lagt til var å registrere seg som en ny bruker, en fiktiv versjon av BankID for å verifisere brukeren og innlogging for å kunne lese mail. Oppdragsgiver fikk etter endt brukertest vite om mulige endringer og hvilke nye funksjoner som vi hadde tenkt å legge til før neste brukertest. Neste brukertest ble avtalt å holdes etter påsken. Det ble gjort brukertesting på følgende områder og funksjoner: Registrering Innlogging Mailsiden Feilmeldinger Pc-versjon Nettbrett-versjon Mobil-versjon Inaktivitet etter 10 minutter 93

98 Pre-Research og forventninger til brukertesten Brukertest på eldre brukere er et nytt kapitel for oss som gruppe, derfor måtte vi avklare enkelte elementer før brukertesten. Her valgte vi å undersøke litt på den digitale kompetansen hos eldre, hvorvidt de føler seg trygge på nett og til hvilken grad de kunne håndtere IKT-relaterte oppgaver som vi skulle gi dem. Oppgavene vi skulle gi brukerne ville bestå av å registrere seg med fiktiv informasjon om fødselsnummer, e-post, passord, og verifisere dette med bruk av fiktiv BankID. Brukerne skulle også forsøke seg på innlogging uten bruk av BankID. Vi så for oss før brukertesten at de eldre brukerne ikke hadde erfaring med det å fylle inn informasjon i et registreringsskjema. Dette trodde vi også om bruk av bankid samt bruken av datamaskin og nettbrett. Vi ønsket å lage en brukertest hvor det trengtes lite kunnskap om IKT- bruk og en test som var enkel som mulig. I følge barne- ungdom og -familiedirektoratet (Buf) ble en undersøkelse gjennomført av Sifo - Statens institutt for forbruksforskning (Statens institutt for forbruksforskning, ) (Barne-, ungdoms-, og familiedirektoratet, ). Her stilte de i 2014 en rekke spørsmål til personer fra år om hvor vidt det var behov for å få hjelp av familie, venner eller andre til å håndtere teknologi og tjenester (Statens institutt for forbruksforskning, ). Undersøkelsen viste her at kun 23% av brukerne hadde behov for veiledning fra andre. Det viste seg at behovet for hjelp var knyttet til mange andre oppgaver, slik som kjøp, installasjon, oppdateringer og feilretting, og ikke IKT-bruk generelt. Samme undersøkelse viste også at blant de 1000 eldre respondentene så følte 59% seg trygge på nett i stor grad. Andelen av brukere som brukte datamaskin var på 87%, mens nettbrett lå på 42% (Statens institutt for forbruksforskning, ). Dette avkreftet på et vis dermed vår tanke om at eldre ikke hadde kjennskap til bruk datamaskin eller nettbrett. Med dette utgangspunktet valgte vi derfor i første omgang å ikke fokusere på brukermanualer bestående av instrukser for hva som må skrives i de ulike feltene eller hva de ulike feltene betydde. Dermed var alt klart for brukertesting den 25.Februar, i seniornett sine lokaler. De stilte også med det utstyret som ble benyttet. 94

99 Gjennomføring Før brukertesten sjekket vi om løsningen fungerte som den skulle ved å gå gjennom funksjonalitetene på forhånd som gruppe og med veileder. Vi ønsket å planlegge brukertesten og teste løsningen i god tid for å avdekke feil eller bugs, men grunnet tiden det tok å få utviklet det vi skulle i løpet av første iterasjon, rakk vi ikke å få planlagt brukertesten så grundig som vi hadde sett for oss. Gjennomføringen av brukertesten foregikk ved at vi kort presenterte oss selv ovenfor testbrukerne, samt formålet med brukertesten. Det ble også informert om at ingen data skulle lagres i denne runden med brukertest. Deretter ble samarbeidsavtalen delt ut og underskrevet av testbrukerne. Før testbrukerne gikk i gang med testingen delte vi ut en lapp til hver bruker med fiktive data, som besto av: fødselsnummer, passord, telefonnummer og epostadresse. Dette ble brukt for å kunne registrere seg som en ny bruker. Det ble også utdelt en annen lapp med engangskode og personligkode som skulle simulere en BankID verifisering. For å teste løsningen fikk testbrukere utlevert datamaskin eller nettbrett etter hva som var til disposisjon og hva de følte seg komfortable med. Det ble testet på forskjellige enheter og med forskjellige nettlesere. Blant enhetene var det to bærbare datamaskiner, seks IPad mini, en Samsung Galaxy tab og en Nokia Windows Phone. Dette ble gjennomført på syv testbrukere og en ansatt fra Seniorpost. På brukertesten var gruppen testbrukere sammensatt med hjelp fra oppdragsgiver. Denne sammensetningen besto av eldre brukere med en estimert alder fra 60 år og oppover, noe som var ideelt for brukertesten. Etter testingen ble det utdelt et spørreskjema som deltagerne kunne velge å svare på, og etter dette takket vi for deres tid og innsats. Selve brukertestingen begynte med at brukerne startet med å gjennomføre registreringsfasen. Etter at registreringen var vellykket ble testbrukerne bedt om å forsøke seg på innloggingsdelen. Her måtte de fylle inn fødselsnummeret og passordet de hadde registrert på registreringsdelen. Om innloggingen ble gjort korrekt ville brukeren komme til mailsiden, hvor det ville være mulighet for å lese testmail som var opprettet av gruppen. 95

100 Metoder Observasjon Ved planleggingen av observasjon under brukertesten hadde vi et fokus på at vi skulle følge med på om det var en sjanse for at testbrukerne satt seg fast og hvor de eventuelt ville trenge hjelp. Under hele brukertestingen fungerte alle vi i bachelorgruppen som observatører, alle tilbakemeldinger og kommentarer fra testbrukerne notert. En observatør sin rolle er å følge med på testpersonene og notere alt som er relevant for brukertesten og som kan brukes i en analyse etter endt test (Sandes 2011, s.312). Vi hadde også i bakhodet at kanskje noen av testbrukerne aldri hadde brukt en datamaskin eller nettbrett før, og at det kanskje måtte litt veiledning til underveis. Etter endt brukertest skulle vi oppsummere brukertesten, og sette sammen alle notatene vi hadde foretatt til et dokument. Spørreskjema I forkant av brukertestingen utformet vi et spørreskjema (vedlegg 3). Spørreskjema ble laget for å finne potensielle svakheter og styrker i testmiljøet med enkle spørsmål hvor de kunne krysse av på alternativene, Ja eller Nei. Her fokuserte vi hovedsak på: Registreringen Innloggingen Om teksten på de utdelte lappene var leselig Om de fikk feilmeldinger underveis Å lese e-posten på mailsiden Til slutt valgte vi å gi testbrukere rom for å kommentere hva de syntes var vanskeligst og hvordan deres helhetsopplevelse var. Personvernet ble ivaretatt ved at de ikke måtte skrive noe form for personlig informasjon, men kun krysse av, og svare på de spørsmålene som de ønsket å svare på. 96

101 Vi forsøkte å lage spørreskjema så enkelt som mulig for å få flest mulig deltagere til å svare på skjemaet. Alt i alt valgte alle de åtte (sju deltagere og en ansatt) testbrukerne å svare på spørreskjema. Resultat av brukertesting Under brukertestingen ble vi overrasket over brukernes kompetanse innen IKT-bruk, da mesteparten av deltagerne både kunne bruke nettbrett og datamaskin. Ved gjennomgang av spørreskjemaene, observasjon, og videre studering av resultatene kom vi frem til følgende resultater: Alle fikk registrert en ny bruker Alle fikk til innlogging Alle fikk lest test epost De ble veldig fort frustrert over gjentagende feil Vanskelig å tyde hva som var skrevet på de utdelte lappene, samt ulik terminologi på lappene opp mot hva som sto på nettsiden. I spørreundersøkelsens siste del hadde vi fem spørsmål - da med egne felt der deltagerne kunne skrive mer utfyllende. Spørsmålene var: Hva synes du om registreringen? Hvordan gikk det? På dette punktet svarte de fleste mer utfyllende og majoriteten av brukerne fikk det til, men noen savnet en funksjon som forhindret at man måtte skrive all informasjon på nytt om man gjorde noe feil. Det ble også nevnt fra flesteparten at de tildelte passordene var litt lange og vanskelig å se om det var skrevet riktig inn, da det man skrev inn ble skjult som et passord. 97

102 Hva synes du om innloggingen? Hvordan gikk det? På dette spørsmålet svarte de fleste litt mindre utfyllende enn hva de gjorde på det foregående spørsmålet. Her svarte de fleste at de fikk til innloggingen, men det ble nevnt at det trengtes litt assistanse for å skrive riktig informasjon i feltene. Hvis noe, hva var vanskelig? På punktet ble det etterspurt å ha litt større ikoner på enkelte elementer, for eksempel når deltageren skulle trykke på logg ut-knappen, så kunne dette vært litt mer tydelig og lettere å finne. Hvordan var nettsiden å bruke? Her svarte de fleste at løsningen var forståelig og enkel å bruke med lite distraherende elementer. Det siste og avsluttende spørsmålet i spørreundersøkelsen var: Hvordan var helhetsopplevelsen med dagens gjennomføring? På dette spørsmålet mente flest at dette var et flott hjelpemiddel for de usikre eldre brukere. Det var fint at man kunne bruke fiktive data for å teste ut løsningen, uten form for konsekvenser. Ble også nevnt at det var rom for å prøve og feile uten å miste data. Til slutt fikk de mulighet til å generell kommentere gjennomføringen av brukertesten og eventuelle forbedringer. Her ble det nevnt at det var nødvendig å tydelig markere at mailene man hadde i mailboksen ikke var ekte, og minne dem om at dette var et testmiljø, på alle undersider. Utenom dette var det enkelte tekniske problemer som oppsto, som forhindret noen av deltagerne i å fullføre arbeidet de holdt på med og de måtte da starte alt på nytt. Dette skyldes nettverket på teststedet. Det ble også gjennomgående nevnt på dette spørsmålet fra alle brukerne at det var fint å ha gruppen tilstede og kunne bruke oss som en ressurs når det oppsto komplikasjoner. Det vi også oppdaget når nettverket sviktet, og når testbrukerne gjorde feil, var at det var veldig tungvint for brukerne å måtte fylle ut alle feltene i registreringsprosessen på nytt. 98

103 Konklusjon Hensikten med denne brukertestingen var at vi som gruppe skulle teste ut løsningen på eldre brukere og hvorvidt de hadde kunnskap nok til å kunne klare å registrere og logge seg inn med fiktive data i testmiljøet. Etter å ha evaluert brukertesten kan vi si oss fornøyde med en vel gjennomført brukertest. Vi fikk testet det vi skulle og fikk med oss en del gode notater og tilbakemeldinger. Etter brukertesten har vi fått tilbakemeldinger som indikerer at vi har en løsning som møter både vårt og seniornett sitt mål med brukertesten. Vi har fått testet på sju testdeltagere, og en ansatt, hvor alle fikk til registrering og innlogging. Det ble utført testing på datamaskin, nettbrett og på en Windows mobiltelefon. Testdeltagerne behersket testmiljøet på en god måte, selv med varierende IKTkunnskaper. Det trengtes ikke mye veiledning fra gruppen for at testdeltagere skulle kunne utføre de ulike oppgavene. Der hvor det trengtes mer veiledning var hvor testdeltagere måtte verifisere seg med BankID. Her var det flere som ikke var kjent med bruken av BankID, mens andre var usikre på hva som skulle fylles inn i noen av feltene i prosessen. Det siste kom av at det var benyttet ulik terminologi på lappene som ble utdelt og hva som sto på nettsiden. Som nevnt var det tungvint for brukeren å måtte fylle ut registreringsskjemaet på nytt når det var gjort feil. Dette fikk oss til å innse at vi var nødt til å legge til en funksjon som automatisk fylte ut de feltene som var korrekte. Så om en bruker hadde fylt ut de to første feltene korrekt, men de to siste feil, så ville brukeren slippe å fylle ut de korrekte feltene på nytt. Gjennom spørreskjemaene kom det fram verdifull informasjon. Vi fikk tilbakemeldinger på valg vi hadde tatt under utviklingen, både ikke-tekniske og tekniske valg. Vi fikk tilbakemeldinger om skriftstørrelsen på lappene som ble utdelt, utformingen av logg ut-knappen og feilmeldinger brukerne fikk opp ved eventuelle feil. Videre fikk vi tilbakemeldinger angående BankID simuleringen og hvordan det var å få informasjonen man skulle fylle inn fra en lapp, for så å fylle inn informasjon inn i feltene. Ved gjennomgang av spørreskjemaene innså vi at selve spørreskjemaet var utformet på en måte som gjorde at spørsmålene var litt begrensende med tanke på hva de 99

104 kunne svare. Noen av spørsmålene var nesten ja/nei spørsmål, med lite rom for å være åpne. Noen av testbrukerne valgte å svare med korte setninger, og i noen tilfeller bare et ord. Dette var selvfølgelig litt dumt da vi ønsket oss flest mulig utfyllende tilbakemeldinger. Etter å ha fullført denne brukertesten, sitter gruppen nå igjen med en rekke inntrykk og erfaringer. På mange måter har dette vært en interessant utfordring, spesielt dette med å teste på eldre brukere da vi ikke har gjort dette før, og ikke minst vært en utrolig lærerik prosess. Vi har fått innsikt i hvordan eldre brukere tilvenner seg til noe nytt, samt fått de eldre sitt perspektiv og tilbakemeldinger når det kommer til bruken av selve løsningen. Alt dette er noe vi kan se nærmere på til neste iterasjon og brukertesting. Da skal vi skal implementere nye funksjoner og forbedre testmiljøet basert på tilbakemeldingene fra brukertesten og ønskene fra oppdragsgiver. Vi undervurderte litt tiden det ville ta å utvikle og gjøre klar testmiljøet til første brukertest. Det resulterte i at vi ikke fikk planlagt brukertesten så nøye som vi ønsket og visse deler av testmiljøet måtte gis en forenklet midlertidig løsning. 100

105 Brukertesting 07/ Formål og forventninger til brukertesten Formålet med å ha en ny runde med brukertest var at vi siden sist hadde utviklet noen nye funksjoner, samt at vi hadde gjort litt endringer på de funksjonene vi testet på i første brukertest. I denne andre runden med brukertest var hovedformålet å teste ut den nye funksjonen for å logge inn gjennom å benytte seg av fiktiv BankID og teste ut funksjonen for glemt passord. Vi ønsket å teste hvorvidt disse funksjonene var intuitive og forhåpentligvis få avdekket noen feil som vi selv ikke hadde oppdaget. Vi hadde også lagt til to funksjoner på BankID-sidene for engangskode og personlig kode. Disse funksjonene erstattet den fysiske kodebrikken og det personlige passordet man opprinnelig benytter seg av når man skal logge inn med BankID. Det var derfor viktig å få testet på disse funksjonene. Vi skulle også gi vår kontaktperson hos Seniornett en opplæring og gjennomgang i bruk av adminpanelet vi hadde lagd, samt en gjennomgang av hele nettstedet da dette kanskje var siste gang vi møttes. Men da vår kontaktperson hos Seniornett var i et annet møte denne dagen, fikk vi ikke gjort dette. Det var også i denne omgang oppdragsgiver som skulle sørge for å ordne med testbrukere. Vi hadde ytret et ønske om å ha like mange testbrukere som sist, om ikke flere hvis det lot seg gjøre. Det ble da kommunisert fra oppdragsgiver at de skulle forsøke å få til dette. Det ble gjort brukertesting på følgende områder og funksjoner: Registrering Innlogging uten BankID Innlogging med BankID Endre passord Feilmeldinger Nettbrett-versjon Inaktivitet etter 10 minutter 101

106 Gjennomføring Før brukertesten hadde vi gått igjennom systemet og forsikret oss på best mulig måte om at alt fungerte som det skulle. Vi sendte også en link til veileder slik at hun også kunne gå igjennom systemet og sjekke at alt fungerte. Vi hadde også denne gangen laget en samarbeidsavtale med brukerne for å forsikre dem om at det er helt trygt å delta på brukertesten. Vi lagde også et lite spørreskjema (vedlegg 4) som testbrukerne kunne svare på etter brukertesten om de ønsket. Til å teste ut systemet denne gangen ble det kun benyttet ipad. På brukertestingsdagen var et av medlemmene i gruppa syk, slik at det var to fra gruppa som tok del under brukertesten. Da det kun var et lite antall testbrukere førte ikke dette med seg noen store utfordringer. Brukertesten ble gjennomført i seniornett sine lokaler og de stilte med nødvendig utstyr. Det var kun fire testbrukere som deltok denne gangen. Dette var litt færre testbrukere enn hva vi egentlig hadde sett for oss, men dette var ikke noe problem. Det var også noen av de samme brukerne som var der på første brukertest. Brukertesten startet med at vi presenterte oss selv og forklarte hva vi ønsket at de skulle gjøre. Vi informerte også om at denne gangen ville informasjonen bli lagret midlertidig, men umiddelbart slettet etter endt brukertest. Brukertesten startet med at brukerne registrerte seg slik som ved forrige brukertest. Etter at registreringen var utført gjennomførte brukerne først innlogging uten BankID. Når dette var gjennomført med suksess, logget brukerne seg inn med BankID. Deretter utførte brukerne glemt passord prosessen. Under brukertesten fulgte vi med på om det kom frem noen feilmeldinger hos noen av testbrukerne. 102

107 Metoder Observasjon Før brukertesten hadde vi planlagt at vi under brukertesten skulle observere testbrukerne og noteres oss eventuelle hendelser og andre aktuelle ting som dukket opp underveis. Da alle testbrukerne hadde kommet, og det kun var fire testbrukere, besluttet vi raskt at vi skulle være observatører (Sandes 2011, s.312) for to testbrukere hver. Begge gruppemedlemmene noterte seg litt av hvert under testingen og etter at brukertesten var utført samlet vi alle notatene og diskuterte litt rundt det vi hadde notert oss. Vi fulgte ekstra nøye med på de nye funksjonene som var lagt til fra sist brukertest. Testbrukerne var i samme aldersgruppe som sist gang med en estimert alder på år. Spørreskjema Som nevnt hadde vi på forhånd laget et spørreskjema vi ønsket at testbrukerne skulle fylle ut etter at de hadde gjennomført brukertestingen. Alle de fire testbrukerne sa seg villige til å svare på dette spørreskjema. Vi ønsket å gjøre dette for å avdekke eventuelle hendelser vi ikke hadde fått med og gi brukerne en mulighet til å komme med en tilbakemelding på hvordan ting fungerte og hvordan de opplevde tjenesten. Spørreskjema inneholdt fire avkrysningsspørsmål og syv spørsmål hvor brukerne kunne skrive litt mer. I hovedsak fokuserte vi på innloggingen med BankID da dette var en av hovedfunksjonene som sto i fokus under brukertestingen. Under evalueringen av brukertesten kom det frem at vi hadde glemt å stille spørsmål om glemt passord funksjonen i spørreskjemaet, som vi egentlig hadde planlagt. Personvernet ble ivaretatt ved at de ikke måtte skrive noe form for personlig informasjon, men kun krysse av, og svare på de spørsmålene som de ønsket å svare på. 103

108 Resultat av brukertesting Etter å ha samlet, og gått igjennom notater og spørreskjemaene, kom vi frem til følgende resultater: Alle fikk registrert seg som ny bruker Alle fikk til innlogging med og uten BankID Alle fikk til å bytte passord gjennom glemt passord Ettersom at vi ikke hadde så mange testbrukere fikk vi ikke like mye tilbakemeldinger som vi hadde håpet på gjennom spørreskjemaet. Tre av de fire testbrukerne svarte også bare ok eller greit på alle spørsmålene hvor de hadde mulighet til å komme med litt utfyllende tilbakemeldinger, så disse svarene ga oss ikke så mye. Det man kan trekke ut fra skjema til den siste personen som svarte litt mer utfyllende er at det kanskje var litt mye å brukerteste på en gang. Det kunne vært bedre om man delte opp i enda mindre brukertester hvor man gikk enda nøyere igjennom de ulike delene hver for seg. Konklusjon Etter å ha planlagt, gjennomført og evaluert brukertesten kan vi konkludere med at det var en vel gjennomført brukertest, men med litt lite tilbakemeldinger. Vi fikk testet det vi skulle og gjennomført nesten alle oppgaver vi hadde planlagt. Vi hadde i utgangspunktet tenkt å gi oppdragsgiver en innføring i systemet, men da han ikke var tilstede fikk vi ikke gjort dette. Vi skulle gjerne hatt flere testpersoner til å gå igjennom systemet slik at vi kunne få testet systemet enda bedre og fått flere tilbakemeldinger. Dessverre glemte vi i spørreskjema å stille spørsmål om glemt passord funksjonen. Dette førte ikke til noen problemer da det kun var fire testpersoner og vi observerte alle under hele testen. 104

109 Brukertest av Brukermanual Under utformingen av testmiljøet har vi laget en brukermanual (vedlegg 9) som skal være til hjelp for brukere av testmiljøet. I brukermanualen har vi tatt i høyde for å ha med alle de nødvendige funksjonene som registrering, innlogging og BankID simuleringen. Funksjonene blir videre vist i en step-by-step guide med skjermbilder og beskrivelser. Siden vi ikke fikk testet dette under de tidligere brukertestene med testdeltagere fra Seniornett, måtte vi sørge for å teste ut dette i etterkant. Dette ble løst ved at vi fikk tak i noen eldre bekjente som kunne hjelpe oss med å teste brukermanualen. For å kunne teste om det holdt mål, laget vi et sett med oppgaver som skulle bli utført i testmiljøet ved hjelp brukermanualen. Oppgavesettet bestod av tre oppgaver Registrer ny bruker Logge inn uten BankID, med fødselsnummer og passord Logg inn med BankID, med engangskode og personligpassord Observatørens rolle ville være å notere tilbakemeldinger både under og etter endt test. Tilbakemeldingene ville videre hjelpe oss med å avdekke feil eller mangler, som vi senere kan endre frem mot overleveringen av opplæringsplattformen til Seniornett. Før brukertestingen ble utført, fant vi ut at skjermbildene på brukermanualen var litt utdaterte. Disse stammet fra deler av nettsiden vår som senere hadde blitt endret på. Det ble derfor gjort endringer i brukermanualen før vi gikk i gang. 105

110 Tilbakemeldinger Første testdeltager reagerte ved første øyekast på at det første punktet burde ha vært en klikk på registrer meg. Videre var det et ønske for å ha en overskrift på alle stegene, med beskrivelse for hva selve steget gikk ut på. Testdeltageren savnet også et punkt for les mail og logg ut, slik at brukere uten store ikt-ferdigheter kan slå opp i brukermanualen for å finne disse funksjonene. Testdeltager to, syntes nettsiden i selv var enkelt å bruke, og de aller fleste av oppgavene ble utført uten særlig hjelp av brukermanualen. Brukermanualen ble kun for brukt for å holde seg på riktig steg og ikke gjøre oppgavene i feil rekkefølge. Med andre ord ble den brukt uten å lese særlig nøye på beskrivelser eller skjermbilder. For testdeltageren var mangelen på overskrifter og litt bedre beskrivelse på hvilket steg vedkommende var på, det største problemet. Når man flere ganger måtte minne testdeltageren om man hadde hoppet over et steg. Konklusjon Fordi brukertesten ble utført på to forskjellige personer med ulik ikt-ferdigheter, fant man raskt ut forskjellen på hvordan enkelte tilnærmer seg en brukermanual. Både på hva de bruker den til og hvordan de forholder seg til rekkefølgen på stegene. De fleste av tilbakemeldingene fra begge testdeltagerne gikk ut på å ha mer beskrivelser eller at det manglet overskrift. Vi fikk også litt ulik tilbakemelding fra brukerne, den første testdeltageren, savnet flere funksjoner og mer beskrivelse på flere av punktene. Testdeltager nummer to var nærmest ikke avhengig av brukermanualen, og brukte kun dette til for å holde seg til riktig rekkefølge på registreringen og innloggingen samt BankID simuleringen. Alt i alt kom denne brukertesten godt med, og vil på mange måter hjelpe oss med å lage en god brukermanual til testmiljøet vi har utformet. 106

111 Brukertesting av applikasjon Formålet med brukertesten er å teste ut applikasjonens brukervennlighet og om applikasjonen er tilstrekkelig nok for å kunne bli brukt til opplæring. Med brukervennlighet menes brukerens forståelse av applikasjonens navigasjon, menyer og struktur. Her fikk vi tak i noen bekjente som testbrukere, som testet ut applikasjonens funksjonalitet og grensesnitt. Denne brukertesten ble gjennomført utenom brukertestingene hos seniornett da applikasjonen ikke var en del av det oppdragsgiver hadde ønske om å teste på. Oppgaver Hver testbruker fikk utdelt fire oppgaver, dette var oppgaver som dekket de fleste av funksjonalitetene applikasjonen hadde. Dermed kunne vi lettere sile ut feil og mangler ved hjelp av brukertesten. Fire oppgaver: Registrer en ny bruker Logg inn Lese epost Gå tilbake til hovedmeny Oppfølgingsspørsmål Hva synes du om innloggingen? Fikk du logget inn? Hvis noe, hva var vanskelig? Hvordan var applikasjonen å bruke? Til slutt fikk de mulighet til å generell kommentere på gjennomføringen av brukertestingen vår og eventuelle forbedringer. 107

112 Resultat av brukertesting Ved gjennomgang av applikasjon kom vi frem til følgende resultater: Begge fikk registrert en ny bruker Begge fikk til innlogging Begge fikk lest test epost De syntes at det burde være klikkbart menyvalg og ikke en pil som sender dem videre. Det var vanskelig å tyde hva som var skrevet på enkelte menyer og pdf, ved bruk av tablet. Savnet flere funksjoner Svar på oppfølgingsspørsmål Hva synes du om innloggingen? Fikk du logget inn? Her fikk begge testbrukerne til innloggingen med det selvregistrerte fødselsnummeret og passordet. Dette ved hjelp av linken registrer bruker på hovedmenyen i applikasjonen, som videresendte dem til nettløsningen for registrering. Hvis noe, hva var vanskelig? Under brukertestingen klarte ikke begge testbrukerne å gå videre til neste meny på første forsøk. Dette skyldes at de gjentatte ganger forsøkte å trykke på feltene fremfor pilen (figur 49). Her måtte observatøren gripe inn og forklare at de måtte trykke på pilen for å gå videre. Figur 49 - Utklipp av applikasjonens meny Hvordan var applikasjonen å bruke? Testbrukerne syntes applikasjon i seg selv var enkel å bruke. Ved å trene seg på dette, ville de være forbedret om de skulle ta i bruk applikasjonen til Digipost senere. 108

113 Tilslutt fikk de mulighet til å generelt kommentere gjennomføringen av brukertesten og eventuelle forbedringer. Etter endt brukertest ønsket begge testbrukerne at det burde ha vært flere funksjoner. Med andre ord savnet de at applikasjon blant annet hadde funksjoner som send e-post, en søkefunksjon for å lete etter mail og legge til flere brukere under samme fødselsnummer. Dette er funksjoner som allerede finnes fra før på Digipost sin applikasjonen og ikke på vår applikasjon, som er opplæringsapplikasjon for registering, innlogging og les av test mailer. Analyse av brukertestingen I denne brukertesten kom det frem at navigasjonen var forstående og brukervennlig, ingen av de to testbrukerne hadde noen spesielle problemer eller store vansker med å navigere i menyene. Bortsett fra det slet begge med å gå videre fra menyene, dette skyldes gå videre pilen, som fantes i alle menyene. Her trykket de på feltene hvor det for eksempel sto postkassen og e-kvitteringer, i håp om å gå videre. Når man egentlig må trykke på pilen. Designmessig, så var skrift og størrelse på skriften veldig varierende i forhold til på emulatoren, som vi brukte for å utvikle samt brukerteste på. Under brukertestingen ble dette også testet på en galaxy tab. Her ble PDF-ene, skriften og alle menyene strukket i bredden for å passe hele skjermen. Noe som resulterte i strekte menyer, ulesbare test PDF-mailer og medførte at testbrukerne ikke kunne lese menyvalgene helt optimalt. Dette er noe vi kan se nærmere på og gjøre endringer på, for å lage en optimal opplæringsapplikasjon for flere enheter. 109

114 110

115 Kilder: - Seniornett. (Udatert). Foreninger. Hentet 26. januar 2016 fra - Seniornett. ( ). Seniornett Norge får Folkeopplysningsprisen. Hentet 03. Mars 2016 fra Norge-faar-Folkeopplysningsprisen - Lovdata. (Udatert). Lov om behandling av personopplysninger. Hentet 03. Mars 2016 fra - Sommerville, Ian (2011). Software Engineering (9th. Edition). Pearson Education. - Stallings, William & Brown, Lawrie (2011). Computer Security, Principles and Practice (Second Edition). Pearson Education - Morville, P., & Rosenfeld, L. (2006). Information Architecture for the World Wide Web (3. utg.). Sebastopol, California: O'Riley Media, Inc. - Sandnes, F.E. (2011). Universell utforming av IKT-systemer, Brukergrensesnitt for alle, Oslo: Universitetsforlaget - Høgskolen i Oslo og Akershus. ( ). VPN for Windows-PC. Hentet 04. April 2016 fra - Free MySQL Hosting. (Udatert). Hentet 04. April 2016 fra - Regjeringen. ( ). Staten tar nå i bruk digital postkasse. Hentet 15. April 2016 fra - Høgskolen i Oslo og Akershus. ( ). Har du opprettet digital postkasse?. Hentet 20. April 2016 fra - Statens institutt for forbruksforskning. ( ). Eldres bruk av digitale verktøy og internett. Hentet 20. Februar 2016 fra i

116 - Statens institutt for forbruksforskning. ( ). Eldres bruk av digitale verktøy og internett: En landsdekkende undersøkelse av mestring, støttebehov, motivasjon og hindringer. Hentet 20. Februar 2016 fra - Barne-, ungdoms-, og familiedirektoratet. ( ). Eldres bruk av IKT. Hentet 20 Februar 2016 fra - Web Accessibility evaluation tool. (Udatert). Hentet 30. Mars 2016 fra - W3schools. (Udatert). PHP 5 Global Variables Superglobals. Hentet 04. April 2016 fra - Mydevice. (Udatert). Hentet 08. Mai 2016 fra - W3schools. (Udatert). HTML Responsive Web Design. Hentet 09. Mai 2016 fra - Christensen, Bo Hjort. (2009). Effektiv anvendelse av IKT Elektronisk forretningsdrift (Versjon 5). - Lovdata. (Udatert). Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger. Hentet 13. Mai 2016 fra ii

117 Vedlegg: Vedlegg 1: Loggbok Dato 28.September Uke 40 Ikke møtt opp? Dagens gjøremål - Danner gruppe. - Diskutere prosjektoppgave. - Kontakte Tor Krattebøl. Problemer - Oppfyller prosjektet kravene? - Får Tobias kontakt med pappa? - Hva hvis vi ikke får førstevalget? - Skal det være et ferdig produkt? - Får vi pengestøtte? Til neste gang - Møte med Tor Krattebøl. - Skrive statusrapport. - Prøve å bestemme oss for et prosjekt. Dato 5.Oktober Uke 41 Ikke møtt opp? Dagens gjøremål - Skrevet statusrapport. - Levere inn statusrapport. Problemer - Har vi oppdragsgiver? - Hva annet kan vi finne på? Til neste gang - Skriv/lever prosjektskisse. iii

118 Dato 12.Oktober Uke 42 Ikke møtt opp? Dagens gjøremål - Ta kontakt med Turbodevs. - Noen som har et annet forslag? Problemer - Til neste gang - Møte med TurboDevs - Skrive ferdig prosjektskisse. - Bestemme oss for et prosjekt. Dato 25.Oktober Uke 43 Ikke møtt opp? Dagens gjøremål -Møte med Turbodevs -Møte med Tor Krattebøl Problemer - Finne veileder - Kravspesifikasjon Til neste gang - Skaffe oss veileder - Få tak i kravspesifikasjon - Skrive ferdig prosjetkskisse - Spørre om akademiskrapport. iv

119 Dato 5.November Uke 45 Ikke møtt opp? Dagens gjøremål - Lage webside Problemer - Trenger informasjon fra TurboDevs/Seniornett Til neste gang - Skaffe oss veileder - Få tak i kravspesifikasjon - Skrive ferdig prosjetkskisse Dato 18.November Uke 47 Ikke møtt opp? Dagens gjøremål - Ferdigstille projektskisse Henning Corneliusen(Syk) Problemer - Trenger kravspesifikasjon fra TurboDevs/Seniornett Til neste gang - Skaffe oss veileder - Få tak i kravspekken - Levere prosjetkskisse v

120 Dato 13.Januar Uke 2 Ikke møtt opp? Dagens gjøremål - Kontakte Veileder - Opprette kontakt med Seniornett - Opprette Forprosjektrapport Problemer Til neste gang - Finne Veileder - Kontakte med SeniorNett - Et av gruppemedlemmene kunne ikke fortsette på oppgaven. - Skaffe oss veileder - Få kontakt med Seniornett - Levere Forprosjektrapport Dato 18.Januar Uke 3 Ikke møtt opp? Dagens gjøremål - Kontakte Veileder - Opprette kontakt med Seniornett - Ferdigstille forprosjektrapport Problemer - Svar fra Veileder Til neste gang - Skaffe oss veileder - Få kontakt med Seniornett - Levere forprosjektrapport vi

121 Dato 20.Januar Uke 3 Ikke møtt opp? Dagens gjøremål - Veiledningsmøte med Veileder - Opprette kontakt med Digipost - Gå gjennom forprosjektsrapport sammen med veileder Problemer - Avvente møte med Seniornett Til neste gang - Levere forprosjektsrapport - Sende mail til SeniorNett - Teste DNB sin testside Dato 21.Januar Uke 3 Ikke møtt opp? Dagens gjøremål - Levere forprosjektsrapporten - Spørre dnb om testside - Sende mail til Seniornett - Lage gruppenavn - SeniorPost Problemer - Kravspesifikasjon - DNB hadde ikke testside Til neste gang - Møte med SeniorNett - Arbeidskontrakt vii

122 Dato 25.Januar Uke 4 Ikke møtt opp? Dagens gjøremål - Lage arbeidskontrakt - Kontakte Digipost angående testbruker - Starte med rapporten - innledning Problemer - Kravspesifikasjon - Ikke mulig å få testbruker fra digipost Til neste gang - Møte med SeniorNett - Skrive i prosjektrapport: - Bilal: Beskrivelse av seniornett - Kristian: Bakgrunn for prosjektet - Henning: Kort presentasjon av sluttproduktet - Lage Digipost brukere - Scanne inn samarbeidsavtale Dato 27.Januar Uke 4 Ikke møtt opp? Dagens gjøremål - Lage gantt-diagram - Lage risikoanalyse - Kontakte veileder Problemer - Veiledningsmøte avlyst - Møte med Seniornett Til neste gang - Legge fagbøker inn på dropbox - Fullføre gantt-diagram - Sette opp veiledningsmøte - Legge inn møter på trello - Begynne å tenke på utformingen av løsningen (prototyping) - Deaktivere digipost - Ta bilder av digipost - Oppdatere risikoanalyse - Kontrakt med Seniornett - Planlegge møte med Seniornett - Videresende kontrakt til Veileder. viii

123 Dato 01.Februar Uke 5 Ikke møtt opp? Dagens gjøremål - Lage arbeidskontrakt - Bilder av digipost - Oppdater risikoanalyse - Planlegge møte med Seniornett - Sende arbeidskontrakt til Veileder for validering Problemer - Kravspesifikasjon Til neste gang - Møte med Seniornett - Lag digipost bruker, følg med på hva som skjer under innlogging. - Printe ut arbeidskontrakt eventuelt gjøre endringer. Dato 04.Februar Uke 5 Ikke møtt opp? Dagens gjøremål - Møte med Seniornett - Skissere grensesnittet Problemer - Arbeidskontrakt Til neste gang - Sende arbeidskontrakt - Opprette Git-repository - Lage Kravspek ix

124 Dato 08.Februar Uke 5 Ikke møtt opp? Dagens gjøremål - Sammenkoble felles Git-repository - Lage Kravspek - Arbeidsoppgaver fra Trello - Bestemme flyt diagram - Jobbe med videre med frontend Problemer - Arbeidskontrakt - Sammenkobling av Git-repository Til neste gang - Begynne med backend - Alle sammenkobler Git-repository - Kravspek ferdigstillelse Dato 09.Februar Uke 5 Ikke møtt opp? Dagens gjøremål - Jobbe med database - Jobbe med registrering frontend - Lage brukermanual Problemer - Sammenkoble github Til neste gang - Ferdig med: - Databaser - Validering - Front-end - Brukermanual x

125 Dato 10.Februar Uke 5 Ikke møtt opp? Dagens gjøremål - Brukermanualer - Validering - Front end - Data til database Problemer - Fikk ikke til github, bruker dropbox i steden. Fungerer bra Til neste gang - Lage ferdig info sider - Front-end - Javascript Dato 15.Februar Uke 6 Ikke møtt opp? Dagens gjøremål - Front end - Legge inn php validering på reg. sidene - Endre HTML5 validering - www- database kobling Problemer - Til neste gang - PHP validering - Skrive på rapporten - Front end - Javascript validering - Svare på mail fra Veileder xi

126 Dato 16.Februar Uke 6 Ikke møtt opp? Dagens gjøremål - Fokusere på store ting - www kobling database - Mail front-end side - Fullføre 2 av de 3 stegene i registrering. Problemer - Testmail fra digipost - Koble Xampp Til neste gang - Jobbe med front-end - Feilmeldinger - Fylle data i databasen Dato 17.Februar Uke 6 Ikke møtt opp? Dagens gjøremål - Feilmeldinger - Front end registrering - Front end mailside Problemer - Testmail fra digipost - Koble Xampp Til neste gang - Ferdigstille mailsiden - Session 10 min logg ut - Backend : registrering-side - Frontend forside xii

127 Dato 18.Februar Uke 6 Ikke møtt opp? Dagens gjøremål - Ferdigstille mailsiden - Session 10 min logg ut - Backend : registrering-side - Frontend forside Problemer - Testmail fra digipost Til neste gang - Ferdigstille mailsiden - Session 10 min logg ut - Backend : registrering-side - Frontend forside Dato 22.Februar Uke 7 Ikke møtt opp? Dagens gjøremål - Checkbox på reg siden - Lage idle.php (inaktiv side) Problemer - Testmail fra digipost - Prøveperiode for database utløp, måtte betale for database hosting Til neste gang - Se trello liste Til Onsdag 24 - Møte med veileder - Gjøre alt klart til brukertesting xiii

128 Dato 23.Februar Uke 7 Ikke møtt opp? Dagens gjøremål - Checkbox på reg siden - Feilmelding reg siden Problemer - Testmail fra digipost Til neste gang - Se trello liste Til Onsdag 24 - Møte med veileder - Gjøre alt klart til brukertesting Dato 24.Februar Uke 7 Ikke møtt opp? Dagens gjøremål - Møte med veileder - Gjennomgang av kode - Alt på Til Onsdag 24 punktet - Lage spørreskjema for bruktertesting - Kontrakt for brukertesting Problemer - Farger på feilmelding Til neste gang - Brukertesting med Seniornett xiv

129 Dato 25.Februar Uke 7 Ikke møtt opp? Dagens gjøremål - Brukertesting Problemer - Til neste gang - Gjøre ferdig kravspek - Skrive om dagens brukertest - Planlegge prosjekskriving - Planlegge neste uke - Dato 26.Februar Uke 7 Ikke møtt opp? Dagens gjøremål - Gjøre ferdig kravspek - Skrive om dagens brukertest - Planlegge prosjekskriving - Planlegge neste uke Problemer - Til neste gang - Henning: - Systembeskrivelse - Kristian: - Use case beskrivelse 4 stk - Aktivitetsdiagram - Use case - draw.io - Bilal: - Beskrive brukertesting xv

130 Dato 01. Mars Uke 8 Ikke møtt opp? Dagens gjøremål - Gjennomgå oppgaver som ble utgitt. - Sette nye oppgaver - Lage sitemap - Lage vår logo - Sende mail til veileder Problemer - Til neste gang Diskuterer om arbeidsmetode Starte prosessdokumentasjon: - Henning: - Valg av oppgave - Definering av oppgave/omfang - Kristian: - Lag alternativt aktivitetsdiagram - Skrive forord og innledning - skrive om Blueprint - Bilal: - Brukertesting - Teknologier Dato 02. Mars Uke 8 Ikke møtt opp? Dagens gjøremål - Gjennomgå oppgaver som ble utgitt. - Sette nye oppgaver - Møte med veileder Problemer Til neste gang - Utviklingsmetodikk - ER-modellering - Henning: - Admin panel - Teknologier - Kristian: - Lese gjennom og rette - Endre use case - Blueprint beskrive - Første iterasjon - Bilal: - Digitaliseringsstrategi til staten (husk kilder) - Fullføre brukertesting xvi

131 Dato 07. Mars Uke 9 Ikke møtt opp? Dagens gjøremål - Starte på App - Starte på sms funksjon Problemer Til neste gang - Utviklingsmetodikk - ER-modellering - Sms funksjon lot seg ikke gjøre - Forhøre med Langemyr om sms funksjonalitet - App/teknologi skriving - Passordstyrke - Rapportskriving Dato 08. Mars Uke 9 Ikke møtt opp? Dagens gjøremål - Fortsette med Android-app - Forhøre med Langemyr om sms funksjonalitet - Ordne databasestruktur - Ordne Session variabler Problemer - Utviklingsmetodikk - ER-modellering Til neste gang - Fortsette med Android-app - Rapportskriving - Feilmeldinger på login/registrering. - Legg til bilde på regside xvii

132 Dato 10. Mars Uke 9 Ikke møtt opp? Dagens gjøremål - Fortsette med Android-app Problemer - Database - ER-modellering Til neste gang - Fortsette med Android-app - Rapportskriving - BankId og glemt passord - Skrive om mysql injectioon Dato 14. Mars Uke 10 Ikke møtt opp? Dagens gjøremål - Fortsette med Android-app - Sende mail til Langemyr - Database - BankID sider Problemer Til neste gang - Starte med IOS-app - Rapportskriving - BankId xviii

133 Dato 16. Mars Uke 10 Ikke møtt opp? Dagens gjøremål - Fortsette med IOS-app - BankID sider Problemer - epost fra Seniornett Til neste gang - Fortsette med IOS-app - BankId Dato 21. Mars Uke 11 Ikke møtt opp? Dagens gjøremål - Fortsette med IOS-app - BankID/glemt passord sider Problemer - epost fra Seniornett Til neste gang - Skrive rapport - App - Glemt passord xix

134 Dato 23. Mars Uke 11 Ikke møtt opp? Dagens gjøremål - BankID/glemt passord sider - Arbeidskontrakt - Skrive rapport Problemer - IOS-app Til neste gang - Ta kontakt med Seniornett - Beskrive IOS katastrofen - Forefallende arbeid. - Teknologier Dato 29. Mars Uke 12 Ikke møtt opp? Dagens gjøremål - Fikse regex - Brukermanual - Lage include for db tilkobling - Bytte index/forside navn - Fikse feilmld på samtykke siden. Problemer Til neste gang - Ta kontakt med Seniornett - Universell utforming - Planlegge brukertesting - Skrive på rapport. - Fikse CSS på bankid. xx

135 Dato 30. Mars Uke 12 Ikke møtt opp? Dagens gjøremål - Ta kontakt med Seniornett - Universell utforming - Regex - pdf fiksing - Fikse feilmelding bankid sidene Problemer Til neste gang - Planlegge brukertesting - Skrive på rapport. - Brukertest Torsdag 7.4 kl 11 - Fiks liten og stor A - Bytte mob-bilde med BID bilde - Front/back end avbrytknapp Dato 04. April Uke 13 Ikke møtt opp? Dagens gjøremål - Ta kontakt med veileder - Se på rapporten - Aa fiks - Brukertesting - Kontrakt med Seniornett - Gå gjennom på IPad mini Problemer Til neste gang - Planlegge brukertesting - Skrive på rapport. - Brukertest Torsdag 7.4 kl 11 - Spørreskjema - Gode passord side - Ios utfordring - Admin - Lage db bilde xxi

136 Dato 06. April Uke 13 Ikke møtt opp? Dagens gjøremål - Planlegge brukertesting - Teste nettsiden - Avtale med brukere - Brukermanual - Kontrakt med Seniornett - Spørreundersøkelse - Tekst på passord Bilal - syk Problemer Til neste gang - brukertesting Dato 07. April Uke 13 Ikke møtt opp? Dagens gjøremål - Gjennomføre brukertest - Signere og levere kontrakt - Gjennomgå brukertest Bilal - syk Problemer Til neste gang - Skrive om brukertest - Gjør endringer etter brukertest xxii

137 Dato 12. April Uke 14 Ikke møtt opp? Dagens gjøremål - Gjennomgå endringer - Se på rapport - Planlegge - Mail veileder Problemer Til neste gang - Blueprint - Lese igjennom - ordne docen - skrive om brukertesten Dato 18. April Uke 15 Ikke møtt opp? Dagens gjøremål - Se på rapport - Møte med veileder - Se på blueprint/sitemap Problemer Til neste gang - Gjøre oppgaver fra trello - Planlegge fremover - xxiii

138 Dato 25. April Uke 16 Ikke møtt opp? Dagens gjøremål - Gå igjennom spørsmålsark - Planlegge fremover - Kryssplattform app? - Windows Phone? - Mobilvennlig nettside? Problemer Til neste gang - Kryssplattform app - Rapportskriving Dato 02. Mai Uke 17 Ikke møtt opp? Dagens gjøremål - Se på diverse rapportskriving - Se på trello - Spørsmål rundt oppgavene Problemer - Tilbakemelding på rapporten Til neste gang - Gjøre tildelte oppgaver - Ferdigstille nettside - Hvor skal vi skrive ut? xxiv

139 Dato 03. Mai Uke 17 Ikke møtt opp? Dagens gjøremål - Ferdigstille nettsiden - Sende mail til veileder - Generell rapportskriving - Diagrammer (use-case) - Problemer - Til neste gang - Gjøre tildelte oppgaver - Mobilvennelig IDportenBankID Dato 09. Mai Uke 18 Ikke møtt opp? Dagens gjøremål - Generell rapportskriving - Se på nettsiden Problemer - Til neste gang - Møte Anis - Rapportskriving - Mail veileder - Brukermanualen xxv

140 Dato 12. Mai Uke 18 Ikke møtt opp? Dagens gjøremål - Generell rapportskriving - Se på nettsiden Problemer Til neste gang - Skrive rapport Dato 16. Mai Uke 19 Ikke møtt opp? Dagens gjøremål - Generell rapportskriving - Se på nettsiden Problemer Til neste gang - Ferdigstille rapport - Lese grundig i gjennom xxvi

141 Dato 19. Mai Uke 19 Ikke møtt opp? Dagens gjøremål - Generell rapportskriving Problemer Til neste gang - Ferdigstille rapport - Lese grundig i gjennom Dato 20. Mai Uke 19 Ikke møtt opp? Dagens gjøremål - Generell rapportskriving - Levere Problemer Til neste gang xxvii

142 Vedlegg 2: xxviii

143 xxix

144 Vedlegg 3: Spørreskjema brukertesting Før vi er ferdige med brukertestingen ønsker vi gjerne at du svarer på disse spørsmålene slik at vi kan få tilbakemeldinger på din opplevelse av nettsiden og dens funksjonaliteter. Dette er for å hjelpe oss med å videreutvikle løsningen og bachelorprosjektet i dens helhet. Sett sirkel rundt ditt svar: Fikk du til registrering? Ja Nei Fikk du til innlogging? Ja Nei Klarte du lese teksten uten problemer? Ja Nei Fikk du sett e-postene dine? Ja Nei Fikk du noen feilmeldinger under testingen? Ja Nei Hva synes du om registreringen? Hvordan gikk det? xxx

145 Hva synes du om innloggingen? Hvordan gikk det? Hvis noe, hva var vanskelig? Hvordan var nettsiden å bruke? Hvordan var helhetsopplevelsen med dagens gjennomføring? xxxi

146 Generelle kommentarer til gjennomføringen: xxxii

147 Vedlegg 4: Spørreskjema brukertesting Før vi er ferdige med brukertestingen ønsker vi gjerne at du svarer på disse spørsmålene slik at vi kan få tilbakemeldinger på din opplevelse av nettsiden og dens funksjonaliteter. Dette er for å hjelpe oss med å videreutvikle løsningen og bachelorprosjektet i dens helhet. Sett sirkel rundt ditt svar: Fikk du til innlogging med BankID? Ja Nei Måtte du noen gang trykke på avbryt knappen? Ja Nei Husker ikke Fikk du noen feilmeldinger under testingen? Ja Nei Husker ikke Hvilken styrke hadde passordet du laget deg? For svakt Svakt Sterk Supersikkert Husker ikke Hva synes du om innloggingen med BankID? Hvordan gikk det? xxxiii

148 Hva synes du om BankID brikken, var dens funksjon selvforklarende? Forklar Hva synes du om tankeboblen med personlig kode, var dens funksjon selvforklarende? Forklar Hvis noe, hva var vanskelig? Hvis du fikk noen feilmeldinger, var de til hjelp? xxxiv

149 Hvordan var helhetsopplevelsen med dagens gjennomføring? Generelle kommentarer til gjennomføringen: xxxv

150 Vedlegg 5: xxxvi

151 xxxvii

152 xxxviii

153 Vedlegg 6: xxxix

154 Vedlegg 7: xl

155 Vedlegg 8: Figur 50 - Skjermbilde av side 6. på Seniornett sin presentasjon om seniorers bruk av internett. xli

156 Vedlegg 9 xlii

157 xliii

158 xliv

159 xlv

160 xlvi

161 xlvii

162 xlviii

163 xlix