Denne siden er blank med tanke på trykk

Transkript

1

2 Denne siden er blank med tanke på trykk

3 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR TILGJENGELIGHET Åpen BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL SHERA arrangementsapplikasjon for Android PROSJEKTDELTAKERE Chris Andre Forberg, s Pernille Celia Sethre, s Ole Petter Skovseth, s DATO ANTALL SIDER / BILAG 122/4 INTERN VEILEDER Tor-Morten Grønli OPPDRAGSGIVER Accenture KONTAKTPERSON Fredrik Bjørnøy SAMMENDRAG Applikasjonen gir personer med en Android-enhet mulighet til å logge seg på SHERA med sin Facebook-profil og deretter opprette, se og delta på arrangementer der de befinner seg. Alle opprettede arrangementer ligger tilgjengelige på et kart, og ved hjelp av filtrering og kategorier vil en raskt og effektivt finne det en er på utkikk etter. 3 STIKKORD Android SHERA Arrangement

4 Denne siden er blank med tanke på trykk

5 Forord Dette dokumentet er en endelig sluttrapport for vårt hovedprosjekt ved Høgskolen i Oslo og Akershus våren Prosjektidéen er selvkomponert, men er gjennomført i samarbeid med Accenture. Oppgaven har gått ut på å utvikle en applikasjon til det mobile operativsystemet Android som skal gjøre det raskt og enkelt for brukere å se, opprette og delta på arrangementer utfra egne preferanser. Vi vil takke Accenture som lot oss skrive bacheloroppgaven vår hos dem, og som har brukt tid og ressurser på oss. Vi vil samtidig også takke våre eksterne veiledere Henning Engen og Simen Søhol for deres arbeid og oppfølgning gjennom denne prosjektperioden. Til slutt vil vi takke Tor-Morten Grønli som har vært vår interne veileder ved Høgskolen i Oslo og Akershus. Du har vært til stor hjelp når svar og løsninger har vært vanskelig å komme frem til. 4

6 Leserveiledning Dette dokumentet inneholder følgende delrapporter og vedlegg, i denne rekkefølgen: - Kapittel 1 Presentasjon: her kan en raskt sette seg inn i hvem oppdragsgiver er, hvem gruppen er og hva bakgrunnen for oppgaven har vært. - Kapittel 2 Prosessdokumentasjon: her beskrives prosessen gjennom prosjektperioden. - Kapittel 3 Produktdokumentasjon: her beskrives sluttproduktet. - Kapittel 4 Testdokumentasjon: her dokumenteres all testing av produkt som er blitt gjennomført. Det forutsettes at leseren av dette dokumentet har noe teknisk innsikt innen emner som programmering og applikasjonsutvikling. Hvis leser har spørsmål rundt uttrykk eller liknende bes vedkommende å slå opp i ordlisten (Vedlegg A) der det meste står forklart. Vedlegg B inneholder alle kilder vi har benyttet oss av, Vedlegg C inneholder en oversikt over alle figurer i denne rapporten, og Vedlegg D inneholder en brukerveiledning for sensor. 5

7 Innholdsfortegnelse Forord... 4 Leserveiledning... 5 Innholdsfortegnelse Presentasjon Innledning Prosjektets deltakere Studentgruppen Oppdragsgiver Bakgrunn for prosjektet Mål Beskrivelse av applikasjonen Kort presentasjon av sluttproduktet Prosessdokumentasjon Oppstartsfasen Idéen Planlegging Valg tidlig i prosessen Programmeringsspråk Utviklingsmiljø API CVS Scrum-verktøy Øvrige teknologier Database En god start Utviklingsmetodikk Smidig utvikling Scrum Scrum i vårt prosjekt Konklusjon Utviklingsprosessen Sprint

8 Sprint Sprint Sprint Sprint Sprint Sprint Sprint Produktdokumentasjon Introduksjon Applikasjonen Innlogging Kartet Arrangementer Chat Navigasjon i applikasjonen Søking og filtrering Flytdiagram Applikasjonens struktur Klassediagram LogInView.java MapView.java EventCreator.java EventsView.java EventView.java ChatView.java Design Enheter og skjermstørrelser Be flexible Optimize layouts Assets for all Touch feedback Enheter, DPI og størrelser Typografi Farger

9 Ikoner Logo Fra idé til ferdig produkt Interaksjonsdesign Universell utforming Implementering av retningslinjene i SHERA Konklusjon Android Design Principles Enchant Me Simplify My Life Make Me Amazing Konklusjon Teknologier Facebook Firebase Videreutvikling av SHERA Detaljer Nye funksjonaliteter Konklusjon Testdokumentasjon Enhetstest Formål JUnit Utførte tester Testing i Android Studio Systemtest Test av grafisk brukergrensesnitt Kompetansetesting Annet Akseptansetest Gjennomføring Konklusjon Brukertest Gjennomføring

10 Resultat Vedlegg Vedlegg A: Ordliste Vedlegg B: Kilder Vedlegg C: Figurer Vedlegg D: Brukerveiledning for sensor

11 1. Presentasjon I dette kapittelet gis en presentasjon av alle involverte parter, bakgrunn for oppgaven, samt beskrivelse av endelig produkt Innledning Tanken bak dette prosjektet og denne mobilapplikasjonen er å gjøre det raskt og enkelt å finne nye ting å gjøre, og møte nye mennesker. Ved å benytte seg av SHERA kan brukere enkelt se, opprette og delta på arrangementer i nærheten av der de befinner seg Prosjektets deltakere Chris Andre Forberg Studentgruppen Pernille Celia Sethre Ole Petter Skovseth HiOA Tor-Morten Grønli Henning Engen Accenture Simen Søhol Fredrik Bjørnøy Figur 1: Oversikt over prosjektets deltakere 10

