HOVEDPROSJEKT. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1 1

2 2

3 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Mobilt Bibliotek - mbib DATO ANTALL SIDER 100 PROSJEKTDELTAKERE André Sharghi Mohammad Aqeel Sharif Jerome Panaligan Abueg Tinh Thanh Le s s s s INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER LSB Digitale tjenester KONTAKTPERSON Tanja Strøm SAMMENDRAG Dette produktet er utført i samarbeid med Læringssenteret og biblioteket, heretter LSB, ved Høgskolen i Oslo og Akershus, heretter HiOA, i forhold til hovedprosjektet. Kravet med denne arbeidsoppgaven er studentdrevet innovasjon, det vil si utvikle en løsning av studenter for studenter. Løsningen ble derfor utviklet i form av en mobil applikasjon. Målet med denne applikasjon er å kunne presentere informasjon samt tilby tjenester og funksjoner relatert til LSB. For eksempel så kan det søkes på materiale fra bibliotekdatabasen, det kan bestilles og eventuelle lån kan fornyes. 3 STIKKORD Mobil applikasjon Android Læringssenteret 3

4 4

5 Forord Rapporten er et sammensatt dokument som er laget i forbindelse med hovedprosjektet ved Høgskolen i Oslo og Akershus våren Sluttrapporten er satt sammen tre rapporter: Prosessdokumentasjon, Produktdokumentasjon og Testdokumentasjon. Prosessdokumentasjoner utdyper prosessutvikling av prosjektet. Produktdokumentasjonen beskriver selve produktet. Testdokumentasjon tar for seg testmiljøet rundt produktet. Rapporten er beregnet for arbeidsgiver og sensor, men vil også være tilgjengelig for interesserte på gruppens hjemmeside. I tillegg til dette vil det være tilgjengelig for videreutvikling. Dokumentformatet er PDF og er tilgjengelig på de fleste plattformer (Datamaskin, mobil og nettbrett). Vedlagt medfølger: Kravspesifikasjonen, Brukermanualen og Kildeliste. Takk til Takk til Tor Krattebøl som anbefalte oss oppgaven. Takk til vår oppdragsgiver Tanja Strøm og hennes underordnede for å ha gitt oss en mulighet til å gjennomføre dette prosjektet. Takk til vår veileder Kirsten Ribu, som har hjulpet oss gjennom hele arbeidsprosessen. Takk til studentene ved HiOA som har hjulpet oss med brukerundersøkelsen og testing. 5

6 6

7 Innhold Presentasjon Mobilt Bibliotek (mbib) Prosessdokumentasjon Innledning Bakgrunn for oppgaven Bakgrunn for valg av plattform Om gruppen Om læringssenteret og bibliotek Mål og begrensninger (Mål & Rammebetingelser) Planleggingsfasen Oppstarten Planleggingsprosessen Utforming av kravspesifikasjon Arbeidsfordeling Dokumenthåndtering Verktøy Ny kunnskap Prototype Utviklingsprosesser Arbeidsmetode Faser Utfordringer under utviklingsprosessen Valg av oppbygging og funksjon Forholdet til oppdragsgiver under prosessen Tilbakemelding fra oppdragsgiver

8 4 Kravspesifikasjon og dens rolle Endringer Samsvar mellom kravspesifikasjon og produkt Om resultatet Brukerundersøkelse Konklusjon Avslutning Videreutvikling Produktdokumentasjon Innledning Hensikten med applikasjonen Kort beskrivelse av applikasjonen Teknologi Utviklingsmiljø Beskrivelse av applikasjonen Applikasjonens oppbygning Applikasjonens hoveddeler Design Klasser/Filstruktur Diagrammer & Use Case Use Case(Brukstilfelle) Detaljerte Use Case beskrivelser Aktivitetsdiagram Forhold til maskiner Programvare Maskinvare

9 6 Avsluttende del Mulige utvidelser Konklusjon Testdokumentasjon Test nr 1: Søk Formål Deler ved søk Oppsett av testen Test metode Data Forventet resultat Resultatet Kommentar til resultatet Konklusjon Test nr 2: Bestilling av materialet Formål Deler ved bestilling Nødvendige tekniske utstyr for testingen Test metode Kvittering Forventet resultat Resultatet Kommentar til resultatet Konklusjon Test nr 3: Link, mail og ringing Formål

10 Deler ved linker, mail og ringing Enhet testing Test metode Enhetsfunksjon Forventet resultat Resultatet Kommentar for resultatet Konklusjon Test nr 4: Farge Formål Farger Andre midler for testing Colorfilter.wickline.org Test metode Forventet resultat Resultatet Kommentar til resultat Konklusjon Test nr 5: Plassering Formål Plassering Test enheter Test metode Forventet resultat Resultatet Kommentar til resultatet

11 Konklusjon Test nr 6: Responstid Formål Responstid Test enheter Testmetode Forventet resultat Resultatet Kommentar til resultat Konklusjon Test nr 7: Navigering Formål ActionBar Test enheter Testmetode Forventet resultat Resultatet Kommentar til resultat Konklusjon Sluttkonklusjon Vedlegg Brukermanual Generelt Nedlasting og installasjon Hovedsidene Informasjon

12 Kurs Mobile tjenester Åpningstider Kontaktinfo IT-støtte Campuskart Søk Mer info Min side Innlogging Innstillinger Automatisk innlogging Kravspesifikasjon Generelt Applikasjonens krav Funksjonelle Ikke-Funksjonelle Designkrav Maskinvarekrav (Android enhet) Dokumentasjonskrav Kildeliste

13 Presentasjon 13

14 Mobilt Bibliotek (mbib) Læringssenter og Bibliotek ved Høgskolen i Oslo og Akershus har i dag et bredt spekter når det gjelder digitale tjenester. Tjenester som søk, bestilling og reservering av læringssenterets materialer finnes i mange forskjellige løsninger. Som for eksempel finnes det allerede en nettbasert løsning som tilbyr disse tjenestene. Læringssenter og Bibliotek vil dermed forstørre deres brukervennlighet, slik at flere studenter skal ha seg nytte av disse tjenestene. Vi vil derfor komme med en mobilløsning, som vi kaller for Mobilt Bibliotek (mbib). I dag bruker de fleste studentene en smart telefon, som har tilgang til applikasjoner. Dette ga oss en mulighet til å komme med en løsning som er både praktisk og effektiv for studenter ved Høgskolen i Oslo og Akershus, en mobilapplikasjon for læringssenteret. Denne oppgaven kunne ha hva som helst som løsning. Oppdragsgiveren ga oss ingen krav å forholde oss til, og dermed var det helt opp til oss å avgjøre hva som skulle være med i løsningen. Dette fikk oss til å være selvstendige og gjorde det meste på egen hånd. Vi gjorde et stort forarbeid, med testing, brukerundersøkelse, prototyping og kom frem til løsningen som vi har som sluttprodukt. Denne applikasjonen vil hjelpe studenter, slik at de får tilgang til de digitale tjenestene som læringssenteret tilbyr. Applikasjonen vil være en løsning som er mer tilgjengelig for de fleste brukere hvor enn de befinner seg så lenge de har en smart telefon og tilgang til internett. Vi viser til våre resultater at denne applikasjonen har potensiale til å bli brukt av studenter. Dette siden funksjonene som har blitt implementert i applikasjonen er mer brukervennlige og praktisk på mange aspekter. Gruppen har sammen gjort det de kan for å få frem det beste i applikasjonen. Etter mye testing og feiling, klarte vi til slutt å få til de målene som vi har satt. Vi håper at dette vil være til hjelp for mange studenter og studiene deres framover. 14

15 Prosessdokumentasjon 15

16 1 Innledning Hovedprosjektet ble anbefalt av Tor Krattebøl som også er kontaktansvarlig for hovedprosjektet våren Etter å ha sendt søknaden og gruppens CV-er ble vi kontaktet av Kirsten Ribu veilederen for denne oppgaven, som da kalte oss inn for et møte. Det var da vi påtok oss oppgaven som LSB (Læringssenter og bibliotek) ved høgskolen i Oslo og Akershus tilbød. 1.1 Bakgrunn for oppgaven I dag bruker en av fem nordmenn medieinnhold på mobilplattform daglig, og overgangen fra PCer til bruk av mobile plattformer drives av smarttelefoner og ulike nettbrett. Arbeidsgiveren ønsket en ny løsning for LSB sine digitale tjenester, laget av studenter for studenter ved Høgskolen i Oslo og Akershus. Her ville de at studentene skal utvikle en prototype eller en fullstendig mobil applikasjon, på et grunnlag av at vi som studenter skal kunne se på virksomheten med friske øyner. Med det var også forslag om nye løsninger eller funksjoner. Vi i gruppen diskuterte og kom frem til at vi ville utvikle en mobil applikasjon som løsning for denne oppgaven. Arbeidsgiveren refererte til Universitetet 1, hvor de hadde et lignende prosjekt og ville dermed at vi studenter her på Høgskolen også skulle få til noe lignende. 1.2 Bakgrunn for valg av plattform Etter å fått tildelt ansvaret om å utvikle applikasjonen i desember, ble det holdt et møte med Kirsten Ribu. Her ble det diskutert gruppens kompetanse i forskjellige programmeringsspråk og eventuelt hvilken plattform vi var interesserte i. Gruppen hadde et bredt spekter med språk, men ingen hadde noe relativ erfaring med applikasjonsutvikling. Tidlig bestemte vi oss at valgene stod mellom dagens populære operativsystemer; ios, Android, Windows 7. Vi utførte en brukerundersøkelse der en del av formålet var å finne ut hvilke operativsystemer ble brukt av studentene i HiOA. Som følge av det gikk vi for Android, nettopp som alle i gruppen hadde planer om å ta valgfaget Applikasjonsutvikling (Android) til våren Dette kunne være med å styrke 1 Universitetsbiblioteket

