Utveckling av ett lärospel för att skapa hög användbarhet till förskolebarn

Linköpings universitet/Linköping University | Institutionen för datavetenskap (IDA) Kandidatuppsats, 16 hp|Innovativ Programmering Vårterminen 2020 |_​LIU-IDA/LITH-EX-G--20/041--SE

Utveckling av ett lärospel för att skapa hög

användbarhet till förskolebarn

Victor Ekström

Marcus Jakobsson

Handledare, Anders Fröberg Examinator, Erik Berglund

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum

under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt

bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av

upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet

kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns

lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed

kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller

presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller

konstnärliga anseende eller egenart.

För

ytterligare

information

om

Linköping

University

Electronic

Press

se

förlagets

hemsida

http://www.ep.liu.se/

_​.

Utveckling av ett lärospel för att skapa hög användbarhet

till förskolebarn

Marcus Jakobsson

Linköpings Universitet

Linköping, Sverige

marja843@student.liu.se

Victor Ekström

Linköpings Universitet

Linköping, Sverige

vicek160@student.liu.se

I detta arbete utvecklas ett spel för utlärning av programmeringskoncept till förskolebarn. Spelet utvecklas agilt som ett delspel i lärospelet “Magiska Trädgården”. Resultatet av det utvecklade spelet är ett spel där ett bi ska flyga i en loop för att plocka upp ett antal bär, detta ska medföra förståelse av loopar som programmeringskoncept. Spelets användbarhet utvärderades av experter i en heuristisk studie med hjälp av 8 erkända användbarhetsprinciper [4].

Utvärderingen av spelet visar att det enligt experternas åsikt uppfyller de utvalda användbarhetsprinciperna. Dessutom utvärderades det av experterna som meningsfullt i utbildningssyfte.

INTRODUKTION

Att lära ut digital kompetens är en del av förskolans läroplan [7], i eftersträvan om detta utvecklas i den här artikeln ett delspel som ska introducera programmeringskoncept till förskolebarn.

Teknologi används allt mer för att utöka lärande av kompetenser såsom matematik, språk och programmering till små barn. Meyer [9] nämner att lärospel blir mer och mer populära för att lära ut engelska och han gör en analys på den marknaden. Zidianakis et al [10] gör en preliminär undersökning på skapandet av ett interaktivt aktivitetsbord som heter Beantable som ska använda sig av “smart games” för att hjälpa barns utveckling.

Moreno-Ger et al [13] nämner att ett fokus för “e-learning” är att utveckla pedagogiska funktioner som ska motverka frustration och öka studentens motivation för att fortsätta studera. En av dessa funktioner är användarfeedback. Eftersom målgruppen för detta spelet är förskolebarn, så fokuserar detta arbete på att designa spelet så att de kan få bra feedback även utan förmågan att läsa, genom att använda bra färgval, händelser, röster och bilder istället för text.

Det är viktigt att tidigt under utvecklingen testa användbarheten av en produkt, så att man iterativt kan förbättra den. Detta kan dock vara svårt när målgruppen för ens produkt är förskolebarn då de inte kan kommunicera väl än. När det är opraktiskt att direkt interagera med sin målgrupp så kan man istället använda sig av en heuristisk

utvärdering, där man frågar en eller fler experter inom området och dessa experter använder sig av erkända användbarhetsprinciper, "heuristics", för att utvärdera produkten. Detta skulle spara tid för utvärderingen då det inte behövs arrangeras testpersoner eller en observatör som annars hade behövts, då barnen troligen inte kan läsa eller skriva väl än vilket är ganska viktigt om man ska fylla ut en enkät själv.

En heuristisk utvärdering kan tillåta oss att jobba snabbare och testa oftare och enklare, då man inte behöver sätta upp en komplicerad studie varje gång man ska testa något. Dock eftersom en heuristisk studie använder sig av experter istället för den faktiska målgruppen, så beror kvaliteten av studien på hur väl uttänkta användbarhetsprinciperna är och erfarenheten av experterna.

Syfte

Vi har fått ett uppdrag av Agneta Gulz som är en del av forskningsgruppen Cognition and Interaction Lab (COIN). Uppdraget är att skapa ett delspel till lärospelet “Magiska Trädgården”, för att introducera programmeringskoncept till förskolebarn. Delspelet som ska implementeras är baserat på studien av Jin et al [1] där de skapade prototyper för delspel som ska lära ut programmeringskoncept.

Vi har valt att använda oss av en heuristisk utvärdering för utveckling och utvärdering av detta lärospel, då det kommer vara mindre tidskrävande än en direkt utvärdering på barn, samt kommer tillåta oss att testa oftare och snabbare. Frågeställning

Hur ska ett delspel för introduktion till programmering i lärospelet Den Magiska Trädgården utvecklas för att ha hög användbarhet.

Implementering

Arbetet kommer använda sig av samma tekniker som Magiska Trädgården är uppbyggd av, detta består av JavaScript, Phaser, Meteor, MongoDB och Node.js. BAKGRUND

För att göra en bra heuristisk utvärdering behöver man experter inom området för att validera att produkten uppfyller användbarhetsprinciperna. Experterna för detta arbete är en del av forskningsgruppen COIN som är experter inom kognitionsvetenskap, och har erfarenhet inom

området av att lära barn med hjälp av spel. Experterna är specifikt från The Educational Technology Group som är1 en grupp som består av forskare, doktorander och masterstudenter från Linköpings och Lunds universitet. Agneta Gulz som är vår uppdragsgivare är en del av denna forskningsgrupp.

