Användargränssnitt

Figurerna 11 till 16 nedan representerar prototypen i studiens sista iteration inklusive en av planscherna med QR-kod.

För att beskriva spelet är digital tipsrunda en bra liknelse. En digital tipsrunda i kombination med ett moment som låter spelaren gissa en stad och få en visuell karta som visar hur långt spelaren har gått beroende på antal steg. Stegen samlades in via stegräknare.

Spelaren startade genom att trycka på start-knappen (Figur 12) efter det att spelet laddats. Därefter i figur 13 kunde spelaren välja ett tema som spelaren önskade att frågorna på tipsrundan skulle innehålla. Efter valt tema valdes svårighetsgrad och spelet var igång.

27 Spelaren fick en uppmaning om att gå ut i korridoren och leta efter planscher med QR-koder. Se exempel på en av dessa planscher i figur 11. Spelaren skannade en QR-kod genom kameran på sin surfplatta (Figur 14) och därefter visades en fråga på liknande sett som i figur 15. Därefter upprepades skanningsmomentet. När spelet upptäckte att spelaren hade gått ett visst antal steg låstes en ny stad upp och spelaren kunde gissa vilken denna stad var. Detta visas i figur 16. Efter detta uppdaterades kartan på startsidan (Figur 12).

28 Figur 12: Bilden ovan är på startsidan som visades när spelet laddat in all nödvändig data. Spelarens stegdata visades till vänster och aktuell stad spelaren kommit till på kartan i mitten av bilden.

Figur 13: Bilden ovan visar sidan där spelaren kunde välja tema för frågorna. Denna sida visades vid tryck på “Starta” knappen på startsidan, dvs figur 12. Spelaren valde ett tema och fick sedan upp en ruta för att visa svårighetsgrad. Den blå knappen till höger har aktiverades av spelaren för att ge hjälp.

29 Figur 14: Bilden ovan visades när spelaren valt tema och svårighetsgrad i figur 13 eller tryckt “Promenera vidare” -knappen i figur 15. Rutan i mitten visade enhetens kamera och användes för att skanna en QR-kod.

Figur 15: Bilden ovan visar en fråga som anropades efter skannad QR-kod i figur 14. Bilden visar frågans bild i mitten till vänster och svarsalternativen till höger. I denna bild har spelaren svarat “Ansikte” vilket var felaktigt, det korrekta svaret visas med grönt.

30 Figur 9: Bilden ovan visar funktionen för att gissa stad. Denna funktion var tillgänglig när ett visst antal steg uppnåtts. Spelaren tryckte på knapparna innehållande bokstäver till vänster för att gissa ordet på den streckade linjen till höger.

3.2 Arkitektur

Prototypen var en webbapplikation med klient- och serverlösning för att stödja plattformsoberoende samt ha möjligheten att uppdatera innehåll för alla användare effektivt. Klienten anropar endpoints på serversidan som via ett REST-API behandlade anropet och returnerade. Beroende på anropet och dess parametrar returnerades en Blade-fil (Otwell, 2017a) eller ren JSON data (Json.org, n.d.). Blade är en variant på HTML med samma stöd vad gäller skript till exempelvis Javascript och CSS. Skillnaden är att Blade har stöd för enklare filreferenser samt möjligheten att dynamiskt skicka med PHP variabler knutet till variabelnamn i Blade-filen. I de fall en Blade-fil returnerades skickades PHP variabler med för att minska antalet anrop från klient till server. Datan i dessa PHP variabler var av okänslig typ, exempelvis stegdata eller en av frågorna i databasen. Blade-filen refererade sedan till CSS och Javascript filer för att skapa samt utföra klientens styling och logik.

REST-APIet byggdes i Lumen vilket är ett PHP-ramverk för REST-API (Otwell, 2017b). Detta API kördes via ett webbhotell som innehöll en MariaDB databas (MariaDB, 2017). Databasen bestod av tabeller innehållande spelets olika teman och frågor samt autentiserings- nycklar till Fitbits API. Ett diagram över systemets kommunikation visas i figur 17.

31 Figur 17: Diagram över kommunikation mellan klienten, servern med REST-API:et och databasen.

Fitbit (Fitbit, 2017) är företaget som tillverkade stegräknaren som användes i studien. Anledningen till att Fitbits produkt valdes var då de tillhandahåller ett fritt API för registrerade utvecklare. För att visa antalet steg inuti spelet hämtade servern mängden steg genom ett anrop till Fitbits API, se figur 11 för ett diagram över denna kommunikation. För att göra detta krävdes autentisering av klienten via Oauth2 (Oauth.net. n.d.). Oauth2 är ett säkerhetsprotokoll som Fitbits API kräver för att möjliggöra kommunikationen. Kraven för denna kommunikation var att en autensieringsnyckel skulle skickas med. Denna var aktiv i åtta timmar, därefter behövdes nyckeln uppdateras vilket gjordes med en uppdateringsnyckel. Vid anrop om uppdatering fick användaren ny autentiseringsnyckel samt uppdateringsnyckel. Hela processen krävde ett Fitbit-konto som var knutet till en stegräknare. Om det var första gången spelet används på en enhet fick användaren logga in med sitt Fitbit-konto på deras hemsida och sedan lagrades användarnamnet i datorns webbläsare. Detta användarnamn användes sedan för att kommunicera med databasen för att kommunicera med Fitbits API samt uppdatera kontots nycklar. Se figur 18 för diagram över kommunikationen mellan Fitbit och webbapplikationen.

Klient

Databas

1. Klienten anropar endpoint i REST-API 2. Servern anropar databasen 3. Databasen returnerar svaret på anropet från servern.

4. Servern returnerar svaret från databasen. Beroende på klientens anrop returneras resultatet som JSON eller som variabel i Blade-fil tillsammans med HTML samt CSS och Javascript referenser.

32 Figur 18: Diagram över kommunikation mellan klient, server/REST-API, databas samt Fitbits API. Denna kommunikation beskriver hur klienten tar emot stegräknarens data.