HOVEDPROSJEKT. Studentdrevet innovasjon EasyBib. Randi Ueland, s Karoline Sanderengen, s Mona Isabelle Yari, s

Transkript

1

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Studentdrevet innovasjon EasyBib PROSJEKTDELTAKERE Randi Ueland, s Karoline Sanderengen, s Mona Isabelle Yari, s OPPDRAGSGIVER Læringssenteret ved studiested Pilestredet (LSB) DATO ANTALL SIDER / BILAG 111 INTERN VEILEDER Kirsten Ribu KONTAKTPERSON Tanja Strøm SAMMENDRAG Læringssenteret ved studiested Pilestredet har ønsket å få utviklet en applikasjon for mobile plattformer, som tilbyr deres digitale tjenester. Applikasjonen skal være tilgjengelig for alle, og universelt utformet. I dette prosjektet har det blitt utviklet to prototyper for denne applikasjonen. Prototypene er utviklet med tanke på brukervennlighet og universell utforming. 3 STIKKORD Universell utforming Brukeropplevelse Prototyping 2

3 Forord Læringssenter og bibliotek, heretter kalt LSB, la ut en oppgavebeskrivelse før jul der de fremstilte ønske om å få utviklet eller prototypet en applikasjon for de digitale tjenestene de tilbyr. Vi tok kontakt med LSB via mail og viste vår interesse. Vår innfallsvinkel for prosjektet var å utvikle en prototype av en applikasjon for mobile plattformer. Det ble lagt stor vekt på brukergrensesnitt, design og universell utforming. Vi vil gjerne takke Kirsten Ribu som har vært vår veileder under dette hovedprosjektet, for all hjelp og støtte hun har gitt oss. Vi vil også takke vår kontaktperson ved LSB, Tanja Strøm og hennes kollega Elin Stangeland, for veiledning og fint samarbeid. Sammendrag I dette hovedprosjektet har det blitt utviklet to prototyper for en applikasjon, som inneholder de digitale tjenestene som tilbys av LSB ved HiOA. Applikasjonen har fått navnet EasyBib. Hovedmålet med EasyBib er å få flere studenter og ansatte til å benytte seg av LSBs digitale tjenester. Det har blitt utformet én prototype i Adobe Photoshop og én kodet HTML prototype. Den kodede prototypen kan ses her: Denne prototypen er tilpasset smarttelefoner og utviklet for Android, og den vises derfor best på en smarttelefon med Android plattform. Trykk «Logg inn» for å gå videre, det er ikke nødvendig med brukernavn og passord. 3

4 Innholdsfortegnelse Forord... 3 Sammendrag... 3 Figurliste... 7 PRODUKTDOKUMENTASJON... 8 Kapittel 1 Introduksjon Om oppdragsgiver Dagens situasjon Bakgrunn for prosjektet BIBSYS Brukerdrevet innovasjon LSBs mobilvennlig side Prosjektets relevans EasyBib...14 Kapittel 2 Mål Mål for oppdragsgiver Mål for prosjektet...15 Kapittel 3 Brukeropplevelse og design Funksjonsnedsettelse og universell utforming Lover, standarder og retningslinjer Tilgjengelighet og universell utforming Universell utforming Tilgjengelighet Syv prinsipper for design WCAG Brukergrensesnitt Brukervennlighet Design Font Ikon Fargevalg...30 Kapittel 4 Metoder Spørreundersøkelse Kravspesifikasjon Brukertesting Prototyping Low fidelity prototype High fidelity prototype...35 Kapittel 5 Spørreundersøkelsen Om respondentene Resultater

5 Kapittel 6 Kravspesifikasjon Overordnet systembeskrivelse Rammekrav Generelle krav Funksjonelle krav: Ikke-funksjonelle krav: Spesifikke krav og egenskaper Hovedside Søk Mine lån Informasjon om LSB Personalisering Databaser Andre funksjoner Use Case Forslag til andre funksjoner...48 Sveip...48 Stjerneordning for dokumenter...48 Reserverknapp...49 Historikk over tidligere lån...49 Kapittel 7 Utviklingsprosesser Utviklingsverktøy Utviklingsteknologier Om prototypene Low-fidelity prototype High-fidelity prototype Funksjonene i prototypen Hovedside Menyknapp og tilhørende meny Tilbakeknapp Søkefunksjonen...55 Kapittel 8 Brukertesting Hensikt med brukertesting Testmiljø Personer tilstede under brukertesting Krav til testperson Personvern Oppgaver løst under bruketesten Oppfølgingsspørsmål etter utført brukertest Uformelle tester Formelle tester Endringer gjort i prototypen etter de uformelle testene Resultat av brukertestingen Oppfølgingsspørsmål Endringer gjort i prototypen etter de formelle testene Konklusjon av brukertestingen Brukertesting Funksjonalitet som ble testet Oppgaver som ble gjennomført under brukertestingen Resultat av brukertestingen

6 Konklusjon av brukertesting Kapittel 9 Sluttprodukt Low-fidelity prototype High-fildelity prototype Konklusjon...69 PROSESSDOKUMENTASJON Kapittel 10 Planlegging og metoder Prosess Rammebetingelser Prosessverktøy...72 Kapittel 11 Evaluering Kapittel 12 Konklusjon REFERANSELISTE VEDLEGG Vedlegg 1 Oppgavetekst...79 Vedlegg 2 Kontrasttester...80 Vedlegg 3 Spørreundersøkelsen...82 Vedlegg 4 Resultatene av spørreundersøkelsen fremstilt i grafer...84 Vedlegg 5 Use Case-beskrivelser...89 Vedlegg 6 Prototype under utvikling...93 Vedlegg 7 - Endelig prototype i helhet...95 Vedlegg 8 - Testplan...99 Vedlegg 9 Samtykkeerklæring Vedlegg 10 - Resultat av brukertesting Vedlegg 11 Fremdriftsplan (Gantt-diagram) Vedlegg 12 Risikoanalyse Vedlegg 13 Arbeidsplan Vedlegg 14 - Utdrag fra prosjektdagbok

7 Figurliste Figur 1 - Viser prikker uten åpenbar funksjon (t.v), viser tilbakeknapp (t.h) Figur 2 - Bookworms prototype (t.v), og Biblioteket ut av biblioteket prototype Figur 3 - LSBs mobilvennlige nettside Figur 4 - Åpningstider på LSBs mobilvennlige nettside Figur 5 - ipod med menydrevet brukergrensesnitt Figur 6 - Deler av skjermbilde i MS DOS som styres gjennom forskjellige kommandoer gjort av brukeren Figur 7 - EasyBibs hovedside som viser bruk av bilder og knapper Figur 8 - Viser bruk av gjenkjennbar menyknapp Figur 9 - Viser en varselboks som brukeren må bekrefte i EasyBib Figur 10 - Viser fargene i EasyBib når smarttelefonen er stilt inn til negative farger Figur 11 - Viser forskjellen mellom serif og sans-serif Figur 12 - Viser Roboto font i forskjellige variasjoner Figur 13 - Viser forskjell på store og små bokstaver Figur 14 - Viser bruk av lett gjenkjennelige ikoner Figur 15 Fargekart for EasyBib Figur 16 - Viser hvordan en knapp vises i EasyBib når den er inaktiv Figur 17 - Kontrasttest mellom oransje og sort Figur 18 - Viser fordelingen mellom fakultetene ved HiOA Figur 19 - Viser hvilke av LSBs tjenester som blir mest benyttet av studentene Figur 20 - Viser hvilke funksjoner og informasjon som er ønskelig i en applikasjon for LSB Figur 21 - Viser en oversikt over interessen for en applikasjon for LSBs tjenester Figur 22 - Use Case-diagram Figur 23 - Viser eksempler fra de forskjellige førsteutkastene av prototypene som ble utformet Figur 24 - Viser et utvalg fra den endelige low-fidelity prototypen basert på førsteutkastet Figur 25 - Viser annonseringsfelt på hovedsiden med informasjon om neste skrivekurs Figur 26 - Viser menyknapp i header Figur 27 - Utsnitt av Samsung Galaxy Ace telefon som viser tilbakeknapp Figur 28 - Viser to forslag på implementert tilbakeknapp i EasyBib Figur 29 - Bilder tatt under brukertestingen Figur 30 - Viser menyen etter endring og varselboks Figur 31 - Oversikt over de samlede resultatene fra første runde med brukertesting Figur 32 - Viser endring i header Figur 33 - Viser introduksjonsside

8 PRODUKTDOKUMENTASJON Produktdokumentasjonen inneholder en beskrivelse av EasyBib, kravspesifikasjon og testdokumentasjon. Det har blitt gjort rede for valg vi har tatt, og produktet skal sammen med dokumentasjonen gi grunnlaget for videre utvikling. Kapittel 1 Introduksjon 1. 1 Om oppdragsgiver LSB har 4 avdelinger, dette er Læringssentret P48, Læringssenteret P35, Læringssenteret P32 og Biblioteket ved Kjeller. Her kan studenter og ansatte blant annet låne bøker og tidsskrifter eller delta på diverse kurs. LSB har en lang rekke digitale tjenester som skal støtte undervisning og forskning ved HiOA. Deres tjenester inkluderer blant annet tidsskrifter, e-bøker og andre informasjonskilder, arkiver med innhold produsert av ansatte og studenter, samt vitenskapelige tidsskrifter som HiOA publiserer. 1.2 Dagens situasjon LSB bruker årlig flere millioner kroner på tilgang til databaser med innhold fra en rekke tidsskrifter. Det er dessverre få studenter som benytter seg av disse tilbudene, eller er klar over de ressursene som er tilgjengelige hos LSB. 8

9 En av fem nordmenn bruker medieinnhold på mobile plattformer daglig, og det er en stadig økende utvikling innen området. Prosjektet tar utgangspunkt i LSBs ønske om at studenter skal se på virksomheten med friske øyne. De ønsker nye ideer, prototyper eller fungerende løsninger i form av en applikasjon til mobile plattformer. Ved å lage en applikasjon håper LSB at flere vil ta i bruk de ressursene de tilbyr. 1.3 Bakgrunn for prosjektet Med bakgrunn i dagens situasjon og tidligere lignende prosjekter som har blitt gjennomført ved andre institutter, ønsket LSB å få til noe tilsvarende ved HiOA. Av lignende prosjekter nevner LSB Universitetet i Oslo (UiO) og BIBSYS. BIBSYS har kommet med en fullverdig applikasjon for sine tjenester, og UiO har utviklet prototyper. LSB har gjort et forsøk på å gjøre sine tjenester tilgjengelig for mobile plattformer ved å tilby en mobilvennlig nettside. For å få en oversikt over hva løsningene tilbyr, ble det gjennomført en vurdering av disse BIBSYS BIBSYS leverer kostnadseffektive informasjonstjenester for universitets- og høgskolesektoren, Nasjonalbiblioteket, forskningsinstitutt og fagbiblioteker for øvrig (BIBSYS, udatert). BIBSYS er systemet som ligger bak bibliotektjenestene til LSB. Applikasjonen ble lastet ned og det ble foretatt en vurdering av denne. Applikasjonen har et enkelt brukergrensesnitt som for det meste er lett å forstå. Den største grunnen til at den fremstår som enkel å bruke er at den har relativt begrensede funksjoner. Den inneholder følgende: Mine lån, Mine bestillinger, Mitt bibliotek og Min profil. Under Mine lån ligger alle lånte bøker i liste, og om brukeren trykker seg inn på en bok, kan han se forfallsdato og fornye lånet. Dersom boken er reservert av noen andre vil ikke fornyelse være mulig. Mine bestillinger inneholder alle dokumenter som brukeren har 9

10 reservert. Siden BIBSYS er en informasjonstjeneste som benyttes i biblioteker på landsbasis, er det mulig å velge hvilken institusjon brukeren skal logges inn under. Dette valget blir tatt rett etter innlogging. Når eventuelt sted er valgt, vil brukeren kunne finne informasjon om de forskjellige avdelingene som ligger under brukerens institutt under Mitt bibliotek. Her finner brukeren informasjon som adresse, telefonnummer og e-postadresse til de forskjellige avdelingene. På Min profil ligger informasjonen som er lagret om brukeren i den gitte institusjonen. Blant annet finner man navn, brukernummer, adresse og telefonnummer. Det er også opplyst hvilken institusjon brukeren hører til, hva som er utlånsstedet og hvordan brukeren har valgt å motta hentebeskjed (eksempelvis via SMS). Ved bruk av BIBSYS sin applikasjon kommer det frem noen negative aspekter. Alle informasjonslinjer har en prikk i enden. Det fremgår ikke hva disse prikkene gjør, da de ikke har noen åpenbar funksjon. Tilbakeknappen som er plassert øverst i venstre hjørne har ikke en gjenkjennelig utforming. Vi mener at den ikke gir brukeren en umiddelbar forståelse for dens funksjon, og er derfor ikke optimal. Figur 1 - Viser prikker uten åpenbar funksjon (t.v), viser tilbakeknapp (t.h). (Skjermdump fra applikasjonen til BIBSYS hentet: 14.april 2013). 10