Spelet vi kommer fortsätta jobba på “Magiska Trädgården” är ett projekt från COIN . Detta lärospel innehåller2 aktiviteter för att lära ut matematik till förskolebarn. Spelet är ett webbspel som är uppbyggt av JavaScript, Phaser, Meteor, MongoDB och Node.js.

Delspelet som ska implementeras är baserat på en tidigare studie, gjord av Jin et al [1]. I denna studie har de tagit fram och utvärderat 3 prototyper för olika delspel vars syfte är att introducera simpla programmeringskoncept till förskolebarn.

Den mest lovande prototypen de testade var “Loopspelet”. Spelplanen består av blommor och ett antal av dessa blommor har en eller flera jordgubbar. Målet är att rita en väg från en korg och mellan blommorna så att biet besöker alla blommor med jordgubbar och sedan tillbaka till korgen. Efter det får spelaren välja hur många varv biet ska flyga för att plocka upp alla bär, problemet är dock att biet bara kan bära en jordgubbe i taget. Målet är att få barnen att tänka iterativt och även få ett koncept för hur loopar fungerar.

Det andra är “Saftspelet”. Spelplanen består av ett antal bägare med saft längst upp som hälls ner i ett antal rör som leder ner i ett antal koppar. Eleven har ett antal val av rördelar som de kan placera ut för att leda saften till rätt kopp. Det tidigare arbetet gav inga exempel på vad det här spelet ska introducera för programmeringskoncept.

Det sista är “Tårtspelet” där spelaren ska baka en tårta efter ett recept, där måste spelaren lägga ut ingredienserna i rätt ordning, för att bygga upp tårtan från botten och uppåt. Målet med detta delspel är att introducera exekveringsordning och algoritmer.

TEORI

Eftersom målgruppen är förskolebarn så måste delspelet som ska utvecklas använda sig av abstraktioner för att representera vad en knapp kan tänkas göra istället för text. Enligt Chiu et al [8] för att öka igenkänning av ikoner så ska man undvika orealistiska designer av ikoner. De upptäckte att barnen inte kände igen en ikon av en tv på grund av att den hade antenner, men så fort de tog bort den 1 https://www.ida.liu.se/divisions/hcs/coin/Research/EduTech .shtml 2 https://www.ida.liu.se/divisions/hcs/coin/studentprojects.sht ml

detaljen så ökade igenkänningen. Sedan ska man också undvika abstraktioner som barnen troligen inte har någon erfarenhet av som t.ex. tar Chiu et al [8] upp hur en triangel ofta representerar att spela eller köra något.

Jämfört med vuxna så har barn relativt omogna exekutiva funktioner samt ett mindre utvecklat korttidsminne [8]. Detta måste man designa efter när man gör ikoner för barn då de lätt blir distraherade. Därför ska man göra det uppenbart för barnen vad som är klickbart på skärmen. Att skapa bra instruktioner är en utmaning då man inte kan veta förmågorna hos användaren i förtid. Fisher [14] har skrivit om hur man ska designa instruktioner i ett spel till barn. Hon skriver att när man designar instruktioner till ett spel inriktat mot barn ska man anta att barnet aldrig har spelat ett spel förut. Hon skriver också att instruktioner borde repeteras efter en stund av inaktivitet från användaren. Det kan även vara att barnet redan vet hur man kör spelet och då ska det vara simpelt att skippa instruktionerna för att inte förlorar barnets uppmärksamhet. Studien utförd av Celis et al [12] tar fram ett antal principer som kan följas för att hålla ett barns uppmärksamhet, till exempel så har de kommit fram till en tabell av sex olika sätt att hålla barnen motiverade att spela.

1. Tävlingsinriktning 2. Utmaning 3. Social interaktion 4. Avledning 5. Fantasi 6. Spännande

För att utvärdera användbarheten av ett spel kan man använda sig av en heuristisk utvärdering. En heuristisk utvärdering är när experter använder sig av användbarhetsprinciper för att utvärdera. Ett exempel på användbarhetsprinciper tas upp i en studie utförd av Tondello et al [3] där de tar fram 28 principer som experter kan använda sig av för att utvärdera spel.

Desurvire et al [4] har funnit att en heuristisk utvärdering är ett bra sätt att tidigt i utvecklingen hitta användbarhetsproblem. De använde sig av tidigare forskning för att hitta användbarhetsprinciper som de sedan gav till en “playability evaluator” och till spelutvecklarna för att hitta användbarhetsproblem. Sedan gjorde de en traditionell användarstudie med testpersoner. Resultatet var att de hittade fler användbarhetsproblem med den heuristiska studien än den traditionella studien.

METOD

Då målet med vårt delspel är att lära ut så fokuserar vår speldesign på att ge bra feedback till eleven. Det ska omedelbart vara tydligt när eleven gör något fel, delspelet kommer att ha en maskot som ska säga till när eleven gör fel och även ge tips för att lösa spelet. Maskoten ska också

ge feedback genom att säga något när eleven gör bra ifrån sig. Enligt Tärning [6] kan man undvika att eleven bara testar sig fram genom att ha en maskot som blir mer och mer irriterad när eleven bara snabbt testar sig fram. Eftersom det här delspelet är riktat mot förskolebarn så är det viktigt att delspelet använder sig av färger och symboler istället för text. Detta är viktigt då förskolebarnen troligen har begränsade läskunskaper. Smith [5] visar att man kan använda sig av symboler för att lära ut programmeringskoncept samt ger insikt i hur barn tolkar symboler.

