Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Lara – en skattjakt med mobil
datorförstärkt verklighet
Anton Hedström, Patrik Ragnarsson
Reg Nr: LIU-IDA/LITH-EX-A--11/021--SE Linköping 2011
Institutionen för datavetenskap Linköpings universitet
Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Lara – en skattjakt med mobil
datorförstärkt verklighet
Anton Hedström, Patrik Ragnarsson
Reg Nr: LIU-IDA/LITH-EX-A--11/021--SE Linköping 2011
Handledare: Mattias Arvola
ida, Linköpings universitet Lars Lundberg
Attentec AB
Examinator: Mattias Arvola
ida, Linköpings universitet
Institutionen för datavetenskap Linköpings universitet
Avdelning, Institution
Division, Department Human-Centered Systems
Department of Computer and Information Science Linköpings universitet
SE-581 83 Linköping, Sweden
Datum Date 2011-06-18 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-70313
ISBN
—
ISRN
LIU-IDA/LITH-EX-A--11/021--SE
Serietitel och serienummer
Title of series, numbering
ISSN
—
Titel
Title
Lara – en skattjakt med mobil datorförstärkt verklighet Lara – a mobile augmented reality treasure hunt
Författare
Author
Anton Hedström, Patrik Ragnarsson
Sammanfattning
Abstract
The performance of mobile phones have increased recently. Thus, it has become relevant with augmented reality in mobile applications. This work has examined how augmented reality is used in mobile applications to focus on a location. By using augmented reality you will be able to add information to a place. In order to apply augmented reality, we have developed Lara. Lara is a prototype of a game in the form of a virtual treasure hunt that takes place at Campus Valla in Linköping. The evolutionary prototype has been tested by four people who afterwards answered questions about usability. Results of the tests showed that the usability was good. The tests also showed that there is interest to expand Lara with both server and editor. The work showed that the presentation of augmented reality have significant impact on how real the experience becomes.
Nyckelord
Keywords augmented reality, förstärkt verklighet, android, system usability scale, använd-barhet
Abstract
The performance of mobile phones have increased recently. Thus, it has become relevant with augmented reality in mobile applications. This work has examined how augmented reality is used in mobile applications to focus on a location. By using augmented reality you will be able to add information to a place. In order to apply augmented reality, we have developed Lara. Lara is a prototype of a game in the form of a virtual treasure hunt that takes place at Campus Valla in Linköping. The evolutionary prototype has been tested by four people who afterwards answered questions about usability. Results of the tests showed that the usability was good. The tests also showed that there is interest to expand Lara with both server and editor. The work showed that the presentation of augmented reality have significant impact on how real the experience becomes.
Sammanfattning
Prestandan i dagens mobiltelefoner har ökat på senare tid. Därmed har det blivit aktuellt med förstärkt verklighet i mobilapplikationer. Det här arbetet har un-dersökt hur förstärkt verklighet används i mobilapplikationer för att framhäva en plats. Genom att använda förstärkt verklighet blir det möjligt att tillföra infor-mation till den verkliga platsen. I syfte att applicera förstärkt verklighet har vi utvecklat Lara. Lara är en prototyp av ett spel i form av en virtuell skattjakt som utspelar sig på Campus Valla i Linköping. Den evolutionära prototypen har tes-tats av fyra personer som efter testet svarat på frågor angående användbarheten. Resultatet från testerna visade att användbarheten var god. Testerna visade även att det finns intresse att utöka Lara med både server och editor. Arbetet visa-de att presentationen av förstärkt verklighet har stor betyvisa-delse för hur påtaglig upplevelsen blir.
Förord
Tack till Mattias Arvola vid Linköpings Universitet, Lars Lundberg, Joakim Wang-mar och övriga vid Attentec som hjälpt oss under arbetets gång, samt Jonathan Ronestjärna för opponering. Vi vill även tacka de personer som ställt upp och testat våra prototyper.
Innehåll
1 Introduktion 1 1.1 Problembeskrivning . . . 1 1.2 Fallbeskrivning . . . 2 1.3 Avgränsningar . . . 2 1.4 Metodval . . . 2 1.5 Struktur . . . 3 2 Litteraturöversikt 5 2.1 Förstärkt verklighet . . . 5 2.1.1 Bildigenkänning . . . 5 2.1.2 Definition . . . 6 2.1.3 Historia . . . 72.2 Spel med förstärkt verklighet . . . 8
2.2.1 Viking Ghost Hunt . . . 8
2.2.2 Find COPAN . . . 8 2.2.3 iButterfly . . . 8 2.3 Verklighetsbaserade spel . . . 9 2.3.1 Geocaching . . . 9 2.3.2 TittaVaJaHitta . . . 9 2.3.3 Turf . . . 10 3 Metod 11 3.1 Fallstudie . . . 11 3.2 Brainstorming . . . 12 3.3 Storyboarding . . . 13 3.4 Användbarhet . . . 13
3.4.1 System Usability Scale . . . 14
3.4.2 Användbarhetstest . . . 16 3.4.3 Pappersprototyp . . . 17 3.4.4 Evolutionär datorprototyp . . . 18 3.5 Utveckling . . . 19 3.5.1 Verktyg . . . 19 3.5.2 Utvecklingsmetodik . . . 19 ix
4 Resultat 23
4.1 Brainstorming . . . 23
4.2 Användningsfall . . . 25
4.3 Storyboarding . . . 26
4.3.1 Utvärdering av pappersprototyp . . . 34
4.4 Val av plattform för förstärkt verklighet . . . 36
4.4.1 QCAR . . . 37
4.5 Systembeskrivning . . . 38
4.5.1 Applikationens olika delar . . . 38
4.5.2 Designbeslut . . . 41
4.5.3 Utvärdering av evolutionär prototyp . . . 43
5 Diskussion 47 5.1 Framtida arbete . . . 47
5.1.1 Server . . . 47
5.1.2 Editor . . . 48
5.1.3 Andra förbättringar och utökningar . . . 48
5.2 Fallstudie . . . 49 5.3 Metodkritik . . . 49 5.3.1 Brainstorming . . . 50 5.3.2 Utvecklingsmetodik . . . 50 5.3.3 Användbarhetstester . . . 50 5.4 Jämförelser . . . 50 5.5 Slutsatser . . . 51 Litteraturförteckning 53
Kapitel 1
Introduktion
I detta kapitel beskrivs problemet samt föreslagen lösningsgång.
Förstärkt verklighet (mer känt som ”augmented reality”) handlar om att förstärka de sinnesintryck (så som visuella, auditiva och haptiska) som verkligheten ger oss. Förstärkt verklighet är ett område som växer tack vare att området tagit steget in på mobilmarknaden. [1] Ett steg som blivit aktuellt i och med att mobiltelefonerna har utvecklats kraftigt. Därmed har mobiltelefonerna blivit mer kapabla att ut-föra de uppgifter som krävs för att uppnå godtagbar nivå av förstärkt verklighet. Uppgifter som tidigare inte var möjliga eller tog för lång tid att utföra.
Utvecklingen av mobiltelefonerna har inneburit ökad beräkningskapacitet i och med snabbare processorer. Större skärmar med bättre ljusstyrka, kontrast och fär-ger har gjort mobiltelefonerna lättare att använda i olika situationer, till exempel utomhus. Att telefonerna utrustats med ytterligare hårdvara som GPS, accelero-meter och gyroskop har öppnat upp för nya tillämpningar. En annan viktig kom-ponent som förbättrats är kameran, eftersom förstärkt verklighet handlar om att mixa den verkliga världen med ett virtuellt lager. I och med att dessa verktyg finns till hands ges möjligheter att skapa applikationer med förstärkt verklighet till mobiltelefoner.
En annan typ av mobilapplikation som på senare tid fått ett stort genomslag är mobilapplikationer där användaren talar om vilken plats han eller hon befinner sig på. I detta arbete presenteras resultatet av en undersökning huruvida det går att kombinera förstärkt verklighet med den plats användaren befinner sig på.
1.1
Problembeskrivning
Det finns många platser som är betydelsefulla för många personer. Det kan till exempel vara en stadsdel, ett universitetscampus, en företagspark eller ett museum. Platser som betyder något speciellt för besökaren. En anledningen till att lyfta
fram en viss plats är marknadsföring. Städer, universitet och museum har alla anledningar till att marknadsföra sin verksamhet.
Frågor som detta arbete försöker besvara är
• hur kan en mobilapplikation med förstärkt verklighet lyfta fram en viss plats? • hur användbar är den resulterande mobilapplikationen?
1.2
Fallbeskrivning
Arbetet har bedrivits som en fallstudie. Den plats som valts för fallstudien är Linköpings universitets (LiU) ena campus, Campus Valla. Olika representanter från LiU agerade kund i projektet. Det är en plats som besöks av många olika människor dagligen och betyder mycket för många.
LiU är, likt andra universitet, beroende av att det finns studenter som väljer att utbilda sig hos dem. För att uppnå detta behövs ständigt innovativa metoder att marknadsföra sig på. Det finns med andra ord ett stort incitament till att ha en mobilapplikation som kan lyfta fram universitetet och dess plats. För att vara mer specifik finns det många olika delar vid Campus Valla att presentera, bland annat utbildning, forskning och historia. I fallstudien har arbetet koncentrerats på att visa upp olika delar av Campus Valla. Applikationen som utvecklats kan till exempel användas i samband med nollningsperioderna för nya studenter.
1.3
Avgränsningar
Under arbetets gång har en prototyp utvecklats. Denna prototyp har utvecklats för Android-plattformen och har testats på Android 2.2. Under utvecklingen av prototypen har en telefon av modellen HTC Desire använts. Prototypen har inte testats noggrant på någon annan modell.
Utveckling av funktioner för bildigenkänning ansågs ligga utanför arbetets ramar. Istället har ett befintligt mjukvarubibliotek använts för det ändamålet. Det existe-rar ett antal olika bibliotek för bildigenkänning till mobiltelefoner. Flera av dem är kommersiella och kostar pengar att använda. Det fanns inte möjlighet att lägga pengar på licenser och på grund av det begränsades valmöjligheterna.
1.4
Metodval
Projektet inleddes med en litteraturstudie inom områdena verklighetsbaserade spel och förstärkt verklighet för att få en djupare förståelse för problemområdet. Efter litteraturstudien följde sessioner av brainstorming för att få fram idéer till olika lösningar. Storyboarding är en metod för att ta fram en samling skisser av till
1.5 Struktur 3
exempel ett systemet. Storyboarding tillämpades efter brainstormingen för att tidigt få en bild av hur applikationen skulle se ut och fungera.
Storyboarding var även en bra metod för att tidigt ta fram en pappersprototyp som användes till tidiga användbarhetstester. För att testa idén på riktigt i den verkliga världen utvecklades en evolutionär prototyp av applikationen. Under utvecklings-tiden användes en agil programutvecklingsmetodik för att strukturera upp arbetet. För att utvärdera den evolutionära prototypen utfördes användbarhetstester.
1.5
Struktur
Kapitel 1 är detta inledande kapitel som introducerar problemet. Det
beskri-ver även kort metoderna som använts, vilka avgränsningar som gjorts och rapportens upplägg.
Kapitel 2 förklarar grundläggande termer samt redogör för aktuellt arbete inom
området.
Kapitel 3 går igenom de metoder som använts under arbetets gång. Kapitel 4 presenterar resultaten av de använda metoderna.
Kapitel 5 utvärderar arbetssättet, beskriver föreslagna förbättringar och
Kapitel 2
Litteraturöversikt
Detta kapitel avser ge en övergripande bild av vad förstärkt verklighet är i form av en definition, några användbara tekniker, lite historia och till slut några tillämp-ningar. Kapitlet handlar även om ett antal spel som är verklighetsbaserade, det vill säga spel som utspelar sig ute i verkligheten.
2.1
Förstärkt verklighet
Förstärkt verklighet är ett område som det forskats på i flera år. Det handlar om att förstärka de sinnesintryck (så som visuella, auditiva och haptiska) som verkligheten ger oss. Det mest aktuella området inom förstärkt verklighet handlar om de visuella intrycken och det är även inom det området som denna uppsats har sin domän. Genom att lägga in virtuella inslag i den verkliga världen på ett sådant vis att det virtuella upplevs vara en del av den riktiga världen vill förstärkt verklighet uppnås. [2]
För att genomföra visuell förstärkt verklighet finns det tre viktiga tekniker att fo-kusera på: spårning, registrering och presentation. Spårning används av systemet för att identifiera var den virtuella informationen ska presenteras. Registrering är resultatet av spårningen och beskriver hur den virtuella informationen ska presen-teras. Presentationen är den del som handlar om vad som presenteras och blir den förstärkande faktorn. [2]
2.1.1
Bildigenkänning
För att i realtid utföra spårning och registrering av ett fördefinerat objekt kan bildigenkänning användas. För att utföra visuell spårning finns i dagsläget huvud-sakligen två metoder: spårning med och utan markörer (se figur 2.1 för exempel
på markörer). Fallet med markörer är det enklare av dem då det är lättare att hitta bra referenspunkter i en bild med höga kontraster och skarpa vinklar.
Bildigenkänning handlar om att känna igen ett objekt, till exempel en skylt eller en fasad, som har fotograferats vid ett tidigare tillfälle. När objektet har hittats ges möjlighet att identifiera dess position och orientering i förhållande till den enhet som tar emot den visuella informationen.
(a) Vanlig markör. (b) QR-kod.
Figur 2.1: Exempel på markörer.
Det finns ett specialfall av markörer som kallas ”QR-koder” [3] (där QR står för ”Quick Response”), se figur 2.1b. Dessa används för att bädda in data, till exempel en URL, i en bild. Dessa bilder är uppbyggda på ett speciellt sätt enligt en standard. Med hjälp av kameran och en avsedd applikation kan nästan alla smartphones läsa QR-koder och på så vis underlätta inmatningen av data för användaren. Med hjälp av verktyg som finns fritt tillgängliga är det lätt att skapa egna QR-koder.
2.1.2
Definition
Definitionen på vad som är förstärkt verklighet är ganska lös men innehåller ändå tre ”krav” [4] som behöver uppfyllas:
1. Den verkliga världen ska kombineras med den virtuella. Det kan jämföras med ”virtuell verklighet” (”virtual reality”) där hela världen är virtuell. För-stärkt verklighet består av att infoga virtuella inslag i den verkliga världen.
2. Att förstärkt verklighet sker i realtid. Det handlar inte om en inspelad video där 3D-modeller har placerats ut i efterhand.
3. Att de virtuella objekten registreras i en 3D-värld, det vill säga, smälta in i den verkliga världen på ett naturligt sätt. Objekten behöver inte nödvändigt-vis vara i 3D. Ett exempel är sport på TV där, säg offside-linjen i fotboll, ritas ovanpå den vanliga bilden för att tydligt visa huruvida spelaren är offside eller inte när passningen slås.
2.1 Förstärkt verklighet 7
2.1.3
Historia
I flera år har förstärkt verklighet varit starkt förknippat med så kallade ”head-mounted displays” (HMD). HMD består av en slags hjälm med glasögon som användaren kan titta igenom och se verkligheten med virtuella inslag. Detta kan göras på två sätt, med video eller optik. Används video har hjälmen en kamera som filmar och visar verkligheten i glasögonen och de virtuella inslagen läggs ovanpå videon. I det optiska fallet är glasögonen genomskinliga och de virtuella elementen projiceras på glasen. [4]
Det finns även något som kallas för ”head-up displays” (HUD), vilka fungerar på liknande vis som HMD men är inte monterad på huvudet. HUD har länge använts i stridsflygplan och på senare tid även i bilar för att visa information för piloten respektive föraren. [4]
System bestående av HMD har varit ganska klumpiga att använda och dyra att framställa, eftersom de förutom själva hjälmen med glasögonen även kräver en dator där en applikation körs. [4]
Dock har de inom vissa branscher så som försvar, medicin och konstruktion ändå kommit till nytta. 1990 började flygplanstillverkaren Boeing experimentera med att elektroniskt lagra ritningar på elektroniksystem i flygplan. Istället för att som tidigare arbeta traditionellt med pappersritningar användes HMD för att se rit-ningarna under arbetet. Det sägs att termen ”förstärkt verklighet” myntades under detta arbete hos Boeing. [4]
Inom spelbranschen har förstärkt verklighet med HMD inte fått någon större fram-gång. Olika forskningsprojekt har bedrivits inom området, där ett av de mest kända är ARQuake. Projektet gick ut på att kunna spela Quake utomhus i den verkliga världen. Spelet fungerade, men det var inte särskilt praktiskt att spela det. Förutom att hålla i vapnet (en videospelpistol) behövde spelaren ha på sig en HMD och en ryggsäck med en bärbar dator och GPS-mottagare i. [5]
(a) Utrustning som krävdes. (b) Skärmdump från spelet.
Figur 2.2: Bilder på ARQuake. Används med tillstånd av Wearable Computer Lab, University of South Australia.
2.2
Spel med förstärkt verklighet
Det finns ett flertal spel som använder förstärkt verklighet. Spelen har fått en ny dimension genom att på olika vis använda verkligheten som spelplan. Nedan följer ett antal exempel på spel som använder sig av förstärkt verklighet.
2.2.1
Viking Ghost Hunt
Viking Ghost Hunt (VGH) är ett platsbaserat mobilspel som utspelar sig på en historisk betydelsefull plats (Old Viking City) i Dublin. Spelet togs fram som en prototyp för att undersöka spelarnas engagemang och inlevelse i ett sådant platsbaserat spel. Spelaren tilldelas rollen som en utredare som ska undersöka om det finns paranormal aktivitet i området. Aktiviteterna presenteras med hjälp av förstärkt verklighet i form av ljud och bild. Spelet består av att leta bevis, jaga spöken och lösa olika mysterier som uppstår. [6]
Deras undersökning visade att de flesta spelarna upplevde att de var engagerade i spelet och att det var en rolig tidsfördrivande upplevelse. Många upplevde ett allt större engagemang allt eftersom de vande sig vid gränssnittet. [6]
2.2.2
Find COPAN
Find COPAN är ett spel som använder förstärkt verklighet via tekniken Layar (beskrivs mer i 4.4 på sidan 36). Spelet är en skattjakt som utspelade sig under en vecka i slutet av 2010 i Dublin. Varje kväll dök det upp en ny virtuell skatt på en angiven plats i staden. Genom att vara bland de första att besöka platsen vanns ett pris. Genom att hitta skatten och utföra olika uppdrag, till exempel att lösa en gåta eller skanna en QR-kod, kunde användarna samla poäng. Tidigare varje dag släpptes en ledtråd via en radiokanal som gjorde att användarna kunde lista ut vilken plats skatten skulle dyka upp på och på så vis vara först på plats. [7] Innan spelet började sattes affischer med QR-koder upp runt om i staden, något som antagligen bidrog till att fler blev intresserade av spelet redan innan det hade börjat.
Find COPAN togs fram i marknadsföringssyfte inför invigningen av ett kafé med namnet COPAN. [8]
2.2.3
iButterfly
Ett annat exempel på marknadsföring med förstärkt verklighet är iButterfly som lanserades i Japan under 2010. Applikationen går ut på att spelaren ska fånga fjärilar med sin iPhone. När spelaren har iButterfly igång på telefonen och tittar sig omkring (riktar telefonen i olika riktningar (upp, ned, åt sidorna)) finns det chans att få syn på en fjäril. Om spelaren får syn på en virtuell fjäril kan hon
2.3 Verklighetsbaserade spel 9
välja att fånga den genom att göra en håvliknande rörelse med telefonen. Fångade fjärilar kan sedan bytas med andra spelare eller användas som rabattkuponger i olika butiker. [9]
2.3
Verklighetsbaserade spel
Verklighetsbaserade spel är spel som utövas med verkligheten som utgångspunkt till skillnad från brädspel som i regel använder sig av någon typ av medföljande spelplan. Verklighetsbaserade spel använder sig av verkligheten som spelplan. Det handlar alltså inte om en spelidé som är baserad på verkligheten utan att själva spelet är det. En konsekvens av detta blir en aktivare utövare som ofta förväntas förflytta sig i den verkliga världen för att göra framsteg. Det är inte ett spel som spelas fem minuter åt gången. Efter detta stycke följer ett antal exempel på verklighetsbaserade spel.
2.3.1
Geocaching
Geocaching [10] är ett koncept som liknar en traditionell skattjakt till stora delar. Den största skillnaden är att utövaren inte behöver någon traditionell karta för att hitta skatter. Istället offentliggör skattjaktsskaparen GPS-koordinaterna till den plats där skatten är gömd. Offentliggörandet sker ofta genom en webbplats där andra utövare kan gå in och ladda hem GPS-koordinaterna för att sedan ge sig ut i verkligheten och leta efter skatten. Skatten består av en behållare som är gömd på ett sådant vis att den är svår att råka stöta på för en person som inte letar efter den. Behållaren innehåller en loggbok som besökaren förväntas skriva i. Vissa skatter innehåller även små saker vilka är tillåtna att ta med sig om något lämnas i utbyte.
Geocaching startade i maj 2000 i USA av en person som heter Dave Ullmer. Han placerade ut en behållare med en loggbok och ett antal saker. Sedan skrev han på en diskussionsgrupp på Internet om vart han hade gömt lådan. Efter det växte geocaching snabbt och antalet utövare blev fler och fler. På geocaching.se (http: //www.geocaching.se) registrerades den första skatten i augusti 2000. Året efter hade 898 stycken registrerat att de hade hittat en skatt. År 2010 var motsvarande siffra 975 292.
2.3.2
TittaVaJaHitta
TittaVaJaHitta [11] är ett spel där användarna själva gömmer egna pengar (i vissa fall pengar från sponsorer) ute i verkligheten, likt geocaching. En spelledare publicerar ledtrådar på spelets webbplats som andra utövare kan gå in och läsa. Utövarna tävlar sedan om att hitta den plats där pengarna är gömda och åka dit och ta pengarna (i regel runt en hundralapp).
2.3.3
Turf
Turf [12] är ett svenskt lokalbaserat spel utvecklat för Android. Det bygger på användarens GPS-position och går ut på att användaren ska ta sig till olika zoner i verkligheten som är registrerade i spelet. Zonerna visas på en karta i spelet. Om en användare ställer sig i en sådan zon i ca 30 sekunder ”äger” användaren den zonen och får poäng varje timme (fram tills dess att någon annan tar över zonen). Användaren erhåller även en summa poäng vid det tillfälle då han eller hon tar över en zon. Antalet poäng som erhålls är olika för olika zoner. En zon som ligger centralt placerad ger i regel mer poäng att äga eftersom det finns många potentiella användare som kan ta över en sådan zon.
Spelet spelas i omgångar som i regel sträcker sig över en månad och den som har flest poäng vid slutet av omgången vinner ett pris. I mars 2011 fanns det totalt nästan 3 000 registrerade användare (varav över 300 var aktiva under den aktuella omgången) samt över 1 000 zoner placerade runtom i Sverige.
Turf är spel som kräver ett aktivt deltagande. Spelarna ställs mot varandra vilket styr hur lätt/svårt det är att behålla en zon. Finns det många aktiva användare i ett område så är risken högre att någon tar över en annans zon. Så länge det finns minst två användare i ett område så kommer spelarna ständigt uppmuntras att spela vidare och ett definitivt slut för spelet saknas. Användarna kan även erhålla medaljer i spelet som en belöning för att ha utfört något speciellt i spelet, till exempel om användaren har tagit över ett visst antal zoner inom en viss tid. Detta är saker som bidrar till att många användare spelar Turf mer än en gång. Användarna har tillgång till en karta över samtliga zoner där även aktiva spelare ritas ut. Användarna kan kommunicera med varandra genom en inbyggd chatt i spelet. I chatten kan användare dela med sig av sina upplevelser under spelandets gång. Detta är komponenter i spelet som bidrar till en gemenskaphetskänsla. En känsla som även den bidrar till att användare vill spela spelet igen.
Kapitel 3
Metod
I detta kapitel förklaras de metoder som använts under projektets gång.
3.1
Fallstudie
En fallstudie är en metod för att undersöka nutida fenomen i sitt sammanhang. Det är en forskningsstrategi som använder flera källor för att inhämta information från människor, grupper och organisationer. En fallstudie innebär avsaknad av experimentell kontroll. [13]
Forskning kan bedrivas på fyra olika sätt. Forskningen kan vara utforskande, vilket innebär att forskaren försöker ta reda på vad som händer, söker nya insikter och genererar idéer och hypoteser för ny forskning. Om forskningen är beskrivande för-söker forskaren porträttera en situation eller ett fenomen. Förbättrande forskning försöker i sin tur förbättra en viss del av ett studerat fenomen. Slutligen söker forskaren i förklarande forskning förklaringar av en situation eller ett problem. Fallstudie används först och främst när det handlar om forskning i utforskande syften. [13]
Forskningsdata kan vara antingen kvantitativ eller kvalitativ. En fallstudie består för det mesta av kvalitativ data: ord, beskrivningar, diagram och bilder, vilket erbjuder en rikare och djupare beskrivning. En kombination av kvalitativ och kvantitativ data (siffror och värden) ger en bättre förståelse av det studerande fenomenet. [13]
Designen av en fallstudie kan vara antingen flexibel eller fixerad. I en flexibel fallstudie kan studiens nyckelparametrar ändras under studiens gång, vilket inte görs i en fixerad fallstudie. [13]
För att öka precisionen i empirisk forskning används triangulering, vilket innebär att titta på det studerade objektet från flera olika vinklar. Triangulering används
nästan alltid vid användning av kvalitativ data. Det finns fyra typer av triangule-ring. Att samla in data från flera källor eller från samma källa vid olika tillfällen är en typ. Att använda fler än en observatör är en annan. Ytterligare ett sätt är att kombinera flera olika metoder, till exempel att använda både kvalitativ och kvantitativ data. Den sista typen är att använda sig av alternativa teorier och synsätt. [13]
Normalt utförs fallstudier inom psykologi, sociologi, statsvetenskap, socialarbete och näringslivet. Inom dessa områden utförs fallstudier för att öka kunskapen om individer, grupper, organisationer och sociala och politiska fenomen. [13] Dessa aspekter finns även inom mjukvaruutveckling, varför fallstudieforskning lämpar sig väl för mjukvaruutveckling.
En annan anledning till att fallstudier och mjukvaruutveckling går hand i hand är att mjukvaruutveckling till naturen är ombytlig, vilket en fallstudie med flexibel design hanterar.
I detta arbete har en flexibel fallstudie utförts eftersom ramarna för arbetet har varit öppna. Innan arbetet startade så fanns det ingen klar idé om vad som skulle göras utan detta var något som utformades under studiens gång. Denna studie har samlat in både kvantitativ och kvalitativ data från flera olika källor vilket motsvarar två typer av triangulering (data och metoder).
3.2
Brainstorming
Brainstorming är en metod som används i projekt för att låta de inblandade fritt spåna fram olika idéer kring ett specifikt problem. Metoden blev populär i bör-jan av 1950-talet när Osborn [14] beskrev den. Under brainstorming bör fölbör-jande principer eftersträvas:
• att inte kritisera andras idéer
• att få fram så många idéer som möjligt • att alla idéer uppmuntras, även de galnaste • att kombinera tidigare idéer
• att tänka högt
• att notera det som kommer fram
Det är inte ovanligt att de mest fantasifulla och till synes mest omöjliga förslag som kommer upp leder till en bra lösning. Under brainstorming önskas inga hämmande känslor och deltagarna måste tillåtas att vara barnsliga och okonventionella i sitt beteende. Metoden inte passar alla individer utan kan upplevas som för utmanande om en individ inte känner att denna presterar likvärdigt med övriga deltagare. Det kan även bli problem om det finns dominanta individer i gruppen som tar över och på så vis hämmar de andra. För att undvika denna typ av problem kan deltagarna
3.3 Storyboarding 13
tillåtas jobba individuellt och på så vis ta fram egna idéer som sedan presenteras i grupp, vilket kallas individuell brainstorming. [15]
3.3
Storyboarding
Storyboarding är en beprövad teknik som utvecklades av Walt Disney Studio på tidigt 1930-tal. Omkring ett decennium senare så producerades en av de första icke-tecknade filmerna som genomgående använde storyboarding. [16]
Storyboarding används numera ofta inom filmproduktion men även inom andra områden som systemutveckling. Storyboarding används som kommunikationsverk-tyg inom en grupp och fungerar som ett hjälpmedel för att förmedla en idé till de inblandade med hjälp av mer än bara text och tal. Ordspråket ”en bild säger mer än tusen ord” speglar principerna bakom storyboarding. Att ta fram skisser av ett system ger tidigt ett tydliggörande av systemets avsikter och även möjligheten att utvärdera systemet. [17]
Genom att använda storyboarding kan både pengar och tid sparas i ett projekt. De inblandade får en mer enad bild av målet och kommer på så vis att jobba mer i samma riktning. [18]
3.4
Användbarhet
Vi börjar med att titta på hur ISO (International Organization for Standardiza-tion) definerar användbarhet:
”Usability is the extent to which a product can be used by speci-fied users to achieve specispeci-fied goals with effectiveness, efficiency and satisfaction in a specified context of use.”
ISO 9241-11 [19]
Det är tydligt att ISO fokuserar på att produkten ska anpassas för målgruppen (specified users), ändamålet (specified goals) och den rådande situationen (speci-fied context). Denna definition fokuserar på slutanvändarens behov och när dessa är uppfyllda så anses produkten vara användbar.
Berndtsson och Domingues (tidigare Ottersten) har skrivit en bok, [20], som senare utvecklats till en hemsida, [21]. Det är denna hemsida vi har utgått från.
Enligt Berndtsson och Domingues [21] är det inte tillräckligt att se till användarnas behov. Om produkten inte uppfyller den nytta som beställaren har förväntat sig så anses produkten ej vara användbar. Berndtsson och Domingues menar vidare, likt ISO-standarden, på att användbarhet måste utgå från den förväntade nyttan. En produkt i sig kan inte vara användbar utan det är först när den sätts i sitt sammanhang som användbarhet kan uppstå. Som exempel är en konstnärspensel
väldigt användbar för att måla en tavla. Den är däremot mindre användbar för att måla om sitt hus och ännu mindre användbar för att klippa gräset.
Hur användbart ett system är beror på flera faktorer. Som exempel ska ett använd-bart system ha hög ändamålsenlighet. Med ändamålsenlighet menas att systemet innehåller relevant funktionalitet. Ett användbart system bör även vara lätt att lära sig och ha en hög effektivitet. Med hög effektivitet menas att systemet sällan gör fel (som kan bidra till merarbete) och klarar av att utföra många olika ar-betsuppgifter som underlättar för användaren. Till slut bör ett användbart system även vara tillfredställande. Med tillfredställande menas att användaren upplever välbehag under användandet och blir positivt inställd till hur systemet fungerar. [22]
3.4.1
System Usability Scale
System Usability Scale (SUS) är en metod för att mäta användbarheten på en pro-dukt (till exempel hårdvara, mjukvara, webbsidor och mobiltelefoner). Den togs fram av Brooke [23] och används för att snabbt och enkelt kunna ta fram ett en-skilt värde som beskriver hur användbar en produkt är. Ett värde som är enkelt att jämföra med andra produkter. Det faktum att SUS ger ett enskilt värde bidrar även till att samtliga inblandade i ett projekt kan relatera och göra jämförelser utan djupare kunskap. För att ytterligare öka uppfattningen av vad SUS-värdet betyder kan värdet associeras med ett adjektiv enligt en föreslagen skala. En skala som har tagits fram genom att komplettera SUS-formuläret med en extra frå-ga om användarens totala uppfattning angående användbarheten för det aktuella systemet. [24]
Mätningen består i sin grundform av 10 frågor där användaren ska svara på en skala mellan 1 och 5. På varannan fråga är 1 det mest positiva och på övriga 5. Första steget är att gå igenom alla svar och transformerar till en skala mellan 0 och 4 (där 0 är dåligt och 4 bra) och summerar sedan svaren. För att ta fram SUS-värdet multipliceras denna summa med 2,5 och uppnår på så vis en skala från 0 till 100 istället för 0 till 40. Produktens totala SUS-värde är sedan medel-värdet av samtliga användares SUS-värden. I figur 3.1 visas hur ett SUS-värde kan kategoriseras. [24] 0 10 20 30 40 50 60 70 80 90 100 SUS-värde Beskrivning Acceptabilitets-betyg
INTE ACCEPTABEL MARGINELL ACCEPTABEL
LÅG HÖG
BRA UTMÄRKT MÖJLIGABÄSTA OK
SVAG SÄMSTA MÖJLIGA
3.4 Användbarhet 15
Utöver SUS-värdet kan det även vara av intresse att beräkna dess standardavvi-kelse för att få en uppfattning om spridningen på svaren. Det går även beräkna medelvärdet och standardavvikelsen för varje enskild fråga (något som Brooke an-såg var ointressant) för att få en uppfattning om det är någon fråga som utmärker sig. [24]
I en studie omfattande 500 system har ett genomsnittligt SUS-värde på 68 beräk-nats. I samma studie har en skala tagits fram som kan användas för att översätta SUS-värdet för ett system till ett betyg från A till F. För att uppnå högsta bety-get A måste SUS-värdet överstiga 80,3. Allt under 51 motsvarar lägsta betybety-get F. Betyg A motsvarar ett system som anses vara mer användbart än 90% av samtliga undersökta system. Statistiken visar även att 15% av systemen får betyg F. [25]
Under slutfasen av projektet användes SUS-metoden för att ta fram systemets SUS-värde, mer om detta i avsnitt 4.5.3 på sidan 44. För att SUS-metoden skul-le kännas naturlig för testpersonerna har SUS-frågorna översatts till svenska, se tabell 3.1.
Nr Originalfråga Svensk översättning
1 I think that I would like to use this system frequently.
Jag tror att jag skulle vilja använda detta program ofta.
2 I found the system unnecessarily complex.
Jag tyckte att detta program var onödigt komplicerat.
3 I thought the system was easy to use.
Jag tyckte att detta program var lätt att använda.
4 I think that I would need the sup-port of a technical person to be able to use this system.
Jag tror att jag kommer att behöva hjälp av en teknisk person för att kunna använda detta program. 5 I found the various functions in this
system were well integrated.
Jag tycker att de olika funktionerna i detta program är väl samordnade. 6 I thought there was too much
in-consistency in this system.
Jag tyckte att det fanns för mycket inkonsekvens i programmet. 7 I would imagine that most people
would learn to use this system very quickly.
Jag kan tänka mig att de flesta skulle lära sig att använda detta program mycket snabbt.
8 I found the system very cumberso-me to use.
Jag tyckte att detta program var mycket besvärligt att använda. 9 I felt very confident using the
sy-stem.
Jag kände mig väldigt trygg när jag använde detta program.
10 I needed to learn a lot of things be-fore I could get going with this sy-stem.
Jag behövde lära mig mycket innan jag kunde komma igång med detta program.
3.4.2
Användbarhetstest
Användbarhetstestning är en metod som används för att utvärdera hur användbart ett system är. I ett användbarhetstest undersöks till vilken grad en användare klarar av att utföra de uppgifter som systemet är avsett att utföra. Genom att utföra tester i ett tidigt skede av ett projekt kan problem snabbt identifieras och på så vis spara tid. För att kunna utföra testerna används prototyper av systemet. Då brukar en generalisering göras till två olika typer: lofi- och hifi-prototyper [26]. Lofi står för ”low fidelity” och hifi står för ”high fidelity”. Lofi-prototyper är prototyper som är snabba och billiga att ta fram och kan användas för att utvärdera konceptet (till exempel innehåll och logik i arbetsflöde) av ett system. Hifi-prototyper är mer interaktiva och liknar mer det färdiga systemet och används för att utvärdera upplevelsen av ett system (till exempel grafisk profil, väntetider och flöde). En lofi-prototyp ger i allmänhet mer åsikter om funktionalitet eftersom den i en högre utsträckning upplevs som en icke-färdig produkt. [27] [28] [29]
Ett användbarhetstest ska utföras i en så realistisk miljö som möjligt, d.v.s. i en miljö där produkten är tänkt att användas. På så vis undviks många svåridentifie-rade faktorer som kan påverka testet. Vid utförandet av användbarhetstest är det viktigt att poängtera att det är systemet som testas, inte användaren. Av den an-ledningen bör termen ”användartest” undvikas. För att få ett relevant resultat är det viktigt att testa systemet med personer som tillhör den avsedda målgruppen. Om personerna inte stämmer in på målgruppen finns det risk för att resultatet blir missvisande, till exempel om en person inte känner till vissa termer som systemet bygger på. [21]
Då det är av vikt att testpersonerna tillhör den tänkta målgruppen gjordes tes-terna med studerande i 20-årsåldern. Studentes-terna var allt från förstaårs- till sista-årsstudenter vid LiU och hade därmed varierande erfarenhet av campusområdet. Samtliga hade ett gediget intresse för teknik och på ett eller annat vis tidigare erfarenhet av smartphones. För att undvika att påverka testet gavs en mycket sparsam introduktion av applikationen. Det klargjordes hur dokumentationen av testet skulle ske samt poängterades att testet syftade på att undersöka applika-tionen, inte användaren. Testpersonerna ombads att tänka högt och ställa frågor under testet. Det framgick även att frågor inte skulle besvaras under testets gång, utan först i efterhand.
För att verkligen förstå varför ett problem som berör användbarhet uppstår är det bra att använda en ”tänka-högt”-metod. En sådan metod går ut på att uppmana användaren att tänka högt under testet för att få en klarare bild av hur använ-daren resonerar och varför vissa beslut tas. På så vis ges det större möjlighet att hitta själva orsaken till att något inte går som förväntat. Allt som användaren säger dokumenteras, antingen genom någon typ av inspelning eller anteckningar. Testledaren kan även ställa kompletterande frågor men måste då vara försiktig med formuleringen då det är lätt att påverka testpersonen så att testet blir miss-visande. Därför brukar det vara fördelaktigt om testledaren undviker att svara på frågor. För att undvika lustiga situationer bör detta förklaras för användaren innan
3.4 Användbarhet 17
testet påbörjas. Om användaren verkligen fastnar får testledaren lov att hjälpa till men måste då vara medveten om att ytterst lite hjälp kan göra en stor skillnad i resultatet, till exempel genom att säga ”Prova tryck på den här knappen”. [30] Allt eftersom slutprodukten tar form kan tester utföras på denna. Det är fullt möjligt att testa en prototyp av produkten, det vill säga en version som inte motsvarar hela slutprodukten utan delar av den. Här finns två varianter att välja bland, horisontell eller vertikal prototyp. [29]
En horisontell prototyp är relativt omfattande när det gäller mängden funktioner. I en horisontell prototyp förmedlas vad den slutgiltiga produkten kommer vara kapabel att utföra, utan att visa hur det kommer ske. En horisontell prototyp för en ordbehandlare skulle kunna vara en prototyp med funktionerna spara, kopiera, söka och formatera en text. Dock behöver inte dessa funktioner vara implemen-terade mer än i det grafiska gränssnittet så att användaren ser att funktionerna finns. [29]
En vertikal prototyp är istället en prototyp där en begränsad mängd funktioner är fullt implementerade. I exemplet med ordbehandlaren skulle det kunna mot-svara att fullt ut ge användaren möjligheten att spara ett dokument. Begreppen horisontell och vertikal prototyp illustreras i figur 3.2.
funktionalit
et
funktioner
Figur 3.2: En så kallad T-prototyp (blandning av horisontell och vertikal prototyp), rekonstruerad från [29].
I denna studie har det tagits fram en lofi- och en hifi-prototyp. I början av processen togs en pappersprototyp (lofi) fram för att utvärdera de grundläggande principerna som systemet skulle bygga på. Utvecklingsprocessen resulterade i en evolutionär datorprototyp (hifi) som användes till ett användbarhetstest.
3.4.3
Pappersprototyp
Pappersprototyp är ett exempel på en lofi-prototyp. Den går relativt snabbt att ta fram och syftar på att ge användaren en första bild av hur systemet kommer att se ut och vad som händer när användaren interagerar med det. Ett test kan i detta fallet bestå av att visa en ritad bild på systemets initialläge och sedan fråga an-vändaren vad den skulle göra som nästa steg för att utföra en fördefinerad uppgift.
När användaren trycker på till exempel en knapp så får en testledare arrange-ra om/byta ut aktuella komponenter så att det motsvaarrange-rar det tänkta systemets agerande. [31]
För att hålla antalet skisser på en hanterlig nivå togs det ej fram skisser för de delar av systemet som upprepade sig. Genom att testa den idé som hade tagits fram upptäcktes tidigt komponenter som inte fungerade som förväntat redan innan implementationen påbörjats.
Testet av pappersprototypen gjordes med fyra personer, varav en kvinna och tre män, och utfördes i en lugn miljö för att undvika störande faktorer. Uppgifterna användarna skulle utföra var att följa instruktionerna på skisserna. När användaren förmedlade interaktion med prototypen byttes skissen ut med hänsyn till ageran-det. Vid varje test närvarade två testledare: en som skrev anteckningar och en som hanterade skisserna. Under testet gjordes en videoinspelning och anteckningar för-des om testpersonens agerande. Efter testet hölls en ostrukturerad intervju med testpersonen.
Efter testerna sammanfattades anteckningarna och om något var oklart användes videoinspelningen för att kontrollera detta. Sammanfattningarna användes som underlag för att göra ändringar i storyboardsen innan utvecklingen påbörjades.
3.4.4
Evolutionär datorprototyp
En evolutionär datorprototyp är ett exempel på hifi-prototyp. En prototyp som byggs med högre kvalitétskrav och allt mer liknar det slutgiltiga systemet. An-vändaren kan interagera med prototypen och systemet reagerar på kommandon (utan hjälp av en extern testledare). Till skillnad från en så kallad ”throw away”-prototyp (som kastas bort efter dess användande) kan en evolutionär away”-prototyp utvecklas till den färdiga produkten. [32]
Under processens gång har en evolutionär prototyp tagits fram. Efter utveckling-en utvärderades prototyputveckling-en gutveckling-enom ett användbarhetstest för att bedöma kvalitén på den ursprungliga idén. Den evolutionära prototypen testades också med fyra personer ur tidigare nämnd målgrupp, dessa var dock alla män. För att få ett rättvisst resultat på användbarheten av systemet testades systemet av nya per-soner som inte haft kontakt med systemet tidigare. Till skillnad från testerna på pappersprototypen så utfördes dessa tester i den tänkta spelmiljön, det vill säga på Campus Valla. Uppgiften som gavs till testpersonerna bestod i att följa de instruktioner som visades i telefonen när de startade applikationen tills det inte fanns fler instruktioner.
Till skillnad från testet av pappersprototypen kunde båda testledarna observe-ra och föobserve-ra anteckningar om testperonens ageobserve-rande. Detta eftersom att det var tänkt att testpersonen efter introduktion skulle kunna slutföra hela testet utan interaktion med testledarna. Efter testet hölls en semistrukturerad intervju där testpersonen fick svara på frågorna i tabell 3.1 på sidan 15. Svaren på frågorna behandlades enligt SUS-metoden.
3.5 Utveckling 19
3.5
Utveckling
För att ta fram en evolutionär prototyp har en del av projekttiden ägnats åt utveckling. För att strukturera upp utvecklingsprocessen användes inslag från den agila metodiken Scrum [33]. Under arbetet användes ett antal verktyg för att underlätta utvecklingen.
3.5.1
Verktyg
Utvecklingen skedde under Windows Vista med Eclipse (https://www.eclipse. org/) som utvecklingsmiljö. Valet av Eclipse föll sig naturligt eftersom det är det rekommenderade sättet att utveckla för Android. Det finns ett plugin till Eclip-se, ”Android Development Tools” (ADT), som utökar Eclipse med möjligheter att sätta upp nya Androidprojekt, ändra applikationers gränssnitt, felsöka samt exportera applikationer för distribution. ADT finns endast till Eclipse.
Git (http://git-scm.com/) tillsammans med GitHub (https://github.com/) användes för versionshantering av koden, något som underlättade utvecklingsar-betet avsevärt. Med Git är det väldigt enkelt att skapa en ny gren (”branch” på engelska) av koden, vilket nyttjades flitigt under utvecklingstiden. Dessutom är decentraliserade versionshanteringssystem som Git, bättre än centraliserade sy-stem (som Subversion) på att foga samman ändringar (merge) [34]. Att använda ett arkiv (engelska ”repository”) lagrat hos webbtjänsten GitHub dit ändringar skickades varje dag tjänade även som en sorts backup. Dessutom är GitHub ett bra verktyg för att titta på koden och granska ändringar som gjorts.
Campfire (http://campfirenow.com/), en webbaserad tjänst för realtidschatt, användes under hela projekttiden för internkommunikation. Campfire lät utveck-larna kommunicera på ett sätt som underlättade utvecklingen. Istället för att störa varandra så fort ett frågetecken uppstod, ställdes istället frågan i Campfire. Den andra parten kunde då själv välja att svara på frågan vid ett tillfälle som passade bra. Campfire underlättade även kommunikationen när utvecklarna befann sig på fysiskt skilda platser.
3.5.2
Utvecklingsmetodik
Under implementeringsfasen av projektet tillämpades en systemutvecklingsmeto-dik med inspiration hämtad från Scrum. Scrum passar bäst för 5-9 personer och var därför inte lämplig att användas i sin helhet.
Roller
Utvecklargruppen bestod av författarna till denna rapport. Från början var det tänkt att det även skulle finnas en Scrum-mästare (anställd på Attentec), men i
praktiken agerade Scrum-mästaren snarare som processhandledare och bollplank åt utvecklargruppen. Personen deltog inte i utvecklingen. Någon produktägare utsågs inte, utan produktbackloggen sköttes av utvecklarna själva.
Möten
För det dagliga Scrum-mötet valdes ett upplägg som skiljer sig från det ursprungli-ga. Eftersom utvecklargruppen och Scrum-mästaren befann sig på fysiskt åtskilda platser och inte hade möjlighet att ses varje dag skedde det dagliga Scrum-mötet via e-post.
Under utvecklingstiden gjordes anpassningar för att förbättra metodiken. Ett ex-empel på det är att tidpunkten för det dagliga Scrum-mötet ändrades från att vara i början av dagen, som i traditionell Scrum, till att vara i slutet av dagen. Detta för att Scrum-mästaren inte hade möjlighet att komma med feedback förrän i slutet av dagen. På detta sätt fick utvecklargruppen hela tiden färsk feedback från Scrum-mästaren.
I vanlig ordning genomfördes planeringsmöte inför varje sprint. Eftersom utveck-lingstiden var knapp hölls inga granskningsmöten eller återblicksmöten. Totalt tre stycken sprintar genomfördes under projektet.
Artefakter
För att hålla ordning på aktiviteterna som skulle utföras av utvecklargruppen an-vändes två system. Ett elektroniskt projekthanteringssystem, Redmine, anan-vändes av två anledningar. Dels för att lagra den fullständiga produktbackloggen och dels för att det möjliggjorde för Scrum-mästaren att på distans gå in och läsa mer om aktiviteterna.
Det andra systemet bestod av ett stort pappersark uppklistrat på en av väggarna i rummet där utvecklargruppen huserade under projekttiden. Detta ark hade tre kolumner: ”Att göra”, ”Under arbete” och ”Klart”. Kolumnen ”Under arbete” var i sin tur indelad i två kolumner, en för varje utvecklare. Varje aktivitet som skulle utföras under en aktuell sprint noterades på en klisterlapp tillsammans med ett unikt prioriteringsvärde. Lapparna sattes upp på arket i ”Att göra”-kolumnen. När en utvecklare valde en aktivitet att utföra flyttades lappen till utvecklarens kolumn. När aktiviteten var klar flyttades lappen till kolumnen ”Klart”.
I slutet av dagen summerades antal estimerade timmar som avverkats. Dessa fördes in i ett burn down-diagram (se figur 3.3 på nästa sida) för att få en bild på hur vi tidsmässigt låg till i projektet. Vanligtvis har varje sprint ett burn down-diagram. I det här fallet gjordes ett burn down-diagram över hela utvecklingsperioden, ef-tersom tidsperioden för varje sprint var kortare än vanligt.
3.5 Utveckling 21 0 20 40 60 80 100 120 140 160 180 200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 es #mer ad e #mma r dagar Burn down-‐diagram
fak/sk burn down ideal burn down
Figur 3.3: Burn down-diagram över utvecklingsperioden. För sista utvecklingsda-gen noterades inte antalet timmar.
Kapitel 4
Resultat
I detta kapitel presenteras resultaten från de olika metoderna som förklarades i föregående kapitel.
4.1
Brainstorming
Under arbetets gång togs det fram ett antal idéer angående olika sätt att applicera förstärkt verklighet på campus. I detta avsnitt presenteras några av de idéer som anses vara av intresse. Idéerna uppstod under projektets inledande fas men även inför och under möten med representanter från LiU. Det har utförts brainstorming kring ämnet med målet att få fram kreativa idéer som kan bidra till en lösning.
Kaniner
En av de första idéerna som diskuterades handlade om att mer eller mindre slump-mässigt placera ut virtuella kaniner i spelet som skulle hoppa runt på campus. Spelaren skulle sedan få i uppgift att fånga kaninerna och på vis samla poäng i spelet. Spelarna interagerar med samma mängd objekt så när en kanin är tagen så kan inte någon annan spelare ta den kaninen. Det är en idé som härstammar från ett annat projekt inom förstärkt verklighet: iButterfly, se 2.2.3 på sidan 8.
Vid närmare undersökning visade det sig att det skulle bli svårt att placera ut kaniner på marken så att det skulle se naturligt ut. Det kräver att applikationen tar hänsyn till byggnader, träd, cykelställ, och liknande, vilket ställer högre krav än vad dagens tekniker och mobiltelefoner kan erbjuda. Fördelen med fjärilar istället för kaniner är att en fjäril kan befinna sig i princip var som helst utan att det ser onaturligt ut. En fjäril är betydligt mindre och kan utan att det upplevs som lustigt vara placerad på en vägg eller ovanför ett cykelställ.
Realtidsinformation
En annan idé var att presentera realtidsinformation på campus. Genom att en användare går runt och filmar en byggnad med kameran i telefonen kan använ-daren till exempel få information om den aktuella elförbrukningen i byggnaden. Informationen skulle kunna presenteras i form av ett stapeldiagram som ritas ut ovanpå kamerabilden. Det skulle även presenteras annan information såsom till ex-empel antal bokade salar, aktuella forskningsprojekt, antal anställda, belastning på trådlösa nätverket och så vidare.
Denna idé valdes bort eftersom det inte var självklart hur informationen som skulle presenteras skulle samlas in. Antagligen skulle universitetets IT-avdelningen behöva blandas in. Att bli beroende av dem ansågs som en alltför stor risk, eftersom de enligt uppgift av representanter från LiU har att göra så det räcker.
Historisk återblick
Varje plats har en historia att berätta. En historia som med fördel kan förmedlas med hjälp av dagens telefoner. Idén går ut på att låta användaren ta del av gamla fotografier, filmer och berättelser genom att använda sin telefon på den plats där händelsen utspelade sig. Användare skulle kunna filma ett hus med mobilkameran och i realtid överlagra en fasad för att illustrera hur byggnaden såg ut förr i tiden. Det skulle kunna vara möjligt att illustrera hur en historiskt betydelsefull person vandrar runt på området. Campusområdet i Norrköping har en intressant historia i och med det fabriksområde som befann sig där förr i tiden. Ett annat alternativ skulle kunna vara att visa historia som inte sträcker sig fullt så långt bak i tiden, till exempel hur området såg ut förra sommaren eller under ett visst arrangemang.
Idén valdes bort då det ansågs att arbetet med att samla in material och behandla det skulle ta för stor del av projektet. Idén kan dock vara väl värd att genomföra i framtiden.
Inomhusnavigering
I samband med att GPS-tekniken har tagit sig in på mobilmarknaden har det blivit möjligt att hålla reda på användarens position. Positionen kan sedan an-vändas för att hjälpa användaren att navigera i omgivningen. GPS fungerar dåligt inomhus då kontakten med satelliterna är begränsad eller saknas helt. Med det i åtanke vore det intressant att leta alternativa tekniker för navigering inomhus. Efter noggrannare undersökningar visade det sig att sådana tekniker handlade mer om signalbehandling än vad detta projektet hade för avsikt att gå in på.
4.2 Användningsfall 25
Skattjakt
En annan idé som blev aktuell var att skapa en skattjakt. Spelaren skulle upp-muntras till att röra sig på campus för att leta efter olika virtuella skatter som var gömda i förväg. Skatterna går bara att se genom användarens telefon och är göm-da på föremål som existerar naturligt i verkligheten, till exempel en skylt. Varje skatt skulle kunna innehålla information om platsen där skatten är gömd. Det var den här idén som efter brainstormingen bedömdes kunna förstärka en plats med anknytning till Linköpings universitet på ett bra sätt och vi valde att bygga vidare på den.
Efter en del spånande togs följande lista med lämpliga beståndsdelar för en skatt-jakt fram:
• Regionen där skatten göms. En region utgörs av GPS-koordinater (latitud och longitud i grader) och en radie (i meter). Regionen motsvarar det område som användaren måste befinna sig i för att kunna hitta en skatt. • Ledtråd 1. Denna ledtråd ska tillsammans med avståndsindikatorn hjälpa
användaren att hitta till skattens region.
• Gömställe för skatten. I teorin kan det vara ett foto på vad som helst men det finns vissa saker att tänka på, dessa förklaras i avsnitt 4.4.1 på sidan 37. • Ledtråd 2. Denna ledtråd ska hjälpa användaren att lista ut vad det är för
objekt som den virtuella skatten är gömd vid.
• 3D-objekt av den virtuella skatten. Detta objekt visas när användaren hit-tar skatten med kameran.
• Informationen om platsen som presenteras efter skatten är hittad. Infor-mationsvyn består av platsens namn, en bild och en text om platsen.
4.2
Användningsfall
Innan utvecklingen påbörjades togs ett användningsfall fram för Lara. Använd-ningsfallet beskriver ett tänkbart scenario där en användare interagerar med Lara. Utvecklingen har skett med detta fall i åtanke.
Kalle har sedan tre veckor tillbaka pluggat teknisk fysik på Lin-köpings universitet. Kalle är mycket intresserad av teknik och har sen fyra månader tillbaka en smartphone med operativsystemet Android. Via sin fadder Stina har han fått höra om ett mobilspel som heter Lara, som tydligen ska utspela sig på Campus Valla. Då Stina har be-rättat att det går att vinna gratis kaffe i en vecka bestämmer han sig för att prova applikationen. Han laddar hem den från Android Market i pausen på en föreläsning. Efter föreläsningen i C1 har han ett hål i schemat. Han tänker att det passar bra att prova Lara då. Han sätter
sig på en bänk i Colosseum och startar applikationen. Han läser in-formationen på välkomstskärmen och förstår snart att det handlar om en skattjakt. Han klickar sig vidare till översikten. Där har han fyra alternativ.
Applikationen visar att han befinner sig i närheten av skatten men han har ändå en bit kvar. Av ledtråden förstår han att han ska rö-ra sig mot Kårö-rallen. Avståndsindikatorn visar att han tar sig närmre och närmre skatten. En ny knapp dyker upp på skärmen där det står ”Nästa ledtråd”. Spännande tänker Kalle och trycker på knappen. Ap-plikationen går över till kameraläget och en ny ledtråd visas längst upp på skärmen. Med hjälp av den ledtråden listar Kalle ut att han ska sikta med kameran på byggnadens logotyp som finns placerad till vänster om vindbryggan. Han går dit och siktar på logotypen och det dyker upp en timer i applikationen som räknar ner. Samtidigt ser han även en LiU-logga som ser ut att sväva utanför väggen. ”Wow!” tänker Kalle.
När timern har räknat ner så ser Kalle en ny knapp på skärmen som säger ”Gå vidare”. När Kalle beundrat skatten ett tag så bestäm-mer han sig för att trycka på knappen. Då får han upp information om Kårallen. Det visar sig att det finns ett café på bottenplan som Kalle inte hört talas om: Baljan. Kalle trycker på tillbakaknappen och kom-mer till översikten. Översikten visar en lista över skatter. Han ser att han har tagit skatten som heter ”Kårallen”. Han väljer nästa element i listan. Han får en ny ledtråd som tar honom vidare till nästa plats där han letar efter den andra skatten i spelet, på liknande vis som den första. När Kalle har hittat alla fyra skatter får han ett tävlingskod-ord som han uppmanas uppge på Kårexpeditionen för att vara med i tävlingen. Kalle tyckte spelet var roligt och har nu lärt sig en hel del nytt om campus.
4.3
Storyboarding
Alla vyer i applikationen skissades på papper innan implementationen påbörjades. Det var ett väldigt bra sätt för att få en överblick av applikationen och dess flöde. Nedan presenteras de storyboards som skissades fram. Flera detaljer har i storyboards ändrats vid implementation, men på det stora hela stämmer de fortfarande överens med den implementerade applikationen.
4.3 Storyboarding 27
Introduktionsvy
Figur 4.1: Vyn som visas första gången applikationen startas.
När applikationen startas för första gången syns vyn i figur 4.1. Överst finns en kort beskrivande introduktion i stil med:
Det finns totalt X skatter gömda på campusområdet. Låt oss se hur många du kan hitta!
Efter denna text visas någon grafik som ger en ledtråd om applikationens syfte (till exempel en skattkista). Längst ner i vyn visas en stor tydlig bild med texten ”Börja skattjakten”, se figur 4.1. När användaren trycker på knappen startar spelet.
Avståndsindikator: Långt ifrån skatten
Figur 4.2: Utanför skattens region. Vyn som visas när användaren valt att leta efter en ny skatt men befinner sig utanför skattens region.
Genom att trycka på ”Börja skattjakten” kommer användaren till vyn i figur 4.2. Denna vy innehåller en ledtråd som ska guida användaren till rätt region där skatten finns gömd. En avståndsindikator visar om användaren är nära eller långt ifrån skatten. Längst ner i vyn finns en knapp som är inaktiverad fram till att användaren befinner sig inuti regionen.
4.3 Storyboarding 29
Avståndsindikator: Nära skatten
Figur 4.3: Vyn som visas när användaren letar efter en skatt och befinner sig inom skattens region.
Är avståndet tillräckligt litet kommer en knapp (till exempel ”Fånga skatt”) längst ner på skärmen att låsas upp och börja pulsera för att väcka användarens upp-märksamhet, se figur 4.3. Knappen tar användaren till nästa vy.
Kameraläge: Användaren letar efter en skatt
Figur 4.4: Vyn som visas när användaren letar efter en skatt med kameran.
Längst ner i vyn i figur 4.4 kan användaren ta del av ytterligare en ledtråd som ska guida användaren till gömstället, det vill säga det objekt som ska upptäckas med kamera.
4.3 Storyboarding 31
Kameraläge: Användaren hittar en skatt
Figur 4.5: Användaren har lokaliserat skatten men inte tagit den ännu.
När användaren har hittat rätt objekt så dyker en virtuell ”skatt” (i detta fall en tekanna) upp ovanpå bilden från kameran (se figur 4.5). Nu måste användaren hålla skatten i kamerafånget i fem sekunder för att skatten ska anses som hittad.
Kameraläge: Användaren har hittat en skatt
Figur 4.6: Användaren har lokaliserat och tagit skatten.
Efter att skatten är tagen byts ledtråden ut mot knappen ”Gå vidare” som an-vändaren kan klicka på för att komma till nästa vy.
4.3 Storyboarding 33
Informationsvy
Figur 4.7: Kortfattad information om omgivning där skatten hittades.
Efter att användaren har tryckt på ”Gå vidare” så får användaren upp en vy med information om platsen där skatten hittades. Denna vy består av en karta med ett antal punkter markerade. Dessa punkter beskrivs kortfattat under kartan. Exem-pelvis kan det vara en karta över Kårallen med Café Baljan och Kårexpeditionen utmärkt. Under kartan står det kort vad Baljan respektive Kårexpeditionen är för något.
I figur 4.7 har användaren två alternativ: Leta efter skatten igen eller gå till över-sikten.
Översiktsvy
Figur 4.8: Översikt. Vyn som visas när applikationen startas efter att användaren har hittat minst en skatt.
Om applikationen startas och användaren redan har hittat minst en skatt så visas en översikt av de funna skatterna i den vy som kallas ”översikt”, se figur 4.8.
4.3.1
Utvärdering av pappersprototyp
Under projektets gång har användbarhetstester utförts för att kontrollera kvalitén på prototyperna som tagits fram. Genom att undersöka hur väl de olika delar-na av applikationen fungerade gentemot användare kunde utvecklingen anpassas
4.3 Storyboarding 35
därefter. Tester har utförts på både pappersprototypen och den evolutionära pro-totypen.
En av de första sakerna som noterades var att återkopplingen till användaren behövde förstärkas efter att en skatt har hittats. Användarna uppfattade inte att skatten hittades och saknade en tydlig indikation på detta. En av användarna som testade applikationen föreslog att det borde spelas upp ett ljud medan en annan tyckte att det skulle stå ”grattis”. Det senare implementerades till den evolutionära prototypen. Istället för att ha kvar räknaren som stod på ”0.0” byttes denna mot texten ”GRATTIS!”. Det gjordes även ett förtydligande efter att en skatt hade hittats genom att skriva ut ”GRATTIS!” på översiktsvyn.
En annan sak som uppmärksammades var att det var svårt att förmedla att använ-daren skulle gå mot skattens plats för att ta sig vidare i avståndsindikatorläget (se figur 4.2 på sidan 28). En av användarna valde att trycka på objektet som beskrevs i ledtråden och även försöka zooma sig närmare objektet genom att använda sig av en zoommetod med två fingrar. Detta kan berott på att testet utfördes inomhus och stillasittandes. Det krävdes alltså inte att användaren fysiskt förflyttade sig till platsen för att skissen på avståndsindikatorn skulle ge utslag. Detta var något som användaren fick beskriva för testledaren genom att säga ”nu går jag närmare platsen” eller liknande. För att tydliggöra att användaren i den färdiga produkten måste förflytta sig fysiskt ändrades ledtrådarna till att börja med ”Gå till ...”.
Testet gav även kommentarer om att knappen ”Gå vidare” i figur 4.6 på sidan 32 var en märklig ledtråd. I figuren syns att den delen av skärmen är döpt till ”Ledtråd #2” vilket var missvisande. Det beslutades att ta bort denna rubrik helt då den ändå ansågs vara självförklarande.
I figur 4.2 på sidan 28 visas en inaktiv knapp, med texten ”Fånga skatt”, som blir aktiv när spelaren förflyttar sig in i skattens område. Testerna visade på att användarna inte upplevde knappen som inaktiv och försökte trycka på den. Med det som bakgrund togs beslutet att inte visa knappen förrän spelaren befinner sig inom skattens område. Det finns en möjlighet att det inte hade varit något problem på den evolutionära prototypen då det eventuellt hade varit tydligare att knappen var inaktiv på ett digitalt gränssnitt men eftersom det egentligen inte fanns något syfte att visa den inaktiva knappen togs beslutet att ta bort den.
Testerna visade att vyn för att visa information om en plats (se figur 4.7 på sidan 33) ibland kunde uppfattas som rörig i förhållande till övriga vyer. Vyn innehåller rubrik, bild, text och två knappar (”Leta efter denna skatt igen” och ”Tillbaka till översikten”). Efter testerna på pappersprototypen så plockades knap-pen ”Tillbaka till översikten” bort. Denna funktionalitet implementerades istället i telefonens fysiska tillbakaknapp. En användare ansåg att knappen ”Leta efter denna skatt igen” inte behövdes i vyn som visas efter att en skatt är hittad. En åsikt som bedömdes fullt rimlig men som på grund av tidsbegränsningar aldrig åtgärdades.
4.4
Val av plattform för förstärkt verklighet
För att utveckla prototypen var ett val av plattform tvunget att göras. Valet av operativsystem stod mellan Android och iOS. Till dessa operativsystem finns olika plattformar för förstärkt verklighet. Nedan följer en redogörelse av de plattformar som valet stod mellan.
Layar [35] är en mobilapplikation som använder mobiltelefonens position (GPS)
för att visa vad som finns i din närhet. Det kan dels vara verkliga platser så som restauranger och sevärdheter, men även virtuella saker som en användares position när de skrev ett visst meddelande på Twitter [36]. I stort sett allt med en GPS-position kan visas i Layar. Vad för innehåll som ska visas väljs genom att välja olika lager. Nästan vem som helst kan bidra med innehåll genom att skapa ett eget lager och specificera vad lagret ska innehålla. Layar valdes inte eftersom det hade inneburit för stora begränsningar gentemot att göra en egen applikation. Layar finns till både iOS och Android.
D’Fusion [37] är ett kommersiellt utvecklingsverktyg för förstärkt verklighet
från Total Immersion. Verktyget finns till både Android och iOS, och klarar av det som kallas ”markörlös spårning”. Detta verktyg valdes inte eftersom licenserna ansågs för dyra.
Junaio [38] är en applikation väldigt lik Layar till funktion och upplägg,
utveck-lad av Metaio. En viktig skillnad mot Layar är att Junaio har stöd för bildigenkän-ning. Precis som i fallet med Layar innebar Junaio för stora begränsningar jämfört med att skapa en egen applikation. Junaio finns till både iOS och Android.
Unifeye Mobile [39] är ett kommersiellt utvecklingsverktyg för förstärkt
verk-lighet även det från Metaio. Verktyget finns till både Android och iOS, men även till Symbian och Windows Mobile. Även detta verktyg klarar av ”markörlös spår-ning”. Detta verktyg valdes inte eftersom det var för dyrt att köpa licenser för det.
ARmsk som står för Augmented Reality Markerless Support Kit är ett bibliotek
som gör bildigenkänning. Det togs fram under ett examensarbete på Combitech och släpptes som öppen källkod i januari 2011 till Android [40]. ARmsk är inte begränsat till traditionella svartvita markörer utan klarar även av fotografier. Ef-tersom prestandan (uppdateringsfrekvensen av antalet bilder per sekund) ansågs vara för lågt vid användning av detta bibliotek valdes det bort.