11 1.3.2 Brukerdrevet innovasjon Høsten 2012 ble det satt i gang et prosjekt ved Universitetet i Oslo kalt brukerdrevet innovasjon. Prosjektet gikk ut på at brukerne selv skulle utvikle en applikasjon for biblioteket. I løpet av høsten 2012 utviklet fem prosjektgrupper bestående av studenter ved instituttet for informatikk, hvert sitt utkast av en prototype for bibliotekapplikasjonen. Prototypene ble beskrevet som veldig gode og hadde potensiale til å videreutvikles til fullverdige applikasjoner. Figur 2 - Bookworms prototype (t.v), og Biblioteket ut av biblioteket prototype. (Skjermdump hentet fra: 17.april.2013) LSBs mobilvennlig side LSB har gjort et forsøk på å gjøre sine tjenester tilgjengelig for smarttelefon og nettbrett. På deres nettsider kan man velge en såkalt mobilvennlig side ved å trykke seg inn på en link. Denne linken fører til en side med menyvalg presentert i form av ikoner og tekst, vist i Figur 3. 11

12 Figur 3 - LSBs mobilvennlige nettside. (Skjermdump hentet fra: 17.april 2013). En bruker kan videre trykke på den blå markerte teksten for å navigere seg rundt. Problemet er at den mobilvennlige nettsiden ikke fungerer optimalt på en smarttelefon. På forsiden er det kun mulig å trykke på teksten og ikke ikonene. En smarttelefon har begrenset størrelse på skjermen og det kan være vanskelig å treffe teksten. Videre fører menyvalgene brukeren til andre tilpassede sider, hvor bilder er fjernet og informasjon er plassert under hverandre i en liste, se Figur 4. Informasjonens plassering fremstår som rotete og uoversiktlig. Flere av sidene skalerer ikke etter skjermens størrelse, noe som er upraktisk da ulike typer smarttelefoner har forskjellig skjermstørrelse. En bruker må først inn på LSBs nettside for å videre navigere seg inn på den mobilvennlige siden. Flere av funksjonene, som for eksempel BIBSYS, er ikke tilgjengelig i mobilvennlig format, og sender dermed brukeren til den ordinære nettsiden. 12

13 Figur 4 - Åpningstider på LSBs mobilvennlige nettside. (Skjermdump hentet fra: 17.april.2013). For en bruker som kun er ute etter enkel informasjon slik som LSBs åpningstider eller campuskart, er likevel den mobilvennlige nettsiden enklere å bruke fra en smarttelefon enn LSBs ordinære nettside. Den mobilvennlige nettsiden fungerer likevel ikke optimalt, og har forbedringspotensial Prosjektets relevans Det kommer frem i oppgaveteksten at LSB ønsker å ta i bruk nye midler for å nå ut til brukerne. En av fem nordmenn benytter seg daglig av medieinnhold på mobile plattformer. Norge og de andre skandinaviske landene regnes som teknologisk avanserte, og befolkningen er som regel tidlig ute med å ta i bruk ny teknologi. Tilgang på smarttelefoner og nettbrett har ført til at folk har begynt å bruke sine smarttelefoner til å surfe på Internett. Se Vedlegg 1 for oppgavetekst. 13

14 På bakgrunn av dette betegner vi det som relevant for LSB å tilby sine tjenester på mobile plattformer. LSB vil da nå sine brukere på nye måter, og dette kan gjøre tjenesten mer synlig og lettere tilgjengelig. 1.4 EasyBib Oppdragsgiver stilte ingen krav til applikasjonen, og prosjektgruppen har derfor jobbet svært selvstendig. LSB ønsket at studenter skulle utvikle for studenter, og ville ikke styre oss i noen retning. Prosjektet har på bakgrunn av dette fått navnet Studentdrevet innovasjon. I tillegg har vi valgt å kalle vår løsning for EasyBib. I prosjektet har det blitt utviklet to prototyper, en low-fidelity prototype designet i Adobe Phototshop og en high-fidelity prototype kodet ved bruk av HTML og CSS. Prototypene viser sammen EasyBibs funksjonalitet, og gir et helhetlig inntrykk av applikasjonen. Prototypene er utviklet for Androidplattform og brukergrensesnittet er tilpasset smarttelefoner. EasyBib vil likevel kunne tilpasses andre plattformer og enheter, som ios og nettbrett. Ved hjelp av spørre- og brukerundersøkelser fikk vi innblikk i hvilke funksjoner som var ønskelig i EasyBib, og en bedre forståelse av hvilke funksjoner som er nødvendig for brukerne. EasyBib har derfor blitt utviklet med indirekte hjelp av brukerne selv, og løsningen er dermed egnet til deres bruksområde. På denne måten håper vi at flere vil ta i bruk EasyBib. 14

15 Kapittel 2 Mål Målet for prosjektet er å lage en prototype av en applikasjon tilpasset Androidplattform, som leverer LSB sine digitale tjenester til smarttelefon og nettbrett. Oppdragsgiver la vekt på at løsningen skulle være tilgjengelig for alle, og det ble derfor bruket mye tid og ressurser på å gjøre EasyBib universelt utformet. 2.1 Mål for oppdragsgiver Få en applikasjon som tilbyr deres digitale tjenester. Øke antallet studenter og ansatte som benytter seg av deres tjenester. 2.2 Mål for prosjektet Utforme en prototype for en applikasjon tilpasset Androidplattform. Utføre gode kvantitative undersøkelser for å kartlegge brukernes behov. Utføre gode brukertester for å kartlegge hva som gir best brukeropplevelse. Prosessen i prosjektet skal resultere i et brukergrensesnitt som kan brukes av alle. Lage en prototype med god tilnærming til et ferdig produkt. Dokumentere prosjektet på en god måte, slik at EasyBib har potensiale for videreutvikling til andre plattformer. 15

16 Kapittel 3 Brukeropplevelse og design I prosjektet har universell utforming vært en viktig del. LSB ønsket at en applikasjon med deres tjenester skulle være utviklet og designet, etter de retningslinjer som gjelder for tilgjengelighet og universell utforming. LSB inngår under HiOA og er en offentlig instans. Det er derfor viktig at tjenestene som tilbys er utformet slik at flest mulig kan benytte seg av disse, uten å bli hindret av eventuelle funksjonsnedsettelser. 3.1 Funksjonsnedsettelse og universell utforming EasyBib vil som ferdig utviklet være tilrettelagt for personer med funksjonsnedsettelser, og vi vil derfor definere dette begrepet. Deltasenteret er et kompetansesenter for deltakelse og tilgjengelighet, og deres arbeid går ut på å få folk med funksjonsnedsettelser til å delta i samfunnet, på lik linje som alle andre. De har definert nedsatt funksjonsevne slik: «Nedsett funksjonsevne vil seie tap av eller skade på ein kroppsdel eller i ein av kroppsfunksjonene. Det kan til dømes dreie seg om nedsett rørsle-, syns- eller høyrslefunksjon, nedsett kognitiv funksjon eller ulike funksjonsnedsetjingar på grunn av til dømes allergi, hjartesjukdomar, lungesjukdomar, nevrologiske sjukdomar eller psykiske lidingar (Bufetat,udatert a)» På Deltasenteret beskrives også målgruppen for universell utforming. De sier at alle mennesker, uansett alder, størrelse og ferdigheter, skal tas hensyn til når vi planlegger og utformer. Hele befolkningens behov skal legges til grunn når behov og ønsker vurderes. Å ta hensyn til at funksjonsevnen varierer fra person til person er sentralt for å oppnå et produkt som er universelt utformet (Bufetat, udatert b). 16

17 3.2 Lover, standarder og retningslinjer Det finnes flere lover og retningslinjer som gjelder for universell utforming og tilgjengelighet, og begrepene er definert av flere instanser. I FN-konvensjonen om rettighetene til mennesker med nedsatt funksjonsevne, er følgende faglige definisjon nedfelt: «Med universell utforming menes: utforming av produkter, omgivelser, programmer og tjenester på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming. Universell utforming skal ikke utelukke hjelpemidler for bestemte grupper av mennesker med nedsatt funksjonsevne når det er behov for det.» (Sandnes, 2011: 29). Denne definisjonen tar for seg alle områder universell utforming gjelder for, inkludert IKT. I Norge nevnes universell utforming i sammenheng med IKT spesifikt i lovtekster. Direktoratet for forvaltning og IKT har som visjon å utvikle offentlig sektor, og sier at ett av deres innsatsområder er digitale tjenester (Difi, 2013). På Difi (2013) står følgende: «Utvikling av digitale tjenester er en av de viktigste driverne for å få til effektivisering og gode tjenester for brukerne. Digitalisering av offentlig forvaltning gir betydelige gevinster, og befolkningen forventer i økende grad å benytte digitale kanaler i kontakten med det offentlige.» I 2009 ble det gjennom Diskriminerings- og tilgjengelighetsloven innført plikt til universell utforming av IKT. Denne forskriften vil gjelde for offentlige og private bedrifter, og skal etter planen vedtas 1.juli Unntaket er for eksiterende IKT-løsninger, der forskriftene sier at disse skal være universelt utformet fra Frem til forskriften blir vedtatt anbefales det at nettsider minst oppfyller nivå AA (WCAG 2.0) for retningslinjer for tilgjengelighet på nettsider (Difi, 2013). 17

18 I Diskriminerings- og tilgjengelighetsloven defineres universell utforming slik: «Med universell utforming menes utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene, herunder informasjons- og kommunikasjonsteknologi (IKT), slik at virksomhetens alminnelige funksjon kan benyttes av flest mulig.» (Lovdata, 2013). 3.3 Tilgjengelighet og universell utforming Universell utforming og tilgjengelighet er to forskjellige betegnelser med ulik betydning. Her er det hovedsakelig de viktigste aspektene som er trukket frem, for å gi en overordnet beskrivelse av begge. Begrepene favner om store områder, men er her beskrevet i sammenheng med IKT Universell utforming Begrepet universell utforming ble i første omgang benyttet innen fagområdet for arkitektur og planlegging. Der ble det brukt for å beskrive hvordan utearealer, bygninger og skilting skulle tilgjengeliggjøres. Hovedmålet med universell utforming er å designe en standardløsning som er tilpasset alle målgrupper. The Center for Universal Design, North Carolina State University definerer universell utforming slik: «Universell utforming er utforming av produkter og omgivelser på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming.» (Sandnes, 2011: 28). Begrepet universell utforming er gjeldene for flere områder, f.eks. omgivelser, produkter og programmer. For disse, og andre områder, betyr det at utformingen skal gjøre det mulig for alle mennesker å bruke, i så stor grad det lar seg gjøre (Sandnes, 2011). Det vil si at et produkt ikke skal utformes i den grad det kun appellerer til en bestemt brukergruppe. For eksempel vil en mobiltelefon uten skjerm, utviklet spesifikt for blinde, gi et uttrykk for funksjonsnedsettelsen gjennom produktets utforming. Et produkt av 18

19 denne typen kan være uønsket, og bli avvist av den tiltenkte brukergruppen (Plos, O. & Buisine, S., 2006). Dette sier noe om hvor viktig det er å unngå diskriminering på bakgrunn av funksjonsnedsettelser. I noen tilfeller vil likevel slike produkter være de mest anvendelige, men i det generelle bildet tar universell utforming for seg prinsippet om å utforme for mangfoldet. Slik kan man unngå eller redusere behovet for spesialløsninger eller sikre at muligheten for å benytte hjelpemidler er tilstede. Dette vil gi et produkt eller en løsning som er bedre for alle (Bufetat, 2013) Tilgjengelighet Tilgjengelighet vil si at standardløsningen støtter bruk av eget tilleggsutstyr. Flere tjenester og tilbud vi benytter oss av i dagliglivet blir elektroniske, og ofte følger ekstra gebyrer eller lignende for de som ikke har mulighet til å benytte seg av disse. Et eksempel på dette er billettautomatsystemet til NSB, der man må betale ekstra gebyr for å kjøpe billett på toget. Med den utviklingen samfunnet tar er det viktig at løsninger blir utformet slik at de er enkle for alle å bruke, uavhengig av kunnskapsnivå, tekniske ferdigheter eller funksjonsnedsettelser. Det finnes flere typer tilleggsutstyr personer med funksjonsnedsettelser kan benytte seg av for å kunne bruke web og annen datateknologi. Disse kalles gjerne tilrettelagte spesialløsninger eller kompenserende teknologi. Et eksempel på dette er minibanker som støtter bruk av høretelefoner, på denne måten kan brukeren få informasjonen lest opp. Når samfunnet erstatter gamle løsninger med nye elektroniske løsninger, må det forventes at alle kan benytte seg av de nye tjenestene. Når dette ikke er tilfelle, fører det til utestenging og diskriminering. 19

20 3.3.3 Syv prinsipper for design Den tidligere nevnte definisjonen for universell utforming gjort av The Center for Universal Design, kan også knyttes til de syv prinsippene for universell utforming. Disse designprinsippene er utformet for universell utforming, og skal gi veiledning i designprosesser og ved evalueringer av eksisterende løsninger. De syv prinsippene hentet fra Norsk Designråd (2007): 1. Enkel og intuitiv i bruk Utformingen skal være lett å forstå uten hensyn til brukerens erfaring, kunnskap, språkferdigheter eller konsentrasjonsnivå. 2. Forståelig informasjon Utformingen skal kommunisere nødvendig informasjon til brukeren på en effektiv måte. 3. Toleranse for feil Utformingen skal minimalisere farer og skader som kan gi ugunstige konsekvenser, eller minimalisere utilsiktede handlinger. 4. Like muligheter for alle Utformingen skal være brukbar og tilgjengelig for personer med ulike ferdigheter 5. Fleksibel i bruk Uansett individuelle preferanser og ferdigheter. Den synshemmede skal kunne høre, den hørselshemmede se og så videre. 6. Lav fysisk anstrengelse Utformingen skal kunne brukes effektivt og bekvemt med minimum besvær. 7. Størrelse og plass for tilgang og bruk Hensiktsmessig størrelse og plass skal muliggjøre tilgang, rekkevidde, betjening og bruk, uavhengig av brukerens kroppsstørrelse, kroppsstilling og mobilitet. 20