17 utviklingen ettersom det å lære seg språket på egenhånd og undervisning ville gi oss mer læringsutbytte. 1.3 Om gruppen André Sharghi Bachelorstudium i Ingeniørfag(Data) s Mohammad Aqeel Sharif Bachelorstudium i Ingeniørfag(Data) s Jerome Panaligan Abueg Bachelorstudium i Informasjonsteknologi s Tinh Thanh Le Bachelorstudium i Ingeniørfag(Data) s Gruppen består av 4 studenter, derav tre av disse går Ingeniørfag (Data) og den siste på informasjonsteknologi. Vi har hatt en lang erfaring med gruppesamarbeid som strekker seg tilbake helt til det første semesteret fra det første skole året. Med dette har vi kunnskap til hvordan enhver person kan bidra på det ytterste. Dannelsen av denne hovedprosjektgruppen er på grunn lag av felles ambisjoner, god arbeidskjemi og samarbeidsmiljø. 1.4 Om læringssenteret og bibliotek Læringssenteret ved Pilestredet har støttet, ved hjelp av sine digitale tjenester, både undervisning og forskning ved Høgskolen i Oslo og Akershus. På hvert av fakultetene fins fortsatt de vanlige rutinene for låning og bestilling av bibliotekets materialer, men LSB bruker også en nettbasert løsning med samarbeid med BIBSYS for deres bibliotek. Her tilbys flere søkemuligheter og enkle låne- og bestillingsfunksjoner via internett. Etter sammenslåingen av Høgskolen i Oslo og Akershus i 2011, ble fellesadministrasjonen på HiOA delt inn i fire avdelinger, der læringssenter og bibliotek (LSB) ble en enhet innenfor forskning og bibliotek. LSB blir regnet som en avdeling under forskning og utdanning som igjen er oppdelt i fire seksjoner. Læringssenteret på HiOA har tilsammen bortimot 70 ansatte. Med stort samarbeid mellom de forskjellige avdelingene, jobber de sammen for å tilby studenter og lærere en mer praktisk måte for å ta i bruk bibliotekets tjenester. Ettersom alle studenter ved de forskjellige fakultetene har like rettigheter, vil også applikasjonen være tilgjengelig for alle studenter, uavhengig av hvilket fakultet de tilhører. 17

