Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Prosessrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Prosessrapport

1 Innholdsfortegnelse 1 Innholdsfortegnelse... 1 2 Prosessdokumentasjon... 3 2.1 Gruppen... 3 2.2 Om oppdragsgiver... 3 2.3 Bakgrunn for oppgaven... 3 2.4 Dagens løsning... 4 2.5 Mål... 5 2.5.1 Oppgavens mål... 5 2.5.2 Egne mål... 5 3 Mobile plattformer... 5 4 Planlegging og metode... 6 4.1 Arbeidsforhold... 6 4.2 Arbeidsfordeling... 6 4.3 Planleggingsverktøy og metodikk... 6 4.3.1 Dokumentasjon... 6 4.3.2 Prosjekthjemmeside... 7 4.3.3 Utviklingsmodell/metode... 7 4.4 Teknologier og verktøy... 8 4.4.1 Netbeans... 8 4.4.2 Ajax... 8 4.4.3 JavaScript... 8 4.4.4 HTML/CSS... 8 4.4.5 jquery/jquery Mobile... 8 4.4.6 Dropbox... 8 4.4.7 Google Docs... 9 4.4.8 CodeIgniter... 9 4.4.9 JSON (JavaScript Object Notation)... 9 4.4.10 MySQL... 9 4.4.11 REST... 9 4.4.12 Phonegap Build... 9 4.4.13 Teambox... 9 4.4.14 SoapUI... 10 4.4.15 (OAuth)... 10

4.4.16 Balsamiq Mockups... 10 5 Faser... 10 5.1 Gjentatte faser... 10 5.1.1 Tilegning av kunnskap... 10 5.1.2 Risikohåndtering... 10 5.1.3 Endring og revurdering... 11 5.2 Utredningsfasen... 11 5.2.1 Fremgangsmåte... 11 5.3 Utviklingsfasen... 12 5.3.1 Fremgangsmåte... 12 5.3.2 Design mobilapplikasjon... 12 5.3.3 Design webside... 15 5.3.4 Problemer og løsninger... 16 5.4 Dokumentasjonsfasen... 17 6 Avsluttende del... 18 6.1 Det ferdige produkt... 18 6.2 Hva kun vært annerledes... 18 6.2.1 Phonegap... 18 6.2.2 Testing... 18 6.2.3 Navngivning og kommentarer... 19 6.3 Konklusjon... 19

2 Prosessdokumentasjon Prosessdokumentasjonen beskriver prosessen rundt utviklingen av applikasjonen. Dette inkluderer begrunnelse av beslutninger, vurderinger, hvordan vi har jobbet, dokumentasjon og teknologier. 2.1 Gruppen Gruppen består av to dataingeniørstudenter, Andreas Berglihn og Harald Svendsen. Vi har tidligere jobbet sammen på diverse prosjekter og gruppearbeid v/hioa og vet av erfaring at vi har et godt samarbeid. 2.2 Om oppdragsgiver Slik presenterer Accenture seg selv. «Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Vi leverer nyskapende løsninger og samarbeider med kundene, slik at de kan realisere sine visjoner og skape verdi for seg selv. Med vår omfattende bransjeekspertise, våre globale ressurser og vår erfaring innenfor konsulentvirksomhet og driftsutsetting kan vi mobilisere de riktige menneskene og den nødvendige kompetansen for å hjelpe våre kunder til å bli virksomheter med høy prestasjonsevne. Med mer enn 186.000 ansatte i 49 land hadde Accenture en omsetning på 23,40 milliarder dollar i regnskapsåret som ble avsluttet 31. august 2007.» Accenture s hjemmeside: www.accenture.com eller www.accenture.no 2.3 Bakgrunn for oppgaven Accenture setter per i dag opp jobbsamtaler og arrangementer med å bestille sted/rom, setter opp timeplan, bestiller nødvendige ressurser, informerer HR om arrangement og gir telefonnummer til den som bestiller sted/rom, sender ut sms/mail til student om avtalt tid og sted. Deretter, hvis det er snakk om jobbsamtale, er det avhengig av om rommet er ledig. Hvis ikke, og studenten ikke kan komme på et annet tidspunkt, så tas samtalen per telefon.

