Prosessrapport. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Transkript

1 Prosessrapport Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31

2 Forord Prosessrapporten inneholder all dokumentasjon som omhandler arbeidsmetoder, utviklingsprosess og alt vi har vært igjennom i løpet av prosjektet. Den beskriver også hvilke verktøy og teknikker vi har brukt. Rapporten er i hovedsak beregnet for sensor, oppdragsgiver og veileder, men også for andre som er interessert i å lese om hvordan vi har jobbet. Det er ikke nødvendig med kompetanse på applikasjonsutvikling og prototyping for å lese denne rapporten, men det kan være en fordel. Rapporten er delt opp i åtte kapitler, som omhandler stadiene vi har vært igjennom i dette prosjektet. 2

3 Innholdsfortegnelse Forord... 2 Innholdsfortegnelse Innledning Gruppen Valg av oppgave Oppdragsgiver Bakgrunn for prosjektet Eksisterende løsning Mål for prosjektet Beskrivelse av prototypene Generell beskrivelse Skeuomorphic prototype Metro-prototype Utvikling av prototyper til mobile plattformer Generelt Vårt utgangspunkt for utvikling Planlegging Før prosjektstart Prosjektstyringsdokumenter Milepælsplan Fremdriftsplan og møtelogger Risikoplan Arbeidsteknikker Gruppearbeid Kommunikasjon med veileder og oppdragsgiver

4 4.4 Verktøy Programvare Dokumentasjon og backup Samsung Galaxy Note 10.1 og Microsoft Surface Utvikling av prototyper Kommunikasjon Utviklingsprosessen Konseptutvikling Forarbeid Introduksjon til Noark Idémyldring Målgruppe og behov Møter Datainnsamling Metode for datainnsamling Intervjurunde Nye krav til prototyper Produktutvikling Hybrid- og native-utvikling Funksjonalitet Design Arbeidsprosessen Kravspesifikasjon Bakgrunn Endringer Kravspesifikasjon og produkt

5 7 Produkttesting Hensikt med produkttest Verktøy og oppsett Egentest av prototyper Funksjonalitet Responstid Brukervennlighet og design Forskjellige enheter Skeuomorphic-prototype Avslutning Læringsutbytte Samarbeid i gruppen Hva kunne vært gjort annerledes? Veiledning Produktene Konklusjon Kilder og referanser Nettsider Litteratur Vedlegg

6 1 Innledning 1.1 Gruppen Prosjektet ble utarbeidet av fire studenter fra bachelorstudiet i anvendt datateknologi ved Høgskolen i Oslo og Akershus (HiOA): Eirik R. A. Hanssen, Lars Helgeland, Tobias Tambs og Andreas Wethal. Vi valgte å danne denne gruppen da vi tidligere har arbeidet godt sammen i andre fag og hatt god kommunikasjon og godt samarbeid. 1.2 Valg av oppgave Oppgaven var lagt ut som prosjektforslag internt på skolen, og vi kontaktet Thomas Sødring som er kontaktpersonen for denne oppgaven for å høre om vi kunne jobbe med denne prosjektoppgaven. Vi valgte denne oppgaven fordi det hadde et spennende og interessant tema, og for å lære noe nytt. I tillegg har vi gjennom studietiden ved HiOA jobbet mye med prototyping og brukergrensesnitt. 1.3 Oppdragsgiver Oppdragsgiver for dette prosjektet er NXC AS. Vår kontaktperson er Thomas Sødring ved HiOA/SAM/ABI som fungerer som et bindeledd mellom oss og oppdragsgiver. 1.4 Bakgrunn for prosjektet Noark (forkortelse for «Norsk arkivstandard») er en standard innenfor arkivdanning, og brukes innenfor blant annet arkivering og saksbehandling i offentlig sektor. Noark oppdateres stadig, og versjon 5 er nyeste versjon. Systemer som omhandler saksbehandling og arkivering må tilfredsstille kravene definert i Noark-standarden. NXC holder på å utvikle et nytt arkivsystem basert på Noark 5, der systemkjernen nesten var ferdigstilt da vi valgte oppgaven. Målet for dette arkivsystemet er at det etter hvert skal erstatte det eksisterende arkivsystemet i offentlig sektor, som i dag er basert på en eldre Noark-versjon. Før den nye kjernen kan tas i bruk, må det utvikles et brukergrensesnitt til den, og det var her vi kom inn i bildet. Vår oppgave gikk i utgangspunktet ut på å lage tre ulike brukergrensesnitt for et Noark 5- basert system, men etter samtaler med oppdragsgiver ble vi enige om at oppgaven skulle reduseres til å bare sammenligne to designprinsipper Metro og skeuomorphic og finne ut hvilket av disse som passer best til et Noark 5-grensesnitt. Designprinsippet som kom best ut av sammenligningen i vårt prosjekt skulle også tas et hakk videre, til prototype og eventuelt fullverdig applikasjon. 1.5 Eksisterende løsning Dagens løsning for arkivdanning og saksbehandling ved Høgskolen i Oslo og Akershus og ellers i offentlig sektor heter ephorte og er basert på Noark 4. ephorte er et omfattende system, og omfatter blant annet saksbehandling, importering av e-post og godkjennelsesrunder. 6

7 Hovedproblemet med ephorte er i følge de vi har snakket med (inkludert oppdragsgiver) at det med sitt lite intuitive brukergrensesnitt er tungvint og vanskelig å bruke. Vi ville derfor utvikle noe helt nytt, og som baserte seg på brukernes egne ønsker og preferanser. 1.6 Mål for prosjektet Målet med prosjektet var både å se på designprinsippene Metro og skeuomorphic, og, ved hjelp av intervjuer med brukere av eksisterende løsning, utvikle ett nytt brukergrensesnitt basert på brukernes egne ønsker. Brukergrensesnittet skal også være tilpasset bruk på nettbrett. Hvor langt vi skulle gå i utviklingen av brukergrensesnittene i de forskjellige designprinsippene var avhengig både av hvor mye tid vi hadde til rådighet og hvilket brukergrensesnitt vi mente passet best til løsningen. Planen var å lage en applikasjon basert på det designprinsippet vi mente passet best, og kun lage skisser og en enklere prototype for det andre designprinsippet. Underveis satte vi oss noen delmål: Intervjue brukere av dagens system Utarbeide en kravspesifikasjon for de nye prototypene Lage to prototyper (evt. applikasjon) for hhv. Metro og skeuomorphic Konkludere med hvilket av de to designprinsippene som egner seg best 7