18 1.4.1 Digitale Tjenester LSB tilbyr også digitale tjenester. Her kan både studenter og ansatte få tilgang til ulike databaser som inneholder materialer fra ulike tidsperioder. Dette kan være forskninger, artikler, oppslagsverk og andre nettressurser. I tillegg tilbys det informasjon som kan hjelpe studenter med deres skolegang, som for eksempel studieverksteder Dagen situasjon Læringssenteret på HiOA har ingen applikasjon for mobile enheter å tilby for sine studenter. For øyeblikket har dem en vanlig nettside, som er tilpasset til mobile enheter ( Denne nettsiden har ikke fullstendig nok funksjoner som gjør den brukervennlig for mobile enheter. Figur 1.1: 18

19 1.5 Mål og begrensninger (Mål & Rammebetingelser) Målet med dette prosjektet er å utvikle en fullstendig applikasjon som skal inneholde de nåværende funksjonene (lsbmobil.hio.no) samt nye funksjoner. Applikasjonen skal være skreddersydd for smarttelefoner som drives av Android operativsystemet Mål for applikasjon Søking etter materiale o Eksempel ved tittel, forfatter, utgivelsesår Bestilling/Reservering av materiale Historikk over søkt materiale, bestillinger/lån Retningsveileder til materiale Status på tilgjengelighet av materiale Diverse informasjon som åpningstider, kontaktinformasjon, nyheter osv. Notifikasjoner på mobil som varsler frister, reservert materiale blir ledig osv. Hvis vi har nok ressurser og tid Låning av materiale ved skanning av strekkode Utvide notifikasjonssystemet Synkronisering mot sosiale medier, anbefaling/deling 19

20 1.5.2 Løsninger/Alternativer Under er det gitt en oversikt over positive og negative sider ved våre valg av funksjoner i applikasjonen. Funksjoner Positiv Negativ Søkefunksjon Enklere å søke opp materiale Kan kun brukes over internett Bestilling/Reservering Enklere å reservere, raskere Kan kun brukes over internett Retningsveileder Historikk søk, reservering Status på tilgjengelighet Diverse informasjon Enklere å finne fram til materiale Enklere å huske hva man har lånt, reservert, søkt etter Enkelt å vite om lånemuligheter Oversikt over åpningstider, kontaktpersoner Kan være litt avvikende, unøyaktig Må ha en begrenset mengde (For eksempel 10 siste) Må vente på beskjed fra biblioteket Kan bli overflødig med for mye informasjon Notifikasjon Får med seg nyheter Kan være upassende og plagsom for noen 20

21 2 Planleggingsfasen 2.1 Oppstarten Det hele startet med at gruppen diskuterte om hva slags tema som var akseptabelt for gruppen å drive med. Rammeverket vi hadde mest lyst å jobbe med var HTML, CSS, Java, MySQL og ASP.NET. Dermed var søket etter oppdragsgiver basert på hva slags kunnskap som krevdes og hva vi liker å drive med. Vi fikk mange anbefalinger fra høgskolen sin side, men i tillegg til dette satt vi og lette etter andre oppdragsgivere fra forskjellige kilder. Vi kom til en konklusjon og tok kontakt med Bekk, Accenture og Aktiviteter for barn AS. Disse bedriftene hadde veldig åpent rammeverk, noe som gjorde at vi ble interessert og var ivrige til å starte. Men uheldigvis var det mange andre som var raskere enn oss og hadde allerede søkt. Til slutt fant vi en Studentdrevet innovasjon, en oppgave der vi kunne komme med en løsning for de digitale tjenestene som LSB bruker. Vi kontaktet først vår veileder Kirsten Ribu, hvor vi fikk informasjon på hva slags oppgave vi hadde framfor oss. Heldig nok fikk vi oppgaven og planla allerede da hvordan vi skulle gå frem. Vi hadde et par veiledningstimer hvor vi diskuterte oss frem til forskjellige løsninger. Vi bestemte oss til slutt å lage en mobilapplikasjon, med de forskjellige tjenestene som læringssenteret tilbyr. Deretter fikk vi møte vår oppdragsgiver, der vi introduserte vår løsning og hva vi tenkte. 2.2 Planleggingsprosessen Prosjektets planlegging startet tidlig desember, der oppgaven ble behandlet av gruppen. Oppgaven var veldig stor, og oppdragsgiveren ga oss muligheten til å lage hva vi ville så lenge det var innen temaet. Vi startet å gjøre research på hva slags digitale tjenester LSB hadde. Det viste seg at LSB hadde en nettbasert løsning som gjorde det mulig å benytte LSB sine digitale tjenester. Gruppen valgte dermed å lage en mobilapplikasjon som hadde de tjenestene som nettløsningen hadde. Vi diskuterte rundt i gruppen og med veilederen hva slags mulige funksjoner applikasjonen skulle ha, noe som er basert på de studentene her på Høgskolen i Oslo og Akershus. 21

22 2.3 Utforming av kravspesifikasjon Arbeidsgiveren hadde ingen krav på hva vi skulle ha i løsningen, for det eneste hun ville ha var en løsning for LSB sine digitale løsninger som er studentdrevet, det vil si laget av studenter for studenter her på HiOA. Dette var en veldig omfattende oppgave, noe som gjorde at vi måtte finne ut hva slags nødvendige funksjoner som var realistiske å ha med i applikasjonen. Vi diskuterte alt fra og med de mest vanlige funksjonene til å diskutere om det skulle være mulig å skanne for utlån via mobilen. Dette ledet oss til at vi måtte teste ut den nåværende løsningen med selvbetjeningsapparatet, testing av nettløsningen og utførte en brukerundersøkelse. Disse tre hovedpunktene avgjorde hva i mobilapplikasjonen som var nødvendige å ha med og om det var realistisk når det er snakk om ressurs og tid. Dette som grunnlag var vi på god vei til å lage en kravspesifikasjon. Men vi bestemte oss å lage en prototype, og testet alle mulige funksjoner som vi tenkte var rimelige og nødvendige. Etter flere utkast av prototyper, ledet det oss fram til den kravspesifikasjonen vi trengte for prosjektet. 2.4 Arbeidsfordeling Vi hadde en grov arbeidsfordeling av oppgavene. Vi lot hver av gruppemedlemmene ha et ansvar for sine oppgaver i prosjektet. De forskjellige oppgavene er for eksempel koding, designing og dokumentering. Selv om de forskjellige gruppemedlemmene hadde ansvar for dem, så gjorde en for eksempel både koding og design. Slik fordeling hadde gruppen, for å optimalisere arbeidstiden og være så effektiv som mulig. Tinh Aqeel Jerome André Dokumentasjon Koding Dokumentasjon Design 2.5 Dokumenthåndtering Etter hvert møte ble det skrevet et referat om hva som er blitt gjort for det møtet som har blitt holdt. Dette kan man se i vedlegg som er vedlagt. Dette er for gruppemedlemmenes skyld, som gir oss en oversikt over hva som har blitt snakket om i hver av møtene. 22

23 Ved siden av møtereferat, har vi i tillegg en prosjektdagbok som forteller oss stikkords vis hva som er blitt gjort til ethvert tidspunkt gjennom hele prosjektet. Dette er for å holde styr på hva som har blitt gjort, slik at gruppemedlemmene vet hva som må gjøres videre. 2.6 Verktøy Det har blitt brukt flere verktøy, både for prosessen og utviklingen gjennom hele prosjektet. Disse verktøyene har blitt bestemt i fellesskap og har vært med på å dekke områdene som var nødvendige Utviklingsverktøy Eclipse Adobe Photoshop & Flash For koding bruker vi programmet Eclipse som vårt hovedutviklingsverktøy, for her har vi tilgang til emulatorer som hjalp oss med å få testet ut funksjonene våres. Grunnen til dette er for at vi har lært å bruke dette programmet spesifikt for Androidutvikling noe som passet for vårt operativsystem og rammeverk. Når det gjaldt design, brukte vi programmene Adobe Flash og Adobe Photoshop som våre hovedprogrammer. Dette er fordi gruppemedlemmene er flinkest med disse programmene som gjør at effektiviteten i gruppen blir optimalt Prosessverktøy Microsoft Word For dokumentasjon forholdte vi oss til Microsoft Office Word. Dette er et standard verktøy som de fleste bruker, og egner seg best for dokumenteringen for utskrift og publisering i form av PDF-fil. 23

24 Skype TeamViewer Skype brukte vi som et kommunikasjonsmiddel og ga oss muligheten til å snakke med hverandre hver dag. Gruppen jobbet stort sett hjemmefra, og var derfor et bra middel for konferansesamtaler. Programmet tilbyr fjernstyring og skrivebordsdeling. Den ble brukt sammen med Skype og sørget for den visuelle delen av gruppekommunikasjonen. Dropbox Vi bestemte å lagre alt av dokumenter og filer i programmet Dropbox, som er en fildelingstjeneste. Vi er mest kjent med dette programmet og det var rimelig for alle gruppemedlemmene. For hver gang vi lagret noe, tar vi backup og skriver i en logg om at det som er gjort slik at vi holder styr på hva som har blitt endret. Det kommer også en melding som forteller oss at noe er oppdatert. WhatsApp Messenger WhatsApp Messenger er et gratis meldingsprogram som var nedlastet på smarttelefonene våre. Naturligvis kunne ikke alle være tilstede til enhver tid, av den grunn opprettet vi en gruppe i applikasjonen for jevnlige oppdateringer blant gruppen. 2.7 Ny kunnskap Produktet er en mobilapplikasjon for Androidplattform, en plattform som ingen av gruppemedlemmene hadde noe særlig erfaring av. Men vi hadde en mulighet å ta et fag innenfor dette temaet, nemlig Applikasjonsutvikling innen Android. Dette førte til at 24

25 kodingen av produktet hele tiden ble forskjøvet framover, pga. nytt kunnskap og nye funksjoner vi lærte oss underveis i dette semesteret. 2.8 Prototype I tidligere prosjekter som gruppen har utført, har prototyper mye å si. Vi bruker dette som et grunnlag over hva vi skal programmere og hvordan utseende skal se ut. Dermed valgte vi å prototype i dette prosjektet også. Ettersom arbeidsgiveren ikke stilte noen spesifikke krav eller rammer rundt oppgaven, brukte vi prototypen som et verktøy for forming av kravspesifikasjonen. Resultatet av dette blir aldri det samme som sluttproduktet, men prototypen kan gi arbeidsgiveren et syn på hvordan applikasjonen blir og eventuelt gi tilbakemelding. Under viser vi progresjonen i prototypen. (Den endelige prototypen er lagt til som vedlegg) Figur 1.2: Prototypene 25

26 3 Utviklingsprosesser 3.1 Arbeidsmetode Gruppen ble inspirert av arbeidsmetoden Scrum. Dette er et rammeverk som er tilegnet for utvikling av programvarebasert system. Denne metoden går ut på at man jobber inkrementelt og iterativt gjennom hele arbeidsprosessen. For hver uke hadde vi mål om å bli ferdig med en del, som skal gjennom analysering og testing. Dette gjorde vi gjennom hele produktutviklingen, og etter fullføring av et mål, satt vi og diskuterte hva som hadde blitt gjort siden sist. Mot slutten av hvert gruppemøte ble det avtalt hva som skulle gjøres videre. 3.2 Faser Forarbeid Det var tre hovedpunkter i startfasen som førte til den løsningen vi har utviklet. Det første var å finne ut løsningene som LSB har, og bli kjent med dem. Dette var forarbeidet som gruppen diskuterte om i første omgang. Den andre store metoden som fikk oss til å danne et bildet av hvordan produktet kommer til å bli, var å teste ut de nåværende løsningene. Vi har en nettløsning, der man kan søke og bestille. Vi har en fysisk løsning av utlån i selve biblioteket, der det finnes selvbetjeningsapparater som gjør det mulig å få lånt et materiale. Til slutt lagde vi undersøkelser der vi spurte medstudenter hva dem trengte og om det var noe nødvendige funksjoner som trengs å ta med. Dette gjorde at vi fikk spesifisere oss slik at vi kunne utvikle mobilapplikasjonen. Men dette var ikke fullkomment uten en prototype. Dermed lagde vi en prototype for å illustrere hvordan mobilapplikasjonen ville være med de funksjonene vi hadde bestemt oss. Dette var grunnlaget for selve produktet Gjennomføring Denne fasen startet så fort vi var klare med den kunnskapen vi hadde lært. Vi hadde for hver uke et mål på hva som skulle bli ferdig. Det ble det diskutert om det var realistiske mål eller ikke. Dette gjorde vi etter hver gang vi ble ferdig med de målene som ble satt til hver uke. Slik foregikk arbeidet vårt gjennom hele prosjektet. 26

27 3.2.3 Testing Under testingen, tester vi ut kun de funksjonene som vi har utviklet for den uken som målet har blitt lagt. Vi ser på både fordeler og ulemper, og hva slags konsekvenser det kunne medføre. Vi tenker også på tilgjengelighet og brukervennlighet når vi tester applikasjonen. For eksempel en knapp skal være stort nok slik at en bruker med dårlig syn skal kunne se knappene og klare å navigere seg rundt på applikasjonen. 3.3 Utfordringer under utviklingsprosessen Android Samtidig som planen var å utvikle en Androidapplikasjon måtte gruppen sørge for å lære programmeringsspråket. Dette gjorde vi gjennom faget Applikasjonsutvikling. Gruppen ble kanskje holdt tilbake ettersom mye av det viktige pensumet kom litt senere, noe som førte til egenlæring og prioriterings skifte. Med andre ord ble hovedprosjektet skyvet litt fremover for å vike plass for tilegningen av programmeringsspråket RESTful & JSON For at oppgaven skulle få den funksjonaliteten som var planlagt, som for eksempel søking, måtte applikasjonen ta i bruk RESTful tjenester for utveksling av data. Det går ut på at det sendes en forespørsel via HTTP protokollen og leverer svaret innpakket som et JSON objekt. JSON er en enkel tekst basert standard for dataveksling der dataformatet er uavhengig av programmeringsspråk. Standarden var lett å lese og skrive for brukere, og lett for systemer å parse og generere. Dette var også en utfordring ettersom denne standarden/protokollen var svært omfattende og tidskrevende å beherske. 3.4 Valg av oppbygging og funksjon Bruk av versjonskontroll Det ble diskutert mellom medlemmene i gruppen om å ta i bruk et versjonskontrollsystem. Tidligere har vi hatt erfaring med dette fra både Git og Team Foundation Server på Visual Studio. Eclipse tilbød sin egen versjon som var EGit og vi gjorde et forsøk om å benytte dette uten lykke. Ettersom gruppen brukte en arbeidsmetodikk inspirert av Scrum, der vi hadde daglig 27

28 møter og jobbet tett sammen, valgte vi å bruke den enklere versjonskontrollmetode som Dropbox hadde Design Arbeidsgiveren stilte ingen krav når det gjaldt design, og lot gruppen avgjøre hvordan dette skulle utføres. Vi ønsket å forbedre den eksisterende løsningen, ved å ta i bruk litt mer farger. Siden LSB er en del av HiOA brukte vi samme fargevalg som deres nettside. Fargevalget består hovedsakelig av nøytrale farger med oransje detaljer. I tillegg til dette er ikonene våres egne som er tilpasset med designet på applikasjonen. De ulike delene i designet er satt opp slik at de er dynamiske og posisjonerer seg etter enhetens skjermstørrelse. Dermed kan vi si at applikasjonen passer til alle enheter i ulike skjermstørrelser som kjører Android Utelatelse av funksjoner I kravspesifikasjonen hadde vi som mål å kunne låne materiale fra biblioteket ved skanning av strekkode. Men tidlig i utviklingsfasen kom gruppen frem til at denne funksjonen ville bli mer overflødig enn til hjelpsom. Grunnen var at hvis studenten skulle skanne materiale for lån, måtte den fortsatt gjennom låneskranken for avmagnetisering. Dette var ikke brukervennlig eller effektivt og vi valgte derfor å kutte ut funksjonen 3.5 Forholdet til oppdragsgiver under prosessen På starten av semesteret ble møte med oppdragsgiver utsatt litt ettersom begge parter hadde travle timeplaner. Kommunikasjonen gikk hovedsakelig gjennom Kirsten, som da videreførte meldinger til Tanja. Etter noen par uker, fikk vi møte Tanja. Deretter ble målene og hva oppdragsgiver ønsket tydeligere. Ut i fra dette lagde vi en prototype som igjen ble vurdert av både oppdragsgiver og veileder. Tilbakemeldingen vi fikk fra prototypen brukte vi som grunnlag for utvikle selve sluttproduktet. 3.6 Tilbakemelding fra oppdragsgiver Tilbakemeldinger fra oppdragsgiver har vært positive når det gjelder utvikling av applikasjonen. Det som ble mest vektlagt fra oppdragsgivers side var designvalg og brukervennligheten. Applikasjonen skulle være tilgjengelig for alle studenter, og at oppsettet og fargevalg skulle være inspirert av hjemmesiden til HiOA. 28

29 4 Kravspesifikasjon og dens rolle Kravspesifikasjonen er en beskrivelse av hvordan arbeidsgiveren ønsker at sluttproduktet skal være. Men i vårt tilfelle hadde vi ingen kravspesifikasjon, og dermed måtte vi utforme en egen kravspesifikasjon via prototyping. Gruppen brukte dette som veiledning for utviklingen, samtidig som det også var et middel for å presentere hvordan applikasjonen skulle bli. 4.1 Endringer Da gruppen satte i gang med kravspesifikasjonen lagde vi rom for endringer ettersom vi regnet med tilbakemeldinger skulle påvirke kravspesifikasjonen. Til å begynne med var det ingen krav på hva som skulle være med av oppdragsgiveren, men disse kom da vi begrenset applikasjonen og presenterte prototyper. Som forklart tidligere, ble flere funksjoner utelatt som førte til endringer i kravspesifikasjonen. Andre faktorer som endret på dette er manglende tid og ressurser. Ikke-funksjonelle krav som kompatibilitet med alle skjermstørrelser, og enkelthet i kildekode som kan føre til lettere vedlikehold og videreutvikling, er gruppen fornøyd med. 4.2 Samsvar mellom kravspesifikasjon og produkt Vi mener at helheten av kravspesifikasjonen samsvarer med sluttproduktet. Noen av målene ble som beskrevet alternert og de mulige utvidelsene ble ikke implementert, men funksjonaliteten og designet på applikasjonen ble vellykket. 29

30 5 Om resultatet 5.1 Brukerundersøkelse Vi hadde en undersøkelse hvor vi spurte studenter ved HiOA generelle spørsmål om læringssenteret. Spørsmål som hvor ofte de bruker tjenestene fra biblioteket, hvordan de gjør det, og et spørsmål angående hva studenter ville ha i en slik applikasjon. Vi kom frem til at ios (Apple) var deres mest brukte operativsystem og Android kom på andre plass. Dette var en del av grunnlaget for valget av operativsystem vi ville bruke i vår utvikling. Resultatet av denne undersøkelse viste oss hva vi ville ha med. Først ville vi ha med de mest brukte tjenestene som læringssenteret tilbyr, men etter denne undersøkelsen viste det seg at vi skulle ha med noen ekstra funksjoner som studenter ville ha implementert i applikasjonen. Disse funksjonene er blant annet om materialene er tilgjengelig i biblioteket, retningsveiledning til materialene og notifikasjon når bøkene er ankommet. Dette bearbeidet vi videre og kom frem til at noen av disse funksjonene skulle implementeres hvis vi hadde nok kapasitet. 5.2 Konklusjon Etter en lang diskusjonsfase med de involverte, kom vi frem at applikasjonen skulle være en digital løsning som får studenter til å bruke dette middelet mer enn den nåværende fysiske løsningen, eller nettløsningen som finnes allerede i dag. Hovedhensikten var dermed å gjøre det mye enklere for studentene å reservere, bestille, finne materialer, og holde styr på hva de allerede har lånt og bestilt. Dette vil man kunne gjøre på egenhånd via en smarttelefon. 30

31 6 Avslutning Dette var en læringsfase med et veldig stort rammeverk. Siden dette var nytt kunnskap og alle sammen i gruppen valgte å ta faget Androidutvikling ved siden av, var det hele tiden noe nytt som vi måtte ta i betraktning når det gjaldt ting vi villa ha med i applikasjonen. Fra den minste plassering av en knapp til å få til slides, er ting som vi lærte gjennom denne utviklingsprosessen. Fra start til slutt har det vært forbedringer hele tiden, som man kan se i prototypen. For vår del har det vært kunnskapsrikt å ha vært med i dette prosjektet. Vi har fått erfart hvordan det er å arbeide i et stort prosjekt, hvor mange parter er involvert og jobbet sammen til å få til slik løsning. Kunnskap innen mobilapplikasjon vil være det mest sentrale temaet som alle i gruppen vil få seg nytte av i fremtiden. Det har vært både oppturer og nedturer i prosessen, men vi har klart å gjennomføre prosjektet som planlagt. 6.1 Videreutvikling For videreutvikling finnes det flere forslag. Det er visse ting som vi ville ha med, men kapasiteten medførte at det ikke kunne gjennomføres. Som for eksempel har vi låning av materiale ved skanning av strekkode, utviding av notifikasjonen og kobling til sosiale medier. 31

32 32

33 Produktdokumentasjon 33

34 1 Innledning 1.1 Hensikten med applikasjonen Formålet med oppgaven er å levere et ferdig produkt som skal tilby Læringssenterets informasjon og tjenester. Applikasjonen skal være en studentdrevet innovasjon der studenter lager noe for studenter, og resultatet er Mobilt Bibliotek, heretter mbib. 1.2 Kort beskrivelse av applikasjonen mbib kan brukes som et middel for presentasjon av informasjon. Her kan studenter samt tilsatte, finne informasjon om læringssenteret. For å nevne noen er åpningstider, campuskart og ulike kurs noen eksempler. Sluttproduktet kan også være et hjelpemiddel for søking av materiale. Ved innlogging kan også studenten få tilgang til en oversikt over nåværende lån. 2 Teknologi 2.1 Utviklingsmiljø Kapitlet under er nødvendig for vedlikehold eller videreutvikling. Alle lenker som trengs for nedlastinger, ligger under Kilder JDK / ADK / Eclipse Androidapplikasjoner er utviklet i Java og krever derfor Java Development Kit (JDK). Over dette blir det igjen brukt Android Software Development Kit (Android SDK). Android SDK er en prosess og et verktøy for å utvikle applikasjonen for operativsystemet. Her finnes det en debugger, et stort utvalg av forskjellige biblioteker inkludert dokumentasjon og veiledninger. Verktøyet er tilgjengelig for Windows, Linux og MacOS. Android har hovedsakelig to typer filer, Java- og XML-filer. Java er den dynamiske delen og XML er en layout fil. 34

35 public void settinntid(string[] tid) { String a = "Stengt"; if(aapen) a = "Åpen"; } for(int i = 0; i < tid.length; i++) { tvukedag[i].settext(tid[i] + a); } Figur 2.1 : Eksempel på Java kode <TextView android:id="@+id/overskrift" style="@style/overskrift" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:layout_alignparenttop="true" android:layout_marginleft="30dp" android:layout_margintop="35dp" android:text="@string/aapningstider" /> Figur 2.2: Eksempel på XML kode Utviklingsprogrammet som ble benyttet under prosjektet var Eclipse. Dette er et flerspråklig utviklingsverktøy for programvare med støtte for utvidet funksjonalitet ved programvareutvidelser. I dette tilfellet bruker vi Java/Android i programmet, men det er også mulighet for andre språk som for eksempel C, C++, JavaScript, Perl, PHP osv Emulator Er det ikke mulighet for å bruke en egen Android enhet, kan det bli substituert med Eclipse sin virtuelle enhet. Denne må lages med minimum Application Programming Interface (API) versjon 16, og ha internett tilgjengelig for denne applikasjonen JSON RESTful, Bibsys sin tjeneste for utlån og søking av materiale er brukt. Dette foregår gjennom en HTTP-POST-metode mot en server, og som sender tilbake et resultat i form av JSONobjekt. JSON er en enkel tekst basert standard for dataveksling der dataformatet er uavhengig av programmeringsspråk. Standarden er lett å lese og skrive for brukere, og lett for systemer å parse (konvertere) og generere. 35

36 3 Beskrivelse av applikasjonen 3.1 Applikasjonens oppbygning Dette avsnittet skal gi en kort oversikt over applikasjons oppbygning. mbib består av 4 hovedaktiviteter, Info/Hjem, Søk, Min Side og Innstillinger. Under er en illustrasjon av hoveddelene. Figur 3.1: Illustrasjon av applikasjon ens hoveddeler Hver av disse aktivitetene har sin egen knapp i menyen. Denne menyen er kalt for ActionBar og er et element i grensesnittet som vanligvis blir funnet på toppen av skjermen. Denne menyen kan inneholde tittel, knapper og andre interaktive moduler. Figur 2.3: ActionBar 36

37 3.1.1 Info Kravspesifikasjon: Presentasjon av diverse informasjon som åpningstider, kontaktinformasjon, nyheter osv. I den første delen presenterer vi informasjon som er relatert med LSB. Dette er alt fra åpningstider til ulike kurs som dette domenet tilbyr. Figur 2.4 : Illustrasjon av info Figuren 3.3 viser at undersidene er fragmenter. Dette er fordi at det blir drevet av en Swipe aktivitet. Det vil si at alle disse undersidene er samlet under en felles aktivitet, men gir brukeren en mulighet for en enkel og rask navigasjon mellom disse. Navigasjonen utføres ved at brukeren gjør en bevegelse fra kanten av skjermen, ut mot midten Søk Kravspesifikasjon: Søking etter materiale(eksempel ved tittel, forfatter, utgivelsesår) Denne delen tar for seg søking av materiale fra bibliotekdatabasen. Her blir det listet ut ulike informasjon som tittel, forfatter osv. Aktiviteten trenger internettforbindelse for å kunne kommunisere med serveren. Figur 2.5: Illustrasjon av søk 37

38 3.1.3 Min Side Kravspesifikasjon: Oversikt over bestillinger og lån Min Side skal gi brukeren en oversikt over ulik informasjon som er under brukerens konto. Kravet til brukeren her er at han/hun har et brukernavn og passord fra Bibsys. Er ikke dette tilgjengelig linkes dette i aktiviteten for innlogging, men også nederst i kilder hvis vedlikeholder eller fremtidige ansvarlig for applikasjonen trenger dette. Aktiviteten trenger også internettforbindelse for å kunne kommunisere med serveren. Figur 2.6: Illustrasjon av min side Innstillinger Innstillinger gir brukeren muligheten til å justere applikasjonen ut ifra deres preferanser. Fra denne aktiviteten kan innstillingene påvirke alle av applikasjonens hoveddeler. Figur 2.7: Illustrasjon av innstillinger 38

39 3.2 Applikasjonens hoveddeler Dette delkapitlet gir en mer detaljert forklaring på produktets hovedaktiviteter Info Brukte filer: HjemActivity.java, HjemSwipeActivity.java, activity_hjem.xml, activity_hjem_swipe.xml Som tidligere nevnt er Info delt opp i flere deler. Info har sin egen meny der knappene videresender brukeren til den ønskede siden. Aktiviteten oppfører seg stort sett statisk og krever ikke innlogging. Figur 2.8 : Illustrasjon av info Kurs Brukte filer: fragment_kurs.xml, KursFragment.java, radlayout.xml, ListAdapter.java Under Kurs er det mulighet for å velge mellom to kategorier, lynkurs og studieverksted. Elementene som er listet ut er bestemt av hvilken kategori som er valgt. Disse inneholder bare tittelen, men hvis det trykkes på dem, blir det ekspandert for å vise ytterligere relatert informasjon. Figur 2.9.1: Illustrasjon av Kurs Figur 2.9.2: Illustrasjon av Kurs 39

40 Verdiene er hentet fra en array fra filen arrays.xml. Hvis det skal tilføyes et nytt element så kan det gjøres via XML filen. Syntaksen er slik: <item> Tittel // Brødtekst // Dato og Sted</item> Figur 2.10: Syntaks for kurs-verdier <item>eric // Hvordan finne artikler innen pedagogikk i en internasjonal database. // Onsdag 27. februar kl (Kjeller, rom F-224)</item> Figur 2.11: Eksempel fra XML Tittel, brødtekst og dato/sted er nødvendig. // er brukt for å skille mellom verdiene. Denne aktiviteten har sin egendefinert listadapter der det bestemmes hvor disse ulike verdiene skal plasseres. String[] info = kurs.get(position).split("//"); overskrift.settext(info[0]); tekst.settext(info[1]); tid.settext(info[2]); Figur 2.12: Utdrag fra KursFragmenter.java Mobile Tjenester Brukte filer: fragment_mobile_tjenester.xml, MobileTjenesterFragment.java, radlayout_mtjenester.xml, ListAdapterTjenester.java Mobile tjenester er en liste over leverandører som har avtaler med læringssenteret. Informasjonen er presentert på samme måte som Kurs men har en ekstra funksjon. Holdes det på et av elementene, så åpnes nettleseren og sendt videre det til leverandørens nettside. I noen av tilfellene der det ikke er et nettsted, men en applikasjon, så åpnes Google Play(Android sin versjon av applikasjonsbutikk). Figur 2.13: Illustrasjon av mobile tjenester 40

41 Syntaksen for innsetting av nye verdier er ganske lik den forrige bortsett fra at det ikke er nødvendig med dato og sted. <item> Tittel // Brødtekst </item> Figur 2.14 : Syntaks for verdier i mobile tjenester <item>ordnett//søk i ordbøker på mobilen. Logg inn med din HiOA-login.</item> Figur 2.15 : Eksempel fra XML I tillegg til dette må det også legges inn en lenke i java koden. Dette er inne i en lytter som tilhører et listview. lv = (ListView) viewen.findviewbyid(android.r.id.list); lv.setonitemlongclicklistener(new OnItemLongClickListener() public boolean onitemlongclick(adapterview<?> arg0, View view, int position, long id) { Intent BrowserIntent = null; switch (position) { case 0: BrowserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("market://details?id=no.bibsys.appl.mypage")); break;... case 14: BrowserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(" break; } startactivity(browserintent); return true; }}); Figur 2.16: Utdrag fra MobileTjenesterFragment.java 41

42 Åpningstider Brukte filer: fragment_aapningstider.xml, AapningstiderFragment.java Åpningstider presenterer tid for når de ulike byggene/områdene er åpent. Tiden for dagens dato er markert litt mer enn vanlig, for å gjøre det enklere for studenten. Ulikt fra de tidligere delene, så er informasjonen skrevet inn i Java kode. Skal det legges til eller endre spesifikke verdier må det gjøres der. Figur 2.17: Illustrasjon av åpningstider <string-array name="array_aapningstidvalg"> <item>biblioteket Kjeller</item> <item>læringssentrene Pilestredet</item> <item>studieverkstedet</item> <item>digital og AV-tjeneste</item> <item>p48, 1. etg (pc-plasser/tidsskrifter)</item> <item>p48, døgnåpent rom (rom S154)</item> </string-array> Figur 2.18: Verdier som blir brukt for å fylle spinner case 5: settinntid(new String[] { "00:00-00:00", "00:00-00:00", "00:00-00:00","00:00-00:00", "00:00-00:00", "00:00-00:00", "00:00-00:00" }); Figur 2.19 Utdrag av kode som setter inn åpningstiden. Her settes det tid for hvert element i en use-case. Syntaksen for arrayen er utefra ukedagene. I dette tilfellet er det tiden for P48, døgnåpent rom (rom s154) som blir satt. 42

43 Kontaktinfo Brukte filer: fragment_kontaktinfo.xml, KontanktInfoFragment.java Her blir det vist telefonnummer, adresse og kontakt for ulike entiteter. Brukeren kan også velge mellom å se et kart som viser entitetens lokasjon, ringe telefonnummeret eller sende en e-post. Disse metodene har en try-catch, som tas imot hvis disse tjenestene ikke er tilgjengelig. Entitetene er hentet fra XMLen, og deres informasjon fylles fra Java koden. Figur : Illustrasjon av kontakt info Figur : Feilmelding hvis utvalgt funksjon ikke kan brukes Button adresseknapp = (Button) viewen.findviewbyid(r.id.kontaktinfo_tv_adresse); adresseknapp.setonclicklistener(new OnClickListener() public void onclick(view v) { String adr = tvadresse.gettext().tostring(); Intent viewonmap = new Intent(Intent.ACTION_VIEW, Uri.parse(String.format("geo:0,0?q=%s",URLEncoder.encode(adr)))); try { startactivity(viewonmap); } catch (ActivityNotFoundException e) { Toast.makeText(getActivity().getApplicationContext(), getstring(r.string.kartapp), Toast.LENGTH_LONG).show(); } }}); Figur 2.21 : Utdrag av kode som lager lytteren til knappen for kart funksjonen <string-array name="array_kontaktvalg"> <item>biblioteket Kjeller </item> <item>læringssenteret P48 (IT-støtte)</item> <item>læringssenteret PP (IT-støtte)</item> <item>læringssenteret P35 (IT-støtte)</item> <item>læringssenteret P32</item> <item>studieverkstedet</item> <item>digitale tjenester</item> <item>medieseksjonen</item> </string-array> Figur 2.22 : Verdier som blir brukt for å fylle spinneren case 7: oppdater(" ", "av@hioa.no", getstring(r.string.p48_adr)); break; Figur 2.23 : Utdrag av kode som setter inn verdier inn i ulike deler av aktiviteten 43