Alt dette skal vi putte i en og samme applikasjon. Den skal kunne sette opp avtaler, sende ut mail og legge inn avtalte møter i intern kalender. Det vil spare ansatte mye tid og vil gjøre det lettere å finne ledig rom/sted og jobbsamtaleressurs/arrangementansvarlig. 2.4 Dagens løsning Accenture tar i dag i mot påmeldinger fra studenter for jobbsamtaler og andre arrangementer på stands på karrieredager, eller at studenten sender en SMS. Dette innebærer at Accentures ansatte må bruke mye tid og ressurser på å sette opp møter. Dagens prosess: Bilde: 2,1

2.5 Mål 2.5.1 Oppgavens mål Målet med prosjektet er å utvikle et system som skal gjøre det enklere for Accenture å sette opp jobbsamtaler med studenter og for å la studenter melde seg på ulike arrangementer som Accenture måtte holde. Dagens rutiner krever en del manuelle steg og et hovedmål er at det nye systemet skal være tidsbesparende for Accentures konsulenter samt sørge for bedre kvalitet og brukeropplevelse for studentene de møter. Løsningen skal integreres mot en SharePoint-portal hos Accenture. Ellers har gruppen stått fritt til å velge utviklingsverktøy og hvordan løsningen implementeres. 2.5.2 Egne mål Våre egne mål er å utvikle en mobilapplikasjon vi selv og sluttkunde er fornøyd med. Den skal være enkel i bruk med riktig funksjonalitet og responstid. Vi skal gjøre en jobb for å gjøre jobben lettere for sluttbruker. Vi skal lære hvordan det er å jobbe i et større prosjekt, som gruppe, over en lengre periode enn vi har gjort tidligere, og vi skal sette opp planer for å nå mål og frister i tide. Vi skal lære nytten av styringsdokumenter gjennom prosjektets løp. Mye ny læring om teknologier og fagområder vi tidligere ikke kjente til. 3 Mobile plattformer Mobilapplikasjoner er et tema som har eksplodert de siste årene med utallige smarttelefonvarianter. Dette bringer med seg et stort marked og muligheter for å utvikle applikasjoner, men også utfordringer. På en mobiltelefonen er skjermen mindre og ytelsen lavere enn på en PC, og det gir begrensninger. Brukeropplevelsen på en applikasjon er veldig viktig, og da spesielt med tanke på utseende og respons. Ser applikasjonen uproff ut, vil den ofte også være vanskelig å navigere seg frem i. Krever applikasjonen mye venting, vil den fort bli byttet ut. Med brukeropplevelse i tankene må man gjøre diverse valg for sin utvikling av mobilapplikasjoner. Det finnes flere måter å gjøre det på, men vi skiller her på de to mest brukte typene; hybrid og native løsninger. En hybrid løsning, som Phonegap Build (som vi har valgt å gå for), har muligheten til å kompilere kode til flere plattformer med kun ett sett med kode skrevet i HTML5, CSS og JavaScript. Ikke alltid like velfungerende på alle plattformer, spesielt om applikasjonen krever mye prosessorkraft.

En native løsning, som X Code, er kun laget til en plattform. Denne løsningen er som regel bedre egnet plattformen den er laget til, i forhold til en hybrid løsning. Er vanskelig å tar lang tid å lage native til alle plattformer, en etter en. 4 Planlegging og metode 4.1 Arbeidsforhold Vi har tidligere i vårt 3 årige bachelorstudie jobbet sammen på vellykkede gruppeoppgaver, og da falt det naturlig å samarbeide på bacheloroppgaven. Vi kjenner hverandre godt, har effektive og fokuserte arbeidsøkter sammen. Vi bestemte oss tidlig for at vi ønsket å være 2 på gruppa. Lettere å samarbeide og mer kunnskap å lære innen alle feltene. Så lenge oppgaven kunne tilpasses 2 stk, så var det slik det ble. Vi har stort sett benyttet oss av grupperommene på Høgskolen i Oslo v/holbergs plass, hvor vi sitter sammen og jobber. Dette gir oss fordelen til å kunne ta opp diskusjoner på stedet og løse problemer mer effektivt. Av erfaring er dette den beste måten for oss å jobbe. Vi har også lokaler hos Accenture Fornebu, men pga. av reiseavstand og vår egen hjemmeadresse valgte vi bort å reise ut dit. 4.2 Arbeidsfordeling Arbeidet er fordelt, så godt det lar seg gjøre, 50% hver. Vi har forsøkt at begge er innom alle felter, både på api-, klient- og dokumentasjonssiden. Dette gjør at vi begge forstår sammenhengen bedre, og kan hjelpe hverandre på et høyere nivå. Vi har begge identiske PCer lånt av Accenture, og har installert samme programvare på dem, som bidrar til at begge enkelt kan ta tak hvor det skulle trenges. 4.3 Planleggingsverktøy og metodikk 4.3.1 Dokumentasjon Vi har ført dagbok etter hver arbeidsøkt, noe som gir oss en detaljert oversikt over hva vi har gjort. Dette er til stor hjelp når vi skal skrive sluttrapport. 4.3.1.1 Styringsdokumenter Statusrapport: En rapport som ble levert i fjor, for å vise at vi var i gang med å finne oppgave. Prosjektskisse: Om oppdragsgiver og en kort beskrivelse av oppgaven. Vedlegg 6 Forprosjektrapport: En rapport, som viser hva vi tenker å gjøre og om dagens situasjon. Vedlegg 5

