Freporter. Malin Kristensen. Midtveisrapport. Mobile Anvendelser Høgskolen i Østfold, avdeling for Informasjonsteknologi Mars, 2010 Halden, Norway

Transkript

1 Freporter Midtveisrapport Malin Kristensen Mobile Anvendelser Høgskolen i Østfold, avdeling for Informasjonsteknologi Mars, 2010 Halden, Norway

2 Abstrakt Ved større arrangementer som for eksempel en triatlon, Grenserittet her i Halden eller lignende, vil det kunne være problematisk for en enkelt eller noen få reportere å dekke hele arrangementet. Da vil en mobilapplikasjon som lar alle brukere av den samarbeide om å dekke for eksempel et sportsarrangement, kunne være til hjelp. Tanken bak applikasjonen er at det vil kunne være mange brukere av systemet som til sammen er med på å dekke arrangementet. Dette kan være både privatpersoner utstyrt med smarttelefoner og/eller profesjonelle reportere. Hver bruker tar bilder, videoklipp, lydopptak eller en kort skriftlig rapport av arrangementet og laster dette opp til basen i tillegg til data om hvor brukeren har logget denne informasjonen fra, altså hvor ved arrangementet brukeren har rapportert, og til hvilken tid. I en bestcase-scenario, vil hele arrangementet bli dekket med bilder, video, lyd og skriftlige rapporter. Dette prosjektet vil ta utgangspunkt i å lage en applikasjon for bruk under Grenserittet i første omgang.

3 Innhold Abstrakt Scenarier...4 SafeWay...4 GpsGame...4 Freporter...5 NaviNow...5 MoSARt...6 DangerMap...6 Applikasjonen Generelt om applikasjonen Brukerne - hvem er det? Hvorfor denne applikasjonen?...10 Generelt om HCI-paradigmene...11 HCI for Freporter...12 Simplicity og Predictability...13 Heuristikker...13 Kontekst...20 Referanser...24

4 Kapittel 1 Introduksjon Mobile Anvendelser er obligatorisk kurs for alle masterstudenter på Høgskolen i Østfold avdeling for Informasjonsteknologi. Emnets innhold er nært knyttet til FoUarbeidet som utføres i avdelingens tverrfaglige gruppe for mobile anvendelser (Mobile Applications Group, MAG). En mobil applikasjon er generelt en programvare som kjører på en mobil enhet. I dette tilfelle er enheten som oftest et velutstyrt mobiltelefon. Videre i kurset fokuseres det på applikasjoner som støtter noen form for sosial interaksjon. Målet med kurset er at studentene skal etter gjennomført emne være teoretisk og praktisk forberedte til å designe og utvikle mobile applikasjoner, med spesiell vekt på grensesnitt, kontekst, brukergenerert innhold, pålitelighet og sosial interaksjon. Arbeidskrav i kurset er at studentene skal gjennomføre og få godkjent et antall individuelle obligatoriske oppgaver. I forbindelse med undervisningen skal studentene selv bidra i presentasjon og diskusjon av egne resultater. Det skal utvikles en prototype på en mobil applikasjon, gitt visse rammer. Implementasjonen kan være en fungerende applikasjon, eller en såkalt "mock-up", der konseptet demonstreres ved grafiske illustrasjoner, fotografier, video, og liknende teknikker. Det vil være et krav at prototypen skal evalueres i en begrenset brukertest. Vurderingen gjøres basert på en individuell sluttrapport som skrives i forbindelse med utviklingen av den mobile applikasjonen. Prosjektet i faget baserer seg på design, prototyping og evaluering av en mobil applikasjon. Dette prosjektet må være basert på ett av flere scenarier. 1.1 Scenarier SafeWay Det er fredag kveld, og du skal flytte deg (til fots) fra ett sted til et annet, i sentrum av en stor by som du ikke kjenner godt. Du vil finne en trygg rute. En appliksjon som vil kunne hjelpe brukeren ved dette scenarioet vil være en applikasjon som benytter seg av din GPS-lokasjon til å vurdere en mulig vei til målet. Applikasjonen må kunne ta imot målposisjon ved hjelp av for eksempel bruk av peker eller lignende. På bakgrunn av disse to koordinatene skal den kunne vise

5 korteste og sikreste vei til målet, ved å benytte seg av for eksempel en database på en server hos leverandøren som til enhver tid er oppdatert på hvilke områder som kan medføre fare. Applikasjonen kan ha et brukergrensesnitt som ligner det man finner på standard GPS-moduler til bruk i bil, med en pil eller lignende som viser brukerens posisjon i tillegg til hvilken retning han/hun burde gå for å følge den beregnede stien. I tillegg bør applikasjonen vise hvilke områder hvor brukeren er spesielt utsatt for fare, ved å merke områdene på kartet med en dus rød farge. GpsGame Du tilbringer en søndag ettermiddag i parken sammen med noen venner, og ønsker å løpe rundt og ha god gammeldags lekeplassmoro, ved hjelp av mobiltelefonen din med innebygd GPS. En applikasjon som brukeren kan bruke ved dette scenairoet er en applikasjon som feks baserer seg på høgskolens Revespill, hvor brukerne skal jakte på animerte rever som vises på et kart på mobiltelefonen. Her vises også din posisjon og poengscore, i tillegg til de andre spillernes poeng. Freporter Som freelance reporter, skal du dekke en stor begivenhet, som for eksempel et triathlon løp. Du innser at du ikke klarer å dekke alle aspekter av hendelsen selv, og ville gjerne ha noen å hjelpe deg med å ta bilder, video og lage små rapporter fra de ulike stedene. Her vil en applikasjon som lar alle brukere av den samarbeide om å dekke for eksempel et sportsarrangement ved at brukerne logger sin posisjon i en felles database hos leverandøren, være en mulig løsning til scenariet. Deretter kan brukerne ta bilder, video og lydopptak av arrangementet eller hendelsen, og laste disse opp til lagring hos administratoren av systemet. På den måten vil bildene lastes opp med posisjon og klokkeslett som til sammen gjør at man får dekket hele arrangementet. Det vil være naturlig om applikasjonen baserer seg på kamera funksjonaliteten på telefonen, og at funksjonaliteten for å laste opp kan være en type plug-in, som gjør det mulig å laste opp de bilder osv. som er tatt, til basen. Brukerens posisjon blir lagt ved filen som sendes enten ved at brukeren legger denne til ved å merke et punkt på et kart lastet til telefonen ved arrangementets start, eller automatisk ved hjelp av innebygget GPS-mottaker, alt etter hva slags telefon brukeren er utstyrt med. NaviNow Du sitter fast i trafikken på vei til jobb, på grunn av tung snøfall. Du er ikke sikker på hvilke veier er åpne for trafikk, slik at du ikke kan finne en alternativ rute. Her vil en applikasjon som ved hjelp av brukerens posisjon, gitt av mobiltelefonens GPS-mottaker, kan beregne ulike mulige kjøreruter som vil føre brukeren til gitt