12 1.3. Studentgruppen Gruppen består av Chris Andre Forberg, Pernille Celia Sethre og Ole Petter Skovseth, der alle studerer ingeniørfag data. Vi ble kjent med hverandre da vi begynte på 3- terminsordningen sommeren før første semester, og er nå gode venner både i og utenfor skolesammenheng. Gjennom disse tre årene har vi arbeidet sammen på flere prosjekter i flere fag og kjenner hverandres styrker og svakheter. I denne sammenheng falt det naturlig å fortsette å jobbe sammen på hovedprosjektoppgaven. Vi har likt ambisjonsnivå og like tanker om hvor stor arbeidsmengde vi ønsker å legge ned i prosjektet. I tillegg har vi forskjellige interessefelter, noe som gjør at vi passer godt sammen i prosjektsammenheng. Pernille er rask til å tilpasse seg nye situasjoner og tar utfordringer på strak arm. Hun er i sitt ess når hun står overfor et programmeringsproblem og er ikke redd for å si hva hun mener. Chris er teoretisk og utadvendt, og tar lett alt som har med logikk og algoritmer å gjøre. Ole Petter er designrettet og språkfokusert, og sørger for at alt blir gjennomført i henhold til arbeidsplanen Oppdragsgiver Accenture er et globalt konsern som tilbyr konsulent-, teknologi- og outsourcingtjenester innen IT. De har over ansatte i mer enn 120 land, og i Norge hadde de i 2010 en omsetning på 1,5 milliarder norske kroner. Accenture har per 1. september 2009 sitt hovedkontor i Dublin i Irland og kan kalle seg verdens største konsulentfirma. Deres slagord både innad og utad er «High performance. Delivered.». Figur 2: Accenture-logo Våre eksterne veiledere hos Accenture er Henning Engen og Simen Søhol. De har begge vært i samme situasjon som vi befinner oss i nå og skrev selv bacheloroppgaven sin hos Accenture for noen år tilbake. Dette gir dem god innsikt til å bistå der det er behov for det, samt komme med gode ideer og forslag. 11

13 1.5. Bakgrunn for prosjektet Formålet med SHERA er å gi brukere muligheten til å se, opprette og delta på arrangementer ut fra selvvalgte preferanser. Idéen til prosjektet er selvkomponert og ble utarbeidet i tiden før samarbeidet med Accenture. Den ordinære idéen var å gi studenter og personer som nylig har flyttet til et nytt sted muligheten til å møte nye mennesker og oppleve nye situasjoner, noe som senere er blitt utvidet til å gjelde alle Mål Gi brukere en applikasjon til Android som viser tilgjengelige arrangementer i nærheten av der de befinner seg. Brukere skal kunne opprette arrangementer, chatte med deltakere og gjennom påmelding via Facebook kunne se hvilke venner som er påmeldte til et gitt arrangement. Alt dette skal skje raskt, brukervennlig og sikkert. Applikasjonen skal tilby brukere å: - Logge inn med Facebook-informasjon. - Se opprettede arrangementer i nærheten av seg ved hjelp av GPS- og WiFilokalisering. - Se hvilke Facebook-venner som er påmeldt på samme arrangement som en selv. - Zoome fritt inn og ut, samt navigere i Google Maps for å se arrangementer over hele verden. - Filtrere arrangementer basert på flere sorteringsalternativer som kategorier og omkrets. - Opprette egne arrangementer enten via langt trykk på kartet eller ved å navigere til «Create Event»-siden. - Bestemme om arrangementet som opprettes er egnet for personer under 18 år. - Velge tittelbilde til arrangementer når de opprettes. - Melde seg på arrangementer. 12

14 - Se påmeldte arrangementer. - Chatte med andre brukere på et gitt arrangement etter påmelding. - Finne raskeste rute til et arrangement, enten fra innskrevet posisjon eller nåværende posisjon via GPS Beskrivelse av applikasjonen Applikasjonen gir brukere med en mobil enhet kjørende operativsystemet Android muligheten til å se arrangementer i nærheten, melde seg på disse og chatte med deltakere. Innlogging og brukerautentisering skjer via Facebook, noe som gjør det både raskt og sikkert. For å gjøre det enklere for brukere å finne rett arrangement er det implementert filtreringsfunksjoner på hovedskjermen. Her kan brukere som har tillatt applikasjonen å bruke posisjonen deres finne arrangementer innen en gitt radius fra der de befinner seg. En kan i tillegg velge en bestemt kategori, for eksempel «sport» eller «kultur», for å kun vise arrangementer innen denne kategorien. Det er også implementert et valg for å vise arrangementer rettet mot voksne. Brukere med en Facebook-informasjon som tilsier at de er yngre enn 18 år vil ikke ha dette valget og vil ikke ha mulighet til å delta på slike arrangementer Kort presentasjon av sluttproduktet Sluttproduktet er en applikasjon som tillater brukere å opprette, redigere og melde seg på arrangementer hvor som helst i verden. Hvert arrangement har en egen chat der deltakere kan snakke med hverandre i tiden før, under og etter et arrangement. Brukere med en registrert alder på under 18 år på sin Facebook-profil vil få visse restriksjoner hva gjelder type arrangement de kan se og delta på. Ved opprettelse av et arrangement vil bruker ha mulighet til å laste opp et bilde fra sin Facebook-profil og som blir liggende øverst på siden med informasjon om arrangementet. Dette for å personliggjøre applikasjonen. En bruker vil kunne se om en av sine Facebook-venner er deltaker på et arrangement og om en av disse er oppretter. 13

15 SHERA er en rask og responsiv applikasjon som følger Google retningslinjer for utvikling til Android og gir brukere i alle aldre og livssituasjoner en mulighet til å utforske nye aktiviteter og oppsøke nye mennesker. 14

16 15 Denne siden er blank med tanke på trykk

17 2. Prosessdokumentasjon 2. Prosessdokumentasjon Oppstartsfasen Idéen Planlegging Valg tidlig i prosessen Programmeringsspråk Utviklingsmiljø API CVS Scrum-verktøy Øvrige teknologier Database En god start Utviklingsmetodikk Smidig utvikling Scrum Scrum i vårt prosjekt Konklusjon Utviklingsprosessen Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint

18 Denne rapporten tar for seg hele prosessen gjennom hele prosjektperioden, og viser hvordan det er jobbet for å komme frem til sluttproduktet. Prosessdokumentasjonen viser hvilke teknologier som er brukt, hvilken arbeidsmetodikk som er fulgt, eventuelle problemer og utfordringer som har dukket opp underveis, samt beskrivelse av hvordan disse er løst Oppstartsfasen Idéen Under vårt første møte med produkteier Accenture fikk vi presentert en rekke oppgaver de hadde utarbeidet og som vi kunne velge. De sa imidlertid at de aller helst ville at vi skulle komme opp med en idé selv, fordi etter deres erfaring var de studentene som jobbet med noe de hadde funnet på selv mer engasjerte og følte mer eierskap i produktet. Dette hadde de nok rett i. Vi hadde en idé som vi hadde snakket litt rundt tidligere; en kartapplikasjon som gjorde det enkelt og spennende å møte nye mennesker og utforske nærområdet sitt. Da vi foreslo dette, noe som etter hvert skulle bli til SHERA, var Accenture svært positive og ville at vi skulle gå videre med idéen vår Planlegging Da vi skulle starte prosjektet hadde vi et møte med våre eksterne veiledere hos Accenture. Vi pratet en del om hvordan det ferdige produktet skulle fungere. Vi skrev ingen kravspesifikasjon fordi dette ikke er i henhold til Scrums prinsipper, men vi satte derimot opp en rekke «epics», eller hovedfunksjonaliteter, samt use-cases til disse. Her er våre epics med tilhørende use-cases som vi satte opp: Kart Som bruker skal jeg kunne se arrangementer nær meg. Som bruker skal jeg kunne søke opp arrangementer i hele verden. Som bruker skal det være lett å finne det arrangementet jeg ser etter ved hjelp av filtrering. 17

