Hovedprosjekt Noark 5 grensenitt. G r u p p e 3 1

Transkript

1 Hovedprosjekt 2013 Noark 5 grensenitt G r u p p e 3 1 Prosjektrapport for gruppe 31 ved institutt for informasjonsteknologi ved Høgskolen i Oslo og Akershus E i r i k R. A. H a n s s e n L a r s H e l g e l a n d T o b i a s T a m b s A n d r e a s W e t h a l

2

3 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Noark 5 grensesnitt PROSJEKTDELTAKERE Eirik R. A. Hanssen Lars Helgeland Tobias Tambs Andreas Wethal OPPDRAGSGIVER NXC AS Industrigata Oslo s s s s DATO ANTALL SIDER 96 INTERN VEILEDER Michael Preminger KONTAKTPERSON Thomas Sødring E-post: Thomas.Sodring@hioa.no Telefon: SAMMENDRAG Dette prosjektet har gått ut på å diskutere to ulike designprinsipper for brukergrensesnitt til Noark 5-kjernen, og deretter utvikle en funksjonell prototype basert på det prinsippet som vi mener er best egnet. Noark 5 er en arkivstandard som benyttes til arkivdanning og saksbehandling i offentlig sektor. Grensesnittene er hjelpemidler som skal bidra til å forenkle hverdagen til ledere og saksbehandlere som bruker denne arkivstandarden. Designprinsippene er basert på Windows Metro og Skeuomorphic. 3 STIKKORD Metro, Skeuomorphic, Brukergrensesnitt

4

5 Forord Om rapporten Sluttrapporten for gruppe 31 inneholder alt av dokumentasjon som er utarbeidet i løpet av hovedprosjektet våren Prosjektoppgaven «Noark 5 grensesnitt» er gitt av NXC AS, og er vårt avsluttende hovedprosjekt for bachelorstudiet i anvendt datateknologi. Sluttrapporten består av tre delrapporter; Prosessrapport, produktrapport og kravspesifikasjon, som alle er selvstendige rapporter med egen innholdsfortegnelse og sidenummerering. 1. Prosessrapporten viser vårt arbeid med prosjektet, progresjonen og hvilke valg vi tok underveis, med begrunnelser. 2. Produktrapporten beskriver selve produktet, utviklingsfasen og valg vi tok. 3. Kravspesifikasjonen beskriver kravene som ble satt av oppdragsgiver i samarbeid med oss og våre undersøkelser. Prosjekthjemmeside I tillegg til rapportene har vi også lagt ut en del annen informasjon om prosjektet på vår prosjekthjemmeside. Her finnes blant annet møtelogger, informasjon om gruppen, forprosjektrapport og PDF-versjon av alle rapportene. Prosjekthjemmesiden finnes på Takk til bidragsytere Vi ønsker å takke de som har hjulpet oss med å få gjennomført dette prosjektet: Thomas Sødring, HiOA som har vært vår nærmeste oppdragsgiver. Thomas har hjulpet oss veldig mye med alt fra prosjektgjennomføring til tekniske aspekter. Michael Preminger, HiOA som har vært vår veileder under dette prosjektet. Michael har sørget for at progresjonen i prosjektet har gått jevnt og at vi har gjort alt vi skal. Amir Maqbool Ahmed, HiOA som har hjulpet oss med lån og oppsett av VM for det første tekniske oppsettet vi brukte til Noark-kjernen.

6

7 Prosessrapport Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 Vedlegg 1: Intervjuresultater sammendrag Dette er et sammendrag av alle svarene vi fikk fra intervjurunden. Disse svarene utgjorde grunnlaget for de nye kravene vi kom frem til. Vi har strukturert dette sammendraget ved at vi har skrevet ned de svarene vi fikk, sortert på spørsmålene vi stilte. Hva bruker du ephorte til? Opprette: o Mapper o Saker Hente dokumenter/e-post fra Outlook Legge inn skannede dokumenter Sluttføre saker Skrive brev Legge inn info om studenter Behandle innkommende brev og søknader Besvare saker på e-post Brukes også som arkiv Minst mulig Lagrer (arkiverer?) personalsaker og avtaler Finne informasjon Viktigste funksjoner og deler av ephorte Opprette nye dokumenter Importere vedlegg og e-post fra Outlook o Importsentralen Min innboks (tildelte saker) Søkefunksjon Godkjenningsrunde Send til godkjenning Mottatte godkjente dokumenter Siste saker Mine saker Til orientering Nettbrett vs PC Flesteparten av saksbehandlerne skriver mye, og trenger dermed tastatur for å være effektive. I tillegg trenger mange stor skjermplass, noe som selvsagt blir et hinder med bruk av nettbrett. Noen mener likevel at en nettbrett-applikasjon med tilkobling til arkiv kunne blitt brukt som oppslagsverk, og da spesielt for lederrollen.

38 Må/bør forbedres i nytt system Må være intuitivt o Brukere bør etter én dags kurs kunne forstå hvordan grunnleggende oppgaver kan utføres o Renere og enklere brukergrensesnitt Terminologi bør ikke være for vanskelig o Hvis terminologien beholdes, bør brukere ha en oversikt over hva som menes med de forskjellige termene Det bør være én (riktig) måte å gjøre én ting på o Det skaper forvirring hvis den samme oppgaven tilsynelatende kan utføres på forskjellige måter og på forskjellige steder i systemet Det må være enkelt å skille mellom journalposter og dokumenter o Forvirrende med samme tittel og utseende i dagens løsning Hver rolle bør ha sitt eget sett med funksjoner, tilpasset den rollens oppgaver o Det ønskes også en mulighet for å vise og skjule «avansert» funksjonalitet Eventuelt at brukere tilpasser sitt eget «område» og/eller startskjerm o Må være synlig hvilken rolle man er logget inn som Søkefunksjon må kunne finne resultater som har liknende ord som søkestrengen o + Utvidet og forenklet bruk av jokertegn (wildcards) o + Fulltekstsøk Forbedret importsentral (epost) o Mulighet for å hente all epost fra Outlook o Må kunne sortere og søke i epost via importsentralen Bør ha sakslister/-mapper som kan tilpasses av hver bruker o Tillater sortering og rask gjenfinning av saker o Ref. Spotify og spillelister Sangene flyttes ikke til spillelistene, men det blir laget snarveier Bør være mulig å se hvor saker ligger i «godkjenningsrunden» o på vei til og fra godkjenning Unngå unødvendige og forstyrrende dialogbokser som «Er du sikker på at du vil» Bør kunne støtte flere OS o Minimum Windows og Mac Ha bedre integrasjon med andre programmer (bl.a. importere og eksportere filer) o Eks. Word, Outlook, FS Bør ha mulighet til å vise hjelpetekster o Enten ved å holde musepekeren over elementer, eller ved å ha et klikkbart (spørsmåls)tegn bak elementer o Kan gjerne også ha en søkbar og navigerbar database med hjelpetekster Bør kunne varsle godkjennere på f. eks. epost når saker blir sendt til godkjenning o Og omvendt. At godkjennere kan varsle saksbehandlere når saker er godkjent Bør være mulig å markere saker som lest

39 Vedlegg 2: Use case-modeller Dette dokumentet inneholder et utvalg use case-beskrivelser for prototypene vi har utviklet. Disse use casene er ment som retningslinjer for funksjonaliteten i prototypene. Modellene består av et felles diagram, med syv tilhørende beskrivelser. Use case-diagram