8 2 Beskrivelse av prototypene I dette avsnittet vil vi gi en generell beskrivelse av prototypene vi skal utvikle, samt en innføring i hva skeuomorphic- og Metro-designprinsipper går ut på. 2.1 Generell beskrivelse Prototypene skal utvikles etter skeuomorphic- og Metro-designprinsippene. De skal utvikles hver for seg, på hver sin måte. Oppdragsgiver ønsker også at prototypene skal støtte bruk på nettbrett, noe som var avgjørende for hvilke utviklingsmiljøer vi valgte. 2.2 Skeuomorphic prototype Skeuormorphic-prototypen skal ha design i fokus, og ha inspirasjon fra den analoge verdenen. Det vil si at ikoner og elementer i programmet skal ligne på ting som finnes i den virkelige verden, som for eksempel at en skeuomorphic-kalender eller -kalkulator ser ut som en vanlig kalender eller kalkulator man har hjemme. Prototypen skal, etter avtale med oppdragsgiver, utvikles i et program kalt Axure RP, som er et prototypingsprogram. Denne prototypen vil ikke være koblet til Noark 5-kjernen, men vil vise hovedfunksjoner og hvordan et arkivsystem kunne sett ut ved bruk av skeuomorphicdesignprinsipper. Det vil altså bli en low fidelity-prototype, som betyr at den har lite teknisk funksjonalitet. Dette ble, i samarbeid med veileder, avtalt underveis i prosjektet, grunnet prinsipielle, men også tekniske og tidsmessige årsaker. Til design av prototypen lastet vi ned en ikonpakke («Milky») fra iconeden.com, som kan brukes fritt så lenge man ikke tjener penger på produkter basert på disse ikonene. Axure genererer prototypen i HTML og CSS, så denne kan brukes i en vanlig nettleser. 2.3 Metro-prototype Metro-prototypen skal lages etter Microsofts Metro-designprinsipper. Det betyr at informasjon er hovedfokuset i brukergrensesnittet, i motsetning til skeuomorphic, hvor selve designet/estetikken er viktigst. Metro-prototypen skal utvikles i Microsoft Visual Studio, som er et applikasjonsutviklingsverktøy som støtter Metro-grensesnittet. Dette programmet fungerer både som koding- og designverktøy. Etter avtale med oppdragsgiver skal prototypen kobles opp mot Noark 5-kjernen, og være fungerende når prosjektet avsluttes i slutten av mai All funksjonalitet må ikke være ferdigutviklet, da det bare skal være en prototype, men det er ønsket at mye av brukergrensnittet og de viktigste funksjonene for saksbehandlerrollen skal være på plass. Hovedpoenget med denne applikasjonen er at designprinsippene skal kunne vises frem og kunne vurderes opp mot andre løsninger. 8

