Konstprogrammering med codeart.ida.liu.se

Transkript

1 Konstprogrammering med codeart.ida.liu.se Öppna Chrome och gå till sidan codeart.ida.liu.se Klicka på den blåa knappen i övre högra hörnet Logga in och skriv in användarnamn codedojo och lösenord codedojo Till höger syns en vit yta Kanvas som man kan måla på. Det svarta fältet till vänster kallas editor, i den skriver man kod, dvs text, som är instruktioner till datorn. 1

2 Konstprogrammering Uppgifter Här följer ett antal uppgifter som guidar dig igenom vanliga programmeringsbegrepp. Text i fetstil är instruktioner för vad du ska ändra i koden. Uppgift 1 Figurer: form, storlek och koordinater I den här uppgiften lär du dig hur du kan rita ut olika figurer och hur setup och draw fungerar. Klicka på den röda knappen Exempel. Välj uppgift 1 På Kanvas syns en cirkel. Koden som skapar cirkeln är ellipse(400, 300, 100, 100); ellipse är en instruktion som talar om för datorn att du vill rita ut en ellips (eller cirkel). Men datorn behöver vet var den ska ritas ut och hur stor den ska vara. Därför måste du ange detta genom de fyra talen inom parentes. Ändra de olika talen och ta reda på vad de betyder. Vad står det första talet för? Det andra? Det tredje? Det fjärde? Du kan ändra på talen genom att klicka i texten och ändra koden genom att skriva, eller genom att klicka på ett tal och dra i reglaget som kommer fram. Vad händer när du ändrar på de olika sätten? Ändra så att det står ellipse(400, 400, 200, 200). Tryck sedan på Uppdatera. Vad händer? När du ändrar koden i draw ritas det ut flera figurer eftersom datorn utför de nya instruktionerna direkt när man skriver dem, det kallas livekodning. När man trycker på Uppdatera knappen startas programmet om. Då körs först setup en gång och den ritar ut en ny vit bakgrund. Sedan körs draw oändligt många gånger. Koden på raden under ellipse är grå. Det beror på att det står // först i raden. Det gör texten till en kommentar som datorn inte bryr sig om. Vad tror du händer om du tar bort // framför raden under ellipsen? Prova! Ändra nu koden för att rita ut fler figurer med olika storlek och på olika platser. Du måste skriva in nya ellipse eller rect inuti draw, dvs på raderna mellan { och }. Försök skapa ett mönster du gillar. 2

3 Uppgift 2 Färgläggning I den här uppgiften lär du dig hur färgläggning av bakgrund och figurer fungerar. Klicka på den röda knappen Exempel. Välj uppgift 2 Testa först att flytta på cirkeln. Ny syns bara en cirkel och inte flera som i förra uppgiften! Skillnaden ligger i background, som är en instruktion för att måla över hela kanvasen med en färg. I förra uppgiften låg den i setup och det som ligger i setup körs bara då du trycker på Uppdatera knappen. Nu ligger den inuti draw, så när du ändrar någonting i koden och draw körs igen så kommer background också att köras igen och måla över hela kanvasen och de figurer som finns på den. Testa att ändra på talen i background och se vad som händer. Prova att skriva background(255, 0, 0). Vilken färg får du då? Vad blir background(0, 255, 0)? Vad blir background(0, 0, 255)? En färg bestäms genom att tala om hur mycket rött, grönt och blått ljus det ska vara i den (som i gamla TV-apparater), det kallas därför RGB. Talen kan gå från 0 för inget till 255 för maximalt. Om man tar bart allt ljus (0,0,0) blir det svart och om man tar maximalt av alla färger (255, 255, 255) blir det vitt. Försök göra bakgrunden lila genom att variera talen i background. Nästa steg är att ändra färg på figurer. Det görs med instruktionen fill. Den fungerar på samma sätt som background. Gör cirkeln gul genom att ändra talen i fill. TIPS! Gul är i det här fallet motsats till blå. 3

4 Uppgift 3 Mer om färgläggning samt Slumptal I den här uppgiften lär du dig hur du man kan göra färger genomskinliga och hur du skapar och använder slumptal. Klicka på den röda knappen Exempel. Välj uppgift 3 I den här uppgiften vill vi skapa nya bilder genom att trycka på Uppdatera knappen. Därför ligger all kod i setup som bara körs när vi trycker Uppdatera. Vi börjar med att göra färgerna lite genomskinliga genom att lägga till ett fjärde tal med värde 100 till fill. Genomskinligheten kan vara från 0 (helt genomskinlig) till 255 (helt ogenomskinlig). Ändra fill(255, 0, 0); till fill(255, 0, 0, 100); och fortsätt lägga till 100 sist i de andra två fill. Tryck Uppdatera för att se vad dina ändringar gör. Hur gör man om man vill slumpa färgen på bakgrund eller figurer? Jo, man kan slumpa fram tal att använda i background och fill. random(255) slumpar ett tal mellan 0 och 255. Byt ut alla fill(255, 0, 0, 100); mot fill( random(255), random(255), random(255), 100); Tryck på uppdatera några gånger tills du får en bild du är nöjd med. 4

5 Uppgift 4 - Funktioner I den här uppgiften lär du dig skapa och använd funktioner. Klicka på den röda knappen Exempel. Välj uppgift 4. För att rita ut cirklar med en slumpmässig färg i den förra uppgiften fick vi upprepa fill(random(255), random(255), random(255), 100); många gånger. Om vi vill göra ännu fler cirklar blir det jobbigt och onödigt att skriva in samma sak flera gånger. Vore det inte trevligt om de två raderna: fill(random(255), random(255), random(255), 100); ellipse(450, 250, 400, 400); kunde ersättas med en rad för att göra en slumpmässigt färgad cirkel? Detta kan vi göra genom att skapa en funktion. Skriv in denna kod längst ned i editorn på raden under } som avlutar setup: void randomcoloredcircle(x, y, w, h) { fill(random(255), random(255), random(255), 100); ellipse(x, y, w, h); } Nu har du skapat en funktion som fungerar precis som ellipse men som ger cirkeln en slumpmässig färg. Ta bort alla rader med fill i setup. Byt ut alla ellipse mot randomcoloredcircle istället. När du är klar bör det stå: randomcoloredcircle(450, 250, 400, 400); randomcoloredcircle(350, 450, 400, 400); randomcoloredcircle(550, 450, 400, 400); Nu fungerar programmet precis som det gjorde innan, men vi har minskat raderna med kod inuti setup. Nu ska vi se vad som händer om vi ändrar vår funktion och lägger till att den ska rita ut två cirklar istället för en. Lägg till ellipse(x, y, w, h/2); under raden ellipse(x, y, w, h); i randomcoloredcircle Testa att köra programmet genom att trycka på Uppdatera några gånger. Varje gång setup anropar randomcoloredcircle ritar den nu ut två cirklar en stor och en med hälften så stor höjd (/ är division). 5

6 Uppgift 5 Loopar I den här uppgiften lär du dig använda en loop för att göra en sak många gånger. För att rita ut t ex 8 cirklar måste vi skriva in nästan samma sak 8 ggr. När ett program ska göra samma sak (t ex rita ut en cirkel) flera gånger kan man använda en loop. Det finns flera sorters loopar men vi kommer att använda while. Klicka på den röda knappen Exempel. Välj uppgift 5. I koden står det : var x = 0; while (x > 0) { randomcoloredcircle(120,300,200,200); } Det betyder att om x är större än noll så ska datorn göra det som står inuti, dvs rita ut en slumpmässigt färgad cirkel. Prova att köra koden genom att trycka på Uppdatera. Det händer ingenting! Varför? Jo, om du tittar på raden ovanför while ser du att x är satt att vara 0. Då x är 0 är det INTE sant att x är större än 0. Ändra var x = 0; till var x = 8;. Tryck på Uppdatera. Nu ritas en cirkel ut. Faktiskt ritas väldigt många cirklar ut, men datorn är så snabb att vi inte hinner se det. Eftersom x nu alltid är större än 0 kommer while att köras oändligt många gånger. Eftersom vi vill måla ut exakt 8 cirklar ska vi ändra så att den räknar nedåt för varje cirkel den ritar ut. Det gör vi genom att inuti while minska x med ett för varje cirkel som ritas ut. Skriv x = x 1; på en ny rad under raden med randomcoloredcircle inuti while. För att inte alla cirklar ska ritas på varandra måste vi också ändra cirkelns position. Det kan vi göra genom att sätta x-positionen till x * 100 (* är multiplikation). Ändra randomcoloredcircle(100, 300, 200, 200); inuti while till randomcoloredcircle(x*100, 300, 200, 200); Det innebär att första gången när x är 8 anropas randomcoloredcircle(8*100, 300, 200, 200), dvs randomcoloredcircle(800, 300, 200, 200). Sedan ändras x till 8 1 = 7 och nästa gång körs randomcoloredcircle(7*100, 300, 200, 200), dvs randomcoloredcircle(700, 300, 200, 200) och x ändras till 7 1 = 6, och så fortsätter det ända till x blir 1 1 = 0. Testa att köra programmet genom att trycka på Uppdatera några gånger. 6

7 Uppgift 6 Variabler I den här uppgiften lär du dig skapa och använda variabler. Klicka på den röda knappen Exempel. Välj uppgift 6. Vi vill göra en snögubbeliknande figur som vi kan ändra storlek på och flytta runt. Vi ritar ut tre cirklar som alla har samma storlek, diameter. Vi säger att diameter är en variabel med namn diameter och värde 100 genom att skriva var diameter = 100; Det betyder att datorn överallt där det står diameter kommer att ersätta det med värdet 100. Om vi ändrar värdet på diameter så kommer det nya värdet att användas istället. Prova att ändra variabeln diameter till 200 genom att ändra var diameter = 100; till var diameter = 200;. Vad händer? Eftersom vi inte ändrade positionerna på cirklarna så överlappar de nu. För att få en snögubbe igen behöver vi ändra y på den andra och tredje cirkeln. Ändra y (dvs det andra talet) på den andra cirkeln från 300 till 400 och på den tredje cirkeln från 400 till 600. Nu stämmer det. Men om vi skulle ändra diametern till 150 skulle vi få samma problem igen. För att slippa ändra y-värdet när vi ändrar diametern, kan vi räkna ut att y för en cirkel är y för cirkeln ovanför + diametern. Ändra så att y-värdet blir 200+diameter för den andra cirkeln och 200+diameter+diameter för den tredje cirkeln. Prova att ändra värdet på variabeln diameter till 100 för att se att det fungerar. Nästa steg är att vi vill kunna flytta snögubben, dvs ändra x och y positionen. För det behöver vi två nya variabler. Skriv in var x = 400; och var y = 200; under raden med var diameter. Ändra sedan raderna med ellipse så att de använder x och y istället för 400 och 200. Prova att ändra värdet på var x, var y och var diameter för att se att allt fungerar. FRIVILLIG UPPGIFT Nu vill vi välta snögubben. Ändra på raderna med ellipse så att det tre cirklarna nu ligger på rad efter varandra. Det ska fortfarande gå att ändra storlek och placering av snögubben. 7

8 Uppgift 7 Animering I den här uppgiften lär du dig att göra en animering genom att göra en loop med en figur som ändrar sin position. Klicka på den röda knappen Exempel. Välj uppgift 7. Nu ska vi göra en animation genom att steg för steg flytta en cirkel över skärmen. Ändra x = x + 0; så att det står x = x + 1; Vad händer? Cirkeln rör sig åt höger! Men, hur? Jo, datorn som kör programmet har som uppgift att först läsa vad som finns i setup och köra det en (1) gång! Sedan går den igenom koden rad för rad, neråt, och kör även allt där en (1) gång tills den kommer till draw. Allt som finns innanför klamrarna { } till draw körs oändligt många gånger, om inte sidan stängs ner. Detta brukar kallas för draw-loopen. Det innebär att datorn först sätter x till 100. Sedan går den in i loopen och målar över bakgrunden, ritar ut en cirkel och ändrar x till = 101. Sedan börjar den om loopen och målar ut bakgrunden, ritar ut en ny cirkel som sitter lite längre till höger och ändrar x till = 102. Så håller den på i all oändlighet. Efter ett tag är x så stort att cirkeln har hamnat utanför kanvas. Prova att ändra så att x = x + 5; Tryck Uppdatera. Vad händer? 8

9 Uppgift 8 Villkorliga uttryck I den här uppgiften lär du dig använda det villkorliga uttrycket if. Klicka på den röda knappen Exempel. Välj uppgift 8. Hur gör vi för att cirkeln inte ska försvinna ut ur kanvas när den når högerkanten? Lägg till följande kod sist i draw-loopen, dvs under raden x = x+5; och tryck på Uppdatera. Vad händer nu? if (x > 900) { x = 0; } Det som händer är att om x är större än 900, dvs kanvasens bredd, så kommer koden inuti { } att köras, och då sätts x = 0, dvs längst till vänster på kanvasen. Hur gör vi om vi vill att cirkeln ska vända om vid högerkanten istället för att hoppa tillbaka till vänsterkanten? Jo, vi kan lägga till en ny variabel som bestämmer riktningen. Lägg till var riktning = 1; under raden med var x. Ändra sedan koden inuti if-satsen: ta bort x = 0; och lägg till var riktning = -1; Slutligen ändrar du x = x + 5; till x = x + riktning * 5; Testa och se vad som händer nu! Nu vänder figurerna om istället för att försvinna till höger, eftersom -1 * 5 blir -5 och x därför kommer att minska istället för att öka. Men nu har vi fått ett nytt problem. Cirkeln försvinner ut till vänster. Det kan lösas med en till if-sats som ser till att riktningen blir 1 igen när x är mindre än 0. Gör en till if-sats under den if-sats som finns. I den nya if-satsen ska variabeln riktning ändra värde till 1 vid vänsterkanten. 9

