Konstprogrammering med codeart.ida.liu.se

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
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
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
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
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
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
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
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 100 + 1 = 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
101 + 1 = 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
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
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
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
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
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
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
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
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å
https://www.khanacademy.org/computing/computer-programming/docs/pjs
16
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?
Observationsprotokoll, sal 303 och 305
Observatör
Datum och tid
Klass och antal elever
Antal labassar
Miljöbeskrivning/karta:
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.
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
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
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
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 6th 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
Innehållsförteckning
Förord ............................................................................................................................................... i
Sammanfattning ............................................................................................................................... ii
Abstract ............................................................................................................................................ ii
1. Inledning ...................................................................................................................................... 1
1.1 Motivering till studien ............................................................................................................ 1
1.2 Syfte och frågeställningar ....................................................................................................... 1
1.3 Avgränsningar ........................................................................................................................ 2
2. Teoretisk bakgrund ..................................................................................................................... 3
2.1 Egenförmåga .......................................................................................................................... 3
2.2 Attityd ..................................................................................................................................... 5
3. Metodik ........................................................................................................................................ 8
3.1 Interventionsmaterial ............................................................................................................. 8
3.2 Enkätundersökning ................................................................................................................ 9
3.3 Fokusgruppintervjuer........................................................................................................... 10
3.4 Pilottestning .......................................................................................................................... 10
3.5 Datainsamling ...................................................................................................................... 11
4. Analys ......................................................................................................................................... 13
4.1 Enkätanalys .......................................................................................................................... 13
4.2 Analys av fokusgrupper ....................................................................................................... 14
5. Resultat ....................................................................................................................................... 15
5.1 Bakgrundsinformation ......................................................................................................... 15
5.2 Attityd ................................................................................................................................... 15
5.3 Egenförmåga ........................................................................................................................ 19
5.4 Attityd och egenförmåga ...................................................................................................... 23
5.5 Teman från fokusgrupperna ............................................................................................... 25
5.6 Noteringar vid datainsamling ............................................................................................... 29
6. Diskussion .................................................................................................................................. 30
6.1 Resultatdiskussion ................................................................................................................ 30
6.2 Metodikdiskussion ............................................................................................................... 34
7. Slutsats ........................................................................................................................................ 37
8. Framtida forskning..................................................................................................................... 40
Referenser ...................................................................................................................................... 41
Bilagor ............................................................................................................................................ 44
iii
Bilaga 1: Pre-Enkäten ................................................................................................................ 44
Bilaga 2: Intervjuguide ............................................................................................................... 46
Bilaga 3: Teman från fokusgrupper .......................................................................................... 47
iv
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. 689-690).
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.
19-20). 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
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
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å 1970talet 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
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
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. 14-15).
5
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. 41-43):





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. 181-182).
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
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. 665-668) 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. 363-364) 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-aPhobic”) 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
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
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
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. 63-67). 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
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
Tabell 1. Sammanställning över datainsamlingen.
Tillfälle
Klass
Antal
elever
1
A
29
Antal
programmeringsassistenter
3
Innehåll
2
3
A
B
30
29
3
3
4
B
31
3
Presentation/introduktion
Pre-enkäter
Programmering
Programmering
Presentation/introduktion
Pre-enkäter
Programmering
Programmering
5
A
28
3
Programmering
6
7
B
A
32
27
3
3
8
B
31
2
9
A
2*5
-
Programmering
Testuppgift
Post-enkäter
Programmering
Testuppgift
Post-enkäter
Programmering
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
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 53.
13
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 2.0.6 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
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
2 st
Mycket negativ
11 st
13 st
Negativ
Neutral
Positiv
20 st
7 st
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
Attityd till att lära sig programmera efter
programmeringstillfällena
Mycket negativ
5 st
11 st
Negativ
10 st
Neutral
Positiv
6 st
Mycket positiv
21 st
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 6.
Attityd till att lära sig programmera före och
efter programmeringstillfällena
25
21
20
Antal elever
20
15
11
13
10
10
5
7
6
11
5
2
0
Mycket negativ
Negativ
Pre-Enkät
Neutral
Positiv
Mycket positiv
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
Medelvärde i Attityd till programmering 1-5
5
4,5
Medelvärde
4
3,5
3,39
3
2,68
2,5
2
1,5
1
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
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.
Medelvärde
Attityd per fråga före och efter programmeringstillfällena
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
Pre
Post
Tråkigt-Kul
3,87
2,79
Svårt-Lätt
2,58
1,92
Oviktigt-Viktigt
3,4
2,74
Töntigt-Coolt
3,72
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
1
2
3
4
FÖRE: Att lära sig programmera är…
Tråkigt-Kul
Töntigt-Coolt
Oviktigt-Viktigt
Svårt-Lätt
EFTER: Att lära sig programmera är…
Töntigt-Coolt
Tråkigt-Kul
Oviktigt-Viktigt
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
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
Svag
4 st
15 st
17 st
Ganska svag
Måttlig
Ganska stark
4 st
13 st
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 11.
19
Egenförmåga i att lära sig programmera efter
programmeringstillfällena
Svag
3 st
Ganska svag
18 st
16 st
Måttlig
Ganska stark
Stark
14 st
2 st
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.
Antal elever
Egenförmåga i att lära sig programmera före och efter
programmeringstillfällena
20
18
16
14
12
10
8
6
4
2
0
18
17
15
13
16
14
4
4
2
Svag
Ganska svag
Pre-Enkät
Måttlig
Ganska stark
3
Stark
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 13.
20
Egenförmåga i programmering 1-5
5
Medelvärde
4,5
4
3,5
3
2,71
2,68
Pre-Enkät
Post-Enkät
2,5
2
1,5
1
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
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.
Egenförmåga per fråga före och efter programmeringstillfällena
3,5
Medelvärde
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
Pre
Post
2,94
2,79
2,75
2,68
2,79
2,81
2,81
3,02
3,25
2,75
2,58
2,47
2,6
2,3
2,53
2,36
2,11
1,91
Fråga
Fråga 11
10
3
2,47
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
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
1
2
3
4
5
6
7
8
9
10
11
PRE: Jag kan lära mig…
… att göra enkla program (Fråga 5).
POST: Jag kan lära mig…
… att skriva kod som en dator kan läsa
och utföra (Fråga 4).
… att göra en enkel animering i CodeArt
… att göra en enkel animering i CodeArt
(Fråga 10).
(Fråga 10).
… de grundtankar som programmering
… att ändra och lägga till i kod som
bygger på (Fråga 1).
någon annan har skrivit (Fråga 3).
… att skriva kod som en dator kan läsa
… de grundtankar som programmering
och utföra (Fråga 4).
bygger på (Fråga 1)
… 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).
… att förstå vad kod som någon annan
… att förstå vad kod som någon annan
skrivit gör (Fråga 2).
skrivit gör (Fråga 2).
… att programmera så pass bra att om det … olika sorters programmeringsspråk
var ett ämne i skolan skulle jag få bra
(Fråga 6).
betyg i det (Fråga 7).
… olika sorters programmeringsspråk
… att göra ett konstverk i CodeArt (Fråga
(Fråga 6).
11).
… att skriva kod själv från början utan att … att skriva kod själv från början utan att
det finns kod att bygga vidare på (Fråga
det finns kod att bygga vidare på (Fråga
8).
8).
… att göra ett konstverk i CodeArt (Fråga … att programmera så pass bra att om
11).
det var ett ämne i skolan skulle jag få bra
betyg i det (Fråga 7).
… 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
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 16—18.
Egenförmåga hos respondenter med Positiv Mycket positiv attityd till att lära sig
programmera, efter programmeringstillfällena
20 %
Svag
20 %
Ganska svag
6,67 %
0%
Måttlig
Ganska stark
53,33 %
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
0%0%
Svag
Ganska svag
50 %
50 %
Måttlig
Ganska stark
Stark
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).
24
Egenförmåga hos respondenter med Negativ mycket negativ attityd till att lära sig
programmera, efter programmeringstillfällena
0%
Svag
15,6 %
Ganska svag
6,25 %
46,9 %
31,25 %
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
Positiv – Mycket positiv
Neutral
Negativ – Mycket negativ
Egenförmåga
Svag
Ganska svag Måttlig Ganska stark Stark Summa
20 %
6,67 %
0%
53,33 % 20 % 100 %
0%
50 %
0%
50 %
0 % 100 %
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,01.
5.5 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
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
Förväntningar på
programmeringstillfällena
Negativa till att lära sig
programmering
Lite eller ingen erfarenhet.
Positiva till att lära sig
programmering
Måttlig eller mycket
erfarenhet.
Likheter
Hade antingen inga
förväntningar eller trodde
att det skulle vara fartfyllt
och inte så mycket siffror.
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.
Tyckte att det
skulle bli kul.
Negativt ändrad syn på
Förändring i syn på programmering.
programmering
Upplägget på
programmeringstillfällena, negativt
Upplägget på
programmeringstillfällena, positivt
Uppgiftshäftet
Programmeringsassistenter
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.
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.
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.
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.
26
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
Programmering,
negativt
Programmering,
positivt
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.
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.
Förstod inte särskilt mycket Svårt att förstå hur man
och behövde fråga om hjälp får saker att flytta på sig.
ofta.
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.
Vill ha mer lektionsliknande Mer förklaring till vad
undervisningstillfällen där
koderna betyder och fler
en lärare går igenom
avancerade uppgifter.
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.
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.
Likheter
Svår uppgift.
Fler lektioner med
mindre mellanrum.
Ha ett projekt som
man jobbar med
över flera lektioner.
Kul när det går bra.
27
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.
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.
Likheter
Skulle vara kul att ha som
skolämne, få hjälp av
lärare och slippa lära sig
själv.
Bör vara valfritt,
exempelvis elevens
val. Bra om man lär
sig i ung ålder för
då blir det lättare
sen.
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.
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.
Skulle lära sig mer
om man fick mer
utbildning i det.
Viktigt för
framtiden.
28
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
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
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
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
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
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
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
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
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
Ä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
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
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
Referenser
Armoni, M. (2011, December). The nature of CS in K-12 curricula: the roots of confusion. ACM
Inroads, Vol 4, No. 4, pp. 19-20.
Bandura, A. (1978). Towards a unifying theory of behavioral change. Advances in Behaviour
Research and Therapy, Vol 1, 139-161.
Bandura, A. (1996). Multifaceted Impact on Self-Efficacy Beliefs on Academic Functioning.
Child Development, 67, 1206-1222.
Bandura, A. (2006). Guide for constructing self-efficacy scales. In F. Pajares, & T. Urdan, SelfEfficacy Beliefs of Adolescents (pp. 307-337). 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,
231-240.
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,
60-75.
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. 689709). 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. 94-172). 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. 247-282). 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. 171-200). Great Britain: John Wiley &
Sons.
Katz, D. (1960). The functional approach to the study of attitudes. Public opinion quarterly, Vol.
24, No. 2, 163-204.
Komarraju, M., & Nadler, D. (2013). Self-efficacy and academic achievement: Why do implicit
beliefs, goals, and effort regulation matter? Learning and Individual Differences, 25, 6772.
41
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, 30-43.
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 SelfEfficacy with Antecedents from the Social Cognitive Theory. Journal of Next Generation
Information Technology (JNIT), Vol 4, 423-432.
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, 33-40.
Rausch, M. J. (1998). Analyzing and Reporting Focus Group Results. In R. A. Kreuger, Analyzing
& Reporting Focus Group Results (pp. 94-95). 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, 661-689.
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), 37-40.
The CoderDojo Foundation. (2015, Mars 23). CoderDojo. Retrieved from Find your Dojo:
https://zen.coderdojo.com/
The CoderDojo Foundation. (2015, Mars 23). CoderDojo. Retrieved from About:
https://coderdojo.com/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, 363-367.
Torkzadeh, R., Pflughoeft, K., & Hall, L. (1999). Computer self-efficacy, training effectiveness
and user attitudes: An empirical study. Behaviour & Information Technology, 18, 299309.
Usher, E. L., & Pajares, F. (2008). Self-Efficacy for Self-Reulated Learning A Validation Study.
Educational and Psychological Measurement, Vol 68, 443-463.
42
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, 0-86.
Zajonc, R. B. (1968). Attitudinal effects of mere exposure. Journal of personality and social
psychology, Vol. 9, No. 2, 1-27.
Zimmerman, B. J. (2000). Self-Efficacy: An Essential Motive to Learn. Contemporary
Educational Psychology 25, 82-91.
43
Bilagor
Bilaga 1: Pre-Enkäten
44
45
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
Bilaga 3: Teman från fokusgrupper
Teman
Negativa till att lära sig programmera
Positiva till att lära sig programmera
Erfarenhet av
programmering
- Hade hört talas om programmering
men visste ej vad det innebär.
- Hade inte hört talas om
programmering.
- 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.
- 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.
- 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.
Förväntningar på
programmeringstillfällena
Förändring i syn
på
programmering
- 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
Upplägget på
svårare.
programmerings- - Tråkigt att skriva samma sak hela
tillfällena, negativt 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
- 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.
- 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
Upplägget på
programmeringstillfällena, positivt
Uppgiftshäftet
Programmeringsassistenter
CodeArt
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.
Testuppgiften
Förståelse för
programmering
Förbättringsförslag
- 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
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
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.
- 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.
- 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.
- 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.
- Skulle vara kul att göra spel.
- Vill programmera mer.
50
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.
KONSTPROGRAMMERING
2
Innehåll
Introduktion
Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
Litteraturstudie
Hur lär man sig programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utmaningar och stöd för lärande av programmering . . . . . . . . . . . . . . . .
5
6
7
Metod
Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Datainsamling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
11
12
Resultat
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
.
.
.
.
15
16
16
16
18
Diskussion
Metoddiskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultatdiskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
20
Slutsats
Framtida forskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
KONSTPROGRAMMERING
3
Figurer
1
2
3
4
Jeliot: visualisering av Javakod . . . .
Programmeringsvyn i CodeArt . . . .
Generella frågor om kod pre/post-test
Poängfrekvens kunskapsfrågor . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
11
17
19
KONSTPROGRAMMERING
4
Tabeller
1
2
3
4
5
6
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. . . . . . . . . . . . . . . . . . . . . . .
17
17
18
18
19
19
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.
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
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
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).
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.
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
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.
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
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 ( true ){
e l l i p s e (x , y ,10 ,10);
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 ( true ){
e l l i p s e (x , y ,10 ,10);
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 ( true ){
e l l i p s e (x , y ,10 ,10);
i f (y>60+5){
y=y −1;
}
}
Rader som ändrats av eleven markeras med fetstil.
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 (255 ,0 ,0);
}
else{
f i l l (0 ,0 ,255);
}
e l l i p s e (30 ,170 ,10 ,10);
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 (255 ,0 ,0);
}
else{
f i l l (0 ,0 ,255);
}
e l l i p s e (30 ,170 ,10 ,10);
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 ;
w h i l e ( 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.
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.
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
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
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
Poäng_Fråga1
56
1,07
1,28
Poäng_Fråga2
56
,19
,43
Poäng_Fråga3
56
,07
,34
Poäng_Fråga4
56
,13
,33
Poäng_Fråga5
56
,34
,48
Poäng_Fråga6
56
,11
,41
Poäng_Fråga7
56
,61
,78
Poäng_Fråga8
56
,48
,50
Summa_Alla_Frågor 56
2,99
2,62
Min
,0
-,5
,0
,0
,0
,0
-,5
,0
-,5
Max Possible_Max
4,0
4,0
2,0
2,0
2,0
2,0
1,5
1,5
1,0
1,0
2,0
3,0
2,0
2,0
1,0
1,0
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åga1
27
0
7
0
8
11
1
Fråga2
1
41
4
7
0
1
Fråga3
51
1
0
1
1
Fråga4
45
6
1
2
Fråga5
35
0
19
Fråga6
50
0
2
2
0
0
Fråga7 16
0
2
30
3
3
Fråga8
28
0
26
-
Korrelationer mellan våra uppmätta värden kan vi se i tabell 5, pre-SE korrelerar
relativt starkt med pre-Attityd rp =, 58p <, 001 och något svagare med pre&post-generell,
rp =, 34p <, 05 repsektive rp =, 37p <, 01. Vi ser ingen stark eller signifikant korrelation
mellan pre-SE och prog-färdighet rp =, 28p >, 05. Pre-attityd korrelerar signifikant med
prog-färdighet, rp =, 39p <, 01. Ytterligare korellerar pre-Attityd även starkt med pre&postgenerell, starkare för pre rp =, 49p <, 001 än för post rp =, 41p <, 01. Tidigare programmeringserfarenhet korrelerar starkt med pre-attityd rp =, 47p <, 001, något svagare med
rp , 39p <, 01 och ännu lite svagare med pre-SE rp , 34p <, 05.
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**
1,0
,39**
,49***
,41**
pre-Attityd
post-Prog-färdighet
1,0
,49***
,59***
1,0
,58***
pre-Prog-generell
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
KONSTPROGRAMMERING
20
Diskussion
Här diskuteras metod och resultat.
Metoddiskussion
Vi valde att inte ha ett programmeringsfärdighetstest som en del av pre-testet, detta
då vi antog att de flesta inte skulle klara av ett sådant test. Vi kan anta att interventionen
förbättrat elevernas programmeringsförmåga men vi kan inte utom tvivel säkerställa att de
inte kunde prestera så bra som de gjorde innan interventionen.
Pilottesterna var för korta, deltagarna hann inte göra alla uppgifter och därför blev
det svårt att se brister i upplägget som helhet. Det blev också svårt att testa kunskapstestet
då det förutsatte att eleverna genomgått interventionen och tillgodogjort sig viss kunskap
som inte kunde reproduceras vid ett kort pilottest. Den golveffekt vi ser i kunskapstestet
beror till stor del på bristerna i pilottesterna vilket gjorde att vi inte kunde nivå-anpassa
uppgifterna på ett adekvat sätt. Golveffekten kan också bero på interventionens uformning
och främst dess korthet i förhållande till vad vi försökte lära eleverna.
Testuppgiften pilottestades inte alls, och den visade sig vara alldeles för svår för
eleverna överlag, endast några få elever klarade av att ta sig förbi det första momentet,
därför har resultatet från denna uppgift inte analyserats.
Resultatdiskussion
Vi ser en ökad generell förståelse bland eleverna för hur datorprogram fungerar, vad
kod är, samt vad man gör när man programmerar. Det är positivt att vi med en relativt
liten intervention har kunnat öka kunskapen om programmering som process och belysa
något hur datorprogram fungerar. Det låga resultatet i programmeringsfärdighetstestet visar tydligt att eleverna inte var redo för den typ av utmaning som testet utsatte dem för.
Utifrån litteraturen kan detta på att de inte kommit tillräckligt långt i sin förståelse och
erfarenhet av programmering, alla testuppgifter utom den sista (om semikolon), krävde antingen semantisk eller syntaktisk förståelse av språket, och några uppgifter krävde förståelse
av programmeringskoncept. Merparten av eleverna lyckades dock, med det stöd de fick från
handledarna, ta sig igenom många av de övningsuppgifter som huvudsaken av interventionen bestod av. Av de olika frågorna så ser kunskapsfråga 3 ut att ha varit svårast, detta
kan sannolikt bero på att den byggde vidare på kunskapsfråga 2 och därför valde sannolikt
många elever att inte svara på den då de inte kände att de kunde svara på kunskapsfråga
2 och därmed även gav upp på kunskapsfråga 3.
Vad gäller korrelationen mellan å ena sidan SE & attityd, och å andra sidan kunskapsresultat efter interventionen ser vi ingen signifikant korrelation mellan SE och kunskap,
däremot en signifikant korrelation mellan attityd och kunskap. Tidigare programmeringserfarenhet verkar inte påverka kunskapsresultatet eller post-generell kunskap, däremot verkar
det påverka attityden samt pre-generell kunskap med signifikans. Pre-Attityd korrelerar
också med pre-generell-kunskap, de med god poäng har i större mån fått hög poäng på pretestet. Att tidigare programmeringserfarenhet inte påverkar kunskapstestresultatet skulle
kunna bero på att de tidigare erfarenheter de har inte överensstämmer med den programmering, och det språk som vi introducerar. Det är som sagt språkspecifika kunskaper som
KONSTPROGRAMMERING
21
är det första steget i programmeringsinlärning, och de flesta som hade provat på programmering innan hade endast gjort det ”några gånger”. De som har programmeringserfarenhet
har oftast också mer positiv attityd till programmering som helhet, detta kan tyda på att
de fått denna attityd från sin interaktion med programmering, detta är dock inte en effekt
som vi sett i vår intervention.
I programmeringsfärdighetstestet ser vi en kraftig sk. golv-effekt där majoriteten av
eleverna fick mycket låg poäng på nästan varje uppgift. Utifrån detta kan vi se att interventionen inte lyckats lära ut programmeringsfärdigheter till eleverna som grupp, kanske
på grund av för lite tid, eller en utformning som inte gynnade den typen av lärande. Golveffekten kan också bero på för svårt utformade testuppgifter, men flera av dem liknade de
uppgifter de arbetat med under lärotillfällena, med den stora skillnaden att de där kunde
be handledare om hjälp samt experimentera i programmeringsmiljön.
Varför elever gav upp är svårt att svara på, det skulle t.ex. kunna bero på att uppgifterna helt enkelt kändes för svåra, kognitiv överbelastning eller bristande intresse. Utifrån
fokusgruppsintervjun kan vi också lägga till möjligheten att elever upplevde att det var
jobbigt att fråga då man lätt känner sig dum när man inte klarar en uppgift själv.
Vi kan se en minskning överlag i såväl attityd som SE, det kan till viss del förklaras
med att uppgifterna överlag var svåra och systemet inte tillräckligt bra på att stödja eleverna. Det kan kanske också förklaras till viss del av att eleverna hade en felaktig bild om
vad programmering innebär, eller att våra uppgifter inte var tillräckligt intressanta. I fokusgrupperna efter interventionen kan vi se en överlag positiv attityd till programmeringen
som helhet, men många sade samtidigt att de hade trott att det skulle vara mer ”action” i
programmering. Med tanke på hur attityd till programmering verkar ha varit viktig för våra elevers resultat, kanske domänen, eller den domän man förknippar programmering med,
kan påverka elevernas attityd?
Det finns tydliga skillnader i miljön och deltagarna mellan Coder Dojos och skolklasser. Dels så är Coder Dojos frivilliga, vi kan därmed anta att deltagarna där överlag har ett
större intresse för och bättre attityd till programmering än elever i en skolklass, där hela
spektrat antagligen finns med. Ofta har deltagarna vid Coder Dojos även en förälder med
sig som kan hjälpa dem att göra rätt när det blir för krångligt, det gör att de problem som
uppstår i en skolklass inte blir lika tydliga i Coder Dojo-miljön.
Slutsats
I slutsatsen sammanfattas och kopplas resultatet till frågeställningarna. Även några
förslag på förbättring av CodeArt som läromiljö ges.
Vad kan elever lära sig om programmering under en kort intervention i
skolan?. Vi har visat att en kortare intervention kan öka elevers generella kunskap om
hur datorprogram fungerar och vad programmering innebär. Vi kan också se en viss programmeringsförmåga efter interventionen, men överlag var denna låg. Detta kan bero på
att vår intervention var för kort för att eleverna skulle hinna lära sig tillräckligt mycket
för att kunna lösa våra testproblem på ett bra sätt. Våra testproblem krävde minst en
språkspecifik förståelse (första steget), och sannolikt även en viss grad av konceptuell förståelse (andra steget), inte minst i testuppgiften. Detta stämmer överens med resultatet
från den studie som Linn och Dalbey (1985) genomfört, där elever överlag inte tog sig långt
på programmeringsstegen.
KONSTPROGRAMMERING
22
Hur kan man lära ut programmering i skolklasser?. För att lära ut programmering i skolklasser måste man hantera elever med stor variation av motivation, attityd,
förkunskaper med mera. Det är därför extra viktigt att man har ett bra kursmaterial då ett
sådant underlättar för svagare och lågt motiverade elever att ta till sig ny information. Det
blir också extra viktigt att ha ett engagerande material som kan intressera elever överlag.
Inom litteraturen finns de som förespråkar att man fokuserar mer på programmeringskoncept, vilket skulle leda till att man hoppar direkt till steg två i programmeringsstegen. Det
fanns också elever som i fokusgruppsintervjuerna påtalade att det hade känts positivt för
dem om de fått mer övergripande information om programmering i form av föreläsningar.
Sannolikt kan en blandning av explicita tutorialsliknande programmeringsövningar och föreläsningar om programmeringskoncept vara ett vinnande koncept. Andra viktiga faktorer
att ha i åtanke är tillgången till datorer i skolan och tillgången till erfarna och kunniga
lärare.
Vad är de tydligaste utmaningarna och hur kan de hanteras?. Elever kan
ha svårt att förstå programmeringskoncept då de inte haft någon kontakt med liknande saker
förut, därför är det viktigt att hjälpa eleven att första programmeringskoncept genom att
introducera dessa på ett bra sätt och inte låta eleven skapa sina egna modeller. Ett effektivt
sätt att introducera programmeringskoncept är att använda sig av konkreta modeller som
metaforiskt kopplar programmeringskoncept till för eleven redan kända koncept. Detta gör
det lättare för eleven att minnas de nya koncepten och använda dessa koncept när de möter
nya problem.
Det största hindret vi upplevde under interventionen, som även styrks av litteraturen,
var syntax. Elever hade svårt att få rätt tecken på rätt plats, och även svårt att veta var
de skulle placera kodstycken trots att det var explicit förklarat i instruktionerna, därför är
det viktigt att man underlättar syntax, antingen genom språkförenklingar eller anpassade
språk, eller genom en anpassad utvecklingsmiljö som stödjer elevens hantering av syntax.
På så sätt minskar man risken för kogntiv överbelastning hos eleven. Det är också viktigt
att eleverna känner att de klarar av att göra något själva, och inte alltid behöver fråga om
hjälp för att lösa uppgifter eller när problem uppkommer.
Vår ansats att låta elever programmera direkt utan att mer ingående förklara olika
programmeringskoncept och hjälpa dem förstå saker innan de ställs inför att programmera
själva har även ifrågasatts i litteraturen, det leder lätt till kognitiv överbelastning (cognitive
overload) där eleven får svårt att lära sig och fokusera på vad som är viktigt. I motsats finns
också en oro för att programmering i förenklade språk kan ha negativ effekt på när man
går över till ”riktiga programmeringsspråk”, det finns dock mig veterligen ingen forskning
som tittat på detta.
Hur kan CodeArt förbättras som läromiljö?. För att göra CodeArt bättre som
verktyg för att lära ut programmering och computational thinking skulle jag se till de krav
Ioannidou m. fl. (2011) ställer. CodeArt i sin nuvarande form uppfyller definitivt punkt 2,4
och 5; högt tak, möjlighet att överföra förmågor till ”riktig programmering”, samt kunna
tilltala alla oavsett vem man är. Då vi använde oss av ett ”riktigt programmeringsspråk”
finns det knappt något tak att tala om, och överföringen till riktig programmering blir
rätt uppenbar. Vad gäller jämlikhet tänkte vi oss att konstdomänen kanske skulle tilltala
tjejer mer, vilket är positivt då pojkar anses vara överrepresenterade inom datavetenskap,
vad vi kunde se verkade programmeringen tilltala båda grupperna. Punkt 1, lågt golv, kan
KONSTPROGRAMMERING
23
diskuteras, de flesta elever klarade av att göra de simpla uppgifterna, men många tyckte
också att de var lite tråkiga, och det blir uppenbarligen svårare att skriva kodrader med
riktig syntax jämfört med att använda ett grafiskt programmeringsspråk. Vad gäller punkt
3, scaffolding flow, skulle man kunna lägga till stöd för kodbitar i utvecklingsmiljön, säg
att en elev har lärt sig skriva en loop eller en if-sats. Då skulle man kunna låta eleven
dra och klistra in denna kodsnutt där de tycker passar, och därefter ändra det som behövs
för att lösa det specifika problemet. Detta liknar vad jag förstår till viss del scratch där
man drar visuella kodbitar likt ett pussel, men också hur professionella utvecklingsmiljöer
fungerar där man kan klistra in fördefinierade kod-element med hjälp av kortkommandon.
Den svåraste punkten med CodeArt är sannolikt nummer 6, att göra det lättillgängligt
för lärare, vi hade hela tiden tre stycken programmeringskunniga handledare på plats som
kunde hjälpa eleverna med de problem de stötte på. Det är inte rimligt att det ska se ut så
om man ska programmera i skolan fullskaligt, ett alternativ vore att ha en lärare som är
programmeringskunnig, eller att man helt enkelt bygger vidare på någon form av stöd eller
guide även för läraren.
Framtida forskning
Det vore intressant att jämföra hur en intervention i något av de populära introduktionsspråken (scratch, kojo, etc.) står sig i jämförelse till en intervention i ett ”riktigt”
programmeringsspråk (javascript,python, etc.). Finns det någon skillnad i vad elever lär sig
och hur de upplever en sådan intervention? Det kan också vara intressant att titta närmare
på hur attityd påverkar lärandet av programmering. En annan intressant sak kan vara att
vidareutveckla CodeArt i lärosyfte med t.ex. kod-templates och syntax-hjälp och vidare
undersöka vilken åldersgrupp som verktyget och domänen med konstprogrammering bäst
lämpar sig för.
Referenser
Barr, V. & Stephenson, C. (2011). Bringing computational thinking to k-12: what is involved
and what is the role of the computer science education community?. ACM Inroads,
2 (1), 48–54.
Bayman, P. & Mayer, R. E. (1988). Using conceptual models to teach basic computer
programming. Journal of Educational Psychology, 80 (3), 291–298.
Bers, M. U., Flannery, L., Kazakoff, E. R. & Sullivan, A. (2014). Computational thinking
and tinkering: exploration of an early childhood robotics curriculum. Computers &
Education, 72, 145–157.
Clark, R. C., Nguyen, F. & Sweller, J. (2006). Efficiency in learning. [electronic resource]
: evidence-based guidelines to manage cognitive load. Pfeiffer essential resources for
training and HR professionals. San Francisco, Calif. : Pfeiffer, c2006.
Dyck, J. L. & Mayer, R. E. (1989). Teaching for transfer of computer program comprehension skill. Journal of Educational Psychology, 81 (1), 16–24.
Esteves, M., Fonseca, B., Morgado, L. & Martins, P. (2011). Improving teaching and learning
of computer programming through the use of the second life virtual world. British
Journal of Educational Technology, 42 (4), 624–637.
KONSTPROGRAMMERING
24
Graczynska, E. (2010). Alice as a tool for programming at schools. Natural Science, 2 (2),
124–129.
Griffin, P. E., McGaw, B. & Care, E. (2012). Assessment and teaching of 21st century skills.
[elektronisk resurs]. Dordrecht ; New York : Springer, c2012.
Grover, S. & Pea, R. (2013). Computational thinking in k-12: a review of the state of the
field. Educational Researcher, 42 (1), 38–43.
Guzdial, M., Johnson, R., Wampler, K., Kussmaul, C., Swanson, J., Humenn, P. & Lewchuk,
M. (2015). What’s the best way to teach computer science to beginners?. Communications of the ACM, 58 (2), 12–13.
Al-Imamy, S., Alizadeh, J. & Nour, M. A. (2006). On the development of a programming
teaching tool: the effect of teaching by templates on the learning process. Journal of
Information Technology Education, 5, 271–283.
Ioannidou, A., Bennett, V., Repenning, A., Koh, K. H. & Basawapatna, A. (2011). Computational thinking patterns. Online Submission.
Kelleher, C. & Pausch, R. (2005). Lowering the barriers to programming: a taxonomy of
programming environments and languages for novice programmers. ACM Computing
Surveys, 37 (2), 83–137.
Kordaki, M. (2010). A drawing and multi-representational computer environment for beginners’ learning of programming using c: design and pilot formative evaluation. Computers & Education, 54, 69–87.
Lehrer, R., Lee, M. & Jeong, A. (1999). Reflective teaching of logo. The Journal of the
Learning Sciences, (2), 245.
Linn, M. C. & Dalbey, J. (1985). Cognitive consequences of programming instruction: instruction, access, and ability. Educational Psychologist, 20 (4), 191.
Mayer, R. E. (1981). The psychology of how novices learn computer programming. ACM
Computing Surveys, 13 (1), 121–141.
McGill, T. J. & Volet, S. E. (1997). A conceptual framework for analyzing students’ knowledge.. Journal of Research on Computing in Education, 29 (3), 276.
Mohebbi, A., Asefi, F. & Tee, E. (2012). Common traits of graphical programming tools for
children. UCSI University, School of Information Technology, Kuala Lumpur, Malaysia, 125743.
Resnick, M., Ohshima, Y., Flanagan, M., Perlin, K., Kelleher, C., Torres, R. & MacLaurin, M. (2009). Growing up programming: democratizing the creation of dynamic,
interactive media. I Conference on human factors in computing systems - proceedings
(Proceedings of the 27th International Conference Extended Abstracts on Human
Factors in Computing Systems, CHI 2009, s. 3293–3296). (1)MIT Media Lab.
Skolverket. (2011). Läroplan för grundskolan, förskoleklassen och fritidshemmet 2011.
Hämtad 11 maj 2015, från http://www.skolverket.se/laroplaner-amnen-och-kurser/
grundskoleutbildning/grundskola/laroplan/curriculum.htm
Stachel, J., Marghitu, D., Brahim, T. B., Sims, R., Reynolds, L. & Czelusniak, V. (2013).
Managing cognitive load in introductory programming courses: a cognitive aware
scaffolding tool. Journal of Integrated Design & Process Science, 17 (1), 37–54.
Sweller, J. (1988). Cognitive load during problem solving: effects on learning. Cognitive
Science, 12 (2), 257–285.
KONSTPROGRAMMERING
25
Utting, I., Kölling, M., Cooper, S., Maloney, J. & Resnick, M. (2010). Alice, greenfoot, and
scratch - a discussion. ACM Transactions on Computing Education, 10 (4).
Yousoof, M. & Sapiyan, M. (2014). Cognitive load measurement in learning programming
using nasa tlx rating scale (non physiological measures). (s. 235–245). Applied computer and applied computational science.
Yousoof, M., Sapiyan, M. & Ramasamy, K. (2008). Performance evaluation of the software
visualization tools and a new framework to manage cognitive load in computer program learning. WSEAS Transactions on Information Science and Applications, 5 (5),
655–663.
KONSTPROGRAMMERING
Konstprogrammering i skolor
26
Bilaga A https://docs.google.com/forms/d/1nK5dkQDO07...
Appendix pre-test
Konstprogrammering i skolor
Detta är en enkät för att undersöka ungas attityder och uppfattningar kring att lära sig
programmera. Ditt svar kommer att behandlas helt anonymt. Läs igenom frågorna noga
innan du svarar. Tack för ditt medverkande!
*Required
1. Kön *
Mark only one oval.
Tjej
Kille
2. Ålder *
Mark only one oval.
10
11
12
13
3. Har du programmerat förut? *
Mark only one oval.
Nej
Några gånger
Många gånger
1 of 6
2015-04-24 15:27
KONSTPROGRAMMERING
Konstprogrammering i skolor
27
https://docs.google.com/forms/d/1nK5dkQDO07...
4. Elev ID *
Mark only one oval.
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
2 of 6
2015-04-24 15:27
KONSTPROGRAMMERING
28
Konstprogrammering i skolor
https://docs.google.com/forms/d/1nK5dkQDO07...
För varje rad, kryssa i det som bäst stämmer in på vad du tycker om ATT LÄRA DIG att
programmera.
5. Att LÄRA SIG programmera är... *
Mark only one oval per row.
Tråkigt
Ganska tråkigt
Varken eller
Ganska kul
Kul
1
6. Att LÄRA SIG programmera är... *
Mark only one oval per row.
Svårt
Ganska svårt
Varken eller
Ganska lätt
Lätt
2
7. Att LÄRA SIG programmera är... *
Mark only one oval per row.
Oviktigt
Ganska oviktigt
Varken eller
Ganska viktigt
Viktigt
3
8. Att LÄRA SIG programmera är... *
Mark only one oval per row.
Töntigt
Ganska töntigt
Varken eller
Ganska coolt
Coolt
4
Skip to question 9.
Kryssa i hur säker du är på att KUNNA LÄRA DIG dessa
saker:
(Du behöver alltså inte kunna dem nu)
3 of 6
2015-04-24 15:27
KONSTPROGRAMMERING
29
Konstprogrammering i skolor
https://docs.google.com/forms/d/1nK5dkQDO07...
9. Jag KAN LÄRA mig... *
Mark only one oval per row.
Jätteosäker
Ganska
osäker
Kanske
Ganska
säker
Jättesäker
… de grundtankar som
programmering bygger
på
... att förstå vad kod
som någon annan har
skrivit gör
... att kunna ändra och
lägga till i kod som
någon annan har skrivit
... att skriva kod som en
dator kan läsa och
utföra
4 of 6
2015-04-24 15:27
KONSTPROGRAMMERING
30
Konstprogrammering i skolor
https://docs.google.com/forms/d/1nK5dkQDO07...
Jätteosäker
Ganska
osäker
Kanske
Ganska
säker
Jättesäker
... att göra enkla
program
... olika sorters
programmeringsspråk
... att programmera så
pass bra att om det var
ett ämne i skolan skulle
jag få bra betyg i det
... att skriva kod själv
från början utan att det
finns kod att bygga
vidare på
... att göra avancerade
program
... att göra en enkel
animering i CodeArt
... att göra ett konstverk
i CodeArt
Frågor om programmering
10. Hur fungerar ett datorprogram? *
11. Vad gör man när man programmerar? *
12. Vad är kod? *
5 of 6
2015-04-24 15:27
KONSTPROGRAMMERING
Konstprogrammering i skolor
31
Bilaga B https://docs.google.com/forms/d/1vMbHLg3Yt2Z...
Appendix post-test del-2 Kunskapstest
Vad har du lärt dig om konstprogrammering?
10. Hur många uppgifter har du gjort?
Fråga 1
11. 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).
Figur1
Fråga 2 och 3
var x =30;
var y =170;
while(true){
ellipse(x,y,10,10);
x=x+0;
y=y+0;
}
6 of 9
2015-04-24 15:29
KONSTPROGRAMMERING
Konstprogrammering i skolor
32
https://docs.google.com/forms/d/1vMbHLg3Yt2Z...
12. Titta på figur1 och koden ovan. Hur kan koden ovan förändras så att cirkeln
skulle röra sig nerifrån och upp? *
Försök skriva koden som löser problemet.
13. Kan du ändra koden från uppgift 2 så att cirkeln stannar när den når den svarta
rektangeln? *
Försök skriva koden som löser problemet.
Fråga 4
color=3;
if(color<4){
fill(255,0,0);
}
else{
fill(0,0,255);
}
ellipse(30,170,10,10);
14. Koden ovan ritar ut en röd cirkel.
Förändra if-satsens villkor så att cirkeln
blir blå istället. *
Fråga 5
var x = 10;
while(x<15){
x=x+3;
if(x==14){
x=22;
}
}
7 of 9
2015-04-24 15:29
KONSTPROGRAMMERING
Konstprogrammering i skolor
33
https://docs.google.com/forms/d/1vMbHLg3Yt2Z...
15. Läs igenom koden ovan, vad blir värdet på x när koden körts färdigt? *
Mark only one oval.
16
22
10
Fråga 6
void setup(){
}
var x = 10;
var y = 10;
var height = 10;
var width = 10;
void draw3circles(){
ellipse(x, y, width, height);
ellipse(x+20, y+20, width+20, height+20);
ellipse(x+40,y+40,width+40,height+40);
}
16. 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. *
Fråga 7 och 8
17. Varför kan det vara bra att använda funktioner när man programmerar? *
Fyll i alla alternativ som du tror är rätt.
Tick all that apply.
Koden blir lättare att läsa.
Kod kan återanvändas flera gånger.
Det går inte att programmera utan funktioner.
8 of 9
2015-04-24 15:29
KONSTPROGRAMMERING
Konstprogrammering i skolor
34
https://docs.google.com/forms/d/1vMbHLg3Yt2Z...
18. Varför är det viktigt att skriva ett semikolon i slutet av en rad? *
Powered by
9 of 9
2015-04-24 15:29
KONSTPROGRAMMERING
35
Bilaga C
Uppgiftshäfte
NAMN:________________________________________________
ID:________
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 ES6B och lösenord engelska
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
KONSTPROGRAMMERING
36
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
2
KONSTPROGRAMMERING
37
mellan { och }.
Försök skapa ett mönster du gillar.
När du är klar trycker du på knappen Spara.
Titel: Ex1
Namn: Ditt ID (se framsidan)
3
KONSTPROGRAMMERING
38
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å.
När du är klar trycker du på knappen Spara. Titel: Ex2 Namn: Ditt
ID
4
KONSTPROGRAMMERING
39
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.
När du är klar trycker du på knappen Spara. Titel: Ex3 Namn: Ditt
ID
5
KONSTPROGRAMMERING
40
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).
När du är klar trycker du på knappen Spara. Titel: Ex4 Namn: Ditt
ID
6
KONSTPROGRAMMERING
41
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.
7
KONSTPROGRAMMERING
42
Testa att köra programmet genom att trycka på Uppdatera några
gånger.
När du är klar trycker du på knappen Spara. Titel: Ex5 Namn: Ditt
ID
8
KONSTPROGRAMMERING
43
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.
När du är klar trycker du på knappen Spara. Titel: Ex6A Namn:
Ditt ID
FRIVILLIG UPPGIFT
Nu vill vi välta snögubben.
9
KONSTPROGRAMMERING
44
Ä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.
När du är klar trycker du på knappen Spara. Titel: Ex6B Namn:
Ditt ID
10
KONSTPROGRAMMERING
45
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 100 + 1 = 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 101 + 1 = 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?
När du är klar trycker du på knappen Spara. Titel: Ex7 Namn: Ditt
ID
11
KONSTPROGRAMMERING
46
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.
När du är klar trycker du på knappen Spara. Titel: Ex8 Namn: Ditt
ID
12
KONSTPROGRAMMERING
47
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 whileloopen 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);
13
KONSTPROGRAMMERING
48
När du är klar trycker du på knappen Spara. Titel: Ex9A Namn:
Ditt ID
14
KONSTPROGRAMMERING
49
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.
När du är klar trycker du på knappen Spara. Titel: Ex9B Namn:
Ditt ID
15
KONSTPROGRAMMERING
50
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.
När du är klar trycker du på knappen Spara. Titel: Ex10A Namn:
Ditt ID
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.
När du är klar trycker du på knappen Spara. Titel: Ex10B Namn:
Ditt ID
16
KONSTPROGRAMMERING
51
17
KONSTPROGRAMMERING
52
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.
18
KONSTPROGRAMMERING
53
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.
19
KONSTPROGRAMMERING
54
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.
När du är klar trycker du på knappen Spara. Titel: Ex11A Namn:
Ditt ID
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.
När du är klar trycker du på knappen Spara. Titel: Ex11B Namn:
Ditt ID
20
KONSTPROGRAMMERING
55
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
21
KONSTPROGRAMMERING
56
for (var i = 0; i <8; i ++) { kod } - Upprepa koden ett fast antal gånger (t ex 8
ggr)
22
KONSTPROGRAMMERING
57
Utmaningar
Utmaning 1 – Vad är det till middag?
Klicka på den röda knappen Exempel. Välj Utmaning 1.
Utmaning 2 - Såpbubblor
Skriv ett program som slumpar en bakgrundsfärg och skapar 50 cirklar
med slumpmässig lite genomskinlig färg, slumpmässig storlek och
slumpmässig position. En ny bild ska skapas varje gång man trycker på
Uppdatera.
23
KONSTPROGRAMMERING
58
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å
https://www.khanacademy.org/computing/computer-programming/docs/pjs
24
KONSTPROGRAMMERING
59
Bilaga D
Testuppgift
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
6. Spara som titel: Test namn: ditt ID
18
KONSTPROGRAMMERING
60