21 3.4 WCAG 2.0 WCAG (Web Content Accessibility Guidelines) 2.0 er et dokument som inneholder fokusområder, retningslinjer og anbefalinger samt krav for hvordan webinnhold kan gjøres mer tilgjengelig (Mehran, udatert). Dokumentet skal bidra til at webinnhold kan gjøres tilgjengelig for en større gruppe mennesker, slik som for eksempel personer med synsproblemer, kognitive begrensninger, begrenset bevegelighet, lysfølsomhet og kombinasjoner av disse (W3C, 2013c). For at behovene til ulike grupper og ulike situasjoner skal oppfylles i forbindelse med designspesifikasjoner, innkjøp, lovregulering og avtaler, er det definert 61 testbare krav fordelt på tre nivåer av samsvar: A (laveste nivå), AA og AAA (høyeste nivå) (W3C, 2013c; Mehran, udatert). 3.5 Brukergrensesnitt «Brukergrensesnittet er det mest synlige i et datasystem, og befolkningens port mot den digitale verden. Uansett hva som ligger under panseret, og uansett hvor avansert eller enkel den underliggende datateknologien er, så er det brukergrensesnittet som gir inntrykk av tjenesten som tilbys.» (Sandnes, 2011: 13). Brukergrensesnittet kan omtales som kontaktflaten mellom en bruker og et program eller operativsystem. Det finnes forskjellige typer brukergrensesnitt, blant annet menydrevet, kommandodrevet og grafisk (Store Norske Leksikon, udatert). Et menydrevet brukergrensesnitt består av menyer som lister opp elementer som brukeren velger fra. For eksempel har en ipod og noen typer mobiltelefoner et menydrevet brukergrensesnitt (JFK-Computing, udatert a). 21

22 Figur 5 - ipod med menydrevet brukergrensesnitt. (Skjermdump hentet fra: 4.mai.2013). Kommandodrevet brukergrensesnitt kontrolleres av brukeren via tastaturet (ComputerUser, udatert a). I et slikt brukergrensesnitt vil brukeren utføre sine oppgaver ved hjelp av tekstlige kommandoer, slik som i MS DOS eller UNIX. Kommandodrevet brukergrensesnitt benytter ikke grafiske bilder eller lignende (JFK-Computing, udatert b). Figur 6 - Deler av skjermbilde i MS DOS som styres gjennom forskjellige kommandoer gjort av brukeren. (Skjermdump hentet fra: 6.mai.2013). Det som er mest brukt i dag er grafiske brukergrensesnitt eller GUI, som står for Graphical User Interface. Her er grensesnittet presentert ved hjelp av bilder og knapper som brukeren benytter for å utføre sine oppgaver (JFK-Computing, udatert c). 22

23 Eksempler på grafiske brukergrensesnitt er operativsystemer som Windows, ios og moderne smarttelefoner (ComputerUser, udatert b). EasyBib har et grafisk brukergrensesnitt. Figur 7 - EasyBibs hovedside som viser bruk av bilder og knapper. Et brukergrensesnitt som er godt utformet vil gi fordeler til både bruker og produsent. Brukeren vil oppleve grensesnittet på en positiv måte, og kan foretrekke det over andre varianter. For produsent vil dette gi positive fordeler i konkurransen i markedet (Sandnes, 2011). For å oppnå et bra brukergrensesnitt er det viktig at brukeren av systemet er i fokus under utviklingen. Det er vanlig å utvikle utkast og teste disse på representative brukere. Utviklingen skjer da gjennom iterasjoner, der endringer og forbedringer blir gjort underveis i prosessen. Det er ikke bare forbedring av grensesnittet som oppnås, forståelsen for brukerne og deres behov økes også (Sandnes, 2011). 23

24 3.6 Brukervennlighet Med brukervennlighet menes det at samhandling mellom bruker og system, foregår på en måte som brukeren oppfatter som god (Brukertest.com, udatert a). Handlings- og evalueringssyklusen er sentral for å forstå hvordan mennesker samhandler med maskiner. Ved å ta hensyn til denne samt brukerens kunnskaps- og ferdighetsnivå, danner dette et grunnlag for å oppnå brukervennlighet. Handlings- og evalueringssyklusmodellen sier at all interaksjon består av en handlingsfase og en evalueringsfase. Modellen viser også at det kan oppstå handlingskløft eller evalueringskløft. Handlingskløft oppstår når brukeren ikke er i stand til å utføre handlingen, og evalueringskløft er når brukeren ikke oppfatter at handlingen er utført. Modellen er generell nok til å omfatte funksjonsnedsettelser, og det er flere situasjoner som kan skape handlingskløft og evalueringskløft for mennesker med funksjonsnedsettelser. Dersom brukeren ikke har mulighet til å benytte brukergrensesnittets input metode, fordi han eller hun har for eksempel ikke har hender, og brukergrensesnittet krever det, vil det oppstå en handlingskløft. For å være et brukervennlig grensesnitt må det da muliggjøres bruk av kompenserende teknologi, for eksempel talestyring (Sandnes, 2011). Sandnes (2011) beskriver noen begreper som er sentrale for brukervennlighet. Synlighet: For at brukergrensesnittet skal gi god brukervennlighet, er det viktig at alle handlinger som er mulig å utføre er synlige i systemet. Brukeren skal ikke måtte lete etter elementer som er nødvendig for å fullføre en oppgave. Tilbydelser: For at brukeren skal kunne utføre en handling er det viktig at brukeren forstår hvordan denne handlingen skal utføres. Må brukeren trykke på en knapp for å reservere en bok, 24

25 må denne knappen tydelig se ut som en knapp, slik at brukeren forstår at han eller hun skal trykke på den for å reservere boken. Tilbakemeldinger: Brukeren skal ikke måtte undre på om handlingen han eller hun har utført er gjennomført. For at systemet skal fremstå som trygt, og for at brukeren skal være sikker på at en handling er utført, er det viktig at systemet gir tilbakemelding til brukeren. Toleranse: Det er viktig at brukeren kan korrigere eventuelle feil som er gjort, eller reversere handlingen dersom det ikke var den handlingen brukeren ønsket å utføre. Av den grunn bør alle handlinger være reversible. Avgrensing: Systemet bør ikke gi brukeren mulighet til å utføre handlinger som ikke er relevante eller som er ugyldige. For eksempel bør ikke et system gi en bruker mulighet til å reservere en bok som ikke er tilgjengelig. Gjenkjennbarhet: Oppnås ved å benytte lett gjenkjennelige elementer som brukeren forstår ut i fra tidligere erfaringer og kunnskap, eller ferdigheter brukeren allerede har. Bruk av metaforer utnytter brukerens mentale modeller, altså at brukeren vet hvordan noe virker fra før av. Dermed unngår man at brukeren opplever problemer eller usikkerhet rundt bruken av systemet. Metaforer: Ved å benytte metaforer i et system kan det gjøre det lettere for brukerne å forstå komplekse systemer, og gjøre det enklere for brukerne å benytte systemet. Da kan brukeren dra nytte av kunnskap og forståelse han eller hun har fra før av. For eksempel kan man benytte knapper, og når brukeren ser en knapp vet han eller hun at den kan trykkes på. 25

26 Sandnes (2011: 16) viser til 5 nøkkelegenskaper ved brukervennlighet som har hatt sentral rolle under utviklingen av EasyBib: 1. Systemet må være lett å lære 2. Bør være effektivt å bruke 3. Må være lett å huske over tid hvordan systemet brukes 4. Systemet bør minimalisere sjansene for feil og være tolerant for feil 5. Systemet må være behagelig å bruke 3.7 Design Designet er en viktig del av applikasjonen, og valg av design kan være avgjørende for hvor mange som faktisk kan bruke den. Et av kravene som er satt til EasyBib er at den skal oppfylle de syv prinsippene for universell utforming som er beskrevet i avsnitt Ideelt sett skal EasyBib kunne brukes av alle studenter. For å oppfylle kravene har vi måttet ta flere valg: Oppsettet og designet i EasyBib er utformet for å gi brukeren et enkelt grensesnitt å forholde seg til. For at applikasjonen skal oppleves enkel å bruke er det fokusert på at elementer skal skilles tydelig fra hverandre og være av god størrelse, slik at det er enkelt for brukeren å treffe riktig. Knappene er store og tydelige, og de er gjenkjennbare ved at alle har samme farge gjennom hele applikasjonen. For at brukeren skal kunne benytte EasyBib effektivt er det begrensede valgmuligheter i den. På hovedsiden får brukeren tre valg, Mine lån, Søk og Info om LSB, som gir brukeren enkel tilgang på de viktigste funksjonene. Gjennom hele applikasjonen er det lagt vekt på at informasjonen er forståelig, og dette er gjennomført ved hjelp av ikoner, beskrivende tekst, tipsboks og elementer som er 26

27 gjenkjennbare. For eksempel har menyknappen samme design som den som benyttes i Facebook sin applikasjon. Figur 8 - Viser bruk av gjenkjennbar menyknapp. (Skjermdump fra Facebook applikasjon hentet 2.mai 2013). For at EasyBib skal være brukervennlig er det viktig at brukeren føler seg trygg på handlingene som blir gjort. Feilmeldinger og bekreftelser gis derfor til brukeren i situasjoner der det er nødvendig. Et eksempel er når brukeren skal reservere et dokument eller fornye et lån. Brukeren vil i begge tilfeller få opp en varselboks som beskriver at han eller hun har reservert et dokument eller fornyet et lån. Brukeren må også bekrefte varselboksen ved å trykke på en OK-knapp. Se Figur 9. Figur 9 - Viser en varselboks som brukeren må bekrefte i EasyBib. EasyBib skal fungere bra sammen med tilgjengelighetsfunksjoner som eksisterer i smarttelefonens operativsystem. Blant annet er det valgt å bruke sort tekst på hvit bakgrunn med tanke på at brukeren skal kunne gjøre fargene negative i smarttelefonens brukergrensesnitt. Dersom brukeren gjør dette skal fargene i applikasjonen fortsatt gi gode kontraster. Se Figur

28 Figur 10 - Viser fargene i EasyBib når smarttelefonen er stilt inn til negative farger Font Det finnes i hovedsak to typer fonter, sans-serif og serif. Forskjellen på disse er at serif har små fnutter eller ben på endene, mens sans-serif ikke har det. Denne fonten er serif Denne fonten er sans-serif Figur 11 - Viser forskjellen mellom serif og sans-serif. Sans-seriffonter er enklere i utseende og er derfor lettere å lese for de som har dysleksi eller lesevansker (British Dyslexia, udatert). Med bakgrunn i dette, og at det er relativt vanlig med dysleksi eller lesevansker, er det brukt en font som er sans-serif. En slik font har også et renere og mer elegant utseende som passer utformingen til EasyBib. Det er videre viktig at brukeren har muligheten til å endre skriftstørrelse. Det ble derfor valgt å bruke en font som er en standard font i operativsystemet Android, for å forsikre at dette er mulig for brukeren. Det er da mulig å skifte skriftstørrelse gjennom smarttelefonens innstillinger. Fonten som er brukt i EasyBibs low-fidelity prototype heter Roboto. 28

29 Figur 12 - Viser Roboto font i forskjellige variasjoner. I hovedsak er Roboto-Condensed brukt i EasyBib fordi den gir det visuelle uttrykket vi ønsket. Den er i tillegg godt lesbar for de fleste. All skrift består av store og små bokstaver. Kun store bokstaver vil ikke bli benyttet, siden det gjør det mindre lesbart for mennesker med lesevansker. Ved å bruke små og store bokstaver beholder vi høydesignaturen, altså at ordene har noen bokstaver som stikker opp og noen som stikker ned. Ordene blir mer gjenkjennbare fordi vi ikke leser bokstav for bokstav, men ordet i sin helhet (Sandnes, 2011). I Figur 13 viser tydelig forskjellen på blanding av store og små bokstaver og bare store bokstaver. Læringssenter og bibliotek LÆRINGSSENTER OG BIBLIOTEK Figur 13 - Viser forskjell på store og små bokstaver Ikon I EasyBib har alle menyvalgene blitt illustrert ved hjelp av gjenkjennbare ikoner. Brukeren skal i størst mulig grad forstå hva som befinner seg i et menyvalg ut i fra ikonet. Hva som gjør et ikon gjenkjennbart for en bruker varierer, men det finnes likevel eksempler på ikoner som mange har samme assosiasjon til. Et eksempel er tannhjulet som ofte blir brukt til å illustrere innstillinger, eller huset som illustrerer hovedside. 29

30 Figur 14 - Viser bruk av lett gjenkjennelige ikoner. I Figur 14 ser vi hvordan og hvilke ikoner som er brukt i EasyBibs meny. Flere av elementene har ikoner som anses som universelle, blant annet Hovedside, Innstillinger, Brukerkonto og Logg av. Noen elementer vil være vanskelige å illustrere med bare ikon, derfor er kombinasjonen av ikon og tekst viktig. Brukeren får da to forskjellige indikasjoner på hva slags informasjon som ligger under elementene Fargevalg Designvalg og fargevalg kan bidra til å bedre et sluttprodukt. For at EasyBib skal være brukervennlig og samtidig estetisk, har vi vært nøye med fargevalg. I hovedsak var det viktigst at applikasjonen fikk et brukervennlig grensesnitt, men det var også viktig at brukervennligheten ble formidlet gjennom det estetiske designet. EasyBib er utformet med tanke på brukervennlighet. Applikasjonen skal være innbydende og fristende å bruke. Farger og design kan i høy grad være en smakssak, og derfor er utformingen holdt enkel og ren. Det er likevel ikke ønskelig at EasyBib skal fremstå steril og kald. 30