Spelet kommer att utvecklas agilt efter Guerilla Programming som beskrivits i “Best Practices for User Experience on Agile Development Projects” [2]. Guerilla Programming tillåter oss att göra snabba implementeringar och förändringar mellan tester, samt få snabb feedback på dessa förändringar. Anledningen att vi kör Guerilla Programming istället för någon scrum metod, är för att vi bara är två personer i projektet, så det skulle vara överflödigt att ha en scrum-master. Vi kommer jobba i korta sprints och sedan utföra en utvärdering på det vi gjort och iterera våra delspel baserat på feedbacken.

Efter en sprint så används en heuristisk utvärdering. Vi kommer ge experterna på COIN ett antal användbarhetsprinciper för att utvärdera vårt arbete. Användbarhetprinciperna som används är tagna från en studie utförd av Desurvire et al [4].

1. Provide immediate feedback for user actions. 2. The Player experiences the user interface as

consistent (in control, color, typography, and dialog design) but the game play is varied. 3. Upon initially turning the game on the Player has

enough information to get started to play.

4. Players should be given context sensitive help while playing so that they do not get stuck or have to rely on a manual.

5. Sounds from the game provide meaningful feedback or stir a particular emotion.

6. Players do not need to use a manual to play game. 7. The interface should be as non-intrusive to the

Player as possible.

8. Get the player involved quickly and easily with tutorials and/or progressive or adjustable difficulty levels.

Vi valde att vidareutveckla Loopspelsprototypen från det tidigare arbetet [1]. Vår implementation heter “Bispelet” då maskoten är ett bi. Loopspelsprototypen valdes då den enligt vår åsikt har mest potential för att introducera programmeringskoncept, samt hade den också lagts mest fokus på i det tidigare arbetet.

Figur 1. Vår rendition av det tidigare arbete [1]

Figur 2. Rutnäts-koncept

Spelet handlar om att leda biet mellan blommorna fram till bären och tillbaka till korgen igen. Eftersom spelet inte tillåt spelaren att besöka samma blomma mer än en gång så tvingade detta spelaren att göra en loop för att ta sig tillbaka. Sedan fick spelaren välja hur många varv biet skulle åka för att plocka upp alla bär. Detta introducerar loopar till spelaren och även ett exempel på en cykel, som båda används i programmering.

RESULTAT

Iteration 1

Vi började vårt arbete med att kolla på det tidigare arbetets prototyp (figur 1). För att kolla vad vi ville vidareutveckla och ändra på. Vi tyckte att det skulle vara svårt att generera varierande banor som liknade deras prototyp.

Vi valde då att delspelet istället skulle ha ett datorgenererat rutnät bestående av buskar, jordgubbar och stenar(figur 2). Sedan fungerar vårt delspel som prototypen och låter spelaren välja en väg genom buskarna. I rutnätet får spelaren leda biet ett steg i taget, buske till buske. Spelaren får välja steg vågrätt och lodrätt. När en korrekt väg har ritats, så kommer en ruta upp, där man får välja hur många gånger biet ska flyga för att hämta alla bär. Sedan flyger biet runt banan så många gånger som man valde, och hämtar ett bär per flygtur, om man valde för många eller för få varv så får spelaren börja om från början på en ny bana. För att kunna generera intressanta banor så krävdes det något som tvingar spelaren att behöva ta olika vägar varje gång och lösa varje bana på olika sätt. Detta löses genom att slumpmässigt placera ut blockerande stenar på olika delar av kartan, samt placera jordgubbarna på ett slumpmässigt ställe inom vissa restriktioner (stenarna genereras aldrig längst bort på spelplanen, och bären genereras aldrig närmast korgen).

Figur 3. Exempel av en vald väg

Dock ledde detta till att delspelet kunde generera banor som inte kunde lösas. Så vi var tvungna att implementera en sökvägsalgoritm som ska se till att alla banor är lösbara. Eftersom delspelet inte tillät spelaren att besöka samma buske fler än en gång var det möjligt för spelaren att välja en väg som gjorde det omöjligt att lösa banan. För att delspelet ska kunna upptäcka att spelaren har gjort banan olösbar så användes samma sökvägalgoritm som förut. När detta händer så planerade vi från början att backa tillbaka spelaren till ett steg där banan gick att lösa. Vi bestämde oss istället för att först vänta tills barnen blev helt fast innan delspelet backade tillbaka dem till ett lösbart läge, så att barnen förstår vad som gick fel och varför de blev tillbaka backade.

För att hjälpa barnet att se vägen de har valt har det lagts till pilar och alla buskar som spelaren tidigare har besökt har gjorts till en mörkare färg (figur 3). Alla buskar som spelaren kan nå från deras nuvarande position är färgad med en ljusare färg. Detta gjordes så att det ska vara intuitivt för spelare vad de kan klicka på.

Vår ban-genererings algoritm är baserad på en svårighetsgrad som man kan välja innan man startar spelet. Svårighetsgraden bestämmer hur många stenar som kommer placeras och hur stor banan blir.

Feedback 1