6 mål. Målet gis av brukeren ved å merke det i et kart, basert på mobilens navigasjonstjeneste. I dette samme kartet blir så en eller flere mulige ruter tegnet opp, med ulike fargekoder basert på hvor lite trafikk det mest sannsynlig er der, og hvor langt det er ekstra å kjøre. Hvor mye trafikk som er i området kan man finne ut ved at alle som har denne applikasjonen laster opp sin posisjon med jevne mellomrom. På den måten ser man hvilke brukere som er i bevegelse, og ikke minst hvor de er i bevegelse. På bakgrunn av dette kan en ny rute beregnes, og systemet er hele tiden oppdatert på hvor trafikken beveger seg. Dataene som blir gitt av brukerne selv, er selvfølgelig avhengig av at det er nokså mange brukere av systemet som er logget på til enhver tid. Dataene kan også bli supplert av data fra kameraer langs veiene osv., i tillegg til data gitt av evt. rapporter fra andre brukere, som har informasjon om veiene. På den måten blir systemet mest mulig konsekvent og nøyaktig. MoSARt Du er på fottur med barna dine i et skogsområde, ofte brukt til rekreasjonsformål. På et tidspunkt innser du at du ikke vet hvor din fem år gamle sønn er, og etter et raskt søk finner du ham ikke. Du ønsker å få andre mennesker i området til å lete etter ham. En applikasjon som vil være til hjelp ved dette scenarioet, kan være en applikasjon som gjør det mulig for forelderen som har mistet barnet sitt å sende ut et bilde av barnet som er borte til alle mobiltelefoner i nærheten av brukerens egen posisjon. Dette er igjen basert på GPS-mottakeren på telefonen, og multimedia-meldinger på telefonen. Applikasjonen finner alle mobiltelefoner med GPS-mottaker i en gitt omkrets, og sender deretter ut et bilde av barnet som er savnet til alle disse, i håp om å finne barnet raskere. DangerMap Du arbeider i en barnehage og har en haug med unger med deg på en piknik. I nærheten av rasteplassen leger du merke til at det er et manglende lokk på et kloakkhull, og du tenker: Hva hvis en av ungene snublet og falt i hullet? Du vil rapportere det slik at andre mennesker ville bli klar over faren, og at det kunne bli løst. Her vil en typisk nettapplikasjon som inneholder ett kart med alle registrerte slike farer, være en løsning som vil kunne gjøre det enklere både for beboere i kommunen og kommunen selv, å registrere slike farer for så å utbedre dem. Applikasjonen vil kunne bruke GPS-mottakeren på telefonen om brukeren selv er på stedet hvor faren befinner seg. Dersom brukeren ikke er på lokasjonen som faren er når han vil registrere det, er det naturlig å kunne tilby et kart hvor brukeren kan peke ut posisjonen til denne faren. Det vil også kanskje virke naturlig med en slags varslingstjeneste som sender brukere som befinner seg i områder med en mulig fare, en tekstmelding eller lignende som gir noe informasjon om denne.

7 Kapittel 2 Applikasjonen 2.1 Generelt om applikasjonen Ved større arrangementer som for eksempel en triatlon, Grenserittet her i Halden eller lignende, vil det kunne være problematisk for en enkelt eller noen få reportere å dekke hele arrangementet. Da vil en mobilapplikasjon som lar alle brukere av den samarbeide om å dekke for eksempel et sportsarrangement, kunne være til hjelp. Tanken bak applikasjonen er at det vil kunne være mange brukere av systemet som til sammen er med på å dekke arrangementet. Dette kan være både privatpersoner utstyrt med smarttelefoner og/eller profesjonelle reportere. Hver bruker tar bilder, videoklipp, lydopptak eller en kort skriftlig rapport av arrangementet og laster dette opp til basen i tillegg til data om hvor brukeren har logget denne informasjonen fra, altså hvor ved arrangementet brukeren har rapportert, og til hvilken tid. I en bestcase-scenario, vil hele arrangementet bli dekket med bilder, video, lyd og skriftlige rapporter. Dette prosjektet vil ta utgangspunkt i å lage en applikasjon for bruk under Grenserittet i første omgang.

8 Brukerne installerer applikasjonen før arrangementet. På dagen av arrangementet registrer de brukerne som har tenkt til å bidra med data seg i systemet ved å sende for eksempel en tekstmelding til et gitt nummer med kommandoen START eller lignende. Brukerne logger sin posisjon i en felles database hos leverandøren, som for eksempel er administratoren av arrangementet, en avis eller et nyhetsbyrå som dekker arrangementet. Deretter kan brukerne ta bilder, video og lydopptak av arrangementet eller hendelsen, og laste disse opp til lagring hos administratoren av systemet. På den måten vil bildene lastes opp med posisjon og klokkeslett som til sammen gjør at man får dekket hele arrangementet. Det vil være naturlig om applikasjonen baserer seg på kamera funksjonaliteten på telefonen, og at funksjonaliteten for å laste opp kan være en type plug-in, som gjør det mulig å laste opp de bilder osv. som er tatt, til basen. Brukerens posisjon blir lagt ved filen som sendes enten ved at brukeren legger denne til ved å merke et punkt på et kart lastet til telefonen ved arrangementets start, eller automatisk ved hjelp av innebygget GPS-mottaker, alt etter hva slags telefon brukeren er utstyrt med. Uten at alle detaljer er helt klare, er en tanke rundt opplasting av såkalte rapporter vil det kunne være en type kode eller lignende som applikasjonen legger ved rapportene som lastes opp. Ideen er da at dette kan tydes av serveren som mottar dataene, og da kan finne ut hvor brukeren som har sendt inn rapporten befinner seg, basert på GPS-koordinatene fra mottakeren i telefonen. En annen type bruk av systemet er brukerne som kun er ute etter å hente informasjon om løpet mens det pågår, og etter. Det vil da være naturlig at alle brukere som er registrert i systemet kan se plasseringen til andre brukere som er