Prosjektdagbok: Blir oppdatert etter hver endt arbeidsøkt. Korte stikkord og forklaringer på hva vi gjorde hver dag. Risikoplan: Er et viktig punkt, som viser oversikt over risikotiltak om det skulle oppstå problemer. Inneholder en tabell med oversikt over sannsynligheten for at noe skal inntreffe. Vedlegg 7 Arbeidsplan og fremdriftsplan: Oversikt over hva som skal gjøres når. Skjema over tidsfrister, sprinter og mål. Vedlegg 3 og 4 Kravspesifikasjon: Denne har blitt endret en del underveis, men er til for å sette kravene på plass. Endringer som har skjedd, gjør at oppgaven ble større, men også mer funksjonibel og lettere å bruke. Blant annet så endret vi fra at studenten skulle sende påmelding på sms, til at studenten melder seg på via web. Viktig at det finnes i hvert fall et førsteutkast ved prosjektets start. Vedlegg 2 4.3.1.2 Versjonskontroll og backup All dokumentasjon, utenom selve sluttrapporten, som ble skrevet i Microsoft Word (pga. problemer med formateringer) er skrevet i Google docs. Dette er en tjeneste vi er godt kjent med og tillater oss å skrive i samme dokument samtidig. Sluttrapporten ble lagret i Dropbox, og Google Docs lagres online. Til koding, brukte vi Netbeans mot git med lokasjon hos Accenture s innersource. Dermed hadde vi også en backup der, pluss en kopi på hver vår laptop. 4.3.2 Prosjekthjemmeside Hjemmesiden var et krav fra skolen hvor vi skulle laste opp dokumenter, som skulle vurderes av dem. Den er laget i ren HTML/CSS. Bilde: 4,1 4.3.3 Utviklingsmodell/metode Vi har tatt utgangspunktet i å bruke Scrum med innflytelse fra vannfallsmetoden, men siden vi kun er to stk, så bruker vi en forenklet og egendefinert versjon. Vi har benyttet oss av en online tjeneste som heter Teambox, hvor vi la opp sprinter og arbeidsoppgaver. Der kunne vi legge til nye oppgaver, kommentere og ferdigstille oppgaver. Denne tjenesten ble opprettet og vedlikeholdt i samarbeid med veilederne hos Accenture.