Vid det här stadiet var det dags för ett första möte med våra experter på COIN för testning och feedback. På grund av covid-19 gick det inte att ordna ett fysiskt möte, och vi var inte förberedda att hosta vår kod över nätet eller fixa fjärrstyrning. På grund av det så kunde experterna inte själva testa vårt koncept, utan vi skärmdelade en demonstration. Vi valde också att inte ge våra experter användbarhetsprinciperna, då det hade varit svårt för dem att ge specifika åsikter om dem när de inte själva kunde testa delspelet. Experterna kunde fortfarande ge generell feedback på konceptet.

De var imponerade med hur delspelet hade vidareutvecklats från originalprototypen, och tyckte att vårt koncept var bättre i och med att det på ett mer meningsfullt sätt visade

Figur 4. En svårare bana med exempel på lösning konceptet av loopar och det framgick tydligare varför man ska flyga i en loop. Fram tills nu hade delspelet designats för en desktop, men experterna informera oss om att spelet troligen skulle köras på en surfplatta med touch. Detta betyder att vi måste designa om vår spelinteraktion för det. Delspelet hade till exempel fram tills nu lagt till en upplysnings effekt när man höll musen över en buske som man kunde åka till, men det fungerar ju inte med pekskärm. Dessutom så var man tvungen att klicka på varje buske, och kunde inte bara dra en väg genom dem, som man skulle förvänta sig kunna göra med pekskärm.

Vi fick också feedback om hur delspelet ska hjälpa barnen, experterna tyckte att barnen fick för mycket hjälp med att sökvägsalgoritmen backade barnen till ett lösbart läge. De tyckte att delspelet istället bara skulle ge spelarna själva ett sätt att backa manuellt på, samt låta dem lista ut själva när det behövs. Det var dessutom viktigt att konsekvenserna för att välja fel mängd bär resulterade i att man får börja om från början på ett logiskt sätt. Det ska finnas någon anledning till att man måste börja om, till exempel att biet åker vilse, eller kanske råkar krascha in i korgen om man flyger för många varv.

De ville att vi skulle vidareutveckla loopkonceptet genom att öka antalet olika bär man måste plocka upp baserat på svårighetsgraden. Med flera olika bärsorter som alla måste plockas upp i olika mängd (figur 4). Efter att man ritat ut en korrekt väg, ska spelaren få välja hur många de ska plocka upp av varje olika bärsort. Detta ska på ett abstraherat sätt demonstrera en mer komplex loop där man måste åstadkomma flera olika uppgifter.

Iteration 2

Vi la till fler olika bär typer, så att det kan finnas många bärbuskar som man behöver flyga mellan på varje bana (figur 4). Under generering av banan såg vi dessutom till att mängden bär som genereras på varje bärbuske minskar korrelerat med hur många olika bärsorter det finns på banan, detta för att biet inte ska behöva flyga alltför många varv, så att barnet inte tappar intresse.

Figur 5. Svårighetsgrad ökning 1-3

Delpelet startar nu med att generera banor med 3x3 storlekar och placerar ut en sorts bär. Svårighetsgrad anpassas till hur väl eller dåligt spelaren klarar sig. Efter att vi la till flera sorters bär, la vi också till en smidigare svårighetskurva (figur 5). Om spelaren gör bra ifrån sig läggs det först till ett nytt bär och stenar placeras så att det bara finns en möjlig väg att gå, detta görs för att tvinga spelaren att plocka upp båda bären så att spelaren förstår att man måste göra det. Om spelaren gör bra ifrån sig igen så ökas storleken på banan till 4x4. Nu introducerar spelet spelaren till att banan kommer öka i storlek och nu kan spelaren även gå fel. Spelet fortsätter sedan att lägga till bärsorter, placera ut fler stenar och öka storleken på banan. Under denna iteration upptäckte vi också att vår sökvägsalgoritm var dålig. Det var en djupet först algoritm som sorterade noderna på så sätt att den alltid försökte gå mot sitt mål, istället för i en slumpmässig riktning. Detta gjorde den mycket snabb då det fanns en möjlig lösning på banan, då den oftast hittade lösningen på första försöket. Dock så upptäcktes det senare att den var extremt långsamt när banan inte gick att lösa, eftersom den då var tvungen att testa alla möjliga vägar. Detta innebär i princip alla möjliga kombinationer av noder i alla möjliga ordningar fram till bäret och tillbaka till korgen innan den upptäcker att det inte finns en väg. Detta gick för långsamt, särskilt eftersom att hela poängen med sökvägsalgoritmen var att upptäcka olösliga banor, och generera en ny bana om nödvändigt. Vi bytte då strategi med utplaceringen av stenar och använde vår sökvägsalgoritm till att hitta en väg fram till bäret och gjorde så att stenar inte kunde placeras över vägen. På detta sätt fanns det alltid en väg. Vi upptäckte dock att våra banor blev väldigt lika varandra då vår sökvägsalgoritm alltid hittade den kortaste vägen. Detta var inte heller bra, då en av användbarhetsprinciperna vi följer handlar om just variation.

För att öka variationen gjordes det så att stenar igen kunde placeras överallt på banan och vi förbättrade vår sökvägsalgoritm istället. Det blev en bredden först algoritm som gör en sökning fram till varje delmål, och skapar en väg som består av de kortaste vägarna mellan varje delmål. Den var mycket snabbare på att upptäcka om det inte finns en lösning på en bana. På detta sätt kunde delspelet ha mer variation med utplaceringen av bär och stenar och fortfarande ha ett snabbt sätt att testa ifall banan är möjlig.