9 registrert for arrangementet, i et kart representerer med punkter eller avatarer. Her vil det også kunne være naturlig å implementere en funksjonalitet som gjør det mulig å se dataene som er logget av de ulike brukerne ved å peke på deres avatar i kartet. En måte å løse dette på er den metoden som Google Earth har benyttet for visning av bilder osv. Ved å zoome inn på kartet vil man kunne se flere detaljer og mer nøyaktig plasserte ikoner på kartet som symboliserer data tilgjengelig for området. Her vil det også kunne være naturlig med funksjonalitet som lister opp all data som er tilgjengelig å se i en, kanskje mer oversiktlig, listefremvisning. Denne funksjonaliteten vil også kunne bli en del mindre ressurskrevende. Integriteten til dataene som blir lagt til i systemet av brukerne, kan variere. Brukere kan tolke situasjoner i løpet på forskjellig måte, og noen brukere kan være mindre troverdige enn andre. Dette kan hell klart være trusler og fallgruver i forhold til troverdigheten til applikasjonen. Videre kan det bli noe problematikk rundt brukernes privatliv i forhold til om de for eksempel flytter på seg under løpet, reiser fra arrangementet eller lignende En videre utvidelse av applikasjonen vil kunne være å tilknytte de dataene som er samlet av brukerne med data samlet av Grenserittet-administrasjonen i etterkant av løpet for å komplettere dekningen av løpet.

10 2.2 Brukerne - hvem er det? For denne applikasjonen kan man definere to typer brukere. Brukere som bare er ute etter å lese og bruke dataene som blir registrert, og så har vi brukerne som bidrar med data. Av brukerne som bidrar med data har vi igjen to typer brukere. Det er amatører og privatpersoner som følger løpet for moro skyld, og profesjonelle brukere som for eksempel jobber for et nyhetsbyrå eller avis. For å begrense målgruppen for denne applikasjonen velger jeg å fokusere på utvikling av en applikasjon som er rettet mot brukere som er å anse som amatører. Det vil si at jeg vil rette applikasjonen mot brukere som er ute etter å dele og se data om Grenserittet, kun for moro skyld, og i utgangspunktet for privat bruk. På den måten er det ikke like viktig med dataenes integritet. Det vil derfor heller ikke være like viktig med å screening av dataene som kommer inn for å sikre at dataene som blir lagret er helt riktige, og at ikke samme data blir logget mange ganger. Det vil også være viktig å se mulig bruk av systemet for eksempel ved en ulykke eller andre nødssituasjoner. Her kan applikasjonen hjelpe helsepersonell ved at de enklere kan får grep om omfanget av det som skjer ved å se bilder og rapporter som er lastet opp, før de selv kommer til åstedet. 2.3 Hvorfor denne applikasjonen? Dette er et interessant prosjekt siden det omhandler deling av data i real-time, som i seg selv er ganske spennende. Prosjektet vil bruke seg av flere teknologier som finnes på moderne mobiltelefoner, som GPS, Wifi, 3G, GPRS, SMS og MMS. Det kan også være en mulig videreutvikling å implementere bruk av RFID-brikker, eller for eksempel QR-kodeleser i applikasjonen for å registrere og administrere brukere. Hele konseptet med å samarbeide om å samle data om et arrangement som dette er nokså interessant, da brukerne selv står for deler av dataene som andre senere kan benytte seg av. Dette har vist seg å være en nokså effektiv og interessant måte å samle og dele data på, for eksempel ved Wikipedia. Applikasjonen er en sosial applikasjon da den baserer seg på deling av data som brukerne selv samler inn. Det sosiale aspektet er nokså klart da brukerne deler dataene som samles inn og de kan beskues av alle registrerte brukere i systemet ved å enten navigere seg rundt i kartet og markere de ulike avatarer eller punkter på stedet man ønsker å hente data om, eller ved listefremvisning, som nevnt over. Applikasjonen er også mer egnet for mobiltelefoner, ikke bare som en webside fordi

11 brukerne kan være on-site og følge løpet hele veien. Brukeren kan følge med når en deltaker kommer til å passere basert på rapporter og bilder. Samtidig kan andre brukere som befinner helt andre steder enn ved selve løpet, følge alt som skjer live uten å være avhengig av å ha en datamaskin med internett tilgjengelig. Et liknende prosjekt som er gjennomført er View & Share: Exploring Co-Present Viewing and Sharing of Pictures using Personal Projection av Andrew Greaves og Enrico Rukzio ved Computing Department, Lancaster University, UK. [1]. Den typiske scenarioet som er adressert av View & Share mobilapplikasjonen, er basert på for eksempel en gruppe venner som møter hverandre og vil vise og dele sine bilder. View & Share støtter rask og effektiv co-present visning og deling av medier som er lagret på brukerens mobile enheter. The View & Share applikasjonen innkapsler delingsprosessen og gir enkel kommunikasjon, koordinering og medieforespørsler mellom én og flere brukere. Av denne grunn, når en bruker er tilkoblet og dermed et medlem av gruppen, håndteres mediaforespørsler automatisk, transparent for brukeren og krever bare en enkelt brukermedvirkning i stedet for flere trinn som vanligvis er nødvendig. Formålet med visning og deling av medier er å formidle erfaringer med andre. Visning og deling av medier gir formidling av denne erfaringen mellom flere mennesker, og resulterer ofte i at brukerne løser en oppgave som et samarbeidsprosjekt. [1] Det resulterende samarbeidet mellom samlokaliserte brukere resulterer i foto-snakk, der bilder brukes som triggere for historiefortelling, mimring og å starte diskusjoner i gruppen. Selv om dette er svært ønskelig, er det veldig tungvint og problematisk å oppnå med en mobil enhet. Vanligvis er erfaringen formidlet til alle, enten ved at alle samler seg rundt en enkel mobil enhet, eller at apparatet blir passert rundt i gruppen. Selv om dette tilfredsstiller kravet til deling, kan man argumentere for at denne opplevelsen ikke er utnyttet til sitt fulle potensial. Opplevelsen er en distribuert natur og ikke forbrukes av alle samtidig. På samme måte er tanken bak denne applikasjonen at brukerne kan dele erfaringer og minner fra Grenserittet ved å gjøre de tilgjengelig for alle brukere som ønsker å være med å dele. 2.4 Design HCI Generelt om HCI-paradigmene Første HCI- Paradigmet (Harrison et. Al) er en blanding av tekniske og menneskelige faktorer. Interaksjon kan sees på som en form for menneske-maskin coupling på måter inspirert av industri og ergonomi. Målet for arbeidet i dette paradigmet, er å optimalisere tilpasningen mellom mennesker og maskiner,