31 Figur 15 Fargekart for EasyBib. Fargene som er brukt i EasyBib er komplementærkontrastene oransje og blå, samt fire nyanser fra gråtoneskalaen. Oransje er valgt fordi det er en gjennomgående farge på HiOAs nettprofil og skaper gjenkjennelighet. Kombinasjonen av fargene gir et friskt og moderne uttrykk. Oransje og blå er de kraftigste kontrastene som finnes, og sammen med sort trer de tydeligere frem. Dette er viktig for at EasyBib skal kunne brukes av mennesker med synsnedsettelser. Tekst fremstilles hovedsakelig i sort på hvit bakgrunn, men i noen tilfeller som hvit tekst på mørkgrå bakgrunn. Dette er en kombinasjon som gir god lesbarhet. De elementene som er blå er i hovedsak knappene. Disse er alltid blå med mindre det ikke er mulig å trykke på knappen, da vil den være lysgrå. Figur 16 - Viser hvordan en knapp vises i EasyBib når den er inaktiv. For å sikre at kontrastene er gode nok har vi benyttet et webverktøy som heter Colour Contrast Check (snook.ca, 2009). Dette verktøyet gjør det mulig å teste kontrastene i 31

32 fargene som brukes i forgrunn og bakgrunn. Ved hjelp av fargekoder tester Colour Contrast Check om kontrasten mellom fargene er stor nok. Den gir tilbakemelding på hvilket nivå av WCAG 2.0 kontrastene holder. På bakgrunn av tilbakemeldingene i kontrasttestene gjorde vi endringer i EasyBib. Blant annet er tekst på knapper og i header endret fra hvit til sort, fordi testene viste at kontrasten var dårlig. Se Vedlegg 2 for alle kontrasttestene. Figur 17 - Kontrasttest mellom oransje og sort. EasyBib har et gjennomgående design som presentere informasjonen på en oversiktlig måte. Fargene på de forskjellige elementene er gjennomgående. Dette gjør det lett å kjenne igjen de forskjellige elementene, som bidrar til å øke brukervennligheten. 32

33 Kapittel 4 Metoder Deler av prosjektet omfatter kartlegging av LSBs tjenester og hvordan disse blir brukt av studentene. Det var avgjørende for prosjektet å tilegne seg god innsikt i hva brukerne ønsket og trengte i en applikasjon, slik at den tilbyr de rette tjenestene til studentene. Det er også viktig at applikasjonen kan bidra til å øke studentenes bruk av LSB sine digitale tjenester. For å oppnå dette ble det benyttet spørreundersøkelse, brukertesting og prototyping som metoder. I dette kapittelet er metodene beskrevet. Gjennomgang av resultater fra spørreundersøkelsen, brukertesting og prototyping er presentert i senere kapitler. 4.1 Spørreundersøkelse LSB ønsket å kartlegge interessen blant studentene ved HiOA, for en applikasjon tilpasset mobile plattformer som tilbyr deres tjenester. Før utformingen av prototypen begynte ble det gjennomført en spørreundersøkelse. Dette er en kvantitativ metode som ga målbare resultater og svar fra et bredt utvalg av respondenter. Undersøkelsen ble laget gjennom et gratis nettbasert verktøy ved navn SurveyMonkey, og denne ble sendt ut til studentene via skolens e-post. Spørsmålene til undersøkelsen ble utformet i samarbeid mellom prosjektgruppen og Elin Stangeland, ansatt ved LSB. Det ble benyttet en kombinasjon av åpne og lukkede spørsmål. De lukkede spørsmålene krevde at respondentene valgte kun ett svaralternativ. De åpne spørsmålene gav respondentene frihet til å skrive sin personlige mening, eller velge flere svaralternativer. Se Vedlegg 3 for den fullstendige spørreundersøkelsen. 33

34 Svarene ble presentert på en ryddig og oversiktlig måte i form av grafer i verktøyet. Det var mulig å lese tallene direkte fra grafene som gjorde det enkelt å prosessere dataene. Det ble valgt å sette en maks grense på 100 svar. Resultatene fra spørreundersøkelsen er presentert i kapittel Kravspesifikasjon Siden det ikke ble stilt noen krav til mobilapplikasjonen fra oppdragsgiver, ble kravene i hovedsak jobbet frem fra resultatene av spørreundersøkelsen og brukertestingen. I spørreundersøkelsen var det derfor spesielt viktig å stille spørsmål om hvilke funksjoner studentene ønsket. Det ble brukt en iterativ metode for å utforme kravene, og de ble endret underveis gjennom hele prosjektet. Etter gjennomført spørreunderundersøkelse og brukertesting, samt en analyse av resultatet de ga, hadde prosjektet nok grunnlag til å lage en endelig kravspesifikasjon. For å kunne fremstille kravene og for å gi et helhetlig inntrykk av systemet, ble det utformet et Use Case-diagram samt Use Case-beskrivelser. Fullstendig kravspesifikasjon presenteres i kapittel Brukertesting Det har vært en forutsetning å involvere brukerne av applikasjonen. Brukertesting og brukermedvirkning har derfor vært en viktig metode for å kartlegge om applikasjonen oppfyller brukerens behov. Med brukertesting menes det å involvere respondenter fra en målgruppe, for å gjennomføre en rekke tester av en løsning eller et produkt (Brukertest.com, udatert b). Målet med brukertestingen var å oppdage eventuelle svakheter for så å forbedre løsningen. Resultater fra brukertesting er presentert i kapittel 8. 34

35 4.4 Prototyping Prototyping er en metode som blant annet brukes til å teste forsøksutgaver av et system eller deler av det. Det skal avdekke feil og se muligheter til forbedringer. På denne måten kan man enkelt kartlegge hva brukerne vil ha, før man implementerer et ferdig produkt (Snyder, 2003). I dette prosjektet har det blitt utformet to prototyper for finne et brukergrensesnitt som gir en god brukeropplevelse Low fidelity prototype Dette er en enkel og rask form for prototyping. Low fidelity prototyper er billig å produsere, og karakteriseres ved at de er basert på papir og inkluderer skisser, illustrasjoner av brukergrensesnitt, eller storyboards. Det er enkelt å gjøre endringer, og man kan på kort tid produsere mange utkast. Denne formen for prototyping blir blant annet brukt for å teste om brukeren forstår terminologiene som er brukt, og om grensesnittet tilbyr logisk informasjon slik at brukeren kan foreta seg av de riktige valgene (Snyder, 2003) High fidelity prototype High fidelity prototyping er en digital prototype, gjerne kodet i et eller flere programmersspråk som skal brukes i det ferdige produktet. Fordelen er at man i større grad må tenke gjennom løsningen, og at man får en løsning med høy tilnærming til det ferdige produktet. En high-fidelity prototype vil også avklare den informasjon som er nødvendig for et nøyaktig teknisk kostnadsanslag tidlig i prosessen, når disse anslagene er mest nyttige (Cagan, 2010). Ulempen er at det er vanskeligere å foreta endringer, og den tar lengre tid å utforme. 35

36 Kapittel 5 Spørreundersøkelsen Spørreundersøkelsen ble utført tidlig i prosjektet. Hovedmålet med den var å få en oversikt over hvem som bruker LSBs tjenester, hvilke tjenester som benyttes mest, og hvilke tjenester som var ønskelig i en applikasjon. Spørreundersøkelsen ble sendt ut til alle fakultetene ved HiOA via mailtjenesten på Fronter. Resultatene er basert på 100 respondenter. 5.1 Om respondentene For å forsikre oss om at respondentene var et representativt utvalg av brukergruppen for EasyBib, ønsket vi å kartlegge noe bakgrunnsinformasjon om dem. Respondentene av spørreundersøkelsen hadde et aldersspenn på 18 til 51+ år, og av disse var 50% mellom 21 og 25 år. Dette var noe antatt, da de fleste som studerer ved HiOA er i denne aldersgruppen. Videre gikk 90% av respondentene i 1. til 3.klasse, mens 10% gikk i 4. til 5.klasse, eller tok opp fag. Denne fordelingen var noe ujevn, men likevel er det representativt for fremtidige brukere. Dette fordi det ved HiOA tilbys et stort flertall av års- og bachelorstudier, noe som tilsvarer 1.-3.klasse. Fordelingen mellom kjønn var også noe ujevn med et flertall av kvinnelige respondenter, her var 69 % av de om svarte på undersøkelsen kvinner og 31% menn. EasyBib er kjønnsnøytral, og fordelingen mellom kvinnelige- og mannlige respondenter er derfor ikke i stor grad relevant. Fordelingen mellom hvilke fakulteter respondentene tilhørte, var derimot mer relevant. Her var fordeling jevn, og derfor et representativt utvalg. 24% tilhørte lærerutdanning og internasjonale studier, 23% tilhørte samfunnsfag, 23% tilhørte teknologi, kunst og design, og 30% tilhørte helsefag. Grafen i Figur 18 viser fordeling mellom fakultetene. 36

37 Antall Fakultet for lærerutdanning og internasjonale studier Fordeling mellom fakultet Fakultet for samfunnsfag Fakultet for teknologi, kunst og design 30 Fakultet for helsefag Figur 18 - Viser fordelingen mellom fakultetene ved HiOA. 5.2 Resultater Spørreundersøkelsen ga svar på mye informasjon som var relevant for prosjektet. Blant annet hadde 97% av respondentene tilgang til smarttelefon eller nettbrett. Videre kom det fram at flertallet benyttet seg i hovedsak av å låne bøker, reservere bøker, se på tidsskrifter, og søke i databasene LSB tilbyr tilgang til. Det var 9% som ikke benytte seg av LSBs tjenester per dags dato, og 5% benyttet seg ikke av noen av tjenestene nevnt i spørreundersøkelsen. Grafen i Figur 19 viser en prosentvis fordeling av tjenestene som blir benyttet. 37

38 Prosent Hvilke av disse tjenestene som Læringssenteret tilbyr benytter du deg av? Figur 19 - Viser hvilke av LSBs tjenester som blir mest benyttet av studentene. For å kartlegge hvilke funksjoner og type informasjon, som var ønskelig i en applikasjon for LSB, fikk respondentene 11 alternativer å velge mellom. Alternativene var valgt ut i fra hvilken type informasjon LSB viser til på nettsiden, i tillegg til de digitale tjenestene som LSB tilbyr via nettsiden. Respondentene kunne velge 5 av de 11 valgalternativene som var satt opp, slik at man kunne få en indikasjon på hva respondentene så på som viktigst. Resultatene viste at funksjonalitetene som var mest ønskelig var; søk på bøker, reservasjon av bøker og oversikt over lån. 84% ville ha mulighet til å søke på bøker og 76% ønsket å kunne reservere bøker. Videre var det 72% som ville ha oversikt over egne lån og 63% som valgte kart med hylleplassering. Resultatet viste tydelig at det var selve tjenestene som var viktigst for respondentene. Likevel kom det fram at informasjon om åpningstider, søketjeneste i databaser og informasjon om kurs var ønsket av mellom 30-35% av respondentene. 38

39 Antall Hva slags funksjonalitet og informasjon er ønskelig i en applikasjon for Læringssenteret? (Velg maks 5 alternativer) Figur 20 - Viser hvilke funksjoner og informasjon som er ønskelig i en applikasjon for LSB. Vi ville også kartlegg om det var ønskelig med en applikasjon som tilbyr de digitale tjenestene til LSB, og ut i fra resultatene svarte 67% av respondentene at de ville benyttet seg av en slik applikasjon. 39

40 Dersom Læringssenteret hadde tilbudt en applikasjon, ville du ha benyttet deg av den? 30 % 3 % 67 % Ja Nei Vet ikke Figur 21 - Viser en oversikt over interessen for en applikasjon for LSBs tjenester. Se Vedlegg 4 for alle resultater av spørreundersøkelsen. 40

41 Kapittel 6 Kravspesifikasjon Oppdragsgiver stilte ingen krav til applikasjonen. Kravene ble basert på resultatene fra spørreundersøkelsen, brukertesting og prototyping. Kravspesifikasjonen er utformet med tanke på at løsningen skal kunne utvikles til en ferdigstilt applikasjon. I kravspesifikasjonen er ordet dokument brukt som en overordnet beskrivelse av bøker, e-bøker, tidsskrifter og e-tidsskrifter. 6.1 Overordnet systembeskrivelse Applikasjonen skal gi brukeren en oversikt over tjenestene LSB tilbyr. Det skal være mulig å søke etter bøker, reservere bøker, få en oversikt over lån, vise dato for innlevering av lånte dokumenter, fornye lån og få generell info om LSB. Det vil ikke være mulig å bruke applikasjonen til å låne dokumenter, dette fordi dokumentene er utstyrt med alarm og denne må fysisk deaktiveres på utlånsstedet. 6.2 Rammekrav Forutsetning for å bruke applikasjonen: - Bruker har tilgang til nettverk. Forutsetninger til bruker: - Bruker er student eller tilsatt ved HiOA. Bruker defineres som Låntaker i Use Case. - Bruker har smarttelefon eller nettbrett. 41