19 Innlogging Som bruker skal jeg kunne logge inn med Facebook. Som bruker skal jeg kunne forbli logget inn til jeg velger å logge ut. Arrangementer Som bruker skal jeg kunne opprette arrangementer. Som bruker skal jeg kunne redigere mine egne arrangementer. Som bruker skal jeg kunne melde meg på andres arrangementer. Som bruker skal jeg kunne se hvilke av mine Facebook-venner som skal delta på et arrangement. Som bruker skal jeg kunne ha tilgang til et arrangement en tid etter at det er over. Som bruker skal jeg kunne melde meg av eller avlyse arrangementer. Skytjeneste Som bruker vil jeg ha en rask og oppdatert brukeropplevelse. Som bruker vil jeg vite at mine data er trygt lagret. Som bruker vil jeg at applikasjonen skal bruke så lite nettverkstrafikk som mulig. Chat Som bruker skal jeg kunne chatte med andre som skal på samme arrangement som meg. Som bruker vil jeg kunne se hvem som har skrevet hva når. I tillegg lagde vi også etter hvert en «epics-rapport», da dette var noe vi kom til å bruke mye tid på, og det da var naturlig å kunne logge hvor mange timer vi brukte på dette underveis. I løpet av prosjektet har vi laget funksjonalitet som dekker alle use-casene vi satte opp i starten av prosjektet. 18

20 Valg tidlig i prosessen Programmeringsspråk Vi bestemte oss tidlig for at vi ville lage en Android-applikasjon. Pernille hadde litt erfaring med Android-utvikling fra tidligere, og syntes dette var et spennende rammeverk som hun gjerne ville jobbe mer med. Diskusjonen om hva som er best av å utvikle «native» kontra «cross-platform» er stor og noe som engasjerer mange i utviklerverdenen, og begge fremgangsmåter har sine klare fordeler. For oss ble det avgjørende at en på gruppen hadde erfaring vi kunne benytte oss av, slik at ikke alle måtte begynne med blanke ark og bruke mye tid i oppstarten på å Figur 3: Android-logo lære seg noe helt nytt. En annen ting som har vist seg å være veldig fint med Android er at siden det er åpent for hvem som helst å lage egne applikasjoner og legge disse ut på Google Play Store, er det stort sett alltid noen som har lurt på akkurat det samme som deg tidligere. Dette gjør prosessen med å finne gode svar og løsninger når en står fast veldig enkel. I tillegg har Google laget veldig gode dokumentasjoner og tutorials som ligger tilgjengelig på developer-sidene deres (Google, 2015). 19

21 Utviklingsmiljø Vi valgte å bruke Android Studio som vårt utviklingsmiljø. Android Studio er utviklet av Google, og basert på IntelliJ-plattformen. Selv om Android Studio har vært tilgjengelig i beta-versjon siden juni 2014, var det kjent for å ikke være helt ferdig og ha en del bugs. På grunn av dette var det vanlig å bruke Eclipse ADT (Android Development Tools) frem til desember 2014, frem til første fullstendige versjonen av Android Studio ble lansert. Mens Eclipse er designet for å støtte flere programmeringsspråk, og trenger utvidelsen ADT for å støtte Androidutvikling, er Android Studio laget utelukkende for Android-utvikling. Dette ble derfor et naturlig valg da vi startet utviklingen av SHERA i januar Figur 4: Android Studio-logo 20

22 API Da vi hadde bestemt oss for å bruke Android og skulle sette opp prosjektet, måtte vi videre bestemme oss for hvilke API-er (Application Programming Interface) applikasjonen vår skulle støtte. Google har laget denne statistikken over sine brukere: Vi valgte å støtte helt ned til API 15 Ice Cream Sandwich. Hvis vi hadde valgt et tidligere API ville en del av det som i dag regnes som vanlig funksjonalitet i Android ikke vært støttet. Dette er tall fra januar 2015 da vi startet på prosjektet. Da ville vi med vårt laveste API-valg hatt en dekning på 87.9% av alle verdens Androidbrukere. I dag, mai 2015, er dette tallet oppe i 90.4%, og vil bare fortsette å stige i tiden som kommer. Figur 5: Googles oversikt over brukte API-er Under utviklingen har Pernille testet på en enhet med API 15, og Ole Petter har testet på en enhet med API 19. Det har tidvis vært en utfordring å få alle skjermbilder til å se like ut på begge enhetene, men det var viktig for oss å være sikre på at vi faktisk støttet API 15 i praksis, ikke bare på papiret. 21

23 CVS Siden vi var tre stykker som skulle programmere på dette prosjektet sammen måtte vi benytte oss av et CVS (Concurrent Version System) i utviklingen. Vi spurte våre veiledere hos Accenture om de hadde noen råd om hva vi kunne benytte, og de foreslo GitHub. GitHub baserer seg på Git, men tilbyr i motsetning til Git også et grafisk grensesnitt i tillegg til kommandolinje. Android Studio har også ferdig innebygget oppkobling mot GitHub som det er lett å sette opp. GitHub er også gratis så lenge en synes det er greit at hvem som helst kan se koden din, og etter at vi sendte en mail til GitHub fikk vi også en studentlisens på to år slik at vi kunne gjøre koden vår privat. Figur 6: GitHub-logo GitHub har vært et flott og enkelt verktøy å bruke. Brukergrensesnittet er både lett og intuitivt, men tilbyr også avanserte funksjoner, slik som grafer over hvilke brukere som har skrevet mest kode, eller når vi generelt er mest aktive: Figur 7: Punchcard fra våre commits på GitHub 22