Figur 6. Flera olika bär och knappar för antal varv Denna algoritm har dock lite negativa sidor, specifikt så kan den ibland missa lösningar på vissa banor, eftersom vägarna den genererar ibland kan blockera vissa noder som hade behövts för att lösa banan. Detta är inte ett särskilt stort problem dock, då det går snabbt att generera nya banor, mycket snabbare än att gå igenom alla möjliga vägar för att var säker på att det inte finns en lösning. Dessutom har vi gjort algoritmen smart så att den alltid försöker ta delmålen i en sådan ordning att den väldigt sällan blockerar sig själv. Delspelet har dock ett möjligt problem med generering av banor i sin helhet. Eftersom det genereras en ny bana om sökvägalgoritmen kommer fram till att den är omöjlig, så är det möjligt fast osannolik att fastna i en evig generation av omöjliga banor. Detta ska inte skapa några problem för genomförandet av användbarhetstestning på spelet, men behövs fixas innan en slutgiltig version av spelet.

För att kunna ge feedback och instruktioner till spelaren så har spelet fått både ljudeffekter och röstklipp som förklarar vad som ska göras och vad som händer i spelet. Biet som är våran maskot för detta spel är den som säger röstklippen. När man startar spelet första gången så förklarar biet sitt uppdrag att hämta bär, och att man måste få honom att flyga i en cirkel då han bara kan bära ett bär åt gången. Biet säger “Hej, jag ska hjälpa mina vänner att samla bär till ett kalas! Jag är tyvärr lite närsynt, så jag behöver din hjälp att leda mig till bären och tillbaka till min korg.”

Efter att spelaren har ritat ut en korrekt väg, så kommer det upp knappar där spelaren ska välja hur många av olika bär som ska plockas upp (figur 6), och röst klippet “Nu behöver jag hjälp, kan du berätta för mig hur många varv jag ska flyga för att få alla bär? Jag kan bara ta ett bär åt gången.” Som förklarar vad som ska göras.

Biet reagerar också med röstklippet “ett bär!” När han plockar upp bär, och han säger “nu flyger jag” när han flyger från korgen.

Om spelaren väljer för många varv för ett slags bär så kraschar biet i korgen och kör ljudklippet “oj jag crashade, nu måste jag testa igen” som förklarar att spelaren nu måste börja om från början då alla bär ramlade ut ur korgen. Om spelaren istället väljer för få varv för ett slags bär så säger biet “oj, det ser ut som att det blev för lite bär, vi får nog ta en korg till”.

Det ska ju också finnas feedback när spelaren har gjort bra ifrån sig, så när rätt antal varv för varje bär har valts så säger biet ”bra jobbat att plocka upp alla bär, nu går vi och ser om vi kan hitta lite till” vilket förklarar för spelaren att de har gjort rätt.

Under iteration 2 ändrades interaktionen med spelet så att den skulle vara mer anpassad för pekskärmar, nu markeras buskarna som spelaren kan gå till, istället för de vi håller över. Det fungerar nu även att både trycka på buskarna eller dra en väg genom dem.

Till sist skrotade vi vår ide att använda sökvägsalgoritmen för att hjälpa barn när de fastnar, och la istället till ett sätt att manuellt backa på, som experterna ville.

Feedback 2

Vid andra feedback tillfället med våra experter på COIN så var vi mer förberedda att utföra testning över internet, då vi hostade vår version av “Magiska Trädgården” över nätet. Den här gången kunde experterna själva köra spelet och skärmdela för att låta oss observera dem istället för tvärtom som under första feedback tillfället. Vi gav dem också våra användbarhetsprinciper, så att de kunde ge oss en full heuristisk utvärdering.

1. Provide immediate feedback for user actions. Experterna tyckte att användbarhetsprincip 1 uppfylls. Spelaren fick omedelbart feedback när de valde en väg genom buskarna. Valda buskar fick en mörkare färg och det ritades ut en pil så att det syntes vilken väg de hade valt. Spelet använde sig av röst klipp och en del animationer för att ge spelaren feedback om vad som ska göras just nu, ge feedback om vad som gick fel och vad som gjordes rätt.

2. The Player experiences the user interface as consistent, but the gameplay is varied.

För användbarhetsprincip 2 så tyckte experterna att den uppfylls för målgruppen. Färgerna och knapparna var konsekventa med resten av spelet. Experterna sa också att spelet var varierat nog för förskolebarn.

3. Upon initially turning the game on the Player has enough information to get started to play.

Experterna tyckte inte att användbarhetsprincip 3 uppfylls helt, så de gav oss förbättringsförslag för att vårt delspel bättre ska uppfylla den.

Under introt till delspelet så berättas det för spelaren att målet är att leda biet genom buskarna för att plocka bär och sedan tillbaka till korgen. Experterna sa att det kommer vara oklart för ett förskolebarn att man måste leda biet genom alla buskar som har bär och inte bara några av dem. Så det borde göras mer klart under introt. Vi fick även förslaget att när delspelet introducerar ett slags bär till som spelaren ska plocka upp så borde bi maskoten säga åt spelaren att de måste plocka upp det nya slags bäret också.

4. Players should be given context sensitive help

while playing so that they do not get stuck or

have to rely on a manual.