42 Administrator: - En til to ansatte ved LSB skal ha ansvar for å oppdatere og vedlikeholde applikasjonen. Administrator er definert som Systemansvarlig i Use Case. 6.3 Generelle krav Funksjonelle krav: - Applikasjonen skal støtte integrerte løsninger og funksjoner for tilgjengelighet som eksisterer på smarttelefoner, slik som invertering av farger. - Hvis en feil oppstår i applikasjonen skal en indikator vise informasjon om dette til brukeren. - Applikasjonen skal følge språkinnstillinger som er satt for smarttelefonen. o Kun tilgjengelig på norsk og engelsk. - Brukeren skal til en hver tid vite hvor han eller hun befinner seg i applikasjonen. - Brukeren skal til en hver tid ha tilgang til hovedmenyen Ikke-funksjonelle krav: - Applikasjonen skal være universelt utformet. - Applikasjonen skal oppfylle de 7 prinsippene for universell utforming. Se kapittel Brukergrensesnittet skal være enkelt og intuitivt. - Alle menyer skal ha tekst og store selvforklarende ikoner, så langt dette lar seg gjøre. - Applikasjonen skal ha et luftig grensesnitt slik at det er enkelt å trykke på linker og menyvalg. - Alle linker og trykkbare tekstfelter skal ha god margin slik at det er enkelt å treffe når de trykkes på. - Bruker må logge inn med lånetakerid og passord for å få tilgang til applikasjonen. 42

43 Alle som er registrert i BIBSYS har en låntakerid. Er du student eller tilsatt står denne på baksiden av adgangskortet ditt. Studenter ved studiested Pilestredet: hio0+studentnummer/hioa+studentnummer (eksempel: hio ). (LSB, 2011). 6.4 Spesifikke krav og egenskaper Hovedside Funksjonelle krav: - Applikasjonen skal ha en hovedside med en nyhetsfunksjon. o Administrator skal ha tilgang til å redigere nyhetsfunksjonen. - Det skal linkes til sider for Mine Lån, Søk og Info om LSB på hovedsiden Søk Funksjonelle krav: - Det skal finnes en egen side med søkefunksjon. - Det skal være mulig å søke på dokumenter LSB tilbyr utlån av. - Dokumenter skal kunne søkes på med enkelt søk og avansert søk. o Ved enkelt søk, søkes det på alle typer dokument. o Ved avansert søk skal det brukes checkbokser for å velge hva slags type dokument det skal søkes på. o Bruker kan velge å søke på en eller flere typer dokumenter. o Det skal være mulig å trykke på både checkboks og tekst for å velge type dokument. - Resultatene ved et søk listes på en ny side. 43

44 - Hvert enkelt resultat vises med tittel, forfatter, årstall og type dokument (om det er bok, e-bok, tidsskrift eller e-tidsskrift). - Ved å trykke på ett resultat skal samme informasjon som nevnt over vises, samt et kort sammendrag av dokumentets innhold, emneord og hvilken avdeling dokumentet er tilgjengelig ved. - Det skal være en funksjon for å reservere det valgte dokumentet. o Hvis et dokument er tilgjengelig for reservasjon skal det være mulig å reservere det. o Dersom et dokument ikke er tilgjengelig skal dette vises med dato for når det er forventet ledig, dersom datoen er tilgjengelig. o Det skal være mulig å se hvor det valgte dokumentet er tilgjengelig, og kart over hylleplassering. Ikke-funksjonelle krav: - Avansert søk skal være lett tilgjengelig på samme side som enkelt søk. - Det skal være god margin mellom checkboksene slik at det er enkelt for bruker å velge ønsket type dokument. - Applikasjonen skal informere bruker om et dokument er tilgjengelig for reservasjon eller ikke. - Alle resultater som listes opp skal skilles med tydelige avgrensninger Mine lån Funksjonelle krav: - Bruker skal kunne fornye eksisterende lån dersom dokumentet er tilgjengelig etter den angitte leveringsfristen. - Bruker skal kunne slette en reservasjon. Ikke-funksjonelle krav: 44

45 - Alle dokumenter som vises på Mine lån skal vises med tittel, forfatter, årstall og type dokument. - Ved å trykke på et lån (gjelder alle typer lån: aktive og reserverte), skal samme informasjon som nevnt over samt sammendrag av dokumentets innhold og emneord vises på en ny side. - Bruker skal ha oversikt over aktive lån. o Disse lånene skal ha informasjon om leveringsfrist. o Applikasjonen skal informere bruker tydelig om et eksisterende lån er tilgjengelig for fornyelse eller ikke. - Bruker skal ha oversikt over reserverte lån. o Det skal vises informasjon om hvor lenge dokumentet er reservert, det vil si når fristen for å utføre lånet hos LSB er satt. - Det skal vises tydelig om et lån er aktivt eller reservert. Disse skal grupperes etter Mine lån og Reserverte dokumenter, og de skal skilles tydelig fra hverandre. - Aktive lån sorteres etter mest nærliggende leveringsfrist (øverst). - Reserverte lån sorteres etter mest nærliggende hentefrist (øverst) Informasjon om LSB Funksjonelle krav: - Det skal finnes en egen side med informasjon om LSB. Ikke-funksjonelle krav: - Det skal finnes informasjon om låneregler. - Følgende informasjon skal finnes om alle avdelingene: o Åpningstider o Kontaktinfo o Campuskart - Det skal finnes informasjon om kurs og kurstider som LSB tilbyr. 45

46 6.4.5 Personalisering Funksjonelle krav: - Det skal finnes en egen side for innstillinger. - Bruker skal enkelt kunne endre skriftstørrelse. o Tekst skal kunne gjøres både større og mindre. - Bruker skal kunne velge mellom norsk og engelsk språk. - Alle innstillinger som blir gjort skal lagres slik at de også er gjeldende etter at bruker har lukket applikasjonen. Ikke-funksjonelle krav: - Dersom bruker har gjort endringer skal dette vises klart og tydelig Databaser LSB tilbyr tilgang til en rekke databaser. Flere av disse får studenter kun tilgang til dersom de er logget på HiOA sitt nettverk. For tilgang hjemmefra må studenter koble seg til skolens nettverk gjennom VPN. Databasesidene er eksterne tjenester, og når brukeren har valgt ønsket database vil han eller hun bli videresendt til databasens egen nettside. I mange tilfeller er ikke sidene tilpasset mobile plattformer, og funksjonen kan derfor fremstå som vanskelig å bruke på smarttelefoner. Funksjonen er inkludert med hensyn til nettbrettbrukere. Funksjonelle krav: - Det skal være en egen side hvor alle databasene LSB tilbyr tilgang til listes opp. - Når en database velges, åpnes nettsiden til den valgte databasen i smarttelefonens eller nettbrettets nettleser. Ikke-funksjonelle krav: - Databasene skal listes alfabetisk. 46

47 - Når en database velges, skal brukeren informeres om at databasens nettside vil åpnes i smarttelefonens eller nettbrettets egen nettleser Andre funksjoner - Informasjon om bruker skal ligge under Brukerkonto. o Studentnummer, tilhørighet til institutt og fakultet. - En menyliste skal være tilgjengelig gjennom hele applikasjonen med en gjenkjennbar knapp i headeren. - I menylisten skal følgene sider inkluderes o Hovedside, Databaser, Info om kurs, Innstillinger, Brukerkonto, Logg ut Use Case Jacobsen (2011) definerer en Use Case-modell som en modell over hva et informasjonssystem skal gjøre og for hvem. Modellen er et diagram bestående av brukstilfeller (Use Case), og inneholder i tillegg til diagrammet også en tekstlig beskrivelse (Hasle, 2008). Brukstilfellene er i dette tilfellet kravene som er definert til applikasjonen. Modellen visualiserer kravene og viser applikasjonens adferd (Hasle, 2008). Use Case-modellen har som hensikt å gjøre det enklere for oppdragsgiver å forstå funksjonene, for enkelt å kunne videreutvikle applikasjonen. 47

48 LSB- EasyBib fss Figur 22 - Use Case-diagram. Se Vedlegg 5 for Use Case beskrivelser. 6.6 Forslag til andre funksjoner Sveip Sveip er en funksjon som stadig blir tatt mer i bruk i mobile applikasjoner. En slik funksjon kan bidra til bedre flyt og effektivisere brukermåten i en applikasjon. Sveip brukes blant annet i forbindelse med tilgang til menylister. Horisontal sveip kan implementeres slik at bruker kan dra fingeren horisontalt fra venstre til høyre for å få tilgang til menyliste, og dra fingeren horisontalt fra høyre til venstre for å komme tilbake til hovedsiden. Stjerneordning for dokumenter Ved hjelp av en stjerneordning kan bruker markere og lagre dokumenter i egen liste. Slik kan brukeren enkelt finne frem til dokumenter som han eller hun har som favoritt, eller ønsker å låne på et senere tidspunkt. 48

49 Reserverknapp Fast reserverknapp i resultatlisten. Mulig å reservere direkte fra resultatlisten uten å måtte trykke seg inn på selve dokumentet. Historikk over tidligere lån Under Mine lån kan en oversikt over tidligere lån vises. Dette vil gi brukerne mulighet til raskt å gjenfinne tidligere lånte dokumenter. 49

50 Kapittel 7 Utviklingsprosesser 7.1 Utviklingsverktøy Oversikt over verktøy som har blitt benyttet under utviklingsprosessen. Balsamiq Mockups Balsamiq Mockups er et verktøy spesielt utviklet for low-fidelity prototyping. Med dra og dropp funksjoner var det et effektivt verktøy å bruke i første fase av utformingen til lowfidelity prototypen (balsamiq, 2013). Adobe Photoshop CS5 Alle illustrasjoner har blitt utformet ved bruk av Photoshop. Dette bilderedigeringsverktøyet var spesielt hendig ved utforming av low-fidelity prototypen, da mange av funksjonene i verktøyet kan gi en god gjengivelse av utseende til applikasjonen. Adobe Dreamweaver CS5 Dreamweaver ble brukt til å kode high-fidelity prototypen. Med en navigering kalt Live View, lar Dreamweaver deg forhåndsvise designet (CSS) av HTML koder direkte i programmet (macnn, 2010). Dette har bidratt til å effektivisere kodingen av high-fidelity prototypen. Adobe Device Central CS5 Dette programmet ble brukt i samhandling med Dreamweaver. Device Central inneholder en stor variasjon av fiktive mobile enheter. Disse mobile enhetene brukes for og forhåndsvise innholdet av kodede løsninger. I prosjektet ble Device Central brukt for å vise et realistisk bilde av en smarttelefon, og hvordan løsningen så ut på enheten. 50

51 Ved bruk av emulator var det mulig å teste funksjonaliteten i den kodede prototypen, slik de ville ha fungert på en smarttelefon i virkeligheten. (Adobe, udatert). 7.2 Utviklingsteknologier Til utvikling av den kodete prototypen ble det brukt HTML5 og CSS3. HTML er en standard som benyttes for å definere og beskrive strukturen av elementer og innhold på en nettside. CSS er en standard som definerer utseende og plassering av elementer på et nettsted (W3C, 2013a). Ved hjelp av CSS definerte vi et brukergrensesnitt som er tilpasset smarttelefoner med Android operativsystem. Standarden ble brukt til å angi farger, plasseringer og størrelser. HTML5 og CSS3 er de nyeste versjonene av standardene. 7.3 Om prototypene I prosjektet var arbeidet med prototypene under stadig utvikling. Prototypene ble basert på kravspesifikasjonen vi hadde formulert og det ble benyttet flere verktøy i prosessen. Det ble utviklet både low-fidelity og high-fidelity prototyper. Prototypene har som hovedoppgave å vise oppdragsgiver et bredt spekter av funksjoner og oppsett til EasyBib, slik at de har et solid grunnlag for videre utvikling av applikasjonen Low-fidelity prototype Arbeidet med low-fidelity prototypen startet tidlig i prosjektet. Det ble avgjort at vi skulle utforme et førsteutkast hver. Førsteutkastene ble utformet ved bruk av forskjellige metoder, det ble benyttet penn og papir, Photoshop og wireframeverktøyet Balsamiq Mockups. På denne måten oppnådde vi ulike forslag til utformingen av den endelige 51

52 prototypen til EasyBib. Vi gikk gjennom de forskjellige forslagene og valgte de som fungerte best. Figur 23 - Viser eksempler fra de forskjellige førsteutkastene av prototypene som ble utformet. Se Vedlegg 6 for alle bildene av prototypene under utvikling. Videre ble det utarbeidet en ny low-fidelity prototype i Photoshop, som viste det endelige resultatet av designet og funksjonene. Se Vedlegg 7 for fullstendig prototype. 52

53 Figur 24 - Viser et utvalg fra den endelige low-fidelity prototypen basert på førsteutkastet High-fidelity prototype Low-fidelity prototypen inneholder ingen funksjonalitet. For å gi oppdragsgiver et inntrykk i hvordan EasyBib fungere i praksis har det også blitt utviklet en high-fidelity prototype. Denne er kodet med HTML og CSS, og viser noe funksjonalitet i form av at det er mulig å trykke på knapper, og dermed komme deg stegvis inn i brukergrensesnittet. Den viser noen sider og funksjoner men går ikke inn i dybden, derav er det en bred prototype. Denne prototypen er tilpasset smarttelefoner og utviklet for Android, derfor vises den best i en smarttelefon med Android plattform. High-fidelity prototypen er tilgjengelig på: Funksjonene i prototypen Hovedside Hovedsiden i EasyBib gir brukeren tre valg. Mine lån, Søk og Info om LSB. Få valg som tilbyr de mest relevante funksjonene gjør brukergrensesnittet enkelt og oversiktlig, og det er derfor lavere sjanse for at brukeren gjør feil eller blir forvirret. Hovedsiden 53