40 Use case-beskrivelser Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Opprette saksmappe Saksbehandler Saksbehandler trenger å opprette en ny saksmappe 1. Saksbehandler er innlogget i systemet. 2. Det finnes en arkivdel som saksmappen kan opprettes under. Saksmappe opprettet. 1. Systemet spør hvilken arkivdel saksbehandler skal bruke. 2. Saksbehandler velger arkivdel. 3. Systemet viser funksjoner som ligger under arkivdel. 4. Saksbehandler velger å opprette saksmappe. 5. Systemet spør om nødvendig informasjon. 6. Saksbehandler skriver inn informasjon om mappen og trykker OK. 7. Systemet oppretter saksmappen og gir tilbakemelding til saksbehandler. 6a. Saksbehandler har ikke skrevet inn nødvendig informasjon. 6a1. Systemet viser feilmelding og går ikke videre før all nødvendig informasjon er skrevet inn. Saksmappe er en spesifikk sak, som kan ha mange registreringer under seg.

41 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Opprette registrering Saksbehandler Saksbehandler har opprettet en sak og trenger registreringer under denne. 1. Saksbehandler er innlogget i systemet. 2. Saksbehandler må ha informasjonen som trengs for å opprette registreringen. Registrering er opprettet. 1. Systemet spør hvilken saksmappe saksbehandler skal bruke. 2. Saksbehandler velger saksmappe. 3. Systemet viser saksmappe og funksjoner. 4. Saksbehandler velger å opprette registrering. 5. Systemet spør om informasjon om registreringen. 6. Saksbehandler skriver inn all nødvendig informasjon og trykker OK/Lagre. 7. Systemet oppretter registrering og gir tilbakemelding til saksbehandler. 6a. Saksbehandler har ikke skrevet inn all nødvendig informasjon. 6a1. Systemet gir feilmelding og går ikke videre før saksbehandler har skrevet inn alt. Registrering kan være forskjellige filtyper, eller kun en notis opprettet av saksbehandler.

42 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Åpne saksmappe Saksbehandler Saksbehandler vil åpne og se på en saksmappe 1. Saksbehandler er innlogget i systemet. 2. Saksmappen må eksistere Saksbehandler har funnet den informasjonen han/hun var ute etter 1. Saksbehandler trykker på Saksmapper på startsiden. 2. Systemet lister opp alle saksmapper som er tilgjenglig. 3. Saksbehandler trykker på ønsket saksmappe. 4. Systemet viser informasjon og innhold i valgt saksmappe Ønsket saksmappe er ikke tilgjengelig for saksbehandler (rettigheter) 3.1. Saksmappen eksisterer ikke Relatert informasjon Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Importere e-post Saksbehandler Saksbehandler trenger å importere en e-post 1. Saksbehandler er innlogget i systemet. 2. E-posten(e) må være tilgjengelig for saksbehandleren E-posten(e) er importert til applikasjonen 1. Saksbehandler trykker på Importér e-post 2. Systemet viser saksbehandlers e-post-innboks 3. Saksbehandler huker av hvilke e-poster som skal importeres og hvilken saksmappe disse skal ligge i, hvilken filtype, samt fyller inn annen informasjon og trykker OK. 4. Systemet importer og lagrer e-post iht. overnevnte felter Saksbehandler har ikke fått tilsendt gjeldende e-post(er) 3.1. Korrekt saksmappe finnes ikke. 3.1a. Saksbehandler kan velge å opprette ny saksmappe. Relatert informasjon

43 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Godkjenne sak Leder Leder har fått en forespørsel om å godkjenne en sak. 1. Saksbehandler er innlogget i systemet. 2. Saken er sendt fra saksbehandler til leder. Saken er godkjent eller ikke godkjent. 1. Systemet viser saker til godkjenning på leders skjerm. 2. Leder velger sak som skal godkjennes. 3. Systemet viser informasjon om sak og alle registreringer. 4. Leder trykker på valget for å godkjenne. 5. Systemet oppdaterer saken til status Godkjent, gir leder tilbakemelding, og sender saken til arkivering. 4a. Leder godkjenner ikke saken. 4a1. Systemet oppdaterer status på saken og sender tilbake til saksbehandler. Leder får mulighet til å godkjenne saker etter at saksbehandlere har opprettet alle nødvendige registreringer. Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Tildele sak Leder Leder har fått inn mange saker til tildeling. 1. Leder må være innlogget. 2. Sakene må ligge klare til fordeling. Saken er gitt til saksbehandler. 1. Systemet viser nye saker i en oversikt. 2. Leder velger sak. 3. Systemet viser saken og saksbehandlere på skjermen til leder. 4. Leder velger saksbehandler saken skal tildeles til. 5. Systemet tildeler sak og gir tilbakemelding til leder. 1a. Ingen nye saker. 1a1. Systemet gir leder beskjed om at det ikke finnes noen nye saker. Leder har flere saksbehandlere i oversikten som kan tildeles saker.

44 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Opprette arkiv Arkivar Systemet har bruk for nytt arkiv. 1. Arkivar må være innlogget i systemet Nytt arkiv er opprettet 1. Arkivar trykker på Opprett arkiv 2. Systemet lister opp felter og valg som må fylles inn (metadata) 3. Arkivar fyller inn informasjon og trykker Lagre/Opprett. 4. Arkivet blir opprettet i systemet Systemet viser feilmelding for at noe er tastet inn feil. Relatert informasjon

45 Produktrapport Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31

46 Forord Produktrapporten beskriver produktet gruppen har utviklet gjennom prosjektperioden. Rapporten inneholder detaljert informasjon, forklaringer og kodeeksempler. Rapporten er opprettet for sensor, oppdragsgiver og veileder for gruppen, og andre interesserte. 2

47 Innholdsfortegnelse Forord... 2 Innholdsfortegnelse Innledning Gruppen Valg av oppgave Oppdragsgiver Bakgrunn for prosjektet Eksisterende løsning Mål for prosjektet Windows 8 og Metro Introduksjon til Windows Metros designprinsipper Fokus på innhold Den digitale verdenen Bevegelse Typografi Enheter Verktøy og koding Skeuomorphic Skeuomorphics designprinsipper Den analoge verdenen Fokus på estetikk Forskjeller fra Metro Bruksområder skeuomorphic Beskrivelse av prototypene Generell beskrivelse Skeuomorphic-prototype Design Funksjonalitet Navigasjon og struktur Metro-prototype Design Funksjonalitet

48 4.3.4 Navigasjon og struktur Arkivsystem Struktur i kildekoden Innlogging via 3. part Lagring i globale variabler Klasser Roaming Bruk av kommentarer Datagrunnlag Hva er en SOAP? Sikkerhet og brukere Om sikkerhet på mobile enheter Sikkerhet i Windows-applikasjonen Brukere Feilsøking Feilmeldinger under kjøring Breakpoints Automatisk fullføring Tilbakemeldinger Videreutvikling Roller Funksjonalitet Datatrafikk og respons Design Kilder og referanser Vedlegg

49 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. 5

50 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. 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 6