12 spørsmål som vil bli svarte fokus på å identifisere problemer i kopling og utvikle pragmatiske løsninger på dem. HF: Human Factors. Andre HCI-Paradigmet er organisert rundt en sentral metafor om sinn og datamaskinen som symmetriske informasjonsprosessorer. Hvordan kommer informasjonen inn i systemet, hvilke transformasjoner gjennomgår den, hvordan går det ut igjen, hvordan kan det kommuniseres effektivt osv. Hva føler folk om interaksjon, plassen til en bestemt interaksjon i større systemer for bruk, unnvikende og gåtefulle sider ved hverdagen som for eksempel "hva er morsomt?". Ett av temaene som ligger bak det 3. paradigmet er fokus på legemliggjort samspill. I menneskelige faktorer er oppmerksomhet til slike faktorer som tilpassningen av en mus til den menneskelige hånd eller hvordan enkelte fontstørrelser kan være lettere å lese. Kognitivt basert arbeid i HCI har lagt ut fysiske begrensninger som praktisk informerer interfacedesignet om ting som for eksempel hastigheten som mennesker er i stand til å reagere i ulike situasjoner. 3. paradigmet er basert på en annen, sentral holdningstegning på fenomenologi: at måten som vi kommer til å forstå verden, oss selv, og samspill avgjørende stammer fra beliggenheten vår på en fysisk og sosiale verden som er nedfelt aktører. Fokusering på legemliggjort samspill endrer vesentlig hva vi tar som sentralt for interaksjon. Et fokus på legemliggjort samspill flyttes fra 2. paradigmeideen om at tenkning er kognitivt, abstrakt og informasjon basert på en tenkning der er også oppnådd gjennom å gjøre ting i verden, for eksempel uttrykket gjennom bevegelser, læring gjennom manipulasjon, eller tenke gjennom bygging av prototyper. Det tyder på at vår grafiske grensesnitt legger for lite vekt på differensielle evner ved menneskekroppen, overfremheve å se, høre og motorisk kontroll over hendene våre, samtidig som det under-støtte andre sanser og våre fysiske ferdigheter som handlingssentrerte ferdigheter og motorisk minne. Kort kan man si at det første paradigmet har som mål å optimalisere (ergonomi) match mellom menneske og maskin. Den andre tar på seg en mer teoretisk tilnærming og vurderer hva som skjer i det menneskelige sinn når datamaskinen blir brukt. Det fokuserer på hvordan brukeren samhandler og kommuniserer med datamaskin. Det tredje paradigmet, skifter oppmerksomheten til en mer sosial tilnærming, prøver å drøfte hvordan design kan brukes i en sosial setting, i en virkelig fysisk verden, og i hvilken grad er brukeren fornøyd når du bruker det HCI for Freporter Freeporter vil i hovedsak basere seg på input via at brukeren bruker tastene på telefonen, men også brukerens posisjon som brukes til å geo-tagge dataene som blir lastet opp. Applikasjonen vil i liten grad være basert på haptisk input fra brukeren, da posisjonen til brukeren er relevant kun når brukeren skal laste opp data, og dette er å anse som tilleggsinformasjon i tillegg til de data som brukeren laster opp.

13 Applikasjonen vil også, sånn jeg anser det, ha lite å tjene på å bruke mye lyder og vibrering som output til brukeren. Dette vil kun ville virke rotete og forstyrrende for brukeren. Slik jeg ser det er det heller ingen deler av systemet som vil kunne bruke dette for at brukeren skal få mer ut av bruken av applikasjonen. Den visuelle delen av applikasjonen som output til brukeren er derfor veldig viktig. Det er flere aspekter ved den visuelle delen av applikasjonen som bør vurderes. Jeg har valgt å bruke begreper beskrevet av Steven Heim i boka The Resonant Interface HCI foundations for interaction design (2008). Simplicity og Predictability Jeg vil forsøke å lage et system basert på enkelhet og forutsigbarhet. Simplicity - Simplicity eller enkelhet er et høynivåsprinsipp som baserer seg på at når ting er enkle vil de være enkle og forstå fordi de vil være enkle å lære og huske. Det betyr ikke at man skal forenkle designet, men at man skal forsøke å gjøre komplekse ting på en enkel måte. Med et design basert på en helhet vil det være enklere å forutse funksjonalitet noe som vil føre til økt effektivitet, bedre brukervennlighet og bedre lesbarhet. Under simplicity finnes andre prinsipper som jeg har valgt å bruke i mitt design. Et av disse er progressive disclosure hvor man bare viser brukeren det som er nødvendig på gitt tidspunkt. Eksempler på dette kan være at hver av delene fra hovedmenyen venstre har hver sin undermeny, og at valgene i denne undermenyen igjen har hver sine undermenyer. Et annet prinsipp jeg vil bruke er constraints. Dette begrenser funksjonaliteten i designet. Igjen er menyene et eksempel, de vil forandre seg etter som hvilken del av systemet man er i. Dette er en barriere som fysisk begrenser bevegelse til passende deler av funksjonaliteten i designet. Jeg vil også vurdere bruken av psykiske begrensinger i et design, dette påvirker måten brukeren ser systemet og de forskjellige elementene i systemet. Dette er en psychological constrain basert på conventions. Predicability - Jeg vil også forsøke å benytte meg av uttrykket predictability eller forutsigbarhet i når jeg utvikler mitt design. Dette baserer seg på forventninger og evnen til å avgjøre hva som kommer til og skje. Her baserer man seg på tidligere erfaringer og hva man husker fra dette. Forutsigbarhet gir en følelse av trygghet som er viktig i alle typer design. Dette øker produktiviteten og brukervennligheten fordi brukeren også føler seg trygg nok til å utforske ukjente deler av systemet. Prinsipper som fører til forutsigbarhet er consistency and correctness. Eksempler på dette kan være konsekvent bruk av farger, ikoner, plassering av knapper og funksjonalitet. Jeg vil for eksempel kunne bruke en konsekvent fargekombinasjon som går igjen gjennom hele designet. (Steven Heim (2008), s )