24 Scrum-verktøy Da vi skulle sette opp den første sprinten ble vi anbefalt to forskjellige digitale verktøy for Scrum: Jira og YouTrack. Mens Jira er mye brukt og er kjent for å være et godt verktøy, så er det også et veldig stort og tungt verktøy med mange funksjonaliteter som vi egentlig ikke trengte på dette prosjektet. Derfor ble YouTrack et bedre alternativ for oss, da dette var første gangen vi skulle jobbe med Scrum i praksis. YouTrack er et litt enklere program med mindre funksjonalitet, men dette gjør også at det er enklere for nybegynnere som oss å orientere seg og lære seg hvordan en skal benytte hovedfunksjonalitetene i programmet. YouTrack har vært et flott verktøy å bruke. Det har et veldig intuitivt brukergrensesnitt, og er veldig responsivt og oppdaterer seg fortløpende når en av oss gjør endringer. YouTrack kobles også enkelt opp mot GitHub, slik at når en merger en branch i GitHub som har samme navn som en task i YouTrack, vil denne automatisk flytte seg til «Resolved», og det vil bli lagt til en link til koden i kommentarfeltet på tasken i YouTrack. 23

25 Øvrige teknologier Figur 8: Facebooklogo Vi bestemte oss tidlig for å benytte Facebooks SDK (Software Development Kit) til innlogging. Dette var fordi vår målgruppe er mennesker som ønsker å benytte seg av smarttelefoner til å interagere med verdenen rundt seg, og de fleste som faller innenfor denne målgruppen er allerede brukere av Facebook. Det er over tre millioner nordmenn på Facebook, månedlig er det over 1,32 milliarder aktive brukere på Facebook over hele verden og ca. 80% av Facebooks trafikk går via mobile enheter (AS, 2015). Med denne brukerstatistikken syntes vi det var et naturlig valg å la brukerne våre logge seg inn via en eksisterende Facebook-konto. Dette sparer brukeren for tiden det tar å registrere en ny bruker hos oss, det gjør det lettere for brukeren å forholde seg til en allerede eksisterende konto, og det sparer oss for lagringsplass og databasetrafikk å la Facebook lagre all brukerinformasjon for oss. Videre i prosjektet har vi også benyttet Facebook til en rekke andre ting, slik som å hente bilder, fødselsdag, navn og venner, men dette var ikke noe vi bestemte oss for før senere i prosjektet. Hovedidéen bak SHERA var å bruke et kart for å vise brukeren hvor arrangementer befinner seg i forhold til brukerens posisjon. Da det er en altfor stor jobb for oss å kartlegge hele kloden (eller bare Oslo for den saks skyld) var det en selvfølge at vi kom til å måtte benytte oss av en ekstern karttjeneste. Google Maps ble et naturlig valg, ikke bare fordi Google er en fellesnevner for kartet og Android, men også fordi det er en mye brukt, godt utbygd og er en godt oppdatert tjeneste som mange benytter seg av. I 2014 var Google Maps-applikasjonen den 6. mest brukte applikasjonen Figur 9: Google Mapslogo i verden med 64.5 millioner brukere i verden (Buczkowski, 2015). Google Maps ligger også ferdig installert på alle Android-telefoner, så brukerne våre trenger ikke å laste ned noe ekstra for å benytte seg av applikasjonen vår. 24

26 Genymotion er en Android-emulator som består av et komplett sett med sensorer og funksjoner for å interagere med et virtuelt Android-miljø. Den gjør det raskt og enkelt å teste Android-applikasjonen på en rekke virtuelle enheter, både i utviklings-, test- og demonstrasjonssammenheng. Figur 10: Genymotion-logo Sammenliknet med Android Studios innebygde emulator er Genymotion veldig rask, spesielt på kraftige maskiner. En virtuell enhet er enkel å sette opp og lett å interagere med. Den er tilgjengelig til både Windows, Mac OS X og Linux, men er kun brukt til førstnevnte i løpet av dette prosjekt. Genymotion benytter seg av Oracle VM VirtualBox. Denne må kjøre i bakgrunnen for at Genymotion skal kunne virtualisere et Androidoperativsystem. Det VirtualBox gjør er å opprette og håndtere virtuelle maskiner på et eksisterende vertsoperativsystem. Det virtuelle Androidoperativsystemet blir da kjørt på en slik virtuell maskin. I teorien skal Genymotion kunne kjøre en applikasjon på en tredjedel av tiden det tar en fysisk enhet tilkoblet en PC å gjøre det samme, samt en oppstartstid på enheten på rett under halve tiden. Erfaring i løpet av prosjektperioden tilsier at dette Figur 11: Skjermbilde Genymotion ikke er rett, men at det heller er snakk om så å si de samme tidene som på en fysisk enhet, på en ordinær og gjennomsnittlig maskin. Genymotions fordeler ligger i dets mulighet til å emulere hvilken som helst telefon med spesifikasjonene du selv velger. Dette i tillegg til at applikasjonen raskt kan testes opp mot forskjellige Android-versjoner. 25

27 Database Vi bestemte oss tidlig i prosjektet for at vi ville lage en chat i applikasjonen, men vi var usikre på hva slags database som var best å bruke til dette formålet. Vi forhørte oss med vår interne veileder, Tor-Morten, og han anbefalte Firebase. Firebase er en «realtime»-dokumentdatabase. Dette gir en veldig rask og responsiv database som egner seg godt til funksjoner hvor lesing og skriving til databasen må gå raskt, slik som chat. Vi endte opp med å bruke Figur 12: Firebaselogo Firebase til resten av applikasjonen også, og den har vist seg å egne seg godt til all slags bruk En god start Alle overnevnte ting har vi vært enige om og funnet raskt ut av. Dette ga oss en god start og et godt utgangspunkt for å starte utviklingen av applikasjonen. Alle valgene vi tok tidlig i prosjektet har vi holdt oss ved, og vi ville tatt de samme valgene igjen om vi skulle begynt på nytt i dag. 26

28 2.2. Utviklingsmetodikk Smidig utvikling Smidig utvikling er basert på prinsippene som er spesifisert i Agile Manifesto (Beck, et al., 2015). De viktigste verdiene for smidig utvikling er: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Smidig utvikling er i dag mye brukt innen utvikling på både små og store prosjekter. Det er blitt svært populært da det gir mye rom for endringer underveis, noe som har blitt mer og mer viktig fordi hyppigheten på lansering av ny teknologi øker. Om en vil gjennomføre et prosjekt med en mer tradisjonell utviklingsmetodikk som for eksempel fossefallsmetoden, kan en risikere at den teknologien en planla å bruke i starten er utdatert innen prosjektet er fullført. De to mest kjente smidige utviklingsmetodikkene er Scrum og Kanban, der Accenture arbeider etter førstnevnte. 27