Delspelet uppfyllde inte alls användbarhetprincip 4. Just nu ifall spelaren kör fast så att det inte finns några buskar kvar att hoppa till så händer ingenting. Experterna gav oss förslaget att leda spelarens uppmärksamhet till de knappar som finns för att ångra senaste steget i den väg de har valt och för att ta bort hela vägen de har valt. Bi maskoten borde nämna knapparna och knapparna borde lysa upp för att fånga spelarens uppmärksamhet när de kör fast.

5. Sounds from the game provide meaningful feedback or stir a particular emotion.

Användbarhetsprincip 5 uppfyllde vi, dock eftersom våra ljudeffekter likt våra texturer bara är temporära. så evalueras här inte själva ljudeffekterna, utan istället hur de används, när de används, och vad deras generella mening är. Experterna tyckte att de fungerade bra för att förklara för spelaren vad som ska göras och informera om vad som händer.

6. Players do not need to use a manual to play the

game.

Användbarhetsprincip 6 uppfylls nästan. När experterna först testade spelet så började de på en medelsvår nivå, och fick därför en bana med ett antal olika möjliga vägar samt två olika bär att plocka. Under emulering av barn, förstod de då inte att man var tvungen att plocka upp alla bär, inte bara det som ser enklast ut. I det läget så uppfyllde vårt spel inte denna användbarhetsprincip.

Efter detta så startade experterna istället på den enklaste svårighetsgraden och fick arbeta sig genom vår inlärningskurva. Då de bara var tvungna att plocka upp ett bär, och det bara fanns en möjlig väg att gå, så förstod de den banan direkt, och löste den snabbt. När banan blev korrekt löst så genererades nästa bana i högre svårighetsgrad, där fanns det nu två bär, men fortfarande bara en möjlig väg att gå. Genom att lösa den, och se hur biet plockade upp från båda bär-buskarna, så förstod

testaren att man var tvungen att fånga alla bär. När experterna efter detta kom till samma svårare bana som de tidigare haft problem med, så förstod de nu hur denna skulle lösas.

För att uppfylla användbarhetsprincip 6 helt, behöver delspelet förklara för spelaren hur man använder ångra och bakåt knapparna när man fastnar

7. The interface should be as non-intrusive to the

Player as possible.

Användbarhetsprincip 7 uppfylls då experterna inte tyckte att något stod ut eller var i vägen för spelaren. Det är dock viktigt att påpeka att våra exakta texturer och utseenden för knapparna inte kommer att användas i den slutgiltiga versionen av spelet, så här utvärderas endast placering av knappar, ideén bakom knapparna och generell interaktion mellan spelaren och spelet

8. Get the player involved quickly and easily with tutorials and/or progressive or adjustable difficulty levels.

Användbarhetsprincip 8 uppfylls då vårt inlärningssystem för nya spelare fungerar, de enklare nivåerna fungerar som en introduktion och förklaring av spelet, och varje gång man gör rätt, så ökar svårighetsgraden.

Allt som allt tyckte experterna att spelet var på rätt väg, och fungerade bra. Som förslag till ett element till för att öka och minska svårighetsgraden så ville de att det skulle läggas till fler sätt att representera bären. Som t.ex. att det skulle finnas både bild och nummer för att representera antal bär som har valts. Sedan efter att svårighetsgraden har ökats kanske man tar bort bildrepresentationen helt och bara använder siffer-representationer.

Iteration 3

Iteration 3 var vår sista iteration för projektet, här fokuserarde vi på att finslipa och lägga till allt som krävdes för att uppfylla de användbarhetsprinciper som inte uppfylldes under iteration 2. De principer delspelet måste uppfylla är 3, 4 och 6. För att uppfylla dessa la vi till fler röstklipp, ett som förklarar för spelaren hur man använder bakåt knapparna när de fastnar, och en som förklarar att man måste hämta alla bär varje gång delspelet la till ett nytt bär på kartan.

Vi har dessutom förbättrat våra instruktioner genom att se till att de inte körs varje gång man börjar på en ny bana, utan bara första gången något nytt händer, eller när spelaren behöver hjälp av någon anledning, såsom att han fastnar eller klickar på hjälp knappen.

Delspelet har fram tills nu bara använt bär för att representera antal varv spelaren har valt för ett specifikt bär. Det har nu lagts till så att siffror också används (figur 7). Detta är gjort så att delspelet ska kunna gradvis lära barnen

Figur 7. Lätt till svår representation

att använda siffror istället för symboler för att representera tal. På lättare svårighetsgrader är det bara antalet bär som ändras när spelaren väljer antal varv, sedan används siffror också och tillsist används bara siffror för att representera antalet varv. Detta är gjort för att göra vårt delspel mer konsekvent med resten av delspelen i “Magiska Trädgården” som använder fingrar, punkter, streck och siffror för att representera tal.

På experternas förfrågan hade vi också planerat att implementera ett system där biet säger hur många varv han ska flyga på varje bana, men när vi väl började implementera detta så kom det upp lite frågetecken för oss. Eftersom man i nuvarande läge kan välja att plocka 1-5 av varje bärtyp, och det kan finnas upp till fyra bärtyper på varje bana, så betyder det att biet skulle behöva kunna räkna hela vägen upp till 20, och vi vet inte om barn i den här åldern förstår så höga siffror. Vi bestämde oss för att vänta med detta, och istället ta upp det med experterna på vårt nästa feedback möte.