Det å sette opp sprinter har gitt oss en stødig og effektiv fremgang i prosjektet og vi har klart å fullføre hver sprint til gitt frist. Vannfallsmetoden reflekteres i at vi satt opp frister i en arbeidsplan. 4.4 Teknologier og verktøy Her tar vi for oss alle teknologier og verktøy vi har brukt for å ferdigstille produktet. 4.4.1 Netbeans Utviklerverktøy for en rekke av språk. Gjenkjenner språk og gjør det enkelt å redigere mange filer samtidig i forskjellige språk. All kode er skrevet i Netbeans, både til backend og klient. Netbeans er et program vi er blitt godt kjent med gjennom tidligere fag på HiOA, og er et velkjent og velfungerende program til å skrive kode. 4.4.2 Ajax Øker sidens interaktivitet og vi slipper å måtte laste siden på nytt hver gang data skal hentes. Brukes i sammenheng med JavaScript og jquery for å lage kort og oversiktlig kode. Ajax var ukjent for oss i starten, men lærte fort at det gav oss akkurat det vi trengte for å gi JavaScriptene våre den funksjonalitet vi trengte. 4.4.3 JavaScript Brukes til å tilføre dynamiske elementer til HTML koden og gir siden funksjonalitet. Koden legges i separate JavaScriptfiler, og importeres der dem trengs. Alle våre JavaScript er importert i index.html. Det er tryggere å legge dem i separate filer, da dette gjør det vanskeligere for codeinjection og tukling av verdier. 4.4.4 HTML/CSS HTML er markup språk for å plassere elementer der du vil ha dem og er bygget av <tags>. IDer og klasser er brukt, slik at vi i CSS filene (filer for utseende) kan utforme elementene med font, farger, rammer osv. Vi har opprettet en egen standard.css fil i tillegg til at vi har importert CSS-filer for jquery Mobile og en datovelger, og brukt dem sine IDer for å få det til å se ut slik vi vil. 4.4.5 jquery/jquery Mobile Hjelpebiblioteker for å gjøre kodingen i JavaScript enklere. Her har vi importert bibliotekfiler for jquery og jquery Mobile, samt som nevnt en egen CSS-fil for jquery Mobile. Brukes hyppig for å hente og referere til elementer i HTML-koden, og hente eller sette data i dem. jquery Mobile er direkte rettet til mobilenheter og utforming og funksjonalitet av disse. jquery Mobile har spesielt vært til stor hjelp på designbiten. 4.4.6 Dropbox Dropbox er en gratis (inntil en gitt grense GB) onlinetjeneste for lagring av data, og brukes av oss til å lagre diagrammer, dokumenter, bilder osv, som flere parter skal ha tilgang til. Vi har god kjennskap til tjenesten og brukes hyppig av oss begge til daglig.

4.4.7 Google Docs Google Docs er en gratis onlinetjeneste for å opprette, dele og redigere de vanligste dokumenttyper, som regneark, tekst, presentasjoner osv. Har god erfaring med Google Docs, og kan redigere i samme dokument samtidig uten å få versjonskrasj. 4.4.8 CodeIgniter CodeIgniter er rammeverket vi bruker til API (Backend) og er skrevet i PHP. Har en mappestruktur og en bestemt måte å sette opp metoder på. Forespørsler kommer inn til en controller, som sender data videre til modeller, som igjen henter ut, eller setter inn data fra/til en server, som i vårt tilfelle er en MySQL database. CodeIgniter har også et sett med filer for konfigurasjon av det en måtte trenge, som hvor databasen er, samt legge inn påloggingsinfo, ruter til forskjellige filer osv. Vi falt for CodeIgniter etter godt tips fra medstudent og testing selv. 4.4.9 JSON (JavaScript Object Notation) Brukes til å sende data mellom server og klient. Det bygges opp et JSON-streng på klient eller server, med relevant data, for å kunne sende dette som tekst over til klient eller server, slik at data kan hentes ut på riktig måte. Inneholder et fast oppsett av klammeparenteser, kolon og komma. JSON passer oss veldig bra, siden vi ikke har de store mengde data for sending og mottak, og da trenger en lett måte å gjøre transaksjoner på. 4.4.10 MySQL Brukes til lagring av data til database. MySQL er verdens mest populære open source database, og er den vi er mest kjent med. Har et sett med kodeord for spørringer og har en strukturert måte å hente eller å putte inn data. Tabellene er laget og redigert i phpmyadmin, som er et hjelpeverktøy, som ofte er installert i sammenheng med en database, og gir deg grafisk kontroll over dataene som måtte være der. 4.4.11 REST Et sett med metodenavngivning i rammeverket. Navnpåmetode_put hvor put brukes videre i Ajax på klient og api (controller) på server, og forteller at her skal det oppdateres noe i databasen. Get og Post er også mye brukt, hvor Get er å hente noe vha. en SELECT-spørring, mens Post er å sette inn en ny rad vha. en INSERT. 4.4.12 Phonegap Build Brukes til å kompilere kode skrevet i HTML, CSS og JavaScript til flere plattformer. En online tjeneste, hvor du laster opp kode enten via et git-repository eller en zippet fil av koden. Deretter kompilerer den til alle (inkl. iphone om du har lisens) plattformer. Dette er noe som er svært tungt å få til på en enkelt PC, da du trenger å installere kompileringskode for hver enkelt plattform. Derfor valgte vi å bruke en skytjeneste som allerede taklet alle plattformer. 4.4.13 Teambox En online tjeneste for prosjektstyring hvor vi kan opprette backlog og tilhørende sprints. Er et enkelt verktøy for å holde kontroll på prioriterte emner, samt ferdigstille dem underveis og sette tidsfrister.