14 Heuristikker I samarbeid med Rolf Molich har Jakob Nielsen utviklet ett sett med 10 heuristikker for interfacedesign. Disse blir kalt heuristikker fordi de ligner tommelfingerregler fremfor å være et sett med retningslinjer innen brukergrensesnitt. Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Systemet vil kontinuerlig gi brukeren tilbakemelding om hva som skjer. For eksempel dersom brukeren vil laste opp et bilde til systemet, vil han/hun få beskjed på skjermen at det lastes data til tjeneren, helt til bildet er ferdig lastet og en ny infoboks vil komme opp som forteller hvorvidt opplastingen var vellykket. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. Gjennom hele systemet er det forsøkt å bruke ord og uttrykk som er kjent for brukeren som vil ha en noe erfaring med å arbeide med media-applikasjoner og sosiale samfunn som for eksempel facebook. Det vil i første omgang kunne være fordelaktig å lage systemet med engelske ord og uttrykk for at det skulle kunne brukes av et internasjonalt publikum. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Systemet vil ikke ha implementert noen undo-knapp som vil slette siste opplastede data fra tjeneren. Brukeren vil derimot kunne velge å avbryte opplastningen som evt. er satt i gang, ved å velge Cancel. Da brukere av systemet mest sannsynlig kommer til å benytte seg av mobilnettet, og med mindre brukeren har et spesialabonnement, vil dette koste penger for brukeren pr nedlastede MB. Det er derfor naturlig å implementere en Cancel-funksjonalitet for all visning av data mens det lastes. Skriving av rapporter vil basere seg på SMS-funksjonaliteten som allerede ligger på telefonen, og har derfor slette-funksjonalitet osv implementer fra før av. På samme måte vil lydopptak, bildetagning og videoopptak være basert på mikrofon og kamerasoftware som allerede ligger på telefonen. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Ordene og uttrykkene som brukes vil bli valgt for å prøve å forhindre forvirring hos brukeren. Jeg vil også forsøke å bruke uttrykk som kan relatere til systemer som brukerne kan ha erfaring med fra før av, samtidig som at det er et uttrykk som godt forklarer hva det innebærer.

15 Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate errorprone conditions or check for them and present users with a confirmation option before they commit to the action. Mulige feil som kan oppstå ved dette systemet er for eksempel feil med tilkobling til serveren. Dette kan komme av problemer på telefonen som enhet, for eksempel at den er utenfor nettdekning, eller at serveren i seg selv er nede. Dersom slike problemer oppstår er det fornuftig at brukeren får beskjed om problemene for eksempel via en dialogboks som forteller han/hun at telefonen er uten nettdekning, og at evt. opp-/nedlastning vil bli mislykket. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. De ord, uttrykk og menyer som lages vil bli forsøkt strukturert på en slik måte at det skal være logisk for brukeren å finne frem til ønskede data, i tillegg til at det skal være logisk for brukeren å skjønne hva han/hun finner på de ulike stedene og under de ulike menyene. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Dette er ikke spesielt vektlagt i dette systemet da applikasjonen på telefonen forhåpentligvis vil bli nokså liten og enkel at det ikke blir behov for dette. Hvis det derimot viser seg at noe funksjonalitet blir naturlig hyppigere brukt, kan det være en mulighet å legge inn hurtigtaster for disse for eksempel ved nummertastene, slik at de brukerne som bruker systemet en del så enkelt som mulig. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Minimalistisk design er noe vil bli lagt stor vekt på ved dette interaksjonsdesignet, da et innviklet design vil fremstå som rotete og vanskelig for brukeren å skjønne seg på, ikke minst fordi skjermen på telefonene i bruk vil være nokså begrensede i størrelse. Tanken er også at et minimalistisk design med få knapper og ikoner å forholde seg til om gangen, vil senke terskelen for brukeren. Verken dialogboker eller menyer vil være overlesset med informasjon til brukeren. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

16 Alle feilmeldinger som systemet skal kunne komme med, skal ha fornuftige meldinger til brukeren, og være basert på naturlig språk slik at ikke brukeren skal behøve å ha erfaring med systemet for å forstå hva meldingene betyr. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. Det vil kunne være naturlig om systemet vil ha en type Hjelp-valg i menyene som vil kunne gi brukeren en funksjonsoversikt over alle funksjoner på gitt del av systemet. Rekruttering og involvere brukere For at Freporter skal være en applikasjon som er verdt for brukerne å bruke tid på, er den helt avhengig av at det er flere brukere som benytter den. Mulige brukere av systemet er som nevnt tidligere er amatører og privatpersoner som følger løpet for moro skyld. For å begrense målgruppen har jeg valgt å fokusere brukere som er å anse som amatører, det vil si brukere som er ute etter å dele og se data om Grenserittet, kun for moro skyld, og i utgangspunktet for privat bruk. På den måten er det ikke like viktig med dataenes integritet. Det vil derfor heller ikke være like viktig med å screening av dataene som kommer inn for å sikre at dataene som blir lagret er helt riktige, og at ikke samme data blir logget mange ganger. Applikasjonen er nokså basert på at det er mange brukere av systemet, for å samle nok data til at applikasjonen er interessant å benytte. For å rekruttere brukere kan man i første omgang benytte seg av populære nettsamfunn som Facebook. Der finnes det flere grupper og sider som vil kunne nå potensielle brukere av systemet. Dette er grupper som for eksempel den rasktvoksende gruppen Halden i form 2010, arrangementsiden og gruppen Grenserittet. Facebookbrukere som har registrert seg som Attending på arrangementsiden til Grenserittet på Facebook, er i like stor grad folk som har tenkt til å være tilskuer, bidra og hjelpe til rundt løpet, og generelt være i området når rittet foregår, som det er folk som faktisk har tenkt til å sykle løpet. Dette er derfor et ideelt sted å lufte ideen rundt applikasjonen og eventuelt rekruttere brukere. I tillegg vil det være fornuftig å dele ut brosjyrer og lignende i forkant av løpet og ved poster langs løpet på selve løpsdagen. For å nå en enda større brukergruppe, kan man også gjøre tiltak som å reklamere for og informere om systemet i aviser og på nettsider. Fordelen med å reklamere ved medier som nettsamfunnet Facebook, er at man treffer direkte på den målgruppen man er ute etter, da man kan bruke grupper som nevnt over som Facebook-brukere selv har registrert seg under. På den måten