44 IT-Støtte Brukte filer: fragment_itstotte.xml, ItStotteFragment.java Aktiviteten henviser til informasjon om hvor og når studentene kan få hjelp fra IT-ansvarlig, samt telefonnummer og e-post adresse. Oppsettet er veldig lik forrige avsnittet, Kontaktinfo. Knappene er knyttet til spesielle lyttere der det gis imot en feilmelding hvis dette ikke kan utføres. Verdiene hentes på lik måte som Kontaktinfo. Figur 2.24 : Illustrasjon av IT- Støtte Campuskart Brukte filer: fragment_campuskart.xml, CampustKartFragment.java Viser kart over campusene i Pilestredet og Kjeller. Aktiviteten viser to ImageView som er under hverandre. <ImageView android:layout_width="wrap_content" android:layout_height="250dp" android:layout_margintop="10dp" android:scaletype="fitcenter" android:src="@drawable/pilestredet" /> Figur 2.25 : Utdrag av XML som viser et bilde Søk Søk krever ingen innlogging, men den krever en Figur 2.26 : Illustrasjon av Campuskart internettforbindelse som skal sørge for å hente inn verdier fra Bibsys databasen. Brukeren kan velge å søke blant alle mulige treff, eller spesifisere søket på tittel, forfatter, emne eller årstall for utgivelse ved å velge fra dropdownlisten til høyre for X. Antall treff vises på bunnen av siden, og mer-knappen vil hente opptil 10 nye treff for hver gang. Ved trykk på ett av listeelementene vil brukeren videreføres til informasjonssiden for det utvalgte elementet. Mer detaljert Figur 2.27: Illustrasjon av Søk 44