51 2 Windows 8 og Metro 2.1 Introduksjon til Windows 8 Windows 8 er et operativsystem utviklet av Microsoft. Operativsystemet er utviklet både til bruk på nettbrett, smart-telefoner (Windows Phone 8), hybrid-maskiner (datamaskiner med touch-skjerm) og vanlige datamaskiner med tastatur og mus. Dette operativsystemet gir en helt ny brukeropplevelse, og fungerer mer flytende enn tidligere versjoner. Brukergrensesnittet er utviklet slik at operativsystemet er enkelt å bruke på alle enheter. 2.2 Metros designprinsipper Fokus på innhold Metro er et kodenavn brukt av Microsoft til å beskrive deres typografibaserte designspråk, som opprinnelig ble laget for Windows Phone-plattformen. Metro er basert på designprinsipper fra International Typographic Style («Swiss style»), og hovedprinsippet med Metro har fokus på innholdet/informasjonen i applikasjoner, og mindre fokus på grafiske elementer («Content before chrome»). Figur 2.1 og 2.2: Windows Phone 8 startskjerm. Hentet fra 7

52 Tidlige utgaver av designet kom med Windows Media Center for Windows XP Media Center Edition, som i hovedsak brukte tekst for å navigere seg rundt. Dette prinsippet gikk igjen i senere utgaver av Media Center og Zune. Microsofts designere redesignet grensesnittet, med hovedvekt på ren typografi og mindre pynt, og det ble etter hvert videreutviklet til Windows Phone og Windows 8. Levende fliser ( live tiles ) ble introdusert til Metro i utviklingsfasen for Windows Phone, og har senere blitt integrert i designet for andre produkter, som Live Messenger, Live Mesh og Windows 8. Microsofts design-team hevder at designet er delvis inspirert av skilter som finnes ved offentlige transportsystemer (f.eks. King County Metro Transit system i Seattle). Designet vektlegger som nevnt god typografi og har stor tekst som er lett å se. Designet er i følge Microsoft «elegant, raskt og moderne» og en oppgradering fra det ikonbaserte grensesnittet fra Android, ios og tidligere Windows-versjoner. Fontene som blir brukt i de fleste tilfellene, er basert på Segoe fontfamilien, men Zune og Windows Phone benytter henholdsvis «Zegoe UI» og «Segoe WP». Forskjellene er kun små detaljer, med unntak av tall-tegnene som ser noe annerledes ut. Den nye Windows 8 startskjermen bruker levende, fargede «live tiles» som kan «scrolles» til siden, i likhet med Windows Phone og Xbox 360 Dashboard. Rammeverket ble designet for å få vanlige oppgaver til å gå raskere. Det blir gjort ved å fjerne overflødig grafikk, og i stedet brukes det faktiske innholdet til et brukergrensesnitt. 8

53 Figur 2.3: Windows 8 startskjerm. Skjermbilde av Tobias Tambs Knappene (flisene) er oftest store og kan «scrolles» sidelengs. Animasjoner spiller også en stor rolle, med overganger og interaksjons-feedback. Et eksempel er at når en scroller til siden, vil flisene flytte seg til siden akkurat som en forventer. Når en trykker på noe eller scroller, vil naturlige animasjoner vise hva som skjer, for å gi bekreftelse på at det som skulle gjøres, har blitt utført. Dette skal gjøre at grensesnittet virker «levende» og er responsivt Den digitale verdenen I Metros retningslinjer for design står det at innhold skal være i fokus. Dette gjør at innholdet selv blir brukt mer enn grafiske elementer til å utgjøre grensesnittet. Ved å ha hovedfokus på innholdet, og ikke grafiske elementer som ser ut som virkelige elementer fra den analoge verdenen, vil applikasjonene fremstille innholdet på en mer «digital» måte Bevegelse Metro-versjoner av Windows bruker animasjoner og bevegelser i større grad enn i tidligere Windows-versjoner. Applikasjoner åpnes for eksempel ved at ikonet eller flisen blåses opp til den dekker skjermen. Metro-versjonene av Windows gir brukeren mulighet til å tilpasse visningen av applikasjonene. Det vil si at brukeren kan dra i toppen av hver applikasjon og velge enten fullskjerm eller liten visning. For å lukke en applikasjon drar brukeren i toppen av applikasjonen og beveger applikasjonen helt ned til bunn av skjermbildet Typografi I tidligere avsnitt har vi bemerket at Metro bruker selve datainnholdet i stor grad til utvikling av grensesnittet. Metro visualiserer tekst (innhold) på en lesbar måte, som betyr at det ikke 9

54 brukes skillelinjer eller grafiske elementer for å vise hierarkiet i applikasjonen. En kan tydelig se hierarkiet i en Metro-applikasjon fordi overskrifter, notater og normal skrift er forskjellig fra hverandre. En overskrift har større skriftstørrelse enn paragrafer, og viser dermed at overskriften er på toppen av hierarkiet. 2.3 Enheter Windows 8 kommer, som tidligere nevnt, til flere enheter. I skrivende stund har det kun blitt lansert to nettbrett med Windows 8; Surface RT og Surface Pro, som kjører henholdsvis Windows 8 RT (bygget for ARM-arkitekturer) og Windows 8 Professional (bygget for x86- og x64-arkitekturer). Når det gjelder hybrid-maskiner, stasjonære maskiner og bærbare maskiner (laptoper), finnes det et hav av disse på markedet som leveres med Windows 8. Det blir også fortløpende lansert flere smart-telefoner fra ulike leverandører som kjører Windows Phone Verktøy og koding Metro-baserte applikasjoner kan lages i blant annet Microsoft Visual Studio, med C# som hovedspråk, mens brukergrensesnittene stilsettes i XAML-strukturspråk. 10

55 3 Skeuomorphic 3.1 Skeuomorphics designprinsipper Den analoge verdenen Ordet skeuomorphic kommer fra de greske ordene «Skeuos», som betyr «beholder» eller «verktøy», og «morphé» som betyr «form». Oxford Dictionary s forklaring på ordet lyder slik noun: an object or feature which imitates the design of a similar artefact in another material. Innenfor IT beskrives dette som et designprinsipp som prøver å imitere det originale utseende fra den virkelige (analoge) verdenen i digitale løsninger. Designprinsippet brukes innen flere områder enn IT: Elektriske artikler kan formes som gamle forgjengere, som f. eks. en vannkoker som ser ut som en kaffekjele. Figur 3.1: Skeuomorphic tallskive. Hentet fra 011/07/retro-rotary-new-oldtechnology.html Med et klassisk eksempel blir det enda enklere å forklare: En notatblokk er noe de fleste kjenner igjen. Åpner du den innebygde notat-applikasjonen på en Apple iphone skjønner en fort hva som menes med Skeuomorphic design. Grensesnittet imiterer en standard notatblokk du finner i den virkelige verden, og som du kan kjøpe på en hvilken som helst bokhandel. Du har en vertikal marg og horisontale linjer. Trykk hvor som helst på blokka, og du kan begynne å skrive. Et annet godt eksempel er Kobos bok-applikasjon til Android og Apple ios. Åpner du applikasjonen, ser du en «bokhylle» med bøkene du tidligere har kjøpt, og holder på å lese. Velger du en bok fra hylla, åpnes boka, og du kan faktisk bla fram og tilbake i boka ved å dra sidene fra høyre til venstre eller omvendt. Figur 3.2: Skeuomorphic bokhylle (Kobo). Hentet fra id/app/best-ebook-reader-appsfor-android-phones/3570/ Poenget med skeuomorphic er altså ganske åpenbart: Design den digitale verdenen slik at brukere rask kjenner seg igjen og finner fram. De aller fleste har bladd i en bok før. Leser du en bok i Kobo, gjør du akkurat det samme som når du leser en virkelig bok. Du kan til og med merke tekst med en merketusj og lage «eselører» slik at du lett finner fram igjen til enkelte ord og sider. 11