29 Scrum Mens Agile Manifesto er en idé om hvilke prinsipper og verdier som burde være viktig innen utvikling, er Scrum en utviklingsmetodikk som strukturerer og realiserer disse verdiene. Scrum er som andre smidige utviklingsmetodikker iterasjonsbasert. I Scrum kalles disse iterasjonene «sprinter», der én sprint vanligvis varer 2-4 uker. Før en sprint setter en opp en sprint backlog. Denne består av «tasks» eller oppgaver som skal utføres i løpet av sprinten. Disse oppgavene er hentet fra produkt-backloggen. Dette er en liste over alle oppgavene som må utføres for å ferdigstille en eller flere funksjoner eller «features». Produkteieren sorterer denne listen med oppgaver fra viktigst til minst viktig, og deretter henter Scrum-teamet inn så mange av de øverste oppgavene som de mener de kan få tid til i en sprint. Under sprinten skal det avholdes daglige «stand up»-møter. Disse møtene er laget slik at alle på utviklingsteamet skal få en oversikt over hva de skal gjøre, og de får sjansen til å fortelle Scrum-master om eventuelle vanskeligheter. Scrum-masterens rolle er å passe på at alle på teamet har de beste forutsetningene for å få gjort det de skal. Vedkommende har også som oppgave å være teamets ansikt utad, og opprettholde kontakt med produkteier. Når en sprint er fullført skal en (forhåpentligvis) sitte igjen med en fullstendig funksjonalitet som en i prinsippet kan sende ut til brukeren som en oppdatering om en ønsker det (Wikipedia, 2015). Figur 13: Illustrasjon av metodikken Scrum 28

30 Scrum i vårt prosjekt Vi hadde ingen praktisk erfaring med å jobbe med hverken Scrum eller noe annen smidig utviklingsmetodikk før dette prosjektet, men vi hadde en grunnleggende teoretisk forståelse av hva det gikk ut på. Gjennomføringen har gått veldig bra. Vi har estimert tid på tasks i timer. Dette var vanskelig i begynnelsen da vi ikke hadde noen erfaring med å forsøke å estimere hvor lang tid en oppgave kom til å ta. Den første sprinten brukte vi på å sette opp alt av teknologier vi kom til å trenge, blant annet YouTrack (Forberg, Sethre, & Skovseth, 2015). YouTrack er et verktøy designet for Scrum, som lar utviklere sette opp og dele en Scrum-tavle over nett. Denne produserer også en Burndown Graph når sprinten er fullført. Figur 14: Skjermdump av Burndown-graf - Sprint 2 Dette er en Burndown Graph over vår andre sprint. Det som er tydelig her er at vi estimerte altfor lite tid, og brukte mye mer tid enn vi hadde regnet med, men at vi klarte å fullføre allikevel. Dette er fordi vi totalt estimerte to uker og tre dager på hele sprinten, og det er ganske få timer fordelt på tre personer over to uker. 29

31 Figur 15: Skjermdump av Burndown-graf - Sprint 3 Her har vi tydeligvis tatt lærdom fra den forrige sprinten og estimert litt bedre. Vi ser også at vi igjen kun la opp til litt over to uker med arbeid. Dette er fordi vi hadde liten oversikt i starten over hvor mye vi faktisk hadde kapasitet til å gjøre i løpet av en sprint så tidlig i prosjektet. Siden vi til stadighet estimerte for lite tid på tasksene fikk vi til neste sprint tips fra vår interne veileder Tor-Morten om å doble det estimatet vi først kom opp med. Et annet tips vi har hørt er å gange med pi. Vi bestemte oss for å doble, og dette ble resultatet: 30

32 Figur 16: Skjermdump av Burndown-graf - Sprint 4 Her har vi truffet den ideelle progresjonen ganske bra, men vi brukte litt mindre tid enn vi hadde planlagt. Dette er helt greit, fordi nesten seks uker er mye tid når vi også har andre fag ved siden av som må prioriteres i løpet av en to-ukers periode. Figur 17: Skjermdump av Burndown-graf - Sprint 5 I sprint 5 ser vi at vi har blitt flinkere til å estimere hvor lang tid en task faktisk tar, og når vi da dobler estimeringen så blir det altfor mye. Her har vi kun brukt halve tiden vi estimerte på å fullføre alle oppgavene. 31

33 Figur 18: Skjermdump av Burndown-graf - Sprint 6 Den samme tendensen ser vi i sprint 6. Her har vi faktisk brukt litt under halvparten av den estimerte tiden. Vi ser også at vi ikke ble ferdig med alle oppgavene fra denne sprinten. Når dette skjer skal de overføres til neste sprint, og være høyest prioritert. Figur 19: Skjermdump av Burndown-graf - Sprint 7 I sprint 7 forsøkte vi å estimere litt mindre etter at vi hadde sett på Burndown-grafen fra de to siste sprintene, men dette hjalp ikke så mye. Igjen bruker vi kun halvparten av tiden vi har estimert. Mye av grunnen til dette er nok også at vi ble flinkere til å dele opp i mindre 32

34 oppgaver, og det er vanskeligere å estimere nøyaktig på små oppgaver enn større. I Scrum skal en task helst ikke ta lenger tid enn to arbeidsdager, og ideelt sett skal den være så liten som mulig. Fra grafen kan vi også lese at vi kun brukte én uke og fire dager på denne sprinten, og dette stemmer nok heller ikke helt. I dette prosjektet gikk det mye tid på å snakke sammen, hjelpe hverandre og planlegge som vi ikke har loggført, fordi dette ikke er ting en kan planlegge eller estimere timer på. Selv om vi fortsatt har litt å lære om estimering, har de andre aspektene ved Scrum gått veldig bra. Annenhver mandag har vi satt oss ned sammen og sett over hva som gikk bra sprinten før, og hva som kunne forbedres. Vi har også satt opp sprint-backloggen i fellesskap. Vi forsøkte også å ha daglige stand-ups, men følte raskt at dette ble overflødig siden vi kun er tre medlemmer på gruppen, og siden vi sitter sammen og har god kommunikasjon oss imellom gjennom hele arbeidsdagen. Alle visste allerede hva alle holdt på med, og hvilke utfordringer de andre hadde. Ingen hadde rollen som Scrum-master, men vi hjalp hverandre der det trengtes fortløpende. Erfaringen er allikevel fin å ha, og vi er enige om at en kan ha stor nytte av daglige møter i et større team. På slutten av hver sprint hadde vi et demomøte med produkteier hvor vi presenterte alle nye funksjonaliteter. Disse ble ikke lansert fortløpende, men de kunne godt ha blitt det Konklusjon Dette har vært en lærerik prosess. Å jobbe med en utviklingsmetodikk som Scrum gjør utviklerne mer klar over hvor mye tid en oppgave tar, og hvor mye av arbeidsdagen en klarer å bruke på ren utvikling. Det å jobbe i team har også lært oss mye om samarbeid, og hvor viktig det er med en god og åpen kommunikasjon gjennom hele teamet. 33