45 informasjon vil vises hvis det er tilgjengelig. Kommunikasjon mot server skjer ved at en bakgrunnstjeneste sender forespørsel og mottar data i form av et JSON-objekt. Spesifikke/utvalgte verdier sjekkes og hentes ut hvis de er tilgjengelige. Disse dataene blir videresendt og listet opp i søk aktiviteten, samtidig som det settes en lytter for elementvalg. jsonparser.getjsonfromurl(url + "ts=" + d.gettime() + "&cql=" + params[1] + params[0] + "&page=" + page); hmut.put("title", jsono_infoto.getstring("title")); if (jsona_infoto.length() > 0) { hmut.put("isbn", con.getresources().getstring( R.string.sok_merinfo_isbn) + " " + jsona_infoto.getstring(0)); } Figur 2.28: Utdrag av kode Mer Informasjon Her får brukeren mer informasjon om det valgte elementet hvis det er tilgjengelig. Her kan brukeren også velge å bestille/reservere elementet, dette krever da innlogging på forhånd. Dette skjer ved å sende med som parameter, det av informasjon som er tilgjengelig, tittel, forfatter, ISBN, årstall og element-id i bibliotekbasen. Serveren håndterer om forespørsel er bestilling eller reservering, og tilbakemelding fra server blir vist for brukeren. Figur 2.29: Detaljert informasjon av materiale jsono_info = jsonparser.getjsonfromurl(url + "ts=" + d.gettime() + "&isbn=" + Uri.encode(params[0]) + "&title=" + Uri.encode(params[1]) + "&creator=" + Uri.encode(params[2]) + "&year=" + Uri.encode(params[3]) + "&pid=" + Uri.encode(params[4]) + "&sid=bibliotekbasen"); if (!jsono_infotre.getstring("orderid").equals(""))res = con.getresources().getstring(r.string.sok_merinfo_bestille) + " " + jsono_infotre.getstring("orderid"); Figur 2.30: Utdrag av kode for bestilling/lån/reservering 45

46 3.2.3 Logg inn Her vil brukeren se et skjema for innfylling av brukernavn og passord, som kobler seg opp mot server for autentisering, eller viser eventuelle feilmeldinger. Hvis brukeren ikke har noe passord har han/hun mulighet til å trykke på knappene for så å bli videreført til nettsiden for Bibsys-adgangskontroll og kan da bestille passord. Hvis brukeren har aktivert automatisk innlogging, vil brukeren autentiseres med informasjon som er lagret. Skjemaet for innlogging vil da ikke vises Personlig Informasjon Her listes opp personlig informasjon som navn, adresse og mobilnummer. Herfra kan brukeren velge å logge ut, og automatisk innlogging vil ikke skje før brukeren restarter applikasjonen. Dette for å hindre at brukeren logges inn hver gang han/hun kommer til Min side. Brukeren kan se sine lån/bestillinger/reservasjoner ved å velge fra dropdownlisten. Figur 2.31 : Ilustrasjon ved feil innloggings verdier Figur 2.32: Illustrasjon av personlig informasjon 46