56 Dette betyr at mange brukere slipper å lære seg nye systemer og andre måter for å samhandle med datateknologi. De kan isteden i høy grad benytte seg av kunnskap de allerede besitter. En kan si det er en mer naturlig måte å bruke programvare på. Etter hvert har skeuomorphic design-prinsippet fått et godt fotfeste spesielt i applikasjonsutvikling og har på mange måter blitt en standard for nye applikasjoner. Dette på både godt og vondt. Det kan se ut som flere og flere utviklere bruker mer tid på at designet skal se og føles «ekte» ut, enn de bruker på selve innholdet som jo faktisk er det viktigste. Får vi en overdreven bruk av elementer stjålet fra den virkelige verden, kan det være med på å skyve fokuset bort fra innholdet. Leser du en e-bok i bok-applikasjonen til Apple ipad, presenteres så mye ekstra-informasjon at det kan bli vanskelig å oppfatte det du leser. Tilleggsfunksjoner er ofte sentralt, og skeuomorphic-applikasjoner dytter på deg valg og informasjon du ikke nødvendigvis trenger. Et godt eksempel på et skeuomorphic-design som fungerer er Amazons e-bokleser Kindle. Med Kindle har Amazon fått med nok av det fundamentale bok-designet til at enheten virker tiltalende for personer som er vant til å lese vanlige bøker. Det som er viktig å legge merke til her, er at Amazon ikke har overdrevet designet. Selv med et skeuomorphic design, står innholdet i fokus, noe som gjør bøker lette å lese, uten for mye pynt og eye-candy. Figur 3.3: Amazon Kindle. Hentet fra Figur 3.4: Apple ibooks. Hentet fra 12

57 Et annet motargument mot skeuomorphic design er at dette prinsippet kan være med på å bremse utviklingen av nye mer intuitive designprinsipper. Med skeuomorphic design har utviklere en enkel løsning som tilsynelatende fungerer bra og som er populært blant brukere. Da slipper man å bruke tid og energi på å prøve å skape noe nytt og potensielt bedre. Også viktig for forbrukere i dag er ytelse. Hardwareprodusenter utvikler hele tiden raskere og bedre maskinvare til blant annet mobiltelefoner og datamaskiner. Når du bruker en PC med Windows 7 i dag, føles den noe raskere enn en ti år gammel PC med Windows XP eller en 15 år gammel PC med Windows 95? På mange måter ikke. Det er i stor grad fordi brukergrensesnitt og programvare er designet på en slik måte at datamaskinen må jobbe mye mer enn før, bare for at ting skal flyte og samhandle. Gjennomsiktige vinduer og animasjoner her og der ser kanskje pent ut, men det går hardt utover ytelsen Fokus på estetikk Utseende har en større betydning i skeuomorphic enn i andre designprinsipper. Det er viktig at ting ser bra ut, samtidig som er lett å forstå hva ikonene representerer. «Pynt» og estetiske elementer er også en viktig del: For eksempel kan man ha en animasjon som viser at et dokument blir lagt i en konvolutt, og deretter lagt i en postkasse ved sending av e-post. Dette hjelper til med å vise hva som faktisk skjer (e-post blir sendt). Et ankepunkt er at dette er ressurskrevende og tar tid, noe som kan virke overflødig for noen. 3.2 Forskjeller fra Metro Skeuomorphic skiller seg fra Metro på mange områder. Som nevnt så er det estetikken og designet som er i fokus på skeuomorphic, mens med Metro-design står informasjonen i fokus. Videre skiller det seg fra Metro ved at det ikke er noe standardisert designspråk, men en relativt bred kategori. Blant annet Android- og ios-design (og applikasjoner til disse) faller innenfor skeuomorphic-kategorien, men designene skiller seg likevel fra hverandre. Metro derimot er Metro uansett hvor det brukes (PC, nettbrett, forskjellige applikasjoner). 3.3 Bruksområder skeuomorphic Applikasjoner der skeuomorphics designprinsipper fungerer er det flere av. Kalendere, notiser, kalkulatorer er noen få eksempler der et skeuomorphic designprinsipp kan komme godt med. Det å gi brukeren assosiasjoner til eksisterende fysiske produkter gjør læringskurven veldig liten. Apple har lenge brukt et skeuomorphic-design i sine produkter. Apple hevder at produktene deres er enklere å bruke hvis man trekker paralleller til den virkelige verden. Da slipper en til en viss grad å lære seg et nytt system. ios hovedkonkurrent Androids designspråk faller også innenfor skeuomorphic-kategorien, men i en litt mer «begrenset» utgave. 13

58 Figur 4.16: Kalkulator - iphone til venstre, vanlig kalkulator til høyre. Hentet fra: 14

59 4 Beskrivelse av prototypene I dette avsnittet vil vi gi en generell beskrivelse av prototypene vi skal utvikle. 4.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. 4.2 Skeuomorphic-prototype Skeuormorphic-prototypen skal ha design i fokus, og ha inspirasjon fra den analoge verdenen. 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 skeuomorphic-designprinsipper. 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 Design Tidligere i rapporten ga vi en innføring i hvordan skeuomorphics designprinsipper fungerer. Vi fulgte prinsippene ganske godt når vi utviklet prototypen. I begynnelsen skisserte vi mye, men så fort vi gikk over til Axure trengte vi ikoner og elementer som var tatt fra den analoge verdenen. Til dette formålet lastet vi ned en ikonpakke, som ble brukt gjennom hele prototypen. Denne ikonpakken har for eksempel et hus-ikon som tilsvarer «Hjem»-knappen Funksjonalitet Skeuomorphic-prototypen ble kun utviklet i Axure, som generer prototypen i HTML og CSS noe som vil si at prototypen ikke er koblet opp mot et bakenforliggende system. Dette betyr at prototypen ikke kan brukes som arkivsystem, men den er god nok til å vise et brukergrensesnitt utviklet med skeuomorphics designprinsipper Navigasjon og struktur Navigasjonen på prototypen er i hovedsak basert på ikoner som menyvalg. På toppen av sidene er det en menylinje som går igjen på alle undersider. Denne linjen inneholder linker til de viktigste sidene: «Hjem», «Søk» og «Logg ut», i tillegg til en tilbakeknapp og overskriften (header) for den siden du er på. 15

60 På «Hjem»-siden finnes det linker (knapper) for alle de funksjonene som kan utføres av rollen man er innlogget som. Dermed vil «Hjem» inneholde alt man trenger, og det meste går via denne siden. Figur 4.1: Startskjerm, saksbehandler. Hentet fra skeuomorphic prototype 4.3 Metro-prototype Metro-prototypen skal lages etter Microsofts Metro-designprinsipper. Det betyr at informasjon er hovedfokuset i brukergrensesnittet. Metro-prototypen/-applikasjonen skal utvikles i Microsoft Visual Studio og Microsoft Blend. Visual Studio fungerer både som koding- og designverktøy og Blend gir et dypere utvalg av designalternativer. 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. Valget av utviklerspråk og verktøy har vært et resultat av diskusjon med arbeidsgiver og innad i gruppen. Ved førsteutkast av applikasjonen ble det brukt et Javascript/HTMLutgangspunkt da gruppen hadde eksklusivt kunnskap om web-programmering, og følte det ville gi oss mest frihet. Det viste seg derimot i ettertid at Javascript ikke egner seg godt til 16