54 viser også et annonseringsfelt, som LSB kan benytte til å fronte nyheter og informere om kurs eller lignende hendelser. Figur 25 - Viser annonseringsfelt på hovedsiden med informasjon om neste skrivekurs Menyknapp og tilhørende meny Menyknappen er, sammen med headeren, alltid synlig i applikasjonen. Det er derfor alltid mulig å komme til hovedsiden via menyen. I menyen finner brukeren Hovedside, Databaser, Brukerkonto, Info om kurs Logg av og Innstillinger. Det er ikke mulig å velge Søk, Mine lån eller Info om LSB, da det er tilstrekkelig at disse valgene befinner seg på hovedsiden i applikasjonen. Figur 26 - Viser menyknapp i header Tilbakeknapp Prototypene er som nevnt tidligere tilpasset Androids operativsystem. I den sammenheng er det ikke behov for tilbakeknapp i selve applikasjonen, da det er tilbakeknapp på smarttelefoner som kjører Android. 54

55 Figur 27 - Utsnitt av Samsung Galaxy Ace telefon som viser tilbakeknapp. (Skjermdump hentet fra: 10.mai 2013). Om det skulle være ønskelig er det likevel mulig å legge inn denne funksjonen. Dersom EasyBib utvikles for ios vil en tilbakeknapp være nødvendig da iphone ikke tilbyr dette. En tilbakeknapp vil gjøre det mulig for brukeren å gå ett steg tilbake, altså til forrige side. Figur 28 - Viser to forslag på implementert tilbakeknapp i EasyBib Søkefunksjonen I den kodede prototypen er det ikke mulig å foreta søk. Siden det er en prototype og ikke en fullt utviklet applikasjon er ikke søkefunksjonen tilkoblet LSBs biblioteksdatabase. 55

56 Kapittel 8 Brukertesting 8.1 Hensikt med brukertesting Brukertesting har vært svært viktig, da dette har vært med på å avgjøre og definere de endelige prototypene. Ved å gjennomføre brukertester har vi sett brukerens opplevelse av EasyBib, og hvordan brukerne oppfatter funksjonene. Det ble gjennomført to runder med brukertesting, hvor det ble gitt konkrete oppgaver etterfulgt av oppfølgingsspørsmål. Ved å bruke konkrete oppgaver fikk vi resultater som lettere kunne sammenlignes. I forkant av brukertestingen ble det holdt et møte for å planlegge testingen, samt utformet en testplan. Se Vedlegg 8 for testplan. Under brukertestingen ble én og én testperson invitert til testrommet og bedt om å utføre forhåndsbestemte oppgaver. Det var viktig å presisere at det var systemet som skulle testes og ikke testpersonen. Testpersonen ble observert og det ble tatt notater. Det ble siden skrevet en oppsummering av hver brukertest, og tilslutt en oppsummering av de samlede resultatene. Resultatene ble analysert og det ble diskutert forbedringsforslag. 8.2 Testmiljø Testene ble gjennomført på et grupperom ved HiOA, 6.mai Alle HiOAs lokaler regnes som vante omgivelser for en bruker av systemet. 56

57 8.3 Personer tilstede under brukertesting Testperson Testpersonene skulle ved hjelp av en prototype utføre oppgaver som var forhåndsbestemt av prosjektgruppen. Testleder Testlederens jobb var å forsikre at brukertestingen gikk som planlagt. Det vil si at tidskjemaet og testplan ble fulgt, og at alle involverte parter utførte sine oppgaver riktig. Testlederen skulle gripe inn dersom testpersonen ikke klarte å løse en oppgave. Observatør Observatøren skulle observere testpersonene og notere seg hvordan han eller hun samhandlet med løsningen. Maskinstyrer Det ble brukt en ikke-funksjonell prototype under brukertestingen. Maskinstyrerens oppgave var derfor å fungere som hjernen til systemet, ved å utføre alle handlingene til systemet for å simulere en fungerende applikasjon. 8.4 Krav til testperson Da det ble valgt ut testpersoner til bruketestingen, ble det tatt utgangspunkt i målgruppen til EasyBib. Dette er i hovedsak studenter, men EasyBib skal også kunne brukes av ansatte ved HiOA. Det var derfor viktig at testpersonene hadde variasjon i alder og dataferdigheter. Krav til ferdigheter - Grunnleggende kjennskap til mobile enheter som benytter seg av touchteknologi. - Kjennskap til native applikasjoner tilpasset mobile enheter. 57

58 Demografiske krav - Én under 25 år - Én over 50 år - Jevn fordeling mellom kjønn. 8.5 Personvern I forbindelse med brukertestingen ble det utarbeidet en samtykkeerklæring. Den informerte testpersonene kort om brukertesten og testpersonenes rettigheter i forbindelse med testingen. Alle testpersonene som deltok signerte denne avtalen. Se Vedlegg 9 for samtykkeerklæring Oppgaver løst under bruketesten Søke etter en bok Reservere en bok Navigere seg tilbake til hovedsiden Finne oversikt over brukerens nåværende lån Fornye et eller flere lån Finne oversikt over databasene LSB tilbyr tilgang til I tillegg til disse oppgavene ble det stilt åpne oppfølgingsspørsmål etter fullført test for å få et bedre innblikk i hvordan brukeren opplevede EasyBib. 8.7 Oppfølgingsspørsmål etter utført brukertest Hvordan opplevde brukeren EasyBib? Hva synes brukeren om begrepene og kategorinavnene som er brukt i EasyBib? 58

59 Hva synes brukeren om EasyBibs utseende og fargevalg? Er det noe spesielt brukeren vil påpeke med EasyBib, (positivt/negativt)? 8.8 Uformelle tester Det ble utført to pilottester i forkant av selve brukertestingen. Disse ble utført for å se hvordan testplanen fungerte i praksis, og om oppgaven lot seg løse. De hadde også som hensikt å gi testleder, observatør og maskinstyrer mulighet til å øve på oppgavene sine før de faktiske brukertestene. Pilottestene ble brukt som grunnlag til å lage et tidsskjema for brukertestingen. 8.9 Formelle tester Hvert medlem i prosjektgruppen hadde en rolle under brukertestingen, disse var testleder, observatør og maskinstyrer. For å ikke forvirre testpersonen foregikk all kommunikasjon under brukertestingen mellom testperson og testleder. Innspill fra mange parter kan virke forvirrende, og det kan gjøre det vanskelig å se hvordan testpersonen naturlig samhandler med prototypen. Det ble totalt foretatt syv formelle tester med syv forskjellige testpersoner. Figur 29 - Bilder tatt under brukertestingen. 59

60 8.10 Endringer gjort i prototypen etter de uformelle testene Under pilottestene ble det oppdaget noen mangler ved prototypen som ble rett opp før de formelle testene. Det var blant annet ingen direkte måte for brukeren å navigere seg tilbake til hovedsiden. Brukeren var avhengig av å bruke tilbakeknappen på smarttelefonen for manuelt å trykke én og én side tilbake. Det ble derfor tilført en snarvei i menypanelet kalt Hovedside som førte brukeren tilbake til hovedsiden. Se Figur 30. Videre ble det også bestemt at brukeren skulle få bekreftelse på sine handlinger i form av varselbokser. Disse vises når en bruker reserverer et dokument eller fornyer et lån. Se Figur 30. Figur 30 - Viser menyen etter endring, og varselboks. 60

61 Søke etter en bok Reservere en bok Navigere seg tilbake til hovedsiden Finne oversikt over brukerens nåværende lån Fornye et eller flere lån Finne oversikt over databasene LSB tilbyr tilgang til 8.11 Resultat av brukertestingen Observatøren vurderte oppgavene etter disse kriteriene: Enkel Oppgaven ble løst på første forsøk Medium Oppgaven ble løst men testpersonen var nølende. Vanskelig Oppgaven ble løst, men brukeren prøvde ut andre alternativ før de kom frem til rett løsning. Fullført med hjelp Oppgaven ble løst, men med hint fra testleder. Ikke fullført Oppgaven ble ikke fullført. Resultatet av brukerundersøkelsen viste at tre av seks oppgaver var enkle å løse, og under to av oppgavene var det kun én som var litt nølende. Ingen av testpersonene trengte hjelp til å fullføre noen av oppgavene, og alle testene ble fullført i sin helhet. Figur 31 viser en oversikt over de samlede resultatene. 100 % 90 % 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % 0 % Enkelt Medium Vanskelig Fullført med hjelp Ikke fullført Figur 31 - Oversikt over de samlede resultatene fra første runde med brukertesting. 61

62 Nedenfor følger et sammendrag fra alle oppgavene som ble løst, sammen med tilbakemeldinger fra testpersonene. Søke opp en bok Alle testpersonene løste denne oppgaven på første forsøk uten å nøle. Dette viste at søkefunksjonen funger godt og er enkel å forstå for brukeren. Reservere en bok Reserver-funksjonen henger sammen med søkefunksjonen, da man er nødt til å søke opp et en bok for å kunne reservere den. Én av testpersonene nølte litt før han eller hun forsto at man måtte trykke på boken i søkeresultatet, for å kunne reservere den. En annen testperson stusset over navnet Reserver dokument. Navigere seg tilbake til hovedsiden Det oppstod noe forvirring under denne oppgaven. To av testpersonene trykket først på headeren, før de forsto at de skulle trykke på menyknappen til venstre i headeren. Det var også to testpersoner som kikket rundt på prototypen, før de forsto hvor de skulle trykke. Under oppfølgingsspørsmålene ble det nevnt av flere testpersoner, at brukere kunne stusse over dette den første gangen de brukte applikasjonen. Problemet ville forsvinne ved andregangsbruk. Én av testpersonene nevnte at det var for mange menyvalg i menyen. Finne oversikt over sine nåværende lån Denne oppgaven ble løst raskt og på første forsøk av alle testpersonene. Det viste at funksjonen fungerer godt. Fornye et eller flere lån Oppgaven ble løst uten problem av alle testpersonene. Dette var en bekreftelse på at også denne funksjonen fungerer godt. 62

63 Finne oversikt over databasene LSB tilbyr tilgang til Under denne oppgaven var det kun én testperson som var litt nølende på hvor han eller hun skulle trykke. De resterende seks klarte oppgaven på første forsøk. Det ble nevnt at hvis man ikke vet at LSB tilbyr tilgang til databaser, kan menyvalget "Database være forvirrende og vagt Oppfølgingsspørsmål Under oppfølgingsspørsmålene kom det frem mange like svar. Det ble blant annet nevnt av alle testpersonene at EasyBib var enkel og intuitiv i bruk. Flere mente at det var vanskelig å gjøre feil, og at applikasjonen hadde et friskt utseende. Det kom også fram at bruken av kontrastfarger samt store knapper gjorde det enkelt å navigere seg rundt Endringer gjort i prototypen etter de formelle testene Etter funnene i de formelle testene beskrevet ovenfor, ble problemene som oppsto grundig diskutert. Endringer ble foretatt i prototypen. Problem: Brukeren forsto ikke at man skulle trykke på menyikonet til venstre i headeren for å komme tilbake til hovedsiden. Løsning: La til en strek mellom logoen og menyknappen som tydeliggjør at det er en knapp i headeren. Figur 32 - Viser endring i header. 63

64 Problem: Menyvalget Databaser kan virke forvirrende for brukere som ikke vet at LSB tilbyr tilgang til databaser. Løsning: Ved å trykke på menyvalget Databaser kommer brukeren først til en introduksjonsside som forklarer hva man finner på siden. Figur 33 - Viser introduksjonsside. Problem: For mange valg i menyen. Løsning: Det ble kuttet ned på menyvalgene. Både Campuskart og Åpningstider ble fjernet fra menyen, og informasjonen ble plassert under Info om LSB som finnes på hovedsiden. Det kom også fram noen forslag til forbedringer. Navnet Reserver dokument ble endret til Reserver. De andre forslagene vil ikke implementeres i vår prototype, men en oversikt over disse kan ses i kapittel 6.6 Forslag til andre funksjoner. Slik informasjon er viktig for oppdragsgiver ved eventuell videreutvikling av applikasjonen. 64

65 8.12 Konklusjon av brukertestingen Basert på resultatene av brukertestingen, konkluderes det med at prototypen gir et godt utgangpunkt for applikasjonen. Testpersonene samhandlet med prototypen på en enkel måte, og det var små endringer som ble foretatt i prototypen etter brukertestingen, se punkt Endringer gjort i prototypen etter de formelle testene. Gjennom oppfølgingsspørsmålene kom det fram verdifull informasjon. Dette i form av bekreftelse om at det hadde blitt tatt riktig valg når det kom til design og fargevalg, funksjoner som er i applikasjonen og brukergrensesnitt Brukertesting 2.0 Den første runden av brukertesingen avslørte noen mangler ved prototypen, se Endringer gjort i prototypen etter de formelle testene. Prototypen ble derfor endret og en ny runde med brukertesting ble gjennomført. Dette var en noe kortere brukertest gjennomført på tre testpersoner. Testpersonene var to medstudenter samt en mann over 50 år. Dette ble gjort for å kontrollere om endringene som ble foretatt under første runde av brukertestingen var gode tiltak for problemene Funksjonalitet som ble testet Om brukeren forsto hvor menyen i EasyBib var. Om brukeren klarte å navigere seg rundt i EasyBib Oppgaver som ble gjennomført under brukertestingen Søke opp en bok o Suksesskriteria: Brukeren klarer å søke opp en bok Navigere seg tilbake til hovedsiden. 65

