Kandidatuppsats
Notifikationsmodeller i virtuell verklighet vid träning inför akuta situationer
En jämförelse mellan två grafiskt presenterade notifikationsmodeller
Författare: Robert Bramstedt Handledare: Karl Johan Rosqvist Examinator: Nico Reski
Termin: VT 20 Ämne: Medieteknik Nivå: C
Kurskod: 2ME30E
Abstrakt
VR står för Virtual Reality och används idag ofta för utbildning, både inom skola och yrkesgrupper då det har uppvisat goda resultat och är relativt billigt att utföra jämfört med att träna till exempel personal inom brandkår, sjukhus och polis. Finns det en applikation där flera användare inklusive en instruktör kan samverka oberoende plats och plattform blir det bättre ur både logistiskt och ekonomiskt perspektiv. Det finns idag ingen standardiserad modell för notifikationer inom VR och därför finns det en mängd olika modeller för att fånga användarens uppmärksamhet.
Det här arbetet handlar om att undersöka webbläsaren som verktyg för en Virtual Reality- applikation där flera användare samtidigt kan använda applikationen oberoende av vilken plattform som används. Anledningen till att det skall fungera för flera användare samtidigt är för att applikationen är till för träning inför akuta situationer och då skall både instruktör och användare kunna vara i applikationen samtidigt. Arbetet handlar också om att ta reda på vilken av de två notifikationsmodeller som i det här arbetet testas är det mest tidseffektiva vid träning av brandkår med hjälp av VR-teknik. Resultatet har framkommit genom utförda användartester genomförda med hjälp av en prototyp som har utvecklats; samt intervjuer av de testpersoner som har deltagit i användartester. Testpersonerna delades upp i två lika stora grupper på 10 st i varje grupp för att testa två olika notifikationsmodeller. De testade notifikationsmodeller är en statisk nödutgångsskylt och en visuell vägvisare i form av en pil i golvet som rör sig i för scenariots uppgift rätt riktning. Uppgiften som testpersonerna fick var att ta sig från en punkt till en annan i en rökfylld lokal på så snabb tid som möjligt, med hjälp av den notifikation som tilldelades. Testpersonerna rangordnades efter att samtliga test var genomförda. Den som klarat sig bäst i den ena gruppen jämfördes med den som klarat sig bäst i den andra gruppen och så vidare. Resultatet visar tendenser åt att den visuella vägvisaren var den mest effektiva av de två notifikationsmodeller som testades. Deltagarna i gruppen som använde den visuella sökvägen presterade något bättre, vilket indikerar en trend mot preferenser för den notifikations modellen framför den statiska nödutgångsskylten.
Nyckelord
Collaborative virtual reality, virtual reality, gamification VR, virtual reality online collaborative, VR notification, VR interaction
Abstract
VR stands for Virtual Reality and is today often used for education, both in schools and professional groups as it has shown good results and is relatively cheap to perform compared to training staff in fire brigades, hospitals and the police, for example. If there is an application where several users, including an instructor, can collaborate independently of location and platform, it will be better from both a logistical and financial perspective. There is currently no standardized model for notifications within VR and therefore there are a variety of models to capture the user's attention.
This work is about examining the browser as a tool for a Virtual Reality application where several users can use the application at the same time regardless of which platform is used.
The reason why it should work for several users at the same time is because the application is for training in emergency situations and then both instructor and user should be able to be in the application at the same time. The work is also about finding out which of the two notification models tested in this work is the most time-efficient when training fire brigades using VR technology. The result has emerged from user tests performed using a prototype that has been developed; as well as interviews of the test persons who have participated in user tests. The test subjects were divided into two equal groups of 10 in each group to test two different notification models. The tested notification models are a static emergency exit sign and a visual signpost in the form of an arrow in the floor that moves in the right direction for the task of the scenario. The task given to the test subjects was to get from one point to another in a smoke-filled room as quickly as possible, with the help of the notification that was assigned. The test subjects were ranked after all tests had been completed. The one who did best in one group was compared with the one who did best in the other group and so on. The results show tendencies that the visual signpost was the most effective of the two notification models tested. The participants in the group using the visual pathfinder performed slightly better, indicating a trend towards the preference of this notification model over the static exit sign
Keywords
Collaborative virtual reality, virtual reality, gamification VR, virtual reality online collaborative, vr notification, VR interaction
Innehållsförteckning
1 Inledning 4
1.1 Bakgrund 5
1.2 Problemformulering 6
1.3 Syfte 6
1.4 Frågeställning 6
1.5 Hypotes 7
1.6 Strategi för lösning 7
1.7 Avgränsningar 7
2 Teori 9
2.1 Litteraturstudie 9
2.2 Tekniker 12
3 Prototypimplementation 14
4 Metod 17
4.1 Metodbeskrivning 17
4.2 Användartest 18
4.3 Scenario 18
4.4 Intervju 20
4.5 Beträffande Coronaviruset SARS-CoV-2 20
4.6 Genomförande 21
5 Resultat 23
5.1 Användartest 23
5.2 Intervju 25
6 Diskussion 27
6.1 Slutsats 29
7 Vidare forskning 30
Referenser 31
Förord
Först och främst vill jag tacka Peter Thor på Omnifinity som varit ett stort stöd för arbetet.
Med tanke på Coronapandemin så har arbetet ändrats längs vägen men detta till trots har Peter hela tiden stöttat mig för att jag ska kunna få arbetet klart och ständigt funnits till hands. Jag vill även tacka min handledare Karl-Johan Rosqvist på Linnéuniversitetet som har hjälpt mig med struktur på uppsatsen. Han har hela tiden varit närvarande och hjälpt till att reda ut frågetecken som framkommit under arbetet, både vad gäller språket och upplägg.
Tack!
1 Inledning
Virtual Reality, förkortas VR, och betyder Virtuell Verklighet. Enligt Virtual Reality Society (2017) betyder VR near-reality, nära verkligheten. VR-glasögon är en teknologi som är av typen uppslukande skärmteknologi och som stödjer VR-teknologi. Inuti glasögonen visas en skärm för användaren vilket gör att det uppfattas som att man befinner sig i en virtuell verklighet, en digital miljö. När användaren rör på huvudet reagerar sensorer i VR-hjälmen och speglar användarens rörelser till den digitala världen. Lavelle (2019) delar upp VR i fyra nyckelkomponenter. De fyra komponenterna är:
● Riktat beteende
○ Organismen har en upplevelse som är designad av skaparen
● Organism
○ Mänsklig användare eller någon annan levande varelse såsom kackerlacka, fisk eller apa, bland annat.
● Teknisk sensorisk stimulans
○ En eller flera av organismens sinnesorgan samverkas och dess vanliga insatser ersätts eller förbättras
● Medvetenhet
○ Organismen luras att känna sig närvarande i en virtuell värld. Organismen får en känsla av närvaro i en alternativ eller förändrad värld vilket i detta fall upplevs som naturligt
Första gången VR nämndes som glasögon var redan 1935 (Virtual Speech, 2020) i kortfilmen Pygmalion’s Spectacles. Den första flygsimulatorn i VR skapades 1966 för att träna det amerikanska flygvapnet (Virtual Speech, 2020). Eftersom flygvapnet sedan också tillhandahöll finansiering för att tillverka bättre flygsimulatorer främjade det även utvecklingen av VR-teknologin. Elva år senare, 1977, skapades ett program som gjorde det möjligt för användare att gå i en stad i VR (Virtual Speech, 2020). Staden var Aspen i Colorado och den skapades genom att använda material fotograferat från en bil. Virtual Speech (2020) jämför detta program med Google Street View. Dock användes inte någon Head Mounted Display (förkortat HMD), alltså en VR-hjälm. År 1965 presenterade datavetaren Ivan Sutherland sin vision av den ultimata skärmen. Han tänkte sig en värld som sågs genom en HMD som skulle visa världen så pass verkligt att man inte kunde se skillnad på verkligheten eller den virtuella verkligheten (Sutherland, 1968). 1968 skapade Sutherland det första VR HMD som han gav namnetThe Sword of Damocles. Hjälmen var inte kopplad till någon kamera, utan till en dator som visade enkla virtuella bilder. Perspektivet ändrades dock då användaren flyttade på huvudet. Det var inte förrän år 2014, när Facebook köpte VR-företaget Oculus, som intresset för VR blev populärt hos hemanvändare. Samma år släppte företaget Samsung hjälmen Samsung Gear VR där användare monterar sin smarta telefon i hjälmen. Google släppte även deras motsvarighet, Cardboard, och Sony annonserade att de håller på att utveckla en VR-hjälm till sin spelkonsol Sony Playstation 4.
Det finns i nuläget hundratals företag som sysslar med VR-utveckling och möjligheterna inom tekniken är mycket stora enligt Virtual Speech (2020). Bara genom att gå i en virtuell värld så interagerar man som användare i VR. Interaktionen är dock mer utbrett än så, då det finns mängder av spel för VR där användare exempelvis kan ta upp och kasta föremål eller skjuta med vapen. I spel som stödjer multiplayer kan användarna även samarbeta och se varandra. Dessa spel stödjer även kommunikation mellan användare genom gester och talat
språk. Många företag använder tekniken i utbildningssyfte och det finns exempel på försök att bota psykiskt sjuka personer med hjälp av VR (Virtual Speech, 2020).
1.1 Bakgrund
Det finns många användningsområden inom VR-tekniken. Ursprungligen användes VR till bland annat militär träning (Nguyen, Tran & Le, 2017) men även flygsimulatorer som användes av NASA (Virtual Speech, 2020). VR har på senare tid blivit en plattform för underhållning såsom film och spel. VR-teknologin har också blivit billigare enligt VRS (2017) vilket har lett till att VR-industrin expanderat för privata konsumenter. Idag finns det ett stort antal olika headsets inom VR, såsom Oculus Rift, Oculus Go, Oculus Quest, Sony Playstation VR och HTC Vive (Virtual Reality, 2017).
Naturliga interaktioner är viktigt inom VR då teknologin skall efterlikna den verkliga världen. Detta menar Thorisson (u.å) är för att användaren skall känna sig delaktig i en annan verklighet. LaVelle skriver om interaktioner i VR och tar då upp effektivitet, komfort och svårigheter att lära sig nya tekniker (Lavelle 2019). Omnideck (Fig 1 och 2) är ett interaktivt golv med en diameter på 4.2 m där användaren kan röra sig 360 grader i den digitala VR-världen (Omnifinity, 2020). Golvet är uppbyggt av sexton stycken sektioner som detekterar var användaren fysiskt befinner sig på golvet genom sensorer i hjälmen.
Beroende på var användaren befinner sig på golvet snurrar den sektionen samt de närliggande sektionerna, vilket gör att användaren inte lämnar golvet. Det kan jämföras med ett löpband. Om användaren går sakta och är nära mitten i jämn gångfart snurrar sektionerna långsamt. Börjar användaren istället gå snabbare och rör sig längre ut på golvet snurrar sektionerna snabbare för att förhindra att användaren hamnar utanför golvets yttre gräns. I VR-världen rör sig avataren i samma hastighet som användaren rör sig på golvet. Omnideck gör att användaren känner sig mer delaktig och närvarande i den virtuella verkligheten.
Figur 1; Omnideck Figur 2; Omnideck med användare på golvet med VR-headset och handkontroller
1.2 Problemformulering
Pantelidis (2010) argumenterar för olika anledningar till att VR-teknik kan användas inom träning och utbildning, och bland annat har det visat sig skapa motivation att använda tekniken. VR uppmuntrar nämligen användaren till att aktivt interagera med objekt i den digitala miljön istället för att passivt vara delaktig i utbildningen. Pantelidis (2010) hävdar att det har givit bättre resultat i tester där VR-teknik användes i jämförelse med tester utförda i den fysiska världen.
Ghosh. et. al (2018) undersökte olika visuella notifikationsmodeller för att utröna vilken modell som användarna uppfattade som mest effektiv. Även i detta examensarbete har olika visuella notifikationer testats. Notifikationer i en VR-miljö hjälper användaren att navigera rätt i olika situationer. Det finns idag ingen standardiserad modell för notifikationer inom VR, och det finns ett antal modeller som fungerar olika bra i olika situationer. I examensarbetet testades två olika modeller för att undersöka vilken modell som är mest effektiv när det gäller träning inom en yrkesgrupp, specifikt inom brandkåren. Den ena modellen är en statisk skylt liknande den nödutgångsskylt som idag finns i offentliga byggnader. Den andra modellen är en visuell vägvisare som rör sig på golvet. Den visuella vägvisaren kan liknas vid pilar som rör sig på golvet i den riktning där nödutgången finns.
Det är viktigt att använda notifikationer då det är dessa som skall göra träningen mer effektiv och att då kunna överföra denna till verkligheten så att det även blir mer effektivt att utföra detta i ett verkligt akut scenario. Då det handlar om träning inför akuta situationer är det viktigt att till exempel en räddningsinsats vid brand skall gå så snabbt som möjligt för att så effektivt som möjligt kunna rädda så många personer det går.
1.3 Syfte
Det ena syftet med undersökningen är att testa olika notifikationsmodeller som skall hjälpa användaren att slutföra en uppgift i en virtuell verklighet. För att kunna testa dessa modeller skapades en prototyp. I prototypen skapades två olika notifikationsmodeller vilka testades för att undersöka vilken av dem som är mest effektiv i ett specifikt scenario. Scenariot för examensarbetet är utformat för brandkåren. Vidare är syftet att undersöka vilken teknik som utvecklare kan använda för att skapa en webbaserad applikation som samtidigt inte kräver någon dator med hög prestanda, vilket ofta krävs för VR-baserad mjukvara. Det andra syftet med undersökningen är att se om det går att använda applikationen oberoende av vilken plattform som används. Applikationen skall kunna användas av flera användare samtidigt då det handlar om utbildning inför akuta situationer vilket kräver att instruktör och användare deltar samtidigt.
1.4 Frågeställning
För att kunna underlätta tränings- och utbildningssessioner för till exempel brandkår, både tidsmässigt såväl som ekonomiskt, är det en fördel att dessa skall kunna utföras oberoende av var instruktör respektive användare befinner sig. Instruktörens roll i prototypen är att ge instruktioner och övervaka träningen. Användarens roll är att utföra en uppgift på snabbast möjliga tid då det handlar om akuta situationer. Det är alltså av intresse att resultatet av träningen skall bli så tidsmässigt effektiv som möjlig. Av dessa anledningar testats vilken sorts notifikation som är mest effektiv i ett scenario där det handlar om att utrymma en
rökfylld lokal. Två notifikationer testas; vilka är nödutgångsskyltar i taket (som idag finns på de flesta allmänna byggnader) samt en visuell vägvisare i golvet som visar vägen till nödutgången. Syftet med dessa var för att testa två modeller som finns i verkliga miljöer, då de finns representerade i allmänna lokaler. Den visuella vägvisaren har uppkommit under senare tid, men som främst fungerar som vägvisare till olika avdelningar i varuhus.
Skillnaden mellan dessa två modeller är att den ena är synlig i taket och den andra i golvet.
Det kan vara intressant att ta reda på vilken som är mest effektiv i det givna scenariot. I detta grundar sig frågeställningarna till examensarbetet.
■ RQ1
Med vilka tekniker kan man möjliggöra interaktion mellan instruktör och användare i en virtuell och webbaserad miljö där instruktör och användare inte befinner sig på samma fysiska plats?
■ RQ2
Vilken av de två visuella notifikationsmodeller som undersöks ger bäst resultat tidsmässigt i en webbaserad applikation i VR-miljö vars syfte är utbildning inom brandkår och där instruktör och användare inte befinner sig på samma fysiska plats?
1.5 Hypotes
Användare tar sig till målet snabbare med dynamiska visuella vägvisare än med statiska skyltar i en webbaserad VR-applikation.
1.6 Strategi för lösning
Prototypen i examensarbetet bestod av en applikation där instruktör och användare inte behövde befinna sig på samma fysiska plats. Olika VR-teknologier som stödjer webbaserade och enhetsoberoende undersöktes. Tillfredsställande prestanda undersöktes även för att kunna skapa applikationer inom området. Det undersöktes också vilka webbplatser som idag använder WebXR samt dess funktionalitet och existerande interaktioner. Det är avancerad1 teknologi att skapa multiplayer till VR och det är ytterligare en utmaning att bygga en applikation som inte är enhetsspecifik. Slutligen skall även styrningen justeras om så att det fungerar att använda Omnideck som plattform i applikationen. Detta krävs då Omnideck använder sig av ett eget API för styrning och är inte fullt ut implementerat för alla applikationer.
1.7 Avgränsningar
Med tanke på rådande pandemi i världen (se 4.5) har avgränsningarna itererats. Den ursprungliga tanken var att användartester skulle utföras på ett Omnideck med Omnifinitys kunder och samarbetspartners som testpersoner. Applikationen testades istället av ett antal personer genom en social applikation online där användaren delar sin skärm med ansvarig.
Omnideck kommer alltså inte användas som styrenhet, utan styrning kommer ske genom wasd-kontroller på en dators tangentbord. Resultatet hade kanske varit annorlunda om Omnideck hade använts i undersökningen (se. 6.1). Ingen hänsyn till tidigare erfarenhet av datorspel har tagits då testpersoner valts ut. Erfarenhet spelar mindre roll då det i undersökningen gäller att jämföra två notifikationsmodeller och det kan då vara intressant
1 Samlingsnamn för VR på webben
och se hur testpersoner med liten eller ingen tidigare erfarenhet av datorspel reagerar och för sig i dessa situationer. Testen kommer fokusera på den tidsåtgång det tar för en användare att med hjälp av notifikationer ta sig från en punkt till en annan.
2 Teori
För att få en bredare bild av vad som undersöks i examensarbetet har tidigare forskning inom ämnet utforskats. De artiklar som nedan presenteras är aktuella för examensarbetet.
Den söktjänst för artiklar som använts är Linnéuniversitetets söktjänst OneSearch. De nyckelord som har använts för att hitta relevanta artiklar är VR internet, VR collaboration, VR simulator training, virtual reality, gamification VR, virtual reality online collaborative, virtual reality education. Sökningarna gav allt mellan 500-300,000 träffar (tabell 1), men det var endast några få som var relevanta för just det här arbetet, så många artiklar sållades således bort. För att bestämma om en artikel var relevant lästes först titeln av arbetet. Om en artikels titel verkade relevant lästes arbetets abstrakt. Verkade innehållet relevant lästes arbetet i sin helhet och användes därefter som källa för påståenden och argumentation. För att ett arbete skulle ses som relevant var det vissa nyckelord som skulle finnas representerade, till exempel “training”, “VR”, “notifications”. Då VR är ett brett ämne användes metoden Semi Systematic Review. Enligt Snyder (2019) används metoden när det inte är möjligt att läsa alla artiklar inom ett ämne om det är för brett. Sett till antalet träffar var det inte möjligt ur ett tidsmässigt perspektiv att läsa samtliga artiklar. Semi Systematic Review kan vara användbar för att hitta vanliga frågor och problem inom ett visst ämne. I detta kapitel kommer även olika tekniker att presenteras för att ge en djupare förståelse för vad som kan användas och vad som används för utvecklingen av prototypen.
Sökord Träffar
VR internet 19,774
VR collaboration 19,371
VR simulator training 4,503
virtual reality 319,196
gamification VR 533
virtual reality online collaborative 29,638
virtual reality education 135,503
VR notification 1,966
VR interaction 113,113
Tabell 1; Visar antalet träffar för de sökord som användes för litteraturstudien
2.1 Litteraturstudie
Mas & Filliard (2018) har utvecklat “Indy” vilket är ett multiplayerspel i VR där användare har olika roller. En är “trainer” som ser en överblick över kartan i spelet och ger ”learner”
direktiv och uppdrag. “Learner” är en grupp som tillsammans ska lösa uppgiften. Spelet är en applikation som skall träna användarens kunskaper i navigation, i det här fallet ett kärnkraftverk. Kravet för användarna är att de alla befinner sig i samma rum. Användarna som skall utbildas i spelet använder HMD, head mounted display, och deras uppgift är att hitta ett visst objekt som finns någonstans på kartan. Den andra gruppen, “trainer”, har
tillgång till kartan i 360 grader och har därmed en översikt över hela området. De kan se var någonstans objektet som “learner” skall hitta finns någonstans och skall då kommunicera hur dessa skall navigera för att hitta objektet. Kommunikationen sker genom tal och att berätta vilka objekt som finns i närheten där “learners” befinner sig. Objekt inne i applikationen används för att på enklare sätt berätta för “trainer” var man befinner sig. Kan
“trainern” då se vilket objekt som är aktuellt är det enklare att förklara vägen till det slutgiltiga målet.
“Trainer” har en så kallad God View över kartan. God View är en vy där en användare, i detta fall en instruktör, kan se hela applikationen från ett fågelperspektiv. Man ser då hela applikationen samt har en god översikt över vad användarna gör och var de befinner sig på kartan. Det är tänkt att applikationen skall fungera i utbildningssyfte för att utbilda och träna yrkesgrupper för att kunna navigera i en specifik miljö. Andra vyer som är vanligt förekommande är first person view och third person view. First person view är en vy som visar vad karaktären i spelet ser med ögonen till skillnad från third person view där användaren ser karaktären i sin helhet snett bakifrån.
Vidare förklarar Mas & Filliard (2018) vad gamification är och hur det tillämpas i deras arbete. Enligt dem använder man spelelement i en kontext som egentligen inte är ett spel.
De använder gamification genom att användare skall hitta ett specifikt föremål på snabbast möjliga tid. Gamification kan även betyda att man fokuserar på underhållning för att effektivisera utbildning. Fokus för prototypen som utvecklats till det här examensarbetet handlar om att utbilda personal inom brandkår och då är inte underhållning det som fokus ska ligga på. Fokus hamnar istället på serious games som är mer allvarligt inriktat vilket är meningen för utbildning av brandkår inför akuta situationer.
Virtual Reality har blivit en enhet som privatpersoner kan ha hemma i underhållningssyfte.
Nguyen, Tran & Le (2017) tar upp historien bakom VR och dess tänkta områden som kan vara nyttiga. De hävdar att det finns fördelar bland annat inom militärträning, flygsimulering och medicinsk utbildning. I artikeln går författarna igenom några exempel på headsets och hävdar att den stora skillnaden är priset. Fram till år 2010 var det högst ovanligt att VR brukades av en hemanvändare, men då utvecklingen av teknologin gick framåt kunde producenter skapa billigare headsets som kunde köpas för bara några dollar. Dessa headsets används genom att sätta in en smartphone i glasögonen. På så sätt spreds VR-teknologin till privatpersoner för en relativt billig summa. Författarna tar även upp VR sickness; bieffekter som kan upplevas av användare. Dessa kan vara bland annat obehag, huvudvärk, illamående och desorientering. I många fall beror det på att användaren oftast sitter still när man använder VR. Användaren är alltså stationär i verkligheten medan man uppfattar det som att man förflyttar sig i den virtuella verkligheten. Detta kan gör att användaren upplever åksjuka. Anledningen att användare upplever illamående kan enligt LaVelle (2019) vara för att det är en mycket snabb rörelse av optiska bildrutor som många upplever jobbigt. Lavelle (2019) skriver vidare att VR kan ibland överösa användarens sinnen och hjärna vilket kan göra att användare känner sig trötta och illamående. Detta kan bero på att programvaran håller en låg-nivå eller att gränssnittet kräver att användaren måste använda mycket muskler för att klara en uppgift i programmet.
Pantelidis (2010) tar upp exempel på hur och vad VR kan användas till. Författaren visar exempel på VR kontra desktop eller verkligheten. Dessa exempel visar bland annat att
studenter får bättre resultat på uppgifter om metoden de använder är VR. Anledningen är att de blev mer motiverade att utföra en uppgift om de aktivt deltar i interaktionen än om de är passiva deltagare. Att använda VR-teknologi som plattform för utbildning och träning har enligt Pantelidis (2010) visat god effekt på 1980-talet. Redan på 60- och 70-talet utvecklades HMD av Wright-Patterson Air Force Base in Ohio för träning inom USA:s flygvapen. Träning med VR-teknik inför händelser som anses akuta har gett bra resultat.
Författaren listar fördelar med att använda VR inom utbildning och bland annat påstår Pantelidis (2010) att upplevelsen inte går att erhålla i någon annan form av utbildning.
Vidare påstår författaren att en anledning till att det blir bra resultat av VR inom utbildning är att användaren tycker det är spännande och utmanande att gå i en tredimensionell värld som upplevs som mer verklig än om det hade varit mer teoretiskt. Artikeln skrevs år 2010 och det har hänt mycket rent grafikmässigt inom VR under dessa år. Dock skriver Pantelidis att VR-tekniken gör så att användaren kommer väldigt nära objekten och att man då kan undersöka föremålen på nära håll, både uppifrån, nerifrån och från sidorna. En av situationerna som författaren skriver att man borde använda VR är där simulering används och där verklig träning är farligt, obekvämt, omöjligt eller svårt. Vidare skriver Pantelidis (2010) att man bör använda VR-teknologin som utbildningsplattform om det är svårt att samla ihop en grupp personer rent logistiskt både ur res- och kostnadsmässigt och där delad upplevelse i en delad miljö är viktigt.
Elqaddem (2019) hävdar samma sak som Pantelidis ovan; att VR inom utbildning ger bättre resultat. Elqaddems forskning har visat att användaren tränar upp sitt minne, och att denne tar bättre beslut om man inkluderar underhållningsfaktorer i utbildningssyfte. En förklaring som Elqaddem lägger fram är att det är färre symboler att behandla och att man då förstår vad som skall göras mer direkt än i verkligheten. I verkligheten är det fler intryck och händelser som kan störa. Vidare skriver Elqaddem att det är enklare att lära sig genom praktisk träning än att läsa instruktioner.
Även LaVelle (2019) nämner utbildning i boken Virtual Reality. Han hävdar att praktisk träning i VR lämpar sig naturligt, på grund av att färdigheter som tränats i en realistisk virtuell värld kan översättas till den verkliga världen. Användare känner sig speciellt motiverade att utföra träning i VR om den verkliga träningen hade utgjort någon hälsorisk, det vill säga att bli utsatt för fara vilket man gör om man till exempel tränar brandövning.
Både Elqaddems artikel och LaVelles bok bekräftar Pantelidis påstående att VR är effektivt som undervisningsmetod.
En artikel skriven av Ghosh et. al (2018) behandlar ett problem som handlar om notifikationer i en VR-miljö. Detta gjordes då det inte finns någon standard inom VR för notifikationer. Författarna till artikeln gjorde tester för att ta reda på vilken notifikationsmodell som var mest effektiv i en applikation där användarna hade en uppgift att utföra i en digital VR-miljö. Notifikationerna som testades var sådana som berättade om händelser utanför applikationen. Till exempel en notifikation som berättade om att användaren var nära att gå på ett föremål i den verkliga världen, såsom ett bord, eller en notifikation om ett inkommande samtal. Testpersonen fick då en visuell-, auditiv- och/eller haptisk notifikation. De gjorde även tester där notifikationerna kombinerades med varandra i par om två. En kombination mellan två eller flera notifikationer kallas Multi-Modal. Det som skiljer undersökningarna åt är att Ghosh et. al (2018) hade notifikationer om händelser
utanför applikationen. I examensarbetet kommer notifikationen att visas för att hjälpa användaren till målet då det handlar om träning i akut situation.
Chalil & Greenstein (2017) gjorde en undersökning för att mäta effektiviteten i samarbete i en tredimensionell värld för att se om det blev samma resultat som om man gjort testen i en fysisk miljö. De använde en webbaserad konferensapplikation där testpersonerna fick instruktioner och skulle sedan tänka högt, dvs göra uppgiften samtidigt som man talar högt om vad man gör. Testpersonerna fick uppgifter via voice-chat inne i applikationen av en instruktör som tog tiden på hur lång tid testpersonerna tog på sig för att slutföra uppgiften.
2.2 Tekniker
För att kunna utveckla en prototyp har olika tekniker undersökts för att se vilket som skulle passa just för det här examensarbetet. Kraven för att det skall gå att genomföra är att tekniken skall stödja enhetsoberoende och fler användare skall kunna vara inne i applikationen samtidigt. Applikationen är tänkt att användas för utbildning och då skall instruktör och användare använda applikationen samtidigt för att träningen skall gå att utföra på korrekt sätt. Tekniken skall vara webbaserad för att det inte skall krävas en dator med för hög prestanda och användare skall kunna kommunicera med varandra. Anledningen är att det ur ett logistiskt perspektiv skall vara smidigare att utbilda på distans, alltså att användare och instruktör inte behöver resa till en specifik plats. Utbildningen skall gå att genomföra oavsett fysisk position. Det är också effektivt ur ett kostnadsperspektiv då det är dyrt att resa och en dator med hög prestanda är relativt dyr. Det finns bibliotek som stödjer alla krav för arbetet och dessa bibliotek är även open source (se 2.2 Open Source). Dock skall ett krav även vara att det skall stödja VR.
● Open source
○ Att något är open source betyder att det är fritt för vem som helst att använda enlig opensource.org (2020). Källkoden i open source-projekt är öppen, alla kan alltså ta del av koden och använda den fritt utan att någon copyright skyddar den som skapat koden. Om koden inte är open source måste författaren till koden godkänna att någon använder koden.
● A-Frame
○ A-Frame är ett web-ramverk som skrivs med HTML där installation av mjukvara inte är nödvändigt (aframe.io, u.å). Det enda som behövs är att inkludera a-frame i head-taggen, sedan har man tillgång till alla de taggar som finns i a-frame-biblioteket. A-frame är speciellt framtaget för att skapa webbaserade VR-projekt. Från början utvecklades detta för Firefox men har på senare tid blivit tillgängligt för alla webbläsare. Ramverket stödjer de flesta headsets såsom Vive, Daydream, Rift och Oculus Go m fl. Man kan även använda ramverket för utveckling av Augmented Reality. A-frame stödjer även enhetsoberoende, det spelar alltså ingen roll om man har ett VR-headset eller inte, man kan som användare ta del av applikationerna som utvecklats även om man sitter med dator eller mobiltelefon. På grund av att ramverket stödjer alla krav som har satts för examensarbetet valdes a-frame som den utvecklingsteknik som då används för utvecklingen av prototypen.
Hittills har Omnifinity jobbat med Unity och Unreal Engine vid utveckling av applikationer till Omnideck. Med A-Frame behövs heller ingen dator med
hög prestanda för att det skall fungera, vilket ofta krävs om en VR-applikation är utvecklat i Unity eller Unreal Engine. Handledare på Omnifinity hade också undersökt A-Frame och funnit detta kompatibelt med deras API.
● HTML
○ En annan teknik som använts och som applikationen grundar sig på är HTML, Hyper Text Markup Language. A-Frame importeras in i ett HTML-dokument i dess head-tag med en länk som då ger tillgång till A-Framebiblioteket och dess möjligheter. Man skriver sedan in beskrivande HTML-taggar för varje objekt från A-Frame och dessa taggar ligger innanför de grundläggande HTML-taggar som måste finnas för att det skall fungera, det vill säga html och body. För att få applikationen dynamisk kan man även importera ett javascript-dokument eller skriva javascriptkod direkt i HTML-dokumentet i script-tag, för att på så vis till exempel kunna lägga till en animation på en A-frame-tag.
● Three.js
○ Three.js är ett javascript-bibliotek som stödjer visualisering av tredimensionell grafik på webben. Biblioteket kan användas för att till exempel bygga spel, modellera eller datavisualiseringar (Blue, u.å).
Biblioteket är enhetsoberoende och kan därför användas för att göra applikationer som kan användas oavsett vilken plattform användaren använder. Three.js kan användas som en webbaserad spelmotor men även till animationer och filmer. För att kunna använda detta bibliotek till examensarbetet måste det gå att implementera VR-funktion. Det finns stöd för detta men prestandan som krävs för att använda applikationer utvecklade med three.js ansågs vara för hög, därför valdes detta alternativ bort.
3 Prototypimplementation
En prototyp är bra att använda och visa för att upptäcka olika designval för intressenter (Preece, Rogers & Sharp, 2015). När man visar designval genom en prototyp uppmuntrar man till att reflektera kring aktuellt val. När man genomför tester av flera prototyper som alla ser olika ut kan man utläsa vilket designval som fungerar bäst i den situationen som produkten är tänkt att användas. Prototypens funktionalitet som testats är av typen High-Fidelity, vilket enligt Preece, Rogers & Sharp (2015) innebär att funktionalitet som är tänkt för den färdiga produkten finns representerad. Vidare kan man argumentera för att det visuella är av low-fidelity, då utseendet i prototypen inte är färdigt. Den färdiga applikationen kommer representera verkligheten bättre.
Implementeringen av prototypen har gjorts med HTML och A-Frame (se 2.2). Den prototyp som utvecklats liknar ett hus med väggar, tak och golv. Användaren skall ta sig från en punkt till en annan. Användaren startar på en sida av huset och skall med hjälp av en visuell notifikation ta sig från startpunkten till utgången, som visualiseras med en sfär som går upp och ner, Figur 3. Notifikationernas utseende varierar beroende på vilken version av prototypen man använder (se 4.2). Det gäller att lokalisera dessa notifikationer och läsa av dem för att kunna ta sig till utgången så snabbt som möjligt. Det är inte alla vägar som tar användaren till utgången, utan vissa håll är det stopp och hamnar användaren där måste han eller hon ta sig tillbaka för att välja en annan väg för att hitta ut. Huset och dess väggar kommer vara likadant planerade och utsatta för båda grupperna, annars hade resultatet blivit felaktigt vid analys av datainsamlingen .Ett liknande test utfördes avMas & Filliard (2018) där de även hade en övervakare som såg hela kartan. Där var även fler personer inblandade i samma prototyp, vilket också är tanken med den färdiga produkten efter vidareutveckling av prototypen i examensarbetet. Både Pantelidis (2010) och Mas & Filliard (2018) hävdar att gamification är mer effektiv vid inlärning. Detta tas till fasta i det här arbetet då det är genom gamification som testet genomförs. Dock kommer detta arbete inte jämföra verkligt test kontra gamification, utan två olika notifikationer inom gamification, varav den ena, nödutgångsskylten, Figur 4, är mer tagen från verkligheten än den andra, vägvisare i golvet, Figur 5. Den fullständiga prototypen sett rakt uppifrån syns i figur 6.
Figur 3; “Nödutgången” som användaren Figur 4; Prototyp med nödutgångsskyltar Figur 5; Prototyp med vägvisare i golvet skall hitta
Figur 6; Visar prototypen sett uppifrån. Testpersoner startar från längst ner i vänstra hörnet och målet är den röda bollen högst upp i högra hörnet. Bilden visar prototypen utan rök och med de visuella vägvisarna.
Notifikationerna har placerats ut på ett så naturligt sätt som möjligt så att ingen av modellerna skall bli favoriserade på något sätt. Tanken med pilarna som rör sig på golvet i den riktning nödutgången ligger är att de skall likna sådana pilar som blir upplysta från taket och redan finns i vissa stora företag. Dock skiljer sig dessa genom att de rör sig.
Utplaceringen av dessa täcker ett större område, men i och med att de rör sig kommer man inte kunna se dessa hela tiden, utan de har en cykel som loopas. De statiska nödutgångsskyltarna är utplacerade på ett så verkligt sätt som möjligt. Det har inte gjorts någon direkt undersökning speciellt för examensarbetet angående dessa nödutgångsskyltar.
Prototypen är uppbyggd baserad på iakttaganden under besök av allmänna byggnader och platser som har dessa skyltar uppsatta. Dessa skyltar kan ses som allmänt vedertagna då de är vanligt förekommande på offentliga platser. Skyltarna är placerade i taket och pekar åt den riktning som nödutgången finns. Prototypen simulerar verklig träning där den i verkligheten är farlig, därför är det en god idé att använda VR (Pantelidis, 2010). Det är farligt att träna i riktig rök, så att träna i VR och på ett Omnideck där användaren rör sig fritt gör att det blir mer verkligt. I och med att prototypen kommer vara webbaserad kommer inte några kostnader för resor att finnas. Pantelidis (2010) hävdar att man bör använda VR-teknologin som utbildningsplattform om det är svårt att samla ihop en grupp personer rent logistiskt både ur res- och kostnadsmässigt och där delad upplevelse i en delad miljö är viktigt. Detta är aktuellt ur båda dessa aspekter då det är mer kostnadseffektivt att samlas över webben och tränas därigenom. På så sätt kan fler samlas i samma applikation och det behövs ingen stor lokal där alla skall få plats. Ghosh et. al (2018) skrev i sin artikel om problem med notifikationer utanför VR-världen när någon har en VR-hjälm på sig. De ville
se vilken notifikation som var mest effektiv för användaren att få reda på om de var på väg att gå in i något verkligt föremål. Detta är en aktuell artikel för arbetet som här har utförts i och med att användarna i applikationen har fått en uppgift av instruktören som de sedan har utfört. Uppgiften bestod som sagt av att gå till ett ställe på kartan där något intressant finns att utforska och då kan det vara intressant att veta vilken notifikation som är den mest tidseffektiva för användaren då applikationen är tänkt att användas till träning av yrkesgrupper inom blåljus. Skillnaden i examensarbetets prototyp är att notifikationerna är hjälpmedel inne i VR-världen, men det finns ingen standardiserad notifikationsmodell för detta heller. Tanken från början var att använda sig av voice-chat inne i prototypen, när användartester genomfördes på Omnideck, men i rådande situation (se 4.5) så ändrades detta. Chalil & Greenstein (2017) gjorde en undersökning som handlade om hur effektivt det var med voice-chat i VR-miljö. Dock används inte voice-chat för prototypen i examensarbetet då användartester genomfördes med testpersonernas dator hemma.
Undersökningen är dock relevant för en eventuell vidareutveckling av examensarbetet då det är tänkt att instruktör och användare inte kommer befinna sig på samma fysiska plats utan kommunikation mellan användare och instruktör kommer ske via voice-chat online.
Instruktörens roll är att iaktta vad användaren gör och att ge introducerande instruktioner om vad användaren skall göra under testet.
4 Metod
Från början skulle detta arbete fokusera mycket på att flera användare skulle vara i applikationen samtidigt. Dock ändrades fokus i och med den rådande pandemin i världen (se 4.5).
För att kunna samla in data som sedan kan användas för att iterera en produkts utveckling finns olika metoder. Olika metoder får fram olika data och det är upp till den ansvariga för testen att hitta den lämpligaste metoden. Enligt Robson & McCartan (2016, s.241) väljs den eller de metoder som skall användas baserat på vilken information man vill få ut av datainsamlingen och från vem och under vilka omständigheter. Vidare beskriver Robson &
McCartan (2016, s.242) olika metoder som är tillgängliga baserat på vilken data som skall samlas in. En av metoderna som kommer användas för examensarbetet är direct observations (Robson & McCartan, 2016, s.320) där användaren beskriver via tal vad han eller hon gör och känner för en viss del i testet. Den andra metoden som kommer användas är intervju där testpersonen efter genomfört användartest får svara på frågor angående applikationen personen precis testat (se kapitel 4.4). Testpersoner kommer delas upp i två grupper där tiderna jämförs med varandra för att se vilken grupp som klarade uppgiften på snabbast tid. Detta kallas för en between-group design, vilket betyder att två grupper testar olika variabler (Nielsen Norman Group, 2020). En grupp fick visuell hjälp i form av en vägvisare på golvet som rör sig i den riktning som föremålet som skall hittas finns. Den andra gruppen har fått hjälp av statiska nödutgångsskyltar som pekar åt nödutgången som skall hittas. Instruktörens roll är att ge introducerande instruktioner om vad användaren skall göra under testet och iaktta vad användaren gör.
4.1 Metodbeskrivning
För att kunna mäta resultatet av undersökningen har användartester genomförts (se 4.2). De innefattar 20 st totalt, uppdelat i två grupper om 10 st i vardera grupp. De test som har utförts är Post-test-only two treatment comparison. Detta betyder att användare är indelade i två olika grupper där var och en av grupperna skall testa varsin variant av prototypen och sedan jämförs dessa tester med varandra för att få fram ett resultat (Robson & McCartan 2016, s.122). Den oberoende variabel som skiljer dessa två versioner åt är det hjälpmedel i form av vägvisare som finns att tillgå. I den ena versionen är det nödutgångsskyltar och i den andra versionen är det vägvisare på golvet som rör sig i rätt riktning. Denna variabel är det enda som skiljer de två versionerna åt. Användartester har genomförts med hjälp av den prototyp som utvecklats för examensarbetet. Prototypen fungerar som ett verktyg som testpersonerna testar notifikationerna i, en notifikation per grupp. Efter genomfört användartest har testpersonerna fått svara på frågor i en semistrukturerad intervju som enligt Backman, Gardelli.T, Gardelli. V & Persson (2012, s.308) är intervjuer som har några förutbestämda frågor men där intervjuaren kan anpassa ordningen beroende på vad respondenten har svarat på föregående fråga och där respondentens svar tillåts vara mer fria och längre än i en strukturerad intervju. Enligt Robson & McCartan (2016, s.286) är intervjuer ett bra sätt att direkt få information från användare vad de tycker och tänker om något. Vidare skriver de att en semistrukturerad intervju ger intervjuaren frihet att utifrån bestämda frågor även ställa följdfrågor för att få ut mer data än vad man tänkte från början.
En sådan intervju kan enligt författarna vara av varierande sort, både fullt strukturerad eller helt ge intervjuaren stor frihet i frågor, likt en ostrukturerad intervju. Mortensen (2017) hävdar att semistrukturerade intervjuer är speciellt användbara när det kommer till insikter i
val av design. Examensarbetet kommer att undersöka valet av notifikationer och vilken design av dessa som kan ge ett för syftet bra resultat. Vidare skriver Mortensen (2017) att intervjuer ofta är ett komplement till användartester och experiment för att få en kvalitativ data som kompletterar den insamlade kvantitativa datan. Dock finns det vissa brister med intervjuer. Till exempel är det tidskrävande enligt Robson & McCartan (2016, s.286). Datan som samlas in vid intervjuer är kvalitativ data som enligt Backman., Gardelli.T, Gardelli. V
& Persson (2012, s.298) är sådan data som förklarar hur något är eller vilka egenskaper som den testade produkten har.
4.2 Användartest
Testen har inte genomförts så som det från början var tänkt (se 1.7). Tanken var att testpersonerna skulle genomföra användartesterna med hjälp av Omnideck och instruktören skall vara på en annan plats, till exempel ett kontor som inte är i anslutning till VR-rummet där Omnideck är beläget. Istället för Omnideck har användartester genomförts via dator på annan plats. Testpersonerna genomför testen samtidigt som de använder sig av metoden
“thinking aloud”, vilket enligt Nielsen (2012) är att man som testperson skall tala om vad man gör och vad han eller hon tycker om användargränssnittet; eller i detta fall applikationen som skall testas. Robson & McCartan (2016, s.364) skriver att “thinking aloud” är populärt under utvärderingar av mjukvara eftersom det resulterar i direkt feedback och som inte är kostsam. Datan som samlats in via användartester är en mätning av tiden som ett test har tagit och är därmed kvantitativ, som enligt Backman., Gardelli.T, Gardelli.
V & Persson (2012, s.297) är data som är mätbart och som representeras i siffror. Datan från medlemmarna av båda grupperna jämförs med varandra och utifrån dessa jämförelser visar resultatet vilken grupp som lyckades bäst på testen. En nackdel med användartest, eller experiment, är att det kan förekomma olika sorters bias. Det finns framförallt två att ha i åtanke när man som testare genomför användartest. Dessa är enligt Robson & McCartan (2016, s.114) demand characteristics och expectancy effects. Demand characteristics innebär att testpersonen är medveten om att det är ett experiment och genomför då testet annorlunda gentemot vad denne hade gjort i en verklig situation. Ett exempel är när testpersonen skall välja mellan två alternativ. Även om de blivit tillsagda att det inte finns något rätt eller fel kan testpersonen välja det alternativ som gör att denne framställs bättre.
Expectancy effects kan inträffa när testpersonen får sina instruktioner från den ansvariga för experimentet. För att minimera risken för detta kan man enligt Robson & McCartan (2016, s.115) använda färdiginspelade instruktioner som spelas upp för testpersonen innan testet börjar. I syfte att eliminera dessa risker med bias har testpersonerna fått instruktioner skickade till sig innan testet startar. Instruktören har därefter endast övervakat testpersonens skärm utan vidare instruktioner samt utan att hjälpa till under testets gång. På så sätt har risken för ovan beskrivna expectancy effects minimerats.
4.3 Scenario
Testpersonerna delades upp i två grupper, 10 st per grupp. En grupp testade en version av prototypen med vägvisare på golvet, kallad Pathfinder (se Bilaga C). Vägvisaren rörde sig i den riktning där målet fanns. Den andra gruppen testade en version av prototypen med nödutgångsskyltar, kallad Exitsign (se Bilaga D). Dessa skyltar hängde i taket och en pil i skylten visade åt vilket håll användaren skulle gå för att hitta nödutgången. Båda gruppernas versioner innehöll samma karta och det enda som skiljde versionerna åt är alltså de olika
notifikationerna. För att simulera att testet skulle bli så verkligt som möjligt fick testpersonerna en scenariobeskrivning innan testet började. Detta för att personerna skall göra sitt bästa och för att applikationen i framtiden kommer vända sig till yrkesgrupper inom blåljus. Scenariot är främst riktat till brandkårspersonal.
Följande text lästes av testpersonen:
Du jobbar inom brandkåren och har fått ett larm om brand med kraftig rökutveckling. När du kommer till byggnaden märker du att röken har spridit sig i hela våningen och hör hur någon ropar på hjälp på längst bort på andra sidan av kontorslandskapet. På vägen dit lägger du inte till minnes vilken väg du tagit för att hjälpa personen i nöd. När du kommer fram till personen tar du upp denne i dina armar och börjar sedan leta efter nödutgången. Nu gäller det att på snabbast möjliga tid ta dig ut från huset för att rädda både dig själv och personen du har i famnen. Följ indikatorerna/notifikationerna som visas för att hitta nödutgången.
Nödutgången är i det här fallet indikerat med en röd sfär som rör sig upp och ner. Du måste ta dig förbi sfären för att komma ut.
Använd tangentbordets knappar för att röra på dig:
W = Framåt A = Vänster S = Bakåt D = Höger
Håll ner vänstra musknappen för att röra på “huvudet” för att hitta notifikationer som visar utgångens riktning. Du rör dig även i den riktning som huvudet pekar åt.
Testpersonerna fick prova kontrollerna innan testet startade för att introducera hur man styr och tittar runt. Anledningen är att personer som inte är vana vid att använda wasd-kontroller skall veta hur navigationen i prototypen går till, samt för att resultatet skall bli så verkligt som möjligt. Introduktionstestet till styrning är inte prototypen som testades i användartesterna, utan en icke rökfylld lokal med endast fyra väggar (Figur 7). Det som också fanns i kontrolltestets prototyp är “nödutgången” som symboliserades genom en röd sfär som förflyttas upp och ner. Denna fanns där för att testpersonerna skulle veta hur den såg ut och vad man skall leta efter när själva användartestet sedan startade. När testpersonerna kände sig redo att starta testet skickades en ny länk som ledde till det verkliga användartestet. Tiden startade när testpersonen började röra sig i prototypen och stannade sedan när testpersonen tog sig förbi den röda sfären, “nödutgången”.
Figur 7; Den tutorial-prototyp som används för att användaren skall lära känna styrning och veta vad personen skall leta efter, dvs nödutgången som i prototypen är den röda sfären
4.4 Intervju
För att få reda på vad testpersonerna tyckte om prototypens design och känsla genomfördes semistrukturerade intervjuer efter varje användartest. Intervjuerna skedde i direkt anslutning till testerna för att upplevelsen efter testet skulle vara färskt i minnet. Samtliga intervjuer skulle från början ha genomförts på plats i Videum, men under rådande situation skedde dessa över en chat-tjänst online där testperson fick frågorna genom chat-tjänstens röstchatt-funktion. Intervjufrågorna skulle finna svar på var hur användarna upplevde själva applikationen och rökeffekten, men primärt hur de upplevde de olika visuella notifikationsmodellerna (se 6) .
■ Intervjufrågor
Följande frågor ställdes för respondenten efter genomfört användartest. Efter varje fråga ställdes eventuella följdfrågor för att ta reda på mer information (se Bilaga A).
1. Hur upplevdes applikationen?
2. Hur tog du reda på hur du skulle ta dig ut?
3. Hur upplevde du notifikationen?
4.5 Beträffande Coronaviruset SARS-CoV-2
Med anledning av den rådande situation världen befinner sig i under tiden som examensarbetet pågår, coronaviruset SARS-CoV-2, har användartester inte kunnat utföras som ursprungligen var tänkt via Omnideck. Anledningen är att företag i största möjliga mån kommer arbeta hemifrån för att minska spridningen av viruset. Därför beslutade handledaren på Omnifinity att Omnideck inte var tillgängligt för användartest av prototypen.
I samråd med handledaren på universitetet och handledaren på Omnifinity har det därför beslutats att användartest kommer ske online från en laptop/stationär dator med wasd-kontroller. Styrning skedde genom tryck på knapparna w, a, s och d på tangentbordet
och med mus/musplatta. Prototypen testades dock på samma sätt som ursprungligen var tänkt; att man som användare skulle ta sig från startpunkten till nödutgången utifrån ett givet scenario. Ett problem som kan uppstå under användartester online är att ansvarig inte kan se vad användaren gör. För att på bästa sätt kunna kontrollera vad som sker på skärmen ombads testpersonen att dela sin skärm och använda mikrofonen för att på så sätt kunna praktisera thinking aloud-metoden och visa ansvarig det resultat som uppnåddes under testet. Testerna genomfördes via tjänsterna Skype och Zoom. Ursprungligen var tanken att testa prototypen i en kollaborativ miljö, men med tanke på pandemin beslutades det att byta spår och endast testa notifikationerna.
4.6 Genomförande
För att kunna genomföra användartester via prototypen måste det finnas testpersoner som testar prototypen. Dessa personer tillfrågades om de ville vara med och genomföra tester på en applikation. Testpersonerna bestod av människor med olika bakgrund gällande dataspelserfarenhet. Deras ålder varierade också; den yngsta var vid testtillfället 22 år och den äldsta var 48 år. Totalt tillfrågades 20 st och samtliga tackade ja. Testprogrammet är skapat i två versioner (se 3) och grupperna blev tilldelade varsin version, vilket testpersonerna inte visste om i början av testet. När en testperson tilldelades en version var det helt slumpmässigt; varannan blev tilldelad en version och varannan testperson den andra versionen.
För att testen skulle kunna genomföras krävdes det att testpersonen hade tillgång till dator med Skype, Messenger, Zoom eller liknande där testpersonen kan dela skärmen med testansvarig. Valet av vilket program som användes för kommunikation mellan ansvarig och testperson hade ingen inverkan på resultatet i användartester. Det program som användes för var och ett av testen valdes huruvida varje testperson hade något konto eller ej i de nämnda programmen. Ett krav för programmet var dock att testpersonen delade sin skärm så den ansvariga skulle kunna övervaka hur testpersonen genomförde testet genom och att det gick rätt till. Körschemat var enligt följande:
1. Testperson ringdes upp i en chattjänst, till exempel Skype eller Messenger.
2. Testpersonen blev tillbedd att dela skärmen
3. Testansvarig skickade en scenariobeskrivning som läses av testperson
4. Testansvarig skickade en länk till ett tutorialprogram där testperson kunde testa styrning med tangenterna och mus/pekplatta.
5. Testansvarig skickade en länk till prototypen där testet genomfördes.
6. Testansvarig startar tiden när testpersonen börjar röra sig i prototypen
7. Testansvarig för anteckningar under tiden testpersonen tänker högt och utför uppgiften.
8. Testansvarig stoppar tiden när testpersonen når målet.
9. Testansvarig genomför en intervju med testpersonen angående prototypen.
Det första som gjordes efter att testpersonen hade ringts upp var att en scenariobeskrivning med tillhörande instruktioner (se 4.3) angående styrning skickades i ett chattprogram.
Texten lästes av testpersonen själv för att minimera risken för bias (se 4.2). När texten lästs igenom tillfrågades testpersonen om han eller hon förstått vad det går ut på och om det var
några vidare frågor angående instruktioner eller scenariot. Nästa steg var att skicka en länk till en tutorial där testpersonen fick testa styrningen med tangenterna och musen alternativt pekplattan på laptopen om mus saknades (se Bilaga B). I tutorialen syntes även den röda sfären som skall föreställa nödutgången som testpersonen ska hitta. När testpersonen kände sig redo att genomföra testet skickades en till länk som gick till själva testprogrammet.
Testpersonen blev här tillfrågad att försöka tänka högt för att testansvarig skulle få veta hur testpersonen resonerar kring händelser i prototypen.
När testpersonen började gå eller röra på huvudet i prototypen startade testansvarig tiden.
Figur 8 visar hur det kunde se ut under ett test.
Figur 8; Visar hur det såg ut när ett test genomfördes. På bilden syns Exitsign-versionen. Testpersonen har delat sin skärm och testansvarig ser då vad testpersonen gör. Test ansvarig tar också tiden för att mäta hur lång tid varje test tar
Under testet förde testansvarig anteckningar över hur testpersonen rörde sig och agerade i prototypen. Detta gjordes för att samla in data i syfte att kunna vidareutveckla applikationen i ett senare skede. Testansvarig gav inte några ledtrådar under testet, utan testpersonen fick hela tiden lösa uppgiften själv. När testpersonen nådde målet, det vill säga nödutgången som visualiseras i form av en röd sfär, stoppades tiden och testet var avslutat.
Efter genomfört test ställdes några frågor i en efterföljande intervju (se 4.4 och 5.2).
Beroende på hur testpersonen svarade på frågorna ställdes eventuella följdfrågor, alternativt besvarades frågan tillfredsställande och därmed var vissa grundfrågor eller följdfrågor överflödiga, då det hade blivit samma svar flera gånger. Första testet som genomfördes spelades in av testansvarig, både ljud och bild, men då ljudinspelningen knappt blev hörbar och bildinspelningen blev felaktig valde ansvarig att endast övervaka de följande testen och föra anteckningar på vad testpersonen gjorde. Intervjuerna antecknades av testansvarig under tiden som testpersonen svarade på frågorna. När testansvarig hade fått svar på de frågor som var viktiga för datainsamlingen tackades testpersonen för sin medverkan och samtalet avslutades.
5 Resultat
Efter undersökning av tekniker och under utvecklingsarbetet av prototypen har det framkommit ett resultat som har visat att det går att använda Omnideck som plattform för en webbaserad applikation, se figur 9. Det har visat sig att A-frame, som är tekniken som används för applikationen, stödjer enhetsoberoende. Den enhet som används för Omnideck är HTC Vive och det finns i ramverket implementationer som gör att HTC Vive går att använda som kontroll. Det som dock måste göras manuellt är att konfigurera kontrollerna med Steams användargränssnitt. Detta har undersökts och resultatet visar att det går att genomföra och att Omnideck då kan användas som enhet för applikationen.
Figur 9; Screenshot när prototypen används på ett Omnideck med VR-headset och handkontroller
För att svara på den andra frågan för examensarbetet samlades data in med hjälp av användartester på en prototyp. Efter varje test genomfördes en intervju för att ta reda på vad testpersonerna tyckte om de designval som fanns i prototypen. Resultatet av användartester och intervjuer presenteras nedan.
5.1 Användartest
Datan som här har samlats in består av den tid det tog för varje testperson att genomföra uppgiften. Tiden startades när testpersonen började röra på sig inne i prototypen och stoppades när testpersonen nådde fram till nödutgången. Den data som samlades in visade att det var gruppen som testade versionen med visuell vägvisare, vidare nämnd som Pathfinder (se Bilaga C), som fick bäst resultat. Pathfinder fick en medeltid på 2 min 34 sek (Tabell 2) jämfört med gruppen som testade versionen med en statisk skylt, vidare nämnd som Exitsign (se Bilaga D), som hjälpmedel som fick medeltiden 5 min 8 sek. Diagrammet i figur 10 visualiserar de olika medeltiderna som uppmätts för de två olika versioner av prototypen som testats och även den sammanlagda medeltiderna för alla test som genomförts. Figur 11 visar varje test uppdelat i de två olika versioner som testats. De blåa prickarna i spridningsdiagrammet visar tider för den Pathfinder och de röda prickarna visar tider för versionen med Exitsign, som visar vägen till nödutgången. Varje test i de båda
grupperna har rangordnats beroende på vilken tid varje testperson genomförde testet på.
Från vänster till höger i diagrammet är varje test rangordnat från den kortaste tiden till den längsta tiden det tog för varje testperson att genomföra uppgiften.
Version av prototypen Medeltid (tt:mm:ss) Standard deviation
Pathfinder 00:02:34 00:01:40
Exitsign 00:05:08 00:04:52
Tabell 2; Medeltid för testpersoner i de olika versioner av prototypen, även den totala för båda versionerna
Figur 10; Medeltid för testpersoner av prototypens båda versioner Figur 11; Visar varje tests tid.
Vidare sammanställdes diagram baserat på hur mycket spelerfarenhet var och en av testpersonerna har. Anledningen till att inkludera detta i undersökningen trots att det inte är någon forskningsfråga var för att se om spelerfarenhet påverkar resultatet i användartestet.
Om datainsamlingen hade gått till såsom det var tänkt från början hade spelerfarenhet inte inkluderats. Eftersom wasd-tangenter är ett klassiskt kontrollschema för dataspel och används i användartesterna ansågs spelerfarenheten relevant. Då prototypen som testats i examensarbetet är en typ av spel kan även erfarenhet av tv- och dataspel ha betydelse för hur lång tid testet tar att genomföra. Spelerfarenhet delades upp i tre kategorier, “Ingen”,
“Måttlig” och “Mycket”. Denna data samlades in under introduktionen av prototypen. Datan presenteras i tabell 3.
Version Spelerfarenhet Antal Medeltid (mm:ss)
Pathfinder Ingen 2 04.58
Måttlig 3 02.39
Mycket 5 01.32
Exitsign Ingen 4 12.48
Måttlig 0 Ingen data
Mycket 6 02.29
Tabell 3; Visar testpersoner uppdelade i sina testgrupper och vilken tidigare spelerfarenhet testpersonerna hade vid tillfället för testet.
Tabellen visar antal testpersoner med ingen, måttlig och mycket spelerfarenhet och medeltiden beroende på spelerfarenhet
Medeltiden för testpersoner med ingen spelerfarenhet i gruppen Pathfinder blev 4 min och 48 sek och i gruppen Exitsign 12 min och 48 sek. Medeltiden för de testpersoner med ingen spelerfarenhet totalt för båda grupperna blev 8 min och 16 sek. För de testpersoner med måttlig spelerfarenhet blev medeltiden 2 min 39 sek. I och med att det inte var någon med måttlig spelerfarenhet i gruppen Exitsign så blev medeltiden totalt densamma som i gruppen Pathfinder. Medeltiden för de testpersoner med mycket spelerfarenhet blev i gruppen Pathfinder 1 min och 32 sek, Exitsign 2 min och 29 sek och den totala medeltiden för samtliga med mycket spelerfarenhet blev 1 min och 45 sek.
5.2 Intervju
Efter genomfört användartest utfördes intervjuer på de 20 st som testat prototypen. Dessa delades upp i två grupper på 10 testpersoner per grupp. Intervjuerna som genomfördes var av semistrukturerad modell, därför skiljer sig vissa frågor från person till person. Dock så finns det ett par grundfrågor som ställdes till samtliga. Tanken med frågorna som ställdes var att ta reda på hur testpersonerna upplevde de olika designval som skapats i prototypen.
Svaren är tänkt att ligga till grund för nästa iteration av prototypen som är tänkt att vidareutvecklas. Frågorna som var viktiga att få svar på är följande:
1. Hur upplevdes applikationen?
2. Hur tog du reda på hur du skulle ta dig ut?
3. Hur upplevde du notifikationen?
Resultatet av dessa sammanställdes i diagrammen nedan.
Figur 12; Diagrammen visar det antal som är positiva, negativa eller neutrala till de designval som gjorts i prototypen
Svaren på frågorna har kategoriserats som negativ, neutral och positiv. De som var negativa till de olika designval hade negativa saker att säga om dessa, till exempel att det var svårt att hitta ut med hjälp av notifikationerna. De som var positiva till de designval som implementerats hade positiva saker att säga om prototypen som till exempel att
notifikationerna hjälpte de på ett bra sätt och att det var lätt att styra. De som kategoriserats som neutrala hade varken något positivt eller negativt att säga om designvalen. Figur 12 visar hur många som var positiva till prototypen generellt. Av 20 st respondenter tyckte 13 st att applikationen var allmänt bra utan några negativa eller neutrala kommentarer. Bland de positiva kommentarerna så var det bland annat styrning, stämning och att det verkade verkligt som var vanligast. 4 st hade varken något positivt eller negativt att säga om den och 3 st hade vissa negativa åsikter om prototypen. Figur 12 visar också hur många som var positiva, negativa eller neutrala angående effekten som skall likna rök i prototypen. Där tyckte 14 st att röken tillför något positivt till prototypen medan 4 st var neutrala. 2 st tyckte den var ett störningsmoment som gjorde det svårare att se och därmed försvårar uppgiften.
Det var dock testpersoner som var positiva till röken som tyckte att det försvårar uppgiften och att man inte ser så mycket, men det tyckte dessa personer var bra då det tillför något till prototypen som gör att det blir verkligare. Frågan som ställdes angående hur testpersonerna upplevde de två olika notifikationerna, Pathfinder och Exitsign, så var det överhängande positiva åsikter om båda två. 8 av de 10 st som testade versionen med Pathfinder fann notifikationen som ett bra hjälpmedel, medan 1 inte riktigt förstod vad den var till för. 10%
tyckte varken positivt eller negativt. 7 av de 10 st som testade Exitsign-versionen var positivt inställda till notifikationen. 3 var neutrala, och ingen var direkt negativt inställd till Exitsign. Samtlig data som samlats in från intervjuer är tänkt att användas som feedback för vidareutveckling av prototypen.