61 bruk av webservices/soap som var det eneste kjernen tilbød oss. Ved videre diskusjon med arbeidsgiver så valgte gruppen å gå over til et C#- og XAML-utviklermiljø for å få enklere tilgang til kjernen og et læringspotensial i nye teknologier gruppen aldri hadde vært borti. Den fullførte prototypen er dermed eksklusivt i C#/XAML, kodet i Visual Studio og designet i Visual Studio og Microsoft Blend med minimalt med veiledning fra arbeidsgiver, da arbeidsgiver og veileder ikke selv har brukt dette utviklingsmiljøet Design Gruppa har tatt flere valg med tanke på designutviklingen. Fargevalget falt på svart/hvit/grått da dette er en del av Windows 8 sitt «light theme» og gir støtte for høykontrast. Dette fungerer veldig bra med tanke på fremstilling av overskrifter og tekstlig innhold. Gode kontraster (svart/hvitt) gjør at brukeren enklere kan lese teksten som fremstilles i applikasjonen uten anstrengelse. Vi prøvde først et «dark theme» i applikasjonen, men intern og ekstern respons tilsa at det var vanskeligere å lese teksten tross et mer elegant utseende. Størrelse på overskrifter, tekst, knapper og andre elementer ble justert gjentatte ganger underveis i prosjektet for å tilpasse både skrivebordet til datamaskiner og nettbrett. Ettersom vi senere fikk tilgang på et Windows-nettbrett ble applikasjonen testet i Windows 8 for nettbrett (Win RT), og dermed var det enklere å vurdere om skrift- og elementstørrelse var korrekt. Stor og tydelig skrift gjør brukeropplevelsen bedre, spesielt når tekst skal fremstilles på mindre skjermer (nettbrett og bærbart skrivebord). Elementer i prototypen er satt i relative «grids» og «lists». Størrelsen på disse ble også justert gjentatte ganger underveis. «Grids» og «lists» blir i prototypen brukt til fremvisning av saksmapper og registreringer, samt andre sammenhengende elementer. Ved bruk av disse kan en opprette én enkelt animasjon for flere elementer samtidig, og skape et brukergrensesnitt som er mer sammensatt (alle saksmapper dukker opp samtidig f. eks.). Designet har fokus på minimalistisk design, minst mulig navigering og tekstmanipulering slik at brukeropplevelsen er behagelig selv på enheter uten musepeker og tastatur. For å opprettholde dette minimalistiske designet har vi valgt å bruke Windows sin pagenavigation og endre på denne ved behov. For eksempel: I stedet for å lede brukeren til en side for redigering og så videre tilbake til originalsiden den kom fra (Hovedside->Saksmappe-> redigering->saksmappe igjen), så manipulerer vi pagenavigation til å sende brukeren et steg tilbake og ikke videre til ny side etter fullført handling. På den måten gjør vi at tilbakeknappen alltid går opp til nivået høyere i applikasjonen (se eksempelet under over tilbeknappens flowchart). 17

62 Figur 4.1: Flowchart over tilbakeknapp. Selv om en befinner seg i Saksmappe og kommer fra Lag ny/endre registrering, så skal du alltid tilbake til forsiden når du trykker tilbake. Dette virker åpenbart og logisk for mange, men er noe som Windows 8 fraråder, da tilbakeknappen ifølge prinsippene skal lede deg til forrige side en var på, uansett. Vi tok da et valg ut ifra intern testing om å reservere tilbakeknappen til eksklusivt å navigere til forrige nivå og ikke forrige side i applikasjonen. Selv om dette bryter med Windows 8 sine designprinsipper på papiret, så er det viktig å huske på at disse er retningslinjer en bør følge, så lenge det ikke skaper forvirring eller andre ugunstige situasjoner Funksjonalitet Vi har hatt et fokus på saksbehandlerrollen under utviklingen av applikasjonen. Dette ble gjort fordi saksbehandlerne bruker dagens løsning mest av de eksisterende rollene. Vi konkluderte også med at saksbehandlerrollen alene kunne vise Metros designprinsipper. Saksbehandler-delen kunne også gi en pekepinn på hvordan Metros designprinsipper ville fungert ved utvikling av et fullt fungerende arkivsystem i fremtiden. Saksbehandlerrollen i prototypen inneholder funksjonalitet til å opprette og redigere saksmappe/registrerings-metadata. Når en saksmappe er opprettet vil den bli vist i hovedvinduet alene, deretter kan en velge å navigere inn i den nylig opprettede mappen eller lage flere. Det er et valg vi har tatt for tydelig å vise at mappen er opprettet og la brukeren selv velge hva dem gjør videre. 18

63 Figur 4.2: Saksbehandler Lag ny/endre saksmappe, opprettelse av ny saksmappe «Søknad om ferie» Figur 4.3: Saksbehandler Forside, viser nyopprettet sak fra figur 4.2 Inne i saksmappen kan en finne relevante registreringer som er knyttet til mappen. I samme vindu finner vi mulighet for å opprette nye registreringer/endre registreringer og legge saksmappen til favoritter. Opprettelse av registreringer har også muligheten til å laste opp dokumenter direkte, uten at applikasjonen trenger mer input fra brukeren enn valg av filer. Valget av filer instansierer en 19

64 Windows Filepicker (se under), som gjør det mulig for brukeren å finne og hente filer direkte fra applikasjonen. Figur 4.4: Filepicker er åpnet i mappen Notes, filer til opplasting kan velges. Figur 4.5: Filepicker er åpnet i Photos-applikasjonen, filer til opplasting kan velges. En ser også at andre applikasjoner med delt lagring kan velges via menyen. 20

65 Filepicker-funksjonen gjør det også mulig å hente dokumenter og filer fra andre Windows Store-applikasjoner som har delt lagring. Det vil si at en kan hente dokumenter fra bilderedigeringsapplikasjoner, kamera, SkyDrive og lignende. Kamera gir for eksempel muligheten til å ta bilde direkte, og importere det til applikasjonen med få tastetrykk. Figur 4.6: Saksbehandler Saksmappe åpnet, dokument i registrering er åpnet. Det er ikke original støtte for visning av tekstdokumenter i Windows 8 sine Windows Storeapplikasjoner og utviklingen av bare denne komponenten alene ville vært langt utenfor vårt prosjekt. Det finnes derimot tredjeparts bibliotek som støtter dette (SyncFusion). Ved å lagre nedlastede dokumenter i applikasjonens temp-mappe så har vi muligheten til å vise dokumentet direkte i applikasjonen uten å gå via et tredjepartsprogram som Word. Ut ifra denne visningen kan brukeren også skrive ut dokumentet direkte. Dette er ikke noe som ble forventet av oss eller som var et av systemkravene, men vi følte at det er en naturlig handling som bør være implementert i applikasjonen. Brukeren kan i et tenkt handlingsforløp, få en tildelt sak med dokumenter, lese disse dokumentene i applikasjonen og skrive dem ut om nødvendig, uten å forlate applikasjonen. Som nevnt så er dette ikke noe som er støttet i Windows Store-applikasjoner og redigering av tekstdokumentene er ikke støttet grunnet begrensninger i biblioteket. Vi har hatt muligheten til å bruke SyncFusionbiblioteket på prøvelisens, og videre utvikling av applikasjonen krever lisens om denne funksjonen ønskes. 21