35 2.3. Utviklingsprosessen Sprint 1 I begynnelsen av utviklingsprosessen var det høyt fokus på å få opp alt av teknologier. Disse besto av YouTrack, GitHub, Android Studio, Genymotion, samt gruppens egne hjemmeside, Ingen av oss hadde jobbet med noen av disse tidligere, så en del tid gikk med på å sette seg inn i de forskjellige programmene. Utover dette måtte vi ta flere valg sammen med våre veiledere hos Accenture. Vi bestemte oss for å arbeide i sprinter på to-og-to uker, da dette bedre passet vår arbeidssituasjon. Vi hadde på dette tidspunktet ikke jobbet etter Scrums prinsipper i praksis, så det var greit å få rask oppfølging ved å ha veiledningsmøte hver andre uke i stedet for hver tredje. Fordi SHERA var en selvvalgt oppgave, kom vi raskt i gang med det viktigste. Vi fikk tegnet arkitekturskisser, opprettet et skall til applikasjonen i Android Studio, sett litt på diverse databasealternativer, samt satt opp et GitHub-repository og skrevet forprosjektrapporten. Sprinten ble avsluttet med et Scrum-kurs hos Accenture Sprint 2 I begynnelsen av den andre sprinten jobbet vi med å få opp alt på hjemmesiden; risikoliste, Gantt-diagram, og generell informasjon om prosjektet, arbeidsgiver og gruppen. Vi fikk koblet YouTrack sammen med GitHub, slik at tasker ble automatisk grået ut i YouTrack når det ble registrert en pull request merket med nummeret til denne tasken. Videre ble Genymotion satt opp til å fungere med Android Studio. Gjennom hele prosjektet ble denne emulatoren, som både skal være raskere og bedre enn Android Studios innebygde, brukt av én på gruppen. De to resterende har hatt egne enheter kjørende Android, så disse ble koblet til og brukt i stedet. Facebooks SDK ble implementert som en modul i prosjektet, og fikk i denne sammenheng opprettet en LoginButton med den funksjon å verifisere en «user» og starte en 34

36 «session». Vi fikk også implementert Google Maps slik at det er mulig å navigere i kartet etter at en har logget inn med en Facebook-bruker. Vi jobbet med GUI-en på aktivitetene event og event_creator, samt tegnet utkast til applikasjonslogoen. I tillegg til dette kom vi gang med Firebase, der vi først fikk satt opp en enkel nettside med test av input og output, og senere satt opp en applikasjon for å teste det samme Sprint 3 I begynnelsen av denne sprinten holdt vi en presentasjon for styringsgruppen hos Accenture. Gruppen besto av ansatte fra human resources, business, IT, samt ansvarlige for bachelorgruppene. Vi presenterte prosjektet og idéen slik de var og fikk vist frem applikasjonen. Noen av tilbakemeldingene på denne presentasjonen var: Positivt: - God presentasjonsteknikk, som her besto av bruk av kort som vi så ned på av og til. - God oppbygning. - Bra idé. - Godt valg av operativsystem, da Android har klart størst markedsandel. - Godt forberedt. Kunne jobbe med: - Mer obs på ordvalg. «Håp» burde ikke brukes. - Kunne vist flere bilder av applikasjonen under presentasjon av idéen, ikke bare skisser. - Kunne snakket mer om vår bruk av YouTrack. Videre fikk vi spørsmål og kommentarer på følgende: - Hvorfor skal en velge akkurat denne tjeneste i stedet for Facebook events eller annet? - Har andre tjenester samme navn? - Trenger en ansatte i flere land for å vedlikeholde applikasjonen på forskjellige språk? - Husk et enkelt brukergrensesnitt. 35

37 - Viktig å få med kategorier slik at brukere ikke trenger å bla gjennom mye for å finne det de leter etter. - Huske å snakke mer om businessdelen ved neste presentasjon. Videre ble det jobbet med å optimalisere GUI-en på activity_log_in, både i portrett- og landskapsorientering, og til alle skjermstørrelser og DPI-er. Både kart-bakgrunnsbildet og logoen med tekst blir opp- eller nedskalert ut fra pikseltetthet på forskjellige enheter slik at eldre modeller får mindre oppløselige bilder, osv. Det ble også jobbet videre med event_creator der klokke- og datovelger måtte implementeres, samt opprettet et event-objekt som blant annet inneholder tid, dato og adultsjekk. Det ble også opprettet en EventList-klasse som inneholder et listfragment som skal implementeres i Events. Det kan nå opprettes arrangementer i applikasjonen som kan ses direkte i Firebase med rett informasjon i en JSON-string. Helt til slutt ble det gjennomført en geriljatest der vi spurte 20 tilfeldige personer om hvilket av to forsidedesign de foretrakk. Figur 21: Skisse 1 Figur 20: Skisse 2 36