66 o Suksesskriteria: Brukeren klarer å navigere seg tilbake til hovedsiden, ved hjelp av menyen. Finne oversikt over databasene LSB tilbyr tilgang til. o Suksesskriteria: Brukeren finner oversikten over databasene LSB tilbyr tilgang til Resultat av brukertestingen 2.0 Søke opp en bok Denne oppgaven ble lagt inn som et grunnlag for oppgave to, Navigere seg tilbake til hovedsiden. I likhet med første runde av brukertestingen, ble denne oppgaven utført på første forsøk av alle testpersonene. Navigere seg tilbake til hovedsiden Under denne oppgaven var det spennende å se om testpersonene, på første forsøk, klarte å få opp menyen. Alle de tre testpersonene fullførte oppgaven på første forsøk. På grunnlag av dette anses tiltaket som suksessfullt og funksjonen fungerer godt. Finne oversikt over databasene LSB tilbyr tilgang til Denne oppgaven ble utført på første forsøk av alle testpersonene. Det konkluderes derfor med at denne funksjonen fungerer godt Konklusjon av brukertesting 2.0 Denne runden med brukertesting ga en bekreftelse på at prototypen var på god vei, og er et godt grunnlag som egner seg for videre utvikling. Alle testpersonene løste oppgavene på første forsøk. Det bekreftet at endringene som ble gjort i prototypen etter første runde med brukertesting, faktisk førte til forbedringer. 66

67 Se Vedlegg 10 for en samlet oversikt over resultatene fra begge rundene med brukertesting. 67

68 Kapittel 9 Sluttprodukt Utformingen av prototypene var en pågående prosess under hele prosjektet, og små og store endringer ble gjort ofte. Prosessen har vært iterativ, det vil si at vil har gjort endringer, testet og vurdert løsningen, og gått tilbake for å gjøre endringer igjen. Endringsprosessen har hatt forskjellige utgangspunkt etter hvor i prosessen prosjektet har vært. I starten var det våre tanker og meninger, sammen med designprinsipper og retningslinjer for universell utforming og tilgjengelighet, som la grunnlaget for utseendet og brukergrensesnittet. Videre ble endringer gjort med bakgrunn i resultatene fra pilottesting og brukertesting. Det ble gjort flere vurderinger og endringer av low- fidelity prototypen før vi endte med en ferdig prototype til brukertesting. 9.1 Low-fidelity prototype Brukertestingen ble utført med low-fidelity prototypen. Etter gjennomført brukertesting kom det frem en del som måtte endres i prototypen. Vi hadde stor nytte av tilbakemeldingene vi fikk, og mener at vi bedret løsningene i EasyBib. Brukertestene viste at grunnlaget i prototypen var bra, men at det var nødvendig med noen forbedringer. Når det gjaldt designet og fargevalgene fikk vi gode tilbakemeldinger, og de fleste funksjonene var lette å forstå for testpersonene. Se Vedlegg 7 for fullstendig low-fidelity prototype. 9.2 High-fildelity prototype High-fidelity prototypen er kodet med utgangspunkt i low-fidelity prototypen. Endringene i denne har derfor blitt utført noe senere i prosjektet. Vi startet tidlig med grunnlaget for denne prototypen, men den ble ferdigstilt sist. Etter hvert som endringer i low-fidelity prototypen ble gjort, tilpasset vi den kodede prototypen. 68

69 9.3 Konklusjon Sluttproduktene våre er i form av en low-fidelity og en high-fidelity prototype, og begge er viktige for prosjektet. Gjennom low-fidelity prototypen fikk oppdragsgiver et bredt innblikk i hvordan EasyBibs mange sider kan utformes. Den er utformet med utgangspunkt i kravene, se kapittel 6 Kravspesifikasjon, og sammen med disse legger prototypen grunnlaget for videre utvikling av EasyBib. High-fidelity prototypen gir et innblikk i funksjonene, for at oppdragsgiver skulle få en oversikt over hvordan det er tenkt at applikasjonen skal fungere. Sluttproduktene gir et godt grunnlag for videre utvikling av EasyBib. Oppdragsgiver får en godt dokumentert løsning, som viser et bredt spekter av funksjonalitet og utforming av brukergrensesnitt og design. Ved hjelp av prototypene og kravspesifikasjonen kan applikasjonen utvikles i helhet. Beskrivelsene gjort løpende gjennom prosjektet skal svare på de utfordringene som finnes ved utvikling av tilgjengelige løsninger. 69

70 PROSESSDOKUMENTASJON Det vil i følgende kapitler bli gjort rede for prosessen i prosjektgjennomføringen. Her er det beskrevet hvordan prosessen fra idé til produkt har utviklet seg, og det er gitt en evaluering av gjennomførelsen. Siste kapittel er en konklusjon for selve prosjektgjennomføringen. Kapittel 10 Planlegging og metoder 10.1 Prosess I oppstartsfasen til prosjektet ble det utformet en milepælsplan i form av et Ganttdiagram. Denne ble brukt til å overvåke fremgangen i prosjektet, og sørge for at prosjektets tidsramme ble holdt. Se Vedlegg 11 for Gantt-diagram. Det ble også utformet en risikoanalyse for håndtering av eventuelle risikoer som kunne oppstå under prosjektets levetid. Se Vedlegg 12 for risikoanalyse. Milepælsplanen la grunnlaget for å utarbeide en arbeidsplan, se Vedlegg 13 for arbeidsplan. Arbeidsplanen tok for seg ukentlig hva som skulle bli gjort, og vi brukte den som et utgangspunkt for å ukentlig strukturere hvem som skulle gjøre hva. Underveis så vi at det hadde blitt satt for liten tid til visse oppgaver, og vi valgte derfor å starte med disse oppgavene tidligere. Et eksempel på dette var kapittelet om brukeropplevelse og design, som i følge arbeidsplanen skulle bli skrevet i uke 20, men som vi valgte å begynne på tidligere. Videre ble det ført en prosjektdagbok på prosjektnettsiden for hver arbeidsdag. På denne måten kunne vi i senere anledninger gå tilbake og se hva som hadde blitt gjort i de forrige ukene. Se Vedlegg 14 for utdrag fra prosjektdagbok. 70

71 Vi hadde ukentlige møter med vår interne veileder, Kirsten Ribu. Her diskuterte vi fremgangen til prosjektet, men mest av alt hvilke temaer det var viktig å belyse, og hvilke temaer som var mindre relevante for prosjektet. Det ble utenom veiledningsmøtene, holdt noe kontakt med vår interne veileder gjennom e-post. Det ble også holdt ett møte med vår eksterne veileder, Tanja Strøm, og ett møte med hennes kollega, Elin Stangeland, i starten av prosjektet. Med bakgrunn i at LSB ikke ønsket å legge styringer for oss, ble det lite kontakt med oppdragsgiver videre i prosjektet. I dette prosjektet har det vært viktig å involvere sluttbrukeren, og vi har ønsket å kunne gå tilbake i prosessen og endre premissene. Vi har derfor brukt en iterativ utviklingsmetode, som er en metode hvor tilbakemelding fra sluttbrukeren har påvirkning på utviklingen av produktet. Ved å bruke prototyping som metode, har vi enkelt kunnet gjøre endringer i produktet underveis i prosjektet Rammebetingelser Tid Prosjekt startet 7. januar 2013 og sluttet 28. mai I løpet av disse månedene skulle prosjektet gjennomføres, og sluttdokumentasjon innleveres til sensur. Tidsrammen kunne ikke påvirkes, da den var fastsatt av Høgskolen i Oslo og Akershus. Ressurser Ressursene som var tilgjengelig under prosjektet var intern og ekstern veileder, prosjektgruppen, samt litteratur fra bøker og Internett. 71

72 10.3 Prosessverktøy Det har i dette prosjektet blitt benyttet følgende tekniske verktøy som hjelpemidler under prosessen til prosjektet. WhatsApp En mobilapplikasjon som tillater å ha gruppesamtaler. Applikasjonen ble brukt som et kommunikasjonsverktøy mellom prosjektgruppens medlemmer. Applikasjonen krever nettilgang. Dropbox Dropbox er en tjeneste som lar deg lagre dokumenter og andre filer på en server, slik at du kan få tilgang til disse via Internett (mobili.no, 2011). Det er mulig å lage mapper som man deler med andre, slik at man har tilgang til hverandres dokumenter. Dette verktøyet ble brukt til å dele alt arbeid som ble gjort, slik at prosjektgruppa til en hver tid hadde tilgang til alle prosjektdokumentene. Google docs Google docs er et verktøy som brukes til å lagre og dele dokumenter over web. Flere personer kan ha tilgang til et dokument, og det er mulig for alle brukerne å skrive i det samme dokumentet samtidig. Word En teksteditor. Brukt til å skrive og formatere prosjektdokumentasjonen. Excel Excel er et regnearkprogram. Brukt til å fremstille grafer, samt beregne og analysere data. Gliffy En online diagrameditor. Verktøyet ble brukt til å lage use case-diagram. 72

73 Kapittel 11 Evaluering En evaluering av arbeidet som har blitt gjort, og utfordringer som har vært i gjennomføringen av prosjektet. Planlegging av prosessen Ved hjelp av prosjektdagbok, arbeidsplan og risikohåndtering, har det vært mulig å planlegge prosessen på en effektiv måte. Frister har blitt overholdt, og arbeidet har blitt jevnt fordelt. Prosjektgruppen har hatt god kommunikasjon, og vi har jobbet godt både selvstendig og sammen. Ved å bruke Dropbox og WhatsApp har vi kommunisert innad i gruppen, og hatt tilgang til alle dokumenter relevant for prosjektet. Dette ga oss frihet til å kunne jobbe selvstendig. Ikke spesifisert kravspesifikasjon fra oppdragsgiver Det ble ikke spesifisert en kravspesifikasjon fra oppdragsgiver i dette prosjektet. Med de tidsbegrensingene som gjaldt for prosjektet, hadde dette vært en klar fordel. Likevel lærte vi masse av prosessen, og det ga oss mye frihet når det kom til utviklingen av sluttproduktet. Universelt utformet design Prosjektet har hatt stort fokus på universell utforming. Vi har dratt nytte av at vi har noe erfaring innenfor feltet, men vi har også lært mye nyttig underveis i prosessen. Under utviklingen av selve produktet, var det viktig at vi tenkte nøye gjennom design- og fargevalg. Slik fikk vi et produkt som på best mulig måte var tilpasset alle type brukere. Selv om fokuset på et universelt utformet sluttprodukt har satt noen begrensinger når det kommer til kreativitet, har det vært en lærerik utfordring. 73

74 Begrenset ferdighet innenfor koding Vi i prosjektgruppen valgte å utfordret oss selv ved å lage en kodet prototype, selv om vi ikke har mye erfaring innenfor feltet. Det ble valgt å benytte seg av hjelpeverktøy slik som Adobe Device Central og Adobe Dreamweaver, for å få en løsning som er tilpasset mobile enheter. Vi brukte derfor noe tid på å lære å bruke disse verktøyene, før vi kunne begynne å kode. Prosessen ble derfor noe mer tidkrevende en forventet. Tildeling av roller Det ble i starten av prosjektet tildelt roller til de forskjellige gruppemedlemmene. Disse var prosjektleder, dokumentansvarlig og teknisk ansvarlig. Prosjektleder hadde som ansvar å ta kontakt med intern- og eksternveileder når dette trengtes, samt ha en oversikt over prosjektets fremgang. Dokumentansvarlig hadde som ansvar å se til at alle prosjektets dokumenter var tilgjengelige, og at avsatte tidsfrister for arbeid ble overholdt. Teknisk ansvarlig hadde som oppgave å oppdatere prosjektnettsiden og hovedansvaret for den kodete prototypen. Prosjektet har blitt sett på som en viktig læringsprosess og det har vært viktig å inkludere alle gruppemedlemmer i alle deler av prosjektet. De offisielle rollene har derfor blitt brukt til å tildele et hovedansvar til hvert gruppemedlem, mens arbeidsmengden har blitt jevnt fordelt. 74

75 Kapittel 12 Konklusjon Prosjektet har vært en utfordrende læringsprosess og prosjektgruppen har lært mye innenfor prosjekthåndtering og arbeidsmetoder. Prosjektet har bydd på utfordringer som har vært spennende å løse, og vi har fått bruk for mye av det vi har lært de årene vi har gått på høgskolen. Det har vært spennende å jobbe med et prosjekt som har hatt mye fokus på universell utforming og tilgjengelighet, da dette er viktige temaer som blir mer og mer relevante. Det har vært interessant å jobbe med teknologi tilpasset smarttelefoner. Vi har fått innblikk i hvordan det er å jobbe med konseptutvikling og planlegging innenfor en iterativ utviklingsmetode. Oppdragsgiver har stilt få krav til prosjektet, og vi har jobbet svært fritt. Dette har ført til at vi har fått prøve oss på mange områder innenfor produktutvikling, slik som kartlegging, analyse av data, brukertesting, prototyping, og brukervennlighet. EasyBib står åpen for fremtidige endringer, og skal enkelt kunne bli utviklet til et ferdigstilt og funksjonelt produkt. Alt i alt er vi fornøyde med egen innsats og prosjektets resultat. 75