4.4.14 SoapUI Brukes til å teste at ressursene til et API fungerer, og at de fortsatt fungerer etter endret kode. Tester direkte til APIet og dets metoder. Setter opp test til ønskede metoder og deretter kjøres testen på samtlige. Dette gir en oversikt og tidlig oppdagelse av feil som oppstår etter endret kode. Må installeres og kjøres lokalt på maskinen/server. 4.4.15 (OAuth) Sikker sending av data. Brukes av store aktører på den sosiale mediafronten. OAuth er ikke implementert, men plan for å gjøre det medfølger rapporten. 4.4.16 Balsamiq Mockups Brukes til å lage mockups (tenkte skjermbilder) i planleggingen. Vi syns det var enkelt å bruke med nødvendige funksjoner lett tilgjengelig. 5 Faser 5.1 Gjentatte faser Vi kalte dette punktet for gjentatte faser, da det er faser, som skjer flere ganger i prosjektets løp. Her er det da spesielt tilegning av kunnskap og risikohåndtering som går igjen. 5.1.1 Tilegning av kunnskap I starten av prosjektet var det mange nye teknologier og fagområder vi måtte ta tak i, å samle informasjon om. Det eneste vi hadde vært borti tidligere var HTML og CSS, som vi begge har hatt ett fag på i første semester. Utover dette var det nye språk, rammeverk, biblioteker og regler vi måtte samle informasjon om før vi kunne gå i gang for fullt. Ut i fra at vi valgte å gå for Phonegap Build (ref kap 2.4.12) og CodeIgniter (ref kap 2.4.8) falt det inn nye teknologier vi måtte sette oss inn i og lære. Blant annet jquery, jquery Mobile, Ajax, REST, JavaScript og JSON. Ref kap 2.4. 5.1.2 Risikohåndtering Vi har klart oss uten de store forsinkelseshendelsene, men litt fravær i forbindelse med reise og ferie pluss tap av lisens har det vært. iphone-lisensen vi måtte ha for å få testet applikasjonen live på en telefon fikk vi i utgangspunktet veldig sent, og vi var godt i gang med Phonegap Build. Kort tid etter vi fikk den, mistet vi viktig informasjon, som gjorde den ukjørbar. Dermed tok det noen dager før vi da fikk opp en ny og kunne legge inn ny versjon på telefonene. Dette medførte frustrasjon og tapt arbeidstid, men i ettertid ser vi at det ikke var kritisk, men heller et kjedelig uhell som kostet noen timer med arbeid.

5.1.3 Endring og revurdering Gjennom prosjektet har vi støtt borti store og små endringer vi må og burde gjøre. Versjon en og to av kravene fra arbeidsgiver er veldig forskjellige, og det skyldes et møte vi hadde med veileder hvor vi kom frem til en bedre og mer effektive måter å gjøre ting på, samt en forstørring av oppgaven. Denne endringen kom tidlig pga. kjapp oppstart og hyppige møter i starten, noe som sparte oss for ekstraarbeid siden vi ikke var kommet til utviklingsfasen enda. En annen stor endring var da vi gikk fra å bare bruke JavaScript og jquery til å i bruk rammeverket jquery Mobile (ref kap 2.4.5), etter startet arbeid. Denne endringen førte med seg en del endring i kode og ny læring, men vi var fortsatt tidlig i prosessen, så det var ikke veldig tidskonsumerende å endre. Det viste seg i ettertid at valget førte med seg positive sider og negative sider. Negative siden var at jquery Mobile og Phonegap sammen krever mer kraft fra enheten det kjører på. Noe som medfører treghet. Dette oppdaget vi ikke før vi fikk iphone-lisensen fra Accenture et godt stykke inn i prosjektperioden, som medførte at vi ikke hadde tid til å gå tilbake å lage ny kode til en annen teknologi. Den positive siden var derimot veldig mye tid spart, og i stor grad penere kode. Bedre funksjonalitet og penere utseende. 5.2 Utredningsfasen 5.2.1 Fremgangsmåte Hvorfor gikk vi for løsningen vi har i dag? 5.2.1.1 Forarbeid Vi brukte tid surfet på nett, pratet med veileder og hørt på anbefalinger fra kjente for å komme frem til løsningene vi gjorde. Phonegap Build falt fort på plass da det kun krevde ett sett med kode, at vi kunne bruke programmeringsspråk som var kjente for oss, og masse god omtale på nett, lett å finne informasjon og veilederne hos Accenture gikk også god for løsningen. Vi har i tillegg sett at tidligere bachelorgrupper, som har vært i lignende situasjon som oss, har gått for samme løsning. Bilde: 5,1

