Produktrapport. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Transkript

1 Produktrapport Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

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

34 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

35 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

36 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

37 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

38 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

39 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

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

41 Saker Søk

42 FluidUI Login Login, feilmelding

43 Startside Søk

44 Paint Login, feilmelding Opprett saksmappe

45 Metro Paint Startskjerm, leder Startskjerm, saksbehandler Saksmappe

46