38 Dette ble gjort fordi vi hadde forskjellige meninger innad i gruppen og hadde fått et tips fra vår interne veileder, Tor-Morten, om å gjennomføre en slik test for å raskt komme frem til en rettferdig løsning. Det ble skrevet ut design for begge forsidedesignene og deretter gikk vi rundt og spurte studenter om hvilke de foretrakk. Resultatet endte med 6 mot 14 på skissene over og ga oss en god indikasjon på hvilket design som passet applikasjonen vår best Sprint 4 Det ble satt opp inputvalidering i EventCreator, og vi fikk ordnet slik at brukerne kan opprette markers på kartet ved et langt trykk. Over disse markerne dukker det da opp en tekstboble som inneholder informasjon om arrangementets tittel og beskrivelse. Ved trykk på denne boblen sendes brukeren videre til aktiviteten EventCreatorView.java for videre utfylling av informasjon. Markerne som blir opprettet kan i tillegg flyttes på ved å holde inne på en og dra til dit du vil. GUI-en til event_creator ble optimalisert for alle modeller og skjermstørrelser slik at alt fungerer som det skal på alle enheter. I event_creator.xml er «number» blitt brukt i «antall deltakere»-feltet slik at brukere ikke kan skrive inn noe annet enn tall, noe som gjør at vi slipper å teste på dette utenom. Vi fikk også gjort følgende: - Lagt til en liste i Event-objektet for å kunne lagre bruker-id-en til påmeldte personer. - Oppdatert informasjonen om et arrangement i databasen slik at det kan redigeres av brukeren. - Lagt til en userid i en userlist i Event.java. En stor endring denne sprinten var implementasjonen av Navigation Draweren. Tidligere hadde vi alle menyvalg helt til høyre på Action Baren, under Androids egne innstillingsikon: en vertikal rad med tre prikker. Med denne endringen kom alle menyelementene i en utfellbar «skuff» som kunne hentes ut fra venstre side på skjermen. Dette er en funksjon som brukes i mange store applikasjoner og i stort sett alle av Googles egne, så dette var noe vi måtte ha med. 37

39 Sprint 5 Vi fikk problemer med å hente ut informasjon fra Firebase-databasen fordi alt ble lagret i én lang JSON-string uten noen mulighet for å plukke ut bestemte deler av denne. Derfor var førsteprioritet denne sprinten å omstrukturere databasen slik at informasjon enkelt kunne hentes ut. Dette ble da løst ved at vi kunne skrive egendefinerte objekter til databasen og den tok seg av struktureringen. Den strukturer da dataene som et JSON-tre noe som vil si at de forskjellige attributtene som er definert i objektet vil være nøkkelen og det som er skrevet inn vil være verdien til denne nøkkelen i et HashMap. Hvis en skriver en liste til databasen vil denne struktureres som en ArrayList med indekser som starter på 0. Fordi Firebase-databasen strukturer dataene på denne måten, vil det være lettere å lese de ut igjen. En får et HashMap med alle deler av det egendefinerte objektet og kan dermed forholdsvis enkelt sette objekter sammen og vise disse til brukeren. Videre fikk vi beskjed av veilederne våre hos Accenture at vi måtte rydde i og omstrukturere koden vår, noe som skyldtes dårlig navngivning og struktur. Dette ble gjennomført ved å endre navn på klassene og legge de i forskjellige nyopprettede mapper; view, service, helpers, fragments og dto. Det ble implementert et søkefelt i Action Baren, noe som hjelper brukerne å finne arrangementet de leter etter raskere. Søkefeltet er plassert under et forstørrelsesglassikon helt til høyre på Action Baren. Så fort det skrives inn noe fjernes alle arrangementer som ikke inneholder dette og kun de som gjør det står igjen. Videre ble det lagt til filtreringsmuligheter i Navigation Draweren. Disse besto av kategorivalg, huke av om du vil se arrangementer for personer over 18 år, samt søking på tid og radius. Ved søking på radius vil en gjennomsiktig sirkel sortere på et gitt område ut fra brukerens innhentede GPS-posisjon. Søkeområdet kan gjøres større eller mindre ved å endre posisjonen til «tommelen» i en seekbar. Kun arrangementer innenfor denne sirkelen vil være synlig på kartet. Brukere kunne nå finne påmeldte Facebook-venner på et arrangement. Disse vil dukke opp i et rutenett nederst på informasjonssiden til et arrangement. Avlyste/slettede arrangementer blir nå fjernet fra brukerens arrangementsliste. En liten toast dukker opp og informerer om at et arrangement er blitt avlyst (dog ikke hvilket). 38

40 For å personliggjøre applikasjonen og opprettelsen av arrangementer la vi her til muligheten for å laste opp et hovedbilde til arrangementet du skal opprette, hentet ut fra dine opplastede Facebook-bilder. Disse blir vist for brukeren i et fragment med et rutenett av tilgjengelige bilder. Helt til slutt sørget vi her for å opprette en korrekt applikasjon hos Facebook. Til nå har vi kun hatt en midlertidig applikasjon kalt «login-test», men dette måtte endres til samme navn som applikasjonen vår, SHERA Sprint 6 Denne sprinten implementerte vi en rekke funksjoner: - Det ble satt en «age_range» slik at personer med en Facebook-profil med registrert alder under 18 år ikke vil kunne se arrangementer rettet mot personer eldre enn dette. Alternativet for å huke av dette i Navigation Draweren vil da ikke være tilstede. - Dobbeltrykk på tilbakeknappen på telefonen avslutter applikasjonen og brukeren sendes til «skrivebordet». Ved kun ett trykk dukker en toast opp som informerer om at et trykk til vil avslutte applikasjonen. Flere applikasjoner følger denne standarden og sørger for at brukeren ikke avslutter applikasjoner ved et uhell. - Muligheter for chat ble lagt til. Dette innebærer å opprette chat-objekt-klasse, sette opp Firebase til å holde på disse chat-objektene, samt vise disse til brukeren i form av et ListView med meldinger. - De nyeste arrangementene kommer øverst i listen over påmeldte og opprettede arrangementer. - Det ble lagt til en mulighet for å trykke oppdatér via et ikon til høyre på Action Baren inne på «Events» og «Chats». Utover det som er nevnt over jobbet vi også mye med å fjerne forskjellige feil. Disse innebar alt fra grafiske feil på forskjellige modeller og skjermstørrelser til rene logiske feil som gjorde at noe skjedde som ikke skulle skje. 39

41 Sprint 7 For å gjøre applikasjonen mer «din» la vi til den innloggede brukerens Facebookprofilbilde og -fornavn øverst i Navigation Draweren. Vi la også til at dersom en oppretter av et arrangement er en Facebook-venn av deg, vil vedkommende dukke opp som host/vert på informasjonssiden til dette arrangementet. Det ble jobbet videre med chatten, og dato/tid og brukernavnet til personen som har skrevet meldingen er blitt plassert utenfor chatteboblen. Selve boblene ble gitt forskjellige farger ut fra hvem som har skrevet meldingen; gult tilsvarer verten, grønt tilsvarer andre personer, og blått er dine egne meldinger (gitt at du ikke er vert). Da vi nå begynte å nærme oss slutten på prosjektet jobbet vi også mye med å rydde i koden og holde en god og jevn struktur gjennom alle filene. I tillegg til dette opprettet vi og utførte en rekke enhetstester som testet direkte på bestemte metoder for å sjekke om de returnerer det de skal. I stedet for å bruke Google Maps egne markers, opprettet vi våre egne markers: Figur 22: Forskjellige markers på kartet Der lilla vises når en holder inne på kartet for å opprette et arrangement, rød er for arrangementer du ikke har noe forhold til og som andre har opprettet, grønn er for arrangementer du har meldt deg på og oransje er dine egne opprettede arrangementer. 40