17 når man brukere som både har noen interesse for informasjonsteknologi, og arrangementet i seg selv. For å nå den rette målgruppen kan for eksempel spinningtimene på Spenst Halden og Family Sports Club være et godt sted å starte utspørring og lokalisering av eventuelle brukere. Her kan man også nå brukere direkte og ikke igjennom et medie slik som om man bruker Facebook eller lignende. Dette gjør at man kan få et med ærlig og direkte tilbakemeldinger fra de eventuelle brukerne i tillegg til at man kan fronte applikasjonen bedre ved at man bedre knytter et fjes til promoteringen. Når applikasjonen lanseres første gangen, vil det være liten grunn til å screene og gjøre mye arbeid ut av å godkjenne brukere av systemet. Det vil da i hovedsak dreie seg om å rekruttere flest mulig for å få mest mulig brukere og data inn i systemet. Målet med denne applikasjonen er ikke å opprette et nytt fellesskap, men å heller støtte et allerede eksisterende fellesskap med data og et hjelpemiddel for å dele disse dataene. Et mål må derfor være å sikte seg inn på å nå dette fellesskapet som allerede eksisterer. Dette fellesskapet består av sykkel- og trimentusiaster i Halden og omegn i hovedsak. Det vil derfor være naturlig å ta sikte på å rekruttere brukere ved å ta kontakt med Halden Cyckleklubb og Halden Skiklubb, som også er blant arrangørene til løpet. På den måten kan man nå kjernen blant de som virkelig brenner for rittet og alt det sosiale rundt løpet. Man treffer også de som står for alt det sosiale rundt løpet, som er nettopp det Freporter skal være med å bidra til. Da man ved denne applikasjonen, som nevnt tidligere ikke skal laget ett nytt fellesskap, men heller bidra til et fellesskap som allerede eksisterer, er det viktig å gjøre en del research på selve brukergruppen. Det vil derfor være naturlig å spørre litt rundt omkring i de kretsene som eventuelt skal benytte seg av applikasjonen, om dette er en applikasjon de i det hele tatt ser nytten av å bruke, og om de har noe innspill og forventninger til hvordan en slik applikasjon skal være. Samarbeidsaspekter En mobil er ikke begrenset til "et program" på mobilen. Et program er ganske komplett infrastruktur med ofte ferdiglagde komponenter som støtter spesifikke aktiviteter som for eksempel fotografering, lyd- og videoopptak, opplasting av data, surfing osv. Computer supported cooperative work (CSCW) kan sees på som et paradigmeskifte, hvor fokuset ligger på det sosiale og praksis i design av systemer. CSCW innebærer ikke nødvendigvis et felles mål, men heller situasjoner rundt større grupper.

18 Samarbeid kan beskrives som en prosess for interaksjon mellom mennesker. Samarbeid kan tolkes på mange måter. Det kan være synkront, altså mellom mennesker tilgjengelig på samme tid som for eksempel chat. Samarbeidet kan også foregå asynkront, der partene ikke behøver å være tilstede samtidig, som for eksempel e-post. Samarbeid kan også være lagt opp som ad hoc eller strukturert. Strukturert samarbeid kan beskrives som en prosess som er godt forstått og kan forutsies i stor grad, som for eksempel opprettelse av månedlige rapporter i et selskap. Ad hoc-samarbeid ikke kan forutses, verken ved frekvens eller innhold. Et eksempel på dette er e-post. [5] Samarbeidsaspektet rundt denne applikasjonen ligger ved at brukerne samarbeider om å dekke arrangementet. Dette samarbeidet skjer allikevel på en slik måte at brukerne ikke verken på forhånd eller underveis kommuniserer til hverandre direkte om hvilke deler av arrangementet som er dekket. Den kan altså defineres som asynkront samarbeid, som ikke er administrert på noen måte. Dette er også et samarbeid som ikke nødvendigvis trenger å være administrert, da dataene i første omgang kun skal brukes av privatpersoner for moro skyld. Administreringen det i så fall ville ha vært naturlig å implementere noen form for funksjonalitet som sørget for at alle brukere av applikasjonen er fordelt jevnt rundt på løypen, slik at alle delene av løpet blir dekket. Utover dette ligger samarbeidsaspektet ved applikasjonen ved at brukerne samarbeider om å samle inn og dele data seg i mellom. Dette kan på mange måte sammenlignes med konseptet rundt Wikipedia som er et produktiv, fellesskapsforfattet online oppslagsverk. Wikipedia er opprettet rundt et nokså uventet scenario i verden rundt informasjonsteknologi, nemlig at enkeltpersoner rundt om i verden samarbeider, uoppfordret, til bidra med sine kunnskaper og og på eget initiativ dele denne kunnskapen for å skape en informasjon ressurs som har høy kvalitet og er fritt tilgjengelig. Det er i ikke intuitivt at en slik ressurs, som er skrevet av komiteen, der anonyme bidrag er akseptable, og hvem som helst hvor som helst kan redigere alt innhold til enhver tid, kunne være nøyaktig etter enhver standard. Men dette er nettopp hva som har skjedd på wikipedia.org. [6] Målet med hele Wikipedia-systemet, å bygge og dele kunnskap i leksikalsk form, forblir i hovedsak uendret over tid. Fagene i seg selv kan derimot endre seg. Brukere som bidrar med kunnskap til Wikipedia har flere karakteristikker som kan endres over tid, herunder individuell motivasjon, mål og oppfatninger av selvtillit. Brukere som er nybegynnere med å delta i Wikipedia, er målet ofte informasjonsinnsamling, altså bruke det som et oppslagsverk. I forbifarten, identifisere de problemer og feil og retter disse. Første bidrag ut til kan springe tilfeldig fra brukernes personlige kunnskap, ofte relatert til domener som de føler seg komfortable og kompetent til å uttale seg om, for eksempel hobbyer og personlige interesser. For ekspertbrukere av Wikipedia, eller "wikipedianere" som de også kan kalles, er Wikipedia som helhet blitt viktigere enn noen enkelt artikkel eller et sett med artikler. Selv om de fortsetter å forbedre kvaliteten på innholdet i de enkelte artikler, synes deres