66 Vi har også utviklet et søkefelt i grensesnittet, der saksbehandler har mulighet til å søke på saksmappetittel, saksmappeidentifikasjon, saksoppretter eller saksmappeeier. Søkefeltet gir brukeren mulighet til å velge hvor mange resultater som skal vises i skjermbildet, og om søkefeltet skal vises i skjermbildet eller ikke. Standard er at søkefeltet er skjult. Etter intervjurunden vi hadde tidlig i prosjektperioden, fikk vi inntrykk av at en «favorittfunksjon» var ønsket av saksbehandlerne. Vi utviklet dermed en favorittfunksjon der hver Figur 4.7: Søkefelt enkelt saksbehandler har mulighet til å legge til, fjerne og vise favorittsaksmapper. Hvis brukeren har laget seg en favorittliste, vil denne listen kunne vises på et senere tidspunkt, på hvilken som helst enhet. Dette virker fordi vi utviklet en tilleggsfunksjon som kobler favorittene sammen med brukernavnet og Microsoft ID. Hovedoppgaven til lederrollen i arkivsystemet er å tildele saker til saksbehandlerne. Disse tildelte sakene fra lederen måtte vi også tenke på når vi utviklet applikasjonen og funksjonene til saksbehandleren. Hvis det er første gang saksbehandleren møter hovedbildet så vil disse tildelte sakene hentes inn, senere så vil hovedbildet være okkupert av de sakene som er relevante å vise etter hva saksbehandleren gjør. For å få tilbake de tildelte sakene så kan brukeren velge disse i søkevinduet. Totalt sett vil det si at saksbehandlerne har tre muligheter i søkevinduet; søke etter saksmapper, søke opp favoritter og vise tildelte saker. 22

67 4.3.4 Navigasjon og struktur Figur 4.8: Flowchart over gjeldende navigasjon Som nevnt tidligere har vi hatt fokus på minimalistisk design og har dermed valgt å gå for et begrenset antall skjermbilder og relativt få navigeringsmuligheter. Vi starter med en loginside der brukeren velger sin rolle. Vi har bevisst valgt at brukeren bare kan logge inn med en rolle om gangen, slik at brukeren aldri er i tvil om hvilke rettigheter som er tilgjengelige. Ved innlogging vil brukeren få forsiden til sin rolle som er skreddersydd rollen. Gjennom de neste avsnittene beskriver vi navigasjonen og viser i bilder et tenkt handlingsforløp for saksbehandleren. 23

68 Figur 4.9 og 4.10: Til venstre, forside med login til applikasjonen, valg av roller er vist. Til høyre, hovedbilde, innlogget som saksbehandler. Forsidene til hver rolle skal ha hvert sitt unike design. Saksbehandlerrollen, som vi har ferdigstilt, har en skreddersydd oversikt over saksmapper. Ved førstegangsinnlogging vil forsiden vise nylige tildelte saker, senere vil dette bildet vise saksmapper brukeren enten har søkt opp eller hentet via favoritter. Herifra kan saksbehandleren enten velge å opprette nye saksmapper, søke i saker eller velge en saksmappe. Opprettelse av saksmappe navigerer brukeren til hovedskjermen med saksmappen i fokus som bekreftelse at mappen ble laget. Figur 4.2 og 4.3: Saksbehandler Opprettelse av saksmappe navigerer brukeren til hovedskjermen med saksmappen i fokus som bekreftelse at mappen ble laget. Inne i saksmappen vises relevant informasjon om saken og registreringene knyttet til den. Ved en nylig opprettet sak, har brukeren noen få valg som vist på bildet under. 24

69 Figur 4.11: Saksbehandler Tom saksmappe fra 4.2 er åpnet. Hvis brukeren velger å opprette en ny registrering, får brukeren opp skjermbildet vist i figur Her listes også opp tidligere registreringer i listen til høyre, slik at disse kan endres om ønskelig. Figur 4.12: Saksbehandler Opprettelse av ny registrering «Søknad om ferie.docx» Brukeren kan laste opp filer om ønskelig, ved å trykke på last opp fil. Da vises Filepicker illustrert med figur 4.4 og

70 Figur 4.13: Saksbehandler Saksmappe «Søknad om ferie» og den nye registreringen er valgt. Duplikatregistrering grunnet testing. Ved opprettelse av ny registrering, så vil brukeren havne i saksmappen med den nye registreringen i listen, som vist ovenfor i Figur 4.14: Saksbehandler Dokument i registrering åpnet. Brukeren kan forhåndsvise dokumenter i en registrering. Dette gjør at dokumentet vises i samme skjermbilde som saksmappen. 26

71 Figur 4.15: Saksbehandler Appbar er åpnet. Brukeren kan til slutt velge å skrive ut dokumentet via skriv ut-funksjonen kalt «Print», navigere tilbake og ut av saksmappen eller logge ut via appbaren (Windows RT: Dra fingeren utenfor skjermen og inn, enten på topp eller bunn). Windows 8: Høyreklikk hvor som helst på skjermen Arkivsystem Etter en lang prosjekttid har vi fått brukt begge designprinsippene til å utvikle to prototyper. Dette har gitt oss en formening om hvordan designprinsippene fungerer når en skal utvikle et arkivsystem. I et arkivsystem er det meget viktig at innholdet fremvises på en god og oversiktlig måte. Det vil si at Metro-prinsippene egner seg godt til bruk i et arkivsystem, der innholdet/informasjonen er hovedfokuset. Etter å ha forsket litt på skeumorphic, og utviklet en prototype basert på dette prinsippet, så vi at dette ville være passe dårlig i et arkivsystem, sammenliknet med Metro. 27

72 5 Struktur i kildekoden Dette avsnittet av rapporten vil gi en grundig gjennomgang av kildekoden til Metroapplikasjonen, hvordan denne er bygd opp, og hva vi har tatt hensyn til underveis i utviklingsprosessen. 5.1 Innlogging via 3. part Kjernen vi jobber mot har ingen autentisering via brukernavn og passord. Kjernen deler ut sikkerhetsnøkler til alle som har en godkjent rolle per dags dato. Det vil si at ingen passord eller spesifikt brukernavn kreves. Etter diskusjon med arbeidsgiver ble det klart at en annen gruppe sto for utviklingen av en autentiseringsmekanisme, men de hadde på det punktet ikke kommet i gang med denne. Det ble videre klart at kjernen skal ha støtte for innlogging via flere forskjellige 3.parter slik som Min ID og lignende. For å simulere dette har vi i samarbeid med oppdragsgiver satt opp en 3.parts påloggingssjekk på via en webserver på HiOA. Det vil si at applikasjonen tar kontakt med denne påloggingsserveren og sjekker brukernavn og passord og gir respons tilbake til applikasjonen. Vi håndterer denne responsen og henter en sikkerhetsnøkkel fra kjernen og logger brukeren inn ved suksess. Figur 5.1: Funksjon for sjekk av pålogging og innhenting av sikkerhetsnøkkel. 5.1 Lagring i globale variabler Vi har valgt å bruke globale variabler flere steder i kildekoden. Det gir mulighet for å lagre data som brukes flere ganger på et enkelt sted. Vi unngår for mye bruk av datatrafikk og ventetid på kjernekall ved å innhente informasjon fra globale variabler, i motsetning til å kontakte kjernen hver gang. 28