Knapparna och interaktionen mellan spelet och spelaren har finslipats. Vi låser och gömmer knappar när spelaren inte har någon anledning att använda dem, samt när dem inte borde få använda dem, detta för att göra det enklare för spelaren att förstå vad som ska göras vid olika tillfällen. Till exempel när man har ritat en väg och knapparna för antal varv kommer upp, så gömmer delspelet både ångra och reset knapparna, när biet flyger göms alla knappar, samt medan biet pratar låser vi alla knappar. Detta ska se till att spelaren inte blir förvirrad av alla knappar han har tillgång till.

Feedback 3

Under Feedback 2 så hade vi tre användbarhetsprinciper som delspelet inte uppfyllde. Vi fokuserade främst på att just få dem validerade av våra experter. Det största problemet vi försökte lösa under iteration 3 var att vi inte gav tillräckligt mycket information till spelaren för att kunna spela spelet helt utan extern hjälp.

Under tredje feedback mötet gav vi igen experterna våra användbarhetsprinciper för validering. De som var speciellt intressanta för oss var användbarhetsprincip 3, 4 och 6, då det var dessa som vi inte uppfyllde under andra iterationens feedbackmöte.

3. Upon initially turning the game on the Player has enough information to get started to play. Experterna tycker nu att vi ger tillräckligt med information under introt för att uppfylla användbarhetsprincip 3.

4. Players should be given context sensitive help

while playing so that they do not get stuck or

have to rely on a manual.

Delspelet ger nu hjälp till spelaren baserat på kontexten, hjälp knappen ger olika tips baserat på vilket läge spelet är i. Spelet ger dessutom hjälp ifall spelaren har fastnat. På så sätt uppfyller spelet användbarhetprincip 4.

6. Players do not need to use a manual to play the

game.

Experterna tycker också att det nu finns tillräckligt mycket information och hjälp i spelet för att man inte ska behöva leta efter hjälp i något externt media för att kunna spela det, därför uppfyller vi nu också användbarhetsprincip 6. Vårt spel uppfyller i det här läget alla våra användbarhetsprinciper, och våra uppdragsgivare är generellt nöjda med vår prototyp och vårt arbete.

Slutprodukt

Vi har skapat ett lärospel för att introducera grundläggande programmeringsprinciper för barn. Spelet introducerar cykler och loopar.

Spelaren får välja en väg från korgen till alla bär och sedan tillbaka till korgen igen. Det enda stället spelaren får besöka mer än en gång är korgen. Varje steg i denna väg blir en nod i en nod-kedja där den första och sista noden är samma nod. Vilket är definitionen av en cykel.

Efter att spelaren har gjort en cykel får de välja hur många varv biet ska flyga för att plocka alla bär. Detta ska introducera programeringskonceptet loopar. Spelaren får se biet repetera att plocka upp ett bär varje loop och får se att det går att specificera antalet gånger en loop ska köras. Spelet uppfyller också enligt våra experter på COIN de användbarhetsprinciper vi har valt.

Figur 8. Översikt av spelet

DISKUSSION Resultat

Från början var vår tanke att utveckla alla tre delspelskoncept, vi upptäckte dock ganska snabbt att detta inte var ett realistiskt mål, det var mycket mer arbete än vi förväntade oss att utveckla dessa spel.

Vi trodde från början att det skulle gå rätt snabbt att utveckla spelen, då de i grunden är väldigt simpla 2d spel. Utvecklandet blev dock mycket utdraget på grund av kravet på hög användbarhet samt mening för barn. Själva spelkonceptet utvecklades hela tiden genom implementeringen och ledde till att mycket av koden var tvunget att skrivas om flera gånger. Vi var också tvungna att testa flera olika lösningar på många av våra problem för att allt skulle bli så optimalt som möjligt för barn.

Optimerande för barn var något som saktade ner utvecklingen av projektet hela vägen, och ledde till att vi valde att bara implementera ett av spelkoncepten, istället för vår original plan som var att implementera alla tre. Vi tycker att detta var rätt val, då både vi och våra experter på COIN är nöjda med vårt resultat.

Metod

Den metod vi använde var Guerilla Programming vilket vi tyckte fungerade bra då vi bara var två personer, och arbetade mycket tillsammans. Vi satt bredvid varandra och arbetade via atom teletype, detta lät oss arbeta på samma fil samtidigt, samt testa spelet med båda våra kod-tillägg samtidigt, detta var mycket viktigt för vårt projekt då den mesta av koden för delspel i den magiska trädgården ligger i en enstaka fil. Dessutom så hjälpte det väldigt mycket med testning, då vi byggde ett delspel från grunden, och genom större delen av projektet så var den kod vi lade till mycket beroende av varandras kod.

Vi delade upp arbetet så mycket som möjligt, och arbetade mestadels på separata spelfunktioner. Vi körde dessutom en hel del parprogrammering, oftast på de delar av projektet som var viktigast eller rakt av blockerade oss från att kunna dela upp arbetet. Vi använde oss också av parprogrammering när det kom upp problem eller buggar som behövde lösas.

Mycket av vår tid gick även åt till själva designen av spelet, hur det skulle fungera, hur det skulle bli meningsfullt för barnen, hur de skulle interagera med det på ett logiskt sätt samt hur det ska hålla deras intresse. Detta var en rätt stor utmaning då de spelkoncept vi fick från den förra studien var svåra att följa då vi inte kunde testa prototyperna. Vi valde att utveckla loop-spelet, för att det var det mest lovande spelkonceptet, fast även det var bristande i form av mening och klarhet. Resultatet av vår omtolkning av loopspelet är väldigt annorlunda från loopspelet utvecklat av Jin et al [1].