19 motivasjon å bli forankret i en bekymring for kvaliteten til Wikipedia i seg selv. I overgangen fra nybegynner til Wikipedianer, mål utvide til å omfatte voksende fellesskapet seg selv og forbedre den generelle kvaliteten og karakteren av området. Det er viktig at Wikipedia er offentlige, og at Wikipedianeres arbeid er tilgjengelig for alle. Mange Wikipedianere oppfatter deres arbeid som bidrar til et greater good, ved å gi kunnskap til verden. Wikipedias grensesnitt med søkefelt godt synlig, og linker igjennom hele artiklene, i tillegg til at Wikipedia-artikler ofte kommer opp som en av de første søkeresultatene ved bruk av for eksempel Google, gjør også at sidene er attraktive for bruk av alle. Videre har alle artikler en link øverst som tilbyr brukeren å redigere artikkelen. Dette gjør at terskelen for å bidra blir senket betraktelig. Alle disse aspektene rundt samarbeid om samling av data som jo det Wikipedia er, er av interesse til dette prosjektet. Det er allikevel viktig å se de klare forskjellene mellom Freporter og Wikipedia. Den klart største forskjellen er tidsperioden h systemet brukes. Wikipedia er bygget opp over lengre tid, og har ingen klar dato eller tidspunkt hvor systemet er ferdig. Det er derimot tilfellet ved Freporter hvor datainnsamlingen har et klart tidspunkt hvor det starter og er ferdig, altså innenfor perioden hvor løpet går. Som nevnt over vil fagene i seg selv som er beskrevet ved bruk av Wikipedia kunne endre seg. Dette vil ikke bli tilfelle for Freporter, mye på grunn av at faget som blir beskrevet er veldig konkret og innenfor en kort tidsperiode. Det er et klart samarbeidsaspekt rundt dette prosjektet, da hele opplevelsen av applikasjonen er basert på at brukerne samarbeider om å samle data om løpet. En av de viktigste aspektene ved dette prosjektet nettopp hvordan man skal rekruttere brukere, og ikke minst hvordan man skal få disse til å bidra til å samle data. Dette er nok den største utfordringen med hele applikasjonen. For å lokke brukere til å være med å på å bidra er det viktig å finne ut hva det er som får brukerne til å ville bidra med data. Det er viktig å kartlegge hva det er som får brukerne til å ville bruke tid og energi på dagen for løpet til å ta bilder, skrive rapporter osv. for å dele med andre brukere. Hva skal til for at brukerne skal gidde å laste opp data? Hvorfor skal brukerne gidde å være med? Som nevnt over er formålet med visning og deling av medier er å formidle erfaringer med andre. Visning og deling av medier gir formidling av denne erfaringen mellom flere mennesker, og resulterer ofte i at brukerne løser en oppgave som et samarbeidsprosjekt. På samme måte er tanken bak denne applikasjonen at brukerne kan dele erfaringer og minner fra Grenserittet ved å gjøre de tilgjengelig for alle brukere som ønsker å være med å dele. Spørsmålet er bare om dette i seg selv er nok. For å lokke brukere til å dele data kan det være aktuelt med en form for poengsystem, som gjør at det å bidra blir en konkurranse blant brukerne. Dette er noe som vil kunne gjøre at brukerne

20 Når jordskjelvet inntraff Haiti i Januar 2010, eksploderte det i mengden data om området på nettet. Dette skjedde over kort tid, men gjorde allikevel at det ble tilgjengelig mye mer data om området på internett. For å sammenligne dette fenomenet med arrangementet Grenserittet, er begge hendelsene begrenset i tidsperiode. Det er allikevel en betydelig større mengde mennesker som har interesse for naturkatastrofen, enn det er for de som har interesse for Grenserittet. Dette har klar innvirkning på mengden data som blir samlet. For å få brukerne til å bidra til datasamlingen er det viktig å skape noe for å friste brukerne. Det man kan vurdere da er et form for poengsystem med ratinger som igjen kan brukes på rabatter for beste poengsum, i for eksempel sportsbutikk-teltene som er lokalisert på festningen på dagen for arrangementet. Denne applikasjonen kan sammenlignes med fenomenet microblogging. En microblog er forskjellig fra en tradisjonell blogg i at dens innhold vanligvis er mye mindre. En oppføring i en microblog kan bestå av bare en kort setning eller et bilde, video eller lignende. Eksempler på tjenester på nettet som støtter microblogging er nettsamfunn som Twitter, Tumblr, Identi.ca og Facebook. Statusoppdatteringene på Facebook er å anse som microblogging. Det man da kan spørre seg er hvorfor velger brukere av disse tjenestene å bruke tid på dele informasjon for andre. Av egen erfaring er motivasjonen for deling av slik info på for eksempel Facebook, i like stor grad for brukerens egen skyld, som for de som evt. velger å lese det. Det er altså ikke nødvendigvis de andre brukernes nytte av dataene som deles som er motivasjonen, men i større grad gleden av å dele data med andre. Et viktig punkt i dette prosjektet er derfor å videre finne ut hva som skal til for at brukere vil dele data på denne måten, og hvorfor de velger å gjøre det. Dette er derfor grunnlaget for evalueringen av prototypen i prosjektet. Kontekst Kontekst defineres av Schilit og Theimer 1994 som sted, identiteten til nærliggende mennesker og gjenstander og endringer på disse objektene. [2] Stedet som er under fokus for dette prosjektet er løypen som er lagt opp for Grenserittet og ikke minst start- og stoppstedet for løpet, hvor det er mye aktivitet rundt dagen for arrangementet. Litt videre kan man si at stedet for bruk av denne applikasjonen er Halden og Strømstad by, som begge kommer til å være innvirket av arrangementet. Identiteten til de nærliggende mennesker rundt brukeren av applikasjonen vil man kunne gi en viss fellesnevner, i forhold til at alle mennesker rundt løpet har noe de samme intensjonene ved å være rundt rittet, i og med at de alle ønsker å få noen type