73 Tilstandshåndtering av applikasjonen bruker også globale variabler, slik at tilstanden lett kan gjenopptas uten at brukeren merker forandring. Dette er svært viktig når kjernen vi kobler oss opp mot er tilstandsløs. Hvis koden henter inn en saksmappe så må vi bruke denne saksmappen senere for å kunne hente inn registreringer, deretter senere å kunne hente dokumentbeskrivelser, og så dokumentobjekter, og til slutt dokumenter. Kjernen husker ingenting og vi må lagre dette etterhvert som brukeren navigerer lengre inn applikasjonen og kjernen. Ved innlogging så lagres brukeridentifikasjonen direkte i en global variabel. Dette er først tenkt å vise personifisert innhold til brukeren, men senere funnet nyttig til automatisering av koden. Først brukes denne variabelen til å hente en sikkerhetsnøkkel, noe som kreves hver gang koden skal ta kontakt med kjernen. Senere brukes denne sammen med andre variabler til å automatisere opprettelse av saksmapper og lignende (innhenting av favoritter, createdby-felter er noen eksempler). Det brukes globale variabler når informasjon innhentes fra serveren for å lagre data til senere gjenbruk. Når koden henter brukerens favoritter så lagres dette både til en global favoritt som brukes senere ved redigering, og i globalvariabel.casedata som bindes til visningen av saksmapper. Ved å gjøre dette kan vi navigere bort fra saksmappe-visningen på startsiden og hente tilbake saksmappene når brukeren kommer tilbake, uten å kontakte kjernen igjen. Vi bruker til slutt noen globale variabler for tilstandshåndtering av elementer etterhvert som brukeren samhandler med applikasjonen, slik som synlighetshåndtering og lignende. 5.2 Klasser Vi bruker svært få klasser i applikasjonen, dette er fordi mye av dataene vi manipulerer kommer utenfra og er relative. Vi bruker likevel noen enkle klasser for å ha tilgang til funksjoner og variabler som vi brukere senere. Klassen GlobalVariabel er den største, og ble utvidet etter hvert som vi hadde behov for å lagre flere variabler. GlobalVariabel inneholder alle de globale variablene vi bruker i koden for å gi kjernen en illusjon om tilstand og brukere på nettverk med høy svartid, en god opplevelse. Gjentatte funksjoner har vi også lagret i klasser. Klassene Registry og CaseFile er statiske og kan kalles utenfra og blir dermed til globale funksjoner vi kan bruke flere ganger. 5.3 Roaming Vi hadde, som tidligere nevnt, en innledende intervjurunde med brukere av dagens løsning. Under disse intervjuene fikk vi inntrykk av at de fleste savnet muligheten til å opprette sin egen «favorittmappe» med selvvalgte saker. Dette var noe vi ville utvikle som en del av Metro-prototypen. 29

74 Figur 5.2: Eksempel på bruk av roamingsettings. Legge til og fjerne favoritter. Vi utviklet derfor noen funksjoner som gjorde at brukeren kunne legge til, vise og slette saker fra favorittmappen. I tillegg til dette ville vi at brukeren kunne se denne mappen hvor som helst, fra hvilken som helst enhet. Vi løste dette ved å bruke roaming. Det vil si at vi koblet favorittsakene til en roamingsetting roamingsettings lagres i Microsoft sin SkyDrive. Denne roamingsettingen er knyttet til applikasjonen og Microsoft-IDen til brukeren. Det vil si at hvis brukeren logger inn med samme Microsoft-ID på alle enheter, og logger i applikasjonen med samme brukernavn så vil favoritter lagres. Vi valgte å ha det slik for da kan en felles Microsoft-ID brukes uten at brukerne får hverandres favoritter. Dette av sikkerhetsårsaker, slik at det kan være flere brukere per enhet. Grunnen til at vi valgte å gjøre det via Microsoft sin roamingsetting er at det ikke finnes en funksjon som kan gjøre dette internt i kjernen. Dette er igjen fordi kjernen er tilstandsløs i skrivende stund uten at det er fremtidige planer om dette. Roamingsettings lagres i SkyDrive og internt på maskinen, og er dermed et sikkerhetshull, da det er systemider som lagres. Vi er klar over dette og har gjort vår oppdragsgiver oppmerksom på dette. 5.4 Bruk av kommentarer Programmerere har god nytte av kommentarer i kildekoden. Kommentarer forklarer for eksempel hva en funksjon gjør eller hva en variabel inneholder. Vi har, i vår kildekode (Metro-applikasjon), benyttet kommentarer der vi mente det var nødvendig med en forklaring til leseren av kildekoden. Dette hjelper ikke bare leseren å forstå kildekoden, men det hjelper oss med å huske hva de ulike funksjonene gjør, uten at vi trenger å lese gjennom hver funksjon. 30

75 Figur 5.3: Eksempel på kommentar, der det kan virke veldig kryptisk hva som skjer. Som eksempelet ovenfor viser så har vi også valgt å ha en «START»- og «END»-tag på starten og slutten av større/kryptiske kodesnutter. Dette gjør det enkelt å se hvor koden hører til og hva den gjør i en større sammenheng. I starten av prosjektet ble nesten alt av kode kommentert da vi hadde liten forståelse av teknologien og kommentarene ga oss mulighet til repetisjon og forståelse. Senere har vi fjernet mye av de overflødige kommentarene, men noe har fått ligge igjen. Vi har med kommentarene fokusert på å forklare hvorfor koden gjør det den gjør, i motsetning til å fokusere på hva den gjør. Dette som tvinger utvikleren til å ha et bedre perspektiv på hele kodebasen. 31

76 6 Datagrunnlag Dataene til applikasjonen hentes fra arkivkjernen, som ligger på en server hos HiOA. Via Visual Studio har vi lagt til en Service Reference på Dette er en såkalt webserviceadresse som gjør det mulig å prate med kjernen via XML. En webservice tar XML meldinger inn og gir XML meldinger ut. Webservices som vi har brukt og hva kjernen tilbyr er basert på SOAP. Ved å legge til denne som Service Reference generer Visual Studio en del hjelpefunksjoner for tilgang til kjernen. Det er en av hovedgrunnene til at vi valgte å gå med en C# løsning og ikke en JavaScript/HTML-løsning. Ved det sistnevnte var det behov for manuelt å konstruere XML/SOAP-meldinger og dekonstruere dem igjen for å hente data. 6.1 Hva er en SOAP? SOAP gir muligheten til å sende data via http og https i form av XML-meldinger. Applikasjonen vår prater med systemkjernen via SOAP. Under er et eksempel på SOAPmelding til og fra systemkjernen, tatt fra SOAP UI. Figur 6.1: SOAP-kall (casefilesearch(string securitytoken, String fieldname, String query, Integer offset, Integer limit)) 32

77 Figur 6.2: SOAP-respons (casefilesearch(string securitytoken, String fieldname, String query, Integer offset, Integer limit)) 33

78 7 Sikkerhet og brukere 7.1 Om sikkerhet på mobile enheter Sikkerhet er et stadig viktigere tema for utviklere av mobile enheter. Når vi snakker om mobile enheter omfatter det alle enheter som er koblet til mobilnettet (mobiltelefoner, nettbrett, lesebrett, mobilt bredbånd til bærbar datamaskin). Mobilnettet i Norge benytter ulike krypteringer for all trafikk. Mobiltrafikk er både tekstmeldinger, samtaler og databruk (surfing på nettet, applikasjoner som bruker nettet). Det vil alltid bli stilt spørsmål om det er mulig og hacke mobilnettet, og deretter lytte på privatpersoners mobiltrafikk. Dagens situasjon er at dette ikke er noe utbredt problem, men hvis noen ivrige datakriminelle finner ulike smutthull i mobilnettets krypteringer, kan det bli et stort problem både for operatørene og brukerne av mobilnettet. 7.2 Sikkerhet i Windows-applikasjonen I vårt prosjekt har prototyping vært hovedfokus, mens sikkerhet har blitt nedprioritet. Vi skulle i første omgang samarbeide med en gruppe fra Universitetet i Oslo, som skulle utvikle adgangskontroll. Etter å ikke ha hørt noe fra denne gruppen på en stund, ga arbeidsgiver beskjed om å ignorere adgangskontrollen og sikkerhet generelt, da intensjonen uansett var at produktet skulle videreutvikles etter vi var ferdige. 7.3 Brukere Systemkjernen vi jobbet mot har ikke hatt noe database over brukere, og funksjonen for å hente sikkerhetsnøkkel krever kun brukernavn og rolle, der rolle er det eneste som forhindrer brukeren å logge inn. Rollen må legges i et array, som sjekkes av kjernen. Kjernen sjekker ikke brukernavnet, og realiteten er at hvilket som helst brukernavn gir adgang, så lenge rollene er i orden. Som nevnt ovenfor samarbeidet vi med arbeidsgiver for å lage en fiktiv innloggingssjekk som applikasjonen kunne bruke. Dette gjør det mulig å bytte ut koden i checkcredentialsasync i fremtiden, uten at innlogging må endres. 34