10 Uppgift 9 Mer om loopar, variabler och villkorliga uttryck I den här uppgiften lär du dig mer om loopar, variabler och villkorliga uttryck. I Uppgift 5 använde vi en while loop för att rita ut en figur 8 gånger. Nu ska vi titta på hur vi kan använda två loopar för att fylla kanvas med ett mönster av kvadrater. Vi kommer att använda variabler för att avgöra var kvadraterna ska placeras ut och för att styra färgen. Klicka på den röda knappen Exempel. Välj uppgift 9. Läs koden och försök förstå vad som händer. while-loopen inne i draw ritar ut en kvadrat, uppdaterar x och räknar upp vilken kolumn det är. while körs så länge kolumnnumret är mindre än 15, alltså ritar den ut en rad med 14 rektanglar. Ta nu bort raderna med */ och /*. Vad händer då? Nu kör loopen draw oändligt många gånger. I varje varv kör den while-loopen för att skriva ut 14 rektanglar. Sedan uppdaterar den y, sätter tillbaka kolumn och x till sina startvärden och börjar om igen. Fundera på hur du skulle gjort utan loopar och hur mycket arbete det hade varit. Förutom att man slipper skriva in jättemånga rektanglar i koden så är det nu också enkelt att ändra avstånden mellan rektanglarna m.m. eftersom vi använder variabler för att bestämma alla positioner. Om vi ändrar på variablerna så kommer hela mönstret ändras. Testa att ändra lite i hur loopen beter sig genom att ändra lite olika variabler. Några förslag på saker du kan ändra är, hur många gånger while-loopen ska få köras, storleken på rektanglarna, mellanrummet mellan dem. Testa t ex att göra kvadraterna små eller stora och att göra mellanrummet 0 eller stort. Du kan också begränsa färgerna genom att varierar talen från 0 till 255. Eftersom draw loopar oändligt fortsätter den att rita utanför kanvas. Precis som med cirkeln i Uppgift 8 ska vi göra så att utritningen ändrar riktning och går uppåt när den når nederkanten på kanvas. För det behöver vi en variabel riktning. Lägg till var riktning = 1; Lägg sedan till en if-sats längst ned i draw på raden ovanför } som ändrar riktningen till -1 om man nått nederkanten. Lägg även till en if-sats som ändrar riktning till 1 om man nått överkanten. Du måste sedan justera hur y beräknas så att den tar hänsyn till riktningen, y = y + riktning * (hojd + mellanrum); 10

11 Hur gör vi om vi istället för att rita ut nya rektanglar på vägen upp vill ta bort de som är utritade? Jo, vi kan måla över dem med svarta rektanglar. För att veta om vi ska använda svart färg eller inte inför vi en variabel svart som får ha värdet true eller false. Till att börja med är den falsk så du ska skapa variabeln svart och ge den värdet false. Detta värde ska ändras beroende på vilken riktning det är så du behöver också lägga till två if-satser. Lägg till raden var svart = false; Lägg till i if-satserna att svart = true; resp svart = false; Slutligen ändrar du i draw så att det står: if (svart) { fill(0); // om svart = true så sätter vi färgen till svart } else { fill(random(255), random(255), random(255)); } Vi har här lagt till en else del i if-satsen, else hänger alltid ihop med en if. I detta fall så kommer fill(0) köras om svart är true, annars kommer fill(random ) köras. else är helt enkelt ett sätt att göra en antingen-eller sats. 11

12 Uppgift 10 Interaktiva program med musklick I den här uppgiften lär du dig göra ett interaktivt program med musklick. Klicka på den röda knappen Exempel. Välj uppgift 10. Börja med att läsa koden och försöka förstå vad som händer. Varför blinkar figuren i olika färger? Vi vill nu kunna placera ut flera likadana figurer. För att slippa kopiera koden i draw och skriva ut den flera gånger kan vi paketera den i en funktion. Du definierar en funktion genom att skriva: void minfigur(x, y, diameter) { } Flytta koden i draw in i definitionen av funktionen minfigur. Ta också bort raderna med var diameter, var x och var y. Nu har du skapat en egen funktion som du kan använda på samma sätt som de funktioner som redan finns, t ex rect och ellipse. Du bestämmer själv namnet på funktionen och vilka argument den ska ha och vad de ska heta. Tryck på Uppdatera. Vad händer? Varför försvinner figuren? Instruktionerna för hur datorn ska rita figuren finns nu i funktionen minfigur, men vi har inte sagt åt datorn att använda funktionen. Det gör vi genom att anropa funktionen minfigur. Lägg till minfigur(450, 300, 100); i draw. Lägg till några fler figurer genom att anropa minfigur med olika värden för x, y och diameter. Tryck på Uppdatera för att rensa bilden. Nu ska vi lägga till möjligheten att rita ut en figur genom att klicka på kanvasen. Definiera en ny funktion annanfigur(x, y). Använd sedan den i mouseclicked() som finns längst ned genom att lägga till instruktionen annanfigur(mousex, mousey) innanför { }. För att figuren ska ritas ut där man har klickat ska man använda mousex och mousey som x och y. 12

13 Uppgift 11 - Ett interaktivt ritprogram för att måla landskap I den här uppgiften använder du allt du lärt dig och lite till Klicka på den röda knappen Exempel. Välj uppgift 11. I den här uppgiften ska du skriva kod för att användaren ska kunna måla ett landskap. Det ska fungera så här: Om användaren drar med musen över kanvas så målas bakgrunden upp. På övre halvan ska det vara en bakgrund (t ex himmel) och på undre halvan en annan (t ex mark). Välj en geometrisk figur (t ex en smal rektangel) och två färger (t ex blå och grön). Färgerna varieras lite slumpmässigt i olika nyanser. Om användaren klickar med musen på övre delen av kanvas så målas ett föremål (t ex ett moln) dit. Om användaren klickar med musen på undre delen av kanvas så målas ett annat föremål (t ex blommor) (gärna med slumpmässig färg och storlek) ut. Använd din fantasi och bestäm vilken typ av landskap det ska vara, vilka färger du vill ha och vilka typer av föremål. 13

14 Börja att lägga till kod i ritabakgrund: Du behöver en if-sats för att avgöra om det är övre eller undre halvan som x och y är på och baserat på det vilken färg och form ett penseldrag har, (t ex en blå eller grön rektangel). Lägg till kod i mousedragged så att den anropar ritabakgrund med musens x och y värden. Testkör genom att trycka Uppdatera och sedan dra med musen över ytan. Ändra namnet på ritamoln till något som stämmer med ditt föremål, t ex ritastar Lägg till kod som ritar ut ditt föremål. Gör på samma sätt för ritablomma, men lägg gärna till att storlek och färg är slumpmässig. Lägg till kod i mouseclicked så att den med en if-sats avgör om det är övre eller undre halvan och anropar rätt funktion för att rita ut ett föremål. Testkör genom att trycka Uppdatera och klicka med musen på ytan. Nu är du klar och kan skapa en tavla genom att först måla bakgrunden och sedan dina föremål. FRIVILLIG UPPGIFT Ändra nu så att istället för att användaren skapar tavlan så gör datorn det. Istället för musklickningar får datorn köra loopar som ritar ut bakgrunden, 5 moln och 10 blommor (eller motsvarande av dina föremål). En ny tavla ska skapas varje gång man trycker på Uppdatera. 14

15 Former rect (x, y, w, h) Rita ut en rektangel med bredd w och höjd h med vänstra hörnet i (x, y) ellipse (x, y, w, h) Rita ut en ellips (cirkel) med bredd w och höjd h med centrum (x, y) triangle (x1, y1, x2, y2, x3, y3) Rita ut en triangel med hörn i (x1, y1)), (x2, y2) och (x3, y3) line (x1, y1, x2, y2) Rita ut en linje från (x1, y1) till (x2, y2) Färger background(r, g, b) - Ställ in bakgrundsfärg med värden mellan 0 och 255 för röd, grön, blå fill(r, g, b) - Ställ in färgfyllning för former nofill() - Stäng av fyllning för former stroke(r, g, b) - Ställ in färg på konturen för former strokeweight(tjocklek) - Ändra tjockleken på linjer och konturer nostroke() - Stäng av konturer för former Text text(mintext, x, y) - Rita ut mintext med start vid (x, y) textsize(storlek) - Ändra storleken på texten Mus mousex, mousey - Aktuella koordinater musen pmousex, pmousey - Tidigare koordinaterna för mus mouseclicked() { kod }; - Körs när musen klickas mousemoved() { kod }; - Körs när musen flyttas mousedragged() { kod }; - Körs när musen dras över kanvas Math random(låg, hög) - Generera ett slumptal mellan låg och hög dist(x1, y1, x2, y2) - Beräknar avstånd mellan två punkter abs(num) - Ta det absoluta värdet av ett tal Kommandon och funktioner void minfunktion () { kod }; - Definiera en ny funktion med namnet minfunktion if (x < 20) { kod } - Kör kod endast om ett villkor är sant while (x < 250) { kod } - Kör kod så länge ett villkor är sant for (var i = 0; i <8; i ++) { kod } - Upprepa koden ett fast antal gånger (t ex 8 ggr) 15

16 Bonusuppgifter Grattis du har klarat av alla våra uppgifter! Nu finns ett gäng häftiga animationer/bilder under Exempel som heter Extraexempel som du kan utgå ifrån och göra vad du vill med. Använd det du har lärt dig för att arbeta med koden! Flera av exemplen innehåller delar som vi inte gått igenom än, några av sakerna som dyker upp är matematik från högstadiet eller gymnasiet. Men det gör inget om du inte förstår allt, du kan ändå testa dig fram och ändra i variabler och olika typer av if-satser och while-satser för att ändra det som händer. Du kan också välja att skapa ett helt eget program utifrån vad du lärt dig. Längst bak i häftet finns en översikt över olika funktioner. Ännu mer information om olika funktioner finns på 16

17

18

19 Intervjuguide för fokusgrupp Öppningsfrågor Vad heter ni? Har ni varit med i någon studie förut? Introduktionsfrågor Hade ni stött på/hört talas om programmering innan de här lektionstillfällena? Vad hade ni för förväntningar innan de här lektionerna började? (Övergångsfrågor) Många tycker att programmering bör bli ett obligatoriskt ämne i alla skolor, andra tycker inte det, vad tycker ni? Nyckelfrågor Vad tyckte ni om dessa lektioner/konstprogrammering? Positivt/negativt? Har dessa lektioner fått er att ändra på vad ni tycker om att lära er programmera? Var programmering lättare/svårare än ni först trodde? Känner ni att ni har lärt er något på dessa lektioner? Mycket/lite? Känns programmering som något ni kan lära er? Varför/varför inte? Vill ni lära er mer programmering? Varför/varför inte? Avslutande frågor Är det någon som har något mer att tillägga? Känner ni att vi missat att ta upp något? Sammanfattning Sammanfatta diskussionen och fråga: Är detta en bra sammanfattning över vad som sagts tycker ni?

20

21 Observationsprotokoll, sal 303 och 305 Observatör Datum och tid Klass och antal elever Antal labassar Miljöbeskrivning/karta:

22 Saker som eleverna uppfattar som svårt. Vilken uppgift. Vad som är svårt. Vem/vilka tycker att det är svårt. (skriv mycket utförligt) Allmän stämning. Emotional arousal. Hur elever pratar med varandra/labass kring uppgifterna. Uppmuntran mellan elever/från labass. Övrigt.

23

24

25

26 Testuppgift Solnedgång 1. Börja med ett helt tomt fönster 2. Rita upp bilden: Använd en ljusblå bakgrund (t ex rgb = (80,220,240)) En gul sol högst upp i mitten med storlek 100 (t ex rgb = (255,255,0)) En grön rektangel som täcker nedre halvan av skärmen 3. Få solen att stegvis gå ned bakom marken (den gröna rektangeln) 4. Få solen att också öka i storlek då den går ner 5. När solen inte längre syns blir det natt, dvs en mörkblå himmel och mörkgrön mark 1

27

28 Programmering i skolmiljö En studie i mellanstadieelevers uppfattade egenförmåga och attityd till att lära sig programmera Christina von Tell Kandidatuppsats inom Kognitionsvetenskap Institutionen för Datavetenskap Linköpings universitet ISRN: xxxxxx Handledare vid Linköpings universitet: Magnus Bång Bihandledare och uppdragsgivare vid Institutionen för datavetenskap: Annika Silvervarg Examinator vid Linköpings universitet: Robert Eklund 2015

29 Förord Jag vill tacka min uppdragsgivare och bihandledare Annika Silvervarg som drivit denna studie och låtit mig få vara en del av den. Det har varit fantastiskt lärorikt och känts meningsfullt att få bidra till denna forskning tillsammans med henne och övriga i forskningsteamet. Jag vill även tacka min handledare Magnus Bång som kommit med insiktsfulla synpunkter på mitt arbete som höjt uppsatsens kvalité. Utöver det riktas ett stort tack till den skola som studien ägt rum på och de barn som deltagit, utan dem hade denna uppsats inte blivit av. i

30 Sammanfattning Datorer och teknik har blivit allt viktigare verktyg i vårt samhälle och behovet av programmeringsundervisning i grundskolemiljö har på senare tid diskuterats. I denna studie utfördes därför en programmeringsintervention för att undersöka mellanstadieelevers attityd till och uppfattade egenförmåga (eng. self-efficacy ) i att lära sig programmera. 63 stycken elever i Årskurs 6 fick prova på att programmera vid fyra tillfällen. Deras uppfattade egenförmåga i att lära sig programmera och attityd till att lära sig programmera mättes före och efter interventionen via ett enkätinstrument. Efter interventionen utfördes även fokusgrupper. Resultatet visade att eleverna blev mer negativa till att lära sig programmera efter att ha provat på det (p < 0,01). Styrkan i deras uppfattade egenförmåga förutom gruppen som från början hade en svag tro på den egna förmågan sjönk efter interventionen. Detta resultat var dock inte signifikant. Utöver det visade sig attityd och egenförmåga vara positivt korrelerade. Från fokusgrupperna framkom att eleverna tyckte att programmering är en viktig kunskap för framtiden. En rad förbättringsområden identifierades att ha i åtanke vid framtida interventioner och forskningsinitiativ. Nyckelord: programmering, barn, attityd, egenförmåga, enkätundersökning, fokusgrupper. Abstract Computers and technology have become important tools in today s society and the need for computer programming education in elementary school has been discussed lately. Therefore, this study conducted a programming intervention to examine middle school pupils attitude to and self-efficacy in learning how to program. 63 pupils in 6 th grade had the opportunity to try computer programming at four occasions. Their self-efficacy in learning how to program and attitude to learning how to program was measured before and after the intervention with a questionnaire. Focus groups were conducted after the intervention. The result showed that the pupils were more negative towards learning how to program after having tried it (p < 0,01). The strength in their self-efficacy except within the group who from the beginning had a weak self-efficacy decreased after the intervention, this result was not significant. Also, attitude and self-efficacy turned out to be positively correlated. The focus groups showed that the pupils thought computer programming is an important knowledge for the future. A number of improvement areas which can be borne in mind for future programming interventions and research initiatives was identified. Keywords: programming, children, attitudes, self-efficacy, questionnaires, focus groups. ii

31 Innehållsförteckning Förord... i Sammanfattning... ii Abstract... ii 1. Inledning Motivering till studien Syfte och frågeställningar Avgränsningar Teoretisk bakgrund Egenförmåga Attityd Metodik Interventionsmaterial Enkätundersökning Fokusgruppintervjuer Pilottestning Datainsamling Analys Enkätanalys Analys av fokusgrupper Resultat Bakgrundsinformation Attityd Egenförmåga Attityd och egenförmåga Teman från fokusgrupperna Noteringar vid datainsamling Diskussion Resultatdiskussion Metodikdiskussion Slutsats Framtida forskning Referenser Bilagor iii

32 Bilaga 1: Pre-Enkäten Bilaga 2: Intervjuguide Bilaga 3: Teman från fokusgrupper iv

33 1. Inledning I detta avsnitt presenteras en motivering till studien samt dess syfte och frågeställningar. Kort beskrivs även de avgränsningar som har gjorts. 1.1 Motivering till studien Programmeringskunskaper blir allt mer viktigt i dagens västerländska samhälle. Ingen kan väl ha undgått att vi till stor del har teknik integrerad i vår vardag. Teknik som konsumeras aktivt i form av bland annat datorer, smarta mobiltelefoner, GPS-klockor, surfplattor med mera. Ändå är det många som inte har kunskap om hur denna teknik egentligen fungerar. Tidigare forskning visar att barn snarare lär sig att använda teknik än att utveckla den (Burke & Kafai, 2014, ss ). För att fostra bättre teknikanvändare och även framtidens teknikproducenter är det därför många som förespråkar att barn och ungdomar bör introduceras till programmering (Armoni, 2011, s. 19). Det finns redan idag en del möjligheter för barn att lära sig att programmera. På många ställen arrangeras exempelvis så kallade CoderDojos som är ideella initiativ där deltagarna möts för att lära ut respektive lära sig programmering. Dessa CoderDojos ingår i ett globalt nätverk som också kallas CoderDojo. CoderDojos finns i totalt 55 länder och har ett fokus på att deltagarna ska lära av varandra (The CoderDojo Foundation, 2015). Varje Dojo sköts lokalt och i Sverige finns det idag registrerade CoderDojo-klubbar på tolv olika orter (The CoderDojo Foundation, 2015). Åldern på deltagarna brukar vara mellan sju och 17 år men de mentorer som närvarar kan vara äldre. Dessa CoderDojo-initiativ bygger på att barnen aktivt söker sig dit och därför är det många som går miste om dem och kanske inte ens vet om att de finns. Ett sätt att introducera programmering till alla barn vore att införa programmeringsundervisning i grundskolan. Tanken är inte att alla elever i framtiden skall bli yrkesprogrammerare, utan snarare få en grundläggande förståelse för programmering. Programmeringsundervisning skulle även kunna fungera som en ögonöppnare för de barn som annars inte hade kommit i kontakt med programmering och väcka deras intresse för vidare studier i ämnet. Om eleverna inte får testa på programmering tidigt kan de lätt utveckla en förutfattad mening mot att göra det. Detta kan bland annat resultera i att få senare söker sig till den typen av utbildning (Armoni, 2011, ss ). De skulle till exempel kunna tro att programmering är för svårt för att lära sig. Avsikten med den föreliggande studien är därför att undersöka om introducering av programmering kan förändra barns syn på ämnet och sin tro på den egna förmågan att kunna lära sig programmera, samt hur programmeringsundervisning för skolklasser i mellanstadiet kan utformas. Detta görs genom en kortare programmeringsintervention för skolelever bestående av fyra programmeringstillfällen där attityd till och uppfattad egen förmåga i att lära sig programmera undersöks före och efter interventionen. 1.2 Syfte och frågeställningar Syftet med denna uppsats är att undersöka hur elever i mellanstadiet upplever programmering i skolmiljö med fokus på deras egen inställning och attityd till programmering samt den egna 1

34 förmågan att lära sig programmera. Syftet är även att undersöka om dessa aspekter påverkas av en kort programmeringsintervention. Frågeställningar: Ändras den uppfattade förmågan att lära sig programmera efter en kort programmeringsintervention? Hur ser eleverna på sin egen förmåga att lära sig programmera? Ändras elevernas attityd till att lära sig programmera efter att ha introducerats till det? Vad anser eleverna om att lära sig programmera? Hur ser elever på programmeringsundervisning i skolmiljö? Hur kan programmeringsundervisning utformas för skolmiljö? 1.3 Avgränsningar Denna studie har valt att inte utvärdera elevernas kunskap i programmering. Den undersöker heller inte programmeringsundervisning över en längre tid, exempelvis en termin. Studien har inte ett genusperspektiv. 2

35 2. Teoretisk bakgrund Nedan följer bakgrund till studien innehållandes de teorier som används och refereras till: egenförmåga och attityd. 2.1 Egenförmåga Egenförmåga (eng. Self Efficacy ) är ett begrepp myntat av psykologen Albert Bandura på talet och handlar om den egna uppskattningen av att kunna klara av en viss uppgift. Det är alltså ett subjektivt mått på hur en person tror sig kunna producera ett visst beteende för att nå ett visst utfall. Detta kan till exempel handla om förmågan att överkomma en fobi. Egenförmåga påverkar både om en person påbörjar en uppgift och hur uthållig denne är i den. Människor räds och undviker situationer som ligger utanför deras egenförmåga, men involverar sig i sådant de tror sig klara av. Om en uppgift påbörjats påverkar egenförmågan hur mycket ansträngning som läggs ned på den och hur motgångar hanteras. Ju starkare egenförmåga en person har desto mer aktiv är denne i sina ansträngningar och ger inte upp lika lätt vid motgångar (Bandura, 1978, s. 141). Att endast ha stor egenförmåga inom ett visst område betyder inte att människor tar sig an uppgifter inom det, utan det krävs även motiv och färdigheter för att utföra uppgiften. Om dessa två faktorer uppfylls är dock egenförmågan något som har stor inverkan på om personen i fråga väljer att utföra uppgiften, hur mycket ansträngning denne lägger ned, hur länge denne behåller sin ansträngning och hur denne hanterar eventuella stressfulla situationer (ibid., s. 142). Egenförmåga varierar i olika dimensioner: magnitud, allmängiltighet och styrka. Magnitud handlar om hur svåra uppgifter en person tror sig klara av, tillexempel är magnituden av egenförmåga vad gäller matematik hur svåra tal personen tror sig kunna lösa. Allmängiltighet beskriver om personen tror sig klara av uppgiften under olika omständigheter och situationer. Uppfattar personen att den klarar av att lösa komplicerad huvuduträkning både i tyst och lugn miljö likväl som i bullrig och stökig miljö? Till sist handlar styrkan av egenförmåga om hur starkt personen håller fast vid sin uppfattning. Är egenförmågan stark behålls den i högre grad vid motgångar än om den är svag och då sänks (Bandura, 1978, s. 142). Det som används som källor till att bygga upp en egenförmåga är bemästringserfarenheter, ställföreträdande upplevelser från sociala modeller, övertalning och fysiologiska tillstånd. Av dessa är bemästringserfarenheter starkast; om en person lyckas med en uppgift stärks egenförmågan inom det området och vice versa om denne misslyckas, speciellt om misslyckandet sker tidigt i dennes försök. Då människor byggt upp en stark egenförmåga efter flertalet framgångar minskar risken för sänkt egenförmåga vid enstaka misslyckanden (Bandura, 1978, s. 143). En förutsättning för detta är dock att personen tillskriver sitt lyckande till den egna förmågan och inte externa faktorer. Om denne tror sig ha lyckats på grund av utomstående omständigheter bidrar det inte till en ökad egenförmåga. På samma sätt kan misslyckanden tillskrivas yttre omständigheter och alltså inte minska egenförmågan. Följaktligen gör fler utomstående hjälpmedel att prestationen tillskrivs något annat än ens egenförmåga (ibid., s. 148). Den andra källan till egenförmåga kommer från sociala modeller, vilka utgörs av människor som liknar en själv. När en social modell lyckas med en viss uppgift kan den som observerat det känna sig i stånd att också klara av det. Detta förutsätter att det som modellen lyckas med inte är tvetydigt 3

36 och ju fler modeller som lyckas desto starkare blir egenförmågan hos observatören (Bandura, 1978, s. 145). Även övertalning är något som bidrar till egenförmågan. Detta är dock en relativt svag källa i jämförelse mot bemästringserfarenheter, men kan fungera i vissa fall. Det innebär kort sagt att en person intalas av någon annan att denne klarar av en viss uppgift (Bandura, 1978, s. 143). Hur lätt en person blir övertalad påverkas bland annat av den övertalande personens trovärdighet och expertis (ibid., s. 149). Egenförmåga som byggs upp på detta sätt sänks snabbt vid motgångar (ibid., s. 145). Den sista källan till egenförmåga kommer från fysiologiska tillstånd som skapas av emotionell aktivering (eng. arousal ). Generellt sett förväntar sig människor att lyckas i högre grad när de inte känner emotionell aktivering än om de till exempel känner spänning eller uppretning. Känsloreaktioner (d.v.s. emotionell aktivering) kan även generera ännu mer känsloreaktioner, exempelvis rädsla, och detta kan leda till att människor bygger upp en ångest inför nära förestående uppgifter vilket påverkar egenförmågan negativt (Bandura, 1978, s. 146). Känsloreaktioner kan dock även tolkas positivt och Bandura (1978, s. 147) noterade att själva tolkningen och uppfattningen av känsloreaktionerna är viktigare än intensiteten hos dem. Eftersom egenförmåga är subjektivt mäts den genom att fråga människor om deras uppfattning om att klara av en uppgift eller inte. Detta kan göras på olika sätt men det vanligaste är genom enkäter där fokus ligger på uppskattad prestationskapacitet (Zimmerman, 2000, s. 83). De två vanligaste tillvägagångssätten att mäta egenförmåga är dels genom att presentera olika uppgifter för personen och be denne uppskatta om vederbörande skulle klara av att lösa dem, och dels genom att ställa mer generella frågor kring egenförmågan inom en domän utan att referera till specifika uppgifter (Bong, 1997, s. 4). Vad denna studie vill se på är elevers egenförmåga vad gäller deras lärande i programmering. Tror de att de kan lära sig att programmera? Bandura (1996, s. 1206) refererar till flera tidigare studier som visar att barns egenförmåga i att styra sitt lärande och bemästra svåra ämnen påverkar deras akademiska motivation, intresse och prestation i skolan. Alltså är det intressant att se om denna egenförmåga går att stärkas genom att introducera programmering för barn, för att det då skulle leda till att fler barn blir intresserade av programmering och möjligtvis väljer att studera det längre fram i sin utbildning. Usher och Pajares (2008, s. 460) skriver att låg egenförmåga ofta beror på att eleven inte förstått vilka färdigheter en uppgift egentligen kräver. Detta menar de kan avhjälpas genom interventioner för att utmana dem. Komarraju och Nadler (2013, s. 67) skriver om akademisk egenförmåga, vilket definieras som en elevs upplevda förmåga för uppgifter inom den akademiska domänen. Detta är något som är intressant att undersöka eftersom akademisk egenförmåga är starkt kopplat till motivation och därför utgör en stor faktor för akademisk prestation (Komarraju & Nadler, 2013, s. 68). Det innebär att om en person tror sig klara av uppgifter i skolan är den mer motiverad att försöka och därför presterar denne väl i högre grad än någon med låg egenförmåga som inte har lika mycket motivation. I den studie som Komarraju och Nadler utförde finns stöd för detta (2013, s. 70). Författarna föreslår därför olika sätt som lärare kan öka elevers egenförmåga, varav ett är att förse dem med erfarenhet av att lyckas inom ett ämne så att de tror sig kunna klara av det i framtiden, något som denna studie skulle kunna göra inom programmering. 4

37 Lee, Park och Hwang (2013) utförde en studie för att undersöka egenförmåga i programmeringssammanhang i vilken de studerade hur stor inverkan de olika källorna till egenförmåga (bemästringserfarenhet, sociala modeller, verbal övertalning och emotionell påverkan) hade vad gäller just datorprogrammering. De fann en statistiskt signifikant relation mellan bemästringserfarenhet och sociala modeller och generell programmeringsegenförmåga. Verbal övertalning och känslor mot datorer var inte signifikant kopplade (ibid., s. 429). Detta tror författarna kan bero på att programmeringsuppgifter kräver mycket kunskap och därför måste erfarenheter ske direkt genom bemästring eller observation snarare än indirekt via övertalning eller emotionella reaktioner (ibid., s. 429). Ett område som kan anses vara närliggande programmering är generellt datoranvändande. I en studie av Torkzadeh, Pflughoeft och Hall (1999) undersöktes studenters egenförmåga innan och efter de gick en kurs i datoranvändande. Studenterna fick svara på en enkät i kursens början och slut som sedan analyserades av forskarna. Vad de fann var att studenterna påbörjade kursen med måttlig egenförmåga och att de efter att ha gått kursen förbättrat den signifikant. Detta gällde dock inte för de som hade en negativ attityd mot datorer. Av de som hade negativ attityd till datorer var det få som förbättrade sin egenförmåga (ibid., s. 303). 2.2 Attityd Begreppet attityd är något som används i vardagligt tal med i princip samma innebörd som inom psykologin. En avgörande aspekt av en attityd är att det är ett utvärderande tillstånd, det vill säga att den som håller attityden tillskriver det den håller attityden emot någon grad av godhet eller dålighet (Eagly & Chaiken, 1993, s. 3). En attityd existerar alltid mot något annat - den finns aldrig endast i sig själv. Det som attityden kopplas till kallas inom socialpsykologin för attitydobjekt. Dock menas inte endast fysiska objekt, vilket det skulle kunna tolkas som. Vad som helst som är särskiljbart kan utgöra ett attitydobjekt. Detta innebär exempelvis abstrakta koncept (t.ex. kommunism), konkreta objekt (t.ex. en hatt), specifika objekt (t.ex. dina solglasögon) och klasser av objekt (t.ex. solglasögon i allmänhet), beteenden (t.ex. att spela fotboll) och klasser av beteenden (t.ex. delta i en sport) (ibid., s. 5). I denna studies fall är attitydobjektet beteendet att lära sig programmera. Attityder har ofta beskrivits ge upphov till tre sorters reaktioner på ett attitydobjekt: kognitiva, emotionella och beteendemässiga. De kognitiva reaktionerna innebär de tankar som personen har om attitydobjektet, de emotionella reaktionerna inkluderar de känslor som personen har mot attitydobjektet och beteendet är hur personen uppför sig eller har för avsikt att uppföra sig mot attitydobjektet (Rosenberg & Hovland, 1960). De tre aspekterna på attitydreaktioner kan även appliceras för att klassificera in de olika källorna till att bilda en attityd, det finns således kognitiva, emotionella och beteendemässiga källor till attitydsbildande. Hur attityder formas genom kognition är genom att personen i fråga får information om attitydobjektet antingen direkt eller indirekt. Exempelvis kan en attityd mot en ny produkt bildas av att testa den själv eller att någon annan som testat den berättar om hur den var. Detta skapar uppfattningar hos den som håller attityden vilka kan vara goda eller dåliga (Eagly & Chaiken, 1993, ss ). 5

38 Emotioner kan forma en attityd om de uppkommer i anslutning till ett attitydobjekt, detta har bland annat undersökts genom betingningsexperiment där en positiv eller negativ emotion kopplats ihop med ett attitydobjekt (Staats & Staats, 1958). Flera studier har visat att även enbart exponering för ett attitydobjekt kan få en person att bilda en mer positiv attityd mot det än ett attitydobjekt som denne inte sett förut (Zajonc, 1968). Forskare har även hävdat att attityder kan komma ur ens eget beteende. Enligt Bems självperceptionsteori (eng. self-perception theory ) har en person inte alltid tillgång till sitt inre tillstånd, och vid sådana tillfällen kan personen härleda en attityd genom att se till hur denne betett sig mot det aktuella attitydobjektet tidigare (Bem, 1972, s. 2). I dessa fall tar även personen hänsyn till under vilken kontext som beteendet skedde, tillexempel om det var påtvingat eller av egen vilja. Det är mer troligt att detta sker när attityden är svag eller oklar. Enligt de mest framträdande modellerna av vilka funktioner attityder tjänar består dessa av fem olika områden (Katz, 1960, s. 170; Smith, Bruner, & White, 1956, ss ): Objektsvärdering (eng. object appraisal function ) vilket innebär att attityder sparar energi åt den som håller dem genom att summera ihop positiva och negativa egenskaper hos attitydobjekten. På detta vis slipper personen gå igenom dessa varje gång denne ska bilda sig en uppfattning. Nyttofunktion (eng. utilitarian function ) som gör att personen med attityden maximerar vinst och minimerar kostnad från attitydobjektet, följaktligen får det en väldigt praktisk implikation. Social anpassning (eng. social adjustment ) vilket innebär att attityder hjälper en person att identifiera sig med människor den gillar och avvika från människor den ogillar. Ego-försvarsfunktion (eng. ego-defensive function ) där attityden skyddar individens självkänsla genom att exempelvis utveckla en negativ attityd mot det som denne är dålig på. Värderingsuttryckningsfunktion (eng. value-expressive function ) i vilken attityder ger uttryck för personers självkoncept och värderingar, exempelvis att en person som värderar hälsan och miljön väljer att cykla till jobbet (Haddock & Maio, 2012, ss ). Attityder kan mätas på flera olika sätt. Eftersom attityder inte är direkt observerbara mäts attitydsreaktionerna för att sedan härleda attityden. När detta gjorts kan attityden plottas ut på en bipolär skala med en neutral mittpunkt och extremerna på vardera sida. Tillexempel görs skillnad på extremt positiv och måttligt positiv där extremt positiv placeras längre ut i ena änden av skalan och måttligt positiv hamnar närmre mitten där neutral finns. Detta på grund av att attityder antas variera i riktning och intensitet där riktningen representerar om personen i fråga har en positiv eller negativ attityd mot attitydobjektet och intensiteten representerar hur stark denna riktning är (Eagly & Chaiken, 1993, s. 4). En hög intensitet på attityden tenderar att leda till att den är mer ihållande, är motståndskraftig mot förändring, samt är mer trolig att influera bearbetande av information samt påverka beteende (Krosnick & Petty, 1995, s. 3). Hur hög intensiteten på en attityd är kan ses på i termer av hur lättillgänglig den är att hämta från minnet. Attityder som ligger nära till hands och är lätta att hämta är mycket tillgängliga (Fazio, 1995, s. 247). Detta innebär att de är mer intensiva än de attityder som inte är lika tillgängliga och alltså inte går lika lätt att hämta från minnet. 6

39 Det finns olika klasser av mått för att mäta attityder, varav en är psykometriska mått. Dessa typer av mått består av att en individ får svara på ett flertal frågor vilka antas bedöma det underliggande attributet som måttet skall mäta. Ju fler frågor personen svarar på desto mer precist blir måttet (Eagly & Chaiken, 1993, s. 29). En typ av psykometriska mått är Likert-skalan, som antar att respondentens svar på formulärfrågorna återspeglar en underliggande variabel (Eagly & Chaiken, 1993, s. 51), attityd i detta fall. Likert-skalan ett explicit mått eftersom respondenten är medveten om vad som efterfrågas (Haddock & Maio, 2012, s. 186). Inom datorvetenskap har attityder undersökts främst i förhållande till datoranvändande i allmänhet. Flertalet skalor har utvecklats för att mäta människors attityder mot datorer, exempelvis listar Shaft, Sharfman och Wu (2004, ss ) 31 stycken skalor och det är på intet sätt en uttömmande lista. Vad gäller attityder mot att lära sig programmera finns dock inte lika mycket litteratur (Korkmaz & Altun, 2014, s. 30). De få studier som undersökt attityd till programmering har främst riktat in sig mot äldre elever som valt att gå programmeringskurser på universitet eller motsvarande gymnasiet (se t.ex. Korkmaz & Altun, 2014; Thomas, Ratcliffe, & Robertson, 2003; Wiebe, Wiliams, Yang, & Miller, 2003). Exempelvis använde sig Thomas m.fl. (2003, ss ) i sin studie av ett frågeformulär för att bedöma studenters attityd till programmering och placera in dem på en niogradig skala från kod-o-fobisk (eng. Code-a- Phobic ) till kod-krigare (eng. Code-Warrior ). Detta frågeformulär användes dock på äldre studenter med tidigare programmeringserfarenhet med syftet att undersöka par-programmering. Programmeringsattityder hos barn är alltså ett förhållandevis outforskat område inom vilket mycket forskning finns kvar att göra. Torkzadeh, Pflughoeft och Hall (1999, s. 301) nämner att elevers attityder mot datorer oftast formas innan de går sin första datorkurs och att om en elev redan har en negativ attityd innan denne kommer i upp i årskurserna blir den svårare att ändra på. De testade detta genom att mäta universitetsungdomars attityder mot datorer före och efter en kurs i datoranvändande och fann att väldigt få deltagare med negativ attityd mot datorer ändrade denna medan de med positiv attityd förstärkte den (Torkzadeh, Pflughoeft, & Hall, 1999, s. 306). Detta var alltså år 1999, innan datorer var allmänt integrerat bland barn och ungdomar, och skulle därför eventuellt kunna jämföras med attityder till programmering idag. Om liknande tendenser visas hos dagens ungdomar är det därför extra viktigt att de får komma i kontakt med programmering vid en tidig ålder för att minska antalet som utvecklar en negativ attityd mot det. Till sist bör nämnas att attityder är tendenser som förvärvas hos en person och alltså inget som är fixerat (Campbell, 1963, s. 97). För att räknas som attityd måste den därför hållas under minst en kort tidsperiod, den behöver alltså inte vara långvarig, även om den kan vara det. Attityder kan således ändras med tiden i och med att personens respons mot attitydobjektet ändras. Detta är vad denna studie hoppas kunna uppnå för eleverna genom att exponera dem för programmering och således ändra deras attityd till det mer positiva. 7

40 3. Metodik För att undersöka förestående frågeställningar antog denna studie en triangulerad ansats med både kvalitativa och kvantitativa metoder. Två skolklasser med elever i Årskurs 6 fick prova på att programmera under fyra tillfällen. I anslutning till detta samlades data in genom en enkätundersökning och fokusgrupper. Enkäternas syfte var främst att mäta förändringseffekter hos samtliga elever och framställa kvantitativ data som kunde analyseras för att producera numeriska resultat. Dessa konstruerades, pilottestades och distribuerade före och efter programmerings-tillfällena. Fokusgrupperna bidrog med kvalitativ data som gav mer fylliga resultat där deltagarna fick en chans att förklara sina synpunkter. Inför dessa utvecklades en intervjuguide som pilottestades och sedan användes efter att samtliga programmeringstillfällen genomförts. Sedan har all data analyserats för att svara på uppsatsens frågeställningar. Figur 1 visar detta visuellt. Figur 1. Schematisk bild över studien och de olika steg som ingick. Nedan följer en beskrivning av de mätinstrument som användes och hur data samlades in. 3.1 Interventionsmaterial Den plattform som eleverna fick arbeta med under programmeringstillfällena heter CodeArt och har utvecklats vid Institutionen för Datavenskap (IDA) på Linköpings universitet. Den bygger på det webbaserade konstprogrammeringsspråket Processing, vilket är ett kodbibliotek som i detta fall är implementerat med Javascript. Koden kräver ingen installation på datorer utan kan köras via webben. Plattformen är uppdelad i en tudelad skärmvy där den vänstra sidan (editor) visar den kod som arbetas med och den högra sidan (canvas) visar resultatet från koden, alltså vilken konst som frambringas; se figur 2. Programmet använder sig av livekodning, det innebär att koden körs samtidigt som den skrivs vilket kan resultera i konstnärliga effekter. Användaren kan göra både enkla saker såsom att rita ut cirklar och streck, men även mer abstrakta konstverk som kräver avancerad kod. Det finns även ett galleri i vilket användaren kan spara sitt konstverk och namnge det. I detta galleri kan användare gå in och se på vad de själva och andra har gjort. Fördelen med just konstprogrammering är att det är direkt visuellt, vilket bör kunna fånga intresset hos de som gillar att skapa saker och normalt inte kommer i kontakt med vanlig programmering. 8

41 Figur 2. Plattformen CodeArt som eleverna fick arbeta med (t.v. editor där kod skrivs in, t.h. canvas där konst frambringas). Under programmeringstillfällena fick eleverna arbeta med ett var sitt häfte. Häftet bestod av elva uppgifter med stigande svårighetsgrad, vilka eleverna ombads att utföra i ordning. Till varje uppgift fanns det kod att starta med i CodeArt. Instruktionerna var utformade på så sätt att den instruerande texten var i fetstil medan den förklarade texten inte var det, för att underlätta ifall någon inte ville läsa all text. I instruktionerna stod det kod som eleverna ombads skriva in i CodeArt. De ombads även att ändra i den kod som redan fanns på plattformen. Detta resulterade i att olika konstverk trädde fram på canvasen. I två av uppgifterna fanns det en frivillig extra uppgift för de elever som kände att de ville ha en ytterligare utmaning. Längst bak i häftet fanns en sammanfattande sida med användbara kodrader. Vid sista programmeringstillfället fick eleverna utföra en testuppgift som innefattade att de skulle rita ut himmel, mark och sol där solen skulle röra sig nedåt och bli större. Till denna uppgift fanns ingen instruerande text med kod och heller ingen kod i CodeArt att utgå ifrån utan eleverna var tvungna att själva skriva in kod från start. Dock fick de tillgång till uppgiftshäftet där den sammanfattande sidan fanns. 3.2 Enkätundersökning En webbaserad enkät utvecklades i verktyget Google Forms vars syfte är att mäta attityd till att lära sig programmera och egenförmåga i att lära sig programmera; se bilaga 1. Denna fylldes i av respondenterna vid två tillfällen, före och efter programmeringstillfällena, för att mäta samma konstrukt och kunna undersöka förändringseffekter. Frågorna och utformningen har inspirerats av tidigare studier (Benson & Hocevar, 1985; Wiebe, Wiliams, Yang, & Miller, 2003; Pintrich & De Groot, 1990; Lee, Park, & Hwang, 2013; Borgers, de Leeuw, & Hox, 2000; Bandura, 2006) men anpassats för det aktuella syftet. Exempelvis har inte normativa frågor eller negativt 9

42 formulerade frågor inkluderats. Frågorna har även formulerats så att de frågar respondenten om att lära sig programmera, inte att programmera. Enkäten finns således i en pre- och post-version och består av tre delar där endast den första delen skiljer sig något mellan de olika versionerna. Pre-enkätens första del innehåller en introducerande text och diverse bakgrundsfrågor samt ifyllnad av elev-id. Post-enkätens första del innehåller endast elev-id, i syfte att kunna koppla ihop enkäter till samma respondent och beräkna förändringsfaktorn. Resterande delar är exakt likadana i både pre- och post-enkät. Del två handlar om att kartlägga respondenternas attityd till att lära sig programmera. Detta görs genom fyra stycken femgradiga skalor med olika attribut som kan kopplas till lärande av programmering. Respondenten får kryssa i var på respektive skala denne anser sig ligga. Exempelvis Att lära sig programmera är med svarsalternativen Tråkigt, Ganska tråkigt, Varken eller, Ganska kul och Kul. Del tre innefattar också frågor där vardera består av en femgradig skala, men syftar till att bedöma respondentens egenförmåga att lära sig programmera. De elva frågorna berör därför saker att lära sig inom programmering vilka respondenten får kryssa i hur säker denne är på att kunna lära sig det. Exempelvis Jag kan lära mig att göra enkla program med svarsalternativen Jätteosäker, Ganska osäker, Kanske, Ganska säker och Jättesäker. 3.3 Fokusgruppintervjuer En intervjuguide skrevs med utgångspunkt i Wibecks (2010) bok Fokusgrupper: Om fokuserade gruppintervjuer som undersökningsmetod. Guiden innehåller frågor härledda ur frågeställningarna för uppsatsen. Frågorna i intervjuguiden är uppdelade i öppningsfrågor, introduktionsfrågor, övergångsfrågor, nyckelfrågor och avslutande frågor (Kreuger, 1998, s. 22), totalt 14 stycken, se bilaga 2. Guiden användes som diskussionsunderlag vid fokusgrupper två veckor efter att deltagarna deltagit i samtliga programmeringstillfällen. Urvalsmetoden för vilka som skulle delta i fokusgrupperna baserades på existerande listor, vilket är en vanlig metod för rekrytering av deltagare till fokusgrupper (Wibeck, 2010, s. 80). I detta fall innebar det klasslistan för respektive klass. Två grupper utsågs från vardera klass baserat på svaren i post-enkäten. En grupp med de som hade mest positiv attityd till att lära sig att programmera och en grupp med de som hade mest negativ attityd till att lära sig programmera. Detta för att uppnå homogena grupper som kunde jämföras med varandra, vilket kallas segmentering (Morgan, 1998, ss ). Totalt blev det fyra stycken grupper med fem deltagare i vardera. 3.4 Pilottestning Pilottestning skedde i två omgångar. Första omgången skedde två veckor innan huvuddatainsamlingen under en CoderDojo i en mötesplatslokal, Linköping. Fem stycken barn deltog i pilottestandet. Dessa barn fick testa på uppgifter i CodeArt med tillgång till handledning ifall de behövde hjälp. Under tiden togs de åt sidan en och en och fyllde i lugn och ro i enkäten samtidigt som tänka-högt-protokoll tillämpades. Under detta moment fick deltagaren fylla i svar på de olika frågorna och samtidigt berätta vad denne trodde att frågan innebar. I slutet av CoderDojon 10

43 samlades deltagarna för att delta i en kortare fokusgrupp på cirka tio minuter. Syftet var att se om de förstod frågorna och se vilka sorts svar som uppkom. Detta pilottest tog totalt två timmar. Efteråt reviderades några av instruktionerna i enkäten samt två av frågorna i intervjuguiden. Den andra pilottestningsomgången skedde på ytterligare en CoderDojo, denna gång på Linköpings universitet, fem dagar innan huvuddatainsamlingen. 14 stycken barn deltog under detta tillfälle och de flesta hade en förälder med sig. Deltagarna fick göra uppgifter i CodeArt. Under tiden togs tre av deltagarna åt sidan för att fylla i enkäten. Efter denna pilottestningsgenomgång gjordes inga stora ändringar i enkäten. 3.5 Datainsamling Data samlades in under åtta veckors på en skola i Linköping, med paus under två av veckorna på grund av nationella prov samt påsklov. Två skolklasser i Årskurs 6 deltog i studien: en med 31 elever och en med 32 elever, totalt 63 elever. De deltog i fyra programmeringstillfällen vardera, totalt åtta programmeringstillfällen. Vid första tillfället introducerades studien och CodeArt demonstrerades för eleverna, varpå deltagarna fick fylla i pre-enkäten. Resterande tid tilldelades eleverna var sitt uppgiftshäfte att arbeta med. Vid andra och tredje programmeringstillfället ägnades hela tiden åt att programmera med hjälp av uppgiftshäftet. Under dessa tillfällen närvarade programmeringsassistenter som eleverna åkallade med handuppräckning. Sista programmeringstillfället fick eleverna självständigt utföra en provliknande testuppgift och sedan svara på post-enkäten. Vid eventuell överbliven tid fick de programmera fritt. Efter programmeringstillfällena togs ytterligare en lektion per klass i anspråk för att utföra fokusgruppsintervjuer. Se tabell 1 för sammanfattning av detta. 11

44 Tabell 1. Sammanställning över datainsamlingen. Tillfälle Klass Antal elever Antal programmeringsassistenter Innehåll 1 A 29 3 Presentation/introduktion Pre-enkäter Programmering 2 A 30 3 Programmering 3 B 29 3 Presentation/introduktion Pre-enkäter Programmering 4 B 31 3 Programmering 5 A 28 3 Programmering 6 B 32 3 Programmering 7 A 27 3 Testuppgift Post-enkäter Programmering 8 B 31 2 Testuppgift Post-enkäter Programmering 9 A 2*5 - Fokusgrupp * 2st 10 B 2*5 - Fokusgrupp * 2st Tio stycken deltagare från vardera klass deltog i fokusgrupperna, i två grupper om fem personer. Fokusgrupperna gick till på så vis att deltagarna samlades kring ett bord i ett avskilt rum. Moderatorn berättade vad syftet med fokusgruppen var och informerade om att det skulle spelas in och att deltagande var frivilligt. Samtliga deltagare gav medgivande till sitt deltagande. Samtalen tog cirka 20 minuter vardera och spelades in med en MP3-spelare. Utöver moderatorn närvarade en assistent som tog anteckningar under samtalets gång. 12

45 4. Analys Detta avsnitt beskriver hur bearbetning av insamlade data har skett. 4.1 Enkätanalys Data från de insamlade enkäterna bearbetades med hjälp av datorprogrammet IBM SPPS Statistics 22, i vilket variabler kodades om samt inferentiell statistik utfördes. Microsoft Exel användes för deskriptiv statistik och skapande av diagram. För att undersöka reliabiliteten på de två konstruktena, Attityd och Egenförmåga, så beräknades Cronbach s Alpha. Detta ger ett värde mellan 0 och 1 där allt över 0,7 anses som god korrelation. Vad gäller Attityd-konstruktet blev α = 0,792 för pre-enkäten och α = 0,810 för post-enkäten. Vad gäller Egenförmåga-konstruket blev α = 0,957 för pre-enkäten och α = 0,937 för post-enkäten. Alltså höll båda konstrukt god intern korrelation och samtliga enkätfrågor behölls för analys. Attityd till att lära sig programmera räknades ut genom att först transformera svaren på attitydfrågorna till dess numeriska värde (1 5). Sedan summerades dessa och medelvärdet beräknades per respondent, som alltså varierade mellan 1 och 5. Utefter medelvärdena delades respondenterna in i fem kategorier motsvarande riktning och intensitet av attityd till att lära sig programmera: Mycket negativ (1 medelvärde < 2), Negativ (2 medelvärde < 3), Neutral (Medelvärde = 3), Positiv (3 < medelvärde 4), Mycket positiv (4 < medelvärde 5). Detta gjordes på pre- respektive post-enkäten. Utöver det beräknades respondenternas sammanslagna medelvärde för pre- och post-enkäten. Dessa testades med Wilcoxon signed-rank test för att se om de skiljer sig signifikant. Differensen mellan respondenternas medelvärde i attityd utifrån preoch post-enkät beräknades och plottades ut för att se spridningen. Dessutom beräknades samtliga respondenters medelvärde för frågorna var för sig och dessa rangordnades för att se vilka frågor respondenterna var mest respektive minst positiva till utifrån pre- och post-enkäten. Egenförmåga bedömdes i styrka. Styrkan har beräknats genom att transformera svaren på frågorna i egenförmåga till dess numeriska motsvarighet, 1 5. Sedan summerades dessa per respondent och medelvärdet räknades ut som varierade mellan 1 och 5. Utifrån dessa medelvärden klassades eleverna in i fem grupper: Svag egenförmåga (1 medelvärde < 2), Ganska svag egenförmåga (2 medelvärde < 3), Måttlig egenförmåga (Medelvärde = 3), Ganska stark egenförmåga (3 < medelvärde 4), Stark egenförmåga (4 < medelvärde 5). Detta gjordes på pre- och post-enkäten. Utöver det beräknades respondenternas sammanslagna medelvärde för pre- och post-enkäten. Dessa testades med Wilcoxon signed-rank test för att se om de skiljer sig signifikant. Differensen mellan respondenternas medelvärde i egenförmåga utifrån pre- och postenkät beräknades och plottades ut för att se spridningen. Medelvärdet beräknades även per fråga och likt attityd-frågorna rangordnades de utifrån pre- och post-enkäten. Attityd och egenförmåga analyserades även i förhållande till varandra. Detta genom att dela upp respondenterna i tre subgrupper av attityd och beräkna deras egenförmåga. Dessutom utfördes en korrelationsanalys mellan attityd och egenförmåga med Spearmans korrelationskoefficient. Under enkätinsamlingen skedde ett bortfall på 10 respondenter (15,87 %). Detta innebär att det totala antalet respondenter som analys har genomförts på är

46 4.2 Analys av fokusgrupper Data samlades in från fyra fokusgrupper; två stycken grupper innehållandes endast deltagare som var positiva till programmering och en grupp innehållandes endast deltagare som var negativa till programmering. I den fjärde fokusgruppen var en av deltagarna positiv till programmering och resterande negativa. Dock har den positiva deltagarens svar markerats och analyserats tillsammans med de övriga positiva. Inspelningarna från fokusgrupperna fördes över till en dator där de transkriberades grovt med hjälp av uppspelningsprogrammet Audacity samt Microsoft Word. På det transkriberade materialet utfördes sedan en innehållsanalys av samma person som var moderator för fokusgrupperna. Denna analys bestod av fyra steg. Först lästes transkriptionerna igenom och gruppernas diskussion sammanfattades i grova drag för att få en övergripande blick av vad som framkom i respektive grupp (steg 1). Sedan kodades alla transkriptioner öppet och axialt (steg 2). Dessa koder grupperades ihop och bildade teman (steg 3). Analys av koderna skedde både horisontellt, det vill säga att grupperna analyserades tillsammans inom samma attitydgrupper (positiv positiv, negativ negativ), och även vertikalt, det vill säga att grupperna analyserades mellan de olika attitydgrupperna (positiv negativ) (Rausch, 1998, s. 94) (steg 4). Skillnader och likheter skrevs ihop i komprimerad form. Samtliga fyra steg har granskats och kommenterats av fokusgruppassistenten. Se figur 3 för schematisk bild över detta och bilaga 3 för teman och koder. Figur 3. Schematisk bild över analysprocessen av fokusgrupperna. 14

47 5. Resultat Följande avsnitt innehåller det resultat som kommit från analysen av insamlat datamaterial. Först presenteras resultat från enkätundersökningen, sedan de teman som framkommit från fokusgrupperna och till sist en sammanfattning av de noteringar som gjordes under datainsamlingen. 5.1 Bakgrundsinformation Utifrån de respondenter som inkluderades i analysen var en elev 11 år (1,9 %), de flesta 12 år (69,8 %) och drygt en fjärdedel 13 år (28 %). På bakgrundsfrågan gällande programmeringsvana sammanställdes att en majoritet aldrig programmerat förut (73,6 %), knappt en fjärdedel hade programmerat några gånger tidigare (22,6 %) samt två elever som programmerat många gånger tidigare (3,8 %). Det var nästan lika många killar (49 %) som tjejer (51 %) bland respondenterna. 5.2 Attityd Resultatet från analysdelen av pre-enkäten visar att 3,8 % (n = 2) av respondenterna var Mycket negativa till att lära sig programmera; 24,5 % (n = 13) var Negativa till att lära sig programmera; 13,2 % (n = 7) var Neutrala till att lära sig programmera; den största andelen, 37,7 % (n = 20), var Positiva till att lära sig programmera och 20,8 % (n = 11) var Mycket positiva till att lära sig programmera; se figur 4. Attityd till att lära sig programmera före programmerningstillfällena 11 st 20 st 2 st 13 st 7 st Mycket negativ Negativ Neutral Positiv Mycket positiv Figur 4. Fördelning över respondenternas attityd till att lära sig programmera före programmeringstillfällena, antal elever per attitydindelning (Mycket negativ Mycket positiv). Det var alltså fler som från början hade en Positiv Mycket positiv inställning till att lära sig programmera (n = 31, 58,5 %) än de som hade en Negativ Mycket negativ inställning (n = 15, 28,3 %). Resultatet från analysdelen av post-enkäten visar att 20,8 % (n = 11) av respondenterna var Mycket negativa till att lära sig programmera; 39,6 % (n = 21) var Negativa till att lära sig programmera; 11,3 % (n = 6) var neutrala till att lära sig programmera; 18,9 % (n = 10) var Positiva till att lära sig programmera och 9,4 % (n = 5) var Mycket positiva till att lära sig programmera; se figur 5. 15

48 Antal elever Attityd till att lära sig programmera efter programmeringstillfällena 10 st 5 st 11 st Mycket negativ Negativ Neutral 6 st 21 st Positiv Mycket positiv Figur 5. Fördelning över respondenternas attityd till att lära sig programmera efter programmeringstillfällena, antal elever per attitydindelning (Mycket negativ Mycket positiv). Det var således färre som efter programmeringstillfällena hade en Positiv Mycket positiv inställning till att lära sig programmera (n = 15, 28,3 %) än de som hade en Negativ Mycket negativ inställning (n = 32, 60,4 %). Vid jämförelse av resultaten från de båda enkäterna visar det sig att det i de båda negativa attitydgrupperna (Negativ och Mycket negativ) skedde en ökning där fler respondenter var Mycket negativa och Negativa efter programmeringsundervisningen än före. I de båda positiva attitydgrupperna skedde en minskning. Den största skillnaden är bland de som klassificerades som Positiva till att lära sig programmera där tio respondenter färre var positiva efter programmerings-tillfällena, men även gruppen Mycket positiv minskade. Det var en respondent färre som var Neutral till att lära sig programmera efter programmeringstillfällena; se figur Attityd till att lära sig programmera före och efter programmeringstillfällena Mycket negativ Negativ Neutral Positiv Mycket positiv Pre-Enkät 6 20 Post-Enkät Figur 6. Fördelning över samtliga respondenters attityd till att lära sig programmera före och efter programmeringstillfällena, antal elever per attitydindelning (Mycket negativ Mycket positiv). Medelvärdet för samtliga respondenters attityd till programmering före programmeringstillfällena var 3,39 vilket motsvarar Positiv attityd. Efter programmeringstillfällena hade medelvärdet sjunkit till 2,68 vilket motsvarar Negativ attityd; se figur 7. 16

49 Medelvärde 5 4,5 4 3,5 3 2,5 2 1,5 1 Medelvärde i Attityd till programmering 1-5 3,39 2,68 Pre-Enkät Post-Enkät Figur 7. Samtliga respondenters genomsnittliga attityd (på en skala 1 5) till att lära sig programmera före och efter programmeringstillfällena. Resultatet från Wilcoxon signed-rank test visar att respondenternas attitydnivå var signifikant lägre efter programmeringstillfällena (Median = 2,5) än före programmeringsundervisningen (Median = 3,5), z = 5,332, p < 0,01, effektstorlek = 0,52. Differensen i attityd till att lära sig programmera före och efter programmeringstillfällena har beräknats för vardera respondent. Spridningen visas i figur 8. Figur 8. Spridningen över respondenternas förändring i attityd till att lära sig programmera från före till efter programmeringstillfällena. Mediandifferensen är alltså 0,75 i attityd och variationsbredden är 3,5. Tre kvartiler ligger under 0 vilket visar på att majoriteten minskat i attityd. Standardavvikelsen är 0,7. 17

50 Medelvärde Analys har även skett av frågorna var för sig, där medelvärdet räknats ut per fråga för pre- och post-enkäten. En minskning har skett i samtliga attitydfrågor; se figur 9. Dessa skillnader var samtliga signifikanta. 4,5 4 3,5 3 2,5 2 1,5 1 0,5 Attityd per fråga före och efter programmeringstillfällena 0 Tråkigt-Kul Svårt-Lätt Oviktigt-Viktigt Töntigt-Coolt Pre 3,87 2,58 3,4 3,72 Post 2,79 1,92 2,74 3,28 Figur 9. Samtliga respondenters genomsnittliga attityd (på en skala 1 5) till att lära sig att programmera utifrån pre- och post-enkäten, uppdelat per fråga. Den fråga med störst differens handlade om att lära sig programmera är kul eller tråkigt. Där visar medelvärdet innan programmeringstillfällena (3,87) att respondenterna i genomsnitt ansåg att det var Ganska kul, medan de utifrån medelvärdet efter programmeringstillfällena (2,79) ansåg att det var Ganska tråkigt. Med utgångspunkt i dessa medelvärden har frågorna rangordnats för att se vilka som respondenterna var mest respektive minst positiva till före och efter programmeringstillfällena; se tabell 2. Tabell 2. Attitydfrågor rangordnade efter respondenternas medelvärde på pre- och post-enkäten, där ett högre medelvärde ger en högre placering. Placering FÖRE: Att lära sig programmera är EFTER: Att lära sig programmera är 1 Tråkigt-Kul Töntigt-Coolt 2 Töntigt-Coolt Tråkigt-Kul 3 Oviktigt-Viktigt Oviktigt-Viktigt 4 Svårt-Lätt Svårt-Lätt Alltså ansåg respondenterna att lära sig programmera är mer kul och coolt än vad det är viktigt och lätt både före och efter programmeringstillfällena. Däremot skiftade kul och coolt placering så att det innan programmeringslektionerna ansågs vara mer kul än coolt att lära sig programmera och efteråt vice versa. På båda enkäter ansåg respondenterna att lära sig programmera är mer viktigt än vad det är lätt. 18

51 5.3 Egenförmåga Resultatet från delen om egenförmåga i pre-enkäten visar att det var 28,3 % (n = 15) av respondenterna som hade Svag egenförmåga i att lära sig programmera; 24,5 % (n = 13) hade Ganska svag egenförmåga i att lära sig programmera; 7,5 % (n = 4) hade Måttlig egenförmåga i att lära sig programmera; 32,1 % (n = 17) hade Ganska stark egenförmåga i att lära sig programmera och 7,5 % (n = 4) hade Stark egenförmåga i att lära sig programmera; se figur 10. Egenförmåga i att lära sig programmera före programmeringstillfällena 4 st Svag 15 st Ganska svag 17 st Måttlig 4 st 13 st Ganska stark Stark Figur 10. Fördelning över respondenternas egenförmåga i att lära sig programmera före programmeringstillfällena, antal elever per styrka av egenförmåga (Svag Stark). Det var alltså fler respondenter som från början hade en Svag Ganska svag egenförmåga i att lära sig programmera (n = 28, 52,8 %) än de som hade en Ganska stark Stark egenförmåga (n = 21, 39,6 %). Resultatet från delen om egenförmåga i post-enkäten visar att det var 34 % (n = 18) av respondenterna som hade Svag egenförmåga i att lära sig programmera; 26,4% (n = 14) hade Ganska svag egenförmåga i att lära sig programmera; 3,8 % (n = 2) hade Måttlig egenförmåga i att lära sig programmera; 30,2 % (n = 16) hade Ganska stark egenförmåga i att lära sig programmera och 5,6 % (n = 3) hade stark egenförmåga i att lära sig programmera, se figur

52 Antal elever Egenförmåga i att lära sig programmera efter programmeringstillfällena 3 st Svag 16 st 18 st Ganska svag Måttlig Ganska stark 2 st 14 st Stark Figur 11. Fördelning över respondenternas egenförmåga i att lära sig programmera efter programmeringstillfällena, antal elever per styrka av egenförmåga (Svag Stark). Det var alltså fortfarande fler respondenter som hade en Svag Ganska svag egenförmåga i att lära sig programmera (n = 32, 60,4 %) än de som hade en Ganska stark Stark egenförmåga (n = 19, 35,8 %) efter programmeringstillfällena, och denna skillnad har ökat. Vid jämförelse av resultaten från de båda enkäterna visar det sig att fördelningen av egenförmåga inom gruppen ändrades så att fler respondenter klassades som att ha Svag och Ganska svag egenförmåga efter programmeringsundervisningen än före. I de övriga grupperna sjönk antalet så att färre hade Måttlig, Ganska stark och Stark egenförmåga efter lektionstillfällena än före; se figur 12. Egenförmåga i att lära sig programmera före och efter programmeringstillfällena Svag Ganska svag Måttlig Ganska stark Stark Pre-Enkät Post-Enkät Figur 12. Fördelning över samtliga respondenters egenförmåga i att lära sig programmera före och efter programmeringstillfällena, antal elever per styrka av egenförmåga (Svag Stark). Medelvärdet för samtliga respondenters egenförmåga till programmering innan lektionstillfällena var 2,71 vilket motsvarar Ganska svag egenförmåga. Efter lektionstillfällena hade medelvärdet sjunkit till 2,58 vilket också motsvarar Ganska svag egenförmåga; se figur

53 Medelvärde Egenförmåga i programmering ,5 4 3,5 3 2,5 2 1,5 1 2,71 2,68 Pre-Enkät Post-Enkät Figur 13. Samtliga respondenters genomsnittliga egenförmåga (på en skala 1 5) i att lära sig programmera före och efter programmeringstillfällena. Resultatet från Wilcoxon signed-rank test visar att respondenternas egenförmåga var ickesignifikant lägre efter programmeringsundervisningen (Median = 2,45) än före programmeringsundervisningen (Median = 2,91), z = 0,836, p = 0,403, effektstorlek = 0,08. Alltså har en liten minskning i egenförmåga skett som inte är signifikant. Differensen i egenförmåga till att lära sig programmera före och efter programmeringstillfällena har beräknats för vardera respondent. Spridningen visas i figur 14. Figur 14. Spridningen över respondenternas förändring i egenförmåga i att lära sig programmera från före till efter programmeringstillfällena. Mediandifferensen är alltså 0,18 i egenförmåga och variationsbredden är 4,73. Standardavvikelsen är 0,98. Ett intressant bifynd uppkom vid analys av respondenterna utifrån vilken styrka av egenförmåga de hade innan programmeringstillfällena (Svag Stark egenförmåga) och om denna har ökat eller minskat. I samtliga grupper var det en majoritet som minskade i styrka från pre- till post-enkäten, 21

54 Medelvärde förutom de som hade Svag egenförmåga. Av dessa 15 respondenter var det 12 stycken (80 %) som ökade styrkan i sin egenförmåga: från 1,49 i genomsnitt, vilket motsvarar Svag egenförmåga, till 2,17 i genomsnitt, vilket motsvarar Ganska svag egenförmåga. Denna förändring testades med Wilcoxon signed-rank test och visade sig vara signifikant, alltså ökade egenförmågan i programmering hos de med Svag egenförmåga innan programmeringstillfällena (Median = 1,45) till Ganska svag egenförmåga efter programmeringstillfällena (Median = 1,91), z = 2,701, p = 0,007, effektstorlek = 0,26. Frågorna har även analyserats var för sig. Där visar det sig att respondenternas genomsnittliga styrka i egenförmåga minskat på samtliga frågor förutom fråga 3 ( Jag kan lära mig att ändra och lägga till i kod som någon annan har skrivit ) och fråga 4 ( Jag kan lära mig att skriva kod som en dator kan läsa och utföra ) där den ökat något; se figur 15. 3,5 Egenförmåga per fråga före och efter programmeringstillfällena 3 2,5 2 1,5 1 Fråga 1 Fråga 2 Fråga 3 Fråga 4 Fråga 5 Fråga 6 Fråga 7 Fråga 8 Fråga 9 Fråga 10 Fråga 11 Pre 2,94 2,75 2,79 2,81 3,25 2,58 2,6 2,53 2,11 3 2,47 Post 2,79 2,68 2,81 3,02 2,75 2,47 2,3 2,36 1,91 2,85 2,42 Figur 15. Respondenternas styrka i egenförmåga (Svag Stark) i att lära sig att programmera utifrån pre- och postenkäten, uppdelat per fråga. Samtliga dessa differenser var dock icke-signifikanta förutom fråga 5 (Jag kan lära mig att göra enkla program). Där sjönk respondenternas egenförmåga från före (Median = 3) till efter programmeringstillfällena (Median = 3), z = 2,389, p = 0,017, effektstorlek = 0,23. Utifrån medelvärdena för vardera fråga har de rangordnats för att se vilka som respondenterna hade starkast respektive svagast egenförmåga i före och efter programmeringstillfällena, se tabell 3. 22

55 Tabell 3. Rangordnade frågor (1 11) utefter styrka i respondenternas egenförmåga i att lära sig programmera före och efter programmeringstillfällena, ju starkare egenförmåga desto högre placering. Placering PRE: Jag kan lära mig POST: Jag kan lära mig 1 att göra enkla program (Fråga 5). att skriva kod som en dator kan läsa och utföra (Fråga 4). 2 att göra en enkel animering i CodeArt (Fråga 10). att göra en enkel animering i CodeArt (Fråga 10). 3 de grundtankar som programmering bygger på (Fråga 1). att ändra och lägga till i kod som någon annan har skrivit (Fråga 3). 4 att skriva kod som en dator kan läsa och utföra (Fråga 4). de grundtankar som programmering bygger på (Fråga 1) 5 att ändra och lägga till i kod som någon att göra enkla program (Fråga 5). annan har skrivit (Fråga 3). 6 att förstå vad kod som någon annan att förstå vad kod som någon annan skrivit gör (Fråga 2). 7 att programmera så pass bra att om det var ett ämne i skolan skulle jag få bra betyg i det (Fråga 7). skrivit gör (Fråga 2). olika sorters programmeringsspråk (Fråga 6). 8 olika sorters programmeringsspråk (Fråga 6). att göra ett konstverk i CodeArt (Fråga 11). 9 att skriva kod själv från början utan att det finns kod att bygga vidare på (Fråga 8). att skriva kod själv från början utan att det finns kod att bygga vidare på (Fråga 8). 10 att göra ett konstverk i CodeArt (Fråga 11). att programmera så pass bra att om det var ett ämne i skolan skulle jag få bra betyg i det (Fråga 7). 11 att göra avancerade program (Fråga 9). att göra avancerade program (Fråga 9). Vad som visar sig av detta är att frågorna 1, 3, 4, 5 och 10 alla tycks ha högre styrka i egenförmåga hos respondenterna än de resterande frågorna 2, 6, 7, 8, 9 och 11 både före och efter programmeringstillfällena, där endast interna skiftningar av placering sker. Fyra frågor behåller samma placering; frågan om att kunna lära sig att göra avancerade program (fråga 9) ligger på lägst styrkenivå i egenförmåga och frågan om att kunna lära sig att förstå vad kod som någon annan skrivit gör (fråga 2) ligger på samma plats i mitten både före och efter programmeringstillfällena, samt frågan om att kunna lära sig att göra en enkel animering i CodeArt som ligger näst högst upp och frågan om att kunna lära sig att skriva kod själv från början utan att det finns kod att bygga vidare på som ligger på 9:e placering. Den fråga som gjort störst förändring i placering är tidigare nämnda fråga 5 vars differens var signifikant, att kunna lära sig att göra enkla program, som innan programmeringstillfällena rankades som starkast egenförmåga hos respondenterna och efteråt sjönk till en 5:e plats. 5.4 Attityd och egenförmåga Egenförmåga har analyserats utifrån subgrupper uppdelade efter attityd till att lära sig programmera på post-enkäten, alltså efter programmeringstillfällena. Respondenterna delades in 23

56 i tre attitydsgrupper: de som hade Positiv till Mycket positiv attityd, de som hade Neutral attityd och de som hade Negativ till Mycket negativ attityd. Nedan presenteras diagram som visar hur stor andel av respektive subgrupp som hade Svag, Ganska svag, Måttlig, Ganska stark och Stark egenförmåga; se figur Egenförmåga hos respondenter med Positiv - Mycket positiv attityd till att lära sig programmera, efter programmeringstillfällena 20 % 20 % Svag Ganska svag 53,33 % 6,67 % 0 % Måttlig Ganska stark Stark Figur 16. Fördelning över Positiva till Mycket positiva respondenters egenförmåga i att lära sig programmera efter programmeringstillfällena (Svag Stark). Av de 15 respondenter som var Positiva till Mycket positiva till att lära sig programmera var det en stor majoritet som hade Stark till Ganska stark egenförmåga, 11 stycken (73,33 %). Ett fåtal (n = 3) hade Svag egenförmåga, en hade Ganska svag egenförmåga och ingen hade Måttlig egenförmåga. Egenförmåga hos respondenter med Neutral attityd till att lära sig programmera, efter programmeringstillfällena 50 % 0 % 0 % 0 % Figur 17. Fördelning över Neutrala respondenters egenförmåga i att lära sig programmera efter programmeringstillfällena (Svag Stark). Av de 6 respondenter som var Neutrala till att lära sig programmera var det hälften som hade Ganska svag egenförmåga (n = 3) och hälften som hade Ganska stark egenförmåga (n = 3). 50 % Svag Ganska svag Måttlig Ganska stark Stark 24

57 Egenförmåga hos respondenter med Negativ - mycket negativ attityd till att lära sig programmera, efter programmeringstillfällena 6,25 % 15,6 % 31,25 % 0 % 46,9 % Svag Ganska svag Måttlig Ganska stark Stark Figur 18. Fördelning över Negativa till Mycket negativa respondenters egenförmåga i att lära sig programmera efter programmerings-tillfällena (Svag Stark). Av de 32 respondenter som var Negativa till Mycket negativa till att lära sig programmera var det en majoritet som hade Svag till Ganska svag egenförmåga, 25 stycken (78,15 %). Ett fåtal (n = 2) hade Måttlig egenförmåga, fem hade Ganska stark egenförmåga och ingen hade Stark egenförmåga. Sammanställning över detta kan ses i tabell 4. Tabell 4. Sammanställning över fördelning av styrka i egenförmåga i att lära sig programmera, uppdelat på attitydindelning. Attityd Egenförmåga Svag Ganska svag Måttlig Ganska stark Stark Summa Positiv Mycket positiv 20 % 6,67 % 0 % 53,33 % 20 % 100 % Neutral 0 % 50 % 0 % 50 % 0 % 100 % Negativ Mycket negativ 46,90 % 31,25 % 6,25 % 15,60 % 0 % 100 % Resultatet från analys med Spearmans korrelationskoefficient visar att respondenternas attityd från post-enkäten korrelerar positivt med deras egenförmåga från post-enkäten (rs = 0,656), detta är signifikant med p < 0,01. Alltså finns det ett positivt samband mellan deltagarnas attityd och egenförmåga till att lära sig programmera efter programmeringstillfällena. Detta samband fanns även utifrån pre-enkäten, där Spearmans korrelationskoefficient mellan respondenternas attityd till och egenförmåga i att lära sig programmera var rs = 0,567 med p < 0, Teman från fokusgrupperna I tabell 5a 5c nedan följer en sammanställning över teman som framträtt under fokusgrupper med deltagare negativa (n = 9) respektive positiva (n = 11) till att lära sig programmera. Den negativa gruppen hade ett medelvärde på attitydskalan på 1,44 (motsvarande Mycket negativ) och de positivas medelvärde på attitydskalan var 4,02 (motsvarande Mycket positiv). Deras skillnader redovisas i respektive kolumn och likheter som både negativa och positiva framhöll redovisas i en egen kolumn. För en icke komprimerad version av koderna se bilaga 3. 25

58 Tabell 5a. Sammanställning över teman från fokusgrupperna uppdelat på de som klassificerats ha negativ respektive positiv attityd till att lära sig programmera, samt likheter om uppkom under alla fokusgrupper. Teman Erfarenhet av programmering Negativa till att lära sig programmering Lite eller ingen erfarenhet. Positiva till att lära sig programmering Måttlig eller mycket erfarenhet. Likheter Förväntningar på programmeringstillfällena Förändring i syn på programmering Upplägget på programmeringstillfällena, negativt Upplägget på programmeringstillfällena, positivt Uppgiftshäftet Programmeringsassistenter Hade antingen inga förväntningar eller trodde att det skulle vara fartfyllt och inte så mycket siffror. Negativt ändrad syn på programmering. Tråkigt med självständigt arbete, tappade lätt koncentrationen när det blev för svårt. Uppgifterna var för styrda och repetitiva. Man tappade lusten när man inte kände att man klarat av något. Kul när man kände sig duktig i början. Då missade de även matten, vilket uppskattades. Svårt att förstå när det var mycket text och svåra ord. Frustrerande om man hade problem med en uppgift och blev hänvisad till häftet. Dock var sista sidan med kod hjälpande och det var bra att alla kunde jobba i sin egen takt. Bra att kunna fråga dem om saker men ibland var de inte tillräckligt förklarande utan gav endast rätt svar. Trodde att de skulle arbeta i ett annat programmeringsspråk och lära sig något nytt. Förväntade sig även fler genomgångar. Inte särskilt förändrad syn på programmering, men fått upp ögonen för att det kan användas på olika sätt. Det skedde en plötslig ökning i svårighetsgrad på uppgifterna. Man hann inte alltid fråga det man skulle fråga och det var för lite genomgångar. Det var roligt att lära sig animation. Bra att man fick jobba i egen takt och lära sig hur koordinatsystemet fungerar. Uppgiften med tre cirklar var också kul Bra att ha uppgifter att utgå ifrån. De gav tillräckligt med hjälp och man förstod det mesta, om man inte gjorde det experimenterade man lite själv istället. Tyckte att det skulle bli kul. För lång tid mellan programmeringstillf ällena, man hann glömma bort saker och behövde kolla tillbaka på gamla uppgifter för att ta sig framåt. De första uppgifterna var mycket lätta. 26

59 Tabell 5b. Sammanställning över teman från fokusgrupperna uppdelat på de som klassificerats ha negativ respektive positiv attityd till att lära sig programmera, samt likheter om uppkom under alla fokusgrupper. Teman CodeArt Testuppgiften Förståelse för programmering Förbättringsförslag Negativa till att lära sig programmering Konstprogrammering var inte så kul, det var ett komplicerat sätt att göra saker man lika gärna kan göra i paint. Jobbigt att inte få hjälp. Förstod inte särskilt mycket och behövde fråga om hjälp ofta. Vill ha mer lektionsliknande undervisningstillfällen där en lärare går igenom grunderna på tavlan först. Mer fria uppgifter och få använda programmering till något man själv gillar. Även möjlighet att få programmera tillsammans med andra. Positiva till att lära sig programmering Verkar svårare än annan programmering. Rolig, ganska enkel till en början men svårt att flytta på solen i slutet. Svårt att förstå hur man får saker att flytta på sig. Man kunde skriva av kod från häftet utan att förstå vad den betydde, men om man läste igenom den kunde man få mer förståelse. Mer förklaring till vad koderna betyder och fler avancerade uppgifter. Likheter Svår uppgift. Fler lektioner med mindre mellanrum. Ha ett projekt som man jobbar med över flera lektioner. Programmering, negativt Programmering, positivt Det är för komplicerat/svårt vilket gör det tråkigt. Det är långtråkigt att sitta framför en dator i flera timmar. Kul att få förståelse för datorer. Ganska kul att programmera när man känner att man kan något. Jobbigt att behöva skriva om allting och veta vart man sätter ut kommatecken och andra små detaljer. Svårt att få saker att flytta på sig. Kan göra mycket och olika saker med enkla koder, är inte jättesvårt. Roligt med animeringar och att färglägga. Kul när det går bra. 27

60 Tabell 5c. Sammanställning över teman från fokusgrupperna uppdelat på de som klassificerats ha negativ respektive positiv attityd till att lära sig programmera, samt likheter om uppkom under alla fokusgrupper. Teman Egenförmåga Programmering som obligatoriskt skolämne Intresse av att fortsätta med programmering Framtidssyn på programmering Negativa till att lära sig programmering Lärde sig en del men har glömt bort det mesta nu, är inte så bra på datorer. Tror dock att man skulle kunna gräva fram grundkunskaperna. Programmering blir nog lättare när man väl kommer in det men avancerad kod är dock för svårt för att lära sig. Om man lär sig mer kommer man ändå glömma bort det. Skulle kunna vara obligatoriskt om man inte får betyg i det utan betygsliknande omdömen. Vill inte programmera mer, inte tillräckligt kul/intressant. Eventuellt kan man fortsätta i framtiden, har ändå lärt sig lite. Tror inte att en själv kommer ha nytta av programmering. Det är dock bra att folk lär sig programmera, viktigt för utvecklingen av teknik. Om man vill bli ingenjör är det bra att kunna programmera. Positiva till att lära sig programmering Skulle kunna bli riktigt bra på programmering. Kan kanske lära sig att skriva avancerad kod i framtiden. Skulle vara kul att ha som skolämne, få hjälp av lärare och slippa lära sig själv. Vill fortsätta programmera, skulle vara kul att göra spel. Kommer att ha användning för programmeringskunskape r. Eftersom programmering utvecklas behövs kunskap om det. Likheter Skulle lära sig mer om man fick mer utbildning i det. Bör vara valfritt, exempelvis elevens val. Bra om man lär sig i ung ålder för då blir det lättare sen. Viktigt för framtiden. 28

61 5.6 Noteringar vid datainsamling Följande utsaga baseras på noteringar från datainsamlingen: Under programmeringstillfällena satt somliga och jobbade på och försökte lära sig medan andra gav upp lätt och inte försökte i samma utsträckning. De som jobbade på gjorde inte lika mycket väsen av sig, varför det finns mer anteckningar om de som avvek från uppgiften. Generellt sett var det ungefär hälften av respondenterna som ägnade sig åt programmering hela lektionen och hälften som tappade fokus av olika anledningar. Eleverna satt två och två vid sina bord med en var sin laptop på vilken de programmerade, med undantag för några få som satt själva. Det var flertalet elever som jämförde med varandra hur långt de kommit och vissa tog hjälp av de som kommit längre i uppgifterna. Många elever hjälptes åt med sin bordsgranne medan vissa arbetade mer självständigt. Bland de som inte sysslade med programmering var det vanligast förekommande att de kollade på exempelkonstverken och lekte med dem, kollade runt i galleriet, gick ut på internet, googlade runt eller kollade sin mail. Vissa hoppade över uppgifter och gjorde dem inte i rätt ordning. Somliga sprang runt till andra elever och störde dem. Detta kunde skapa en stökig miljö. Några gånger fick läraren ingripa och säga åt eleverna. Galleriet, där alla sparade konstverk samlas, utnyttjades som ett kommunikationsmedel av en del elever. Några blev inspirerade av de andras konstverk medan andra använde det för att vara lustiga och/eller taskiga. Faktumet att de anonymt kunde spara bilder med diverse olika namn gjorde nämligen att vissa elever tog sig friheter och sparade bilder med fula namn etc. Detta upprörde de elever som blev utsatta och skapade en orolig stämning i klassrummet. Den visuella feedbacken som ges i konstprogrammering uppskattades främst när färger ändrades, något som många elever tyckte var häftigt. När eleverna ändrade i koden och inget hände på canvasen ledde det i vissa fall till frustration. När programmeringstillfällena var slut var det somliga elever som packade ihop datorn snabbt och tycktes ivriga att gå, medan andra fortsatte ett tag för att avsluta det de höll på med innan de stängde ned. 29

62 6. Diskussion Nedan följer diskussion och möjliga förklaringsmodeller kring resultaten från studien samt en diskussion kring de metoder som använts och möjliga svaga punkter i studien. 6.1 Resultatdiskussion Trots att minskningen i styrka av egenförmåga inte var signifikant kan det ändå fastslås att den inte ökade. Enligt Banduras teori utgör erfarenhetsbemästring den starkaste källan till egenförmåga, vilket dessa programmeringstillfällen skapar tillfälle för. Eftersom egenförmågan inte ökade bör det innebära att programmeringstillfällena inte gav tillräckligt med lyckade erfarenheter av att lära sig programmera hos eleverna. Specifikt tros testuppgiften kunnat ha haft en inverkan på respondenternas svar på post-enkäten eftersom de utförde den precis innan de svarade på enkäten. Det framkom under fokusgrupperna att testuppgiften var mycket svår och att flertalet inte klarade av den eftersom det var så stort hopp i svårighetsgrad från vad de gjort tidigare. Fokusgruppdeltagare om att testuppgiften var svår: Elev: Det där provet vi hade innan ni skulle sluta programmeringen, ah det var ju jättesvårt för ni hjälpte ju inte så och man förstod inte häftet, i alla fall inte jag. Elev: Sista? Jag tyckte den var svår. Eller alltså att flytta på solen det tyckte jag var svårt. Om många misslyckades med testuppgiften bör detta således ha influerat egenförmågan negativt hos eleverna. Detta blir ännu mer troligt om åtanke tas till att eleverna inte haft så mycket tid att bygga upp egenförmågan på de få programmeringstillfällen de hade innan. Egenförmåga påverkar hur uthållig en person är i sitt utförande av en uppgift och hur väl denne hanterar motgångar. Som noterades under datainsamlingen var det många av eleverna som gav upp efter en viss tid in i programmeringstillfället. Detta kan kopplas till resultatet från pre-enkäten där 52,8 % hade Svag Ganska svag egenförmåga till att börja med och alltså inte hög uthållighet. Därför är det viktigt att eleverna får positiva erfarenheter av att lyckas tidigt så att de kan bygga upp egenförmågan och bli uthålligare. Från fokusgrupperna framkom dock att många elever tyckte att programmering var lätt till en början, emellertid handlade det då mycket om att skriva av kod direkt från häftet. Detta tillsammans med att många fick mycket hjälp av programmeringsassistenter och varandra gjorde att flera inte kände att de hade klarat av uppgiften själv. Två deltagare ur negativ fokusgrupp diskuterar att det inte känns som att de klarade av uppgiften själva: Elev 1: Fast då kommer ju frågan också ifall alla frågor är jag förstår inte det här och lärarna svarar genom att skriva rätt svar, då kommer ingen att lära sig så det blir ju lite för och emot. Elev 2: Och det är inte roligt, för då gör ju inte du det. Elev 1: Näej, exakt. 30

63 En deltagare ur negativ fokusgrupp uttrycker att denne kände att den inte hade klarat av uppgiften själv: Elev: Ah, asså, ett problem var väl också att som jag sade förut att många förstår ju inte och då blir det såhär att ah, okej, jag har bara fått hjälp hela tiden och jag har aldrig gjort, det här är liksom, jag har inte gjort det här utan någon annan har gjort det och då är det klart att det inte blir så kul [ ] Enligt Bandura bidrar inte egna erfarenheter som tillskrivs utomstående hjälpmedel till en ökad egenförmåga, vilket således kan vara en förklaring till varför den inte ökade trots att de flesta eleverna klarade av åtminstone några uppgifter. Det positiva resultat som uppkom var att 80 % av de med svagast egenförmåga ökade denna. Detta resultat kan dock väntas eftersom att de som ligger längst ned på en skala inte kan röra sig så mycket annat än uppåt. Dock var ökningen signifikant och skall inte förringas. Programmeringsinterventionen tycks således ha höjt styrkan i egenförmåga bland de som från början hade svagast styrka. Det skulle kunna vara så att de som i princip låg i botten vad gäller styrka i egenförmåga höjde denna genom att endast exponeras för programmering, oavsett hur bra det gick. Spekulativt skulle kunna sägas att från att ha känt att de i princip inte kan lära sig någonting inom programmering (Svag egenförmåga) nu känner att de åtminstone klarar av att lära sig någonting litet, om än inte mycket (Ganska svag egenförmåga). Ur fokusgrupperna framträdde en delad syn på egenförmåga där de med positiv attityd till att lära sig programmera i högre utsträckning hade starkare egenförmåga i att lära sig programmera. Detta bekräftades även av enkätundersökningen med en positiv korrelation mellan attityd och egenförmåga utifrån både pre-enkäten och post-enkäten. Deltagare ur negativ fokusgrupp svarar på fråga om de kan lära sig att skriva avancerad kod: Elev 1: Nej jag tror inte det. Elev 2: Vi skulle glömma det. Deltagare ur positiv fokusgrupp önskar mer avancerade uppgifter så att denne kan lära sig mer: Elev: Det skulle vara roligt om det var lite mer avancerat också, så man skulle kunna lära sig mer. Denna korrelation säger dock inget om riktningen, det vill säga om attityden påverkar egenförmågan eller om egenförmågan påverkar attityden. En indikation på att stark egenförmåga skulle kunna ändra attitydriktningen mot det positiva är att flera elever under fokusgrupperna uppgav att det var kul att programmera när de kände att de kunde någonting, men att det blev tråkigt när det blev för svårt och de tvivlade på sig själva. Fokusgruppdeltagare uttrycker att det var roligt att programmera när denne kände att den klarade av det men tråkigt när det blev för svårt: Elev: [ ] Och sen så efter halva lektionen, första, så var det ganska roligt för då var uppgifterna ändå ganska enkla så man kunde lösa dem själv och känna att åh vad glad jag är för nu har jag löst den här själv, då känner man sig duktig. Men när man kom till uppgift sju och sådär, då tyckte man att det var svårare och man fick hjälp hela tiden och det blev faktiskt ganska tråkigt. [ ] 31

64 Ifall att lära sig att programmera är kul eller tråkigt var en av frågorna för att skapa attitydkonstruktet och om detta är kopplat till egenförmåga kan det mycket väl vara så att egenförmågan influerar attityden. Med detta sagt behöver det inte nödvändigtvis vara ett enkelriktat förhållande utan attityden skulle även kunna påverka egenförmågan samtidigt så att de påverkar varandra. Att attityden till att lära sig programmera sjönk signifikant var det motsatta resultatet mot de förhoppningar som fanns. Från fokusgrupperna kan en möjlig förklaring till den negativa attityden formuleras. Det skulle nämligen kunna vara kopplat till elevernas erfarenhet av och förväntningar på programmering. De negativa hade inte särskilt mycket erfarenhet av att programmera vilket kan ha lett till något orealistiska förväntningar. Tre elever ur de negativa fokusgrupperna uttrycker vad de hade för förväntningar på att lära sig programmera: Elev 1: Asså typ mer action eller vad man ska säga. Elev 2: Jag förväntade mig inte siffror. Elev 3: Jag visste att det fanns något som hette programmera. Men jag trodde inte att det var såhär. När dessa sedan inte möttes sjönk deras attityd till programmering eftersom de trodde att det skulle vara roligare än vad det var. I klassen var det 73,6 % som inte programmerat förut vilket enligt denna förklaringsmodell stödjer varför så många blev negativt inställda till programmering. Bland de positiva fokusgruppdeltagarna däremot hade flera erfarenhet av att lära sig programmera innan programmeringstillfällena. De hade alltså troligtvis mer realistiska förväntningar på hur lärande av programmering skulle vara. Faktumet att de ägnat sig åt det frivilligt visar även på att de från början hade en positiv inställning till det vilket kan ha påverkat deras resultat. Deltagare ur positiv fokusgrupp uttrycker att dennes förväntningar på programmeringstillfällena möttes: Elev: Jag tänkte ungefär att det var så svårt som jag trodde att det skulle vara. En annan möjlig förklaring till varför så många fick en negativ attityd mot att lära sig programmera kan vara den ego-försvarsfunktion som attityder utgör. Denna funktion skyddar mot dålig självkänsla. Det skulle därför kunna vara så att åtminstone några av eleverna utvecklade en negativ attityd mot att lära sig programmera på grund av att det inte gick så bra för dem. Den negativa attityden kan även ha kommit från interventionens upplägg. För att fånga intresset hos någon som aldrig testat på något förut är det viktigt att det görs intressant och inte alltför svårt så att personen i fråga känner att den kan och vill fortsätta med det. Detta tycks inte programmeringstillfällena ha lyckats med. Uppgifterna var för de flesta väldigt enkla i början, då det mest handlade om att skriva av kod som stod i häftet. Detta ledde dock till för lite förståelse för koden och syntax vilket skapade problem senare när uppgifterna blev svårare och deltagarna var tvungna att tänka lite själva. Då blev det inte lika kul längre. Återigen är testuppgiften en faktor som tros ha influerat respondenternas svar på post-enkäten. Denna var för många mycket svår att utföra. Där uppgav de med negativ attityd till att lära sig programmera att det var frustrerande att de inte fick någon hjälp utan enbart blev hänvisade till 32

65 häftet vilket de inte förstod sig på. Detta ger alltså upphov till en emotionell attitydreaktion i form av negativa känslor mot attitydobjektet. Eftersom uppgiften delades ut precis innan post-enkäten kan de negativa reaktioner som uppkom ur frustrationen över testuppgiften ha färgat en del av svaren i enkäten. Även om många inte var positiva till att själva lära sig programmera framgick det att flera ansåg att det är en bra kunskap att ha, likaså bland de som var negativa till att lära sig programmera. I fokusgrupperna diskuterades programmering i allmänhet där flera såg det som nyttigt för framtiden. Deltagare ur negativ fokusgrupp talar om att programmering är viktigt för teknikutvecklingen: Elev: Jag tror det kan vara viktigt faktiskt eftersom, som jag sade förut, datorer och ipads, teknologi liksom, det är väl viktigt för alla kommer att använda det och det kommer användas mer och mer medan tiden går för det utvecklas hela tiden. Deltagare ur positiv fokusgrupp talar om att programmering är viktigt för teknikutvecklingen: Elev: För programmeringen har ju utvecklats nu på senaste tiden så den stoppar väl inte så man kan ju behöva veta mer om det. Detta är intressant eftersom det går emot den värderingsuttryckningsfunktion som attityder har, det vill säga att attitydhållarens attityd ger uttryck för dennes värderingar och självkoncept. Enligt värderingsuttryckningsfunktionen bör de med negativ attityd mot att lära sig programmera inte tycka att det är en bra idé att skaffa sig den kunskapen. Denna diskrepans skulle kunna uppstå av att de ser en allmän nytta i att lära sig programmera men inte vill göra det själva för att de anser att det är för svårt. Denna tes stöds av både pre- och post-enkäten där det var fler som svarade att de tyckte att lära sig programmera är mer viktigt än vad det är lätt. Deltagare ur negativ fokusgrupp om att programmering är viktigt fast svårt: Elev: Vet man hur man gör kan det vara väldigt viktigt men det är också väldigt svårt. Det tycks ändå finnas ett stöd hos eleverna att införa programmeringsundervisning som ett ämne i grundskolan, dock vill de få välja det själva och inte bli tvingade in i det. Detta skulle kunna bero på en känsla hos eleverna av att inte vara tillräckligt duktiga och därför inte få bra betyg vilket gör att de hellre har det som ett valfritt ämne som inte är lika seriöst som övriga grundämnen. Denna reflektion kommer ur fokusgrupperna med negativa elever där de diskuterade möjligheten att få betygsliknande omdömen i programmering, men inte riktiga betyg. Deltagare ur negativ fokusgrupp talar om betygsliknande omdömen: Elev 1: (ohörbart) jag vill också men asså, men jag vill liksom inte betygssätta. Elev 2: Inte betygssätt kanske inte men liksom ändå bedöma det (ohörbart). Varför fokusgruppdeltagarna med positiv inställning till att lära sig programmera hellre ser programmering som valfritt än obligatoriskt skulle kunna bero på att de inser att det är ett omtvistat ämne som många elever inte gillar och därför tycker att det skulle vara bättre om det var valfritt. 33

66 6.2 Metodikdiskussion I denna studie användes en triangulerad ansats där data samlades in med både kvantitativa och kvalitativa metoder genom enkätundersökning och fokusgrupper. En utmaning med denna ansats är att integrera och jämföra resultatet av de olika metoderna på ett bra sätt, men om det lyckas är det även ansatsens styrka. Detta anses ha uppnåtts då samtliga frågeställningar besvarats utifrån enkätresultatet och teman från fokusgrupperna, vilket har gjort det hela mer intressant. Med detta sagt finns det ändå en del förbättringsområden vad gäller metodik. Enkätundersökning Gällande mätning av attityd finns det invändningar mot att använda sig av explicita mått, som denna studie har gjort. En av dessa invändningar är att respondenterna påverkas av vad som är socialt accepterat och inte svarar ärligt på frågorna. Detta tros inte ha skett i denna studie. Om respondenterna hade svarat oärligt och fyllt i vad de trodde var önskvärt skulle en betydligt större andel uppgett att de var positiva till att lära sig programmera. Eftersom majoriteten av eleverna fick en mer negativ attityd efter programmeringstillfällena tros det återspegla en verklig attitydförändring snarare än att de trodde att en negativ attityd till programmering var det önskvärda. Vid val av hur många steg en Likert-skala skall innehålla bör reflektion ske kring om det är ett jämnt eller udda antal. I skalor med ett jämnt antal steg finns ingen mittpunkt och respondenten kan inte svara att denne är neutral. Den tvingas således att ta ställning. På skalor med udda antal steg finns en mittpunkt och respondenten kan ange att denne är neutral i frågan. I enkäten för denna studie fanns fem steg på respektive Likert-skala. Detta på grund av att programmering var ett område som respondenterna inte hade så mycket erfarenhet av sedan tidigare. Därför antogs att några inte hade en uppfattning om ämnet innan och därför rätteligen skulle klassificeras som neutrala vad gäller attityd och måttliga vad gäller styrkan av egenförmåga. Detta visade sig stämma för 7 (inom attityd) respektive 4 (inom egenförmåga) respondenter. En annan sak utifrån enkätens utformning som kan ha haft en inverkan på respondenternas svar är det faktumet att de mest extrema stegen på Likert-skalan i egenförmåga innehöll ordet Jätte, alltså Jätteosäker och Jättesäker. Det får dem att låta ännu mer extrema än vad de skulle ha gjort om det endast stod Osäker och Säker. Detta kan ha påverkat några av respondenterna till att inte välja de svarsalternativen. Vad gäller analysen av enkäten så gör uppdelningen i de fem attitydgrupperna gör att respondenternas svar blir förskjutet från mitten. För att bli Neutral i attityd eller ha Måttlig egenförmåga måste medelvärdet på respondentens svar vara exakt 3. Om en respondents medelvärde i attityd exempelvis skulle bli 2,99 klassificeras denne som Negativ, detta trots att denne ligger närmre 3 (Neutral) än 2 (Negativ). En annan respondent med medelvärde 2 skulle också klassas som Negativ trots att det skiljer nästan ett helt steg (0,99) på skalan mellan de två. Detta sker även på andra sidan mittpunkten (Neutral) där respondenterna klassificeras som positiva så länge deras medelvärde är över 3, även om det skulle vara väldigt nära 3, exempelvis 3,1. Konsekvensen av detta är således att respondenternas svar trycks ut mot kanterna och väldigt få klassificeras som Neutrala i attityd eller Måttlig i styrka av egenförmåga vilket kan få resultatet att verka mer extremt än vad det egentligen är. Att dela in grupperna på detta vis 34

67 grundar sig i att författaren anser att en respondent endast är neutral eller har måttlig egenförmåga om denne ligger exakt i mitten, om denne har minsta förskjutning åt något håll är personen i fråga inte helt neutral eller har inte en måttlig egenförmåga. Denna studie har använt sig av psykometriskt mått för att mäta attityd. Detta innebär att ju fler frågor personen svarar på desto mer precist blir måttet. I enkäten fanns det endast fyra stycken frågor vilket kan anses vara i minsta laget. Dock visade sig konstruktet ha ett högt Cronbachs alpha och det stärker dess reliabilitet. Enkätundersökningen hade ett bortfall på 15,87 % och det bidrar bland annat till en ökning av variansen. Detta har kompenserats för genom att använda icke-parametriskt test. Bortfallet beror på tre saker: för det första var det en av respondenterna som inte fyllde i pre-enkäten seriöst och därför inte anses bidra till ett reliabelt resultat, varför dennes svar togs bort; för det andra var det några elever som inte närvarade vid sista programmeringstillfället och därför inte svarade på postenkäten; och för det tredje var det två elever som på post-enkäten blandade ihop sina elev-id:n och fyllde i fel, därför kunde inte deras svar kopplas ihop med pre-enkäten och togs bort. Fokusgrupper Ett snedsteg som begicks var att det i den första fokusgruppen hamnade en positiv elev bland de negativa. Detta gör att det inte skedde en strikt segmenterad uppdelning av fokusgruppdeltagarna som var tanken. Vad detta skulle kunna tänkas få för konsekvens är att den positiva eleven inte fick komma till tals bland de negativa och uttrycka sina åsikter, vilket sänker studiens validitet. Detta blev dock inte fallet då denna deltagare lyckligtvis var mycket talför och fick fram sina synpunkter. Att samma moderator utfört samtliga fokusgrupper ökar reliabiliteten då variationen i dess utförande hålls låg. Däremot har kodningen skett av endast en person. Det sänker interkodarreliabiliteten och läsaren uppmanas notera att de teman som redovisas endast är en tolkning av rådata och skulle kunna se något annorlunda ut om en annan person gjort den. Dock har transkriptionerna och analysen granskats av fokusgruppassistenten och detta minskar risken för att fokusgruppdeltagarnas utsagor har feltolkats. Huruvida fokusgruppdeltagarnas åsikter representerar alla deltagare i programmeringsinterventionen kan diskuteras. Självfallet skulle en del andra synpunkter dryftas om andra elever deltog i fokusgrupperna. Däremot hölls två grupper per attitydtillhörighet vilka till stor del framhöll samma saker, detta är en indikation på att deras utsagor representerar en generell grund att dra slutsatser ifrån. En annan segmentering av fokusgruppdeltagarna skulle kunnat ha gjorts, exempelvis utefter egenförmåga. Att rekrytera deltagarna utefter attityd valdes på grund av att det är ett av de centrala konstrukten i uppsatsen och att det utifrån enkätundersökningen fanns en signifikant skillnad. Fördelarna med att använda fokusgrupper som forskningsmetod är många. De genererar ett djup som är mycket användbart för att förstå svaret på forskningsfrågan. De är även upptäckande eftersom att deltagarna kan komma med synpunkter som annars inte skulle ha frågats efter i exempelvis en enkät. Fokusgrupper är även lämpliga att använda när barn är involverade eftersom det jämnar ut maktbalansen som annars kan vara skev vid exempelvis individuella intervjuer där 35

68 vissa barn kan känna sig utfrågade och inte vågar säga vad de tycker. Alla dessa positiva delar har upplevts under datainsamlingen för denna studie. Studiens upplägg Eftersom att testuppgiften tros ha påverkat resultatet negativt var det en stor nackdel att ha med den i studien så som den var utformad. Antingen skulle den varit lättare så att fler hade en chans att klara den, eller så skulle den ha utförts efter att eleverna fyllt i post-enkäten. Detta hade troligtvis minskat den negativa inverkan som testuppgiften förmodas ha haft. Även datainsamlingens tidsperiod kan ha inverkat negativt. För att känna att de verkligen lärde sig något och att de skulle kunna lära sig mer kan det för eleverna behövas fler än fyra programmeringstillfällen. Att dessa tillfällen var så pass utspridda lär också ha inverkat negativt. Det gjorde att eleverna fick repetera mycket och gå tillbaka i uppgifterna i början på varje tillfälle och därför inte kände att de gick framåt så snabbt. Etikmässigt är det alltid känsligt att utföra studier med barn. Därför har denna studie varit extra noggrann med att följa etisk forskningssed. Samtycke till att delta i studien har getts av både föräldrar och barnen själva. All insamlad data har anonymiserats och behandlats konfidentiellt. Dock skedde en oförutsedd incident under datainsamlingen; några elever sparade sina konstverk med fula namn och detta upprörde andra elever. Denna situation hanterades av läraren lokalt på skolan. En lärdom av detta är att vid liknande initiativ i framtiden se till att det går att spåra vilket inlogg som sparat vad så att det går att reda ut vem som namngett respektive konstverk vid behov. 36

69 7. Slutsats I detta avsnitt presenteras de slutsatser som dragits kring frågeställningarna för studien. Ändras den uppfattade förmågan att lära sig programmera efter en kort programmeringsintervention? Analys av enkäterna visade att innan programmeringstillfällena hade den genomsnittliga eleven Ganska svag egenförmåga i att lära sig programmera. Efter att ha fått testa på programmering hade genomsnittseleven en något svagare egenförmåga i att lära sig programmera, fortfarande Ganska svag. Alltså indikeras en tendens till minskning i elevernas styrka i egenförmåga efter att ha fått testa på programmering. Den genomsnittliga styrkan i egenförmåga minskade på samtliga frågor förutom fråga 3 Jag kan lära mig att ändra och lägga till i kod som någon annan har skrivit och fråga 4 Jag kan lära mig att skriva kod som en dator kan läsa och utföra. Analys av subgrupper visade att de elever med svagast styrka i egenförmåga innan programmeringstillfällena ökade den efter att ha testat på programmering, och gick från att i genomsnitt haft Svag egenförmåga till att ha Ganska svag egenförmåga. Hur ser eleverna på sin egen förmåga att lära sig programmera? En majoritet av eleverna har svag tro på att kunna lära sig att programmera; enligt post-enkäten var det 60,4 % som hade Svag Ganska svag egenförmåga. Det som eleverna hade starkast egenförmåga i var att kunna lära sig att skriva kod som en dator kan läsa och utföra, lära sig att göra en enkel animering i CodeArt samt att ändra och lägga till i kod som någon annan har skrivit. Från eleverna som deltog i fokusgrupperna framkom att egenförmågan varierade beroende på attitydtillhörighet. De flesta kände att de hade lärt sig en del men det som skiljde de negativa från de positiva var att de negativa uppgav att de glömt bort det mesta och trodde att de skulle glömma bort det igen även om de lärde sig mer. De tror dock att det går att lära sig mer programmering och att det troligtvis blir lite lättare när en väl kommer in det, men att lära sig skriva avancerad kod upplever de ligga alldeles för långt bort för deras förmåga. De med positiv attityd till programmering tror sig kunna bli riktigt bra på att programmera och kanske till och med skriva avancerad kod i framtiden förutsatt att de får öva mer. Det gemensamma ifrån fokusgrupperna är således att merparten av eleverna tror sig kunna lära sig mer programmering, men det skiljer i hur bra de tror sig kunna bli. Detta fynd stöds även av enkätundersökningen där majoriteten av de elever som klassificerades ha Positiv till Mycket positiv attityd till att lära sig programmera även hade Stark eller Ganska stark egenförmåga till att lära sig programmera (73,33 %). Av de som var Negativa till Mycket negativa till att lära sig programmera hade en majoritet Svag eller Ganska svag egenförmåga i att lära sig programmera (78,15 %). En korrelationsanalys mellan egenförmåga och attityd visar att dessa har ett positivt samband. Det tycks följaktligen finnas en koppling i syn på sin egenförmåga i att lära sig programmera och attityd till att lära sig programmera. 37

70 Ändras elevernas attityd till att lära sig programmera efter att ha introducerats till det? Vad enkätundersökningen visar är att elevernas inställning till att lära sig programmera ändrades efter att ha introducerats till det. Attityden till att lära sig programmera sjönk signifikant hos eleverna efter programmeringsundervisningen från att ha varit Positiv till att bli Negativ. Eleverna tyckte att lära sig programmera både blev mindre kul och coolt, samtidigt som det ansågs svårare och mindre viktigt, efter att ha testat på det. Fokusgrupperna stödjer detta resultat då flertalet av de negativa deltagarna uppgav att programmeringen var mindre aktivt och tråkigare än förväntat, vilket ledde till en negativt förändrad syn. Av de som hade programmerat mycket innan ändrades inte uppfattningen nämnvärt, men dessa var en minoritet (3,8 %) av deltagarna. Vad anser eleverna om att lära sig programmera? Från enkätundersökningen kan slutsatsen dras att deltagarna tycker att lära sig programmera är ganska tråkigt (2,79 av 5), svårt (1,92 av 5), ganska oviktigt (2,74 av 5) och ganska coolt (3,28 av 5). De uppfattar det följaktligen som mer coolt än vad det är kul och svårare än vad det är viktigt. De flesta fokusgruppdeltagarna, oavsett attitydtillhörelse, hade en positiv syn på programmering i framtiden och tycker att det är viktigt att folk lär sig det, även om de med negativ attityd inte nödvändigtvis anser att de själva behöver göra det. Deltagarnas personliga intresse av att fortsätta med programmering var således lågt bland de negativa och högre bland de positiva även om alla höll med om att det är en viktig kunskap i dagens tekniksamhälle. Det som framhölls som negativt med att lära sig programmera var främst att det var komplicerat, långtråkigt och svårt att veta hur man ska göra. Det som framhölls som positivt var främst att kunna göra animeringar och många andra saker samt färgläggning. Hur ser elever på programmeringsundervisning i skolmiljö? Majoriteten av deltagarna i fokusgrupperna, med undantag för några deltagare, tycktes nå en konsensus om att programmering bör vara ett valfritt ämne i skolan, liknande elevens val, men att de ändå ska finnas där. De diskuterade dock fördelar med att ha programmering som ett obligatoriskt ämne och kom fram till att det vore en god idé att lära ut det till barn i ung ålder, för att det då blir lättare att lära sig i längden. Några av de med negativ attityd till att lära sig programmera framhöll att de skulle vilja bli bedömda i programmering men inte betygssatta. Hur kan programmeringsundervisning utformas för skolmiljö? Utifrån denna studie kan några slutsatser dras kring utformning av programmeringsundervisning. Eftersom programmeringstillfällena inte var lärarledda lades stort ansvar på att eleverna satt och arbetade självständigt. Detta kräver fokus och koncentration på uppgifterna, något som tycks vara svårt att upprätthålla, speciellt då det inte går framåt för personen. Detta var fallet för flertalet deltagare som helt enkelt tappade fokus när det blev för svårt och därmed tråkigt, vilket noterades under programmeringstillfällena. Därför vore det en god idé att ha programmeringsundervisning under former mer liknande annan skolundervisning där en lärare går igenom viktiga koncept och syntax framme på tavlan först. 38

71 Att det var för stort mellanrum mellan programmeringstillfällena framhölls frekvent, både av de negativa och av de positiva fokusgruppdeltagarna. Dessa mellanrum gjorde att många hann glömma bort vad de lärt sig vid föregående tillfälle och då fick gå tillbaka i uppgiftshäftet. Deltagare från båda attitydtillhörelser lade fram som förbättringsförslag att det bör vara fler lektioner med mindre mellanrum. På dessa lektioner skulle deltagarna kunna ha ett långsiktigt projekt som de jobbar med. Fokusgruppdeltagarna ansåg att de assistenter som deltog vid programmeringstillfällena var bra att ha och kunna fråga om hjälp. Ibland kändes det dock som att de inte förklarade betydelsen av koden tillräckligt bra. De som var positivt inställda till att lära sig programmera uppgav att de vid de tillfällena experimenterade lite själva också, medan de med negativ inställning inte tog samma initiativ. Samtliga elever tyckte ändå att det var bra att ha assistenter som stöd. Därför är det mest positivt att ha programmeringsassistenter närvarande vid programmeringstillfällena. Vad gäller just CodeArt så var det vissa som tyckte att det var ett onödigt komplicerat sätt att rita ut enkla saker som de lika gärna kunde göra i Paint. De med mer positiv inställning tyckte istället att det var ett intressant nytt sätt att skapa saker med programmeringens hjälp. Dock ansåg de som hade programmerat förut att CodeArt verkar svårare än annan programmering. Fokusgrupperna visade att det häfte med uppgifter som var utgångspunkten för programmeringstillfällena var inte optimalt utformat. Synpunkter som framkom var att det var för mycket text som var svår att ta sig igenom och att de inte förstod vad som stod där i. Dock ansåg deltagarna att själva tanken med ett häfte är bra för att det tillåter en att arbeta i sin egen takt, men ett bättre utformat häfte önskas. Förutsatt att uppgifterna omstrukturerades skulle de därför tillsammans med CodeArt kunna användas som verktyg för att introducera barn till programmering. 39

72 8. Framtida forskning Denna studie har fungerat som ett första steg att undersöka hur mellanstadieelever svarar på programmeringsintervention i skolmiljö vad gäller attityd och egenförmåga. Den är inte uttömmande eller definitiv men kan belysa viktiga punkter att ta hänsyn till vid vidare initiativ. Detta är värdefull kunskap för utformandet av programmeringsinterventioner i skolan i framtiden. Att göra en liknande intervention men med de förbättringsförslag som framkom under fokusgrupperna skulle vara intressant. Resultatet bidrar även med mycket information som är värd att ta till sig och beakta i fortsatt forskning. Detta område är som tidigare nämnt hittills relativt outforskat. Däremot är det högst aktuellt och därför bör mycket satsning ske för att undersöka dessa frågor vidare. Vad som skulle vara intressant att titta på är programmeringsundervisning under en längre tidsperiod, för att höja den ekologiska validiteten i studien och göra den mer realistisk mot verkligheten. Det skulle även vara intressant att inkludera fler frågeställningar såsom att utföra programmeringsundervisning med olika plattformar och se vilken som lyckas bäst, göra en uppföljningsundersökning för att se hur många av de elever som introducerats till programmering som faktiskt väljer att studera det vidare i äldre ålder, eller att titta närmre på vilken åldersgrupp som är mest optimal att introducera programmering för. 40

73 Referenser Armoni, M. (2011, December). The nature of CS in K-12 curricula: the roots of confusion. ACM Inroads, Vol 4, No. 4, pp Bandura, A. (1978). Towards a unifying theory of behavioral change. Advances in Behaviour Research and Therapy, Vol 1, Bandura, A. (1996). Multifaceted Impact on Self-Efficacy Beliefs on Academic Functioning. Child Development, 67, Bandura, A. (2006). Guide for constructing self-efficacy scales. In F. Pajares, & T. Urdan, Self- Efficacy Beliefs of Adolescents (pp ). USA: Information Age Publishing, Inc. Bem, D. J. (1972). Self-perception theory. In L. Berkowitz, Advances in experimental social psychology, Vol 6 (pp. 1-62). New York: Academic Press. Benson, J., & Hocevar, D. (1985). The Impact of Item Phrasing of the Validity of Attitude Scales for Elementary School Children. Journal of Educational Measurement, Vol. 22, No. 3, Bong, M. (1997, Mars). Congruence of Measurement Specificity on Relations between Academic Self-Efficacy, Effort, and Achievement Indexes. Chicago, USA. Borgers, N., de Leeuw, E., & Hox, J. (2000). Children as Respondents in Survey Research: Cognitive Development and Response Quality. Bulletin de Méthodologie Sociologique, Burke, Q., & Kafai, Y. B. (2014). Decade of Game Making for Learning: From Tools to Communities. In M. C. Angelides, & H. Agius, Handbook of Digital Games (pp ). Hoboken, New Jersey: John Wiley & Sons, Inc. Campbell, D. T. (1963). Social attitudes and other acquired behavioral dispositions. In S. Koch, Psychology: A study of a science, Vol. 6 (pp ). New York: Mc-Graw-Hill. Eagly, A. H., & Chaiken, S. (1993). The Psychology of Attitudes. USA: Harcourt Brace Jovanovich, Inc. Fazio, R. H. (1995). Attitudes as object-evaluation associations: Determinants, consequences, and correlates of attitude accessibility. In R. E. Petty, & J. A. Krosnick, Attitude strength: Antecedents and consequences (pp ). Hillsdale, NJ: Erlbaum. Haddock, G., & Maio, G. R. (2012). Attitudes. In M. Hewstone, W. Stroebe, & K. Jonas, An Introduction to Social Psychology (5th ed) (pp ). Great Britain: John Wiley & Sons. Katz, D. (1960). The functional approach to the study of attitudes. Public opinion quarterly, Vol. 24, No. 2, Komarraju, M., & Nadler, D. (2013). Self-efficacy and academic achievement: Why do implicit beliefs, goals, and effort regulation matter? Learning and Individual Differences, 25,

74 Korkmaz, Ö., & Altun, H. (2014). A validity and reliability study of the Attitude Scale of Computer Programming Learning (ASCOPL). MEVLANA International Journal of Education, Vol 4, Kreuger, R. A. (1998). Developing Questions for Focus Groups. USA: Sage Publications, Inc. Krosnick, J. A., & Petty, R. E. (1995). Attitude strength: An overview. In R. E. Petty, & J. A. Krosnick, Attitude strength: Antecendents and consequences (pp. 1-24). Hillsdale, NJ: Erlbaum. Lee, J., Park, J.-G., & Hwang, Y. (2013). A Study on General and Specific Programming Self- Efficacy with Antecedents from the Social Cognitive Theory. Journal of Next Generation Information Technology (JNIT), Vol 4, Morgan, D. L. (1998). Planning Focus Groups. USA: Sage Publications, Inc. Pintrich, P. R., & De Groot, E. V. (1990). Motivational and Self-Regulated Learning Components of Classroom Academic Performance. Journal of Educational Psychology, Vol. 82, No. 1, Rausch, M. J. (1998). Analyzing and Reporting Focus Group Results. In R. A. Kreuger, Analyzing & Reporting Focus Group Results (pp ). USA: Sage Publications, Inc. Rosenberg, M. J., & Hovland, C. I. (1960). Cognitive, Affective and Behavioral Components of Attitudes. In M. J. Rosenberg, C. I. Hovland, W. J. McGuire, R. P. Abelson, & J. W. Brehm, Attitude Organization and Change (pp. 1-14). New Haven: Yale University Press. Shaft, T. M., Sharfman, M. P., & Wu, W. W. (2004). Reliability assessment of the attitude towards computers instrument (ATCI). Computers in Human Behavior 20, Smith, M. B., Bruner, J. S., & White, R. W. (1956). Opinions and personality. New York: Wiley. Staats, A. W., & Staats, C. K. (1958). Attitudes established by classical conditioning. The Journal of Abnormal and Social Psychology, 57(1), The CoderDojo Foundation. (2015, Mars 23). CoderDojo. Retrieved from Find your Dojo: The CoderDojo Foundation. (2015, Mars 23). CoderDojo. Retrieved from About: Thomas, L., Ratcliffe, M., & Robertson, A. (2003). Code Warriors and Code-a-Phobes: A Study in Attitude and Pair Programming. ACM SIGCSE Bulletin, Vol. 35, No. 1, Torkzadeh, R., Pflughoeft, K., & Hall, L. (1999). Computer self-efficacy, training effectiveness and user attitudes: An empirical study. Behaviour & Information Technology, 18, Usher, E. L., & Pajares, F. (2008). Self-Efficacy for Self-Reulated Learning A Validation Study. Educational and Psychological Measurement, Vol 68,

75 Wibeck, V. (2010). Fokusgrupper: Om fokuserade gruppintervjuer som undersökningsmetod. Lund: Studentlitteratur. Wiebe, E. N., Williams, L., Yang, K., & Miller, C. (2003). Computer science attitude survey. Computer Science, Zajonc, R. B. (1968). Attitudinal effects of mere exposure. Journal of personality and social psychology, Vol. 9, No. 2, Zimmerman, B. J. (2000). Self-Efficacy: An Essential Motive to Learn. Contemporary Educational Psychology 25,

76 Bilagor Bilaga 1: Pre-Enkäten 44

77 45

78 Bilaga 2: Intervjuguide Intervjuguide för fokusgrupp Öppningsfrågor Vad heter ni? Har ni varit med i någon studie förut? Introduktionsfrågor Hade ni stött på/hört talas om programmering innan de här lektionstillfällena? Vad hade ni för förväntningar innan de här lektionerna började? Övergångsfrågor Många tycker att programmering bör bli ett obligatoriskt ämne i alla skolor, andra tycker inte det, vad tycker ni? Nyckelfrågor Vad tyckte ni om dessa lektioner/konstprogrammering? Positivt/negativt? Har dessa lektioner fått er att ändra på vad ni tycker om att lära er programmera? Var programmering lättare/svårare än ni först trodde? Känner ni att ni har lärt er något på dessa lektioner? Mycket/lite? Känns programmering som något ni kan lära er? Varför/varför inte? Vill ni lära er mer programmering? Varför/varför inte? Avslutande frågor Är det någon som har något mer att tillägga? Känner ni att vi missat att ta upp något? Sammanfattning Sammanfatta diskussionen och fråga: Är detta en bra sammanfattning över vad som sagts tycker ni? 46

79 Bilaga 3: Teman från fokusgrupper Teman Negativa till att lära sig programmera Positiva till att lära sig programmera Erfarenhet av programmering Förväntningar på programmeringstillfällena Förändring i syn på programmering - Hade hört talas om programmering men visste ej vad det innebär. - Hade inte hört talas om programmering. - Hade inga förväntningar. - Tyckte det skulle vara kul att lära sig programmera. - Verkade coolt. - Förväntade sig inte så mycket siffror. - Förväntade sig action. - Annorlunda. - Mindre aktivt. - Mindre intressant. - Mindre roligt. - Mer långtråkigt. - Hört talas om programmering förut. - Förälder arbetar med programmering. - Har vänner/syskon som programmerar. - Gått på Coder Dojo. - Programmerar på fritiden. - Trodde att det skulle vara ett annat programmeringsspråk. - Förväntade sig fler genomgångar. - Förväntade sig att lära sig någonting. - Tyckte det skulle bli kul. - Lärde sig att man kan använda programmering på flera olika sätt. - Svårare än förväntat. - Lättare i början än förväntat. - Typ samma syn nu som innan. - Visste hur svårt det var sedan innan. Upplägget på programmeringstillfällena, negativt - Tråkigt att sitta ensam och läsa och göra saker utifrån en text. - Lätt att tappa koncentration. - Uppgifterna var för styrda så att friheten försvann. - Tråkigt att ha det FÖR strukturerat. - Tråkigt i slutet när uppgifterna blev svårare. - Tråkigt att skriva samma sak hela tiden, repetitivt. - Inte kul när man inte känner att man gjort något själv. - För långt uppehåll mellan programmeringstillfällena, hann glömma bort. - Var tvungen att läsa om saker. - Tråkiga uppgifter att göra. - Inte mycket motivation att göra jobbiga uppgifter som ändå är tråkiga. - I början var det lite kul när det var enklare. - Kände sig duktig i början när - Hann inte alltid fråga det man skulle fråga. - Plötslig ökning i svårighetsgrad på uppgifterna. - För lång tid mellan programmeringstillfällena. - För lite genomgångar. - Behövde gå tillbaka i uppgifterna. - Mycket lätt i början. - Bra att man fick jobba i egen takt. - Roligt med animation. 47

80 Upplägget på programmeringstillfällena, positivt Uppgiftshäftet CodeArt Testuppgiften Förståelse för programmering Programmeringsassistenter Förbättringsförslag uppgifterna var lättare. - Första lektionen missade de matten, då var många nöjda. - Instruktionshäftena var svåra att förstå. - Positivt med häftet att alla kan jobba i sin egen takt. - Instruktionerna längst bak i häftet var hjälpande. - Frustration över att bli hänvisad till häftet när det ändå inte funkar. - För mycket text i instruktionerna. - Gav inte tillräckligt förklarande svar ibland. - Gav rätt svar endast. - Bra att få hjälp från labbassistenter. - Tycker att just konstprogrammering blev långtråkigt efter någon lektion. - Tråkigt att rita ut simpla grejer med komplicerad kod. - Inte kul med just konstprogrammering, det kan man lika gärna göra i paint. - Testuppgiften var svår. - Jobbigt att inte få hjälp. - Behövde fråga mycket om hjälp. - Förstod väldigt lite. - Förstod ej varför man skrev in så som man gjorde. - Förstod ej vad man skulle göra. - Förstod inte syftet med att lära sig programmera. - Tråkigt när man inte förstår vad man gör. - Färger var lite lättare att förstå. - Ha ett projekt över flera lektioner. - Antingen fler labbassistenter, eller att man förklarar fler saker på tavlan. - Programmera tillsammans med andra. - Fler lektioner med mindre mellanrum. - Muntlig genomgång av grunderna i början. - Uppgiften med tre cirklar var kul. - Bra att lära sig hur koordinatsystemet fungerar. - Bra att ha att utgå ifrån. - Gav tillräckligt med hjälp. - Förstod det mesta från labbassistenterna. - Ibland fick man experimentera själv istället. - CodeArt verkar svårare än annan programmering. - Svår uppgift. - Rolig uppgift. - Svårt att flytta på solen. - Ganska enkel till en början. - Gjorde klart den hemma. - Man kunde kopiera kod från häftet utan att förstå vad den betyder. - Om man läste igenom koden visste man vad den betydde. - Ju mer man förstår av programmering desto roligare är det. - Förstod inte mycket första programmeringstillfället. - Svårt att förstå hur man får saker att flytta på sig. - Förstod inte vissa saker som man skrev in. - Mer förklaring av vad koderna betyder. - Fler lektioner med tätare mellanrum. - Fler avancerade uppgifter. - Programmera ett långsiktigt projekt, t.ex. spel eller app. 48

81 Programmering, negativt Programmering, positivt Egenförmåga - Vill ha mer fria uppgifter istället för att alla gör likadant, t.ex. att få välja färger själv. - Skriva ned koder för hand innan man testar dem på datorn. - Mindre text i instruktionshäftet. - Använda programmering till något man gillar att göra. - För komplicerat/svårt. - Tråkigt att siffa framför en dator i flera timmar. - Tråkigt med programmering för att man inte kan någonting. - Långtråkigt med programmering. - Kul att programmera när man känner att man kan något. - Kul att få en förståelse för vad programmering innebär och hur datorer fungerar. - Programmering var ganska roligt. - Programmering var både kul och tråkigt. - Går att göra programmering roligare om man förstår mer. - Lärde sig en del men har glömt bort det nu. - Skulle kunna gräva fram grundkunskaperna i bakhuvudet. - Tror inte att det går att lära sig skriva avancerad kod. - Tror att man kan lära sig mer om man får fler lektioner och satsar på det. - Tror att programmering blir lättare när man väl kommer in i det. - Antar att man kommer glömma bort det man lärt sig, även om man lär sig mer. - Tror att man kan lära sig grunderna och i alla fall ha lite lättare för programmering än de som inte lärt sig det förut. - Är inte så bra på datorer. - Skulle lära sig av programmeringsundervisning men inte få bra betyg. - Jobbigt att behöva skriva om allting. - Jobbigt med kommatecken, vet inte vart de ska vara. - Svårt att veta hur man ska göra och vad man ska skriva in. - Det svåraste var att sätta ut grundkoderna. - Svårt att få saker att flytta på sig. - Kan göra mycket med enkla koder. - Kul om man lär sig det snabbt. - Kan göra många olika saker. - Roligt att färglägga saker. - Kul när det fungerar. - Roligt med animeringar. - Är inte jättesvårt. - Inte lika bra på programmering som sina vänner. - Känner att man lärt sig lite av programmeringstillfällena. - Kan sätta ut en bakgrund. - Svårt att göra någonting helt nytt. - Skulle bli bra på programmering om man gjorde det ofta. - Lättare med animering än vad det först verkade. - Kan inte skriva avancerad kod nu, men kanske i framtiden. - Går att bli riktigt bra på programmering om man fick mer utbildning. 49

82 Programmering som obligatoriskt skolämne Intresse av att fortsätta med programmering Framtidssyn på programmering - Man borde få välja om man vill programmera eller inte. - Tycker att programmering kan vara obligatoriskt om det liknar annan undervisning mer. - Skulle vara okej eftersom man lär sig något av det. - Skulle vara lättare om man börjar i ung ålder. - Vill inte bli betygssatt, men ändå bedömd. - Vill få betygsliknande omdömen i programmering. - Finns en nytta i att lära sig programmera om man börjar med det i ung ålder. - Vill inte programmera igen. - Svårt att säga nu om man vill fortsätta med programmering, kanske i framtiden. - Inte intresserad av att programmera frivilligt. - Har ändå lärt sig lite, kan lika gärna fortsätta. - Är inte tillräckligt kul för att fortsätta med. - Programmering är för tråkigt/ointressant för att fortsätta med. - Tror inte programmering blir roligare med tiden, vill därför inte fortsätta. - Tror inte att man kommer ha nytta av det man lärt sig. - Bra att kunna programmera om man vill bli ingenjör. - Bra för framtida yrken. - Viktigt för vårt teknikanvändande. - Tror att teknikanvändandet kryper ned i åldrarna. - Viktigt för utveckling av teknik. - Bör vara valfritt. - Kan finnas i gymnasiet. - Bör lära sig grunderna tidigt. - Kan ha det som elevens val. - Skulle vara kul att ha som skolämne. - Att lära sig programmera är en bra sak. - Om man lär sig det tidigt blir det inte lika svårt/tråkigt sen. - Bra att få hjälp av läraren och slippa lära sig själv. - Skulle vara kul att göra spel. - Vill programmera mer. - Kommer ha användning av programmeringskunskaper. - Ha nytta av att ha lärt sig ett nytt programmeringsspråk. - Programmering fortsätter att utvecklas, därför behövs kunskap om det. 50

83 Konstprogrammering i skolor: en litteratur och interventionsstudie Karl Hörnell Linköpings Universitet Sammanfattning Datorer och teknik blir en allt mer naturlig del av vår vardag, ändå finns inom grundskolan inget ämne som närmare tar upp hur denna teknik fungerar. Det ses idag som helt naturligt att alla måste lära sig matematik, kemi, fysik, och andra ämnen som hjälpt till att bygga upp vårat samhälle, oavsett vem man är som person. Varför kan då inte programmering som dessutom kan användas som verktyg inom andra ämnen, bli en naturlig del av grundskoleutbildningen? Rapporten söker svara på detta genom en litteraturstudie samt genom en genomförd interventionsstudie för att introducera programmering, specifikt konstprogrammering i Javascript, för totalt 63 elever i två klasser i årskurs 6 på en mellan-högstadieskola. Vid totalt fyra tillfällen á 60 minuter över loppet av fyra veckor får eleverna lära sig lite om, och prova på att programmera- Vi mäter deras attityd och förståelse för vad programmering är i ett pre-test och ett utökat post-test med specifika kunskapsfrågor för att mäta programmeringsfärdighet. Eleverna visar ökad förståelse för vad programmering är. Deras programmeringsfärdighet ser dock relativt låg ut efter interventionen.

84 KONSTPROGRAMMERING 2 Innehåll Introduktion 5 Syfte Frågeställning Litteraturstudie 5 Hur lär man sig programmering Utmaningar och stöd för lärande av programmering Metod 10 Intervention Datainsamling Analys Resultat 15 Observation Hur kan man bemöta utmaningarna? Resultat för generella frågor om program och kod Resultat för Kunskapstest av programmeringsförmåga Diskussion 20 Metoddiskussion Resultatdiskussion Slutsats 21 Framtida forskning

85 KONSTPROGRAMMERING 3 Figurer 1 Jeliot: visualisering av Javakod Programmeringsvyn i CodeArt Generella frågor om kod pre/post-test Poängfrekvens kunskapsfrågor

86 KONSTPROGRAMMERING 4 Tabeller 1 Paired-samples T-test generella frågor om programmering Deskriptiv statistik för generell kunskap grupperat efter låg-medel-hög attityd och kön Deskriptiv statistik för programmeringsfärdighetstest Poängfrekvens kunskapsfrågor Pearson-Korrelation mellan pre-test och programmeringsfärdighetstest Deskriptiv statistik för SE och Attityd

87 KONSTPROGRAMMERING 5 Introduktion Programmering är en förmåga som vi kan anta blir allt viktigare i vårt samhälle i takt med att vi blir allt mer beroende av teknik. I Skolverkets läroplan från 2011 står att eleven efter grundskolan kan göra väl underbyggda val av fortsatt utbildning och yrkesinriktning, samt även att eleven kan använda modern teknik som ett verktyg för kunskapssökande, kommunikation, skapande och lärande(skolverket 2011). Detta förutsätter dock att eleven får kontakt med programmering under skoltiden, då detta är en viktig del inom flera yrken och högre utbildningar. Ett argument emot kan vara att det ses som tekniskt avancerat och därmed kommer de inte att förstå, men det är också andra skolämnen som kemi eller fysik. Vi går successivt från ett industrisamhälle mot ett informationssamhälle, detta ställer nya krav på arbetskraften och därför också på skolan så att utbildningen återspeglar kraven från samhälle och arbetsgivare (Griffin m. fl. 2012). Vårt projekt som helhet har syftet att generera kunskap om hur barn kan lära sig programmering i skoljmiljö. Genom att använda oss av konstprogrammering kan eleverna med simpel kod få väldigt tydlig förändring på skärmen och det kan också tänkas locka andra än de som annars kommer i kontakt med programmering. Det är idag populärt med så kallade Coder Dojos där barn får pröva på och lära sig programmering runtom i Sverige, dessa är dock ofta fullbokade. För att alla ska få chansen att pröva på och lära sig programmering är det därför skolan en lämplig miljö. Vår studie sker i skolmiljö, vi förväntar oss därför att elevernas attityd, intresse och motivation kommer att variera stort jämfört med hur det ser ut vid frivilliga tillfällen som Coder Dojos. Syfte Syftet med studien är att undersöka hur man skulle kunna introducera programmering i vanliga skolklasser. Detta genom en litteraturstudie samt en kort intervention med det primära syftet att lära eleverna mer om vad programmering respektive program är, och det sekundära syftet att öppna elevernas ögon för programmering i allmänhet. Frågeställning 1. Vad kan elever lära sig om programmering under en kort intervention i skolan? 2. Vad är de tydligaste utmaningarna och hur kan de hanteras? 3. Hur kan man lära ut programmering i skolklasser? Den första frågeställningen besvaras främst igenom interventionsstudien, de andra två främst genom litteraturstudien men även genom interventionsstudien. Litteraturstudie Litteraturstudien har gjorts med fokus på hur programmering kan läras, vilka utmaningar som måste mötas och hur man kan hantera dessa. Därför har sökningen av litteratur utgått ifrån utlärning av programmering i allmänhet och introduktion av programmering för noviser i synnerhet.

88 KONSTPROGRAMMERING 6 Hur lär man sig programmering Enligt Mayer (1981) måste eleven för att inlärning ska ske på ett bra sätt : 1. Ta in den nya informationen i korttidsminnet. 2. Hitta relevant tidigare inlärd information i långtidsminnet. 3. Använda den nya och gamla informationen så att de kan kopplas samman och lagras till långtidsminnet. Detta kallas ideational scaffolding. När tidigare relevant information saknas så blir det svårare för eleven att lära sig den nya informationen, som novis har man ingen eller minimal relevant kunskap. Man kan enligt Mayer (1981) underlätta denna process på främst två sätt, genom att strukturera inlärningen på ett sätt som hjälper eleven att se sambanden mellan olika koncept, och genom att använda konkreta modeller för att representera program, i stil med hur man lär ut matematik med hjälp av t.ex. tändstickor. Mayer (1981) använder sig i sin studie flera konkreta modell som beskriver en dators eller ett datorpgrograms funktioner med t.ex. ett arkivskåp, en sorteringskorg, en whiteboard och ett skrivblock, och visar att elever blir bättre på överföra sin kunskap (transfer) när de blivit introducerade med en sådan modell. Programmering är ett komplext ämne(al-imamy m. fl. 2006; Kelleher och Pausch 2005), det finns tre huvudsakliga kunskapsområden kopplade till programmering: syntaktisk kunskap, konceptuell kunskap, och strategisk kunskap(bayman och Mayer 1988; McGill och Volet 1997). Syntaktisk kunskap syftar här till språkspecifik kunskap i form av syntax, t.ex. att veta hur en loop skrivs i ett aktuellt språk. Konceptuell (eller semantisk kunskap), syftar till förståelse av programmering på en konceptuell nivå, alltså att man förstår de olika delar som ett program består av och hur de kan interagera med varandra. Strategisk kunskap är slutligen förmågan att sammanföra syntaktisk och semantisk kunskap i syfte att lösa programmeringsproblem. Konceptuell och strategisk kunskap sträcker sig tydligt över språkgränser, syntaktisk kunskap är till större delen språkspecifikt, även om likheter mellan olika språk kan finnas (Bayman och Mayer 1988; McGill och Volet 1997). Linn och Dalbey (1985) har utvecklat en tredelat stege som visar hur noviser lär sig programmering, denna stege ser ut som följer: 1. Eleven lär sig språkspecifika kunskaper. 2. Eleven lär sig en mängd mallar och lär sig kombinera dessa för att lösa programmeringsproblem. 3. Eleven utvecklar problemlösningsförmågor som kan användas inom flertalet andra formella system utöver programmering. Denna stege relaterar tydligt till de tre kunskapsområdena syntaktisk, konceptuell, och strategisk kunskap som McGill och Volet (1997) tar upp. Det finns ett löst definierat begrepp som kallas Computational Thinking (CT). Det kopplas i grunden till analytiska och problemlösningsorienterade förmågor mer eller mindre kopplade till datavetenskap och programmering. CT skulle kunna ses som strategisk förmåga, eller det tredje steget i programmeringsstegen. CT har visar sig ha positiv effekt även på problemlösning och tänkande inom

89 KONSTPROGRAMMERING 7 andra områden än datavetenskap (Barr och Stephenson 2011; Bers m. fl. 2014; Ioannidou m. fl. 2011). Enligt Grover och Pea (2013) är essensen av CT att tänka som en datavetenskapsman när man ställs inför ett problem. Min egen tolkning skulle vara att CT till stor del är de strategiska förmågor som McGill och Volet (1997) beskriver som den tredje och sista punkten av programmeringsfärdighet. Det vill säga förmågan att applicera sin kunskap om programmering för att lösa nya problem. Bers m. fl. (2014) visar i sin studie att barn i förskoleåldern med ett åldersanpassat grafiskt programmeringsverktyg kan lära sig simpla programmeringskoncept genom att programmera robotar, i stil med hur de lär sig enklare matematiska koncept som att räkna. De blir även bättre på problemformulering och att systematiskt angripa problem, och mindre rädda för att misslyckas med en lösning de testar, vilket som helhet kan antas vara CT eller en del av CT. Linn och Dalbey (1985) har vid programmeringsinterventioner med språket BASIC, på flertalet mellanstadieskolor undersökt en mängd variabler som kan tänkas påverka uppnådd programmeringsförmåga hos eleverna. De kommer fram till att den största determinatorn för för programmeringsförmåga är kursmaterialet, där explicita och tydliga instruktioner fungerar bättre än någon annan metod. Därefter kommer tillgång till datorer i skolan, med hög tillgång till datorer presterar elever bättre. Samtidigt visar sig tidigare programmeringserfarenhet och kön ha låg eller ingen effekt på programmeringsfärdighet. Linn och Dalbey (1985) såg att elever i vanliga klasser under interventionen inte tog sig särskilt långt på programmeringsstegen, medan elever i vad de kallar exemplariska klasser där det fanns god tillgång på datorer och erfarna lärare närvarande, klarade sig mycket bättre. Deras resultat styrker att vid klassisk programmeringsundervisning sker programmeringsinlärning i den ordning som stegen visar, med språkspecifika kunskaper först, och generell problemlösningsförmåga sist. Guzdial m. fl. (2015) menar att programmering till en början inte borde fokusera på själva programmeringsprocessen, istället borde fokus läggas på att hjälpa eleven förstå programmeringskoncept för att senare introducera programmering som aktivitet. Guzdial m. fl. (2015) pekar på forskning som visar att programmering definitivt är ett steg i att lära sig programmera, men att det steget inte borde vara det första då det lätt överrumplar och förvirrar eleven. I två experiment visar Dyck och Mayer (1989) att elever som först presenteras ett programmeringsproblem uttryckt i engelska, och därefter får det presenterat för sig uttryckt i BASIC, blev bättre på att skriva semantiskt korrekta program, än vad kontrollgruppen som bara fick problemen beskrivna i BASIC. Kontrollgruppen var dock bättre på att skriva syntaktiskt korrekt kod. Detta visar vikten av problemrepresentation och att programmering inte enbart borde läras ut genom att låta elever programmera, men att det finns fördelar med flera ansatser i kombination. Utmaningar och stöd för lärande av programmering Kognitiv belastning (Cognitive Load) presenterades som koncept av Sweller (1988), där han pekade på arbetsminnets vikt vid inlärningen av nya koncept och idéer i form av schemata. Vad som skiljer en novis från en expert inom ett ämne är till stor del de schemata som experten har lagrat i långtidsminnet, och som novisen fortfarande måste lagra in. Denna inlagring kan vara kostsam och innebär också att arbetsminnet måste hålla koll på fler koncept samtidigt, en hög belastning på arbetsminnet kan inverka negativt på överföring av kunskap till långtidsminnet, och därmen också på lärande. Begreppet kognitiv belastning

90 KONSTPROGRAMMERING 8 har därefter förfinats och delats upp i tre olika typer: inre belastning (intrinsic load), vilken beror på kursmaterialets komplexitet och interaktivitet; relevant belastning (Germane load), den belastning som behövs för att skapa nya schemata; och onödig belastning (extraneous load), vilken uppkommer när kursmaterialet presenteras på ett för en elev suboptimalt sätt (Clark m. fl. 2006; Stachel m. fl. 2013; Sweller 1988). Målet vid utlärning måste alltså vara att minska en onödiga belastningen, dvs. att göra kursmaterialet så enkelt som möjligt utan att ta bort någon egentlig kunskap från materialet. Lehrer m. fl. (1999) har jämfört programmering i Logo för årskurs 2 och årskurs 5 och kommer bland annat fram till att det tar längre tid för elever i årskurs 2 att bemästra programmering, vilket attributeras till att eleverna i årskurs 2 har mindre arbetsminne tillgänligt för att utföra uppgiften. Ioannidou m. fl. (2011) menar att det krävs sex olika punkter i en utvecklingsmiljö för att göra det möjligt att få genomslagskraft vid programmeringsundervisning inom grundskolan: 1. Lågt golv, eleven ska lätt kunna producera något konstruktivt. 2. Högt tak, eleven ska kunna göra avancerade program utan att begränsas av verktyget. 3. Scaffolding flow, verktygen och kursplanen ska tillhandahålla språngbädor för lärda moment inklusive utmaningar. 4. Möjliggöra överföring av förmågor, verktyget och kursplanen måste kunna hantera komplexa datavetenskapliga koncept utöver verktygets huvudområde. De borde också stödja eleven i övergången mot riktiga programmeringsspråk. 5. Stödja jämlikhet, aktiviteterna borde vara tillgängliga och motiverande för alla elever oavsett kön eller ursprung. 6. Tillgängligt för lärare, verktyg och kursplan ska vara lätt för lärare att ta till sig och använda för att lära elever.. Dessa krav går som synes även in på kursplanen och de uppgifter som eleverna förväntas göra. Det finns enligt Ioannidou m. fl. (2011) inte något språk eller någon utvecklingsmiljö som uppfyller alla ovanstående punkter.al-imamy m. fl. (2006) menar att syntax tar upp merparten av tiden vid introduktion till programmering vid Sharjah University och att detta stjäl tid från att skapa en konceptuell och strategisk förståelse av programmering. Yousoof och Sapiyan (2014) och Yousoof, Sapiyan och Ramasamy (2008) undersöker visualiseringsmetoder för att minska kognitiv belastning för elever som lär sig programmering. De kommer genom detta fram till att upplevd kognitiv belastning beror på tre faktorer, nämligen, konceptets komplexitet, individen, samt olika visualiseringsmodeller kopplade till koncept och individ. En av visualiseringsmodeller de tittar på är Jeliot som kan ses i figur 1. Där kan vi till vänster se en editor, och till höger se grafiska representationer av koden, i fyra olika fält. En annan visualiseringsmodell de undersöker liknar till större delen UML-diagram (Unified Modeling Language).

91 KONSTPROGRAMMERING 9 Figur 1. Jeliot: visualisering av Javakod Mikael Kölling menar i Utting m. fl. (2010), att barn i 10-års åldern verkar ha svårt att förstå Java-syntax. Det finns dock många språk och projekt utvecklade just i syfte att förenkla introduktionen av programmering, såsom Alice 2, Scratch, Kojo, Logo m.fl. (Graczynska 2010; Kelleher och Pausch 2005; Mohebbi m. fl. 2012; Resnick m. fl. 2009). Kelleher och Pausch (2005) utreder och bygger en taxonomi över verktyg som dessa, ämnade för att förenkla introduktionen av programmering, de identifierar tre huvudsakliga sätt att underlätta programmering: Förenkla programmeringens mekanik (ex. förenkla syntax). Ge stöd för lärande åt eleven. Motivera/engagera eleven. De flesta verktyg siktar på att förenkla syntax och göra programmeringsmekanismen enklare för eleven (Kelleher och Pausch 2005). Det finns även en del forskning på att integrera stöd i form av templates och syntaxhjälp i utvecklingsmiljön vilket kan hjälpa elever att reflektera kring sin programmering och tydliggöra modulariteten i program och programmering (Kordaki 2010; Lehrer m. fl. 1999). Linn och Dalbey (1985) och McGill och Volet (1997) menar att själva processen att lära sig programmering till stor del handlar om att lära sig templates. Den tredje metoden syftar till att göra programmeringen engagerande för eleven genom att koppla programmeringen till en intressant domän, ett exempel finner vi hos Esteves m. fl. (2011), som använde spelet Second Life för att lära elever programmering. Vårt projekt berör de två senare stegen, och riktar främst in sig på att motivera och engagera eleven genom att koppla koden till skapandet av konstverk och animationer.

92 KONSTPROGRAMMERING 10 Metod Studien har bestått av en programmeringsintervention där elever fått pröva på programmering vid fyra olika tillfällen. Datainsamling har skett i form av sparad kod från de uppgifter eleverna gjort, enkäter före och efter interventionen samt genom observation. Enkäterna användes för att främst mäta attityd, upplevd egenförmåga, generell förståelse av program och programmering. post-testen mätte också elevernas programmeringsfärdighet. Intervention Interventionen utformades och genomfördes i syfte att introducera elever för programmering samt samla data till studien. Interventionen beskrivs nedan med fokus på upplägg, material, och teknisk plattform. Interventionsmaterial. Eleverna fick under interventionstillfällena arbeta med uppgifter ur det uppgiftshäfte som vi tagit fram. Vid framtagandet av detta uppgiftshäfte försökte vi fokuera på att blanda styrda och öppna uppgifter, ha många små uppgifter med tydliga svar så att eleven lätt kunde förstå om de gjort rätt. Vi försökte också få in lite häftigare uppgifter som skulle engagera eleverna samt överkurs-uppgifter att arbeta med om man klarat av övriga uppgifter. Vi hämtade inspiration från hemsidor vars ambition är att introducera och lära ut programmering på ett enkelt och roligt sätt, se t.ex. KhanAcademy. Vi försökte också få med ett antal programmeringskoncept såsom variabler, loopar, if-satser m.m. Efter pilottesterna kom vi fram till att mer styrda och explicita uppgifter fungerade bättre. Interventionsupplägg. Interventionen utfördes i två stycken klasser årskurs sex med 31, respektive 32 elever över 3 veckor med fyra interventionstillfällen á 60 minuter per klass och en veckas hål mellan tillfälle 2 och 3. Vid första tillfället hölls en kort introduktion av programmering och vad som skulle ske vid de kommande tillfällena, därefter fick eleverna fylla i för-enkäten och programmera utifrån uppgiftshäftena. Nästa två tillfällen ägnades till fullo åt programmering, och det sista tillfället avslutades med en testuppgift i den utvecklingsmiljö de redan arbetat i och slutligen efter-enkäten. Under interventionstillfällenas programmeringsbit observerades eleverna av två studenter utefter ett observationsprotokoll. Lärare & Handledare. Det fanns alltid tillgång till tre (två vid ett tillfälle) universitetsstudenter som agerade handledare och svarade på frågor eleverna hade kring programmering. Någon ur skolpersonalen närvarade också vid varje tillfälle. De två studenter som observerade hjälpte även till med att svara på elevernas frågor när så behövdes. Teknisk Plattform. Den tekniska plattform som använts vid interventionen kallas CodeArt och har utvecklats vid Institutionen för datavetenskap på Linköpings Universitet i syfte att med konst som medium sprida kunskap om programmering. CodeArt är webbbaserat (besöks via en webbläsare), och består av två huvudsakliga delar, en editor till vänster, och ett canvas till höger, som synes i figur 2. I editorn skriver man javascript-kod, bilden på canvas förändras direkt när man ändrar något i koden. Vi valde att använda oss av CodeArt för att vi ville använda ett språk med riktig syntax där man verkligen programmerar, samtidigt som vi ville ha en domän (konst) som kan engagera elever i allmänhet, och de som inte annars skulle vara intresserade i synnerhet. CodeaArt är baserat på på en Javascript-adaption av det Java-baserade språket Processing, som från början utvecklades för att lära ut programmering med hjälp av en visuell

93 KONSTPROGRAMMERING 11 kontext men kommit att utvecklas till ett verktyg som används av proffs inom flera områden. Det finns i CodeArt en möjlighet att spara vad man skapat, både i form av bild och tillhörande kod. Det finns även möjlighet att nollställa koden/resultatet så att det börjar om från början, detta är främst användbart när man gör någon form av animation som man vill starta om. Vidare kunde felmeddelanden visas längst ner på skärmen, detta var dock inget vi informerade eleverna om, då felmeddelandena ofta var missvisande. Figur 2. Programmeringsvyn i CodeArt Datainsamling Datainsamlingen skedde främst elektroniskt, genom pre-test- och post-test-enkäter samt genom att elever fick spara sina uppgifter i systemet som användes. Alla interventionstillfällen observerades också av två observatörer med hjälp av ett observatinsprotokoll. Instrument. Här redovisas de instrument som använts vid datainsamlingen. Pre-test & post-test. Pre-testet och post-testet bestod av en enkät som alla elever fick fylla i på sina datorer före och efter interventionen, se appendix A. Enkäten syftade till att mäta elevers allmänna förståelse för datorprogram och programering, deras attityd gentemot programmering, samt deras upplevda egenförmåga (Self Efficacy), för att sedermera jämföra dessa värden med motsvarande värden ur post-testet. Kunskapstest. Kunskapstestet bestod av åtta frågor med syfte att mäta elevernas programmeringsförmåga efter interventionen, se appendix B. Dessa frågor beskrivs närmare i metodkapitlets analys-del. Testuppgift. En testuppgift togs fram för att se om eleverna kunde lösa en programmeringsuppgift från grunden. Eleverna fick ett instruktionsblad med instruktioner som sade att de skulle programmera en solnedgång, men inte hur, till skillnad från interventionsinstruktionerna som var mer explicita. Testuppgiften kan ses i appendix D.

94 KONSTPROGRAMMERING 12 Observation. Observationen gjordes vid programmeringstillfällena av två studenter enligt ett observationsprotokoll fokuserat på att försöka fånga upp elevernas attityd, kommunikation mellan varandra och handledare, samt vad eleverna tyckte var svårt. Pilottester. Vi har utfört två pilottestat interventionsförfarandet, uppgiftshäftet, och instrumenten vid två olika tillfällen. Vid första tillfället testades uppgiftshäftet, pretestet, samt observationsförfarandet. Vid andra tillfället testades samtliga ovan nämnda delar, inklusive observationsprotokollet och post-testen med tillhörande kunskapstest. Det första pilottestet genomfördes på en sk. CoderDojo dit barn med intresse för att lära sig programmering kan komma för att få hjälp och inspiration. De som var intresserade av att delta i pilottestet och var i lämplig åldersgrupp fick arbeta med vårt uppgiftshäfte och kunde be om hjälp när så behövdes. Vid andra tillfället bjöds intresserade barn in till universitetet där de fick arbeta med uppgiftshäftet. I slutet av det andra tillfället fick alla elever svara på pre-testen, och några utvalda fick svara på post-testens kunskapstest, stödda av en student. Som resultat av pilottesterna gjordes interventionsuppgifterna mer styrda, och det som eleverna skulle ändra i koden markerades med fetstil. Även någora formuleringar i pretestet ändrades. Analys Här beskrivs analysen av studien. Elevernas kunskap om datorprogram och vad programmering är mättes i ett PRE- och ett POST-test med hjälp av tre frågor med fritextsvar. Utöver detta mättes även deras programmeringsförmåga och kodförståelse som en del av POST-testet (se appendix C). Generell förståelse om datorprogram och programmering. Här beskrivs de frågor som använts för att mäta generell förståelse av datorprogram och programmering, samt hur dessa frågor poängsatts. Frågorna exemplifieras med ett fullpottsvar ur den insamlade datan. Hur fungerar ett datorprogram?. Här får man 1 poäng för svar som indikerar att datorpgrogram byggs upp av kod, exempelvis: Ett dator program läser av en kod som en människa eller en annan dator har skrivit in och utför uppmaningarna i koden. Man fick 0,5 poäng för svar som blandar ihop programmering eller konstprogrammering med datorprogram, ex.: man kan göra en bild genom att skriva på olika tangenter.. Elever som inte svarade eller gav svar som: jag vet inte, fick 0 poäng. Max: 1p Vad gör man när man programmerar?. Här fick elever 1 poäng om de svarade att man vid programmering skriver kod som datorn tolkar, exempevis: Man skriver in en kod som en dator kan läsa och utföra för att få det resultat man vill. 0,5 poäng fick man om man inte generaliserat generaliserar vidare från vårt konstprogrammeringsexempel, t.ex. man gör bilder genom att skriva koder. 0 Poäng fick elever som inte svarade eller svarade saker i stil med: jag har ingen aning fråga ej mig. Max: 1p Vad är kod?. Eleverna fick 1 poäng om de svarade att kod är instruktioner till datorn, t.ex. En kod är ett språk som datorn lyder och följer. De fick 0,5 poäng om de inte tog med att kod tolkas av datorn, eller om de inte generaliserade tillräckligt från vårt konstprogrammeringsexempel, såsom: det är det man skriver för att få fram det man vill

95 KONSTPROGRAMMERING 13 ha i kanvas. 0 poäng har man fått om man inte svarat eller har svarat felaktigt, t.ex. en kod som man slår exempel på mobil,dörrar och sånt där. Max: 1p Programmeringsförmåga. Nedan beskrivs analysen av frågorna ämnade att mäta programmeringsförmåga. Kunskapsfråga 1:. Skriv den kodrad som ritar upp den svarta rektangeln i figur1 nedan. Tänk dig att fill(0,0,0); redan finns (fyller rektangeln med svart färg). Eleverna fick skriva in sitt svar i ett en-rads fritextfält. Eleverna gavs 1 poäng för att ha använt funktionen rect, 1 poäng för att ha angett korrekta koordinater i funktionsanropet, 1 poäng för att ha korrekt bredd och höjd i funktionsanropet och slutligen 1 poäng för korrekt syntax. Max: 4p. Svarsexempel som fått 4p: rect (20,20,40,40) Rader som ändrats av eleven markeras med fetstil. Kunskapsfråga 2:. Titta på figur1 och koden ovan. Hur kan koden ovan förändras så att cirkeln skulle röra sig nerifrån och upp? Eleverna presenterades här med följande kod som de skulle ändra för att producera rätt resultat: var x =30; var y =170; while ( t r u e ){ e l l i p s e ( x, y, 1 0, 1 0 ) ; x=x+0; y=y+0; } Eleverna fick svara i ett fler-rads textfält och hade tillgång till koden ovan i det textfältet. De fick 1 poäng för att ändra från minus till plus på y=y+0, ett poäng för att få y-värdet att ändras i loopen, och -0,5 poäng för att ändra värdet på x. Max: 2p. Svarsexempel som fått 2p: var x =30; var y =170; while ( t r u e ){ e l l i p s e ( x, y, 1 0, 1 0 ) ; y=y 1; } Rader som ändrats av eleven markeras med fetstil. Kunskapsfråga 3:. Kan du ändra koden från uppgift 2 så att cirkeln stannar när den når den svarta rektangeln? Eleverna fick här alltså åter igen ändra i koden från uppgift två, även här i ett fler-rads textfält. De fick 1 poäng för att använda en if-sats, 1 poäng för att ha ett korrekt villkor i if-satsen, och -0,5 poäng för att ha if-satsen utanför loopen. Max: 2p Svarsexempel som fått 2p: var x =30; var y =170; while ( t r u e ){ e l l i p s e ( x, y, 1 0, 1 0 ) ; i f (y>60+5){ y=y 1; } } Rader som ändrats av eleven markeras med fetstil.

96 KONSTPROGRAMMERING 14 Kunskapsfråga 4:. Koden ovan ritar ut en röd cirkel. Förändra if-satsens villkor så att cirkeln blir blå istället. Eleverna presenterades här med följande kod som de skulle ändra för att producera rätt resultat: c o l o r =3; i f ( c o l o r <4){ f i l l ( 2 5 5, 0, 0 ) ; } e l s e { f i l l ( 0, 0, ) ; } e l l i p s e ( 3 0, 1 7 0, 1 0, 1 0 ) ; Eleverna fick skriva in sitt svar i ett en-rads fritextfält. Här fick eleverna 1 poäng för att ändra i if-satsen, och 0,5 poäng för att skriva kod som kan göra cirkeln blå, oavsett if-satsen. Max: 1,5p. Svarsexempel sin fått 1,5p: c o l o r =3; i f ( color >4){ f i l l ( 2 5 5, 0, 0 ) ; } e l s e { f i l l ( 0, 0, ) ; } e l l i p s e ( 3 0, 1 7 0, 1 0, 1 0 ) ; Rader som ändrats av eleven markeras med fetstil. Kunskapsfråga 5:. Läs igenom koden ovan, vad blir värdet på x när koden körts färdigt? Eleverna presenterades här med följande kod, de fick sedan svara på det som en flervalsfråga med tre alternativ för värdet på x: 16, 22, eller 10. var x = 1 0 ; while ( x<15){ x=x+3; i f ( x==14){ x=22; } } Här fick eleverna 1 poäng för rätt svar (16) Max: 1p. Kunskapsfråga 6:. Det är tänkt att koden nedan ska rita upp tre cirklar, men inget ritas upp. Fyll i vad som saknas för att cirklarna ska ritas upp. Eleverna fick skriva sitt svar i ett en-rads textfält.

97 KONSTPROGRAMMERING 15 void setup ( ) { } var x = 1 0 ; var y = 1 0 ; var h e i g h t = 1 0 ; var width = 1 0 ; void d r a w 3 c i r c l e s ( ) { e l l i p s e ( x, y, width, h e i g h t ) ; e l l i p s e ( x+20, y+20, width +20, h e i g h t +20); e l l i p s e ( x+40,y+40, width +40, h e i g h t +40); } Eleverna fick vid rättning 1 poäng för att anropa draw3circles, 1 poäng för att få de tre cirklarna att ritas upp, och 1 poäng för användning av korrekt syntax. Max: 3p. Svarsexempel som fått 2p: void setup ( ) { } var x = 1 0 ; var y = 1 0 ; var h e i g h t = 1 0 ; var width = 1 0 ; void draw(){ e l l i p s e ( x, y, width, h e i g h t ) ; e l l i p s e ( x+20, y+20, width +20, h e i g h t +20); e l l i p s e ( x+40,y+40, width +40, h e i g h t +40); } Rader som ändrats av eleven markeras med fetstil. Kunskapsfråga 7:. Varför kan det vara bra att använda funktioner när man programmerar? Denna fråga presenterades för eleverna som en flervalsfråga med följande tre alternativ: 1. Koden blir lättare att läsa. 2. Kod kan återanvändas flera gånger. 3. Det går inte att programmera utan funktioner. Här fick eleverna 1 poäng för det första alternativet, 1 poäng för det andra alternativet, och -0,5 poäng för det tredje alternativet. Max: 2p. Kunskapsfråga 8:. Varför är det viktigt att skriva ett semikolon i slutet av en rad? Här fick eleverna svara i ett en-rads textfält. Eleverna fick 1 poäng för svar som indikerade att det behövs för att det ska fungera, eller för att markera slutet på en rad, helt enkelt att det är syntax. Max: 1p. Observation. De problem som oftast uppkom för eleverna var syntaxrelaterade (missade parenteser, kommatecken, eller rena stavfel), eller en svårighetatt se var specifik kod skulle infogas (t.ex. vad som ska vara inom en if-sats eller utanför en loop, även när instruktionen specificerade detta). Under observationen noterades också att elever som satt nära varandra ofta hjälpte varandra med programmeringsuppgifterna. Detta märktes både genom vad de sa till varandra och genom att det ofta hände att de hade gjort samma misstag. Många elever gav upp under interventionstillfällena och gjorde inga eller få uppgifter. En del blev också stökiga vilket bitvis påverkade hela klassen. Resultat Här presenteras resultatet från studiens samtliga delar.

98 KONSTPROGRAMMERING 16 Observation Eleverna verkade vara som mest engagerade vid det första programmeringstillfället när programmering var helt främmande för dem. Vid senare tillfällen märkte man att vissa hade fattat tycke för programmering, medan andra definitivt inte verkade tycka om det. Nedan beskrivs vad som verkat svårt för eleverna. Vad var svårt?. Utifrån den observation vi gjort under interventionstillfällena kan vi konstatera att många elever hade problem med att förstå var kodbitar ur instruktionen skulle placeras, t.ex. vad betyder inom draw{} eller under if-satsen. Många hade också stora problem med syntax dvs., skrev fel antingen genom att utelämna t.ex. ett kommatecken, skriva för många kommatecken, eller skriva kommatecknen på fel plats. Även semantiska och procedurala problem uppstod vilket symboliseras av frågor som Hur ritar jag ut en kvadrat?, eleven fick här till svar att man skriver rect(), med rätt parametrar så blir det en kvadrat. Vidare uppkom en del problem med plattformen som användes för interventionerna, den upplevdes bitvis som något instabil då man t.ex. kunde komma åt backspace när man inte var i editorn, vilket i värsta fall ledde till att man fick börja om med den aktuella uppgiften. Det kom även upp problem som var svåra för handledarna att felsöka, oftast för att syntax-felsökning inte fanns inbyggd i systemet, men ibland för att koden betedde sig på ett sätt som inte var tydligt ens för programmeringskunniga universitetsstudenter. Hur kan man bemöta utmaningarna? Utifrån litteraturen kan vi se flera förslag på hur man kan underlätta programmeringsinlärningen för eleven. Sammanfattningsvis kan de viktigaste av dessa förslag anses vara: Förenkla syntax för eleven (antingen genom språkförenklingar eller stöd för syntaxhantering). Ha ett lågt golv (det ska vara lätt för eleven att producera konstruktiv kod). Använd konkreta modeller för att beskriva programmeringskoncept (elever lär sig bättre om de kan koppla inlärd kunskap till koncept de redan känner till). Ha tillgång till erfarna och programmeringskunniga lärare (det är positivt om läraren har god förståelse av materialet). Använd tydliga och explicita instruktioner. Den sista punkten såg vi även var viktig genom våra pilotstudier. Resultat för generella frågor om program och kod Här presenteras resultaten för de generella frågorna om vad program och kod är. Vi kan i figur 3 kan vi se att eleverna enligt pre&post-testen har fått ökad förståelse rörande alla tre frågor, fråga1-hur fungerar ett datorprogram?, fråga2-vad gör man när man programmerar?, och fråga3-vad är kod?. Ett paired-samples T-test användes för att jämföra elevernas prestation på dessa frågor före och efter vår intervention, resultatet redovisas i tabell 1. Störst förändring kan vi i fråga1 före interventionen (M =, 18, SD =, 32) och

99 KONSTPROGRAMMERING 17 efter interventionen (M =, 49, SD =, 45) med t(53) = 5, 16, p =, 000. Därefter kan vi se skillnaden i fråga2 före (M =, 42, SD =, 45) och efter interventionen (M =, 69, SD =, 42) med t(53) = 4, 32, p =, 000. Slutligen kan vi se skillnaden i fråga3 före interventionen (M =, 42, SD =, 45) och efter (M =, 61, SD =, 43) med t(53) = 3, 04, p =, 004. Detta visar tydligt att eleverna har presterat bättre på dessa frågor efter interventionen, vilket tyder på ett interventionen haft en positiv effekt på deras förståelse om hur kod, datorprogram och programmering hänger ihop. I tabell 2 kan vi se att både pre&post-generell kunskap är högre för elever med bättre attityd gentemot programmering. Figur 3. Generella frågor om kod pre/post-test Tabell 1 Paired-samples T-test generella frågor om programmering. Medelvärde Std-avvikelse Std-error-mean t df Sig.(2-tailed) Fråga1_Pre-Post -,31,45,06-5,16 53,000 Fråga2_Pre-Post -,28,47,06-4,32 53,000 Fråga3_Pre-Post -,19,47,06-3,04 53,004 Tabell 2 Deskriptiv statistik för generell kunskap grupperat efter låg-medel-hög attityd och kön. N Medelvärde Standardavvikelse Min Max Låg_attityd_pre_generell 19,32,48,00 1,50 Medel_attityd_pre_generell 16 1,16 1,12,00 3,00 Hög_attityd_pre_generell 19 1,58,90,00 3,00 Låg_attityd_post_generell 19 1,26,99,00 3,00 Medel_attityd_post_generell 16 1,66 1,15,00 3,00 Hög_attityd_post_generell 19 2,45,78,00 3,00 Pojkar_pre_generell 27 1,11 1,04,00 3,00 Pojkar_post_generell 27 1,80 1,09,00 3,00 Flickor_pre_generell 27,91,97,00 3,00 Flickor_post_generell 27 1,80 1,09,00 3,00

100 KONSTPROGRAMMERING 18 Resultat för Kunskapstest av programmeringsförmåga Som synes i tabell 3 har eleverna generellt sett inte uppnått någon hög poäng vid programmeringsfärdighetstestet. På alla frågor utom fråga 7 har majoriteten av eleverna 0 poäng (se figur 4). Vi kan också se att det finns någon eller några elever som kommit upp i maxpoäng på alla frågor utom fråga 6. Tabell 3 Deskriptiv statistik för programmeringsfärdighetstest. N Medelvärde Standardavvikelse Min Max Possible_Max Poäng_Fråga1 56 1,07 1,28,0 4,0 4,0 Poäng_Fråga2 56,19,43 -,5 2,0 2,0 Poäng_Fråga3 56,07,34,0 2,0 2,0 Poäng_Fråga4 56,13,33,0 1,5 1,5 Poäng_Fråga5 56,34,48,0 1,0 1,0 Poäng_Fråga6 56,11,41,0 2,0 3,0 Poäng_Fråga7 56,61,78 -,5 2,0 2,0 Poäng_Fråga8 56,48,50,0 1,0 1,0 Summa_Alla_Frågor 56 2,99 2,62 -,5 12,5 16,5 Tabell 4 Poängfrekvens kunskapsfrågor N(-,5) N(0) N(,5) N(1) N(1,5) N(2) N(3) N(4) Fråga Fråga Fråga Fråga Fråga Fråga Fråga Fråga Korrelationer mellan våra uppmätta värden kan vi se i tabell 5, pre-se korrelerar relativt starkt med pre-attityd r p =, 58p <, 001 och något svagare med pre&post-generell, r p =, 34p <, 05 repsektive r p =, 37p <, 01. Vi ser ingen stark eller signifikant korrelation mellan pre-se och prog-färdighet r p =, 28p >, 05. Pre-attityd korrelerar signifikant med prog-färdighet, r p =, 39p <, 01. Ytterligare korellerar pre-attityd även starkt med pre&postgenerell, starkare för pre r p =, 49p <, 001 än för post r p =, 41p <, 01. Tidigare programmeringserfarenhet korrelerar starkt med pre-attityd r p =, 47p <, 001, något svagare med r p, 39p <, 01 och ännu lite svagare med pre-se r p, 34p <, 05.

101 KONSTPROGRAMMERING 19 Tabell 5 Pearson-Korrelation mellan pre-test och programmeringsfärdighetstest. programmerat-förut pre-se pre-attityd Prog-färdighet pre-prog-generell post-prog-generell prog-förut 1,0,34*,47***,24,39**,24 pre-se 1,0,58***,28,34*,37** pre-attityd 1,0,39**,49***,41** post-prog-färdighet 1,0,49***,59*** pre-prog-generell 1,0,58*** post-prog-generell 1,0 Note.N=54,Sig.(2-tailed). p <,05. ** p <,01. *** p <,001. Tabell 6 Deskriptiv statistik för SE och Attityd. N Medelvärde Standardavvikelse Min Max Possible_Max pre-se 54 2,71,97 1,00 4,55 5 pre-attityd 54 3,39,83 1,75 4,75 5 post-se 54 2,58,94 1,00 5,00 5 post-attityd 54 2,69,91 1,00 4,75 5 Figur 4. Poängfrekvens kunskapsfrågor