5.2.1.2 Bytte rammeverk Vi fikk også i starten beskjed om å bruke «Spring», som er et Javabasert rammeverk. Noe vi etter mye prøving fikk lov å gå bort i fra, da dette var for stort og tungt å bruke til vårt arbeid. Vi gikk, etter anbefalinger og artikler lest, for «CodeIgniter» isteden, som er et PHP-basert rammeverk. Vi oppfattet kvikt hvordan det fungerte, og fikk etter kort tid satt opp et testmiljø for dette. CodeIgniter koblet vi opp mot en MySQL database, som falt helt naturlig å bruke, siden vi har brukt det før og er per i dag det mest utbredte databasesystemet. Bilde: 5,2 Hovedgrunner til bytte: CodeIgniter var lettere tilgjengelig i form av informasjon og veiledning på Internet. CodeIgniter er lettere satt sammen, og da også lettere å forstå hvordan mappestrukturen er bygget opp. CodeIgniter var lettere å forstå. CodeIgniter har enkel integrering mot NetBeans (ref kap 2.4.1) I alt brukte vi noen dager på å lese og utforske flere varianter av «samme» løsning, og mener vi gjorde gode valg og justeringer fra start og underveis. 5.2.1.3 Jira og Teambox 5.3 Utviklingsfasen Kapitlet tar for seg implementeringen av applikasjonen, og sammen med utredningsfasen gir et bilde på hvordan produktet ble produsert. 5.3.1 Fremgangsmåte Under prosessen ble det mye lesing på nett, og hele tiden forbedring av kode, så en iterativ arbeidsmetode falt naturlig for oss. 5.3.2 Design mobilapplikasjon Når man skal lage design til en mobilapplikasjon er det er det en del viktige ting å tenke på, som at skjermen er liten så et minimalistisk utseende er og foretrekke, ikke masse bilder og plass på å ha

god plass til navigering. Siden vi ikke hadde gjort dette før, tok vi utgangspunkt i mobilapplikasjoner vi selv likte og laget et eget utseende basert på erfaringer vi gjorde etter bruken av disse. 5.3.2.1 Mockups Vår applikasjon skulle stort sett vise informasjon og motta input fra bruker og lagre dette, så utseende burde være enkelt og oversiktelig på listeform. Bilde: 5,3

Slik så vi for oss at det skulle se ut når du klikket deg inn på en detaljert oversikt over et spesifikt arrangement, og et vindu for endring av info. Bilde: 5,4 Slik ble til slutt. Skjermbildet er hentet fra Phonegap Build sin emulator, men utseende og størrelsen er tilnærmet identisk med hvordan det ser ut på iphone 5. 5.3.2.2 Planlegge design Vårt valg av hybrid løsning til å kompilere applikasjonen krever at koden er skrevet i HTML5, CSS og JavaScript, noe som gjør det enkelt å ha et gjennomgående design i applikasjonen. Vha. importerte CSS filer sammen med egendefinerte har vi klart å sette et fast design på hvordan ting skal se ut. Spesielt har jquery Mobile kommet til god hjelp. jquery Mobile (ref kap. 4.4.5) er et rammeverk med metoder og elementer, samt en tilhørende CSS fil. Dette har gjort det enklere å opprette nye sider, og bygge sidene dynamisk med samme design. Vi har lagt vekt på at utseende skal være oversiktlig og brukervennlig, og har som nevnt sett på andre mobilapplikasjoner for å lage oss et eget bilde av hvordan ting kan se ut. Fargene vi har valgt følger en mal i jquery Mobile og gjør det lett å lese og se. Små ikoner på knapper og nedtrekksmenyer er også valgt etter standardikoner, og gir en forklaring i seg selv i tillegg til teksten. Luft mellom elementene er også vesentlig for at det skal være lettere å navigere seg rundt i applikasjonen. Det at knappene alltid er plassert i topp venstre og høyre hjørne, gjør at brukeren alltid vet hvor de er, og gjør det enklere å treffe knappene med fingrene, noe som er en utfordring med utvikling av mobilapplikasjoner.