9 3 Utvikling av prototyper til mobile plattformer 3.1 Generelt Utvikling for mobile plattformer (smarttelefoner og nettbrett) blir mer og mer populært, og disse plattformene har den siste tiden tatt større og større markedsandeler fra stasjonære og bærbare PCer. Utviklingen foregår ofte på samme måte som utvikling på andre plattformer, men det er flere ting man må ta høyde for: Skjermstørrelsen er mindre på mobile enheter, knapper og ikoner må være store nok til at de fungerer med berøringsskjerm, og programmet bør være enkelt å bruke (selvforklarende). Funksjonaliteten på en smart-telefon/nettbrett er også mer omfattende enn en normal PC. For eksempel så har man bevegelsessensorer, lokasjonstjenester (GPS), mobilt nettverk, kameraer og mye annet som de fleste PCer ikke har. Det er altså flere muligheter med mobile plattformer, siden man har flere tekniske tjenester man kan benytte seg av. Noen av begrensningene er batterikapasitet, skjermstørrelse og ytelse, noe som også må tas med i betraktning. Brukervennlighet er også et sentralt aspekt som er minst like viktig som på en PC. Å kombinere mye funksjonalitet med god brukervennlighet kan være en stor utfordring. 3.2 Vårt utgangspunkt for utvikling Våre prototyper er ment å brukes på nettbrett. Dette er på grunn av at oppdragsgiver ønsker å se på mulighetene for dette, da bruk av nettbrett stadig blir mer utbredt i arbeidssammenheng. Vi avgjorde derfor at vi skulle fokusere på å lage prototyper primært til nettbrett, men som også kan brukes på PC. Vi valgte, som allerede nevnt, å lage prototypen for skeuomorphic i Axure RP, som er et prototypingsprogram som genererer alle sidene i HTML og CSS. Dermed vil denne virke på alle plattformer som har en nettleser. Vi utviklet denne prototypen med utgangspunkt i visning på Android-nettbrett (oppløsning, ikoner og skjermbilder), men den vil også fungere på samme måte på en PC i nettleseren. Metro-applikasjonen er laget i Visual Studio (med programmeringsspråket C#), som støttes av både Windows 8 til PC og Windows RT til nettbrett. Vi valgte også her å tilpasse oppløsning og knapper så det ville fungere like bra på PC som på et nettbrett. 9

10 4 Planlegging 4.1 Før prosjektstart Før prosjekts oppstart i januar 2013, måtte det gjøres en del forberedelser. Dette gjaldt både avtaler om samarbeidet som skulle inngås og møter med veileder og oppdragsgiver. Vi måtte også velge verktøy vi skulle bruke, og installere dette på våre maskiner. 4.2 Prosjektstyringsdokumenter Vi har brukt en rekke styringsdokumenter gjennom prosjektet. Dette er administrative hjelpemidler som skal si noe om hvordan vi jobber og hva som skal gjøres. Noen av dokumentene ble opprettet i oppstartsfasen av prosjektet, og senere oppdatert og tilpasset underveis, mens noen av dokumentene ble opprettet senere Milepælsplan Vi laget en milepælsplan tidlig i prosjektet hvor vi førte opp de viktigste delmålene vi satte oss. Disse ble gitt egne frister som vi skulle jobbe opp mot. Etter hvert i prosjektet måtte denne tilpasses noe, men ble stort sett fulgt. Milepælsplanen ligger ute på prosjekthjemmesiden vår Fremdriftsplan og møtelogger I tillegg til milepælsplanen har vi også opprettet en fremdriftsplan i form av et Ganttdiagram. Diagrammet viser hvordan vi har jobbet og når vi har gjort de ulike deloppgavene. Diagrammet ble tilpasset underveis, men ble laget med milepælsplanen som utgangspunkt. Vi har også dokumentert alle møtene vi har hatt i form av møtelogger, hvor vi har skrevet ned hva vi har gjort. Dette bidro til å gi alle (inkludert veileder) en oversikt over hva som hadde blitt gjort og hvordan vi lå an. Alle møteloggene ligger på prosjekthjemmesiden vår i form av HTML-sider. 10

11 4.2.3 Risikoplan Vi opprettet en risikoplan som inneholder hendelser som kan opptre i løpet av prosjekttiden. Første kolonne beskriver hvilken hendelse som kan opptre. Den andre kolonnen handler om hvor stor sannsynlighet det er for at hendelsen skal opptre. For å kunne beregne risikoen for hver hendelse har vi brukt tall. I andre kolonne er tallene 1 til 4 brukt, der: 1 = Ikke sannsynlig 2 = Litt sannsynlig 3 = Moderat sannsynlig 4 = Svært sannsynlig Kolonne tre viser hvor stor konsekvens det vil ha for prosjektet dersom hendelsen opptrer. Vi har også her brukt tallene 1 til 4, der: 1 = Ikke farlig 2 = Farlig 3 = Kritisk 4 = Katastrofalt Den siste kolonnen viser hvor stor risiko det er for at hendelsen skal opptre. Her har vi brukt summen av kolonne to og tre for å anslå risikofaktoren: 2-3 = Liten risiko (Grønn) 4-5 = Middels risiko (Gul) 6-8 = Stor risiko (Rød) Hendelse Sannsynlighet Konsekvens Risiko Fravær og unnasluntring Uenigheter innad i gruppa Bortfall av gruppemedlemmer Mangel på motivasjon Tekniske problemer Tidsmangel Ujevn arbeidsfordeling Manglende/dårlig kommunikasjon i gruppa Mangel på kommunikasjon med veileder Mangel på kommunikasjon med oppdragsgiver

12 Hvordan unngå/redusere sannsynligheten og risikoen for hvert punkt? - Ved sykdom og annet fravær: Meld fra til gruppa i god tid, og sørg for at alle dine dokumenter er tilgjengelig for resten av gruppa så arbeidsoppgavene blir utført i tide. - Fravær og unnasluntring/ujevn fordeling: Ta opp dette på gruppemøter med den det gjelder og gi eventuelt vedkommende en advarsel. Det skal fordeles jevn arbeidsmengde på alle fire i gruppa, og om noen føler at de har mer enn andre tas dette opp og drøftes så alle blir enige om arbeidsoppgavene. - Uenigheter: Drøfte fordeler/ulemper ved de ulike meningene, eventuelt avtale et møte med veileder og/eller oppdragsgiver for å bli enig. - Bortfall av gruppemedlem: Sørge for at alle deloppgaver og gjøremål blir utført av resterende medlemmer. Eventuelt få råd av veileder om hvordan prosjektet kan gjennomføres. - Motivasjon: Alle på gruppa skal i størst mulig grad oppmuntre og engasjere de andre. - Tekniske problemer: Alle må ta backup! Sørg for å bruke et filformat som alle kan bruke. Ved manglende kunnskaper om tekniske aspekter hjelper vi hverandre så godt som mulig. - Tidsproblemer: Omfordele arbeidsoppgaver hvis dette kan hjelpe. Omprioritering og innsnevring av deler av prosjektet kan også vurderes. - Lite/dårlig kommunikasjon: Alle på gruppa må sørge for å følge med på e-post og Facebook-gruppa vår, samt være tilgjengelig på telefon til rimelige tider. På gruppemøtene kan man ta opp med den det gjelder angående manglende tilgjengelighet eller andre kommunikasjonsproblemer. Ved manglende kommunikasjon med oppdragsgiver må dette tas tak i. 12

13 4.3 Arbeidsteknikker Vi valgte å gå bort fra Scrum og andre velkjente prosjektarbeidsteknikker, og heller jobbe som vi tidligere har gjort under andre prosjekter. Vi har jobbet ut ifra en milepælsplan hvor vi har satt opp delmål til ulike datoer, og sørget for å ferdigstille disse delmålene innen fristen. Måten vi gjorde dette på var å danne oss en oversikt over omfanget til arbeidsoppgavene, fordelt oppgavene og jobbet med disse både sammen og på egenhånd. Dette synes vi har fungert bra før, noe det også har gjort i dette prosjektet. Vi følte ikke et behov for noen strengere organisering av arbeidet, og ble enige om å gjøre det på denne måten med hverandre, oppdragsgiver og veileder Gruppearbeid Gruppearbeidet har vært preget av godt samarbeid og få uoverensstemmelser. Medlemmene har møtt opp til avtalte møter, og generelt utført de arbeidsoppgavene som gruppen har forventet av dem. Vi har stort sett møttes på skolen 3-5 dager i uken og jobbet sammen. Vi har også jobbet litt sammen med Thomas. Arbeidsmetoden vår har fungert bra og fordelingen av arbeidsoppgaver har vært god Kommunikasjon med veileder og oppdragsgiver Kommunikasjon med oppdragsgiver (representert ved Thomas Sødring) har vært meget god, og vi har alltid kunnet kontakte og prate med ham hvis vi har hatt spørsmål eller problemer knyttet til prosjektet. Han har vært tilgjengelig for å svare på spørsmål vi har hatt om selve oppgaven, fremgangsmåter og tekniske aspekter. Vår veileder Michael har også vært tilgjengelig og vi har ofte hatt møter med han og Thomas samtidig. Da har vi diskutert blant annet fremgangen og hvordan vi skal legge opp arbeidet videre. Arbeidsprosessen har gått veldig bra, så vi har ikke hatt noe behov for at veileder må «rydde opp» og omorganisere prosjektet. Vi har rapportert til veileder om hvor langt vi har kommet, og han har fulgt med på Google Docs, der vi har alle dokumenter og møtelogger. 13

14 4.4 Verktøy Programvare Vi har brukt en rekke verktøy og programmer underveis i prosjektet. Vi har i hovedsak brukt programmer vi har erfaring med fra før, og som vi vet fungerer bra. Vi har blitt enige om bruk av programvare og holdt oss til dette under hele prosjektet. Den virtuelle maskinen hvor Noark-kjernen kjører trengte også en rekke programmer for å tilby den funksjonaliteten som vi måtte ha. Programmene/verktøyene vi har brukt er: Fildeling og dokumentasjon Google Drive / Docs Dropbox Microsoft Office-pakken Kommunikasjonsverktøy Telefoni/SMS Facebook Skype E-post (Gmail, Fronter) Utvikling og Web Microsoft Visual Studio (til Metro-applikasjonen) Microsoft Paint (til tidlige prototyper low fidelity og enkelte bilder) Microsoft Visio (til use case-diagram) Axure RP Pro (til skeuomorphic-prototypen) fluidui (nettleserbasert. Til skissering av prototype) Lucidchart (nettleserbasert. Til skissering av prototype) Google Chrome (nettleser for PC, Mac og Android) Notepad++ (for HTML/CSS til prosjekthjemmesiden) WinSCP (FTP-klient for prosjekthjemmesiden) Virtuell maskin VNC Viewer (remote desktop) MySQL Workbench Oracle VM VirtualBox Eclipse CVS Repository Exploring pgadmin III GNU Emacs 23 14

15 4.4.2 Dokumentasjon og backup Google Docs (Drive) er Googles nettbaserte kontorpakke, der brukeren har mulighet til å opprette dokumenter, presentasjoner, regneark og tegninger. Tjenesten er tilgjengelig for alle med en Google-konto. Vi brukte Docs til å skrive flesteparten av dokumentene, fordi flere brukere her har mulighet til å redigere dokumenter samtidig. Dokumentene ble også delt med vår interne veileder og oppdragsgivers representant for at de lettere skulle kunne gi oss tilbakemeldinger. Google Drive tilbyr også fillagring og -deling, så mange av dokumentene våre og backup-filer ble lagret her Microsoft Word, som er «standarden» innen tekstbehandling, ble brukt til formatering av leveransedokumentene vi hadde underveis i prosjektet. Selv om Google Docs fungerte bra på samarbeid, mangler denne en del viktig funksjonalitet som vi finner i Word. Dropbox ble brukt som fildelingsprogram, da vi hadde et behov for et sted å legge prototyper, backup og andre relaterte dokumenter, samtidig som alle fikk tilgang til disse Samsung Galaxy Note 10.1 og Microsoft Surface Samsung Galaxy Note 10.1 (Android 4.1) og Microsoft Surface RT (Windows 8 RT) er to nettbrett vi fikk låne av Høgskolen i Oslo og Akershus under store deler av prosjekttiden. Hensikten med disse nettbrettene var å gi oss et sammenligningsgrunnlag for de forskjellige designprinsippene, i tillegg til at de skulle fungere som testenheter for prototypene vi laget Utvikling av prototyper Under utviklingen av prototypene brukte vi ulike verktøy. Til low fidelity-skisser og tegninger brukte vi både penn og papir og Microsoft Paint. Til skisser brukte vi også Lucidchart og FluidUI, som inneholder verktøy, elementer og rammer bedre egnet for skissering av brukergrensesnitt enn Paint. Disse er nettleserbaserte prototypingsverktøy som vi brukte for å lage utkast og diskutere litt om hvordan en Android-applikasjon kunne se ut. Til skeuomorphic-prototypen brukte vi Axure, et program som er spesielt egnet for prototyping. Prototypen basert på Metro/Windows 8 laget vi i Microsoft Visual Studio Kommunikasjon Det ble under hele prosjektperioden kommunisert godt, både mellom gruppemedlemmer, veileder og oppdragsgiver. Kommunikasjonen mellom oss har vært god, og vi har ikke støtt på noen problemer på dette området alle har vært tilgjengelige hele tiden og svart på det som ble spurt om. Vi brukte ulike kanaler for kommunikasjon; mobiltelefon, e-post, Facebook og Skype noe som har fungert bra for alle. Vi har også hatt mange møter der vi har diskutert alle aspektene i prosjektet. Disse møtene har vært viktig for kommunikasjonen innad i gruppen, siden vi fikk snakket om hva som har blitt gjort og hva som gjensto. Alle gruppemedlemmene har møtt opp til de møtene vi har avtalt. 15

16 5 Utviklingsprosessen 5.1 Konseptutvikling Forarbeid Vårt første møte med oppdragsgiver (Thomas Sødring) fant sted rett etter vi hadde fått tildelt oppgaven. Vi snakket sammen om hva prosjektet gikk ut på, hva som ble forventet av oss og hvordan vi burde starte opp. Vi snakket også med veileder, og satte sammen en midlertidig plan for oppstartsfasen. Videre startet vi med forprosjektrapporten og kom i gang med å sette oss inn i hva vi skulle gjøre fremover. Vi fikk også en rask opplæring i hva Noark var og hvordan produktet vårt skulle fungere i praksis. En representant fra NXC, Dimitar Ouzounov, som har utviklet Noark-kjernen vi skulle jobbe med, var også med på dette. Han fortalte blant annet om hvordan kjernen er bygd opp og hvordan man kaller på metoder i denne. Vi hadde mange møter med Thomas i starten, hvor han hjalp oss med teknisk oppsett og andre aspekter Introduksjon til Noark 5 Noark 5 er en standard for arkivdanning som stiller krav til arkivstruktur, metadata og funksjonalitet. Noark 5 skal kunne brukes for alle typer arkivdanning, uavhengig av teknologisk løsning og type organisasjon. Alle former for aktiviteter som skaper dokumenter som er viktig å oppbevare og gjenfinne i autentisk form, skal i prinsippet inngå i en standardisert løsning for arkivdanning. Noark 5 er den siste utgaven av Noark-standarden, og ble publisert sommeren Fra og med 1. mars 2011 er Noark 5 versjon 3.0 gjeldende versjon. (Arkivverket.no, 2013) Hva har Noark 5 å gjøre med vår oppgave? Mange offentlige organer/instanser er pålagt å bruke Noark-standarden for arkivdanning og -behandling, men siden Noark bare er en standard, trenger man å ha et system basert på denne. For øyeblikket holder selskapet NXC på å utvikle et slikt system, og de har kommet så langt at systemet (systemkjernen) i teorien fungerer. Problemet er at de ennå ikke har utviklet noe brukergrensesnitt til denne kjernen. Oppgaven vår er å sammenlikne to forskjellige designprinsipper som kan brukes i utviklingen av brukergrensesnitt for dette systemet. Deretter starter vi utviklingen av to utkast til brukergrensesnitt basert på forskning og tilbakemeldinger fra brukere av det nåværende systemet; ephorte. 16

17 Et stort problem med GUI-løsninger brukt i eksisterende arkivsystemer er at de er kompliserte og vanskelige å bruke. Dette er basert på uttalelser fra saksbehandlere og andre som bruker systemet, i tillegg til vår oppdragsgiver, som er enig i dette. Det tungvinne designet fører til at saksbehandlere bruker lengre tid enn nødvendig på hver sak, og at de til og med kanskje omgår arkivsystemene, slik at ting ikke blir lagret og logget på riktig måte. Dette kan igjen føre til at dokumenter og viktige data blir vanskelige å finne igjen, eller i verste fall går tapt. Vår oppdragsgiver ser et behov for en nyskapning innenfor arkivdanning, som dekker alle behovene definert i Noark-standarden på en måte som ikke gjør oppgavene kjedelige og kompliserte. Dette kan gjøres blant annet ved å lage gode, brukervennlige brukergrensesnitt, og å bevege seg ut til nye plattformer, som for eksempel nettbrett Idémyldring I oppstartsfasen satt vi mye sammen med Thomas som forklarte hva han ville (at vi skulle) oppnå med prosjektet. Han kom med mange gode idéer om hva som kunne gjøres, både med tanke på prosjektprosess, design og tekniske løsninger. Vi kom tidlig i gang med å bruke internett (Google) til å finne eksempler på skeuomorphicog Metro-designeksempler, for å få en forståelse på hva disse gikk ut på. Vi så også litt på HiOAs veiledninger til dagens system (ephorte) for å forstå hvordan dette fungerer. I tillegg brukte vi nettbrettene vi fikk utdelt, og sammenlignet begge designprinsipper på disse Målgruppe og behov Målgruppen for våre nye programmer er brukere av alle arkiv- og saksbehandlingssystemer som er basert på Noark-standarden. Deres ønsker og behov for et nytt system er kartlagt gjennom intervjuer med brukere av ephorte ved HiOA, og dette har dannet grunnlaget for vår utvikling av de nye brukergrensesnittene. Brukerne av systemet har ulike roller: Administrator, arkivar, leder og saksbehandler, der saksbehandlere er i flertall og dermed har vært vårt største fokusområde. Alle rollene krever ulik funksjonalitet i systemet, noe vi måtte ta høyde for. Dette vil si at det er fire ulike utgangspunkter for funksjonaliteten i systemet Møter Vi har hatt møter både gruppen alene, men også med Thomas og Michael underveis i hele prosjekttiden. Der har vi gått igjennom hva vi har gjort, hva de synes og hvordan vi skulle legge opp prosjektet videre. I startfasen hadde vi mange møter for å fastslå hva vi faktisk skulle gjøre og hvordan oppdragsgiver ville at vi skulle jobbe. På møtene fikk vi svar på det vi lurte på angående administrative ting, design og tekniske aspekter. Alle møtene ble loggført på prosjekthjemmesiden. 17

18 5.2 Datainnsamling Metode for datainnsamling For å danne grunnlaget for prototypene våre måtte vi ha et inntrykk av hvordan brukerne av dagens system (ephorte) opplever dette, og hvordan de ville at et nytt system skulle fungere og se ut. Dette gjorde vi ved å intervjue syv personer som daglig bruker ephorte. Vi valgte intervjuer fremfor spørreundersøkelser da vi var interessert i mer kvalitativ informasjon enn det en spørreundersøkelse kunne gitt oss. Dette betyr mer utfyllende svar, og forklaringer på hvorfor de mener det de gjør. Vi ble enige om at en kvantitativ spørreundersøkelse ikke ville gi samme verdi for datainnsamlingen, da dette ofte innebærer korte, definerte spørsmål, uten noen form for utdyping av hvorfor de mener det de mener. Vi så heller ikke et stort behov for å skape statistiske fremvisninger av svarene vi fikk, så derfor endte vi opp med kun intervjuer. Vi skrev ned spørsmål vi ville ha svar på i en intervjuguide. Denne guiden skulle være mer en enkel oversikt over hva vi lurte på, fremfor et skjema vi fulgte slavisk. Vi endte opp med syv generelle spørsmål, som vi skulle stille og la respondenten svare på, hvorpå vi kunne spørre oppfølgingsspørsmål basert på svarene. Vi brukte boka «Det kvalitative forskningsintervju» (Kvale, S. & Brinkmann, S. 2009) for inspirasjon til oppsett av intervjuguiden. I et såkalt semi-strukturert intervju får vi muligheten til å spørre om ting som vi ikke nødvendigvis hadde tenkt på forhånd, men tar det mer på sparket etterhvert som vi får svar. Det er altså delvis respondenten som styrer retningen på intervjuet, i form av at han/hun snakker om det han/hun synes er mest viktig i forhold til det vi spør om. Spørsmålene vi hadde laget var ganske generelle, og gjorde at vi kunne få mer detaljerte svar om f. eks. hvorfor respondenten mener noe, hvordan respondenten gjør/ønsker ting og hva han/hun faktisk gjør i ephorte som er av interesse for oss Intervjurunde Vi intervjuet syv ansatte ved HiOA, som alle bruker ephorte. Disse personene hadde ulike roller, men de fleste var saksbehandlere. Intervjuene tok ca. 25 minutter og svarene vi fikk ble skrevet ned (kladdet) og spilt inn med respondentenes samtykke. Alle svarene ble så renskrevet i et samlet dokument, der vi sorterte alle svarene vi fikk systematisk etter spørsmålene. Alle respondentene ble anonymisert, og den eneste personlige informasjonen vi spurte om var rolle, hva de brukte systemet til og hvor lenge de hadde brukt systemet. De fleste av respondentene synes at prosjektet virket spennende og ønsket å hjelpe til. Vi fikk avdekket mange feil og mangler ved ephorte vi ikke hadde tenkt på tidligere. Mange hadde også forslag til nye ting de kunne tenkt seg implementert i et nytt system. Et sammendrag av intervjuresultatene finnes som vedlegg til denne rapporten. 18

19 5.2.3 Nye krav til prototyper Svarene vi fikk i intervjurunden dannet grunnlaget for hva vi skulle fokusere på i de nye prototypene. Vi fikk mange svar og mange var enige om flere ting. Vi fant dermed de ti tingene som gikk igjen hos de fleste, og som vi anså som de viktigste fokusområdene for oss. Disse meningene skulle danne grunnlaget for designet for våre prototyper og utgjøre de største forbedringene i forhold til ephorte. Disse ti tingene utgjorde utgangspunktet for funksjonaliteten i programmet, i tillegg til det som er bestemt i Noark-standarden. De ti viktigste fokusområdene vi kom frem til var: Oversikt over «hvor man er» (eksempel: Breadcrumbs). Endre terminologien fra arkivfaglig til noe alle kan forstå. Tydelig vise hva man jobber på (hvor i systemet) skille mellom arkiv, saksmappe, dokument, etc. Egen startside for hver rolle, kun med funksjoner som brukes av denne rollen. Minst mulig museklikking. Mulighet for egendefinert mappestruktur/lister, hvor man kan organisere saksmapper etter eget ønske. Hjelpetekster/hjelpefunksjon på hver enkelt side, fremfor en felles hjelpeside. Godt synlig knapp for å logge ut av programmet. Godt synlig hvilken rolle man er logget inn som. Mulighet for å markere saker som lest. 5.3 Produktutvikling Hybrid- og native-utvikling Vi hadde, ved utvikling av Metro-applikasjonen, mulighet til å utvikle enten hybrid eller native. Hybrid-utvikling vil si at en kan utvikle en applikasjon ved å bruke HTML og JavaScript sammen med native-kode for å få et produkt. Native-utvikling er utvikling av applikasjoner til en spesifikk plattform, for eksempel ios eller Android. Vi vurderte lenge å utvikle en hybrid-applikasjon med HTML og JavaScript. Dette var planen helt til vi fant ut at native-utvikling ville gå enklere med tanke på oppkobling mot arkivkjernen. I tillegg er Metro-design standard i Visual Studio. Hybrid-utvikling ville da ført til mer arbeid og unødvendig mye tilpasninger. Dermed avtalte vi internt i gruppa og med veileder og oppdragsgiver, at skulle utvikle native. Dette gjorde at vi måtte lære oss mer enn det vi hadde forventet. Ingen av gruppemedlemmene hadde noe erfaring fra native-utvikling med kodespråket C# før, og det ble dermed en del arbeid med å lære seg kodespråket før vi fikk utviklet noe som kunne ligne en applikasjon. 19

20 5.3.2 Funksjonalitet Vi startet utviklingen med å avgjøre hva som skal implementeres av funksjonalitet og hvor omfattende prototypene skulle være. Vi fant ut at de aller fleste funksjoner for saksbehandlere burde implementeres for å få et helhetsinntrykk av hvordan ting kommer til å virke i praksis. Vi hadde tidlig i prosjektet laget en kravspesifikasjon som inneholdt funksjonelle og ikkefunksjonelle krav til Noark generelt og noen som vi selv ville implementere. Disse kravene kom vi frem til sammen med Thomas og Michael, som begge mente det ville tilfredsstille kravene for hele prosjektet. I tillegg til den opprinnelige kravspesifikasjonen, brukte vi intervjuene som utgangspunkt for forbedringer og tilføyelser, som vi også skulle implementere. Dette til sammen utgjorde den fullstendige kravspesifikasjonen som vi arbeidet mot i utviklingen av funksjonaliteten til prototypene. Som nevnt skrev vi ned de ti viktigste kravene vi kom fram til basert på intervjuene, og disse skulle implementeres så langt det lot seg gjøre i forhold til tid og egen kompetanse. Vi mente at alle disse ti lot seg gjennomføre, og vi diskuterte litt hvordan vi skulle løse de ulike aspektene. For eksempel valgte vi å legge inn en favorittliste for saker, der brukerne kan markere saksmapper som «favoritter». På denne måten ville vi mer eller mindre dekke kravet for egendefinert mappestruktur, der respondentene ønsket seg en egen mappe hvor de kunne legge filer etter eget ønske. Brukerne ønsket seg også en mulighet for å markere saker som lest, noe vi (til dels) løste ved å ha en mappe for uleste saker. Dermed vil alle saker som ikke er lest ligge i denne mappen. Vi hadde som hensikt å implementere alle kravene, men grunnet tidsaspektet måtte vi utelate enkelte funksjoner og heller fokusere på å ferdigstille andre ting. Siden vi valgte å basere skeuomorphic-prototypen på HTML/CSS ville ikke alt av funksjoner støttes, så i denne prototypen vil det kun være menyvalgene for funksjonene som vises. I Metro-applikasjonen vil det meste av funksjonalitet fungere i henhold til kravspesifikasjonen Design Designet av prototypene gjorde vi etter vi hadde kartlagt funksjonaliteten. Når vi visste hva som skulle være med, kunne vi begynne å se på hvordan ting skulle se ut og henge sammen. Vi brukte som nevnt Microsofts krav for Metro-design i Metro-applikasjonen og holdt oss til dette. For skeuomorphic-prototypen brukte vi ikoner og tekst og laget en relativt enkel side, basert på vår oppfatning av skeuomorphic-design. Vi fikk dekket det aller meste av funksjonalitet for saksbehandler-rollen på begge prototypene (skeuomorphic kun i form av menyvalg/skjermbilder). Vi brukte også kravspesifikasjonene i designprosessen, hvor det var bestemt hvordan enkelte ting skulle se ut med tanke på navigasjon og estetikk. 20

21 5.3.4 Arbeidsprosessen Vi startet arbeidet med selve prototypene ved å skissere opp hvordan vi ønsket at de skulle se ut. Vi brukte kravspesifikasjonen kombinert med intervjuresultatene til skisseringen av designet. Til skissering brukte vi først penn og papir og Microsoft Paint, og gikk etter hvert over til nettbaserte prototypingsverktøy (FluidUI og Lucidchart) som vi brukte til skissering for oppsett av enkelte skjermbilder til skeuomorphic-prototypen. Vi lagde også noen use case-modeller som skal vise flyten i enkelte av oppgavene som systemet skal tilby (disse finnes som vedlegg til denne rapporten). Videre begynte vi utviklingen i Visual Studio og Axure RP for henholdsvis Metro- og skeuomorphic-prototypene. Vi ble først ferdig med skeuomorphic, siden denne var mindre omfattende enn Metro-prototypen. Skeuomorphic-prototypen lagde vi kun med Axure RP med en ikonpakke vi lastet ned. Resultatet ble en HTML-side med et utvalg skjermbilder for saksbehandlerrollen, som viser hvordan et skeuomorphic-basert arkivsystem kan se ut. Metro-applikasjonen tok vesentlig mye lengre tid, mye på grunn av at dette skulle være en high fidelity-prototype som faktisk skulle fungere mot kjernen, men også fordi selve programmeringen var vanskeligere og mer omfattende. Hele applikasjonen ble kodet og designet i Visual Studio, og vi jobbet jevnt med denne frem til innlevering. Dokumentasjon for produktene ble skrevet underveis i utviklingsfasen. 21

22 6 Kravspesifikasjon 6.1 Bakgrunn Vi begynte med å sette opp en liste med «selvsagte» funksjoner og elementer som burde være med i et nytt brukergrensesnitt. Dette var generelle ting som vi på gruppa, etter å ha snakket med oppdragsgiver, mente burde være med. Vi delte opp kravspesifikasjonen i funksjonelle og ikke-funksjonelle krav, samt delte opp kravene i «må-krav» og «bør-krav». Vi bestemte oss fort for at det vi mente burde være med ikke var nok, og at vi, for å få en skikkelig kravspesifikasjon, burde ta en intervjurunde med de som bruker dagens arkivsystem. Bare på denne måten kunne vi få til en kravspesifikasjon som gjenspeiler det brukerne ønsker av et slikt brukergrensesnitt. 6.2 Endringer Etter å ha ferdigstilt intervjurunden og analysert og samlet resultatene så vi fort at vårt tidligere utkast til kravspesifikasjon var mangelfullt. Respondentene hadde kommet med mye informasjon om hva de ønsket seg i et nytt arkiv- og saksbehandlingssystem. Vi skrev derfor en liste over de viktigste ønskene til brukerne som ble intervjuet. Denne kravspesifikasjonen ble igjen innskrenket til bare å inneholde de ti viktigste punktene. Dette måtte gjøres på grunn av tidsbegrensninger, da vi ikke hadde mulighet til å tilfredsstille alle behov og ønsker. Vi valgte ut selv de ti nye kravene, basert på viktighet og hvorvidt det var mulig å implementere i våre prototyper. 6.3 Kravspesifikasjon og produkt Den opprinnelige kravspesifikasjonen var veldig generell og enkel, så alt i denne ble tilfredsstilt, med unntak av en brukerveiledning («how-to») som vi hadde under «Mulige utvidelser». Kravene i denne spesifikasjonen gikk i korte trekk ut på hva vi skulle lage og hvordan den skulle programmeres altså ingen detaljerte krav om funksjonalitet, utenom det som Noark-standarden krever. Denne kravspesifikasjonen dekket altså bare rammeverket for prototypene. De ti kravene vi valgte fra intervjuresultatene var mer rettet mot detaljer og funksjoner, og ble i stor grad innfridd. På skeuomorphic-prototypen ble disse tilfredsstilt kun ved statiske menyvalg og ikoner. På Metro-applikasjonen ble kravene innfridd hvor funksjonaliteten er på plass. 22

23 Liste over de ti kravene og hvorvidt disse ble innfridd: Krav Status skeuomorphic Status Metro Oversikt over hvor man er (f. eks. breadcrumbs) Endre terminologien fra arkivfaglig til noe alle forstår (journalpost etc.) Tydelig vise hva man jobber med (arkiv, saksmappe, dokument etc.) Tilpasset startside for hver rolle. Ikke vise funksjoner man ikke kan gjøre som denne rollen. Minst mulig klikking Mulighet for egen liste/mappestruktur for saksmapper. Hjelpetekster på hver side, i stedet for en hjelp-side. Godt synlig knapp for å logge ut av systemet. OK. Breadcrumbs på hvert skjermbilde. OK. Endret uttrykk som for eksempel «journalpost» til «registrering» OK (brukt beskrivende ikoner for hver type) OK. Hver rolle har hver sin startside. OK. Ikoner og menyvalg på hver side. Alle funksjoner samlet på startsiden. OK. Løst ved å kunne merke saksmapper som «Favoritter» som kan listes opp. OK. Eget felt på de fleste sider med forklaringstekster. OK. Ligger synlig øverst til høyre i hvert skjermbilde. Tittel beskriver «hvor man er». Applikasjonen har veldig få sider, og vi valgte å fjerne bredcrumbs for å få en strømlinjeformet opplevelse. OK. Endret uttrykk som for eksempel «journalpost» til «registrering» OK. Saksmapper, registreringer og filer ser helt forskjellige ut, og er organisert i en mappestruktur. Det er få sider i applikasjonen, så vi har ikke lagt mye vekt på å utheve dette noe mer. OK. Hver rolle har hver sin startside. OK. Applikasjonen har generelt få sider, og man kan få gjort mye på hver side. Applikasjonen henter mye data selv, og genererer metadata automatisk. OK. Løst ved å kunne merke saksmapper som «Favoritter» som kan listes opp. Ingen hjelpetekster, men alle knapper har gode tekstbeskrivelser. Denne ligger i «app-bar» som er en nedtrekksmeny integrert i Metro-rammeverket. 23

24 Godt synlig hvilken rolle man er logget inn som. Mulighet for å markere saker som lest. OK. Er en dropdown-liste som viser rollene man har tilgang på, og hvilken man er logget inn som. Delvis OK. Alle uleste saker ligger i en egen mappe. Man velger rolle når man logger inn. Må logge inn på nytt for å bytte rolle. Nei. Kjernen har ikke støtte for dette, å implementere en slik løsning vil da ligge i grensesnittet. Vi fant ingen god løsning på dette etter hvert som store mengder saker ble lest. 24

25 7 Produkttesting 7.1 Hensikt med produkttest Vi valgte å gjennomføre en enkel slutt-test på vår prototype, for å se hvordan den fungerer, og om den tilfredsstiller kravene vi hadde utarbeidet. Vi har naturligvis også testet mye underveis i utviklingsfasen, så vi hadde en god oversikt over hvordan ting så ut og virket. 7.2 Verktøy og oppsett Testingen ble foretatt som en simulering av vanlige arbeidsoppgaver (saksbehandler) i nettleser for skeuomorphic, og på PC og nettbrett for Metro-applikasjonen. Skeuomorphicprototypen kan vises i alle nettlesere, og vi brukte Google Chrome på en Windows-maskin. Metro-applikasjonen ble vist på både en PC med Windows 8 og Windows Surfacenettbrettet vi fikk låne av skolen. 7.3 Egentest av prototyper Funksjonalitet Funksjonaliteten i Metro-applikasjonen tilfredsstiller de fleste kravene som vi har spesifisert basert på data som er definert i Noark-standarden, men da kun for saksbehandlerrollen. Noen av funksjonene er søk, opprettelse av saksmapper og registreringer, visninger av saksmappe, registrering og integrert dokumentvisning og opplastning av egne dokumenter. De implementerte funksjonene virker (etter vår mening) som de skal, men vi har ikke implementert feilmeldinger. Applikasjonen hadde også trengt noe finpuss hvis den skulle blitt brukt offentlig Responstid Responstid skjermbilde til skjermbilde (internt i applikasjonen) er bra. Funksjoner som ikke trenger kontakt med server flyter veldig bra, både på PC og på nettbrett. Responstiden på applikasjon til server og omvendt er relativt god, men det kommer også an på internettforbindelsen. Når vi har testet har vi aldri opplevd lang ventetid på forespørsler til server Brukervennlighet og design Både Metro-applikasjon og skeuomorphic-prototypen er enkle å bruke (mener vi), og man forstår fort hvordan ting henger sammen. Skeuomorphic design er et ganske bredt begrep, men vi føler vi har fått til en prototype som havner innenfor denne kategorien, blant annet med utbredt bruk av ikoner og elementer hentet fra / basert på den «virkelige verden». 25

26 Metro-applikasjonen følger Metro-prinsippene bra, og det ser absolutt ut som en applikasjon designet for Windows 8. Brukergrensesnittet fungerer bra, og det er helt klart informasjon som står i fokus her Forskjellige enheter Metro-applikasjonen fungerer veldig bra både på PC og nettbrett. Forskjellen går da på bruk av hender og fingre mot å bruke mus og tastatur. Dette blir da altså en vanesak; liker du best å bruke mus og tastatur, støtter applikasjonen det fullt ut, og er like god å bruke på PC som på nettbrett Skeuomorphic-prototype Skeuomorphic-prototypen er også blitt testet både på PC og nettbrett. Denne fungerer godt på PC, men noen av elementene blir litt små for et nettbrett (ca. 10 tommers skjerm). Prototypen gir en indikasjon på hvordan et arkivsystem kunne sett ut ved bruk av et designspråk basert på skeuomorphic. Nettsidene viser hvordan ting kan være lagt opp og designet, og vi mener også her at det er lett å finne frem til alle funksjoner. 26

27 8 Avslutning 8.1 Læringsutbytte Alt i alt har vi lært mye i løpet av prosjekttiden. Vi har i større grad en før jobbet selvstendig, satt egne rammer og tidsfrister, og lært å fungere sammen som en gruppe gjennom et (for oss) relativt langvarig prosjekt. Vi har også fått mye ny kunnskap om forskjellige designprinsipper, prototyping og apputvikling, inkludert programmering. Prosjektgjennomføring Vi har fått god kjennskap til hvordan et større prosjekt bør og ikke bør gjennomføres, med tanke på tidsfrister, rammer, styringsdokumenter, møter, planer, kommunikasjon innad og med arbeidsgiver og veileder m.m. Brukergrensesnitt og designprinsipper Vi har tilegnet oss mye kunnskaper om designprinsippene skeuomorphic og Metro, noe som var et av hovedmålene med prosjektet. Vi har lært forskjeller på forskjellige prinsipper, og har fått kunnskaper om hvilke sammenhenger prinsippene bør brukes i (Metro fungerer best til arkivsystem etc.). Arkivsystemer Ved å jobbe med akkurat denne oppgaven, har vi også fått en del innsikt i arkivsystemer og offentlige arkivstandarder. Det er essensielt at disse standardene og reglene følges av alle offentlige instanser som bruker arkivsystemer, slik at det er sikkert at saker og dokumenter ikke går tapt og at de kan gjenfinnes i sin autentiske form. I tillegg har vi sett på en del av oppgavene som blant annet saksbehandlere daglig utfører i slike systemer, og hvordan de samhandler med systemet. Dette har vært med på å danne grunnlaget for kravspesifikasjonen vår og generelt gjennomføringen av prosjektet. Tidsbruk og planlegging Da dette er det mest omfattende prosjektet noen av oss har hatt (i skolesammenheng), har vi lært og utviklet oss mye, særlig når det kommer til planlegging, styring, kommunikasjon og samarbeid. Vi har lært viktigheten av blant annet å komme raskt i gang, ha definerte mål og tidsfrister, og god arbeidsfordeling og arbeidsflyt. Design, prototyping og applikasjonsutvikling I utviklingsfasen av prosjektet har vi brukt programmer og rammeverk vi ikke tidligere hadde erfaring med. Vi laget Metro-applikasjonen i Visual Studio, som har C# som standardspråk, noe vi har måttet lære oss underveis. 27

28 Vi har også lært hvordan vi bør designe applikasjoner som skal brukes på flere plattformer (PC og nettbrett), og hvordan vi får disse til å fungere like bra på begge plattformer. Samtidig har vi også lært en del om det tekniske oppsettet av kjernen, og tilkobling til og kommunikasjon med denne. Vi har brukt en rekke prototypings- og designverktøy, og lært oss hvordan vi bruker disse for å oppnå målene vi har satt. Dette er designverktøy for applikasjonsutvikling (FluidUI og Lucidchart) og et prototypingsprogram (Axure RP) som vi har brukt til utviklingen av skeuomorphic-prototypen. Dokumentasjon Under hele prosjekttiden har vi dokumentert det vi har gjort, som for eksempel å skrive møtelogger og på prosessrapporten. Vi har fått enkelte maler og veiledninger for rapportoppsett som vi har brukt som rammeverk for all dokumentasjon. Disse har vi igjen endret på, slik at de har passet våre behov. 8.2 Samarbeid i gruppen Gruppa har jobbet godt sammen under hele prosjektet, og det har aldri vært noen større konflikter. Vi har stort sett vært enige om hvordan ting burde gjøres, og hvis det har vært uenigheter, har dette fort blitt løst gjennom dialog, slik at vi har fått til gode løsninger som alle på gruppa har kunnet stille seg bak. Samarbeidsmåten har gått ut på å fordele arbeidsoppgaver, ferdigstille disse og vise frem til de øvrige gruppemedlemmene hva man har gjort. Gruppen har så kommet med tilbakemeldinger og forslag til endringer. På denne måten har vi på sett og vis jobbet selvstendig, samtidig som at gruppen som helhet har vært med på alle større beslutninger. 8.3 Hva kunne vært gjort annerledes? Vi hadde en litt treg oppstart, hvor vi blant annet måtte vente ganske lenge før intervjuene kunne gjennomføres. Med andre ord kunne selve planleggingen av intervjurunden blitt gjort mer effektivt. Vi hadde også en del tekniske utfordringer i starten, med oppsettet av kjernen og maskinen der denne skulle kjøres. Siden dette tok litt tid, kom i sent i gang med rammeoppsettet for Metro-applikasjonen, men dette har vi hentet inn senere. 8.4 Veiledning Når det kommer til veiledning, har vi fått mesteparten av denne fra vår oppdragsgiver/mellommann Thomas Sødring. Han har hele tiden hjulpet oss med problemer og spørsmål underveis, og har i tillegg kommet med egne forslag og ideer om hvordan diverse aspekter av prosjektet kunne gjøres bedre og mer effektivt. Thomas har også hele tiden lagt vekt på at det er vårt (gruppen sitt) prosjekt, og de idéene han har hatt til utviklingen, er ting som vi har kunnet forkaste hvis vi ville gjøre ting annerledes. 28

29 Med tanke på rapportskriving og hvordan vi benyttet tiden vår, var Michael veldig behjelpelig på dette området. Han kom underveis med ideer om hvordan vi kunne sette opp arbeidet og hvordan vi skulle beregne tidsbruken på hver enkelt prosess. Dette endte med god arbeidsfordeling og god struktur i rapporten med bra innhold. 8.5 Produktene Produktene vi har laget i dette prosjektet er som nevnt én skeuomorphic-basert prototype laget i HTML/CSS og én Metro-applikasjon laget i Visual Studio (C#). Metro-applikasjonen er desidert mest omfattende, og er laget som en fungerende high fidelity prototype. Begge produktene er forslag til hvordan de ulike designprinsippene kan anvendes i et arkiv- /saksbehandlingssystem, og kan danne et grunnlag for videre forskning på dette området. Vi mener at produktene våre viser det oppdragsgiver ønsket, som var eksempler på bruk av Metro og skeuomorphic for et Noark-basert system. 8.6 Konklusjon Dette prosjektet har vært det mest omfattende alle på gruppen har jobbet med i skolesammenheng, noe som også gjenspeiles i det vi har lært. Vår kunnskap om applikasjonsutvikling og prototyping var ganske begrenset ved prosjektets oppstart, og vi har hatt en bratt læringskurve på dette feltet. Vi har også i prosjektet lært masse om dokumentasjon, planlegging og prosjektgjennomføring generelt. Vi har naturligvis støtt på mange utfordringer underveis, men har som gruppe klart å løse disse på en god måte, og holdt alle frister vi har satt. Arbeidsprosessen har vært nokså jevn og arbeidsfordelingen har vært rettferdig. Vi har heller ikke støtt på noen større problemer når det gjelder samarbeid og kommunikasjon. Alle har gjort det som ble forventet av gruppen og har bidratt til å gjøre prosjektet til det har blitt. Produktene tilfredsstiller de viktigste kravene vi spesifiserte, og vil forhåpentligvis være til hjelp for oppdragsgiver ved utredning av brukergrensesnitt for arkivsystemer i fremtiden. 29

30 9 Kilder og referanser 9.1 Nettsider Content customs. ( ). jpg-bilde. Hentet fra: Brukt til: Forsidebilde Kunnskapssenteret. ( ). Risikoanalyser / -matriser. Hentet fra: anisere_forbedringsarbeidet/ros-analyse/1301 Arkivverket. ( ). Noark 5. Hentet fra: Iconeden. ( ). Milky iconser. Hentet fra: Brukt til: Ikonpakke for skeuomorphic-utvikling HiOA. ( ). Brukerveiledning for saksbehandlere. Hentet fra: Brukt til: Veiledning til ephorte 9.2 Litteratur Kvale, S; Brinkmann, S. (2009). Det kvalitative forskningsintervju. Oslo: Gyldendal Akademisk. 10 Vedlegg Vedlegg 1: Intervjuresultater sammendrag Vedlegg 2: Use case-modeller 30