76 REFERANSELISTE Adobe. (udatert). Adobe Device Central CS5 & CS5.5. Hentet 8. mai 2013 fra: B6E8-56F88AED8511a.html balsamiq. (2013). Balsamiq Mockups. Hentet 12. mai 2013 fra: BIBSYS. (udatert). BIBSYS. Hentet 3.april 2013 fra: Brukertest.com. (udatert a). Brukervennlighet. Hentet 4. mai 2013 fra: Brukertesting. (udatert b). Hva er brukertesting. Hentet 2. mai 2013 fra: Bufetat. (2013, 28. januar). Hva er universell utforming av Kristin Bille. Hentet 1. mai 2013 fra: Bufetat. (udatert). Råd for mennesker med nedsatt funksjonsevne. En håndbok med informasjon og veiledning. Hentet 01. mai 2013 fra: _Rad_for_mennesker_med_nedsatt_funksjonsevne_handbok.pdf Cagan, M. (2013, 7. oktober). Top Ten Benefits of a High-fidelity Prototype. Hentet 7. april 2013 fra: ComputerUser. (udatert a). Command-driven. Hentet 4. mai 2013 fra: ComputerUser. (udatert b). GUI graphical user interface. Hentet 4. mai 2013 fra: Direktoratet for forvaltning og IKT [Difi]. (2013, 26. april). Universell utforming. Hentet 28. april 2013 fra: GSMArena (udatert). Samsung Galaxy Ace S5830 pictures. Hentet 10. mai 2013 fra: Hasle, T. E. (2008). Systemutvikling. Oslo: Cappelen Damm. 76

77 Jacobsen, I., Spence, I. & Bittner, K. (2011). Use Case 2.0. Hentet 19. mai 2013 fra: JFK-Computing. (udatert a). Menu driven user interface example. Hentet 4. mai 2013 fra: JFK-Computing. (udatert b). Commando line user interface examples. Hentet 4. mai 2013 fra: JFK-Computing. (udatert c). GUI (Graphical User Interface). Hentet 4. mai 2013 fra: Lovdata. (2013, 29. april). Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne (diskriminerings- og tilgjengelighetsloven). Hentet 1. mai 2013 fra: macnn. (2010, 22. oktober). Reveiw: Adobe Dreamweaver CS5. Hentet 6. mai 2013 fra: Mehran, R. (udatert). Krav til universell utforming av offentlige nettsider. Hentet 8. mai 2013 fra: Mobili.no (2011, 28. januar). Her er tidenes beste app. Hentet 13. mai 2013 fra: Norsk Designråd. (2007, 19. november). Prinsipper for Design for alle. Hentet 26. april 2013 fra: Plos, O & Buisine, S. (2006). Universal design for mobile phones: A case study doi: / Sandnes, F. E. (2011). Universell utforming av IKT-systemer. Oslo: Universitetsforlaget. Snyder, C. (2003). Paper Prototyping. San Francisco: Elsevier. snook.ca (2009). Colour contrast check. Hentet 17. april 2013 fra: Sourceforge (2013, 10.mai). FileZilla. Hentet 13. mai 2013 fra: Toftøy-Andersen, E., & Wold, J. G. (2011). Praktisk Brukertesting. Oslo: Cappelen Damm Akademisk. 77

78 Universell utforming Difi. (udatert). Hva er universell utforming. Hentet 15. april 2013 fra: Universitetsbiblioteket ved UiO (udatert). Brukerdrevet innovasjon. Hentet 17. april 2013 fra: Universitetsbiblioteket ved UiO (2012, 12. november). Frokostmøte: Studentene tar styringa med bibliotek-app. Hentet 17. april 2013 fra: W3C. (2013 a). HTML & CSS. Hentet 24. april 2013 fra: W3C. (2013 b). Accessability. Hentet 1. mai 2013 fra: W3C. (2013 c). Web content accessibility guidelines (WCAG) current status. Hentet 15. april 2013 fra: 78

79 VEDLEGG Vedlegg 1 Oppgavetekst Studentdrevet innovasjon. Hva skjer når brukerne får mulighet til å utvikle bibliotektjenester for brukerne når studenter utvikler løsninger for studenter? Læringssenteret ved studiested Pilestredet ønsker at studenter skal se på virksomheten med friske øyne, og foreslå nye løsninger for de digitale tjenestene. På universitetet i Oslo har studenter lagget apper for Universitetsbiblioteket. ( Læringssenteret ønsker å få til noe lignende på Hioa. Det kan det være snakk om flere studentprosjekter, og omfatte bla prototyping og utvikling av Apper. Løsningene skal være tilgjengelige for alle, og universelt utformet. Bakgrunnsinformasjon: Læringssenter og bibliotek (LSB) har en lang rekke digitale tjenester som skal støtte undervisning og forskning ved HiOA. Vi bruker flere millioner kroner årlig på tilgang til databaser med innhold fra en rekke tidsskrifter. Vi har tilgang til mange e-bøker og andre informasjonskilder. HiOA publiserer seks vitenskapelige tidsskrifter som ligger på en plattform som er satt opp av LSB, og vi har flere arkiver med innhold produsert av tilsatte og studenter ved HiOA. En av fem nordmenn bruker nå medieinnhold på mobile plattformer daglig. Norge er et land på nesten fem millioner mennesker. Norge og de andre skandinaviske landene er teknologisk avanserte - og befolkningen er generelt ansett for å være tidlig ute med å ta i bruk ny teknologi. Overgangen fra PCer til bruk av mobile plattformer drives frem av smarttelefoner og Ipad (og andre lesebrett/nettbrett). Plutselig har folk begynt å bruke sine mobiltelefoner til å surfe på nettet. Mobilmanifestet - hvorfor satser Læringssenteret på mobiltjenester?: På nettsidene finner dere våre tjenester: Kontakt Tanja Strøm Leder, Lsb-Digitale tjenester Tanja.Strom@hioa.no 79

80 Vedlegg 2 Kontrasttester Kontrasttester gjort før endring av farger: Kontrasttester gjort etter endring av farger: 80

81 81

82 Vedlegg 3 Spørreundersøkelsen Følgende tekst ble sendt med spørreundersøkelsen: Hei! I forbindelse med vårt hovedprosjekt ber vi deg om å svare på en kort spørreundersøkelse, det vil ta 2 min. Vi skal lage en applikasjon (app) for Læringssenteret som skal kunne brukes på smarttelefoner og nettbrett. Spørsmål: 1. Alder Kjønn Mann Kvinne 3. Hva studerer du? (skriverute) 4. Hvilket år går du? 1.klasse 2.klasse 3.klasse 4.klasse 5.klasse Tar opp fag Annet 5. Har du tilgang på et nettbrett eller smarttelefon? Ja Nei 6. Hvilke av disse tjenestene som læringssenteret tilbyr benytter du deg av? Låne bøker Reservere bøker Se på tidsskrifter Søke i databaser Bestill bibliotekar 82

83 Søkehjelp Kurs eller lynkurs Benytter meg ikke av læringssenterets tjenester. 7. Hvordan synes du det er å finne informasjon om Læringssenterets tjenester? Veldig enkelt Enkelt Middels Vanskelig Veldig vanskelig 8. Hvilke av tjenestene i listen under, er du klar over at Læringssenteret tilbyr: Skrivekurs Skrivementor Lynkurs (bl.a i EndNote) Databaser over fagrelaterte artikler, ny forskning og andre nettressurser ODA - institusjonelt arkiv som inneholder masteroppgaver, doktoravhandlinger og vitenskapelige artikler av tilsatte Utleie av AV-utstyr (diverse video og lydutstyr) 9. Hva slags funksjoner/informasjon ville du skulle vært tilgjengelig i en eventuelt applikasjon? (Lag en prioritet liste fra 1 til 5) Søke etter bøker Kart over hylleplassering for ønsket bok. Reservere bøker Brukerens søkshistorikk. Brukerens favoritter Bestille artikler Oversikt over brukerens egne lån. Info om låneregler Info om LSBs åpningstider Kontaktinfo Info om kurs Kurstider Søketjenesten i databaser Annet (kan krysses av og definere annet) 10. Dersom læringssenteret hadde tilbydd en applikasjon, ville du ha benyttet deg av den? Ja Nei Vet ikke 83

84 Antall Vedlegg 4 Resultatene av spørreundersøkelsen fremstilt i grafer Alder Kjønn Mann 31 % Kvinne 69 % 84

85 Antall Antall Hva studerer du? (Eks. Administrasjon og ledelse) Fakultet for lærerutdanning og internasjonale studier Fakultet for samfunnsfag Fakultet for teknologi, kunst og design Fakultet for helsefag 4. Hvilket år går du? klasse 2. klasse 3. klasse 4. klasse 5. klasse Tar opp fag Annet 85

86 Antall 5. Har du tilgang på et nettbrett eller smarttelefon? 6% Ja Nei 94% Hvilke av tjenestene i listen under er du klar over at Læringssenteret tilbyr?

87 Antakk Antall Hvordan synes du det er å finne informasjon om Læringssenterets tjenester? Veldig enkelt Enkelt Middels Vanskelig Veldig vanskelig Hvilke av disse tjenestene som Læringssenteret tilbyr benytter du deg av?

88 Antall Hva slags funksjonalitet og informasjon er ønskelig i en applikasjon for Læringssenteret? (Velg maks 5 alternativer) Dersom Læringssenteret hadde tilbudt en applikasjon, ville du ha benyttet deg av den? 30 % 3 % 67 % Ja Nei Vet ikke 88

89 Vedlegg 5 Use Case-beskrivelser Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Søke på et dokument. Låntaker Smarttelefon eller nettbrett. Låntaker ønsker å finne et dokument i læringssentrets register. Låntaker må være student eller ansatt ved HIOA. Informasjon om dokumentet det er søkt på kommer opp. 1) Systemet ber brukeren skrive inn tittel, forfatter eller emne. 2) Låntaker skriver inne sitt behov i søkefeltet. 3) System viser informasjon om dokument. Variasjoner 2.1 Brukeren har ikke skrevet inn tekst i søkefeltet. 2.2 System viser feilmelding, og ber låntaker skrive inn tekst. 2.3 Bruker skriver inn tekst i søkefeltet. 2.4 System viser informasjon. 3.1 Dokumentet finnes ikke i læringssenterets register. 3.2 System viser en melding hvor det står at dokumentet ikke finnes i læringssenterets register. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Reserver dokument. Låntaker Smarttelefon eller nettbrett. Låntakeren ønsker å reservere et dokument i læringssentrets register. Låntakeren har søkt og funnet et dokument som han eller hun ønsker å reserver. Dokumentet blir reservert i låntakerens navn. 89

90 Normal hendelsesflyt Variasjoner 1) Låntakeren finner frem dokumentet som er ønskelig å reserver. 2) Systemet reserverer dokument i låntakerens navn. 1.1 Dokumentet kan ikke reserveres 1.2 Systemet gir låntakeren ingen mulighet til å reservere, og dokumentet lar seg ikke reservere. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Se oversikt over tidligere lån. Låntakeren Smarttelefon eller nettbrett. Låntakeren ønsker å se historikk for sine tidligere lån. Låntakeren må være student eller ansatt ved HIOA. Historikk over tidligere lån vises. 1) Systemet viser en oversikt over brukerens nåværende lån, reserverte dokumenter og tidligere lån. 2) Brukeren scroller ned til oversikten over tidligere lån. Variasjoner 2.1 Bruker har ingen tidligere lån 2.2 Ruten under Tidligere lån et tom. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Se oversikt over nåværende lånte dokumenter. Låntaker Smarttelefon eller nettbrett. Låntakeren ønsker å se oversikt over sine nåværende lån. Låntakeren må være student eller ansatt ved HIOA. Oversikt over låntakerens nåværende lån vises. 1) Systemet viser en oversikt over brukerens nåværende lån, 90

91 reserverte dokumenter og tidligere lån. 2) Brukeren scroller ned til oversikten over nåværende lån. Variasjoner 2.1 Bruker har ingen lån 2.2 Ruten under Dine lån et tom. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Se oversikt over reserverte dokumenter. Låntakeren Smarttelefon eller nettbrett. Låntakeren ønsker å se oversikt over sine reserverte dokumenter. Låntakeren må være student eller ansatt ved HIOA. Oversikt over låntakerens reserverte dokumenter vises. 1) Systemet viser en oversikt over brukerens nåværende lån, reserverte dokumenter og tidligere lån. 2) Brukeren scroller ned til oversikten over reserverte dokumenter. Variasjoner 2.1 Bruker har reserverte dokumenter. 2.2 Ruten under Dine reservasjoner et tom. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Fornye lån Låntaker Smarttelefon eller nettbrett. Låntaker ønsker å fornye lån. Låntakeren må være student eller ansatt ved HIOA. Lånet blir fornyet. 1) Systemet viser en oversikt over brukerens nåværende lån, 91

92 reserverte dokumenter og tidligere lån. 2) Brukeren scroller ned til oversikten over nåværende lån, finner lånet som han eller hun ønsker å fornye. 3) Systemet fornyer lånet. Variasjoner 3.1 Lånet kan ikke fornyes 3.2 Systemet gir låntakeren ingen mulighet til å fornye lånet, og lånet blir ikke fornyet. Use Case Aktør Sekundæraktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Redigere nyheter. Systemansvarlig. Smarttelefon eller nettbrett. Systemansvarlig ønsker å redigere nyheter. Systemansvarlig må være ansatt ved HIOA. Nyhetene på forsiden blir redigert. 1) Systemansvarlig logger inn på systemet med administrator brukernavn og passord. 2) Systemet gir systemansvarlig mulighet til å endre informasjonen som står i ruten som inneholder nyheter. 3) Systemansvarlig redigerer innholdet. 4) Systemet oppdaterer ruten. Variasjoner 1.1 Systemansvarlig oppgir feil administrator passord eller brukernavn. 1.2 Systemet gir en feilmelding og systemansvarlig blir ikke logget inn. 1.3 Systemansvarlig logger inne med riktig administrator passord og brukernavn. 92

93 Vedlegg 6 Prototype under utvikling Prototype gjort med penn og papir. 93

94 Prototype gjort i photoshop. Prototype gjort i Balsamiq Mockups. 94