Vi brukte samme versjon av Phonegap Build gjennom hele utviklingen. Vi forsøkte å oppdatere mot slutten av kodeperioden, men dette skar seg og dermed havnet vi tilbake på tidligere versjon. 5.3.3 Design webside I oppgaven skulle vi lage en tilhørende webside hvor studenter kunne melde seg på spesifikke arrangementer vha. en unik URL gitt til hvert arrangement. Denne siden inneholder kun et par felter for å fylle inn informasjon samt et lite informasjonsfelt. Slik så vi for oss at side kunne se ut i en mockup. Se bilde 5,5. Slik ble den seende ut. Se bilde 5,6 Bilde 5,5

Denne siden er laget kjapt for å få en fungerende side. Det ikke lagt mye arbeid i design, men funksjonalitet bak er på plass. Dette fordi det ikke ble satt noe krav til siden, og da satt vi design på siden lengre ned på prioriteringslisten. 5.3.4 Problemer og løsninger I dette kapitelet tar vi for oss de største problemene vi støttet på under utviklingen av applikasjonen, samt løsningene vi valgte for problemet. 5.3.4.1 Liveserver for testing Da tiden var kommet for brukertesting av applikasjonen, trengte vi en ekstern server å legge backend på. Vi fikk da tilgang til en server av en medstudent men vi fikk ikke backend til å kjøre på serveren. Det viste seg at vi hadde brukt noen elementer fra PHP 5.4 mens serveren kjørte versjon 5.3. Det tok litt tid før vi skjønte at dette var årsaken til problemet. Løsningen var da å oppgradere serveren. Da dette var i orden ble vi møtt med et nytt problem når vi gjorde AJAX-kall til backend. Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin JavaScript er begrenset av «same policy origin». Av sikkerhetsmessige årsaker hindrer policy en JavaScript tilgang til ressurser fra andre domener. Løsningen var å legge til en header i responsen fra backend. header('access-control-allow-origin: *');

5.3.4.2 Navngivning og kommentarer Navngivning og kommentarer er viktig for en lesbar og oversiktlig kode. Konsekvent bruk av et språk, og kommentarer til hver metode. Vi var sent ute med å sette et fast mønster på navn og kommentarer, og merket etter hvert at dette burde vi ha gjort fra starten da det i senere tid ble knotete og uoversiktlig og endre hele koden på en gang. Vi valgte allikevel å gjøre jobben for en mer lesbar og oversiktlig kode. Kommentarer er lagt til alle metoder og navnene har likt mønster og samme språk. 5.3.4.3 iphone lisens For å få lov til å legge mobilapplikasjonen fra Phonegap Build og over på en iphone (som er mobiltypen begge i gruppen har for testing), må en lisens være tilstede med serienummer på mobiletelefonene og annen info mottatt fra Apple mot kjøpt lisens. Accenture hadde tilgang på slike lisenser, men det tok noe tid før vi fikk lisens til å teste. Dette medførte sen testmulighet på iphone, og det viste seg at applikasjonen var litt i overkant lite responsiv da spesielt på iphone 4. iphone 5 og Samsung Note ll hadde akseptabel responstid vel og merke. Det viste seg også senere at vi mistet viktig informasjon i lisensen, og måtte dermed bygge en ny lisens. Noe som medførte tapt tid og frustrasjon. Vi fikk ordnet det kjapt og med god responstid fra veileder hos Accenture var vi kjapt oppe å kjøre igjen. 5.3.4.4 Testing selenium Selenium er et testprogram til nettleseren, som lar deg ta opp knappetrykk og innskrivninger, for å senere utføre nettopp denne innspillingen. Vi hadde planer om å bruke dette, men det viste seg fort at Selenium ikke taklet vår type oppbygging av nettside. Vår applikasjon er bygget dynamisk og Selenium mister alle filene vi importerer i index.html fila fra start, fordi Selenium laster sider på nytt etter hvert knappetrykk. 5.3.4.5 Handlebars og JQuery Mobile Handlebars er et bibliotek skrevet i JavaScript som vi brukte i starten for å generere templates for HTML-kode. Fordelen er at man kan separere logikk fra presentasjon. Før vi oppdaget jquery Mobile brukte vi ikke noe rammeverk men skrev applikasjonen med hjelp av JavaScript og Handlebars templates. Men da vi gikk over til jquery Mobile fikk vi det ikke til å fungere sammen med Handlebars. Dette løste vi med å gå vekk fra Handlebars og over til å bruke Mustache, som tjener samme formål. 5.4 Dokumentasjonsfasen For å lage sluttdokumentasjonen valgte vi å gå bort i fra Google Docs, fordi formatteringer av diverse slag ikke er tilgjengelig i Google Docs. Vi gikk heller for å bruke Microsoft Word for å ferdigstille rapporten. Vi gikk igjennom dokumentasjonsstandarden laget av Ann-Mari Torvatn tilgjengelig på hovedprosjektsidene, for å få tips til hvordan forme dokumentasjonen. Andre rapporter fra tidligere grupper ble også gjennomgått for å se hvordan de ulike formateringer hadde effekt på å tilegne seg informasjonen.