42 Sprint 8 Da dette var den siste sprinten vår, var det fullt fokus på rapporten. Vi satte programmeringsstopp fra og med 1. mai, noe som ga oss over tre uker der vi kun kunne jobbe med rapporten. Vi fikk i tillegg gjennomført både brukertest og systemtest, og dokumentert dette i rapporten. 41

43 3. Produktdokumentasjon 3. Produktdokumentasjon Introduksjon Applikasjonen Innlogging Kartet Arrangementer Chat Navigasjon i Applikasjonen Søking og Filtrering Flytdiagram Applikasjonens struktur Klassediagram LogInView.java MapView.java EventCreator.java EventsView.java EventView.java ChatView.java Design Enheter og skjermstørrelser Be flexible Optimize layouts Assets for all Touch feedback Enheter, DPI og størrelser Typografi Farger Ikoner Logo Fra idé til ferdig produkt Interaksjonsdesign Universell utforming

44 Implementering av retningslinjene i SHERA Konklusjon Android Design Principles Enchant Me Simplify My Life Make Me Amazing Konklusjon Teknologier Facebook Firebase Videreutvikling av SHERA Detaljer Nye funksjonaliteter Konklusjon

45 3.1. Introduksjon SHERA er en arrangementsapplikasjon for Android-enheter. Via et kart lar den brukeren finne arrangementer nær seg, eller opprette egne arrangementer andre brukere kan delta på. Via en gruppechat kan brukeren snakke med andre deltakere på et arrangement både før, under og etter et arrangement. Vår målgruppe med SHERA er mennesker som ønsker å bruke teknologi til å interagere med verdenen rundt seg, møte nye mennesker og utforske både nærmiljøet sitt og nye steder. Vårt mål med SHERA er å skape verdi ved å hjelpe mennesker knytte nye bekjentskaper, oppleve nye ting og skape gode minner Applikasjonen Innlogging Den første aktiviteten som starter i applikasjonen er LogInView.java. Dette er et enkelt skjermbilde med SHERA-logoen, samt en innloggingsknapp via Facebook. Innlogging via Facebook forutsetter at brukeren har en eksisterende Facebook-konto. Etter første innlogging vil applikasjonen ivareta brukerens Facebook-session, og det er derfor ikke behov for å logge seg inn på nytt med mindre brukeren velger å logge seg ut. Figur 23: Innloggingsskjermbilde 44

46 Kartet Til høyre er et bilde av skjermbildet som vil bli vist når brukeren har logget seg inn. På kartet finnes det «markers» der brukere har opprettet arrangementer. Grønn stjerne: Arrangementer brukeren har meldt seg på. Gult hjerte: Arrangementer brukeren har opprettet selv. Rød sirkel: Alle andre arrangementer. Figur 24: Skjermbilde kart Disse markerne kan brukeren trykke på for å få opp mer informasjon om arrangementet, for så å trykke på teksten som kommer opp for å få mer informasjon om et arrangement, samt mulighet til å melde seg på. Figur 25: Skjermbilde kart 45

47 I tillegg til de overnevnte markerne finnes det også en lilla marker formet som et plusstegn. Denne dukker opp når brukeren trykker og holder inne på kartet. Da vil brukeren kunne trykke seg videre på denne markeren for å opprette et nytt arrangement på den valgte lokasjonen, eller flytte rundt på den. Hvis brukeren velger å opprette nytt arrangement vil adressefeltet være ferdig utfylt dersom det finnes en adresse på den valgte lokasjonen. Figur 26: Skjermbilde kart Arrangementer Inne på siden til et arrangement kan brukeren se mer informasjon om arrangementet, blant annet adresse, hvor mange som deltar, når det er, og hvem av brukerens Facebook-venner som også er påmeldt. Hvis en av brukerens venner har opprettet arrangementet vil denne vennens profilbilde bli vist med en ramme rundt. Når brukeren klikker seg inn på et vanlig arrangement vil det være et alternativ å kunne melde seg på øverst i høyre hjørne. Når brukeren er meldt på (slik som på bildet til høyre) finnes det alternativer for å melde seg av, eller å gå til arrangementets chat. Dersom det er brukeren selv som har opprettet arrangementet, vil alternativene være de samme som for påmeldte brukere, men brukeren vil i tillegg ha mulighet til å redigere arrangementet. Figur 27: Skjermbilde arrangementsinformasjon Figur 28: Skjermbilde Action Bar 46

48 Til høyre er skjermbildet for å opprette et arrangement. Her kan brukeren fylle inn arrangementsnavn, beskrivelse, adresse (dersom denne ikke er ferdig utfylt fra en plassert marker) og antall deltakere. I tillegg kan brukeren velge en kategori, om det er kun for voksne (hvis det f.eks. vil bli servert alkohol), samt velge dato og klokkeslett. Brukeren kan også velge å legge ved et arrangementsbilde fra en av sine Facebook-bilder. Figur 29: Skjermbilde opprett arrangement Figur 30: Skjermbilde velg tid Figur 31: Skjermbilde velg dato 47

49 Chat Hvert arrangement har en gruppe-chat som er tilgjengelig for alle arrangementets påmeldte brukere. Chatteboblene er fargekodede: Gul chatteboble: dette er fargen til personen som har opprettet arrangementet. Grønn chatteboble: dette er fargen brukeren ser på sine egne chattebobler med mindre en har opprettet arrangementet, da vil den være gul. Blå chatteboble: dette er fargen på alle andre chattebobler Navigasjon i applikasjonen Figur 32: Skjermbilde Chat Under hovedaktiviteten «MapView» finnes det også en meny. Her kan brukeren velge å opprette et nytt arrangement, se egne og påmeldte arrangementer, se alle gruppechatter som brukeren deltar på eller logge ut av applikasjonen. I tillegg finnes det alternativer for filtrering av hvilke arrangementer som skal vises i kartet. Øverst i menyen vises profilbildet til brukeren som er logget inn, samt fornavn. Figur 33: Skjermbilde Navigation Drawer 48