47 Lån/Bestilling/Reservasjon Ved visning av lån kan brukeren fornye lånet hvis det lar seg gjøre. Ved bestillinger/reservasjoner kan brukeren slette bestillingen/reservasjonen hvis det er ønsket Innstillinger Brukte filer: fragment_innstillinger.xml, InnstillingerActivity.java Innstillinger gir brukeren en mulighet for å stille inn applikasjonen etter sitt eget ønske. Figur 2.33 : Illustrasjon av lån En av innstillingene er muligheten for valg av norsk eller engelsk som språk. Det er også mulig å bytte ut ifra språket som er på enheten, men vi valgte å sette dette inn i applikasjonens innstillinger for lettere tilgjengelighet. Brukeren kan også aktivere automatisk innlogging for å slippe å taste inn brukernavn og passord hver gang. Figur 2.34 : Innstillinger if (autoinn) { mbrukernavn = sp.getstring("bnavn", ""); mpassword = sp.getstring("bpass", ""); Figur 2.35 : Utdrag av kode som henter brukernavn og passord automatisk hvis autoinnlogging er aktivert Figur 2.36 : Ulike språk mappene 3.3 Design Designmessig ønsket ikke gruppen om å gå langt ifra fargeoppsettet LSB/HiOA allerede har. Det består hovedsakelig av nøytrale farger, men med noen oransje detaljer. Som de eksisterende løsningene som er nevnt, tilbyr de en flott kontrast som ikke gjør det vanskelig for brukere å lese informasjonen. Dette ville vi også ta med i vår applikasjon. 47

48 Figur 2.37 : Skjerm bilde av Figur 2.38 : Skjermbilde av applikasjonen Som vist over kan man se likhetene og hvor vi har hentet inspirasjon fra. Målet med designet var å få studentene til å gjenkjenne applikasjonen med nettstedet, samtidig som at den er litt selvstendig når det gjelder utseende. I applikasjonen er det brukt en god del dropdownlister. Dette er på grunn av at vi ikke vil vise for mye informasjon i en aktivitet. Vi ville ha minst mulig scrolling og dermed delte vi opp disse i dropdownlister. De viser forklaringene ut ifra hvilken kategori som er valgt. Denne forhindret overflødig tekst på et sted. Når det gjaldt knappene har vi brukt et felles utseende på dem, med grunnlag av å skille mellom knapper og alt annet. Figur 2.39 : Illustrasjon av spinner Figur 2.40: Illustrasjon av knapper 48

49 3.4 Klasser/Filstruktur Fil-tre Figur 2.41 : Java filer Figur 2.42 : XML filer 49

50 4 Diagrammer & Use Case 4.1 Use Case(Brukstilfelle) Under er en brukstilfellemodell, som er en illustrasjon av hva programmet gjør og dens hovedfunksjoner. Figur 2.43: Use case 50

51 4.2 Detaljerte Use Case beskrivelser Under er det modeller for de funksjonene vi mener er viktigst Beskrivelse: Søking etter materiale Hovedaktør: Bruker(Student) Prebetingelse: Enheten må ha tilgang til internett Postbetingelse: Applikasjonen har listet ut informasjon Hovedscenario: Brukeren skriver inn søketekst Applikasjonen sender forespørsel og lister ut resultat Utvidelser/avvik: Søknadsteksten returnerer ingen verdier o Det vises en feilmelding Beskrivelse: Innlogging Hovedaktør: Bruker(Student) Prebetingelse: Enheten må ha tilgang til internett, må ha en brukerkonto i Bibsys Postbetingelse: Brukeren er logget inn Hovedscenario: Brukeren skriver inn brukernavn og passord Applikasjonen sender forespørsel og bekrefter verdiene Sendes videre til Min Side Utvidelser/avvik: Brukerinformasjonen stemmer ikke o Vises en feilmelding om dette Brukeren har ikke brukerkonto o Vises en feilmelding og brukeren får en mulighet om å registrere seg 51

52 4.3 Aktivitetsdiagram Søk Innlogging 52

53 4.3.3 Min Side 53

54 5 Forhold til maskiner 5.1 Programvare For å kunne kjøre mbib-applikasjonen er det ikke satt mange spesifikke krav. Det som trengs er en Androidenhet som kjører Android API 16 eller høyere. For å kunne ta i bruk noen av tjenestene er det nødvendig for enheten å ha nettleser, e-post applikasjon og en kartleser. 5.2 Maskinvare Det settes ingen krav når det gjelder maskinvare. Det brukes veldig lite RAM og lagrer ikke data til enheten 6 Avsluttende del 6.1 Mulige utvidelser Skanning Grunnet begrenset kapasitet fikk ikke gruppen utviklet de mulige utvidelsene vi hadde som mål. En av disse var å låne materiale ved å skanne det utvalgte objektet. Dette fant vi ut at det blir litt vanskelig ettersom en avmagnetisering var nødvendig. I stedet for lån, var en mulig utvidelse å skanne selve materiale, for å få relaterte stoff Retningsveileder En annen funksjon kunne vært en aktiv retningsveileder som kunne vise for studenten hvor for eksempel en bok var. Det finnes en eksisterende funksjon som Bibsys bruker, men det vi mener er et mer interaktivt veileder, som fungerer lik som en GPS Sosiale medier Applikasjonen kunne fått enda mer potensiale hvis det var mulig å knytte applikasjonen mot sosiale medier. Dette er noe de fleste applikasjoner tilgjengelig i markedet har i dag, og kan være med på øke brukeropplevelsen hos flere. Her kunne brukere eventuelt søke etter materiale eller velge fra tidligere lån, og anbefale disse gjennom Facebook, Twitter, Google+ etc. 54

55 6.1.4 Universell utforming Når det gjelder grensesnittet til applikasjonen, mener vi at det er lite å klage over når det gjelder utseende. Vi har brukt farger som utgjør en bra kontrast og elementer der deres funksjoner er forståelig. Et annet tenkelig funksjon i produktet er å utvide tilgjengeligheten. Her kunne brukeren eventuelt forstørre teksten, invertere farge og få en opplesning av tekster. 6.2 Konklusjon mbib-gruppen sier seg veldig fornøyd med det resulterende produktet. Produktet er et oversiktlig program, både når det gjelder det funksjonelle grensesnittet og med tanke på kildekoden og dens potensiale for videreutvikling. Som alle andre applikasjoner tar det litt tid før man har satt seg inn i koden, men dette er noe som absolutt ikke er umulig. Applikasjonen er et kjørbart program som er klar for å settes i bruk hvis arbeidsgiver ønsker dette. Vi håper at dette kan være en del av erstatningsløsningen av den mobiltilpassede siden. 55

56 56

57 Testdokumentasjon 57

58 1 Test nr 1: Søk Formål Forsøke og søke etter læringssenterets materialer i alle mulige skjermstørrelser, ved tittel, forfatter, emne og årstall Deler ved søk Skrivefelt for søk Søkeknapp Dropdownlist for kategori Oppsett av testen Utviklingsprogrammet Eclipse der vi får tilgang alle mulige emulatorer (skjermstørrelser). Andre mobil enheter og nettbrett (Samsung Galaxy S2/S3 og Samsung Galaxy Tab 2) Test metode Data 1. Åpne en emulator med den valgte skjermstørrelse 2. Trykke på søk ikon øverst i menyen (Actionbar) 3. Skriver inn i søkefeltet (tittel) 4. Trykk på søk knapp og får resultatet 5. Gjenta dette med forfatter, emne og årstall 6. Repeter dette med alle mulige skjermstørrelser Samtlige informasjon skal kunne komme etter søket. Tittel Forfatter Emne Årstall Forventet resultat Det skal kunne komme ut tittel, forfatter og årstall ved søk av tittel Det samme skal komme ved valg av forfatter-, emne- og årstall-søk. 58

59 Resultatet Skjermstørrelse Søk ved tittel Søk ved forfatter Søk ved emne Søk ved årstall 2.7 Ok Ok Ok Ok 3.2 Ok OK Ok Ok 3.3 Ok Ok Ok Ok 3.4 Ok Ok Ok Ok 3.7 Ok Ok Ok Ok 4.0 Ok Ok Ok Ok 4.65 Ok Ok Ok Ok 4.7 Ok Ok Ok Ok 5.1 Ok Ok Ok Ok 5.4 Ok Ok Ok OK 7.0 Ok Ok Ok Ok 7.2 Ok Ok Ok Ok 10.1 Ok Ok Ok Ok Kommentar til resultatet Ingen hindringer eller forsinkelser som fikk søket til å fungere. Konklusjon Det fungerer som planlagt 2 Test nr 2: Bestilling av materialet Formål Få å bestille læringssenterets materialer, bøker, cd-er, dvd-er, e-bøker, lydbøker osv. Deler ved bestilling For bestilling er det krav at man har en bruker (Bibsys bruker) og må være innlogget Bestilling/reservering knapp Kvittering på bestilling Nødvendige tekniske utstyr for testingen For testingen trenger man en enhet som kan kjøre applikasjonen. I vårt tilfelle hadde vi 59

60 emulatoren som vi har tilgang til via utviklingsprogrammet Eclipse. Vi testet også ved hjelp av mobil- og nettbrett-enheter som er tilpasset for Android (Samsung Galaxy Tab 7 og Samsung S2/S3). Test metode 1. Først logge inn med en Bibsys bruker 2. Søk etter materialet 3. Klikk deretter inn i materialet 4. Klikk deretter bestill/reserver 5. Gjenta dette med alle tilgjengelige materialer Kvittering Etter bestillingen skal det være en bekreftelse at man har bestilt i form av en kvittering. Forventet resultat Vi forventer at materialet som er bestilt, blir listet opp i bestillingslisten. 60

61 Resultatet Materialer E-tidsskrifter Trykte tidsskrift Nettressurser DVD-er DCROM-er E-Bøker Bøker Lydbøker Videoer Kart Musikk-CD-er Musikkspor Musikkassetter Musikk-LP-er Musikknoter Artikler og bokkapitler Doktoravhandlinger Master- og hovedfagsoppgaver Studentoppgaver Bestilt/reserver Ok Ok Finner ingen Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Finner ingen Finner ingen Finner ingen Kommentar til resultatet Blir et problem å søke etter materialer som ikke finnes, som studentoppgaver, master- og hovedoppgaver osv. Konklusjon Det virker som vi har planlagt, bare at databasen ikke har alle de materialene. 61

62 3 Test nr 3: Link, mail og ringing Formål At tilleggsfunksjoner som link, mail og ringing sender deg til riktig enhetsfunksjoner som støtter link, mail og ringing. Deler ved linker, mail og ringing Spinner som lar seg velge hvilken kategori man skal til En funksjon som åpner og skjuler den informasjonen Enhet testing For denne testen må vi bruke en enhet som har disse enhetsfunksjonene som gjør det mulig å åpne en nettleser og sender deg til riktig link. Funksjonen som lar deg sende mail og ringefunksjonen for enheten. Vi tok i bruk en Android tilpasset mobil som kunne foreta disse handlingene (Samsung S3). Test metode Navigere deg til stedene hvor det finnes disse funksjonene (link, mail, telefonnummer) Klikk dermed på funksjonen Sender deg videre til enhetsfunksjonen (enten nettleser, sende mail eller til ringefunksjonen) Gjør dette med alle linker, mailer og telefonnummer som finnes i applikasjonen Enhetsfunksjon For linker, skal det åpne en nettleser og sender deg til riktig link For mail adresser, skal det åpne en epost funksjon som gir deg muligheten til å sende en mail til riktig mail adresse For telefonnummer, skal man komme til ringefunksjonen i riktig telefonnummer 62

63 Forventet resultat Vi forventer at: De riktige linkene, sender deg til riktig webside/sted o Bibsys MinSide fører deg til Play Butikk, der man kan laste ned Bibsys MinSide applikasjonen o Britannica fører deg til o Ordnett fører deg til o Wikipedia fører deg til o EBSCOhost (Nettside) fører deg til o EBSCOhost (Applikasjon) fører deg til Play Butikk, der man kan laste ned EBSCOhost applikasjonen o Emerald fører deg til o HelseBibloteket fører deg til o Idunn fører deg til o IEEE fører deg til o JSTOR fører deg til o Nature fører deg til o ScienceDirect fører deg til Play Butikk, der man kan laste ned ScienceDirect applikasjonen o Science fører deg til Play Butikk, der man kan laste ned Science applikasjonen o Web of Knowledge fører til De riktige adressene, epostene og telefonnumrene sender deg til riktig enhetsfunksjon. o Kontaktinfo (Biblioteket Kjeller) Adresse linken skal være Kunnskapsveien 55, 3. etg. Telefonnummer skal være Eposten skal være lsb-kjeller@hioa.no o Kontaktinfo (Læringssenteret P32) Adresse linken skal være Pilestredet 32 Telefonnummer skal være Eposten skal være lsb-pp@hoa.no o Kontaktinfo (Studieverkstedet) Adresse linken skal være Pilestredet 48, 3. etg. Telefonnummer skal være Eposten skal være studieverkstedet@hioa.no o Kontaktinfo (Digitale tjenester) Adresse linken skal være Pilestredet 48, 3. etg. 63

64 Resultatet Telefonnummer skal være Eposten skal være o Kontaktinfo (Medieseksjonen) Adresse linken skal være Pilestredet 48, 3. etg. Telefonnummer skal være Eposten skal være o IT-Støtte (Læringssenteret P48) Telefonnummer skal være Eposten skal være o IT-Støtte (Læringssenteret PP) Telefonnummer skal være Eposten skal være o IT-Støtte (Læringssenteret P35) Telefonnummer skal være Eposten skal være Mobile Tjenester Bibsys MinSide Britannica Ordnett Wikipedia EBSCOhost (Nettside) EBSCOhost (Applikasjon) Emerald Helsebibloteket Idunn IEEE JSTOR Nature ScienceDIrect Science Web of Knowledge Linker Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok Ok 64

65 Kontaktinfo (Biblioteket Kjeller) Telefonnummer E-post Adresse Riktig enhetsfunksjon Ringe Ok Mail Ok Kart Ok Kontaktinfo (Læringssenteret P32) Telefonnummer E-post Adresse Riktig enhetsfunksjon Ringe Ok Mail Ok Kart Ok Kontaktinfo (Studieverkstedet) Telefonnummer E-post Adresse Riktig enhetsfunksjon Ringe Ok Mail Ok Kart Ok Kontaktinfo (Digitale Tjenester) Telefonnummer E-post Adresse Riktig enhetsfunksjon Ringe Ok Mail Ok Kart Ok Kontaktinfo (Medieseksjonen) Telefonnummer E-post Adresse Riktig enhetsfunksjon Ringe Ok Mail Ok Kart Ok IT-Støtte (Læringssenteret P48) Telefonnummer E-post Riktig enhetsfunksjon Ringe Ok Mail Ok 65

66 IT-Støtte (Læringssenteret PP) Telefonnummer E-post Riktig enhetsfunksjon Ringe Ok Mail Ok IT-Støtte (Læringssenteret P35) Telefonnummer E-post Riktig enhetsfunksjon Ringe Ok Mail Ok Kommentar for resultatet Det er kun for mobilenheter som har den muligheten til å ringe når man trykker på telefonnummeret. For andre enheter som nettbrett uten 3G, så kan man kun lagre telefonnummeret til kontakter. Når det gjelder adressen, vil de enhetene med kart, kunne få opp konkret hvor adressen befinner seg. Til slutt har vi epostene, som støtter alle enheter som har en mail funksjon. Konklusjon Det viser seg at alle funksjoner virker som det skal hvis enheten har de funksjonene som støtter kart, mail og ringing. 66

67 4 Test nr 4: Farge Formål Teste om fargekombinasjonen er egnet for all fargeblindhet. Farger Disse fargene har vi brukt for applikasjonen. For det første var det for å designe så likt som mulig som designen til hjemmesiden for HiOA. Dermed brukte vi de fargene som de allerede har på sin hjemmeside. Farger Hexkode RBG-kode Test fargen Svart # R: 49, G:48, B:49 Grå #D6D7D6 R: 214 G: 215, B: 214 Orange #E17300 R: 225, G: 115, B: 0 Hvit #FFFFFF R:255, G: 255, B: 255 Andre midler for testing For å teste ut fargen: Gjorde vi ved hjelp av en webside kalt for Colorfilter.wickline.org. Vi må ha en server (stud.hio.no skolens server) der vi får lastet opp en html side, hvor vi har bilder av applikasjonen med fargene. o Vi brukte: Colorfilter.wickline.org Dette er en webside hvor vi kan teste ut fargeblindhet, ved å filtrere bort farger. Denne websiden vil ta for oss de mest vanlige fargeblindhet, og sjekke om det er egnet for fargeblindhet. De mest vanlige fargeblindhetene er: Protanopia (rød/grønn fargeblindhet; ingen rød membran) Deutanopia (rød/grønn fargeblindhet; ingen grønn membran) Tritanopia (Blå/gul fargeblindhet; ingen blå membran) 67

68 Grayscale/achromatospsia (For alle fargeblindhet) Atypical achromaatopsia (Lavt membran funksjon; membran monokromat) Protanomaly (Unormal rød membran) Deutanmaly (Unormal grønn membran) Tritanmaly (Unormal blå membran) Test metode 1. Laste opp html siden med bildene/fargene 2. Skrive url-en inn i colorfilter.wickline.org 3. Tester ut alle mulige fargeblindhet Forventet resultat For all fargeblindhet, vil fargene ikke ha så mye å si når det gjelder leselighet, ikoner, knapper, felt og kart. Resultatet Fargeblindhet Leselig Ikoner Knapper Felter Kart Protanopia Ok Ok Ok Ok Ok Deutanopia Ok Ok Ok Ok OK Tritanopia Ok Ok Ok Ok OK Grayscale/achromatospsia Ok Ok Ok Ok Ok Atypical achromaatopsia Ok Ok Ok Ok Ok Protanomaly Ok Ok Ok Ok Ok Deutanmaly Ok Ok Ok Ok OK Tritanmaly Ok Ok Ok Ok OK 68

69 Figur 3.1: Orginal Figur 3.1: Protanopia 69

70 Figur 3.2: Protanomaly Figur 3.3: Deutanopia 70

71 Figur 3.4: Deutanmaly Figur 3.5: Tritanopia 71

72 Figur 3.6: Tritanomaly Figur 3.7: Atypical Achromatopsia 72

73 Figur 3.8: Grayscale Achromatopsia Kommentar til resultat Ingen stor forandring mellom original og de fargeblinde eksemplene Konklusjon Alt er leselig og som forventet. 73

74 5 Test nr 5: Plassering Formål Få tilgang til alle knapper så lett som mulig Plassering Plasseringer hvor det lett tilgjengelig å trykke og komme frem til Test enheter Mobile enheter og nettbrett, (Samsung S2/S3 og Samsung Galaxy Tab S2) Test metode Teste med en hånd, slik at jeg rekker alle funksjonene i applikasjonen: Knapper Skrive felt Dropdownliste Teste med to hender, om de er lett tilgjengelig: Knapper Skrive felt Dropdownliste Forventet resultat Alle knapper og felter, skal være lett tilgjengelig, både en hånd og to hender. 74

75 Resultatet En hånd Knapper Skrive felter Dropdownlister Godkjent Ok Ok Ok To hender Knapper Skrive felter Dropdownlister Godkjent Ok Ok Ok Kommentar til resultatet Med en hånd, har vi plassert knappene og ikonene, slik at man skal kunne holde telefonene og rekke fram til alle funksjoner med tommelen. Med to hender, har vi plassert det slikt at det skal være lett og trykke uansett hvilken mobil enhet det er snakk om. Konklusjon Testingen viser at det er lett å navigere seg rundt i applikasjonen som forventet. 75

76 6 Test nr 6: Responstid Formål Finne ut om applikasjonen har noen forsinkelser når det gjelder å finne informasjon, linker, ringing, mail, kart, søk, bestilling/reservering, innlogging/utlogging, forny lån og slett bestilling. Responstid Funksjonene i applikasjonen skal ha minst mulig responstid (under 1 sekund) Alle funksjoner som omhandler databasen må ikke ha for lang responstid (under 3 sekunder) Test enheter Mobile enheter eller nettbrett (Samsung S2/S3 eller Samsung Galaxy Tab S2) En stoppeklokke Testmetode Teste de generelle funksjonene i applikasjonen 1. Finne informasjon 2. Linker 3. Kart 4. Telefon 5. Mail Teste funksjoner som omhandler en database 1. Søk 2. Bestilling/Reservering 3. Innlogging/utlogging 4. Forny lån 5. Slett bestilling Forventet resultat Forventer de generelle funksjonene skal bruke mindre enn 1 sekund Forventer at de funksjonene som omhandler databasen vil være mellom 1-3 sekunder 76

77 Resultatet Funksjoner Finne informasjon Linker Kart Telefon Mail Responstid 0.2 sek 1.0 sek 0.2 sek 0.2 sek 0.2 sek Funksjoner som omhandler databasen Søk Bestilling/reservering Innlogging/utlogging Forny lån Slett bestilling Responstid 1.8 sek 1.0 sek 0.7/0.6 sek 2.0 sek 2.0 sek Kommentar til resultat For de generelle funksjonene, så var det som forventet unntatt funksjonen link. Grunnen til at denne funksjonen hadde lengre responstid er fordi man må holde inne tittelen før den sender deg videre. Og ved å holde inne tittelen bruker enheten enda lengre tid til å registrere at brukeren utfører den handlingen og dermed ble responstiden 1 sekund i motsetning til de andre generelle funksjonene som hadde responstid på 0.2 sekund. For de funksjonene som omhandler med databasen, så var det som forventet at det skal variere mellom 1-3 sekunder, grunnet båndbredde og stor trafikk på server. Konklusjon Alt som ble forventet på forhånd, stemte med testingen. De generelle funksjonene hadde en responstid på 1 sekund eller mindre De funksjonene som omhandler databasen var mellom 1-3 sekunder. 77

78 7 Test nr 7: Navigering Formål Teste ut om man kan navigere seg rundt etter tre-klikk prinsippet. Det vil si ved tre klikk så skal man klare å navigere seg rundt i applikasjonen, tilgang til alle funksjoner ved tre klikk. ActionBar Denne menyen er en meny linje som inneholder blant annet informasjon, søk, min side og innstillinger. Ved hjelp av denne menyen vil det være enkelt å navigere seg rundt på, pga. at denne menyen er tilgjengelig hele tiden, bortsett fra Innstillinger. Test enheter Samsung Galaxy Tab S2 (Et nettbrett som er egnet for Android) Testmetode Figure 3.9: Actionbar Starte på startsiden 1. Klikk 1 En kategori ved ActionBaren 2. Klikk 2 Et valg på den kategorien 3. Klikk 3 Få ut den dataen, målet ditt var Forventet resultat Ved hjelp av maks tre klikk: Kunne komme seg til informasjon Kunne klare å komme seg til en link Kunne komme seg til kart Kunne ringe Kunne sende mail Kunne søke Kunne bestille/reservere Kunne logge seg inn/ut Kunne fornye lån Kunne avbestille 78

79 Resultatet Formål Finne informasjon Finne en link Finne adressen ved hjelp av kart Kunne ringe Kunne sende epost Kunne søke Kunne bestille Kunne logge seg inn/ut Fornye lån Avbestille Antall klikk 2 til 3 klikk spørs hva slags informasjon 3 klikk også hold inne tittelen 3 klikk 3 klikk 3 klikk 2 klikk gitt at man er innlogget 3 klikk gitt at man har søkt 2 klikk for logg inn / 1 klikk gitt at man er innlogget 3 klikk gitt at man er innlogget 3 klikk gitt at man er innlogget Kommentar til resultat Man klarer å navigere seg rundt ved hjelp av tre klikk, gitt at visse krav allerede må være der. Som for eksempel ved bestilling, så må man allerede har søkt og er innlogget. Eller ved avbestilling gitt at man har bestilt og er allerede innlogget. Dermed kan man komme fram til sine formål ved hjelp av tre klikk. Konklusjon Resultatet ble som forventet. 79

80 8 Sluttkonklusjon Testene bekrefter vår hypotese angående at applikasjonen er optimalisert for bruk av flest brukere. Søkefunksjonen er effektiv og søkeresultatene stemmer overens med databasen. Applikasjonen tilpasser seg på en fin måte til alle skjermstørrelser. Fargevalgene viser at innholdet er lett synlig for enhver bruker, både for svaksynte og fargeblinde. Responstesten viser til minst mulig ventetid ved funksjonene i applikasjonen. Navigasjonstesten bekrefter at 3-klikk-regelen overholdes. Det er enkelt å navigere seg rundt i applikasjonen. Plasseringer av knapper og tekstfelter gjør at man kan bruke applikasjonen med kun en hånd eller begge hender. Bestillingstesten og knappetesten bekrefter at alle funksjoner virker etter sin mening, så lenge kravene oppfylles f. eks tilgang til internett. 80

81 Vedlegg 81

82 82

83 Brukermanual 83

84 1 Generelt Denne brukermanualen retter seg mot sluttbrukere av mobilapplikasjonen. Formålet med brukermanualen er å veilede brukere til å laste ned, installere og bruke applikasjonen på sin Android telefon. Forkunnskapene som forutsettes av leserne til manualen er grunnleggende forståelse av bruken av en Android telefon. 2 Nedlasting og installasjon For å laste ned applikasjonen på en Android telefon besøker man denne linken fra telefonen. Deretter kan applikasjonen installeres hvis telefonen har Android API 16 eller oppover og telefonen er konfigurert til å akseptere applikasjoner fra Ukjente kilder. For å akseptere Ukjente kilder går man på mobilens Innstilinger, deretter Sikkerhet og huker av Ukjente kilder. 3 Hovedsidene Hovedsakelig er det fire hovedsider mobilapplikasjonen har. Disse er: 1. Informasjon 2. Søk 3. Min side 4. Innstillinger Vi vil se nærmere på hver av hovedsidene. 84

85 Informasjon For informasjon om LSB trykker man på informasjonsmenyen. slik at man blir sendt til Informasjon inneholder info om Kurs, Mobile Tjenester, og IT-støtte som LSB tilbyr og Kart, Kontaktinfo og Åpningstidene til LSB. Da man først trykker på Informasjon er det 6 knapper å velge mellom. Trykker man på en, åpnes det en ny side med mer informasjon, og man kan navigere til de 5 andre sidene ved å trykke på skjermen med en feiende bevegelse. Kurs gir en oversikt over alle lynkurs og studieverksted samt hvor og når de skjer. Mobile Tjenester lister en liste over noen av leverandørene som har utviklet mobiltilpassede tjenester. Her kan man lese om leverandørene eller besøke deres nettside. Åpningstider oppgir åpningstidene til de forskjellige avdelingene til HiOA. Kontaktinfo viser adresse, telefonnummer og epost til de forskjellige avdelingene. IT-støtte lister åpningstidene, telefonnummer og epost til avdelingene som tilbyr ITstøtte. Campuskart viser kart over Pilestredet og Kjeller. 85

86 Kurs På Kurs-siden er det en dropdownliste som bestemmer hva slags informasjon som vises. Det kan velges mellom Lynkurs og Studieverksted. Under vises noen av overskriftene til valgt kategori i listen. For mer informasjon trykker man på ønsket underkategori, og skuffen vil åpne seg. Man trykker igjen på overskriften for å lukke skuffen. Mobile tjenester På Mobile Tjenester-siden er det listet en liste med alle mobile tjenester LSB anbefaler. Som på Kurs-siden kan man trykke på overskriften for å åpne skuffen for å få mer informasjon om den spesifikke anbefalingen. Trykker man igjen vil skuffen lukke seg. Man kan også trykke og holde inne for å besøke deres nettside. For å se flere mobile tjenester må man bla ned i listen. Åpningstider På Åpningstider-siden er det en dropdownliste man velger hvilken avdeling man ønsker å se åpningstidene til. Åpningstidene endres etter valget og dagen man er i vil fremheves. Kontaktinfo På Kontaktinfo-siden er det en dropdownliste man velger hvilken avdeling man ønsker å se kontaktinformasjon til. Det vil bli vist adresse, epost og telefonnummer til den valgte avdelingen. Trykker man på adressen, vil kartapplikasjonen på mobilen åpnes for veibeskrivelse. Trykker man telefonnummeret vil man kunne ringe. Trykker man på epostadressen vil epostapplikasjonen på mobilen åpnes for sending av mail. 86

87 IT-støtte På IT-støtte er det en dropdownliste man velger hvilken læringssenter med IT-støtte man ønsker å se informasjon om. Det vil bli vist åpningstider, telefonnummer og epost til det valgte læringssenteret. Trykker man telefonnummeret vil man kunne ringe. Trykker man på epostadressen vil epostapplikasjonen på mobilen åpnes for sending av mail. Campuskart På Campuskart er det to kart over. Øverste er av Pilestredet, og under er et kart over Kjeller. Man må blad ned for å se andre kart. Søk For å kunne søke etter LSB sine utlånsmaterialer trykker man på slik at man blir sendt til søkesiden. Her kan man spesifisere søket ved å velge hva man ønsker å søke i dropdownlisten. Valgene er tittel, forfatter, emne og årstall. For å tømme søkefeltet trykker man på X. Etter at søkefeltet er fylt trykker man på søk-knappen for å søke. Det vil bli listet en liste med søkeresultater, for mer informasjon trykker man på et av elementene. Man kan bla ned i listen for flere elementer og trykke på Mer for å få enda flere søketreff. Mer info Trykker man på et av elementene i lista etter å ha søkt vil man bli videresendt til Mer infosiden. Her får man oversikt over tilgjengelig informasjon om materialet. Om man er innlogget har man også muligheten til å Bestille/Reservere materialet ved å rulle helt ned på siden og trykke knappen. Under er et bilde på hvordan man kan Bestille/Reservere. 87

88 Min side For å kunne se oversikt over personlig informasjon trykker man på slik at man blir sendt til Min side-siden. Det kreves først innlogging, deretter vil det være en dropdownliste som gir deg 4 valg. Disse er Min info, Lån, Bestillinger, Reservasjoner. For å se oversikten over brukerens navn, brukernummer, adresse, mobilnummer, epost, bibliotek, utlånssted velger man Min info i dropdownlisten. For en liste med alle lån velger man Lån. Det samme gjelder bestillinger og reservasjoner. Man får også til en hver tid muligheten til å logge ut ved å trykke Logg ut -ikonet ved overskriften. Innlogging For å kunne logge inn trenger man brukernavn og passord til sin Bibsys bruker. Om man enten har glemt eller ikke har passord kan man trykke Glemt passord eller Bestill passord. Er riktig informasjon skrevet og man trykker Logg inn, blir man sendt videre til Min side. 88