Vi har delt inn i mange kapitler og underkapitler for å enkelt bruke hyperlinker og referanser til andre kapitler. Dette gjør rapporten mer leselig og lettere å navigere seg i. Bilder har også fått egne navn i sammenheng med hvilket kapitel du hører til. Dermed kan vi referere til dem, på samme måte som kapitler. Dokumentasjonen er delt inn i hoveddeler som samlet representerer sluttdokumentasjonen. Prosessrapport; Tar for seg hvorfor vi gjorde det vi gjorde, og hvordan vi arbeidet oss gjennom hele perioden. Produktrapport; Forklarer mer tekniske valg, og hvordan ting fungerer. Testrapport; Tar for seg hvordan vi testet, resultat fra brukertesting. Brukerveiledning; Forklarer hvordan mobilapplikasjonen skal brukes. Vedlegg; Inneholder diverse tilleggsopplysninger vi refererer til i fra andre deler av rapporten. Styringsdokumenter, kildehenvisninger, modeller med mer. 6 Avsluttende del 6.1 Det ferdige produkt Vi har laget et produkt, som med implementasjon i kundens system vil kunne brukes i dag. Etter brukertest har vi fått gode tilbakemeldinger, og kunden er så langt fornøyd. Det finnes forbedringsmuligheter, og oppgaven kan videreutvikles. 6.2 Hva kun vært annerledes Når vi nærmer oss slutten, ser vi at det er ting vi kunne gjort annerledes, men at tiden ikke strekker til. 6.2.1 Phonegap For å få applikasjonen mer responsiv kunne vi ha utforsket en annen teknologi enn Phonegap, men som forklart i kap 5.3.4.3 fikk vi ikke testet applikasjonen før vi var godt ute i arbeidsperioden. Hadde vi oppdaget treghet veldig tidlig, kunne vi forsøkt en annen teknologi, og sammenlignet mot Phonegap. Vi kunne også ha brukt mer tid på å undersøke å teste andre hybride løsninger. 6.2.2 Testing For å gjøre testingen enklere, tenker her på soapui (kap 4.4.14) og ikke generell kodetesting, kunne vi ha satt opp testmiljø før vi begynte å kode, og ikke mot slutten av kodeperioden. Dette hadde gjort koden tryggere å endre og lettere å jobbe med, pluss et fordelt arbeid gjennom hele prosessen og ikke en bulk med arbeid på slutten.

6.2.3 Navngivning og kommentarer Vi var ikke konsekvente på navngivning og kommentarer fra starten. Vi satt ikke en fast mal på om kommentarene og navnene skulle være engelsk og heller ikke noe fast oppsett på hvordan navnene var bygget opp relativt til posisjon. Dette skapte ekstra arbeid vi måtte sette av tid til istedenfor å gjøre det kontinuerlig underveis. Dette er noe vi allikevel fikk fikset, med å sette av tid til det. 6.3 Konklusjon Dette er det største prosjektet vi har vært med på og har vært en lærerik, spennende og tidkrevende prosess. Vi måtte ta viktige valg, og for det meste har vi gjort riktige og bra valg vi er fornøyd med. Læringskurven vår har vært bratt fra start, siden vi ikke hadde kunnskap og/eller kjennskap til teknologier vi måtte ta i bruk. Dette var en spennende og krevende utfordring for oss begge, og føler vi har kommet godt ut av det med mye relevant læring og forståelse av nye teknologier. Prosjektet har gitt oss en bedre innlevelse i hvordan et større prosjekt må styres for å komme i mål, og hvor viktig det er å sette opp planer, krav og frister. Vi har gjennom prosjektets løp hatt et bra samarbeid med et ubetydelig antall uenigheter, og kommet i mål til gitte frister hver gang. Samarbeidet med veilederne både på HiOA og hos Accenture fungert bra, med små unntak av kommunikasjonsproblemer, og har vært til stor hjelp gjennom prosjektet. Med hyppige møter mellom oss på gruppa og veiledere har vi holdt en stødig kurs og er nå i mål med erfaringer og et produkt vi er stolte av.