Det var väldigt bra att ha användbarhetsprinciper att sikta på under utvecklingens gång. Även fast vi inte hade erfarenheten att själva validera att vi följde dem var det ett bra sätt för oss att fokusera utvecklingen.

Att vi hade tillgång till experterna på COIN för att validera att vi följde våra användbarhetsprinciper var också bra. De har erfarenhet av att skapa lärospel för barn vilket ger deras åsikter större vikt än våra egna ifall vi uppfyller användbarhetprinciperna eller inte. Det är också viktigt att få kritik från människor som inte är så nära spelet som vi själva är. Ett exempel på detta var vår egna åsikt ifall spelet uppfyllde variations kravet på användbarhets princip 1. Vi själva tyckte att spelet var allt för repetitivt men vi hade spenderat väldigt mycket tid med delspelet, samt är vi inte förskolebarn. Experterna på COIN tyckte att det hade tillräcklig variation för förskolebarn.

SLUTSATSER

Vår fråga var hur ska delspel för introduktion till programmering i lärospelet Den Magiska Trädgården utvecklas för att ha hög användbarhet. För att skapa användbarhet så kan man under utvecklingens gång följa erkända användbarhetsprinciper. För att validera att delspelet följer dessa, kan man använda sig av experter inom området vilket blev experterna på COIN som har erfarenhet av att skapa lärospel till barn. För att använda sig av experternas åsikter kan man arbeta Agilt korta sprintar och ha feedbackmöten med experterna mellan.

Framtida arbete

Det som behöver göras i ett framtida arbete är att faktiskt testa spelet på målgruppen. Vi valde att använda oss av experter och heuristik för att validera att vi har skapat ett spel med hög användbarhet vilket vi ansåg var tillräckligt bra när det var så tidigt under utvecklingen. Det som också behöver göras är att först byta ut all grafik, då alla bilder förutom biet just nu är tagna från google. Sedan behöver alla röstklipp bytas ut till någon som kan göra bra röster. Efter detta så krävs det också en del arbete för att integrera spelet helt i den magiska trädgården. Det behöver integreras i deras databas samt passas in i den kronologiska storyn som alla partyspel deltar i inom den magiska trädgården. REFERENCER

1. Dennis Jin, Ebba Busch, Lia Karida, Joel Ottosson Tidig programmering Utveckling och utvärdering av ett lärospel för barn i åldrarna 4-6 år. Retrieved February 12, 2020 from

https://www.lucs.lu.se/LUCS/LUCS_175.pdf 2. Chris Nodder and Jakob Nielsen. Agile

Usability: Best Practices for User Experience on Agile Development Projects.

3. Tondello, G. F., Kappen, D. L., Mekler, E. D., Ganaba, M., & Nacke, L. E. (2016, October). Heuristic evaluation for gameful design. In

Proceedings of the 2016 Annual Symposium

on Computer-Human Interaction in Play

Companion Extended Abstracts (pp.

315-323).

4. Desurvire, H., Caplan, M., & Toth, J. A. (2004, April). Using heuristics to evaluate the playability of games. In _{​CHI'04 extended} abstracts on Human factors in computing systems​ (pp. 1509-1512).

5. Smith, A. C. (2009, June). Symbols for children's tangible programming cubes: an explorative study. In _{​Proceedings of the 2009} Annual Conference of the Southern African

Computer Lecturers' Association (pp.

105-109).

6. Tärning, B. (2018). Review of Feedback in Digital Applications–Does the Feedback They Provide Support Learning?. _{​Journal of}

Information Technology Education: Research​,

17​(1), 247-283.

7. ”Läroplan för förskolan”,Skolverket, [Online]_{​https://www.skolverket.se/undervisnin} g/forskolan/laroplan-for-forskolan/laroplan-lpfo -18-for-forskolan_{​ [Hämtad: 11 Mars, 2020]} 8. Chiu, S., Koong, C. S., & Fan, S. H. (2012).

Icon design principles for preschoolers: Implications derived from child development. Procedia-Social and Behavioral Sciences​, _​64​, 228-237.

9. Meyer, B. (2012, October). Game-based language learning for pre-school children: a design perspective. In Proceedings of the 6th European Conference on Games Based Learning: ECGBL (p. 332). Academic Conferences Limited.

10. Zidianakis, E., Antona, M., Paparoulis, G., & Stephanidis, C. (2012). An augmented interactive table supporting preschool children development through playing. ​Proceedings of the AHFE International​, _​2012​, 21-25.

11. J. Fu, "Graphic Design and Usability

Evaluation of Physical Programming Teaching Aids," 2019 IEEE 3rd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC), Chengdu, China, 2019, pp. 2634-2637.

12. Celis, V., Husson, J., Abeele, V. V., Loyez, L., Van den Audenaeren, L., Ghesquière, P., ... & Geurts, L. (2013, June). Translating

preschoolers' game experiences into design guidelines via a laddering study. In

Proceedings of the 12th International Conference on Interaction Design and Children​ (pp. 147-156).

13. Moreno-Ger, P., Burgos, D., Martínez-Ortiz, I., Sierra, J. L., & Fernández-Manjón, B. (2008). Educational game design for online education. Computers in Human Behavior​, _​24​(6),

2530-2540.

14. Fisher, C. (2014). _{​Designing Games for} Children: Developmental, Usability, and Design Considerations for Making Games for Kids​. CRC Press.