BuddyTracker INF5261 Final report Nguyen Cong Nguyen Kennet Vuong Thuc Hoang Martin Dang
Innholdsfortegnelse Introduksjon... 4 Ordforklaringer... 4 Idé... 4 Problemstilling... 4 Fokusgruppe... 5 Teori... 5 Personvern... 5 Universal design:... 5 Cityflocks... 6 Mobilitet... 6 System arkitektur... 7 Klient... 7 Webapplikasjon... 7 Cordova... 7 Tilleggsverktøy... 8 Server... 8 Rest API... 8 NodeJS... 8 Database... 8 Server-klient kommunikasjon...10 Utforsking av eksisterende applikasjoner...10 Life360...10 Find my Friends...11 mbuddy...11 Forskningsmetoder...11 Intervju...12 Spørreundersøkelse...12 Brukertester...12 Utviklingsprosess...12 Funksjoner...13 Resultater av intervju...13 High-fidelty prototype...14 2
Analyse...14 Dypere analyse av valg av utviklingsplatform:...14 Utfordringer vedrørende personvern...16 Gjør Buddytracker det lettere å finne hverandre?...16 Konklusjon...17 Referanser...17 Figurliste...19 3
Introduksjon Buddytracker er en mobil applikasjon som skal kunne finne venner ved bruk av geografiske koordinater. Disse koordinatene regnes ut ved hjelp av GPS og mobildata på dagens smarttelefoner. Smartelefonen har blitt en essensiell del av vår hverdag. I en undersøkelse utført av TNS Gallup for MediaNorge [MediaNorge, 2014] kommer det fram at 81% i 2013 av hele Norges befolkning har en smarttelefon. Hvis vi går dypere inn på aldersgruppen, 16-24 år så har over 90 % en smarttelefon [MediaNorge, 2014]. I Norge har vi sterk konkurranse mellom store mobile operatører som tilbyr mobildekning (Telenor, NetCom, Network Norway). De tilbyr den norske befolkningen meget god 3G dekning nesten overalt i landet, og dette er en viktig faktor for vår applikasjon. Applikasjonen krever at man har mobildata for å nøyaktig søke fram bredde- og lengdegrad for en gitt bruker. Til denne endelige rapporten bestemte vi oss for å skrive på norsk. Flertallet i gruppen følte seg mest komfortable med å skrive på norsk. Siden vi også skal ha en muntlig eksaminasjon ut i fra rapporten, var det greit å ha selve rapporten på norsk hvis framføringen også skal være på norsk. Ordforklaringer Noen av uttykkene på engelsk som vi har lest om fra pensumet, og uttykk brukt i kilder fra nettet kan være vanskelig og få en entydig og god oversettelse på til norsk. Derfor har vi valgt å bruke det engelske ordet. Listen over ord som ble brukt bevisst på engelsk er derfor listet her: Native app - En applikasjon som er skrevet i telefonens opprinnelige språk. Hybrid app - En web-applikasjon som er pakket inn til å ligne en native applikasjon. Tracking - å spore. Trail - Spor/Avtrykk Disclosure - formidle/avsløre Temporal - Tid/tidsbestemt Identity - identitet Idé Ideen for vår applikasjon var opprinnelig fra en diskusjon om hvordan vi kunne finne hverandre og andre venner når vi er ute på byen. Med tanke på at en kan være i beruset tilstand etter en kveld på byen kunne det være vanskelig å finne gruppen man var med. Ideen ble realisiert da vi skulle finne et prosjekt vi kunne jobbe med i kurset INF5261. Problemstilling Utvikle en mobil tracking applikasjon med attraktive funksjon som kan finne venner. Utfordringer for applikasjonen: Gjør applikasjonen det lettere for venner og finne hverandre under diverse situasjoner? Personvern, hva slags utfordringer oppstår når man lager en sosial tracking applikasjon? Valg av utviklingsplatform: Native eller hybrid? 4
Fokusgruppe Vår fokusgruppe for dette prosjektet er studenter. Dette vil gjøre det lettere for oss å samle inn nødvendig data fordi vi omgås medstudenter hver dag. Vi er selv studenter og har derfor mulighet til å spørre studenter ved IFI og andre fakulteter rundt om på Forskningsparken og Blindern. Som nevnt i introduksjonen, har nærmere 90% av studentene i Norge, i aldersgruppen 20-24. Vår fokusgruppe for prosjektet er liten, men andelen av andre brukere som kan få nytte av et slikt system er stor. Teori Her vil vi presentere litteratur fra pensumet som vi har lest. Vi har tatt for oss mange av ideéne og fått en mye større forståelse for alle aspektene man må ta stilling til når det kommer til utforming av mobile applikasjoner. Personvern I artikkelen Negotiating Privacy Boundaries in Social Application for Accessibility Mapping blir det presentert flere personverns problemer som oppstår når man utvikler en sosial applikasjon som deler personlig lokasjon. Tre vesentlige punkter innen personvern som blir nevnt: Hvilke informasjon skal man formidle, og hva skal man holde unna? Identitet, hvilke rolle man tar når man formidler informasjonen. Effekten av langvarig lagring av informasjon. Er informasjonen lagret kan den brukes i en annen kontekst og det er ikke noen måte å kontrollere dette på. Gjennom artikkelen diskuteres personvernsproblemer og det oppsummeres at personvernet må kunne forhandles ut i fra situasjonen brukerne er i. Brukeren skal selv ha fullmakt over personvernet i systemet. Universal design: Artikkelen tar for seg hvordan designe mobilen universell for mennesker som har svekket syn, hørsel og eldre mennesker. Det er ikke alltid mennesker med funksjonshemminger eller svekninger kan utføre en oppgave like effektiv som andre. Og det handler om å inkludere flest mulig mennesker til og med de som er nedsatt funksjonsevne. Diskusjoner om universell design for BuddyTracker: BuddyTracker er designet for å intuitiv og veldig lett å bruke. Det er en app som ikke trengs å bruke mye tid for å lære. Hvem som helst kan ha nytte av denne appen. Voksne som passer på barna sine. Hukommelsestap/funksjonshemmende/eldre mennesker, de kan lettere bli passet på uten å være til stede. Alt som trengs er å plante mobilen på en person som skal passes på. Det store spørsmålet her er om de som er funksjonshemmede er i stand til å ha kontroll over appen selv, noe som kan gå utover personvernet. Spesielt de som er blinde eller de som ikke er i stand til å trykke på tastene på mobilen. En løsning på det her er kan være at Buddytracker også forstår talestyring slik at man slipper berøre mobil skjermen for å bruke applikasjonen. 5
Cityflocks Denne artikkelen tar for seg hvordan man får tak i informasjon området rundt seg. Det blir presentert to hoved interaksjon alternativer - direkte og indirekte sosial navigasjoner. Og det blir analysert i hvilken tilfeller det er bedre å bruke direkte ovenfor indirekte sosialnavigasjoner, og vice versa. Hvordan folk får bruk for sosialnavigasjon i hverdagene? Cityflocks kobler opp brukere som ikke kjenner hverandre sammen. Er et slikt sosialbasert navigasjon system bedre enn en profesjonell kilde? Ut fra brukertester og undersøkelser så finner de hvordan folk foretrekker å tak i informasjoner fra. Indirekte eller direkte sosial navigasjon, og når det er mest effektiv på forskjellige situasjoner. For å få med mest folk som mulig til å bli med på å forbedre appen vår, bestemte vi oss for å gjøre undersøkelser og intervjuer. På denne måten kom vi fram til både positive og negative tilbakemeldinger på appen, slik at vi kunne gjøre endringer. Mobilitet Under videre utvikling av applikasjonen vår har vi også tatt med forskjellige konsepter innen mobilitet. I de to siste tiårene har samfunnsutviklingen gått i tråd med utviklingen innen IKT (Informasjons- og kommunikasjonsteknologi). Dette blir sagt i artikkelen Expanding the mobility concept av Karkihara og Sørensen som ble skrevet 2002. Allerede da var det ett økt fokus på teknologi og bruken av det. Fram til i dag har dette fokuset bare økt og det har i stor grad endret vår hverdag, hvor vi i dag lever i et samfunn hvor mobilitet har en viktigere rolle enn noen gang tidligere. Vi er geografisk uavhengige (Kakihara & Sørensen, 2002), vi kan komme dit vi vil ved bruk av forskjellige transportmidler. Vi kan jobbe hvor som helst gjennom internettet. Vi kan jobbe på farten gjennom bruk av mobiler. Tre hovedpunkter innen mobilitet som nevnes i artikkelen er: Romlig. Hvor interaksjonen foregår. Det skjer også ikke bare blant mennesker, men objekter, symboler, bilder etc. Tid (Temporal på engelsk). Når interaksjonen foregår. Man ser på objective tid som er klokketid sammenlignet med sosial tid som er det subjektive. Kontekst. På hvilke måte, i hvilke sammenheng og til hvem interaksjonen foregår. Artikkelen sier at mobiliteten blant mennesker vil øke i takt med teknologien. Videre er det ikke bare bevegelsene og den geografiske uavhengigheten som vil videreutviklet, men også menneskelig interaksjon. I forhold til Buddytracker ønsker vi at man skal kunne finne ut hvor sine venner er uten å være der. Man kan når som helst finne vennene sine i forskjellige situasjoner. Denne mobiliteten er noe vi ønsker å få til med Buddytracker. 6
System arkitektur Klient Webapplikasjon Alle i Buddytracker gruppen kommer fra studieretningen Programmering og nettverk. I starten hadde vi ambisjoner om å utvikle og programmere hele applikasjonen og systemet, men på grunn av tidsbegrensninger i kurset har utviklingen av hele systemet blitt utelatt. Det vi har fått ferdigutviklet er en enkel prototype av brukergrensesnittet til appen. I første omgang har vi valgt å utvikle en singlepage-application (Single-page application, 2007), som er en webbasert løsning for en applikasjon. Dette gjør at brukeren kun forholder seg til en HTML side og all interaksjon og data henting fra server foregår i javascript på klient siden. Fordelen med å gå bruke denne form for utvikling er at det blir mindre belastning på server-siden. Serveren overlater alt design rendering til klient-siden. I tillegg til dette vil det også være lettere for oss å distribuere en web applikasjon over flere mobile plattformer(ios, Android, Windows phone osv), da vi har ambisjoner om å støtte de fleste mobilenheter. Cordova For at vi skal kunne distribuere applikasjonen slik vi ønsker, skal vi bruke et rammeverk som heter Cordova. Med hjelp av Cordova (The Apache Software Foundation, 2012), kan vi utvikle en native applikasjon ved bruk av HTML, CSS og Javascript. Cordova tar koden en har skrevet og pakker det rundt med native kode [Figur 1]. En stor fordel med å utvikle applikasjonen ved hjelp av webteknologiene nevnt ovenfor er at vi kun trenger å utvikle applikasjonen i et språk. Likevel kan vi distribuere applikasjonen raskt til alle platformer og vi slipper også å lære oss platformrettet språk mot de forskjellige operativsystemene (ios, Android etc.). Hvis dette produktet blir et vellykket prosjekt og skal settes i større produksjon, så er det en mulighet å gå native. Det man oppnår gjennom native er en forbedret ytelsen og noe lunde mer strømlinjeformet interaksjon i applikasjonen. Buddytracker er et ganske lite prosjekt, og spørsmålet om det er nødvendig med native applikasjon eller ikke, kommer vi til å diskutere og undersøke med vår mer i dybden med fokusgruppen. Figur 1: Hvordan Cordova fungerer 7
Tilleggsverktøy I tillegg til bruk av Cordova og webteknologier for å få fart på vår prototype, kommer vi til å bruke Ionic framework (Drifty Co, 2013). Ionic er en front-end rammeverk i HTML og CSS som hjelper oss med å sette opp vårt UI-design. Rammeverket setter også opp web applikasjonen på en strukturert måte. Alle DOM manipuleringer kommer til å bli utført av Ionic. For å holde javascript delen av vår applikasjon strukturert og ryddig, kommer vi til å bruke rammetverket AngularJS [kilde]. Angular er utviklet og opprettholdt av Google og vi har også masse erfaringer med dette rammeverket fra tidligere prosjekter. Server Rest API Alle disse verktøyene kombinert, definerer vår applikasjon slik at den fungerer på telefonen. Men hvordan skal applikasjonen kommunisere med andre brukere med samme applikasjon? Vi ønsker å lage et REST API som backend-serversite, hvor en bruker sender HTTP pakker til en server, og serveren vil respondere med informasjon. Hva er et REST API? REST står for Representational state transfer [kilde], dette er en ny måte å bruke den eksisterende HTTP protokollen ved hjelp av GET, POST og mer. Vanligvis sender man en HTTP forespørsel til en server og serveren svarer med ett HTML dokument. Dette er unødvendig bruk av ressurser, da vi kun ønsker data som er relevant for brukeren. Her kommer REST inn i bildet. Når en klient gjør en HTTP forespøresel mot en server, vil serveren svare med data i JSON format, som kun inneholder data som er relevant for brukeren. Eksempel: { user : Ola Nordmann, coordination : { latitude : 01.0000323, longitude : 02.0030333 }} Dette er et eksempel på et JSON format/object. Som man ser er dataen man får tilbake strukturert og lett og lese. Et JSON objekt er en javascript objekt notasjon [kilde], og dette er en lettleselig notasjon med nøkkel-verdi par. JSON fungerer utmerket med javascript, fordi det er slik man oppretter et objekt i Javascript. NodeJS Som server kommer vi til å bruke NodeJS. Grunnen til at vi vil bruke dette er for å komme raskt i gang med utviklingen, og syntaks for denne serverteknologien er Javascript som vi har masse erfaringer med. NodeJS er raskt og har ikke-blokkert input og output. I tillegg er den en veldig lett(lightweight) server applikasjon, som da utfyller våre ytelse krav perfekt. Database Bak denne serveren trenger vi også en persistent database, som kan holde orden på dataene. Det må være sikkert å lagre dataen, men også være stabil. Går databasen ned vil ikke brukerne ha noe data å forholde seg til og man vil ikke kunne finne hverandre. For å oppfylle disse kravene 8
kommer vi til å bruke MySQL eller MongoDB. MySQL er en relasjonsdatabase som betyr at dataen er lagret i tabeller med rader og kolonner. Mens MongoDB ikke er et relasjonsdatabase, men en nosql database, hvor dataen blir lagret som JSON objekter. I følge MoreDevs referansen så er MongoDB 2-3 ganger raskere enn MySQL, men dette teller kun for stor mengde data, og i våres tilfelle, hvor vi er i oppstartsfasen har vi ikke fokusert på skalerbarhet ennå, konklusjonen på database valg, blir at vi velger det som kan få oss raskt i gang, i dette tilfellet MySQL, da dette er noe vi har masse erfaringer med. Figur 2: Systemarkitektur BuddyTracker 9
Server-klient kommunikasjon Figur 3: Interaksjon mellom brukere og server På figuren ovenfor [Figur 3] viser vi hvordan vi tenker oss kommunikasjonen mellom brukerne ser ut. Client 3 er venn med client 1 og 2, og han kan hente data fra begge disse via buddytracker server. Men siden client 1 og 2 ikke er venner, kan ikke de hente data fra hverandre. Utforsking av eksisterende applikasjoner Life360 Life360 (Life360, 2008) er en kryss platform applikasjon, som betyr at den støttes på alle enheter. Life360 er gratis med begrenset funksjonaliteter, applikasjonen går ut på at du kan finne venner og familie gjennom deres system, samt kommunisere med hverandre. Men Life360 har en veldig lukket bruksområde, platformen fungerer best i USA, men den tilbyr langt flere funksjonaliteter enn BuddyTracker, som meldingsutveksling mellom brukere, lokalisering av brukere som ikke har smart phone, og finne forsvunnet telefoner, i tilegg til dette lagrer også life360 historien på steder du har besøkt, noe buddytracker ikke vil, vi lagrer kun siste lokasjon. Våres app har et større fokus på studenter og yngre mennesker, og er mer tilpasset det norske miljø, systemet vårt ligner veldig på Life360, men vi vil holde systemet som open kilde kode, samtidig som det er gratis, mens Life360 tilbyr en sum for ekstra funksjonalitet, vil vi holde alle ekstra funksjonaliteter gratis. 10
Find my Friends Find my Friends (Apple Inc., 2011) er en velkjent app utviklet for ios enheter av Apple. Deres konsept ligner veldig på våres, hvor du kan spore dine venner. Find my Friends har de samme funksjonene som BuddyTracker har, men det som skiller Find my Friends og BuddyTracker er at BuddyTracker sikter mot flere platformer. Find my Friends vil gjøre det mulig for venner å finne hverandre dersom begge har internett, dersom de ikke har det vil det ikke komme opp noe siste kjente posisjon, noe som BuddyTracker tilbyr. Problemet med Find My Friends er at alle funksjonene er implementert, men de fungerer ikke så veldig bra på de ulike ios enhetene. Selv etter at det ble sendt en invitasjon (ref. bilde) så fikk ikke vi lagt hverandre til. Eller at den velger å sende lokasjonen til en annen enhet som er blitt koblet opp mot apple-kontoen. Figur 4: Brukergrensesnittet til Find My Friends mbuddy mbuddy (mbuddy, 2007) er en posisjoneringstjeneste levert av NetCom, hvor norske mobilabonnementer(begrenset til Telenor og Netcom) kan lokalisere hverandre. mbuddy bruker informasjon fra mobilnettet for å finne hvilke basetasjoner en mobiltelefon er tilknyttet. I tettbygde strøk vil deres lokalisering normalt gi nøyaktighet på et par hundre meter, i områder hvor det er langt mellom basestasjonene er det mer normalt med et par kilometers nøyaktighet. Buddytracker bruker GPS-koordinater og vil være mer nøyaktig til en viss grad. Et lite pluss ved mbuddy i forhold til Buddytracker, er at mbuddy lokaliserer ved hjelp av basestasjoner, som vil si at telefonen ikke krever å være en smart telefon eller ha 3g dekning, noe buddytracker applikasjonen krever. Mbuddy operer også på basestasjoner, noe som vi i førsteomgang ikke har tilgang til, og derfor vil ikke dette være vurdert som et alternativ til GPS i buddytracker. Forskningsmetoder Vårt mål er å utvikle et nyttig system med attraktive funksjoner. Målet med datainnsamlingen vi har utført er å kartlegge hvilke funksjoner som kan være nyttige for studenter. Sammen med tilbakemeldinger om hvordan applikasjonen skal se ut, har også innsamlingen gitt oss mange svar på personvernspørsmål. Vi vil også finne ut om studentene legger vekt på om en mobil applikasjon er native eller hybrid. Gjennom disse dataene vil vi kunne rettferdiggjøre vårt valg av utviklingsplatform. 11
Vi har valgt å gjennomføre intervjuer, spørreundersøkelser og brukertester. Disse metodene gir oss både kvalitative og kvantitative tilbakemeldinger som gir oss et bredt spekter av data som vil hjelpe oss med valgene vi tar. Intervju Intervjuer er en god måte å tilegne seg kvalitative tilbakemeldinger fra brukerne. Vi hadde ett sett med strukturerte spørsmål, samtidlig er disse spørsmålene åpne slik at brukerne selv kan fortelle sin mening om applikasjonen. Dette kalles for semi-strukturert intervju, og med dette kan brukeren ha friheten til å gi oss sine ideér og forslag. Målet er å få svar på ting som vi kanskje ikke har vært oppmerksom på, slik at vi kan forbedre designet og applikasjonen. Spørreundersøkelse Spørresundersøkelser er brukt for å få kvantitative data om brukergruppen. Sammenlignet med intervjuer kan vi spørre en mye større brukergruppe uten at brukerne selv er tilstede. De er også veldig lett å gjennomføre fordi de er strukturerte og kravene er få. Brukertester Dette ble brukt for å involvere brukerne under utviklingen og testingen. Brukertester ble tatt i bruk for å teste prototypen vår og få verdifull tilbakemeldingen på funksjonaliteten og designet. Dette er viktig for å kunne utføre forbedringer og fikse feil i applikasjonen. Det er ikke mulig for utviklerne og finne alle feil, og det beste er å få tilbakemeldinger fra brukerne selv. Utviklingsprosess Vi bestemte oss for å ta i bruk brukersentrert utvikling (Lawton & Thorp, 2008). Vi vil involvere brukerne tidlig og finne ut hva brukerne ønsker. Det finnes gode lignende applikasjoner som Buddytracker. Vi har testet noen av disse for å finne ut hva som mangler, ikke er bra nok, eller rett og slett noe nytt som brukerne ønsker. Fra artikkelen Universal design for mobile phones har vi funnet et diagram som i stor grad har påvirket vår utviklingsprosess. Figur 5: Universal design diagram 12
Funksjoner Den mest vanlige funksjonen i et tracking system er å kunne se hverandre på kartet. Dette vil selvfølgelig være en viktig del av applikasjonen, men vi vil også legge til ha en ekstra funksjoner. Det skal være opp til hver enkelt å bestemme om posisjonen skal være synlig eller ikke for å unngå at systemet gjør noe brukeren ikke vil. Applikasjonen må derfor ha et krav om mulighet for å forhandle personvern ut fra hvilken situasjoner brukeren er i (Holone, H., Herstad, J. 2010). Brukeren må gi oss tilgang til å lagre deres informasjoner til en viss grad, men ikke over lengre tid. Ideer på funksjoner til appen vår: Busy mode (andre brukere kan ikke se deg) Begrense tilgjengelighet på kartet (andre brukere får kun se deg i en kort periode) Alert mode (i tilfelle det er en nødsituasjon) Open source kart (vise posisjonene til brukere) Kontakt liste (Slette/legge til kontakter) Bruker profil (Generell informasjon) Resultater av intervju De fleste som vi intervjuet syntes disse funksjonene var viktig for en app som Buddytracker, spesielt busy mode. Hadde det ikke vært for busy mode så kunne de aldri tenkt seg å ha appen instalert på mobilen. Busy mode blir den store skillen mellom vår applikasjon og et overvåknings program. På open source kartet fikk vi også mye bra tilbake meldninger på. De sa at det hjelper å få et visuelt bilde på hvor andre brukere var istedenfor å bare få gate/vei adressen. Ellers var syntes de fleste at det holder med disse funksjonene. Fordi da blir det ikke så mye å sette seg inn i. Jo mer funksjoner en app har jo mer tid trengs det for å forstå appen. Andre ønskede funksjoner fra intervjuene: Skjule noe av informasjonen i profilen til man er blitt venner. Sende meldinger til hverandre i form av chat eller lignende. Opprette møte plass til en bestemt tid. Noen få som vi intervjuet ville at vi skal legge til en funksjon slik at man kan skjule noe av den generelle informasjon på brukerprofilen, som etternavn, fødselsdato/alder/kjønn, telefonnummer, pga personlige grunner. Det var en god ide som lett kan bli implementert. Vi vil at appen skal være enkel å bruke derfor utelukker vi funksjoner som ringe eller sende hverandre melding gjennom appen. Appen er kun ett alternativ for å kunne hverandre enklere uten å måtte sende melding eller ringe. For oppretting av møteplasser så har vi tenkt på det, men har ikke implementert det i prototypen. 13
High-fidelty prototype Etter tilbakemelding fra brukerne og ideene deres om funksjoner og design, har vi lagd en webapplikasjon prototype. Denne prototypen er ren HTML, CSS og Javascript som vi ikke enda har fått pakket inn i Cordova for utrulling til de forskjellige operativsystemene. Vi har ikke fått funksjonene til å fungere som vi ønsker enda og dette er bare bilde på hvordan applikasjonen vil bli seende ut. Analyse Figur 6: Skjermbilde av BuddyTracker prototype Dypere analyse av valg av utviklingsplatform: Vi valgte å ta i bruk Cordova som er et kryssplatform rammeverk. Med tanke på vår kompetanse og begrensende tid i kurset kunne vi ikke utvikle for alle de tilgjengelig mobile platformene. Derfor valgte vi en utviklingsplatfrom som man kan rulle ut for alle. Etter en intern diskusjon innad i gruppen kom vi fram til: For brukerne spiller det ingen rolle hvordan applikasjonen er utviklet, så lenge det fungerer og brukeren får gjort det dem ønsker. Vi lagde derfor en spørreundersøkelse som inneholdt representater som hovedsaklig er fra UiO, men også noen fra HiOA for å undersøke vår påstand. Totalt var det 33 personer som svarte på undersøkelsen anonymt. Målet med spørreundersøkelsen var å finne ut mer om studenters generelle kunnskap om utviklingsplatformer. Om hva som viktigst i en mobilappliaksjon, og om de i det hele tatt bryr seg om hvordan applikasjonen er utviklet. 14
Spørsmål brukt for undersøkelsen: 1. Hybrid eller native mobil applikasjon? Hybrid Native Vet ikke forskjellen mellom dem 2. Vet du hva en native eller en hybrid applikasjon er? Ja Nei 3. Hva er det viktigste med en mobil applikasjon: Design Funksjonalitet Ytelse 4. Hvis applikasjonen fungerer, yter bra og har et bra design. Hybrid eller Native? Hybrid Native Spiller ingen rolle Resultater av spørreundersøkelsen: På spørsmål 1, svarte majoriteten på at dem ikke vet forskjellen. Hele 90 % visste ikke forskjellen. Dette tallet hadde nok vært høyere om deltagerne hadde vært mer spredt om på fakultetene på UiO. En høy del andel av deltagerne var IT-studenter, og vi antar at dem vet en del mer om ulike utviklingsteknologier for mobil enn f. eks farmasi studenter. De resterende svarte at dem foretrakk native applikasjon. Spørsmål 2 er veldig relatert til spørsmål 1. De som ikke visste hva forskjellen var mellom hybrid og native mobilapplikasjoner, vet heller ikke hva de enkelte platformene er for noe. Spørsmål 3 gav ganske spredte svar. En liten andel på bare 2 % mente at ytelse var det viktigste. Resten var ganske jevnt fordelt mellom design og funksjonalitet. Det vi ser her er at få legger vekt på ytelse, som er en av hovedgrunnene til at man går native. Design og funksjonalitet er noe hybrid applikasjoner kan tilby. På spørsmål 4 svarte alle, utenom en deltager på at det spiller ingen rolle på hvilke platform man utvikler i. For å oppsummere, majoriteten vet ikke hva forskjellen på Native og Hybrid applikasjoner. De som ikke vet forskjellen legger derfor ikke stor vekt på hva slags platform applikasjonen er utviklet så lenge dem for gjort det dem skal. Selv de som vet forskjellen, legger ikke så stor vekt på ytelse, og de mener at så lenge applikasjonen gjør det de ønsker så kan det for all del være hybrid utviklingsplatform. Eneste grunnen til at man går for native applikasjon er en noe forbedret ytelse, men veldig få la vekt på dette som en viktig funksjon. Vi kan dermed si at valget vårt av å bruke en hybrid utviklingsplatform var et godt valg. 15
Utfordringer vedrørende personvern Personvern i BuddyTracker har gått gjennom mange diskusjoner internt på hvordan vi skal løse det. Hvor går grensen på for mye informasjon og hvor går grensen for altfor sensitiv informasjon? Palen og Dourish (Holone, H., Herstad, J. 2010) definerte informasjonslagring ved å bruke temporality boundary. I de siste årene har lagring av persondata forandret seg helt, før var det vanlig å tenke seg at informasjonen bare ville være tilgjengelig midlertidig. Men nå er det sånn at i det informasjonen er blitt lagt ut på internett så vil den være der mye lengre enn før, det kan ta måneder eller år før informasjonen blir glemt. BuddyTracker tar høyde for dette ved å begrense hvilken data som blir lagret av brukeren når de bruker BuddyTracker. Istedenfor å lagre trails om hvor brukeren har vært (som mobiloperatørene gjør i det skjulte (Lekanger, 2012)), så vil vi kun lagre siste kjente koordinat til enhver tid i en kort periode. Dette er for at brukeren ikke kan bli overvåket ved senere anledninger slik at informasjonen om brukeren forblir minimalt for økt sikkerhet. Dersom brukeren ønsker å forlate tjenesten vil vi slette all data som tilhører denne brukeren, samt alle relasjoner mellom brukeren og andre brukere i systemet. Eller om brukeren har lyst på innsyn av sin egen data vil han få dette fortløpende, for det er slått fast i personopplysningsloven 16 (2001) at brukeren har rett på informasjon om data som er lagret innen 30 dager. På denne måten har brukeren full kontroll på hvilken informasjon BuddyTracker har på brukeren og muligheten til å fjerne all data på seg selv hos BuddyTracker. Dette er en av hovedfundamentene for BuddyTracker som vil gjøre det mer attraktivt i forhold til mange andre tjenester som Facebook som lagrer data om brukeren til tross for at brukeren har meldt seg ut av tjenesten. Vi har også sett på disclosure boundaries og identity boundaries som blir nevnt i artikkelen. Dette gjør vi gjennom de diverse funksjonene vi vil ha med i Buddytracker. På den måten er det hele tiden brukeren som bestemmer hva og når dem publiserer informasjon, og hvilke rolle dem tar inne i systemet. Gjør Buddytracker det lettere å finne hverandre? Ved første forelesning ble det presentert et prosjekt for å lage en GPS tracker som de kan feste på deres ski, for å finne ut om det noen var forsvunnet fra gruppen på fjellet da de sto på ski eller ble tatt av snøskred. Det var da vi tenkte; Hvorfor ikke bruke deres telefon til å gjøre det samme?. Vi har i utgangspunktet vår telefon med oss overalt, dette kunne vært til nytte for alle. I vårt prosjekt brukte vi studenter som fokus gruppe. Hvis vi sammenligner den nye tilnærmingen av å finne hverandre mot hvordan vi skulle finne hverandre på byen tidligere. Så er vi alle i gruppen enige at Buddytracker ville hjulpet oss. Buddytracker konseptet kan kan også konverteres til andre brukergrupper: Eldre mennesker kan utstyres med en smarttelefon hvor man Buddytracker er på. Foreldre kan passe på barna sine gjennom å ha Buddytracker på mobilen. Eventuelt andre familiemedlemmer. 16
Dette er to konkrete eksempler på hvor Buddytracker kan være nyttig og lett å bruke, foruten vårt eksempel hvor det handler om å finne venner på byen. Konklusjon Da vi bestemte oss for å utvikle Buddytracker var utvikling av applikasjonen vår viktigste prioritet. Vi har derfor gått i dybden på systemarkitektur og forklart nøye hvordan vårt planlagte system blir. Men pågrunn av tidsbegrensningene har vi måtte nedprioritere utviklingen av applikasjonen, og vi fikk heller ikke satt opp en workshop for brukerne. Det vi har lært mye underveis er at det er mange andre komplikasjoner som oppstår når man skal utvikle en mobil applikasjon. Personvern er en viktig del av Buddytracker og vi tror at gjennom måten vi ønsker å behandle dataene på er en god måte å bevare personvernet på. Den nåværende versjonen av Buddytracker har ikke universal design, men dette er noe vi har tenkt mye på, og vi har også nevnt hvordan vi kan løse visse situasjoner for forskjellige type brukere. Referanser [1] Andel som har smarttelefon (2014) MediaNorge [Internett]. Tilgjengelig fra: <http://medienorge.uib.no/statistikk/medium/ikt,oppdatering/379>. [Lest 1. Oktober 2014]. [2] Andel med tilgang til smarttelefon (2014) MediaNorge [Internett]. Tilgjengelig fra: <http://medienorge.uib.no/statistikk/medium/ikt,oppdatering/379>. [Lest 1. Oktober 2014]. [3] Kakihara, M. and Sørensen, C. (2002) Mobility: An Extended Perspective. 35th Annual Hawaii International Conference on System Sciences [4] The Apache Software Foundation (2012) Apache Cordova [Internett], The Apache Software Foundation. Tilgjengelig fra: <http://cordova.apache.org/>. [Lest 10. November 2014]. [5] Google Inc. (2010) AngularJS [Internett], Google Inc.. Tilgjengelig fra: <https://www.angularjs.org/>. [Lest 10. November 2014]. [6] Representational state transfer (2008) Wikipedia [Internett]. Tilgjengelig fra: <http://en.wikipedia.org/wiki/representational_state_transfer>. [Lest 1. Oktober 2014]. [7] JSON (2005) Wikipedia [Internett]. Tilgjengelig fra: <http://en.wikipedia.org/wiki/json>. [Lest 1. Oktober 2014]. [8] Joyent Inc. (2009) NodeJS [Internett], Joyent Inc. Tilgjengelig fra: <http://nodejs.org/> [Lest 1. Oktober 2014]. 17
[9] Moredevs (14. Mars 2013) MySql vs MongoDB performance benchmark [Internett], Moredevs. Tilgjengelig fra: <http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/>. [Lest 10. November 2014]. [10] Life360 (2008) Life360 [Internett], Life360. Tilgjengelig fra: <https://www.life360.com/>. [Lest 1. Oktober 2014]. [11] Apple Inc. (2011] Find My Friends [Internett], Apple Inc.. <https://www.apple.com/apps/find-myfriends/>. [Lest 1. Oktober 2014]. [12] Shawn Lawton Henry, Justin Thorp. (18. April 2008). WAI: strategies, guidelines, resources to make the Web accessible to people with disabilities [Internett], W3C. Tilgjengelig fra: <http://www.w3.org/wai/redesign/ucd>. [Lest 1. Oktober 2014]. [13] Plos, A., Buisine, S. (2006). Universal design for mobile phones: a case study. ACM. [14] Bilandzic, M., Foth, M., & De Luca, A. (2008). CityFlocks: Designing Social Navigation for Urban Mobile Information Systems. Paper presented at the ACM SIGCHI Designing Interactive Systems (DIS) Conference, Cape Town, South Africa. [15] Holone, H., & Herstad, J. (2010). Negotiating privacy boundaries in social applications for accessibility mapping. In Proceedings of the 6th Nordic Conference on Human-Computer Interaction: Extending Boundaries (pp. 217-225). ACM. [16] Lekanger, Kurt (2012) 2000 lesere krevde innsyn. Artikkel, Mediehuset Tek, 7. Juni 2012 [Internett]. Tilgjengelig fra: <http://www.tek.no/artikler/2000-lesere-krevde-innsyn/109994>. [Lest 10. November 2014]. [17] Personopplysningsloven - popplyl. (2000) Lov om behandling av personopplysninger (personopplysningsloven) 01. Januar 2001. Tilgjengelig fra: <https://lovdata.no/dokument/nl/lov/2000-04-14-31>. [Lest 10. November 2014]. [18] mbuddy (2007) mbuddy [Internett], mbuddy. <http://www.mbuddy.no/buddyweb/>. [Lest 10. November] [19] Single-page application (2007) Wikipedia [Internett]. Tilgjengelig fra: <http://en.wikipedia.org/wiki/single-page_application>. [Lest 10. November 2014]. [20] Drifty Co (2013) Ionic [Internett], Drifty Co. Tilgjengelig fra: <http://ionicframework.com/>. [Lest 10. November] 18
Figurliste [1-4 + 6] Selvlagde bilder av BuddyTracker-gruppen (2014). [5] Tatt fra Plos, A., Buisine, S. (2006). Universal design for mobile phones: a case study. ACM. 19