21 informasjon om det som skjer i selve rittet. Det er også naturlig at selve utøverne er en del av konteksten til denne applikasjonen da det faktisk er de dataene skal handle om. De faller både inn under mennesker og gjenstander og endringer på disse objektene. Kontekst eller sammenheng innebærer også brukerens følelsesmessige tilstand, fokus for oppmerksomheten, plassering og orientering, dato og klokkeslett, objekter og personer i brukerens miljø, i følge Dey, Dey hevder også at kontekst er enhver informasjon som kan brukes til å karakterisere situasjonen til en enhet. En enhet kan være en person, sted eller objekt som anses relevant for interaksjon mellom en bruker og en applikasjon, inkludert brukeren og programmene selv. [3] En vesentlig del av konteksten rundt bruk av applikasjonen på Grenserittet, er været. Været kan i stor grad spille inn på selve bruken av applikasjonen og HCI-et. Dette kan for eksempel være aspekter som at det kan være lettere å se hva som står på skjermen dersom det ikke er helt lyst ute, eller at dersom det (mot formodning siden det tross alt er i august) skulle være så kaldt at brukerne vil ha på seg hansker når applikasjonen brukes og vanskeligheter rundt dette. Dersom det skulle regne på dagen for arrangementet, vil dette også legge en demper på hvor mye brukerne velger å benytte applikasjonen, da de fleste mobiltelefoner ikke er veldig vannresistente. Rekruttering av brukere vil også da naturlig nok kunne bli noe vanskeligere dersom regnet pøser ned. Miniatyriserte sensorer og aktuatorer utvikles raskt, kommunikasjonsnett blir allestedsnærværende og standarder for trådløse nettverk er under etablering. Fremfor alt, teknologi og design bryter ned muren som historisk har skilt computing fra resten av livet. Man kan derfor si at mobiltelefoner løsner tilordningen mellom aktiviteter og steder. Mobiltelefoner aktualiser en primitiv modell av tilkoblingsmuligheter: brukere blir avbrutt og deretter tilkoblet synkront. Når alles forhold kan bli kontinuerlig tilstede, blir man hele tiden avhengig av delt oppmerksomhet. Delingen av aktiviteter og steder vil løses opp, og man kan si at alle steder vil være for alle ting til enhver tid. Vi trenger et konseptuelt rammeverk for å analysere dette fenomenet. For dagens fenomener er det tre nivåer som kan brukes: Arkitektur, praktisering og institusjoner.[4] Med arkitektur menes det konstruerte miljøet og ikke som man kanskje tror ut i fra begrepet, arkitekturen til datasystemet. Her fokuseres det på fiksede strukturer som for eksempel bygninger, vegger, dører osv. og alle andre fysiske objekter dersom de vanligvis er begrenset til et spesifikt sted. Arkitekturen som er innenfor omfanget av dette prosjektet er naturen og omgivelsene rundt løpet Grenserittet. Her er værforhold og alle andre aspekter som ikke er fikset irrelevant i følge rammeverket foreslått av Agre. Derimot er ting som salgstelt, boder og andre ting satt opp av arrangøren og interessenter rundt arrangementet innenfor dette omfanget. Det samme gjelder også selve løypa som er lagt opp for løperne. Indirekte vil alle disse aspektene spille inn på hvordan brukerne av applikasjonen bruker den, da det har

22 innvirkning på hvordan dagen for arrangementet forløper seg for brukerne. Omstendighetene rundt løpet gjør også at man går fra å være en udefinert person for denne settingen, til å bli tilskuer, løper, selger, funksjonær, teknikker eller lignende. Hvilken rolle brukeren har i sammenhengen vil kunne ha noe å si for dataene som han/hun bidrar med eller ønsker å bruke seg av. Med praktiseringer menes samlingen med innarbeidede rutiner som en spesifikk gruppe med mennesker har utviklet for å gjøre spesielle ting på et spesifikt sted. For dette prosjektet vil for eksempel enkel tilskueretikette spille inn for hvordan applikasjonen blir brukt. Institusjoner er de vedvarende strukturene i menneskelige forhold og samlingen med sosiale roller og regler som utgjør disse forholdene. Eksempel på slike institusjoner kan være et ekteskap, det norske språket, generelle normer osv. Som nevnt over, vil også måten man som person skifter rolle i det man entrer arrangementet til å bli for eksempel tilskuer, funksjonær eller lignende spille inn for hvordan man har muligheten til å dele data, og hvilke typer data brukeren kan være ute etter. En funksjonær kan for eksempel dele mer detaljrike og korrekte data om løpet enn det en enkel tilskuer kan gjøre. På en annen måte kan en enkel tilskuer ha mer tid og mulighet for å dele og laste ned data da han/hun ikke har like mange andre ting å forholde seg til rundt løpet. 2.5 Planlagt prototype Prototypen som er planlagt gjennomført i dette prosjektet vil være en semifunksjonell mock-up som har noe av den funksjonaliteten som er ønskelig for den endelige applikasjonen. Prototypen som skal utvikles i prosjektet skal ha funksjonalitet som støtter det som man ønsker å finne ut ved evalueringen. På den måten må man ta utgangspunkt i evalueringen når prototypen skal velges. Videre er det også viktig at det må være attraktivt å laste ned data også. Nedlastningsdelen vil i første omgang være beskrevet og ikke nødvendigvis implementert i prototypen. Denne delen av prototypen vil være en mock-up med skjermbilder som viser hvordan funksjonaliteten er ønsket ved den ferdige løsningen. Dette vil være bedre enn kun full funksjonalitet på opplastning. For å finne ut hva brukerne får ut av å dele er det viktig at denne delen av applikasjonen er en velfungerende mock-up, som forsøker å vise brukerne ved evalueringen, det som applikasjonen kan tilby. Poenget med denne prototypen er ikke såkalt proof of concept, da det er antatt at funksjonaliteten som denne applikasjonen skal tilby faktisk lar seg gjøre. Jeg ønsker i større grad å finne ut av brukernes erfaringer med å se dataene representert i et kart når de skal lastes ned, kontra i en liste eller lignende som for eksempel på flickr.