79 8 Feilsøking Vi benyttet oss av ulike verktøy ved feilsøking av kildekoden. Disse er beskrevet under. 8.1 Feilmeldinger under kjøring Når en applikasjon kjøres fra Visual Studio lokalt på en maskin, kan det oppstå runtimeerrors. Disse vises med en rute som beskriver feilen med tekst. Samtidig lukkes applikasjonsvinduet. Vi håndterte disse feilene ved å se gjennom kildekoden og søkte spesifikt etter feilmeldingen på nettet. 8.2 Breakpoints Breakpoints brukes til debugging av en applikasjon. Ved å sette breakpoint hvor som helst i kildekoden har vi hatt muligheten til å spesifikt gå over forskjellige funksjoner for bedre forståelse av teknologien. Vi har valgt flere steder å bruke breakpoints på Microsoft egne funksjoner for nok en gang bedre forståelse av ha som foregår dypere inn i koden. Vi ser da om funksjonene henter ut riktig data og manipulerer den korrekt. Henter ikke funksjonen ut riktige data, kan utvikleren enkelt endre dette løpende for å få ønsket resultat. Figur 8.1: Tidlig prototype av opp og nedlastning fra kjernen. Opplastning krever dokumentet konvertert til base64 og vi får base64 tilbake. Eksempel på windows «Dark theme» nevnt tidligere. Vi benyttet breakpoints i vår feilsøking for å kunne se gjennom hver enkelt funksjon ettersom de ble utviklet og på selve kjernen for å se hva som skjedde på kjernen mens applikasjonen kjørte. 8.3 Automatisk fullføring Visual Studio var verktøyet vi brukte til å utvikle Metro-applikasjonen. Integrert i dette utviklingsverktøyet er det en funksjon som heter IntelliSense. IntelliSense er en autocomplete-funksjon som gir forslag til utvikleren basert på hva som er tidligere skrevet inn. Ved inntasting av klassenavn eller funksjoner så vil IntelliSense gir forklaringer og forslag til variabler som skal velges. 35

80 I XAML og designfasen ble start-tag automatisk fullført med en end-tag av IntelliSensefunksjonen. Dette gjør at utviklerne ikke trenger å bekymre seg over manglende end-tags hvis mye kode skal imellom. IntelliSense gir også forslag på attributter som lytter til elementer. Inntasting av «visibility=» gir forslaget «collapsed» og «visible». Dette var til stor hjelp under design-fasen, da vi ikke alltid var klar over hvilke muligheter vi hadde. 36

81 9 Tilbakemeldinger Vi har ikke gjort noen offisiell intervju-/tilbakemeldingsrunde med det ferdigstilte produktet. Vi har hatt kontakt med testpersoner underveis, men kan ikke komme med tilbakemeldinger på produktet i skrivende stund. Vi vil vise fram tilbakemeldinger i presentasjonen av produktet, etter vi har dette på plass. 37

82 10 Videreutvikling 10.1 Roller Vi har valgt å legge hovedfokuset vårt på én rolle; saksbehandler. Funksjonaliteten og navigering til startside for de andre rollene er likevel tilgjengelig og kan videreutvikles. Ved å fokusere på bare én rolle har vi fått begrenset prosjektet litt, og fått mer tid til å utvikle funksjonalitet for denne rollen Funksjonalitet I applikasjonen skulle vi ønske at det var mulighet for å markere saker som lest, eller ha en indikator fra kjernen om at saker er hentet fra før. Siden kjernen er tilstandsløs, vil ikke dette være mulig fra kjernen med det første, men dette er noe som kan videreutvikles på et senere tidspunkt. Redigering av tekstdokumenter i applikasjonen er også noe som kan videreutvikles, enten på egen hånd, eller ved å implementere fremtidige versjoner av SyncFusion. Visning av bilder og andre filer enn tekstfiler, er noe vi ser på som nødvendig for å gi brukeren mulighet til og kun bruke applikasjonen uten 3. parts-programvare til å håndtere disse filene. Funksjonalitet i kjernen er garantert noe som vil bli videreutviklet. Kjernen vi jobbet mot var uferdig, og på slutten av prosjektet var det en ny versjon av kjernen tilgjengelig, men vi har ikke benyttet denne. Arbeidsgiver ønsket ikke at vi brukte denne, da dette hadde kunnet føre til endringer i det vi allerede hadde gjort, noe vi ikke hadde hatt tid til å gjennomføre Datatrafikk og respons Favorittfunksjonen går i gjennom en liste med system-ider og gjør et kall for hver eneste system-id for å hente saksmappen. Dette gjør at en lang favorittliste kan bruke betydelig lengre tid på nettverk med høy responstid. Vi skulle da ønske at det var mulighet til å kontakte kjernen med flere system-ider og få en respons lik søkefunksjonen, der responsen er flere objekter sammenhengende. Applikasjonen lagrer saksmapper, men ikke registreringer. Det vil si at for hver registrering brukeren går inn på, gjøres et kall til systemkjernen. Dette kan løses med caching på system- IDer Design Designet er en prototype som er testet på et begrenset antall personer, og selv med positiv respons så vil ikke dette kunne regnes som majoriteten av brukere. Vi har også kun testet saksbehandlerrollen, og det kan godt hende de andre rollene trenger en annen fremgangsmåte under designet. 38

83 11 Kilder og referanser Co.Design. ( ). Can We Please Move Past Apple s Silly, Faux-Real UIs?. Hentet fra: Brukt til: Bakgrunn og ideer, skeuomorphic design Excelgrow. ( ). jpg-bilde. Brukt til: Forsidebilde. learnforeverblog. ( ). Skeuomorph. Hentet fra: Brukt til: Bilde, idial SyncFusion ( ). Visning av dokumenter. Hentet fra: Essential Studio ( ). Visning av dokumenter. Hentet fra: Wikipedia. ( ). Metro. Hentet fra: Microsoft.com. ( ). Index of UX guidelines for Windows Store apps. Hentet fra: 12 Vedlegg Vedlegg 1: Skisser 39

84 Vedlegg 1: Skisser Tidlige skisser, skeuomorphic og Metro, laget med forskjellige verktøy. Skeuomorphic Lucidchart Forklaring til ikoner for skisser laget i Lucidchart Login

85 Saker Søk

86 FluidUI Login Login, feilmelding

87 Startside Søk

88 Paint Login, feilmelding Opprett saksmappe

89 Metro Paint Startskjerm, leder Startskjerm, saksbehandler Saksmappe