Onderzoek naar mobiele apparaten als leerplatform voor informatica in het voortgezet onderwijs

Transcriptie

1 Eindhoven University of Technology MASTER Onderzoek naar mobiele apparaten als leerplatform voor informatica in het voortgezet onderwijs Crombach, C.J.H.; Eggenkamp, R.H. Award date: 2012 Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 26. Dec. 2017

2 Onderzoeksverslag Onderzoek naar mobiele apparaten als leerplatform voor Informatica in het voortgezet onderwijs Onderzoek van Onderwijs (EME19) Studiejaar Uitgevoerd door: Coen Crombach (303528) François Vonk ( ) Robin Eggenkamp ( ) Begeleid door: Kees Huizing Jacob Perrenet Versie juli 2012

3

4 Samenvatting Programmeren wordt gezien als een essentieel onderdeel van het informatica-curriculum in het voortgezet onderwijs. Nieuwe generaties studenten worden omringd door computer gerelateerde instrumenten. Bij het oplossen van problemen van uiteenlopende aard wordt deze apparatuur vaak ingezet. Het wordt dan ook voor iedereen steeds belangrijker te kunnen werken met computers, te begrijpen hoe ze werken en ze (tot op zekere hoogte) te kunnen programmeren. Hoe kunnen we leerlingen motiveren om te leren programmeren en hoe leren we ze dit op een zo effectief mogelijke manier? Onze hypothese is dat mobiele apparaten zoals smartphones hiervoor een geschikte context zijn. Mobiele telefoons zijn immers niet meer weg te denken uit het leven van de leerlingen in het voortgezet onderwijs. De mobiele context gecombineerd met de juist didactische aanpak en ontwikkelomgeving (een visuele omgeving genaamd App Inventor in ons geval) vormt volgens ons een motiverende en effectieve leeromgeving. De resultaten van ons onderzoek zijn beschreven in dit verslag en ondersteunen onze hypothese. Deze resultaten hebben geleid tot lesmateriaal dat gebruikt kan en zal worden bij het leren programmeren in het voortgezet onderwijs. 1

5 2

6 Inhoudsopgave Samenvatting Inhoudsopgave 1. Introductie 2. Theorie 3. Onderzoeksvragen 4. Methode 4.1. Steekproef en respondenten 4.2. Procedure 4.3. Instrumenten Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal Enquête over motivatie bij programmeren Masterclass voor het verzamelen van feedback op het ontwikkelde materiaal Interviews voor het verzamelen van feedback op het ontwikkelde materiaal 5. Resultaten 5.1. Gebruikte programmeermethoden en tekortkomingen 5.2. Criteria goed programmeeronderwijs 5.3. Motiverende werking van apps maken voor mobiele apparaten 5.4. Geschiktheid gebruik visuele programmeeromgeving 5.5. Perceptie met betrekking tot het ontwikkelde lesmateriaal 6. Discussie 6.1. Conclusies 6.2. Aanbevelingen tot verder onderzoek 6.3. Aanpassingen ten opzichte van het onderzoeksplan 6.4. Samenwerkingsproces Referenties Bijlagen A. Vragenlijsten A.1. Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: vakdidactici A.2. Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: docenten A.3. Enquête over motiverende contexten bij programmeren A.4. Vragenlijst evaluatie ontwikkelde lesmateriaal B. Resultaten en conclusies uit enquêtes B.1. Resultaten en conclusies van de oriënterende enquêtes B.2. Resultaten en conclusies van de enquête over motivatie bij programmeren B.3. Resultaten en conclusies van de lesmateriaal evaluaties C. Bekeken en vergeleken lesmateriaal C.1. GameMaker4School C.2. Fundament Informatica: Ontwikkelen van ios applicaties 3

7 C.3. Ervaring met Solid Edge en Google Sketchup D. Ontwerpplan lesmateriaal E. Docentenhandleiding F. Lesmateriaal 4

8 1. Introductie Programmeren is een moeilijk (Van Diepen, 2005), maar wel een essentieel onderdeel van het informatica-curriculum (Saeli, 2012). Nieuwe generaties studenten worden omringd door computer gerelateerde instrumenten. Bij het oplossen van problemen van uiteenlopende aard wordt deze apparatuur vaak ingezet. Het wordt dan ook voor iedereen steeds belangrijker te kunnen werken met computers, te begrijpen hoe ze werken en ze (tot op zekere hoogte) te kunnen programmeren. Mobiele apparaten worden vaak als een bedreiging gezien voor het schoolwerk. Veel scholen verbieden het gebruik van bijvoorbeeld mobieltjes in de klas. Wij, in de positie van informatica docent, zien juist een kans om leerlingen gemotiveerd te krijgen door ze op een leuke, maar ook serieuze manier, te laten werken met hun telefoon. Zo kunnen we leerlingen laten zien dat er heel wat te leren valt over informatica rondom hun mobiele telefoon. Het aspect waar we ons vooral op willen richten is het programmeren van apps, bijvoorbeeld met App Inventor. Wie gebruikt ze per slot van rekening niet tegenwoordig? Leerlingen zijn er dagelijks mee bezig, hun telefoon is een computer waar ze graag mee werken en waar een heleboel mee mogelijk is. Wij zijn benieuwd of ze hierdoor gemotiveerd zullen raken om te leren programmeren. Immers, wat ze bouwen kunnen zij en hun klasgenoten meteen, altijd en overal delen en gebruiken. Tijdens het leren programmeren moet een leerling volgens Govender (Govender, 2006) drie dingen leren: data, instruction and syntax. Hierbij staat syntax voor de groep regels die bepalen wat wel en wat niet mag in een programmeertaal. Als leerlingen zich niet aan de syntax houden krijgen ze foutmeldingen. In tekstuele programmeeromgevingen zijn die veelal moeilijk te begrijpen, zeker voor een beginnend programmeur. Voor het leren programmeren is Computational Thinking (Wing, 2006) ook noodzakelijk, leerlingen moeten een probleem zodanig kunnen formuleren dat het om te zetten is in een voor de computer begrijpbaar programma. In een grafische programmeeromgeving, zoals App Inventor, is het leren en toepassen van de basis syntax van het programmeren eenvoudiger dan in een tekstuele programmeertaal. Programma s worden namelijk geconstrueerd door blokken (grafisch gerepresenteerde programmeerelementen) in elkaar te klikken. De blokken zijn zo vormgegeven dat leerlingen duidelijk kunnen zien hoe ze in elkaar passen. Ze kunnen de correcte syntax herkennen aan de vorm van de blokken. Hierdoor leert een leerling op een intuïtieve manier (blokken als analogie voor programmeerelementen) de basis concepten van het programmeren, zonder daarbij belast te worden met de complexe syntactische details van een tekstuele programmeertaal en de bijbehorende onduidelijke foutmeldingen. 5

9 Een voorbeeld uit de PaintPot tutorial ( De hierboven beschreven eigenschappen van grafisch programmeren willen we gebruiken om de motivatie en effectiviteit bij het leren programmeren van leerlingen in het voortgezet onderwijs te bevorderen. We zullen dit onderbouwen aan de hand van literatuur en meningen van vakdidactici en collega docenten. Aan de hand daarvan gaan we op een gefundeerde manier lesmateriaal ontwikkelen in de vorm van een programmeermodule voor het voortgezet onderwijs. 6

10 2. Theorie Programmeeronderwijs staat nog relatief in haar kinderschoenen en programmeren is geen gemakkelijk onderwerp om te onderwijzen (Van Diepen, 2005). Leren programmeren vereist van de leerling dat deze zich op zowel hoog niveau (eisen en ontwerp) als op laag niveau (syntax en bijbehorende foutmelding) ontwikkelt. Waar begin je? Ervaring wijst uit dat beginnen op hoog niveau lastig is zonder enige kennis te hebben van het lage niveau. Echter op laag niveau beginnen is vaak niet motiverend omdat leerlingen met triviale en saaie problemen te maken krijgen. Bovendien verzanden ze al gauw in de details van de programmeeromgeving (Van Dijk en Koppelman, 1995). Om het probleem van waar te beginnen met leerlingen leren programmeren te omzeilen stelt Van Merriënboer het zogenaamde Programmeren door completeren voor (Van Merriënboer, 1992). De uitdaging hierbij is het aanbieden van een raamwerk dat uitdagend maar wel begrijpbaar is voor de leerlingen. Saeli geeft in haar proefschrift (Saeli, 2012) ook aan dat de completeerstrategie een mogelijk geschikte didactische aanpak voor het leren programmeren is. Een andere uitdaging ligt in het kiezen van een geschikte programmeeromgeving. Daar waar omgevingen met compilers of interpreters worden gebruikt kampt men met het probleem van foutmeldingen die vaak onduidelijk en moeilijk te begrijpen zijn. Deze leiden af van het werkelijke onderwerp, namelijk het leren van programmeerconcepten. Hierdoor verloopt het leerproces niet op een effectieve manier. Bovendien komen ze de motivatie van de leerling niet ten goede (Diepen, Perrenet, Zwaneveld, 2011). Programmeren is geen onderwerp dat iemand snel leert. De hoeveelheid tijd die beschikbaar is in het voortgezet onderwijs voor het leren programmeren is beperkt;; maximaal 110 uur voor HAVO en 170 uur voor VWO (afgeleid uit Schmidt, 2007). In deze uren moeten leerlingen ook nog leren over het ontwikkelproces en projectmatig werken. Daarom is het belangrijk dat leerlingen op een zo effectief mogelijke manier leren programmeren. Onderzoek onder informatica docenten in het voortgezet onderwijs en onderzoek naar bestaande lesmethoden wijst uit dat er een beperkte hoeveelheid programmeerconcepten aangemerkt kunnen worden die als belangrijk worden beschouwd, de zogenaamde Big Ideas van programmeren (Saeli, 2012). Een tweetal van deze Big Ideas, decompositie en algortimes, speelt ook een rol bij het Computational Thinking (Wing, 2006). Er is geen onderzoek bekend naar de motiverende werking van App Inventor als programmeeromgeving in het voortgezet onderwijs. Ervaring met App Inventor in het hoger beroeps- en wetenschappelijk onderwijs is er wel (Wolber, 2011). Hierin wordt geconcludeerd dat studenten die vrijwel meteen apps, met een real-world impact, kunnen bouwen gemotiveerd zijn om de uitdaging van het oplossen van moeilijke logische problemen aan te gaan. Een bijkomende observatie was dat bleek dat een student met dyslexie beduidend minder problemen had met het programmeren in App Inventor dan in een tekstuele 7

11 omgeving. Tot slot moet informatica in het voortgezet onderwijs niet alleen gericht zijn op de korte termijn (Diepen, Perrenet, Zwaneveld, 2011). De volgende lange termijn doelen kunnen worden gedefinieerd: Inzicht hebben in de mogelijkheden en onmogelijkheden van informatica. Herkennen of een probleem zich leent voor een informatica-aanpak. Informatica-aanpakken kennen, zoals analyseren, ontwerptechnieken gebruiken en prototyping toepassen. Begrip hebben van en inzicht hebben in belang, mogelijkheden en beperkingen van de toe te passen informatica-aanpakken. De gebruiker een centrale rol geven in het proces, rekening houdend met sociale en ethische aspecten. Programmeeronderwijs als onderdeel van het informaticacurriculum kan en moet hier dan ook een bijdrage aan leveren. Het aanleren van algoritmisch denken hangt hier sterk mee samen. Relevante begrippen De volgende domein specifieke begrippen spelen een centrale rol in ons onderzoek: App afkorting voor applicatie, computerprogramma, tegenwoordig vaak gebruikt voor apps die op een mobiel apparaat draaien. Android besturingssysteem dat op veel van de huidige mobiele apparaten draait. App Inventor SDK waarmee grafisch software voor Android toestellen ontwikkeld kan worden. Mobiel apparaat apparaat zoals de iphone, de ipad of een Android-toestel. SDK Software Development Kit. Een verzameling hulpmiddelen voor het ontwikkelen van software voor een bepaald product. De volgende onderwijskundige begrippen spelen een centrale rol in ons onderzoek: Computational Thinking Computational thinking builds on the power and limits of computing processes, whether they are executed by a human or by a machine (Wing, 2006, p.33). Computational Thinking is een houding tezamen met een verzameling van vaardigheden en technieken om problemen op te lossen. De oplossingen worden gezocht in de vorm van algoritmes die uiteindelijk de basis voor een computerprogramma zouden kunnen zijn. Enkele technieken zijn: probleem ontleding, patroonherkenning, abstractie, data analyse en visualisering. Effectiviteit The criterion for effective teaching, schools, and education is the extent to which they are finally able to reach goals, the amount of variance of student outcomes in those goals explained by teachers, schools, and education in general (Creemers, 1999, p.52). Vertaald naar ons onderzoek betekent dit dat we moeten kijken naar de doelen van programmeeronderwijs en hoe deze bereikt worden door onze en bestaande programmeermethoden. 8

12 Motivatie De term motivatie refereert aan een toestand waarin een individu zich bevindt, wanneer een of meer motieven, onder invloed van bepaalde omstandigheden, worden geactualiseerd. Motivatie wordt vastgesteld aan de hand van drie gedragsparameters: namelijk intensiteit van gedrag, doelgerichtheid, en persistentie (Boekaerts & Simons, 1993, p.105). 9

13 3. Onderzoeksvragen Er zijn veel onderzoeksvragen mogelijk als het gaat over programmeeronderwijs. In ons onderzoek richten we ons op de onderstaande vragen. Elke onderzoeksvraag krijgt hier ook een identificatie, bijvoorbeeld [1-Methoden], zodat we naar de vragen kunnen verwijzen in de rest van ons verslag. 1. Welke programmeermethoden worden er nu gebruikt in het voortgezet onderwijs en wat zijn de tekortkomingen van deze methoden met betrekking tot effectiviteit en motivatie? [1-Methoden] Op dit moment wordt er een breed scala aan programmeermethoden gebruikt binnen het voortgezet onderwijs. Naar ons idee wordt er hierbij te weinig aandacht besteed aan motivatie en effectiviteit, waardoor er op dit vlak verbeteringen zijn door te voeren. 2. Aan welke criteria moet goed programmeeronderwijs voldoen? [2-Criteria] Wij verwachten hier een antwoord in lijn met de Big Ideas van Saeli (Saeli, 2012). 3. Motiveert het maken van applicaties voor mobiele apparaten, met bijvoorbeeld App Inventor, leerlingen meer dan bestaande methoden? In het bijzonder de leerlingen met een niet N-profiel? [3-Motivatie] Gezien de interesse van leerlingen in mobiele telefoons verwachten wij dat het maken van apps de leerlingen ook motiveert. 4. Is het gebruik van visuele ten opzichte van tekstuele programmeeromgevingen zoals voornamelijk gebruikt in de geanalyseerde methoden geschikter voor het aanleren van de basis principes van het programmeren? [4-Visueel] Wij verwachten dat visuele programmeeromgevingen geschikter zijn om te leren programmeren, voornamelijk omdat hierbij de nadruk ligt op programmeerconcepten en niet op de syntax. 10

14 4. Methode De aanpak om onze onderzoeksvragen beantwoord te krijgen is tweeledig. Enerzijds zullen we in de literatuur zoeken naar antwoorden, anderzijds zullen we informatica vakdidactici, docenten en leerlingen enquêtes afnemen en interviewen. Dit onderzoek is ontwerpgericht, we zullen een interventie ontwerpen [lesmateriaal] met het doel een complex onderwijsprobleem [leren programmeren] op te lossen en de kennis te vergroten met betrekking tot de kenmerken van deze interventies en hun ontwerp- en ontwikkelingsprocessen (Plomp, 2009). Praktisch betekent dit dat we op basis van de uitkomsten van het literatuuronderzoek en de enquêtes lesmateriaal zullen ontwikkelen. Vervolgens verzamelen we feedback op het ontwikkelde materiaal bij de deelnemers aan de enquêtes en komen we tot aanbevelingen tot verbetering van het materiaal. Er is een aantal enquêtes ontworpen: die voor docenten en vakdidactici en die voor leerlingen. De enquêtes voor docenten en vakdidactici richten zich op het programmeeronderwijs in het algemeen, de methode van lesgeven zoals nu wordt toegepast en de daarbij horende motivatie en effectiviteit, en de verwachting van hen bij onze ideeën. De enquête voor leerlingen richt zich enkel op motivatie. Gedurende een masterclass (nascholing voor informatica docenten) hebben we ons materiaal gepresenteerd, docenten met het materiaal laten werken, en hen vervolgens individueel en plenair om feedback gevraagd. Daarnaast hebben we nog enkele docenten persoonlijk geïnterviewd middels open interviews. We hebben hierbij wel een vragenlijst gebruikt als houvast maar lieten de respondent de loop van het gesprek mede bepalen. Door de interviews en de masterclass kunnen we inzicht krijgen in de afhankelijke variabelen van ons onderzoek;; te weten wat is de perceptie van informatica vakdidactici en docenten met betrekking tot het door ons ontwikkelde lesmateriaal. We hebben enkele bestaande methoden onderzocht. We hebben hierbij gebruik gemaakt van het proefschrift van Saeli (Saeli, 2012), waarin zij drie in Nederland veel gebruikte methoden vergelijkt, namelijk Fundament Informatica, Informatica Actief en Enigma. Zij geeft in haar proefschrift een overzicht in hoeverre de door haar gebruikte Big Ideas van programmeren door deze methoden gecoverd worden. We hebben ook bekeken en besproken hoe het boek GameMaker4School, een nieuwe programmeermodule van Fundament Informatica Ontwikkelen van ios applicaties en een methode behorende bij Solid Edge en Google Sketchup zijn opgezet (zie bijlage C.). 11

15 Omdat we de beschikking hebben over een beperkt aantal vakdidactici en docenten zullen we voornamelijk kwalitatief onderzoek doen, aangevuld met de enquête over motivatie onder leerlingen. Begrippen als motivatie van leerlingen en effectiviteit van een leerproces lenen zich bij uitstek voor kwalitatief onderzoek. Je kunt vragen of motivatie is toegenomen, maar niet of het verdubbeld is, de nadruk ligt op ordinale gegevens. De vragenlijsten lieten we zo open mogelijk (veel ruimte voor toevoegingen van de respondenten) en ook het open interview is hiervoor een geschikte vorm. Door dit kwalitatief onderzoek te combineren met literatuur onderzoek kunnen we alle vier de onderzoeksvragen beantwoorden Steekproef en respondenten In de hierna volgende tabel is te zien hoeveel respondenten we bij de diverse onderdelen hebben gebruikt. Meer informatie over deze respondenten is te vinden in de samenvatting van reacties in bijlage A. Onderdeel Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: Didactici Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: Docenten Aantal 5 8 Motivatie enquête leerlingen 59 Evaluatie lesmateriaal: Didactici en docenten

16 4.2. Procedure Een schematische weergave van de fasen in ons onderzoek is te zien in de volgende figuur: Zoals te zien in het bovenstaande figuur is de eerste fase van het onderzoek een literatuuronderzoek. In de literatuur hebben we gezocht naar (deel-)antwoorden op onze onderzoeksvragen en informatie om te gebruiken voor het opzetten van de enquêtes. Aan de hand hiervan zijn enkele enquêtes opgezet die worden besproken in paragraaf en Met de gegevens verkregen uit het literatuuronderzoek en de resultaten van de enquêtes is begonnen met het ontwikkelen van lesmateriaal. Hierop volgend hebben we drie manieren van feedback gebruikt: een masterclass workshop, individuele interviews met docenten en schriftelijke feedback van vakdidactici en enkele andere geïnteresseerden. Op deze manier hopen we zoveel mogelijk feedback op het materiaal te ontvangen. Tot slot zullen we komen met aanbevelingen ter verbetering van het materiaal. Omdat we het materiaal zelf willen gaan toepassen in ons onderwijs is ons plan om zelf, na afloop van het onderzoek, aan de slag te gaan met de aanbevelingen en het materiaal verder te ontwikkelen. 13

17 4.3. Instrumenten In dit hoofdstuk beschrijven we de verschillende instrumenten die wij gebruikt hebben om gegevens te verzamelen ter onderbouwing van onze onderzoeksvragen. Deze instrumenten kunnen getoetst worden op een viertal kwaliteitsaspecten: validiteit (validity;; Van den Akker, 1999 en slides bijeenkomst Onderzoek van Onderwijs): Een instrument is valide als het meet wat het beoogd is te meten en gebaseerd is op recente kennis. Validiteit kan worden getest door het instrument voor te leggen aan experts. bruikbaarheid (practicality;; Van den Akker, 1999): Bruikbaarheid betekent dat een instrument in de praktijk toepasbaar is en kan worden getest door middel van een try-out. effectiviteit (effectiveness;; Van den Akker, 1999): Effectiviteit geeft aan of de resultaten overeenkomen met het doel van het instrument. Van den Akker geeft aan dat dit getest kan worden door field-tests. betrouwbaarheid (slides bijeenkomst Onderzoek van Onderwijs): Een instrument is betrouwbaar als (1) het datgene wat het meet, goed meet, (2) het consistent is en (3) de meting vrij is van verstorende invloeden. Per instrument zullen we aangeven in hoeverre we het hebben kunnen toetsen aan deze eisen voor kwaliteit Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal Deze enquête is ingezet om er achter te komen wat vakdidactici en docenten belangrijk vinden aan programmeeronderwijs en om onze ideeën en plannen te valideren en aan te scherpen. Met deze enquête leveren we dus informatie voor alle vier de onderzoeksvragen. De vragenlijsten (zie bijlage A.1. en A.2.) voor de enquêtes bestaan uit 16 vragen verdeeld over 4 categorieën: algemeen (5 gesloten vragen), informatica curriculum (2 gesloten vragen plus toelichting), programmeermethoden (7 open vragen) en context/motivatie (2 gesloten vragen plus toelichting). Aan de hand van de door ons gewenste informatie is de eerste versie van de vragenlijst opgesteld. Hierbij hebben we gebruik gemaakt van de door de ESoE aangeleverde checklist voor vragenlijsten. Verder kunnen we het volgende over de kwaliteitsaspecten zeggen: validiteit: Als eerste hebben we de vragenlijst voorgelegd aan een begeleider (expert) en een medestudent (try-out). Hieruit is de tweede versie van de vragenlijst voortgekomen. Dit is de vragenlijst die aan de vakdidactici is gestuurd (field-test). Naar aanleiding van feedback van de vakdidactici is een derde versie van de vragenlijst gemaakt die aan de docenten is gestuurd. 14

18 bruikbaarheid: De tweede versie van de vragenlijst was bruikbaar op basis van de feedback van de medestudent (try-out). De derde versie was bruikbaar op basis van de feedback van de vakdidactici (field-test). effectiviteit: Dit hebben we ondanks de field-test niet expliciet getoetst omdat we slechts één analyse slag op de antwoorden hebben gedaan. De effectiviteit is echter voldoende voor ons onderzoek omdat we op basis van de analyse onze onderzoeksvragen hebben kunnen beantwoorden. betrouwbaarheid: Dit hebben we niet expliciet getoetst. De afname heeft online plaatsgevonden via een Google Docs formulier Enquête over motivatie bij programmeren Deze enquête (zie bijlage A.3.) onder leerlingen is bedoeld om ons vermoeden over de motivatie voor het ontwikkelen van apps voor mobiele telefoons te bevestigen. Vanwege de kleine schaal hebben we de kwaliteitsaspecten voor deze enquête niet verder onderzocht. De enquête draagt bij aan het beantwoorden van onderzoeksvraag [3-Motivatie]. Deze korte vragenlijst hebben wij afgenomen onder leerlingen uit drie informatica klassen. In deze vragenlijst krijgen zij een twaalftal onderwerpen te zien die zij op een schaal van 0-3 (helemaal niet leuk tot heel leuk) moeten beoordelen. Daarnaast krijgen zij de vraag of er nog onderwerpen ontbreken. Er is bewust voor een schaal met een even aantal keuzes gekozen omdat we leerlingen willen dwingen een kant te kiezen. Ook deze vragenlijst is online afgenomen, via een Google Docs formulier, bij alle informatica klassen op twee scholen. Leerlingen kost het slechts enkele minuten om deze vragen te beantwoorden Masterclass voor het verzamelen van feedback op het ontwikkelde materiaal Ten behoeve van het evalueren van het door ons gemaakte lesmateriaal hebben wij het gepresenteerd gedurende een masterclass, als onderdeel van nascholing van docenten informatica. Ter voorbereiding hebben de docenten het materiaal toegestuurd gekregen. De masterclass bestond uit een korte introductie van ons onderzoek en de daaruit voortgekomen uitgangspunten die aan het materiaal ten grondslag liggen. Vervolgens kregen de docenten ongeveer anderhalf uur de tijd om ieder met het materiaal aan de slag te gaan. Om spreiding van de feedback te bevorderen hebben we de deelnemers ieder een hoofdstuk gegeven om op te focussen. Gedurende deze periode hebben we vrij met de docenten gesproken en feedback over motivatie, effectiviteit, duidelijkheid en bruikbaarheid ingewonnen. Het laatste uur van de masterclass hebben we gebruikt om het materiaal plenair te bespreken. De plenaire bespreking vond plaatst aan de hand van de vragenlijst uit bijlage A.4. Bij het opstellen van deze vragenlijst hebben we gebruik gemaakt van de door de ESoE aangeleverde checklist voor interviews. Verder kunnen we het volgende over de kwaliteitsaspecten zeggen: 15

19 validiteit: We hebben de vragenlijst eerst uitgetest via een individueel interview met een informatica docent (try-out). Op basis daarvan zagen we geen noodzaak om de vragenlijst aan te passen. bruikbaarheid: De vragenlijst was bruikbaar op basis van de feedback van de informatica docent (try-out) die we vooraf individueel geïnterviewd hebben. effectiviteit: Dit hebben we niet expliciet getoetst omdat we slechts één analyse slag op de antwoorden hebben gedaan. De effectiviteit is echter voldoende voor ons onderzoek omdat we op basis van de analyse onze onderzoeksvragen hebben kunnen beantwoorden. betrouwbaarheid: Dit hebben we niet expliciet getoetst. De verkregen feedback is genotuleerd en verwerkt. Hiervoor hebben we gekeken naar de methode beschreven in het Basisboek Kwalitatief onderzoek (Baarda, Goede, Teunisse, 2005). De gebruikte labels en uitwerking van de feedback zijn te vinden in bijlage B.3. Aan de hand van de verkregen informatie zijn wij in staat geweest te valideren of ons materiaal voldoet aan onze eigen verwachtingen. Dit heeft bijgedragen aan het beantwoorden van onderzoeksvragen [3-Motivatie] en [4-Visueel] Interviews voor het verzamelen van feedback op het ontwikkelde materiaal Aan de hand van de vragenlijst in bijlage A.4. hebben we ook enkele docenten geïnterviewd die niet bij de masterclass aanwezig waren. Ook in dit geval hebben we deze docenten het materiaal van te voren ter beschikking gesteld. De duur van deze interviews heeft gevarieerd van 1 tot 2 uur. De resultaten van de interviews zijn op dezelfde manier verwerkt als de in besproken resultaten uit de masterclass. Ook voor de kwaliteitscriteria geldt hetzelfde als in beschreven is. Wel kunnen we nu de masterclass als field-test voor de validiteit en bruikbaarheid van de vragenlijst zien. 16

20 5. Resultaten In dit hoofdstuk behandelen we onze resultaten door de gestelde onderzoeksvragen te beantwoorden. Daarnaast zullen we ook ingaan op de perceptie van informatica docenten met betrekking tot het ontwikkelde lesmateriaal en aangeven hoe we hun feedback gaan verwerken of verwerkt hebben Gebruikte programmeermethoden en tekortkomingen Ons literatuuronderzoek en de antwoorden op onze enquête leveren de onderstaande resultaten op over de gebruikte programmeermethoden in het voortgezet onderwijs en hun tekortkomingen met betrekking to effectiviteit en motivatie. De oriënterende enquête is geanalyseerd zoals beschreven in bijlage B.1. Voor de tekortkomingen van de gebruikte programmeermethoden zijn de volgende vragen relevant: vraag 8: Welke programmeertalen en bijbehorende lesmethoden gebruikt u in het middelbaar onderwijs? vraag 9: Wat vindt u de sterke en zwakke punten van deze talen en methoden? vraag 10: Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? De antwoorden op deze vragen geven direct inzicht in de eventuele tekortkomingen van de gebruikte methoden. In het materiaal dat gebruikt werd in de CODI trainingen (CODI - Vakdidactiek Informatica - II - dec. 2002) zien we de volgende opsomming van programmeeromgevingen en hun nadelen: Imperatief (klassiek);; Basic, C, Pascal: ouderwetse omgeving, niet aantrekkelijk, zonder kant-en-klare procedures en functies kom je niet ver Visueel;; Delphi, Java (Visual Café), Visual Basic: moeilijk vat op te krijgen, gebruik van standaardbibliotheken is lastig Functioneel (declaratief);; Haskell, Lisp, LOGO: Ziet er in het algemeen niet aantrekkelijk uit, minder gangbaar dus minder overdraagbaar, LOGO alleen een speelgoedtaaltje Logisch (declaratief);; Prolog: moeilijk vat op te krijgen, ziet er in het algemeen niet aantrekkelijk uit, minder gangbaar dus minder overdraagbaar Object-georiënteerd;; C++, Java: moeilijk vat op te krijgen, gebruik van standaardbibliotheken is lastig Programmeeromgeving;; auteurssysteem, code kruispunt, PSD: beperkt domein, beperkte taalmechanismes (b.v. geen parameteroverdracht) Hierbij dient opgemerkt te worden dat de categorisering in het artikel niet helemaal optimaal is gekozen door de makers. Zo is Visual Basic ondergebracht bij de categorie visueel terwijl deze ook bij Object-georiënteerd had kunnen staan. 17

21 Desondanks geeft dit een goed overzicht van veel voorkomende nadelen: ouderwets en niet aantrekkelijke ontwikkelomgeving (nadeel voor motivatie) sterke afhankelijkheid van standaard bibliotheken die niet makkelijk te doorgronden zijn (nadeel voor motivatie en effectiviteit) beperkte toepasbaarheid;; moeilijk om in korte tijd iets leuks te maken (nadeel voor motivatie en effectiviteit) Naast bovenstaande tekortkomingen met betrekking tot aantrekkelijkheid en gebruik van programmeeromgevingen is er ook onderzoek gedaan naar bestaande informatica onderwijsmethoden en in hoeverre zij de Big Ideas van programmeren adresseren (Saeli, 2012). In deze methoden worden een aantal van de eerder genoemde ontwikkelomgevingen gebruikt zoals Java, Delphi, PHP, BlueJ, VB.net en VB. Het blijkt dat veel van de bestaande methoden wel redelijk tot goed bijdragen aan de Big Ideas. Ook uit onze oriënterende enquête hebben we feedback gekregen over tekortkomingen van programmeermethoden die op dit moment door informatica docenten in het veld gebruikt worden. Hier volgt een overzicht: GameMaker en GML (GameMakerLanguage) Weinig oefenopdrachten te vinden waarbij één onderdeel een aantal malen herhaald wordt zodat echte verankering plaats vindt (vergelijk met Getal en Ruimte bij wiskunde). GML is specifiek voor GameMaker. Java Jcreator is te moeilijk voor scholieren. Ze gebruiken Eclipse en kopiëren de programma's om ze te wijzigen. Dat gaat goed. Java/Greenfoot Object oriëntatie kan soms moeilijk zijn. De methode biedt geen (extra) opdrachten aan de hand waarvan de leerlingen kunnen oefenen. De methode (aanschaf van het boek) is relatief duur. Ontbreken van goede debuggers. JavaLogo (Applet) De resultaten blijven vrij simpel, leerlingen raken daardoor redelijk snel verveeld. Het legt veel nadruk op ruimtelijk inzicht, leerlingen die daar moeite mee hebben, hebben ook met deze manier van programmeren moeite. PHP (& MySQL) Indirect karakter omdat het op een server draait. Hiermee wordt bedoeld dat het voor de leerlingen niet duidelijk is welke activiteiten op de server draaien en welke op de client. Integratie met HTML maakt het moeilijk. Veel syntax. Ontbreken van goede debuggers. RobotBasic Slechte editor, ongevoelig voor hoofdletters/kleine letters. 18

22 Struktograaf Niet fancy. De blokjes suggereren een structuur, maar dat is slechts schijn. Javascript Ontbreken van goede debuggers. BlueJ Pittig voor havo leerlingen. Ook de resultaten van de enquête laten zien we dat de ontwikkelomgevingen niet aantrekkelijk zijn (slecht voor de motivatie) en het vaak lastig is om iets leuks te maken in een korte tijd (niet effectief en slecht voor de motivatie). Daarnaast wordt aangegeven dat een goede debugger vaak ontbreekt. Het nodig hebben van een debugger duidt al op een programmeeromgeving die minder geschikt voor het voortgezet onderwijs. Het doel is immers om programmeerconcepten onder de knie te krijgen en niet om te leren debuggen. Moeten debuggen is slecht voor zowel de motivatie als de effectiviteit. Er wordt door de informatica docenten een veelheid aan programmeeromgevingen gebruikt zoals hierboven is aangegeven. De meeste van deze omgevingen lijken niet echt bij te dragen aan de motivatie (niet aantrekkelijk en lastig om snel iets leuks te maken) en effectiviteit (lastige syntax, bibliotheken moeilijk te doorgronden en debugger nodig). Een uitzondering hierop is GameMaker. Het maken van games lijkt een grote motiverende werking op leerlingen te hebben (dit zien we ook terug in onze enquête onder leerlingen naar programmeercontexten, zie bijlage B.2.). Het nadeel bij het maken van games is dat het lastig is om er de relevante programmeerconcepten expliciet in aan bod te laten komen. Dit probleem willen we met App Inventor aanpakken door leerlingen niet alleen games te laten ontwikkelen maar ook serieuze apps Criteria goed programmeeronderwijs Belangrijk bij goed programmeeronderwijs is dat leerlingen op de juiste manier de juiste dingen leren. Uit onderzoek (Saeli, 2012) blijkt dat er een aantal Big Ideas van programmeren te definiëren zijn die door informatica docenten en makers van informatica onderwijsmethoden als belangrijk worden beschouwd. De juiste didactische aanpak daarbij is nodig om deze ideeën ook daadwerkelijk bij de leerlingen te laten landen. Wat didactiek betreft zijn er meerdere theorieën: 1. Semiotic Ladder (Kaasbøll, 1998). Deze beschrijft dat programmeerkennis moet worden opgebouwd door achtereenvolgens de volgende aspecten van een programmeertaal te leren: syntax, semantics en pragmatics. Deze strategie wordt aangehaald door onder andere Koffman (Koffman, 1986) en Pascal, Liebenau en Backhouse (Pascal, Liebenau en Backhouse, 1990). 2. Cognitive Objectives Taxonomy (Kaasbøll, 1998). Deze beschrijft dat leerlingen programmeren moeten leren door de volgende stappen te doorlopen: a. een programma uitvoeren b. een stuk code van een programma lezen c. een bestaand programma aanpassen d. een eigen programma creëren 19

23 Deze strategie wordt aangehaald door onder andere Reinfelds (Reinfelds, 1995) en Kirkerud (Kirkerud, 1996). De theorie is gebaseerd op de taxonomy of cognitive objectives van Bloom (Krathwohl, 2002). 3. Problem Solving (Kaasbøll, 1998). Hierbij moeten leerlingen aan de hand van gestelde problemen leren programmeren. Men kan dit als een vorm van probleemgestuurd onderwijs zien. Deze strategie wordt aangehaald door Rogalski en Samurçay (Rogalski, Samurçay, 1990). 4. Programmeren door Completeren. Hierbij moeten leerlingen door het aanvullen van bestaande programma s die incompleet zijn leren programmeren (Van Merriënboer, 1992). Merk op dat dit nauw verwant is aan de derde stap uit de eerder genoemde Cognitive Objectives Taxonomy;; namelijk het aanpassen van een bestaand programma. Ook Saeli (Saeli, 2012) refereert hieraan als een mogelijk goede didactische aanpak. In de methode GameMaker4School (Maas, 2011) wordt deze aanpak ook gebruikt. In onze oriënterende enquête ging vraag 13 Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren? over criteria van goed programmeeronderwijs (zie bijlage B.1.). Volgens de ondervraagden zijn de volgende zaken belangrijk: computational thinking (Wing, 2006) control structures (selectie en lussen) datastructuren, -types en -abstractie procedures, functies en methoden variabelen Dit sluit aan bij de Big Ideas die genoemd worden in het onderzoek van Saeli (Saeli, 2012). Goed en effectief programmeeronderwijs vereist dat leerlingen de juiste dingen leren (de Big Ideas, programmeerconcepten) en dat hierbij de juiste didactische aanpak wordt gekozen zodat de concepten ook goed landen bij de leerlingen. Wat didactische aanpakken betreft kiezen wij voor de Cognitive Objectives Taxonomy en het leren programmeren door completeren. Deze twee aanpakken sluiten goed bij elkaar aan en vormen een goede manier om in kleine stappen het complexe probleem van het leren programmeren aan te pakken. Voor een deel haken we ook aan op de Problem Solving aanpak door leerlingen via pakkende apps aan het werk te zetten. De Semiotic Ladder vinden we minder geschikt omdat deze een sterke nadruk legt op syntax terwijl wij van mening zijn dat syntax (zeker in het begin) afleidt van het leren van de programmeerconcepten Motiverende werking van apps maken voor mobiele apparaten In de literatuur lijkt nog niets te vinden te zijn over de motiverende werking van het maken van apps voor mobiele apparaten als het gaat om leren programmeren binnen het voortgezet onderwijs. Vanuit het hoger beroeps en wetenschappelijk onderwijs zijn er wel geluiden dat op deze manier leren programmeren motiverend is (Wolber, 2011). In onze oriënterende enquête geven de antwoorden op vraag 15: Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren? 20

24 direct een indicatie voor de uitkomst van onze onderzoeksvraag (zie bijlage B.1.). Uit de antwoorden blijkt dat de helft van de vakdidactici denkt dat de mobiele telefoon als platform motiverend werkt en de andere helft denkt van niet. Initieel hadden we deze vraag als ja/nee vraag geformuleerd maar naar aanleiding van feedback van de vakdidactici hebben we hier voor de docenten een schaal van 1 tot 5 van gemaakt. Bij de docenten was iedereen neutraal tot enthousiast over het gebruik van de mobiele telefoon als platform om te leren programmeren. Dit bleek ook tijdens de workshop die we hebben gehouden met informatica docenten bij de Fontys. Eén docent gaf zelfs aan dat leerlingen al gevraagd hadden of ze apps voor hun telefoon mochten maken als onderdeel van de informatica les. Ook onze enquête onder leerlingen naar contexten voor programmeeronderwijs (zie bijlage B.2.) suggereert dat het maken van apps motiverend is. 86% van de leerlingen geeft aan dat ze dit leuk (49%) of heel leuk (37%) lijkt. In deze enquête is alleen het maken van games populairder en dit is iets dat ook voor de mobiele telefoon mogelijk is. Gezien de reacties hebben we niet meer expliciet gekeken naar de motiverende werking voor leerlingen met een niet N-profiel. De uitkomsten bevestigen onze hypothese over de mobiele apparaten als motiverend platform voor het leren programmeren Geschiktheid gebruik visuele programmeeromgeving Deze onderzoeksvraag kunnen we beantwoorden aan de hand van vraag 6: Is programmeren noodzakelijk in het informatica curriculum? en vraag 7 Is alleen visueel programmeren voldoende in het informatica curriculum? uit onze oriënterende enquête (zie bijlage B.1.). Het blijkt dat alle vakdidactici van mening zijn dat programmeren een essentieel onderdeel van het vak informatica is. Daarbij vinden twee van de vijf didactici dat visueel programmeren voldoende is. Ook onder docenten oordeelt men unaniem dat programmeren essentieel is binnen het vak informatica. Hier is men echter ook unaniem over het feit dat visueel programmeren niet voldoende is. Docenten en vakdidactici zijn het er over eens dat leerlingen in het voortgezet onderwijs moeten leren programmeren. Er zijn vakdidactici die vinden dat visueel programmeren voldoende kan zijn. Het merendeel van de ondervraagden vindt echter dat leerlingen ook tekstueel moeten leren programmeren. Ze zien een visuele programmeeromgeving wel als een goede opstap naar het tekstueel programmeren zo blijkt uit de toelichtingen bij de gestelde vragen. Naar aanleiding van de masterclass en de interviews met docenten informatica over ons materiaal kunnen we concluderen dat een visuele programmeeromgeving prima geschikt is om te leren programmeren. Ook een aantal artikelen die over programmeeronderwijs gaan suggereren dit. Deze geven aan dat tekstuele syntax en syntax errors van compilers en interpreters afleiden van het leren programmeren. Visuele programmeeromgevingen hebben dit nadeel niet. 21

25 5.5. Perceptie met betrekking tot het ontwikkelde lesmateriaal De perceptie van de informatica docenten die we gesproken hebben tijdens de masterclass (die we hebben gegeven in het kader van nascholing voor informatica docenten bij Fontys) was zeer positief. Dit geldt ook voor de docenten die we daarna nog individueel hebben geïnterviewd. Zowel de masterclass als de interviews hebben we gedaan aan de hand van de vragenlijst in bijlage A.4. De resultaten zijn te vinden in bijlage B.3. In het algemeen vond men het materiaal in de aangeboden toestand al bruikbaar in de klas. Uiteraard kan het materiaal nog verbeterd worden en daarvoor hebben we voldoende input van de deelnemende docenten gekregen. Daarnaast liggen er nog een aantal punten die we niet meer opgepikt hebben voor de workshop omdat we graag eerst wilden weten of het materiaal voldoet aan de verwachtingen van informatica docenten. Gedurende de masterclass hebben we veel feedback ontvangen van de aanwezige docenten en didactici. De indruk was voornamelijk positief, wat blijkt uit de volgende reacties: Leerlingen eerst laten stoeien met een bestaand project is een goede opzet. Tempo is goed. Leuk om te doen, duidelijk geschreven. Goede opstap naar een tekstuele programmeertaal. Spreekt waarschijnlijk aan bij leerlingen (al ben je hier nooit zeker van totdat de leerlingen er echt mee bezig zijn geweest) Doordat je je telefoon altijd bij je hebt en daarmee (trots) resultaten kunt laten zien aan anderen is het ontwikkelen van apps voor de mobiel motiverend. Door de lage drempel nodigt de omgeving uit tot onderzoeken. Mooi dat er veel optionele uitbreidingen bij staan. De volgende zaken nemen we in ieder geval mee in ons materiaal naar aanleiding van de workshop: Voor havo 4 leerlingen (met nadruk op vmbo instroom) gaat de opbouw in moeilijkheid waarschijnlijk te snel. Meer suggesties en bonus opgaven meegeven om leerlingen uit te dagen. Niet alle component namen zijn voor leerlingen direct duidelijk. Bijvoorbeeld: wat is een label? Een referentiehandleiding kan nuttig zijn. Na de techniek verder gaan met andere aspecten van ontwikkeling, zoals projectmanagement. Zorg dat er een klant is en laat de leerlingen meerdere iteraties meemaken. Lever een uitgebreid resources pakket mee. Het hoofdstuk Meteoor is wellicht te wiskundig. Het is niet altijd duidelijk voor de leerling of hij de tekst strak moet volgen (omdat hij anders de mist in gaat), of dat er eigen initiatief wordt verwacht. Extra motiverend kan het zijn als een app aan de echte wereld wordt gekoppeld door gebruik te maken van APIs. Een mashup bouwen dus. 22

26 Aan de docentenhandleiding ideeën over toetsen toevoegen. Docenten hebben de behoefte individueel te controleren of leerlingen het snappen. Hoe past dit in ons materiaal? De docentenhandleiding duidelijk verdelen in wat docenten echt moeten weten zodat de leerlingen aan de slag kunnen en achtergrond informatie. Ons doel was lesmateriaal te ontwikkelen dat motiverend en effectief werkt bij het leren programmeren in het voortgezet onderwijs. Afgaande op de reacties van docenten die ons materiaal bekeken en er mee gewerkt hebben zijn we hierin geslaagd. Ze vinden de opbouw goed waarin we een aantal van de didactische aanpakken uit de literatuur gebruikt hebben zoals de Cognitive Objectives Taxonomy en het programmeren door completeren. Verder zien ze de context inderdaad als motiverend omdat de mobiele telefoon een alledaags en populair apparaat is voor veel leerlingen. Ook zijn er leerlingen die al vragen of dit soort dingen bij informatica aan bod komen. 23

27 6. Discussie Het doel van ons onderzoek was het beantwoorden van de onderstaande vragen zodat we op een gefundeerde manier nieuwe lesmateriaal konden ontwikkelen voor het onderwijzen van programmeren in het voorgezet onderwijs: [1-Methoden] Welke programmeermethoden worden er nu gebruikt in het voortgezet onderwijs en wat zijn de tekortkomingen van deze methoden met betrekking tot effectiviteit en motivatie. [2-Criteria] Aan welke criteria moet goed programmeeronderwijs voldoen. [3-Motivatie] Motiveert het maken van applicaties voor mobiele apparaten, met bijvoorbeeld App Inventor, leerlingen meer dan bestaande methoden? In het bijzonder de leerlingen met een niet N-profiel? [4-Visueel] Is het gebruik van visuele ten opzichte van tekstuele programmeeromgevingen zoals voornamelijk gebruikt in de geanalyseerde methoden geschikter voor het aanleren van de basis principes van het programmeren? Er wordt op dit moment een overvloed [1-Methoden] aan methoden gebruikt waarbij eigenlijk alleen GameMaker als motiverend wordt gezien. Er is echter geen materiaal dat leerlingen leert programmeren op een effectieve manier. De criteria waaraan programmeeronderwijs moet voldoen is dat er een goede didactiek aan ten grondslag moet liggen en dat een aantal belangrijke programmeerconcepten (Big Ideas, Saeli, 2012) onderwezen moeten worden. Het gebruiken van mobiele apparaten als context om te leren programmeren is een motivator en een visuele programmeeromgeving is geschikter voor beginnende programmeurs dan een tekstuele programmeeromgeving. Ons onderzoek is voornamelijk gebaseerd op kwalitatief onderzoek. Enerzijds omdat de populatie die beschikbaar is voor het onderzoek niet voldoende groot is om kwantitatief onderzoek te doen, anderzijds omdat onze vragen zich goed lenen voor kwalitatief onderzoek. Omdat de derde vraag over motivatie zich ook leent voor kwantitatief onderzoek hebben we een kleine groep leerlingen hierover om input gevraagd. Dit als extra verificatie voor de resultaten uit het kwalitatief onderzoek onder vakdidactici en docenten informatica Conclusies Programmeeronderwijs staat nog in de kinderschoenen, zelfs op HBO- en WO-opleidingen. Docenten zijn op zoek naar effectieve didactische strategieën en motiverende contexten om leerlingen te leren programmeren. Uit ons onderzoek blijkt dat er een motiverende werking uitgaat van de door ons gekozen omgeving en context. Het onderzoek uitgevoerd door Saeli (Saeli, 2012) en ons onderzoek onder vakdidactici en docenten toont overlap in wat men ziet als belangrijke programmeerconcepten. Starten met een tekstuele programmeeromgeving werkt veelal niet motiverend en is bovendien niet effectief. Leerlingen verzanden in de syntax van de programmeertaal, de 24

28 foutmeldingen van de compiler of interpreter en de noodzaak om te debuggen. Dit leidt af van het leren van de programmeerconcepten die belangrijk worden geacht. Uit eigen ervaring weten we bovendien dat er hierdoor ook extra druk op de docent komt. Leerlingen verwachten dat de docent hen namelijk even snel kan helpen met het debuggen van hun problemen. Hierdoor verspilt een docent vaak veel tijd en als hij/zij de leerlingen niet kan helpen geeft dit ook nog een ontevreden gevoel over de leraar bij de leerlingen. Het verwachte eindniveau met betrekking tot programmeerkennis in het voorgezet onderwijs is vooralsnog onduidelijk. Ook de meningen van vakdidactici en docenten hierover lopen uiteen. Het materiaal dat we gemaakt hebben naar aanleiding van ons onderzoek is een goede start om een minimaal kennisniveau te bereiken. Het staat docenten vrij om daarna nog verder te gaan met programmeeronderwijs. Het materiaal dat we ontwikkeld hebben werd goed ontvangen. De initiële kwaliteit werd reeds als goed gezien en er zijn goede en nuttige verbeterpunten aangedragen. Na een verbeterslag zal het materiaal in een echte lessituatie getest gaan worden. Daarna wordt het opnieuw geëvalueerd en mogelijk verbeterd. Het materiaal zal ook open source ter beschikking worden gesteld, zie hiervoor Het materiaal wordt gezien als motiverend en effectief en dat was ons doel. Het informatica curriculum is behoorlijk gevuld. Een uitdaging is daarom het ontwikkelde materiaal te plaatsen binnen het curriculum. Het ontwikkelde materiaal kan dienen als vervanging van bestaande programmeermodules. Daarnaast kan ons materiaal gebruikt worden om te voorkomen dat leerlingen die zijn blijven zitten nog een keer met bijvoorbeeld GameMaker aan de slag gaan. Ons materiaal biedt de mogelijkheid om er andere aspecten van het informatica curriculum aan te koppelen. Buiten het leren programmeren kan het ook gebruikt worden om te leren hoe een klein softwareproject opgezet en uitgevoerd wordt Aanbevelingen tot verder onderzoek Naar aanleiding van vragen over welk lesmateriaal docenten nu gebruiken kwam regelmatig het antwoord eigen materiaal. Het is interessant om uit te zoeken waarom zo veel docenten eigen materiaal gebruiken. Zijn deze mensen bereid om (en onder welke voorwaarden) lesmateriaal van anderen te gebruiken? Zijn ze van mening dat er nog geen goed materiaal is, of kennen ze het niet? Vinden ze hun eigen materiaal beter? Vinden ze misschien dat je beter les kunt geven met redelijk tot goed eigen materiaal dan met goed materiaal van anderen? Kortom: als het lukt didactisch goed materiaal te maken, gaat dit dan ook gebruikt worden? In ons onderzoek hebben we niet meer expliciet gekeken naar de motiverende werking voor leerlingen met een niet N-profiel. Carrière- en doelgerichte leerlingen willen we ook graag enthousiasmeren voor programmeren. We denken dat dit met onze lesmethode gebeurt maar hebben hier geen bewijzen voor. 25

29 Uit het onderzoek blijkt dat de meeste vakdidactici en docenten informatica vinden dat alleen visueel programmeren niet voldoende is. Een relevante vraag daarom is wat goed aansluit op ons materiaal als het gaat om tekstueel programmeren. In het informaticacurriculum komen op het moment veel verschillende onderwerpen aan bod in relatief weinig tijd. Het lesmateriaal dat we hebben ontwikkeld kan niet zomaar worden toegevoegd. Er zijn wel ideeën over hoe het ingezet zou kunnen worden maar verder onderzoek op dit gebied is aan te bevelen Aanpassingen ten opzichte van het onderzoeksplan Gedurende het onderzoek hebben we op enkele punten besloten af te wijken van ons originele onderzoeksplan. In deze paragraaf worden deze punten kort besproken. Ten opzichte van ons plan hebben we de interviews anders ingericht. Ons plan was de docenten individueel te interviewen. We hebben echter de kans gekregen om gedurende een masterclass (nascholing informatica docenten) ons materiaal te presenteren, de docenten ermee te laten werken, en hen vervolgens individueel en plenair om feedback te vragen. Door deze aanpassing hebben we het informatie verzamelen efficiënter in kunnen richten. Omdat er nu ook mogelijkheid was tot discussie heeft dit geleid tot meer en dieper gaande feedback. Naast de masterclass hebben we, wel in lijn met het plan, nog enkele docenten (die niet aan de masterclass deelnamen of niet aanwezig konden zijn) persoonlijk geïnterviewd. Een ander punt waarop we afgeweken zijn van ons oorspronkelijke plan is het onderzoeken van bestaande methoden. We hebben Fundament Informatica en Enigma minder uitgebreid onderzocht aangezien Saeli (Saeli, 2012) in haar proefschrift drie in Nederland veel gebruikte methoden vergelijkt, namelijk Fundament Informatica, Informatica Actief en Enigma. Zij geeft in haar proefschrift een overzicht in hoeverre de door haar gebruikte Big Ideas van programmeren door deze methoden gecoverd worden. We hebben wel een aantal andere modules bekeken en besproken (zie bijlage C.). Tot slot hebben we een extra enquête toegevoegd aan ons onderzoek. Deze enquête is afgenomen onder leerlingen en betreft hun interesse in diverse contexten waarbinnen we programmeeronderwijs kunnen plaatsen. Wij hebben dit toegevoegd om ons vermoeden over de motivatie voor het ontwikkelen van apps voor een mobiele telefoon te bevestigen. Vanwege de kleine schaal van deze enquête hebben we de resultaten niet uitgebreid geanalyseerd volgens een methode voor kwantitatief onderzoek, zie bijlage B Samenwerkingsproces Omdat dit onderzoek is uitgevoerd door drie personen volgt in deze paragraaf een beschrijving van ons proces en onze taakverdeling. Dit om aan te verantwoorden dat we ieder voldoende tijd en inspanning in dit onderzoek hebben gestoken en de taken evenwichtig waren verdeeld. 26

30 Robin kwam met het idee om te onderzoeken of we leerlingen konden leren programmeren met behulp van een visuele omgeving zoals App Inventor waarmee ze apps kunnen maken voor hun mobiele telefoon. Hij hoopte dat hier materiaal uit kwam dat hij zelf het komende schooljaar in zijn klassen kan inzetten. François en Coen vonden dit een goed en leuk idee en besloten er aan mee te werken. Aangezien we elkaar elke woensdag zagen bij de ESoE was er elke week wel een moment om te overleggen wat er de komende week moest gebeuren. In het begin hadden we niet direct een duidelijke taakverdeling. Wel hadden we de bedoeling dat ieder aan alle aspecten van het onderzoek zou werken. Het bleek een leuk team. Op woensdag maakten we vaak al brainstormend aantekeningen en afspraken over taken die in de loop van de week dan uitgewerkt moesten worden. Als we niet bij elkaar konden komen gebruikten we Skype om te overleggen. Alle drie wilden we dit schooljaar het onderzoek afronden, alle drie hadden we ook genoeg andere dingen te doen. Het duurde even voor we op gang kwamen, er zijn als je voor de klas staat en tegelijk een studie als deze volgt altijd zaken die prioriteit hebben. Soms had de één meer tijd, dan de ander. Er ontstond als vanzelf een taakverdeling zonder dat we hier harde afspraken over maakten. Zo werd bij het opstellen van de vragenlijsten gezamenlijk gebrainstormd over wat er in moest komen, waarna iemand een eerste versie maakte, deze rond mailde en ieder gaf zijn commentaar of paste het aan. Zo gebeurde het met de meeste onderdelen. François heeft het voortouw genomen bij het maken van het lesmateriaal door de inleidende hoofdstukken te schrijven. Verder hebben we alle drie een inhoudelijk hoofdstuk geschreven: Mollen Meppen (François), Schrandere Scholier (Robin) en Meteoor (Coen). Pas tijdens het schrijven viel de beslissing het materiaal in LaTeX op te maken. Robin heeft vervolgens een geschikt template gezocht en bewerkt. Hij heeft ook het al bestaande materiaal omgezet in LaTeX. Coen en François moesten hiervoor het een en ander uitzoeken, want LaTeX en Windows bleek geen ideale combinatie (Robin werkt op een Mac). Door de LaTeX bestanden via Dropbox (en later Git) te delen was het mogelijk gezamenlijk aan het materiaal te werken. Nadat we de afzonderlijke delen samengevoegd hadden, hebben we de hoofdstukken op één lijn gebracht waarbij we allemaal een paar keer het document van voor tot achteren doorgewerkt hebben. De interviews hebben we verdeeld. Toen bood zich de mogelijkheid aan het materiaal in de masterclass bij Fontys te presenteren en ter plekke feedback te krijgen van de docenten. Het voorbereiden, regelen van de telefoons, internettoegang, maken van de boekjes, opstellen van de presentatie, het presenteren hebben we wederom verdeeld en het verzamelen van de feedback hebben we zoveel mogelijk per docent gedaan, waarbij wij elkaar afwisselden. Omdat elk zijn eigen sterke punten heeft, heeft ieder aan alle facetten van het onderzoek, het materiaal en het verslag gewerkt. 27

31 Referenties Akker, J. van den (1999). Principles and methods of development research. Design approaches and tools in education, pp Baarda, B., Goede, M. de, Teunissen, J. (2005). Basisboek Kwalitatief onderzoek. Stenfert Kroese. Boekaerts, M., Simons, P.R. (1993). Leren en Instructie: Psychologie van de leerling en het leerproces. Assen: Dekker & van de Vegt. Creemers, B.P.M. (1999). The effective teacher: What Changes and Remains. Asia-Pacific Journal of Teacher Education & Development, June 1999, Vol. 2, No. 1, pp Diepen, N. van (2005). Elf redenen waarom programmeren zo moeilijk is. Tijdschrift voor informaticaonderwijs, 14e jaargang 2005, nr. 4. Diepen, N. van, Perrenet, J., Zwaneveld, B. (2011). Which Way with Informatics in High Schools in the Netherlands? The Dutch Dilemma. Informatics in Education, 10(1), pp Dijk, E.M.A.G. van, Koppelman, H. (1995). From the Bottom to the Top? TINFON, 4(1), pp Govender, I. (2006). Learning to Program, Learning to Teach Programming: Pre- and In-service Teachers Experiences of an Object-oriented Language. South Africa: Unpublished doctoral dissertation University of South Africa. Kaasbøll, J.J. (1998). Exploring didactic models for programming. Tapir, pp Krathwohl, D. (2002) A revision of Bloom s Taxonomy: An Overview, Theory Into Practice vol. 41-4, pp Maas, P. (2011). GameMaker4School. Rosmalen: Interfax. Merriënboer, J.J.G. van (1992). Programmeren door completeren. TINFON, 1(2), pp Plomp, T., Nieveen, N. (2009). An Introduction to Educational Research. Enschede: SLO. Saeli, M. (2012, February). Teaching Programming for Secondary School: a Pedagogical Content Knowledge Based Approach. Eindhoven: Technische Universiteit Eindhoven. Schmidt, V. (2007). Handreiking schoolexamen informatica havo/vwo. Enschede: SLO. 28

32 Wing, J.M. (2006). Computational Thinking. Communications of the ACM, March 2006, 39(3), pp Wolber, D. (2011). App Inventor and Real-World Motivation, CIGCSE 11 ACM, March 2011, pp

33 30

34 Bijlagen 31

35 32

36 A. Vragenlijsten A.1. Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: vakdidactici Oriënterende vragenlijst Programmeeronderwijs Geachte heer/dame, Wij doen voor ons afstuderen aan de Eindhoven School of Education een onderzoek naar programmeeronderwijs. U hebt na een eerdere van ons aangegeven met ons onderzoek mee te willen doen. In de onderstaande vragenlijst vragen wij u naar uw mening over programmeertalen en daarmee verband houdende onderwijsmethoden waar u ervaring mee hebt. Het doel van ons onderzoek is een programmeermodule ontwikkelen die aanspreekt bij middelbare scholieren en die bovendien de leerling op een effectieve manier leert programmeren. Uw antwoorden worden vertrouwelijk behandeld en de resultaten van de vragenlijsten die wij in onze rapportage opnemen worden geanonimiseerd. Het invullen van de complete vragenlijst neemt ongeveer 15 minuten in beslag. * Required Algemeen 1. In welke leeftijdscategorie valt u?* jonger dan 30 jaar jaar jaar 50 jaar of ouder 2. Wat is de hoogste opleiding die u genoten heeft?* HBO Informatica WO Informatica HBO anders WO anders 3. Hoe lang geeft u het vak Informatica in het middelbaar onderwijs?* minder dan 2 jaar 2 tot 5 jaar 5 tot 10 jaar meer dan 10 jaar ik geef geen Informatica in het middelbaar onderwijs 33

37 4. Welke methode gebruikt u voor uw informatica onderwijs?* Fundament Informatica (Instruct) Enigma (voorheen Turing) Informatica Actief (voorheen Edu Actief) Eigen lesmethode ik geef geen Informatica in het middelbaar onderwijs Other: 5. Wat is de gemiddelde klasgrootte waaraan u les geeft?* minder dan 10 leerlingen 10 tot 20 leerlingen 20 tot 30 leerlingen meer dan 30 leerlingen ik geef geen Informatica in het middelbaar onderwijs Informatica curriculum 6. Is programmeren noodzakelijk in het informatica curriculum?* Ja Nee Toelichting: 7. Is alleen visueel programmeren voldoende in het Informatica curriculum?* Ja Nee Toelichting: Programmeermethoden 8. Welke programmeertalen en bijbehorende lesmethoden gebruikt u in het middelbaar onderwijs?* 9. Wat vindt u de sterke en zwakke punten van deze talen en methoden?* 10. Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? Gelieve uw antwoord toe te lichten.* 11. Hoe vindt u de motiverende werking van de deze talen en methoden?* 12. Hoe toetst u de leerlingen met betrekking tot deze talen en methoden en waarom hebt deze manier van toetsen gekozen?* 13. Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren?* 14. Brengt u een relatie aan tussen de diverse talen en methoden die u gebruikt?* 34

38 Context 15. Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren?* Ja Nee Toelichting* 16. Heeft u leerlingen die (buiten de lessen) bezig zijn met het ontwikkelen van mobiele applicaties?* Ja Nee Toelichting (wat doen en gebruiken deze leerlingen?) Tot slot 17. Zou u nog iets wijzigen aan deze vragenlijst voordat we deze doorsturen naar de docenten?* 35

39 5 reacties Overzicht Complete reacties bekijken Algemeen 1. In welke leeftijdscategorie valt u? jonger dan 30 jaar 0 0% jaar 1 20% jaar 2 40% 50 jaar of ouder 2 40% 2. Wat is de hoogste opleiding die u genoten heeft? HBO Informatica 0 0% WO Informatica 2 40% HBO anders 0 0% WO anders 3 60% 3. Hoe lang geeft u het vak Informatica in het middelbaar onderwijs? minder dan 2 jaar 1 20% 2 tot 5 jaar 0 0% 5 tot 10 jaar 1 20% meer dan 10 jaar 1 20% ik geef geen Informatica in het middelbaar onderwijs 2 40% 4. Welke methode gebruikt u voor uw informatica onderwijs? 36

40 Fundament Informatica (Instruct) 1 20% Enigma (voorheen Turing) 1 20% Informatica Actief (voorheen Edu Actief) 1 20% Eigen lesmethode 0 0% ik geef geen Informatica in het middelbaar onderwijs 2 40% Other 0 0% 37

41 5. Wat is de gemiddelde klasgrootte waaraan u les geeft? minder dan 10 leerlingen 0 0% 10 tot 20 leerlingen 0 0% 20 tot 30 leerlingen 3 60% meer dan 30 leerlingen 0 0% ik geef geen Informatica in het middelbaar onderwijs 2 40% Informatica curriculum 6. Is programmeren noodzakelijk in het informatica curriculum? Ja 5 100% Nee 0 0% Toelichting: Niet te veel, maar zoveel dat het hele ontwerp/ontwikkeltraject een keer doorlopen wordt. Bij vrijwel alle informaticaactiviteiten kom je programmeeraspecten tegen. Het is een belangrijk onderdeel van informatica, daarnaast ook een leuk, praktisch onderdeel. Programmeren en modelleren moet aan bod komen. 7. Is alleen visueel programmeren voldoende in het Informatica curriculum? Ja 2 40% Nee 3 60% Toelichting: 38

42 Als dat tenminste efficiëntievoordelen heeft. Bij visueel programmeren 'kun je geen fourteen maken' maar je moet door de ervaring van syntax error, puntkomma vergeten heen Onder visueel programmeren versta ik het programmeren aan de hand van sleep en klik acties. In principe kan dit denk ik voldoende zijn, hoewel het wel lastig zal zijn om goede opdrachten te bedenken die alleen met visueel programmeren zijn op te lossen. Het gaat erom dat leerlingen bepaalde problemen kunnen oplossen, dat kan in principe met visueel programmeren. Visueel programmeren is een (mogelijke) eerste stap bij het ler... Programmeermethoden 8. Welke programmeertalen en bijbehorende lesmethoden gebruikt u in het middelbaar onderwijs? RobotBasic php struktograaf geen methoden ik geef geen informatica in het vo. Nvt (started met structograaf vind ik niet verkeerd) PHP (informatica-actief) Java (Greenfoot) Applet JavaLogo (informatica-actief) Game-Maker (divers materiaal) Ik gebruik onder andere: (1) Python met de cursus van /ThinkPython (2) SQL zoals in Enigma aan bod komt (3) NetLogo zoals in Enigma aan bod komt (4) GameMakerLanguage (GML) bij de lln van 6vwo als ze een spel moeten maken 9. Wat vindt u de sterke en zwakke punten van deze talen en methoden? slecht: RobotBasic: slechte editor; ongevoelig voor hoofdletters/kleine letters php: indirectie omdat het op een server draait struktograaf: niet fancy, de blokjes suggereren een struktuur, maar dat is slechts schijn. zie 8 Nvt PHP: nadelen: integratie met HTML maakt het moeilijk. Veel syntax. voordelen: integratie met databases goed mogelijk. Leerlingen maken interactieve websites, dat maakt het boeiend voor leerlingen. Kan met standaard, gratis tools. Je kunt makkelijk beginnen met simpele voorbeelden. Java / Greenfoot: nadelen: object georiënteerd kan soms moeilijk zijn. De methode biedt Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? Gelieve uw antwoord toe te lichten. robotbasic: ok php: ok voor de mensen die het door hebben struktograaf: laag zie 8 Resultaten blijven lastig. Je moet je vaak beperken tot toy-problems. En dat is niet altijd interessant. JavaLogo en PHP minder. Met GameMaker en Greenfoot zeker, bij (1) Bij Python doet vooral de turtle het goed. En ook GvRng voor de herkansing van 4havo (2) Het formuleren van een query levert vaak het gewenste resultaat op; de lln hebben meerdere succeservaringen (3) De gegeven AI modellen van Enigma spreken de lln aan (4) Het snelle en leuke resultaat kan ook met visueel programmeren. Het gebruik van GML code l Hoe vindt u de motiverende werking van de deze talen en methoden? robotbasic: direct resultaat php: lastig te debuggen zie 8 Zie boven Idem als vorige vraag: GameMaker en Greenfoot werken erg motiveren, PHP deels ook, JavaLogo wat minder. (1) Python is een hele goede basistaal, die de lln (pas) later weten te waarderen (2) Met SQL kunnen de db's worden geraadpleegd achter interactieve websites (3) Zie antwoord van vraag 10 en het inspringen van NetLogo kennen de lln van Python (4) De lln van 6vwo zien dat ze met GML het ook voor elkaar krijgen, het hoeft niet perse visueel 12. Hoe toetst u de leerlingen met betrekking tot deze talen en methoden en waarom hebt deze manier van toetsen gekozen? individuele toets op de PC, en prakticumopdracht (event. in duo's) gekozen omdat mijn voorganger het ook zo deed zie 8 Nvt Praktische opdrachten en een toets. De praktische opdrachten bestaan uit deelopdrachten, waarin een verplicht deel en een vrij deel in zit. Deze mogen in tweetallen worden gemaakt. De toets bestaat uit een theoretisch deel, waarin onder meer wordt gevraagd naar terminologie en begrip, alsook het lezen van code, en uit 39

43 een praktisch deel, waarbij de leerlingen tijdens de toets een klein programma moeten maken. met een individuele practische opdracht (PO) en een the... (1) Python 13. Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren? computational thinking variabele, datastructuren, lussen, problemsolving Programma-ontwerp Programmaflow Sequentie Keuze Iteratie Data-abstractie Procedurele abstractie Bouwstenen - Begrip van controle structuren, variabelen, methoden, parameters, OO begrippen zoals klassen, objecten, etc. - Het toepassen van controle structuren, variabelen, methoden, etc - Debug-vaardigheden. - Oplossen van problemen. De 3 controle-structuren (sequentie, keuze en herhaling), decompositie met functies, enkele datatypen, goede naamgeving van variabelen, goed gebruik van commentaar 14. Brengt u een relatie aan tussen de diverse talen en methoden die u gebruikt? niet expliciet; wel expliciet (variabelen, expressies, if/for) zie 8 Nvt Voor een deel. Bijv deeltaken bij Javalogo = methoden bij Java. Variabelen bij JavaLogo = variabelen bij Java. Controle structuren bij JavaLogo = controlestructuren bij Java. Verder nog (te) weinig. Ja, Python fungeert als basis voor NetLogo en GML Context 15. Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren? Ja 2 40% Nee 2 40% Toelichting de mobiele telefoon is teveel een 'black box' Neutraal. Maar moet ja of nee invullen. Je moet het altijd interessant maken, maar daar is de telefoon niet per se voor nodig Leerlingen kennen deze context heel goed. Daarnaast werkt het motiverend dat ze makkelijk aan anderen kunnen laten zien wat hebben gemaakt. Apps zijn over het algemeen niet heel complex, het is dus enigszins mogelijk om op het niveau te komen van veel bestaande apps. Dit in tegenstelling tot veel 'gewone' applicaties. Smartphones vinden de lln zeker interessant 16. Heeft u leerlingen die (buiten de lessen) bezig zijn met het ontwikkelen van mobiele applicaties? 40

44 Ja 2 40% Nee 2 40% Toelichting (wat doen en gebruiken deze leerlingen?) Nvt Leerlingen uit V6 hebben een app gemaakt voor onze open dag. Ze gebruiken de SDK van Android en de omgeving van Apple (iphone). Een leerling uit V2 heeft een app gemaakt met de roosterwijzingen, voor Android, mbv de AppInventor van MIT/Google. Hij gaat ook een app maken voor een conferentie die we organiseren. In 4havo ontwikkelen ze mobiele applicaties met behulp van Google App Inventor Tot slot 17. Zou u nog iets wijzigen aan deze vragenlijst voordat we deze doorsturen naar de docenten? met persoonlijk interview kom je waarschijnlijk meer informatie te weten zodanig maken dat vragen over het programmeeronderwijs voor mensen die geen les geven (zoals ik) niet zichtbaar worden. Suggestie: neem iets meer vragen op over iemands visie op het programmeeronderwijs: wat, waarom, hoe? Nee Misschien zou het goed zijn om te vragen naar de lessen bij programmeren. Moeten leerlingen veel zelf uitzoeken, of is er ook veel klassikaal les. Daarnaast is het denk ik interessant om te achterhalen wat redenen voor docenten zijn om iets wel of niet te doen. Bijvoorbeeld bij apps kan ik me voorstel... Aantal dagelijkse reacties 41

45 A.2. Oriënterende enquête naar relevante aspecten van programmeeronderwijs en lesmateriaal: docenten Oriënterende vragenlijst Programmeeronderwijs Geachte heer/mevrouw, Wij doen voor ons afstuderen aan de Eindhoven School of Education een onderzoek naar programmeeronderwijs. Daarom zoeken wij informaticadocenten om een vragenlijst aan voor te leggen over dit onderwerp. We hopen dat u mee wilt werken aan ons onderzoek. In de onderstaande vragenlijst vragen wij u naar uw mening over programmeertalen en daarmee verband houdende onderwijsmethoden waar u ervaring mee hebt. Het doel van ons onderzoek is een programmeermodule ontwikkelen die aanspreekt bij middelbare scholieren en die bovendien de leerling op een effectieve manier leert programmeren. Uw antwoorden worden vertrouwelijk behandeld en de resultaten van de vragenlijsten die wij in onze rapportage opnemen worden geanonimiseerd. Het invullen van de complete vragenlijst neemt ongeveer 15 minuten in beslag. * Required Algemeen 1. In welke leeftijdscategorie valt u?* jonger dan 30 jaar jaar jaar 50 jaar of ouder 2. Wat is de hoogste opleiding die u genoten heeft?* HBO Informatica WO Informatica HBO anders WO anders 3. Hoe lang geeft u het vak Informatica in het middelbaar onderwijs?* minder dan 2 jaar 2 tot 5 jaar 5 tot 10 jaar meer dan 10 jaar ik geef geen Informatica in het middelbaar onderwijs 42

46 4. Welke methode gebruikt u voor uw informatica onderwijs?* Fundament Informatica (Instruct) Enigma (voorheen Turing) Informatica Actief (voorheen Edu Actief) Eigen lesmethode ik geef geen Informatica in het middelbaar onderwijs Other: 5. Wat is de gemiddelde klasgrootte waaraan u les geeft?* minder dan 10 leerlingen 10 tot 20 leerlingen 20 tot 30 leerlingen meer dan 30 leerlingen ik geef geen Informatica in het middelbaar onderwijs Informatica curriculum 6. Is programmeren noodzakelijk in het informatica curriculum?* Ja Nee Toelichting: 7. Is alleen visueel programmeren voldoende in het Informatica curriculum?* Ja Nee Toelichting: Programmeermethoden 8. Welke programmeertalen en bijbehorende lesmethoden gebruikt u in het middelbaar onderwijs?* 9. Wat vindt u de sterke en zwakke punten van deze talen en methoden?* 10. Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? Gelieve uw antwoord toe te lichten.* 11. Hoe vindt u de motiverende werking van de deze talen en methoden?* 12. Hoe toetst u de leerlingen met betrekking tot deze talen en methoden en waarom hebt deze manier van toetsen gekozen?* 13. Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren?* 14. Brengt u een relatie aan tussen de diverse talen en methoden die u gebruikt?* 43

47 Context 15. Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren?* niet Toelichting* wel 16. Heeft u leerlingen die (buiten de lessen) bezig zijn met het ontwikkelen van mobiele applicaties?* Ja Nee Toelichting (wat doen en gebruiken deze leerlingen?) Tot slot Zou u willen meewerken aan het vervolg van ons onderzoek? U krijgt dan het door ons ontwikkelde materiaal en wellicht willen we u nog kort interviewen. Zo ja, vul dan hieronder uw adres in. Ons onderzoek behelst het maken van lesmateriaal. We willen dit graag aan u voorleggen. 44

48 8 reacties Overzicht Complete reacties bekijken Algemeen 1. In welke leeftijdscategorie valt u? jonger dan 30 jaar 0 0% jaar 2 25% jaar 3 38% 50 jaar of ouder 3 38% 2. Wat is de hoogste opleiding die u genoten heeft? HBO Informatica 1 13% WO Informatica 3 38% HBO anders 2 25% WO anders 2 25% 3. Hoe lang geeft u het vak Informatica in het middelbaar onderwijs? minder dan 2 jaar 2 25% 2 tot 5 jaar 2 25% 5 tot 10 jaar 2 25% meer dan 10 jaar 1 13% ik geef geen Informatica in het middelbaar onderwijs 1 13% 4. Welke methode gebruikt u voor uw informatica onderwijs? Fundament Informatica (Instruct) 3 38% Enigma (voorheen Turing) 1 13% Informatica Actief (voorheen Edu Actief) 0 0% Eigen lesmethode 2 25% ik geef geen Informatica in het middelbaar onderwijs 1 13% Other 1 13% 5. Wat is de gemiddelde klasgrootte waaraan u les geeft? minder dan 10 leerlingen 0 0% 10 tot 20 leerlingen 2 25% 20 tot 30 leerlingen 5 63% meer dan 30 leerlingen 0 0% ik geef geen Informatica in het middelbaar onderwijs 1 13% 45

49 Informatica curriculum 6. Is programmeren noodzakelijk in het informatica curriculum? Ja 8 100% Nee 0 0% Toelichting: Programmeren is wat mij betreft een kerncompetentie binnen het vakgebied. communiceren van de informatiebehoefte via UML en het implementeren van Informatie Systemen is voor mij minstens zo belangrijk. Het is een onmisbaar onderdeel maar mag m.i. niet de boventoon voeren. Het kunnen analyseren en Informatica in het VO is mijns inziens vooral bedoeld om leerlingen enthousiast te maken voor een vervolgstudie in de ICT of aan de ICT gerelateerde vakgebieden. Daar hoort dus zeker ook programmeren bij. Daarnaast zorgt het voor een goede kennismaking met de hedendaagse programmeertechnieken en talen Is alleen visueel programmeren voldoende in het Informatica curriculum? Ja 0 0% Nee 8 100% Toelichting: Als opstap prima, maar niet toereikend. begrip krijgen van de mechanismen zoals variabelen en program flow (loop's e.d.) inzicht in het ontwikkelen van verschillende oplossingsrichtingen. in syntax bij de diverse talen), inspringen, editors etc. vor... Zolang de pro's ook nog geregeld code aan het kloppen zijn is het van groot belang dat informatica leerlingen op een zo 'laag' mogelijk niveau Een stuk basiskennis om inzicht te krijgen hoe dingen werken, geeft voor een programmeur meer Er belangrijk bij programmeren is gestructureerd werken. Zaken als hoe je een code opbouwt, syntax (en verschillen Programmeermethoden 8. Welke programmeertalen en bijbehorende lesmethoden gebruikt u in het middelbaar onderwijs? Java JavaScript / PHP (Havo) JavaScript / VBA / Java (VWO) Alleen voor JavaScript wordt gebruik gemaakt van een door anderen ontwikkelde cursus (autheurs onbekend). Overige programmeertalen: zelf ontwikkeld materiaal. Robotbasic (Html) & php Psd's (heb ik juist dit jaar overgeslagen ten gunste van robotbasic momenteel -XHTML & CSS -PHP & MySQL -met als einddoel meer te kunnen doen met een standaard CMS zoals DRUPAL Dit wil ik verder gaan uitbreiden zodra ik zelf de programmeertalen voldoende beheers. van Gertjan Laan, Instruct PHP, lesmateriaal van Enigma html(5) met css(3) java... BlueJ, boekje 9. Wat vindt u de sterke en zwakke punten van deze talen en methoden? Jcreator is te moeilijk voor scholieren. Ze gebruiken eclipse en kopiëren de programma's om ze te wijzigen. Dat gaat goed. Nog onvoldoende uitontwikkeld Te weinig referentie voor gefundeerd antwoord Voor XHTML & CSS geeft het een sterke basis om in andere vervolgopleidingen de opgedane kennis en vaardigheden te kunnen blijven toepassen. Deze respons krijg ik regelmatig van oud-leerlingen en zij kunnen zich dan met hun producten positief onderscheiden van studiegenoten die geen informatica hebben gevolgd. Voor PHP & MySQL is het puur om het feit dat het toegankelijk is voor iedereen en een e Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? Gelieve uw antwoord toe te lichten. Redelijk, al valt het resultaat vaak tegen. Ze willen mooiere dingen maken. Moet nog blijken (dit jaar is de eerste lichting waarmee ik het nieuwe programma doorloop) Bij Robotbasic moeten de leerlingen een relatief stijle leercurve nemen tov psd's. Het resultaat wat ze bereikten na een les of was echter toch erg indrukwekkend te noemen. Dit wisseld enorm omdat er ook leerlingen zijn die studieprofielen zonder exacte vakken hebben. Zij hebben er beduidend meer moeite mee maar hebben meestal andere goede vaardigheden om in een projectgroep toch samen tot een goed resultaat te komen. BlueJ: Hoe vindt u de motiverende werking van de deze talen en methoden? Minimaal. Heeft wel een leuk effect... Ik merk dat de leerlingen behoorlijk geconcentreerd zitten te werken! robotbasic ondersteund alle in en uitvoer methodes. Knoppen, toetsenbord en muis etc... leerlingen die willen kunnen goed uit de voeten met de help en ze motiveren elkaar. Gevorderde leerlingen komen tegen problemen aan waarbij array's en procedure's lokale en globale variabelen een goede oplossing zijn... op een natuurlijke manier ontstaat dan de behoefte aan een betere programmeertaal. de totale inhoud van het vak informatica. Wanneer dit Nu omvat het feitelijke programmeren 20% van 46

50 12. Hoe toetst u de leerlingen met betrekking tot deze talen en methoden en waarom hebt deze manier van toetsen gekozen? Po. Omdat ze daarmee kunnen laten zien wat ze kunnen. Individuele Praktische Opdrachten. Gedeeltelijk schriftelijk na enkele weken. Dit om basale dingen te toetsen. Vervolgens met een praktische opdracht. Korte individuele opdrachten (PO's) en grote opdrachten in groepsverband, gekoppeld aan een mondeling tentamen waarbij 'hands-on' toelichting moet worden gegeven over de gekozen strategie/oplossing en het kunnen aangeven/demonstreren van alternatieve oplossingen. theoretische tussentoets, aan het eind van de periode eenpraktische Opdracht. Tussentoets om ervoor te zor... Halverwege de periode een 13. Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren? De basis. Beginsel van denkproces dat nodig is om software te ontwikkelen. Computers denken anders, vereisen andere insteek. Dat wi ik bijbrengen. Concepten van programmeertalen. Tijdens de PO mag gebruik worden gemaakt van al het materiaal waar de leerlingen over beschikken. Ze hoeven niet de specifieke statements uit hun hoofd te kennen. Op het VWO wordt ook (enige) aandacht besteed aan complexiteit: slimme en minder slimme oplossingen. variabelen, if for while loops... basale in en uitvoer De gemeenschappelijke onderdelen die terugkomen... Gebruik variabelen, verschil toekenning en evaluatie 14. Brengt u een relatie aan tussen de diverse talen en methoden die u gebruikt? Zoveel mogelijk. Of de leerstof herhaal ik bij het po onderwerp. Nee. Op het VWO wordt het programmeren in Java vooraf gegaan door een module Object Oriëntatie. Nog niet.. Ik probeer altijd de generieke elementen te benadrukken zodat de specifieke taal ondergeschikt is aan de methoden nee, wel komt BlueJ, na een introductie in de 4e klas, terug in de 5e klas en bij PHP (5e klas) bouw je voort op voorkennis HTML en databases uit de 4e klas. Het zijn steeds stapjes naar steeds volwaardiger websites. Bedoeling is dat het wor... Ja. De talen kennen een logisch vervolg. Van html via javascript naar php. Context 15. Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren? 1 - niet 0 0% 2 0 0% % % 5 - wel 5 63% niet wel Toelichting Mobiel is geïntegreerd in het leven van leerling. Denk dat onderwijs meer aansluiting moet vinden bij beleving van leerlingen. Mogelijk gaan wij dit combineren met het programmeren van LegoRobots (MindStorms). In mijn groepen nog geen ervaring mee Als platform voor het eindgebruik van hun product wel! Een app maken die ze dagelijks kunnen gebruiken of juist ook bruikbaar is voor medeleerlingen die geen informatica volgen, heeft volgens mij een sterk onderscheidend en motiverend effect. Ik wil hier in de toekomst ook naar toe om het maken van app's in mijn PTA op te nemen ja, voor sommigen vast Heeft u leerlingen die (buiten de lessen) bezig zijn met het ontwikkelen van mobiele applicaties? Ja 3 38% Nee 5 63% Toelichting (wat doen en gebruiken deze leerlingen?) Java, ontwikkelen apps, html, andere talen. Een 6e klasser (technisch geen leerling van mij) heeft een rooster kijk applicatie ontwikkeld Nog niet. 1 leerling, heeft een app op z'n Android smartphone gebouwd Voor het nieuwe schooljaar hebben zich een aantal leerlingen aangemeld die, in de vorm van een profielwerkstuk, een app willen maken. Ik hèb dus geen leerlingen... Tot slot Zou u willen meewerken aan het vervolg van ons onderzoek? U krijgt dan het door ons ontwikkelde materiaal en wellicht willen we u nog kort interviewen. Zoja, vul dan hieronder uw adres in. joko@vandeningh.nl jacco.gnodde@gmail.com hamoen.p@lcl.nl wtt.informatica@gmail.com nij@guido.nl remie.woudt@gmail.com post@meneergroeneveld.nl huubmetz@onsnet.nu Aantal dagelijkse reacties 47

51 48

52 A.3. Enquête over motiverende contexten bij programmeren Je helpt ons enorm met ons onderzoek als je de onderstaande twee vragen serieus en eerlijk beantwoordt. Denk niet te lang na over elk onderwerp, maar ga af op je gevoel. Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: websites maken robotica apps voor mobieltjes games maken kunstmatige intelligentie databases huisautomatisering (domotica) apps voor pc graphics informatiesysteem automotive simulaties helemaal niet leuk niet leuk leuk heel leuk Mis je hierboven nog een onderwerp dat je leuk vindt? 49

53 59 reacties Overzicht Complete reacties bekijken Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - websites maken helemaal niet leuk 0 0% niet leuk 5 8% leuk 44 75% heel leuk 10 17% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - robotica helemaal niet leuk 7 12% niet leuk 17 29% leuk 21 36% heel leuk 14 24% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - apps voor mobieltjes helemaal niet leuk 0 0% niet leuk 8 14% leuk 29 49% heel leuk 22 37% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - games 50

54 maken helemaal niet leuk 2 3% niet leuk 5 8% leuk 19 32% heel leuk 33 56% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - kunstmatige intelligentie helemaal niet leuk 14 24% niet leuk 18 31% leuk 16 27% heel leuk 11 19% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - databases helemaal niet leuk 17 29% niet leuk 25 42% leuk 17 29% heel leuk 0 0% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - huisautomatisering (domotica) helemaal niet leuk 17 29% niet leuk 18 31% leuk 21 36% heel leuk 3 5% 51

55 Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - apps voor pc helemaal niet leuk 6 10% niet leuk 13 22% leuk 28 47% heel leuk 12 20% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - graphics helemaal niet leuk 10 17% niet leuk 14 24% leuk 23 39% heel leuk 12 20% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - informatiesysteem helemaal niet leuk 20 34% niet leuk 30 51% leuk 8 14% heel leuk 1 2% 52

56 Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - automotive helemaal niet leuk 14 24% niet leuk 16 27% leuk 22 37% heel leuk 7 12% Geef van de volgende (programmeer-) onderwerpen aan in hoeverre je ze leuk vindt: - simulaties helemaal niet leuk 7 12% niet leuk 11 19% leuk 34 58% heel leuk 7 12% Mis je hierboven nog een onderwerp dat je leuk vindt? - Nieuwe technieken "bespreken" (bv. less, coffeescript, etc.). - RoR Biometrie en computercriminaliteit. nee Neen Nee Nee Games spelen Neen Neen hacken hacken hacken Flash zou wel leuk zijn. Nope Films bewerken met After Effects of met (lego NXT werken een robot programmeren, net als bij de lego league) nee nee nee Aantal dagelijkse reacties 53

57 A.4. Vragenlijst evaluatie ontwikkelde lesmateriaal Deze vragenlijst is als leidraad gebruikt bij het interviewen nadat docenten het materiaal zelf bekeken en (deels) doorgewerkt hadden. We hebben daarbij de vraagstelling zo open mogelijk gehouden, de docent zoveel mogelijk laten aangeven wat hij/zij ervan vond, tussendoor en achteraf steeds de vragenlijst als een checklist erbij gehouden of alle onderdelen wel ter sprake waren geweest. 1. Wat vindt u van het idee om App Inventor te gebruiken voor het leren programmeren in het voortgezet onderwijs? 2. Het leerlingenmateriaal (bij elke vraag hoort ook de "waarom" vraag): a. Wat vindt u van de lay-out van het lesmateriaal? b. Wat vindt u van het gebruik van figuren in het lesmaterialen? c. Wat vindt u van de duidelijkheid van het lesmateriaal? d. Wat vindt u van de opbouw/volgorde van het lesmateriaal? e. Wat vindt u van de opbouw/volgorde binnen een onderwerp zoals bijvoorbeeld Meteoor? f. Vindt u het lesmateriaal qua moeilijkheid geschikt voor de doelgroep (4 HAVO/VWO), te moeilijk of te makkelijk? g. Wat zou u zeker willen houden in het lesmateriaal? h. Wat zou u veranderen aan het lesmateriaal? i. Wat zou u nog toevoegen aan het lesmateriaal? 3. De docentenhandleiding (bij elke vraag hoort ook de "waarom" vraag): a. Wat vindt u van de duidelijkheid van de docentenhandleiding? b. Wat vindt u van de opbouw/volgorde van de docentenhandleiding? c. Wat vindt u van de bruikbaarheid van de docentenhandleiding? d. Wat zou u veranderen aan de docentenhandleiding? e. Wat zou u nog toevoegen aan de docentenhandleiding? 4. Wat is uw mening over de motiverende werking van het concept en het materiaal? 5. Wat is uw mening over de effectiviteit van het concept en het materiaal om leerlingen in het voortgezet onderwijs te leren programmeren en voor te bereiden op tekstueel programmeren? 6. Zou u het materiaal als het af is willen gebruiken op uw school? 7. Welk cijfer tussen de 1 en 10 zou u aan het materiaal geven op dit moment? 8. Hebt u nog andere opmerkingen, uitbreidingen, aanvulling, wensen ten aanzien van het materiaal? 54

58 B. Resultaten en conclusies uit enquêtes B.1. Resultaten en conclusies van de oriënterende enquêtes In deze paragraaf beschrijven we de resultaten en conclusies die voortkomen uit de vragenlijsten in bijlagen A.1. en A.2. We hebben eerst een aantal vakdidactici informatica gevraagd een vragenlijst (bijlage A.1.) in te vullen. Op het einde werd gevraagd of ze deze lijst ook geschikt vonden voor docenten. Aan de hand van hun commentaar hebben we een iets aangepaste vragenlijst (bijlage A.2.) gemaakt en naar docenten gestuurd. Aangezien deze vragenlijst in essentie niet veel afwijkt hebben we de antwoorden bekeken en aangezien ook deze vergelijkbaar zijn hebben we besloten de antwoorden van didactici en docenten verder samen te verwerken. Deze bijlage is daar de weerslag van. Merk op dat hoewel het nummer van sommige vragen afwijkt tussen de twee enquêtes dit geen invloed heeft op de conclusies die we er uit trekken. Op vraag 6 (Is programmeren noodzakelijk in het informatica curriculum?) wordt door alle vakdidactici en docenten bevestigend geantwoord. De toelichting varieert van Niet te veel, maar zoveel dat het hele ontwerp/ontwikkeltraject een keer doorlopen wordt tot Het is een belangrijk onderdeel van informatica, daarnaast ook een leuk, praktisch onderdeel. Er wordt opgemerkt dat programmeren een kerncompetentie in het vakgebied is. Iemand merkt op dat het een onmisbaar onderdeel is maar niet de boventoon mag voeren (andere belangrijke onderdelen volgens deze respondent: kunnen analyseren en communiceren van informatiebehoefte via UML en implementatie van Informatie Systemen). Tot slot wordt door iemand opgemerkt dat informatica vooral bedoeld is om leerlingen enthousiast te maken voor een vervolgstudie in de ICT en aanverwante, aldus deze respondent. Op vraag 7 (Is alleen visueel programmeren voldoende in het informatica curriculum?) wordt overwegend negatief gereageerd: 10 nee, 2 ja. Hierop afgaand is het dus verstandig om behalve een module over visueel programmeren ook een module over niet-visueel programmeren te gebruiken. Zoals in het onderzoeksplan al staat wordt door visueel programmeren de initiële kennismaking met programmeren eenvoudiger omdat de student niet direct compiler meldingen voor zijn neus krijgt: De blokjes waarmee App Inventor werkt om taal-constructies te representeren passen alleen in elkaar als de bijbehorende taal-constructies op die wijze gecombineerd kunnen worden. Het ligt dan ook voor de hand met de visuele module te beginnen. Eén van de respondenten: Als opstap prima, maar niet toereikend. Daarna is het dus volgens het merendeel van onze respondenten nodig nog een module niet-visueel (tekstueel) programmeren te doorlopen. Enkele toelichtingen van deze respondenten: je moet door de ervaring van syntax error, puntkomma vergeten heen. Een andere respondent: belangrijk bij programmeren is gestructureerd werken. Zaken als hoe je code opbouwt, syntax (en verschillen in syntax bij de diverse talen), inspringen, editors etc. vormen een belangrijk onderdeel van het programmeren., Zolang de pro's ook nog geregeld code aan het kloppen zijn is het van groot belang dat informatica leerlingen op een zo 'laag' mogelijk niveau begrip krijgen van de mechanismen zoals variabelen en program flow (loop's e.d.), Een stuk basiskennis om 55

59 inzicht te krijgen hoe dingen werken, geeft voor een programmeur meer inzicht in het ontwikkelen van verschillende oplossingsrichtingen.. Bij met name de laatsten wordt de nadruk gelegd op voorbereiding op studie en werk in de richting van ICT. De niet-visuele module valt overigens buiten de scope van ons onderzoek. Vraag 8 en 9 gaan over de door de respondenten gebruikte programmeertalen en lesmethoden. We beginnen met een opsomming van talen/omgevingen. Erbij staan meteen de voor ons relevante opmerkingen die de respondenten hebben gemaakt, met een labeltje nadeel/voordeel. Waar nodig hebben we de opmerking vertaald naar onze situatie of algemener gemaakt. Er zijn hierbij een aantal gevallen te onderscheiden: het kan zijn dat een genoemd voordeel ook van toepassing is op App Inventor, het kan zijn dat een genoemd nadeel van een andere omgeving/taal niet van toepassing is op App Inventor, het kan zijn dat een genoemd nadeel ook van toepassing is op App Inventor, het kan zijn dat een voordeel van een andere omgeving niet van toepassing is op App Inventor, het kan zijn dat een genoemd voordeel van een andere omgeving te vertalen is naar een nadeel van App Inventor en er zijn nog andere gevallen te bedenken. GameMaker / GML (GameMakerLanguage) nadeel: er zijn weinig opdrachten te vinden die specifieke onderdelen testen/oefenen (vgl. wiskunde). nadeel: de bijbehorende taal is specifiek GameMaker. Relevantie: App Inventor heeft geen bijbehorende taal, dus dit nadeel gaat niet op voor App Inventor. voordeel: het is voor de leerlingen erg motiverend. (Waarom staat er helaas niet bij, maar afgaande op wat deze respondent verder zegt lijkt dit te liggen in de hoek: snel starten, eenvoud, spellen maken is motiverend. Relevantie: Deze redenen gelden ook voor App Inventor. ) voordeel: er is redelijk wat lesmateriaal. Ook voor App Inventor is veel materiaal verkrijgbaar. Een docent geeft aan dat hij GML gebruikt om onderscheid te maken tussen 5 havo (mag alles visueel programmeren) en 6 vwo (moet ergens GML code gebruiken). Relevantie: Hoewel dit niet direct te vertalen is naar een voor-/nadeel voor het gebruik van App Inventor blijk hier wel uit dat de docent het visueel programmeren als makkelijker voor leerlingen beschouwt. Java Jcreator is te moeilijk voor scholieren. Ze gebruiken Eclipse en kopiëren de programma's om ze te wijzigen. Dat gaat goed. Java/Greenfoot nadeel: object georiënteerd kan soms moeilijk zijn. Relevantie: dit nadeel heeft App Inventor niet. nadeel: De methode biedt geen (extra) opdrachten aan aan de hand waarvan de leerlingen kunnen oefenen. Relevantie: het is belangrijk dat er veel extra opdrachten zijn. 56

60 nadeel: De methode (aanschaf van het boek) is relatief duur. Relevantie: App Inventor is gratis, kan gebruikt worden met een emulator. Echter, een Android phone kost natuurlijk wel geld. Voor de motiverende werking die wij verwachten van de mobiel is een mobiel wel vereist. voordeel: leerlingen leren OO programmeren. Relevantie: in App Inventor programmeer je niet OO. Wij beschouwen onze module echter voor een eerste introductie in programmeren en denken dat OO hiervoor een brug te ver is. voordeel: het maken van games in Greenfoot werkt erg stimulerend. Relevantie: het bouwen van games (in een omgeving die daarvoor geschikt is) werkt erg stimulerend. De methode legt nadruk op OO termen. Relevantie: Het feit dat een leerling in App Inventor niet met OO-termen hoeft te werken zien wij (voor het alleereerste programmeeronderwijs) als een voordeel. JavaLogo (Applet) nadeel: de resultaten blijven vrij simpel, leerlingen raken daardoor redelijk snel verveeld. nadeel: Het legt veel nadruk op ruimtelijk inzicht, leerlingen die daar moeite mee hebben, hebben ook met deze manier van programmeren moeite. voordeel: Je kunt snel starten. De omgeving is simpel, er zijn slechts een paar basismogelijkheden. Het kan daarom goed worden gebruikt als inleiding op programmeren en algoritmes. JavaScript: een door anderen ontwikkelde cursus (auteurs onbekend) NetLogo geschikt voor AI modellen. Python voordeel: kleine en krachtige taal, minder details dan Java. Relevantie: App Inventor gebruikt ook een kleine taal. PHP (& MySQL) nadeel: indirectie omdat het op een server draait. Hiermee wordt bedoeld dat het voor de leerlingen niet duidelijk is welke activiteiten op de server draaien en welke op de client. Relevantie: Hoewel (de ontwikkelomgeving voor) App Inventor via een web browser draait geldt dit nadeel hier niet. nadeel: integratie met HTML maakt het moeilijk. Relevantie: App Inventor heeft dit nadeel niet. nadeel: Veel syntax. Relevantie: App Inventor heeft dit nadeel niet. voordeel: Leerlingen maken interactieve websites, dat maakt het boeiend voor leerlingen. Relevantie: (algemeen, zodat het toepasbaar is voor ons): leerlingen maken een bruikbaar, interactief product, dat maakt het boeiend voor leerlingen. voordeel: Kan met standaard, gratis tools. voordeel: Je kunt makkelijk beginnen met simpele voorbeelden. puur om het feit dat het toegankelijk is voor iedereen en een extra dimensie geeft aan de statische programmeertalen. Leerlingen kunnen er gemakkelijk thuis mee verder zonder extra voorzieningen te treffen. PSD's (heb ik juist dit jaar overgeslagen ten gunste van RobotBasic). 57

61 RobotBasic Nadeel: slechte editor, ongevoelig voor hoofdletters/kleine letters. Relevantie: Dit nadeel heeft App Inventor niet. Struktograaf nadeel: niet fancy. Relevantie: Apps maken voor je mobiel is wel fancy. nadeel: de blokjes suggereren een structuur, maar dat is slechts schijn. Relevantie: voordeel: De blokjes suggereren een structuur en die wordt ook afgedwongen: de taalconstructies passen dan en slechts dan bij elkaar als de blokjes bij elkaar passen. SQL voordeel: sluit goed aan bij het relationele model. Relevantie: Bij voorkeur sluit een taal goed aan bij het doel. App Inventor sluit goed aan bij het doel (Zelf eenvoudig apps kunnen maken voor je mobiel) XHTML & CSS: het geeft een sterke basis om in andere vervolgopleidingen de opgedane kennis en vaardigheden te kunnen blijven toepassen. Deze respons krijg ik regelmatig van oud-leerlingen en zij kunnen zich dan met hun producten positief onderscheiden van studiegenoten die geen informatica hebben gevolgd. Over de programmeertalen en lesmethoden: Eigen materiaal. Javascript: eigen materiaal. Sterk punt: het gebruik kan dicht bij de belevingswereld van de leerlingen liggen. Zwak punt is het vrijwel ontbreken van goede debuggers. PHP (met MySQL): Sterk punt: het gebruik kan dicht bij de belevingswereld van de leerlingen liggen. Zwak punt is het vrijwel ontbreken van goede debuggers. Geen methode Losse tutorials van internet ThinkPython van de site wiki.ubuntu-nl.org BlueJ, boekje van Gertjan Laan, Instruct. Goed opgebouwd, maar voor havo-leerlingen toch best pittig Enigma (commentaar met name over het deel over PHP). Begin is duidelijk (wel voorkennis HTML nodig, maar dat zouden leerlingen moeten hebben), paragraaf over PHP en databases zou duidelijker kunnen. Informatica-actief Greenfoot (welke lesmethode hier bedoeld wordt staat er niet bij vermeld) / Java Sterk punt: het gebruik kan dicht bij de belevingswereld van de leerlingen liggen. Zwak punt is het vrijwel ontbreken van goede debuggers. 58

62 Vraag 10. Zijn leerlingen met deze talen en methoden snel in staat om een (voor hun) leuk resultaat te behalen? In deze vraag komen effectiviteit ( snel ) en motivatie ( een (voor hun) leuk resultaat ) bij elkaar. Uit de antwoorden gedestilleerd: Robotbasic: ok PHP: ok (voor mensen die het door hebben) / matig GameMaker: ja GML: voor snel/leuk toch vooral het visuele deel van GameMaker Greenfoot: ja JavaLogo: matig Python: vooral turtle & GvRng SQL: motiverend door (meestal) succeservaring NetLogo: Enigma geeft aansprekende AI-modellen (los van taal/omgeving): Resultaten blijven lastig. Je moet je vaak beperken tot toy-problems. En dat is niet altijd interessant. We moeten opletten met het trekken van conclusies uit antwoorden als ja en ok, aangezien ze van verschillende respondenten af komen, maar toch kunnen we voorzichtig wel conclusies uit deze vraag trekken. Blijkbaar is het niet triviaal dat een gebruikte taal/omgeving de studenten snel in staat stelt een leuk resultaat te bouwen. Wij vinden het voor de motivatie echter belangrijk dat leerlingen met ons lesmateriaal snel succeservaringen opdoen. Deze ervaring wordt nog eens vergroot doordat de mensen met een Android mobiel hun resultaten altijd bij zich hebben en dus makkelijk aan vrienden en familie kunnen laten zien. Vraag 12. Hoe toetst u de leerlingen met betrekking tot deze talen en methoden en waarom hebt deze manier van toetsen gekozen? De meeste docenten geven aan dat ze in ieder geval ook individueel controleren of leerlingen het snappen. Dit gebeurt door middel van een toets of individuele opdrachten. Hiervoor kunnen we wellicht voorzieningen treffen in ons lesmateriaal? "individuele toets op de PC, en prakticumopdracht (eventueel in duo's) gekozen omdat mijn voorganger het ook zo deed" Praktische opdrachten en een toets. De praktische opdrachten bestaan uit deelopdrachten, waarin een verplicht deel en een vrij deel in zit. Deze mogen in tweetallen worden gemaakt. De toets bestaat uit een theoretisch deel, waarin onder meer wordt gevraagd naar terminologie en begrip, alsook het lezen van code, en uit een praktisch deel, waarbij de leerlingen tijdens de toets een klein programma moeten maken. "(1) Python met een individuele praktische opdracht (PO) en een theorietoets, in zowel het voorexamenjaar als het examenjaar (2) Met een PO (3) Met een PO (4) Het uiteindelijke spel wordt door de klant en de manager (dat ben ik) beoordeeld" PO. Omdat ze daarmee kunnen laten zien wat ze kunnen. Individuele Praktische Opdrachten. Gedeeltelijk schriftelijk na enkele weken. Dit om basale dingen te toetsen. Vervolgens met een praktische opdracht. 59

63 Korte individuele opdrachten (PO's) en grote opdrachten in groepsverband, gekoppeld aan een mondeling tentamen waarbij 'hands-on' toelichting moet worden gegeven over de gekozen strategie/oplossing en het kunnen aangeven/demonstreren van alternatieve oplossingen. Halverwege de periode een theoretische tussentoets, aan het eind van de periode een Praktische Opdracht. Tussentoets om ervoor te zorgen dat leerlingen vanaf het begin aan het werk gaan, en om ze te dwingen 'na te denken' en niet alleen alle voorbeelden na te bouwen. PO: mooie manier om te testen wat ze nu echt zelf kunnen bouwen. Meestal in de vorm van praktische opdrachten in groepsverband. Maar ook wel korte stukjes in de schoolexamens om hen individueel te kunnen beoordelen. Vraag 13. Wat vindt u de belangrijkste aspecten die uw leerlingen van programmeren moeten leren? We hebben de Big Ideas van Saeli (Saeli, 2012) als uitgangspunt. We hebben deze bewust niet expliciet in de vraag genoemd om de vraag zo open mogelijk te houden. Bovendien waren we benieuwd of wellicht één van de didactici zelf met deze lijst zou komen aanzetten. Tot slot waren we benieuwd of de lijst van onderwerpen aangedragen door de respondenten enigszins overeenkwam met de onderwerpen van de Saeli-lijst. De volgende onderwerpen kwamen uit de enquêtes: voorop staat bij voorkeur het begrip dat naar onze mening de lading het beste dekt (de labels), daarna volgen eventueel andere omschrijvingen die door de respondenten werden gegeven, gescheiden door een slash: /. Ons eigen commentaar staat tussen rechte haken: [ en ]. 9x : computational thinking / (Beginsel van) denkproces dat nodig is om software te ontwikkelen. / de manier van oplossingsgericht denken en de wijze om dit naar anderen toe te ontsluiten / logisch nadenken / abstract denken / het denken in structuren, het ontleden van een probleem. / problemsolving / Oplossen van problemen/computers denken anders, vereisen andere insteek 8x : lussen / Programmaflow: Iteratie / Begrip van controle structuren / Controle-structuur herhaling / for while loops 5x : variabele / Gebruik variabelen, verschil toekenning en evaluatie variabelen 4x : datastructuren / Data-abstractie / enkele datatypen / datatypes 4x : methoden / Procedurele abstractie / decompositie met functies 2x : if / Controle-structuur keuze 2x : Programmaflow: Sequentie / Controle-structuur sequentie, 2x : OO begrippen zoals klassen, objecten, etc. / inzicht in klassenontwerp. 2x : Concepten van programmeertalen / structuur van programma's [Wat hier precies bedoeld is moeten we hier zelf bedenken: het ligt voor de hand dat het hier gaat om een combinatie van een aantal andere labels als variabelen / if / lussen / methoden] 2x : Programma-ontwerp / Natuurlijk moet het informatica-onderwijs vooral ruim aandacht besteden aan het voortraject (ontwerp). 2x : leesbaarheid: goede naamgeving van variabelen / goed gebruik van commentaar 60

64 1x : parameters [heeft te maken met variabelen en met methoden] 1x : basale in en uitvoer 1x : complexiteit: slimme en minder slimme oplossingen. 1x : Debug-vaardigheden Buiten beschouwing gelaten: Dat het leuk is! [helpt mooi bij motivatie, een van de aandachtspunten van ons onderzoek, maar is verder in dit rijtje een vreemde eend in de bijt...] Bouwstenen [want is te vaag: zou op Decompositie kunnen slaan, of op OO-begrippen, of op Concepten van programmeertalen]. Ze moeten minstens een keer goed proeven van wat het is om oplossingen te coderen. [moeilijk te categoriseren]. Nu sommen we de zeven (grootste) Big Ideas op (Saeli, 2012): Control structure, focus on Loops Data structures Decomposition Parameters Arrays Problem-solving skills Algorithms De Big Ideas Arrays en Algorithms komen niet direct in de feedback terug, de andere Big Ideas wel. Arrays komen echter ook bij datastructuren aan bod, wellicht dat ze daarom door de docenten niet apart genoemd zijn. Als je de categorie Algorithms breed ziet heeft dit te maken met het wel genoemde computational thinking en heeft het verder te maken met labels als methoden, OO-begrippen, programma-ontwerp en zeker ook complexiteit. Andersom komen de (minstens tweemaal) genoemde categorieën als volgt terug in de genoemde Big Ideas: Computational Thinking als Problem-solving skills. Lussen als Control structure, focus on loops. Variabelen komen niet als eigen Big Idea terug maar hebben te maken met Data structures, Parameters, Arrays en Algorithms. Datastructuren als data structures Methoden hoort bij Decomposition en is gerelateerd aan Parameters. If is een Control structure. Programmaflow: Sequentie hoort ook bij Control structure. OO begrippen kunnen aan bod komen bij Data structures, bij Decomposition, bij Problem-solving skills en bij Algorithms. Concepten van programmeertalen passen bij de Big Ideas Control structures, Data structures, Decomposition, Parameters en Arrays. Programma-ontwerp raakt aan Control structures, Data structures, Decomposition, Problem-solving skills en Algorithms. 61

65 Leesbaarheid is niet hard te koppelen aan Big Ideas, maar raakt ze allemaal, aangezien leesbaarheid te maken heeft met het gebruiken van de juiste constructies voor het juiste doel (Control structure, Data structure, Parameters, Arrays) en sterk afhangt van een helder Programma-ontwerp (zie vorige item, waar de overige Big Ideas naar voren komen) te maken heeft. Hoewel de lijst niet één-op-één overeenkomt komen we toch wel op een vergelijkbaar rijtje als de Big Seven van Saeli. Vraag 11. Hoe vindt u de motiverende werking van deze talen en methoden? De antwoorden: BlueJ: GML Omdat het voor sommige leerlingen moeilijk is, zijn ze moeilijk te motiveren (leerlingen blokkeren als ze niet weten hoe ze moeten beginnen). De leerlingen van vwo 6 zien dat ze met GML het ook voor elkaar krijgen, het hoeft niet perse visueel JAVA: minimaal PHP: Lastig te debuggen [dit is wel iets wat voor App Inventor geldt] Python Is een hele goede basistaal, die de leerlingen (pas) later weten te waarderen Robotbasic: Direct resultaat Ondersteunt alle in en uitvoer methodes. Knoppen, toetsenbord en muis etc... leerlingen die willen kunnen goed uit de voeten met de help en ze motiveren elkaar. Gevorderde leerlingen komen tegen problemen aan waarbij array's en procedure's lokale en globale variabelen een goede oplossing zijn... op een natuurlijke manier ontstaat dan de behoefte aan een betere programmeertaal. SQL Met SQL kunnen de databases worden geraadpleegd achter interactieve websites. Zie antwoord van vraag 10 en het inspringen van NetLogo kennen de leerlingen van Python. Opmerking: Het antwoord Idem als vorige vraag: GameMaker en Greenfoot werken erg motiverend, PHP deels ook, JavaLogo wat minder. laten we hier buiten beschouwing aangezien dit al eerder is opgenomen. Vraag 14: Brengt u een relatie aan tussen de diverse talen en methoden die u gebruikt? Zoveel mogelijk. Of de leerstof herhaal ik bij het PO onderwerp. Nee. Op het vwo wordt het programmeren in Java vooraf gegaan door een module Object Oriëntatie. Nog niet. 62

66 Ik probeer altijd de generieke elementen te benadrukken zodat de specifieke taal ondergeschikt is aan de methoden Nee, wel komt BlueJ, na een introductie in de 4e klas, terug in de 5e klas en bij PHP (5e klas) bouw je voort op voorkennis HTML en databases uit de 4e klas. Ja. De talen kennen een logisch vervolg. Van HTML via JavaScript naar PHP. Het zijn steeds stapjes naar steeds volwaardiger websites. Bedoeling is dat het wordt afgesloten met Ajax toepassingen waarbij zo mogelijk ook JSON e.d. aan de orde komt. Maar dit is nog in ontwikkeling. Java is vooral gekozen omdat dat de belangrijkste taal is voor het maken van apps voor Android. Dit geldt zeker nu ook televisies met Android op de markt gekomen zijn. Ook dit moet volgend schooljaar aan de orde komen. We zien geen mogelijkheid om hier relevante conclusies uit te kunnen trekken. Vraag 15. Denkt u dat het gebruik van mobiele telefoons als context/platform motiverend werkt voor het leren programmeren? De antwoorden van de didactici: nee : 1 neutraal: 1 ja : 2 Bij docenten werd de vraag net iets anders gesteld, namelijk met een schaal van 1 tot en met 5: 1: 0x (~nee) 2: 0x 3: 2x (~neutraal) 4: 1x 5: 4x (~ja) Door nee op 1 te projecteren, neutraal op 3 en ja op 5 krijgen we het volgende totaalplaatje: 1: 1x (~nee) 2: 0x 3: 3x (~neutraal) 4: 1x 5: 6x (~ja) Toelichtingen bij nee : de mobiele telefoon is teveel een 'black box' Toelichtingen bij neutraal : Je moet het altijd interessant maken, maar daar is de telefoon niet per se voor nodig. [Dit is geen antwoord op onze vraag. Door de omschrijving (met name: niet per se ) blijkt juist dat de persoon eigenlijk zelfs denkt dat mobieltjes motiverend werken (maar dat er ook nog andere motiverende factoren zijn), met andere woorden: eigenlijk dus een voorzichtige ja?]. In mijn groepen nog geen ervaring mee. Ja, voor sommigen vast wel, maar anderen zijn hier minder mee bezig. [dus het is 63

67 motiverende voor een deel van de klas, niet iedereen] Toelichtingen bij ja : Leerlingen kennen deze context heel goed. Daarnaast werkt het motiverend dat ze makkelijk aan anderen kunnen laten zien wat hebben gemaakt. Apps zijn over het algemeen niet heel complex, het is dus enigszins mogelijk om op het niveau te komen van veel bestaande apps. Dit in tegenstelling tot veel 'gewone' applicaties. Smartphones vinden de leerlingen zeker interessant Mobiel is geïntegreerd in het leven van leerlingen. Denk dat onderwijs meer aansluiting moet vinden bij beleving van leerlingen. Mogelijk gaan wij dit combineren met het programmeren van LegoRobots (MindStorms). Als platform voor het eindgebruik van hun product wel! Een app maken die ze dagelijks kunnen gebruiken of juist ook bruikbaar is voor medeleerlingen die geen informatica volgen, heeft volgens mij een sterk onderscheidend en motiverend effect. Ik wil hier in de toekomst ook naar toe om het maken van app's in mijn PTA op te nemen Ja. Het maken van een app ligt heel dicht bij de belevingswereld van de leerlingen. Conclusie: Het overgrote deel van de mensen denkt dus dat het motiverend werkt. Vraag 16. Heeft u leerlingen die (buiten de lessen) bezig zijn met het ontwikkelen van mobiele applicaties? 6x nee, 5x ja Er zijn dus best al wel leerlingen zelf mee bezig. Toelichting bij nee : Geen toelichting Een 6e klasser (technisch geen leerling van mij) heeft een rooster kijk applicatie ontwikkeld. [wat deze nee misschien wel maakt tot: een beetje ja ] Nog niet. [de verwachting is er dus wel dat het een keer gaat gebeuren]. Toelichting bij ja : Leerlingen uit V6 hebben een app gemaakt voor onze open dag. Ze gebruiken de SDK van Android en de omgeving van Apple (iphone). Een leerling uit V2 heeft een app gemaakt met de roosterwijzingen, voor Android, mbv de App Inventor van MIT/Google. Hij gaat ook een app maken voor een conferentie die we organiseren. In 4 havo ontwikkelen ze mobiele applicaties met behulp van Google App Inventor Java, ontwikkelen apps, html, andere talen. 1 leerling, heeft een app op z'n Android smartphone gebouwd Voor het nieuwe schooljaar hebben zich een aantal leerlingen aangemeld die, in de vorm van een profielwerkstuk, een app willen maken. 64

68 Nu zijn dit voornamelijk nog steeds apps die te maken hebben met school, maar interessant is hier of het in opdracht is van school? We kennen verschillende voorbeelden van leerlingen die web apps of phone apps voor roosters ontwikkeld hebben op eigen initiatief. Dit is dus wel degelijk eigen motivatie. Hier zou een toevoeging op de vraag handig zijn, achteraf gezien. B.2. Resultaten en conclusies van de enquête over motivatie bij programmeren Omdat docenten aangeven dat ze verwachten dat leerlingen het maken van apps voor een mobiele telefoon motiverend vinden maar het niet zeker weten is besloten een enquête te houden onder leerlingen die het vak informatica volgen. Hierbij hebben we ze voor twaalf mogelijke contexten waarin ze kunnen leren programmeren aan laten geven of ze deze wel of niet interessant vinden. We hebben gekozen voor een oneven schaal van vier zodat ze een kant moeten kiezen en niet neutraal mogen oordelen. Dit heeft tot de volgende resultaten geleid: helemaal niet leuk niet leuk leuk heel leuk som leuk websites maken 0% 8% 75% 17% 92% robotica 12% 29% 36% 24% 60% apps voor mobieltjes 0% 14% 49% 37% 86% games maken 3% 8% 32% 56% 88% kunstmatige intelligentie 24% 31% 27% 19% 46% databases 29% 42% 29% 0% 29% huisautomatisering (domotica) 29% 31% 36% 5% 41% apps voor pc 10% 22% 47% 20% 67% graphics 17% 24% 39% 20% 59% informatiesysteem 34% 51% 14% 2% 16% automotive 24% 27% 37% 12% 49% simulaties 12% 19% 58% 12% 70% Door afrondingen leveren sommige rijen een totaal van 99% of 101% op. Dit valt te verwaarlozen in het kader van ons onderzoek. De enquête is gehouden onder zowel havo als vwo leerlingen en zowel jongens als meisjes. 65

69 Websites maken, games maken en apps voor mobieltjes scoren significant hoger dan de rest in de som van de kolommen leuk en heel leuk (weergegeven in de meest rechtse kolom). Als we alleen naar de kolom heel leuk kijken springen games maken en apps voor mobieltjes er uit. Het aantal respondenten was 59 wat een kleine populatie is. Verder hebben we geen echte kwantitatieve analyse gedaan op de resultaten. We kunnen op basis van de uitkomsten geen harde conclusies trekken maar we worden gesterkt in onze aanname dat leerlingen het maken van apps voor een mobiele telefoon leuk vinden. B.3. Resultaten en conclusies van de lesmateriaal evaluaties Wie heeft er feedback gegeven? Op 7 juni 2012 hebben we, in het kader van een masterclass bij Fontys die gericht is op de bijscholing van informatica docenten, een workshop gehouden. Vóór de workshop hebben we de deelnemende docenten reeds het materiaal toegestuurd en ook tijdens de workshop was er voldoende tijd om zelf of in tweetallen met het materiaal aan de slag te gaan. Er waren in totaal zeven deelnemers aan de workshop. Om niet iedereen hetzelfde deel van het materiaal te laten bestuderen hebben we een aantal taken gedefinieerd. Twee deelnemers hebben gekeken naar het materiaal als geheel en de overige deelnemers hebben we verdeeld over de individuele onderdelen van het materiaal. Op het einde hebben we een plenaire feedback-sessie gehouden, losjes sturend aan de hand van de vragen zoals we die hadden opgesteld. Verder hebben we de vakdidactici en docenten die de oriënterende enquête hebben ingevuld om schriftelijke feedback gevraagd. Hierop heeft één persoon gereageerd. Tot slot hebben we nog een drietal informatica docenten geïnterviewd aan de hand van de vragenlijst uit bijlage A.4. De vragenlijst was hierbij een leidraad om alle onderwerpen aan bod te laten komen en geen keurslijf volgens welk het gesprek moest verlopen. Resultaten en conclusies masterclass Tijdens het analyseren van de resultaten zijn we tot de volgende labels gekomen: algemene indruk van het materiaal, doelgroep, opzet van het materiaal, motivatie, voorgestelde verbeteringen op het materiaal, voorgestelde aanvullingen op het materiaal, context (school en benodigde apparatuur), programmeer leerlijn en verdere suggesties. De opmerkingen die we graag mee willen nemen in ons lesmateriaal staan vermeld in het verslag in paragraaf

70 Hieronder hebben we de feedback die we gekregen hebben per label opgesomd: Algemene indruk Heel interessant. Heel leuk om te doen, duidelijk geschreven. Er was nog bijna niks in het Nederlands! Afhankelijk van de groep wil ik het materiaal wel gebruiken. Ja, ik wil het materiaal wel gebruiken maar hoe pas ik het in het grote geheel van het informatica vak? Lijkt me geweldig als module in de lerarenopleiding wiskunde. Goed bruikbaar. In huidige staat al toepasbaar. Ziet er goed en verzorgd uit. Uitgebreid genoeg voor een eerste inleiding in programmeren. Er is behoefte aan openbaar goed lesmateriaal. Breng het onder de aandacht bij VO-raad, InformaticaVO, i&i. Doelgroep Opzet Voor 4 havo/vwo wat heftig, nog te moeilijk. Mollenmeppen, te moeilijk? Havo met vmbo instroom is minder zelfstandig dan vereist voor het materiaal. Kun je oplossen door iets meer uit te leggen in het begin en minder onderzoekend te maken voor havo. Je kunt het nog aan veel jongere leerlingen geven als je hele eenvoudig apps gebruikt. Basis niveau zou voor iedereen haalbaar moeten zijn in 4 havo. Echte producten opleveren beter in later jaren. Install werkt goed. Eerst stoeien met iets bestaands, goede opzet. Eerste opdracht bij MollenMeppen heel goed. Standaard waarde van random in App Inventor is 1 tot 100 waardoor niet het hele scherm gebruikt wordt. Leerlingen gaan hiermee experimenteren en ontdekken dan zelf dingen. Dit geldt voor veel van de opdrachten, prima. Tempo van het materiaal is goed. De extra opdrachten zijn goed, die werken uitdagend, stop er nog meer in. Als je dingen meteen wiskunde maakt haken leerlingen af. Je moet ze eerst grijpen met de mobiel en daarna wiskunde er aan relateren. Motivatie Goed idee, lijkt mij dat het aanspreekt bij de leerlingen. Wel altijd de vraag of het echt motiveert als ze er echt mee aan de slag moeten. De ontwikkelomgeving is niet echt vernieuwend maar je kunt er wel dingen mee voor op je telefoon maken. Motiverend aan apps voor mobiele telefoons is dat je je telefoon eigenlijk altijd bij je 67

71 hebt dus je kunt je app overal laten zien. Aan vrienden, familie enzovoorts. Je moet op school een aantal extra telefoons hebben omdat je de ervaring van het runnen op de telefoon moet krijgen. Als je hier niet voor zorgt kan het leerlingen zonder telefoon demotiveren. Er zit geen scripting taal bij zoals bij GameMaker en Lego MindStorm. Raken bepaalde leerlingen er dan niet snel op uitgekeken? De ontwikkelomgeving is niet helemaal syntax error vrij. Je kunt dingen doen waarbij de omgeving foutmeldingen of een waarschuwing in een pop-up geeft. Het is laagdrempelig om aanpassingen te maken. Het ziet er speels uit dus nodigt uit om te experimenteren. Meer dan bij tekstueel programmeren. Makkelijk om synergie met andere vakken te creëren via opdrachten. Is een half jaar niet te lang? Gaan leerlingen zich dan niet vervelen? Verbeteringen Bij Mollenmeppen moeten ze op een gegeven moment geluid toevoegen. Deze stap is te groot. Veel leerlingen zullen niet beseffen dat ze in het verkeerde scherm zitten. Hier moet iets meer uitleg bij. Bij MollenMeppen is het toevoegen van een timer erg leuk om mee te stoeien. Alleen zullen ze op de havo niet precies weten waar ze de timer neer moeten zetten. vwo leerlingen komen hier wel uit. Voeg iets meer detail toe. Bij Schrandere Scholier is het niet meteen duidelijk wat een label is. Voeg bijvoorbeeld screenshots toe van gebruikte componenten. Bij Schrandere Scholier wordt Toets1Label gebruikt. Waarom niet Toets1Textbox (naamgeving is wellicht minder mooi, maar wel duidelijk voor de leerling). Bij Schrandere Scholier is het in elkaar zetten van het optel (+) block misschien te moeilijk voor leerlingen om dat zelf uit te vogelen. Het vinden waar en hoe je een variabele een nieuwe waarde geeft is niet triviaal om te vinden (my blocks -> my definitions -> set global var to). Laten zoeken naar geluid op internet kan leiden tot veel surf tijd. Misschien beter zelf een aantal geluiden geven waar ze uit mogen kiezen (kan in resource package). Installatie Unknown Sources duidelijk vermelden in de docentenhandleiding (en wellicht ook het leerlingenmateriaal). Een enkele keer raakt de sync tussen de blocks editor en design weg (een nieuw component staat dan niet in de blocks editor bij My Blocks). Oplossing is om de Blocks Editor te sluiten en opnieuw te starten. Waar is de Blocks Editor nadat ik in design modus ben geweest? Lastig omdat de blocks editor een Java icoon heeft en dus niet herkenbaar is. Bij Meteoor is het misschien beter om de wiskunde in een bijlage te zetten. Bij Meteoor een optionele opgave toevoegen om de besturing andersom te maken (boven en onder omdraaien. Geef aan wanneer je wilt dat leerlingen het materiaal volgen en wanneer ze zelf hun weg mogen zoeken. De aansluiting van de verschillende hoofdstukken is nog niet helemaal goed. Zo komt canvas al bij de schrandere scholier voor, maar wordt pas bij meteoor toegelicht. Zou mooi zijn als er concrete opdrachten/toetsen liggen om te toetsen. 68

72 Aanvullingen Opmerking toevoegen dat je MollenMeppen.zip als zip moet uploaden en dus niet uitpakken. Opmerking toevoegen dat je de emulator niet 2 keer moet openen. Dit geeft errors en maakt de boel instabiel. Voeg bij MollenMeppen meer suggesties/bonus opgaven toe. Bijvoorbeeld een achtergrondje erbij maken. Een goed resource package bij het materiaal leveren. Handleiding voor systeembeheerder toevoegen. Diagnostische opdrachten om leerlingen fouten in het programma te laten vinden en ze vervolgens op te lossen. Maak een opdracht die via het internet aan de echte wereld hangt. Dit is de kracht van mobiele apparaten. Ideeën voor projecten: Wordfeud en Poker. Context Bedenk dat beeldschermen op school vaak kleiner zijn dan je thuis hebt. Werkte direct op het schoolnetwerk. Jammer dat het niet platform onafhankelijk is. Hoe zit het met de ondersteuning van App Inventor door MIT op de lange termijn. Je wilt niet iedere paar jaar weer wat anders moeten doen. Blijft het gratis? Is een half jaar te lang voor deze module? Verankering van programmeerconcepten versus de breedte van het vak. Leerlijn Zeker een goede opzet naar een tekstuele taal. Ik zou leerlingen niet verplichten het lesmateriaal door te werken. Het MAG maar leerlingen kunnen ook uitgaan van een case zoals een rooster app. Je kunt het dan inpassen in een projectmanagement opzet. cirkel van social, create, share, (re)create, evaluate: en opnieuw. Leerlingen moeten een methodiek hanteren. Het materiaal wat ze maken moeten ze delen, expert geeft feedback, een nieuwe ontwikkelstap in en volgende iteratie! Aantal deadlines zijn noodzakelijk. Aan het einde een stukje marketing. Is er behoefte aan? Wat vinden gebruikers? Het lesmateriaal is techniek, leuk, maar niet interessant: visueel en qua ergonomie niet interessant (dat komt pas na feedback van gebruikers). Leerlingen kunnen zelf ideeën aandragen wat en ook hoe ze het willen doen. Er kunnen dus leerlingen tussen zitten die het programmeerverhaal niet snappen, die bijvoorbeeld het project management inrichten of zich op het grafische gedeelte storten. Gezonde mix van leerlingen. Meer open aanpak voorkomt "je was er niet: je hebt DIT stukje gemist". Ik zou het gebruiken om met bijvoorbeeld groep 8 leerlingen als PR apps te bouwen. 69

73 Vergelijk het met het maken van een mensfiguur uit klei en het maken van een abstract mensfiguur a la Picasso. Het tweede is opener, verwacht meer van studenten. De opdrachten en projecten scheiden ook qua tijd, de opdrachten kunnen in vierde maar zou projecten later doen klas 5 of 6. Projecten misschien ook vrijlaten als leerlingen b.v. ios op Mac te gebruiken. Verdere suggesties Leerlingen dragen zelf aan dat ze bijvoorbeeld een app zouden willen maken die aangeeft wat vandaag het eerste uur van het rooster is. Knal een domein de lucht in (los van App Inventor), zet het materiaal er op, hou het open, laat het groeien. [zie Serge de Beer heeft ook materiaal gemaakt. Is het mogelijk om diversiteit in te bouwen voor havo en vwo, dus dat je het materiaal voor havo en vwo iets anders maakt. Bij vwo is het juist wel goed als ze onderzoekend aan de slag moeten. Dit vinden ze een uitdaging en moeten ze ook aankunnen. Het materiaal is nu receptmatig en daardoor is het lastig om iets terug te vinden. Een reference manual met links naar dit materiaal kan hierbij helpen. Uit deze sessie is veel nuttige feedback gekomen. De belangrijkste feedback is dat men potentie ziet in het materiaal. We zullen niet meteen alle feedback kunnen verwerken. Ons eerste doel is om het materiaal testbaar in een lessituatie te maken. Daarom is één van de belangrijkste zaken om het materiaal geschikt te maken voor zowel havo als vwo leerlingen. Hiervoor hebben we voldoende feedback ontvangen. Verder zullen we goed moeten omschrijven wat docenten en systeembeheerders op school moeten weten om met ons lesmateriaal de slag te kunnen. Als dit in orde is kunnen ook docenten die niet mee hebben geholpen aan het maken van het materiaal gaan testen. Tot slot moeten we voldoende bonus opdrachten toevoegen/inbouwen zodat alle leerlingen uitgedaagd blijven. Resultaten en conclusies schriftelijke feedback De resultaten van de schriftelijke feedback zijn op dezelfde manier te labelen als de resultaten van de masterclass. Een groot deel van de labels komt niet terug in dit commentaar en is daarom weggelaten. Doelgroep Mij is niet duidelijk wat het doel van de module is: een allereerste introductie of aan de hand van de drie casussen een aantal programmeerconcepten duidelijk maken. Door de inrichting van de leerlingenmodule, die erg 'kookboekmatig' is (doe dit, doe dat) komt een doelstelling als programmeerconcepten onderwijzen niet uit de verf. Zet dus in ieder geval in beide teksten wat de bedoeling is en beargumenteer in de docentenhandleiding waarom er gekozen is voor bepaalde zaken, gegeven de geformuleerde bedoeling. Als het om de concepten gaat, moeten er bijvoorbeeld aan 70

74 het eind van elke casus ruimte zijn waar de leerlingen met hun leraren uitgedaagd worden om die concepten te expliciteren. De casussen schrandere scholier en meteoor komen mij als start voor het programmeeronderwijs al behoorlijk complex voor. Ergens wordt opgemerkt dat er geen problemen met 'diversiteit' worden verwacht. Maar de casussen mollen meppen en meteoor lijken mij meisjes minder aan te spreken. Opzet Neem in ieder geval in de docentenhandleiding op wat je verwacht dat leerlingen en docenten moeten beheersen vóór ze hiermee aan de slag gaan. Resultaten en conclusies interviews De resultaten van de interviews zijn op dezelfde manier te labelen als de resultaten van de masterclass. Algemene indruk Materiaal krijgt een dikke voldoende. Als het klaar is ga ik het zonder meer gebruiken in de les. Materiaal ziet er niet te druk maar wel aantrekkelijk uit. Krantenstijl lay-out leest fijn en makkelijk. Lay-out is prima. Brede kantlijn met kantlijn figuren is goed. Dit verstoort de kantlijn minder dan allemaal figuren in de tekst. Gebruik van highlights is goed en duidelijk. Doelgroep Opzet Niveau lijkt pittig voor havo (zeker met veel vmbo instroom). Het is altijd lastig om vooraf te beoordelen of het niveau precies goed is. Dat moet meestal proefondervindelijk vast worden gesteld. De docentenhandleiding zou in twee gedeeltes opgesplitst moeten worden. De achtergrond is best interessant maar veel docenten willen zeker in het begin alleen weten wat er nodig is om de leerlingen aan het werk te zetten en de omgeving op school draaiend te krijgen. Begin daarom met wat heb je nodig om je leerlingen aan het werk te zetten en zet de achtergrond theorie apart. Volgorde en opbouw is prima. De aanpak van uitvoeren - lezen - aanvullen - zelf maken lijkt een prima aanpak om mee te beginnen. 71

75 Motivatie De motiverende werking lijkt me prima. Leerlingen hebben hier echt wel zin in. Er zijn al leerlingen die gevraagd hebben of ze met zoiets als App Inventor aan de slag mochten buiten de lessen om. Verbeteringen Maak de Big Ideas expliciet in je lesmateriaal. Licht deze uit wanneer ze nodig zijn bij een opdracht. Bij MollenMeppen mag nog iets meer uitleg toegevoegd worden zoals aangeven hoe je geluid toevoegt. Dit moeten ze nu helemaal zelf uitzoeken. Aanvullingen Mogelijk nog een kleine zeer eenvoudige opdracht voor MollenMeppen invoegen. Voeg nog een aantal vrije extra/bonus opdrachten toe aan MollenMeppen. Context Leuk dat ze het op een telefoon kunnen uitproberen. Waardevolle toevoeging zeker in deze tijd. Leerlingen zien zoiets wel zitten. Leerlijn De stap van App Inventor naar tekstueel programmeren zou nog wel eens te groot kunnen zijn. Misschien is er nog een tussenstap nodig. Wat je mist is een scripting taal in App Inventor zoals bij GameMaker. Het is moeilijk in te schatten hoe dit materiaal in de leerlijn programmeren past. Het is in ieder geval beter dan meteen met tekstueel programmeren te beginnen. Het lijkt niet minder geschikt dan bijvoorbeeld GameMaker of Visual Basic. Verdere suggesties Onze vakvereniging i&i heeft een omgeving waarin ze materiaal onderbrengen. Jullie zouden contact op kunnen nemen over jullie materiaal. [Gedaan] Maak uitwerkingen (oplossingen van de opdrachten) voor de docenten. Let op hierbij op veiligheid, je wilt niet dat leerlingen hier makkelijk aan kunnen komen. Je kunt een wedstrijd koppelen aan het ontwikkelen van apps. Loof bijvoorbeeld een kleine prijs uit voor de beste app. Laat leerlingen zien hoe ze apps in de Google Play Shop zetten. Het materiaal kan ter vervanging van GameMaker of Visual Basic kunnen dienen. Dit kun je doen voor de hele klas maar je kunt het ook alleen zittenblijvers laten doen. Ga ook na wat leerlingen precies bezig houdt op het gebied van mobiele telefoons. Welke apps gebruiken ze en wat voor spellen spelen ze? Als je soms met leerlingen meekijkt zie je dat een spel bijvoorbeeld helemaal niet ingewikkeld hoeft te zijn. Je ziet dat ze vaak "lullige spelletjes" spelen als ze even niks te doen hebben. 72

76 Ook de docenten die we geïnterviewd hebben zijn enthousiast over het materiaal. Ze zien ook hoe en waar ze het in hun curriculum in kunnen passen. Vooral het feit dat ze hiermee zittenblijvers een alternatief aan kunnen bieden ten opzichte van het jaar daarvoor spreekt ze aan. Dit levert ook een goede testgroep op voor het materiaal omdat die ook hetgeen kennen dat door ons materiaal vervangen wordt. Als we naar de opmerkingen van de docenten kijken zien we dat ze in lijn zijn met de opmerkingen uit de masterclass. Dit rechtvaardigt ons besluit om niet nog meer docenten te zoeken om te interviewen. Wat nog wel zinvolle toevoegingen zijn is aandacht besteden aan de Google Play Shop en een wedstrijd element inbouwen bij het ontwikkelen van de apps. Ook de suggestie voor een andere structuur van de docentenhandleiding en het zorgen dat er uitwerkingen voor de docenten zijn van de opgaven moeten we meenemen. Tot slot kunnen we het lesmateriaal nog effectiever maken door de Big Ideas die we behandelen expliciet in het materiaal te verwerken. Hierdoor worden leerlingen direct bekend gemaakt met de programmeerconcepten die belangrijk worden gevonden door didactici en docenten. Hierbij is het belangrijk om goed aan te geven hoe zo n concept terugkomt in de app en waarom het belangrijk is. 73

77 C. Bekeken en vergeleken lesmateriaal C.1. GameMaker4School De opzet van het boek GameMaker4School vinden wij een schoolvoorbeeld van hoe het moet. Het begint met één van de in Saeli (Saeli, 2012) genoemde didactische aanpakken die effectief is gebleken in het programmeeronderwijs namelijk het aanvullen van een bestaand programma, in dit geval een game. Door de leerlingen een bestaande game aan te laten vullen zien ze met weinig inspanning direct een leuk resultaat (snel succes moment), bovendien zijn er veel kleine stapjes (veel succes momenten). Als ze van scratch beginnen hebben ze aanvankelijk alleen een bewegend poppetjes in een leeg veld, een bewegend poppetje in een reeds gemaakt speelveld daarentegen geeft meer motivatie. Daarnaast bouwt GameMaker4School de complexiteit goed op door van de basis (eenvoudigste begrippen) te werken naar meer complexe dingen. De games die na het eerste spel moeten worden gemaakt vragen om het toepassen van moeilijkere begrippen maar ook minder voor de hand liggende type begrippen (door een ander type game te laten maken). De opzet van een les is zo te zien gebaseerd op het Directe Instructie model idee. Ondanks dat dit een oud model is is het geen fout model! Leerlingen hebben structuur en herhaling nodig en dat biedt het model voldoende. Iedere les begint met de leerdoelen, de te leren begrippen en de benodigdheden. Iedere les sluit af met wat er in die les geleerd is. Dit zijn allemaal belangrijke onderwijs aspecten. Verder is er verdieping aangebracht op punten waar dat mogelijk is in de diverse lessen. Deze verdieping is in principe niet nodig maar wel wenselijk om onderscheid te maken tussen snelle en langzame leerlingen omdat er een overvloed aan materiaal is. De snelste leerling kan bijvoorbeeld bij bladzijde 30 zijn terwijl de langzaamste bij pagina 8 is. Op deze manier blijven alle leerlingen bezig. Het nadeel hiervan is echter dat dit de klas verdeeld en dat is niet wenselijk. Je kunt verder onderlinge afstandelijkheid en jaloezie krijgen die je als docent weer in de kiem moet smoren en die nooit bevorderlijk is voor de sfeer in de klas. Bovendien loop je op het einde in de val omdat je dan typisch wilt dat er een game in groepjes wordt gemaakt. En dan zitten de snelle leerlingen bij elkaar in de groep omdat die klaar zijn en je ze niet kunt laten wachten. Dit laatste wil je typisch niet omdat je snelle en langzame leerlingen wilt mengen zodat de snelle leerlingen de langzame leerlingen uitdagen hun grenzen te verleggen (let wel op dat je hier expliciet op aanstuurt anders heb je kans dat de langzame leerlingen juist niets of weinig doen!). Door tijdig verdiepingen in het lesmateriaal op te nemen voorkom je bovenstaand probleem. De leerlingen zullen als het goed is minder ver uiteen lopen wat plaats in het lesmateriaal betreft. Dit is ook bevorderlijk voor de motivatie van de snelle leerlingen. Een snelle leerling die ziet dat hij 20 pagina's voor ligt op de rest zou kunnen besluiten om het maar rustig aan te gaan doen. Dit kan bij deze leerlingen leiden tot verveling en dat kan ordeverstoringen 74

78 teweeg brengen. In het minst slechte geval gaat zo'n leerling een beetje internetten of zelfs aan andere vakken werken en feitelijk is dat niet de bedoeling zelfs al is de leerling goed in het vak! Daarnaast is er nog een belangrijk voordeel en dat is dat de snelle leerlingen intellectueel uitgedaagd worden. Zij zullen het lesmateriaal typisch goed kunnen volgen en makkelijk vinden. De complexiteit aan het einde van het materiaal zal voor hen nog steeds makkelijk zijn. Zonder verdieping worden zij daarom minder intellectueel uitgedaagd. Dit is jammer en kan demotiverend werken "bwah alweer hetzelfde suffe gedoe!". Misschien een minder aspect is de look & feel van GameMaker4School. Het is bedoeld voor groep 8 en klas 1 en 2 van de middelbare school. Daarom is het lekker kleurrijk opgezet. Voor onze doelgroep (klas 4 en 5 van de middelbare school) komt het misschien iets te kinderlijk over. Ik denk dat ons materiaal daarom een professionelere look & feel moet hebben. Wat wij wel goed vinden is de keuze voor landscape formaat en twee kolommen. Dit leest veel makkelijker dan A4. Het doornemen van het GameMaker4School boekje is daardoor veel fijner dan het doornemen van het "Ontwikkelen van ios applicaties" materiaal. Wij willen in ons materiaal daarom genoeg witruimte en niet te brede regels gebruiken. C.2. Fundament Informatica: Ontwikkelen van ios applicaties Dit is een nieuwe programmeermodule van Fundament Informatica (Instruct). Deze module lijkt op de onze als het gaat om het platform waarvoor ontwikkeld wordt want dat is de iphone. Blijkbaar ziet Instruct ook mogelijkheden in de mobiele context. Het materiaal is technisch opgezet. Het begint met een inleiding, een stukje context en historie. Daarna welke soorten applicaties er zijn, welke ontwerpregels er zijn en vervolgens hoe de SDK werkt. Dit is een hele lap tekst waarbij de leerlingen nog niks echt kunnen maken. Het gevolg hiervan is dat er weinig succes momenten in zitten voor de leerlingen en dit is niet motiverend. Wij kiezen daarom voor een andere opzet van ons materiaal. Op het moment dat de leerlingen zelf iets gaan maken wordt er gewerkt met een plaatje van een auto. Wij vinden dit minder handig omdat dit een typisch jongens onderwerp is. Een neutralere opdracht die zowel jongens als meisjes aanspreekt verdient de voorkeur volgens ons. Verder is dit materiaal uitgebreid en goed uitgewerkt, alleen voor ons niet op de manier waarop wij het aan zouden willen pakken. Er lijkt ook geen specifieke didactiek aan ten grondslag te liggen. Tot slot zijn de kosten die komen kijken bij de aanschaf van de ontwikkelomgeving en de licentie om je apps op je iphone te krijgen volgens ons een belemmering voor de module. Daarom hebben wij voor een platform gekozen waaraan (buiten een telefoon) geen kosten aan verbonden zijn. Bovendien kan een school een aantal goedkope telefoons aanschaffen voor leerlingen die er zelf geen hebben. 75

79 C.3. Ervaring met Solid Edge en Google Sketchup Bij Google Sketchup in klas 2 (vwo plus niveau) was het idee dat we ze eerst stap voor stap begeleiden bij het tekenen van een huis. Dit kan typisch in één lesuur. Daarna mogen ze zelf aan de slag en uiteindelijk moeten ze een stoel tekenen. Ze weten hoe die er uit moet zien en er is een filmpje van hoe je deze stoel kunt tekenen. De leerlingen reageren hier erg divers op. Veel leerlingen vinden Google Sketchup niet leuk. De helft van de klas komt significant minder ver dan de andere helft. De reden dat ze Google Sketchup niet leuk vinden kan te maken hebben met het feit dat het maar een tekentool is (niet professioneel) maar ook met het feit dat de begeleiding bij het leren te minimaal is. Solid Edge in dezelfde klas levert andere resultaten. Het programma is complexer, kan dus meer en wordt professioneel gebruikt. Bovendien heeft de distributeur erg gedetailleerde lesbrieven gemaakt zodat iedere leerling vooruit kan met het materiaal. Na de eerste zeven stappen voor te hebben gedaan kon iedere leerling zelfstandig aan de slag (en dit hadden wij niet verwacht). Ook de onderlinge verschillen tussen de voortgang van de leerlingen is veel minder extreem. Aan het einde van de eerste les is iedere leerling enthousiast. Het enige nadeel van de lesbrieven is dat ze van hetzelfde detailniveau blijven zodat je het inzicht van de leerlingen te weinig aanspreekt naarmate de tijd vordert. Dit is iets dat je als docent dan in moet bouwen in de lessen op een andere manier. Hier moeten wij bij ons materiaal rekening mee houden. Begrippen moeten minimaal twee keer aan de orde komen. De eerste keer in detail uitgewerkt de twee keer globaal zodat leerlingen terug moeten grijpen op hun ervaring uit het verleden. Meer dan twee herhalingen kan overigens geen kwaad hierbij. Geef ook niet meteen de verwijzing naar waar het begrip de eerste keer in detail behandeld is weg want dan zoeken ze het op en ontbreekt het teruggrijp effect. 76

80 D. Ontwerpplan lesmateriaal Wensen van de opdrachtgever Bij het ontwikkelen van dit lesmateriaal zijn de makers feitelijk de opdrachtgevers. Er worden gedurende het onderzoek wel meningen van informatica vakdidactici en docenten gevraagd en verwerkt in dit plan. Onze twee belangrijkste eisen aan het materiaal zijn dat het effectief moet zijn met betrekking tot het leren programmeren. Verder moet het motiverend zijn voor leerlingen om mee aan de slag te gaan. De keuze van het platform, zijnde de mobiele telefoon, zou op zich al een grote drive bij de leerlingen moeten genereren maar dit alleen is niet voldoende. Criteria die effectiviteit bevorderen zijn: intuïtieve en duidelijke aanpak voor het aanleren van basis concepten van het programmeren zoals script/programma, syntax & semantiek, statements, variabelen, selectie en herhaling. voldoende herhaling om de basis concepten in te laten slijten bij de leerlingen voldoende sprekende en aansprekende voorbeelden voldoende aansprekende opdrachten en uitdagingen meerdere manieren om door het lesmateriaal te lopen (leerstijlen) Criteria die motivatie bevorderen zijn: opdrachten en uitdagingen die iets bruikbaars opleveren veel succes momenten focus blijven houden op het eindresultaat dat bruikbaar is basis voor andere opdrachten in de toekomst Het lesmateriaal moet geschikt zijn voor leerlingen van havo en vwo klas 4. Uitdagingen waar deze lessenreeks aandacht aan wil besteden Er zijn geen specifieke bèta-onderwijs uitdagingen zoals dubbelzinnige leerdoelen, overladen curriculum, onsamenhangend curriculum, beperkte transfer of irrelevantie waar we aandacht aan willen besteden. Al is beperkte transfer wel iets waarover we ons zorgen maken bij het programmeeronderwijs op middelbare scholen. Het idee is dat we een visuele programmeeromgeving gebruiken om basis concepten bij te brengen zodat het later makkelijker is om over te stappen naar een tekstuele programmeeromgeving met een interpreter of compiler. Onze grootste uitdaging wordt de leerlingen spelenderwijs te leren programmeren. 77

81 Leerdoelen Keuzes type leerdoelen Om de leerlingen spelenderwijs te leren programmeren willen we een constructivistische aanpak hanteren. Door middel van herkenbare en voor leerlingen interessante uitdagingen moeten zij zelf in de wereld van het programmeren willen duiken om die uitdagingen aan te pakken. Een probleemgestuurde onderwijs aanpak kan zich hier goed voor lenen. Het is echter wel essentieel om een bepaald deel van de leerlingen op weg te helpen via een meer cognitieve aanpak. Het aanbrengen van differentiatie in de klas is daarom noodzakelijk. Het is ook belangrijk individuele programmeerkennis op te laten bouwen en die vervolgens toe te laten passen in teamverband. Bij de cognitieve aanpak die voor een deel van de leerlingen aangeboden moet worden gebruiken we meer gedetailleerde instructies om de leerlingen wegwijs te maken in de ontwikkelomgeving en de basis programmeer concepten. Hierbij is het wel belangrijk dat leerlingen niet alleen maar knopjes leren drukken, ze moeten ook begrijpen wat ze doen en waarom. De leeropbrengsten zitten verdeeld over de taxonomie van Bloom (Krathwohl, 2002). Er is kennis en begrip nodig van de basis concepten. Vervolgens moeten die toegepast leren worden. Daarna zullen ook analyse en synthese een belangrijke rol gaan spelen als meer complexe programmeeruitdagingen te lijf worden gegaan. Leerdoelen 1. (Her)kennen van de basis concepten van het programmeren. 2. Toepassen van de basis concepten van het programmeren. 3. Integreren van basis concepten van het programmeren. 4. Zelfstandig apps kunnen ontwikkelen, implementeren en testen. kunnen toepassen van oplossingsstrategieën bij eigen problemen. Relatie leerdoelen met uitdagingen en wensen opdrachtgever De leerdoelen zijn onderling afhankelijk. Leerdoel 2 hangt af van leerdoel 1, leerdoel 3 van leerdoel 2 en leerdoel 4 van leerdoel 3 (en deze afhankelijkheid is transitief). Leerdoel 4 is waar het uiteindelijk om gaat. Met een relevant en interessant platform om apps voor te ontwikkelen zal de motivatie van de leerlingen optimaal gestimuleerd worden. Door de complexiteit te vergroten per leerdoel zullen leerlingen stapsgewijs op een effectieve manier geleid worden naar het zelfstandig apps kunnen ontwikkelen. Voorkennis Te verwachten voorkennis Het uitgangspunt is dat leerlingen geen programmeerkennis hebben. Dit zal voor een deel van de leerlingen niet waar zijn. Vandaar dat het noodzakelijk is differentiatie aan te brengen in de klas. 78

82 Het is wel de verwachting dat leerlingen ervaring hebben met het gebruiken van apps op een mobiele telefoon. Ook is het de verwachting dat leerlingen met web applicaties en gewone PC applicaties hebben gewerkt. De programmeeromgeving zal deels afwijken van wat leerlingen gewend zijn maar ook overeenkomsten vertonen. Leerlingen hebben vaak impliciet ervaring met het opdelen van een groter probleem in deelproblemen. Ze zijn zich hiervan echter vaak niet bewust. Het is belangrijk deze voorkennis te activeren voordat ze beginnen met leren programmeren. Strategie voor het omgaan met voorkennis Leerlingen met programmeerkennis moeten de vrijheid krijgen om zelfstandig aan de slag te gaan. Hiervoor moet het te ontwikkelen materiaal mogelijkheden bieden. Het activeren van de voorkennis over decomponeren kan aan de hand van uit het leven gegrepen voorbeelden. Hiervoor moeten de juiste voorbeelden worden gevonden. Het te ontwikkelen materiaal moet aandacht besteden aan verschillen en overeenkomsten met veel gebruikte web en PC applicaties zoals Microsoft Office producten. Rekening houden met diversiteit Het is belangrijk om in het te ontwikkelen materiaal voorbeelden te gebruiken die zowel jongens als meisjes aanspreken. Het is echter ook belangrijk om geen voorbeelden te pakken waardoor jongens juist minder gemotiveerd raken. Kleine voorbeelden verdienen daarom de voorkeur boven grote. Voorbeelden die in meerdere culturen voorkomen verdienen ook de voorkeur. We moeten voorkomen voorbeelden te gebruiken die typisch van westerse aard zijn. We gaan er verder vanuit dat informatica toegankelijk is voor alle profielen. Het is daarom belangrijk technisch georiënteerde voorbeelden te voorkomen. Ook hier is afwisseling belangrijk, laat voorbeelden zien uit alle profielen. Diversiteit wat voorkennis betreft hebben we hiervoor al besproken. Benadering Bètadidactische benadering We gaan een combinatie van cognitieve en constructivistische aanpakken toepassen. Dit is noodzakelijk door de diversiteit aan leerlingen die we in de klassen verwachten. Voor het cognitieve deel zullen we gebruik maken van een Activerende Direct Instructie achtige aanpak. Verder zullen we een probleemgestuurde aanpak kiezen als de basis aanwezig is of is gelegd. 79

83 Consequenties voor opbouw Leeractiviteiten Leerlingen moeten uiteindelijk leren zelf apps te maken. Dit is het uiteindelijke doel en zou ook de motivatie moeten geven om zich in te zetten bij deze lessenserie. Docentrollen De rol van de docent verandert gedurende de lessen van leidend naar ondersteunend. Groeperingsvormen Leerlingen werken individueel en in groepen. De groepsgrootte is bij voorkeur 2 tot 3 personen. Leeromgeving De lessen zullen gegeven worden in een informaticalokaal met voldoende computers. Bovendien moeten er voldoende mobiele telefoons met Android erop aanwezig zijn, maar naar verwachting zal dit geen probleem zijn. Tijd De lessenserie beslaat ten minste één periode maar bij voorkeur twee waarbij uit wordt gegaan van drie lesuren per week. Bij voorkeur zit er één blokuur in de week. Toetsing Voor de leerlingen die nog geen programmeer ervaring hebben moeten we formatieve toets momenten in de te ontwikkelen materiaal bouwen zodat er veel succes momenten zijn. Daarna zullen de gemaakte apps beoordeeld worden. Dit toetst alleen leerdoel 4 expliciet maar feitelijk worden leerdoelen 1, 2 en 3 hierbij impliciet getoetst. Een leerling is niet in staat een voldoende goede app te ontwikkelen als leerdoelen 1, 2 en 3 niet bereikt zijn. Bètadidactische ingrediënten Bij deze lessenserie staat ICT centraal aangezien het hier om een programmeeronderwijs gaat. Verder is het een soort van practicum omdat er veel praktische opdrachten in zitten die uitgewerkt moeten worden. Bij de complexere opdrachten zal modelleren ook een rol gaan spelen omdat leerlingen een model moeten maken van hetgeen ze willen gaan implementeren. 80

84 E. Docentenhandleiding Voor updates en de bijbehorende resources zie 81

85

86 Android Apps met App Inventor Docentenhandleiding Coen Crombach Robin Eggenkamp François Vonk 1 juli 2012

87

88 Inhoudsopgave 1 Inleiding 1 2 Opzet van het materiaal 5 3 Achtergrond bij keuzes gemaakt in het materiaal 11 4 Tot slot 17 5 Referenties 19 iii

89

90 Hoofdstuk 1 Inleiding Noot Het lesmateriaal dat u hebt gekregen is nog niet af! Zaken zoals lay-out en schrijfstijl zijn bijvoorbeeld nog niet altijd consistent. Ook is het materiaal nog niet helemaal compleet. Het materiaal is volgens ons echter van voldoende kwaliteit om er een oordeel over te vormen en aan te geven of het zinvol is om het af te maken of dat we mogelijk zaken anders aan moeten pakken. Hierover willen we dan ook graag feedback. We zijn in het bijzonder geïnteresseerd in uw mening over motiverende werking en effectiviteit. Beste docent. Dit is de docenten handleiding bij het lesmateriaal Android Apps met App Inventor. Het lesmateriaal is zo opgezet dat leerlingen die dit willen zelfstandig kunnen werken. In het lesmateriaal zijn opgaven verwerkt die makkelijk herkend kunnen worden door de manier waarop we ze vorm hebben gegeven, zie figuur 1

91 2 Hoofdstuk 1 Inleiding 1.1. Hierdoor kunnen meerdere lesstrategieën tegelijkertijd worden toegepast: Leerlingen kunnen zelfstandig de opdrachten in het materiaal zoeken en proberen die te maken door eerst zelf zo ver mogelijk te komen en op te zoeken wat ze niet weten. Leerlingen kunnen zelfstandig gaan lezen en opdrachten maken wanneer ze die tegenkomen. Leerlingen kunnen zelfstandig eerst alles doorlezen en daarna opdrachten gaan maken. Je kunt als docent de hele klas of die leerlingen uit de klas die daar behoefte aan hebben een aantal stappen uit het materiaal voordoen en de leerlingen het dan na laten doen. Dit biedt de mogelijkheid om leerlingen met verschillende leerstijlen op een voor hen fijne manier aan het werk te zetten en ze daardoor beter te bedienen. In hoofdstukken 1 (Installatie) en 2 (Ontwikkelomgeving) staan nog geen opgaven. Het is daarom raadzaam alle leerlingen die twee hoofdstukken eerst door te laten lezen. Figuur 1.1 Opmaak van een opgave in het materiaal We raden aan om als docent een Google account te heb-

92 3 ben zodat je zelf de App Inventor ontwikkelomgeving kunt gebruiken. Hieronder de relevante links (die natuurlijk ook in het lesmateriaal staan): accounts.google.com/newaccount?hl=nl beta.appinventor.mit.edu Ook raden we aan om toegang tot een dummy leerling schoolaccount te hebben zodat je kunt testen of alles werkt voor de leerlingen. Dit voorkomt vervelende verrassingen tijdens de eerste les.

93

94 Hoofdstuk 2 Opzet van het materiaal Na de uitleg van de installatie en ontwikkelomgeving beginnen we met een luchtig spel genaamd Mollen Meppen. We laten de leerlingen hier allereerst kennismaken met de emulator. We raden aan de leerlingen niet te vroeg naar een echt Android apparaat te laten gaan omdat we het gebruik van de emulator ook belangrijk vinden. Bovendien wil je in het begin dat leerlingen met de ontwikkelomgeving bezig zijn en niet met hun mobieltje. Als ze alle opgaven van Mollen Meppen hebben gemaakt (behalve de bonus opgave) is het een mooi moment om het op hun telefoon te testen. In het lesmateriaal worden elementen uit de ontwikkelomgeving met een aparte opmaak weergegeven. Voor items uit de menu s gebruiken we tekst op een licht groene achtergrond en voor programmeerblokken (blocks) gebruiken we tekst op een licht blauwe achter- 5

95 6 Hoofdstuk 2 Opzet van het materiaal grond. Dit staat uiteraard ook uitgelegd in het lesmateriaal zelf. Bij het lesmateriaal worden ook projecten bijgeleverd die als startpunt voor de leerlingen dienen. Omdat scholen verschillende leeromgevingen hebben kunnen we in ons lesmateriaal geen informatie verschaffen over waar deze projecten te vinden zijn. Het handigst is het als de leerlingen dit al weten voor ze met het materiaal aan de slag gaan. Op punten waar zij iets nodig hebben geven we in het lesmateriaal aan dat ze bij de docent kunnen informeren waar het één en ander staat. Het lesmateriaal begint vrij eenvoudig en wordt gaandeweg moeilijker. We zetten eerst de basis in de steigers (scaffolding) en bouwen daar vervolgens op verder. Ook worden belangrijke concepten herhaald om ze goed te verankeren. Ieder hoofdstuk heeft verder één of meerdere bonus opgaven zodat leerlingen die snel door het lesmateriaal gaan extra uitdagingen krijgen. In figuur 2.1 staat een schema dat aangeeft welke App Inventor - en programmeerconcepten aan bod komen in de diverse onderdelen van het lesmateriaal. De verschillende fontkleuren in het figuur geven de volgorde in het lesmateriaal aan. Concepten in rode tekst behoren bij Mollen Meppen, groene tekst bij Schrandere Scholier en blauwe tekst bij Meteoor. De doorgetrokken pijlen geven afhankelijkheidsrelaties aan. Zo hebben we ervoor gekozen een leerling eerst code te laten lezen voordat hij/zij met het design scherm aan de slag gaat. Voordat een leerling echter zelf gaat programmeren moet deze eerst een beperkte kennis van het design scherm hebben. De onderbroken pijlen geven herhaling weer en staan alleen tussen concepten met gelijke namen.

96 7 Concepten die op dezelfde hoogte staan in het figuur hebben geen relatie of afhankelijkheid ten opzichte van elkaar. Een aantal concepten in figuur 2.1 verdienen enige toelichting: Met design scherm bedoelen we gebruik van menu s en componenten. Met selectie bedoelen we het conditioneel uitvoeren van stukken code met bijvoorbeeld een if-statement. Met events bedoelen we gebeurtenissen gegenereerd door standaard componenten, zoals het indrukken van een knop. Met sprites worden bewegende objecten bedoeld. We hebben botsen detecteren gebruikt als vertaling van Collision Detection.

97 8 Hoofdstuk 2 Opzet van het materiaal Figuur 2.1 Scaffolding en herhaling In het lesmateriaal is niet specifiek rekening gehouden met vrouwelijke leerlingen of allochtone leerlingen. De onderwerpen zijn naar onze mening redelijk neutraal van aard op het gebied van deze vormen van diversiteit. Op het moment schatten we de benodigde tijd per onderwerp als volgt in: Introductie en Mollen Meppen 4 lesuren Schrandere Scholier 6 lesuren Meteoor 6 lesuren Onderwerp waarin we procedures met parameters gebruiken en liefst variabelen, selectie en

98 9 loops herhalen 6 lesuren (nog te ontwikkelen) Vrije individuele opdracht 10 uren (nog te ontwikkelen) Vrije groepsopdracht 15 uren (nog te ontwikkelen) Dit is in totaal 47 uur wat uitkomt op bijna 16 weken bij 3 uur les per week. Vrij vertaald zou dit moeten passen in 2 perioden van ongeveer 8 weken.

99

100 Hoofdstuk 3 Achtergrond bij keuzes gemaakt in het materiaal Ons doel met het lesmateriaal was het maken van een lessenserie die leerlingen motiveert om te leren programmeren en die dit vervolgens op een effectieve manier doet. Het gekozen platform is ons grootste motiverende aspect. Echter het niet hoeven omgaan met vaak lastig te interpreten compiler of interpreter meldingen omdat we voor een grafische ontwikkelomgeving hebben gekozen zal voorkomen dat leerlingen gedemotiveerd raken. Voor startende programmeurs is een grafische ontwikkelomgeving een effectieve manier voor het leren van programmeerconcepten om de volgende redenen: 11

101 12 Hoofdstuk 3 Achtergrond bij keuzes gemaakt in het materiaal Syntax van tekstuele programmeertalen leidt af van de programmeerconcepten. Lastig te interpreteren meldingen van compilers en interpreters kosten vaak veel tijd die niet besteed kan worden aan het leren programmeren. Grafische bouwblokken die in elkaar klikken geven direct feedback over de semantiek van de bouwblokken zodat leerlingen niet steeds hoeven te zoeken naar de regels zoals bij tekstuele programmeertalen. Onder programmeerconcepten verstaan we dingen als variabelen, selectief code uitvoeren, herhaald code uitvoeren (loops), events, testen, debuggen enzovoorts. Als leerlingen eenmaal bekend zijn met de programmeerconcepten kunnen ze veel makkelijker en sneller overstappen naar een tekstuele ontwikkelomgeving omdat ze ook moeten ervaren hoe deze werken. Met name testen en debuggen is heel anders in dit type omgevingen. Zeker in het begin bij Mollen Meppen hebben we ervoor gekozen om de leerling steeds iets kleins te laten wijzigen zodat er voldoende succesmomenten zijn. Dit zal bijdragen aan de motivatie van leerlingen om door te gaan. Als eerste ervaring met programmeren hebben we er voor gekozen om de leerlingen al iets te geven dat werkt maar nog verre van perfect is. Dit is een goed beginpunt om voor het eerst een app uit te voeren in de ontwikkelomgeving. De opzet is dusdanig eenvoudig dat leerlingen het moeten kunnen begrijpen. Daarna mogen de leerlingen zelf dingen in de code veranderen en er dingen bij maken. Dit sluit aan bij de "cognitieve doe-

102 13 len strategie"van Jens Kaasbøll (Kaasbøll, 1998). In deze strategie onderkent Kaasbøll 4 stappen: 1. Voer een programma uit 2. Lees de code van een programma 3. Breng veranderingen aan in een programma 4. Schrijf zelf een programma Onderdeel van deze strategie is tevens het "programmeren door completeren"zoals beschreven door Merriënboer (Merriënboer, 1992). Dit wordt doorgaans ook als een goede didactische aanpak gezien bij het beginnen met leren programmeren. Verder hebben we gepoogd zoveel mogelijk van de zogenaamde Big Ideas van programmeren (Saeli, 2012) aan bod te laten komen omdat Informatica docenten deze belangrijk vinden binnen het programmeeronderwijs: Controle structuren met de focus op loops In Schrandere Scholier bij het doorlopen van een lijst Data structuren Arrays De ontwikkelomgeving kent getallen, booleans en tekst als data structuren maar dit is een zeer klein begin en booleans zijn zeer impliciet In Schrandere Scholier wordt de datastructuur lijst gebruikt

103 14 Hoofdstuk 3 Achtergrond bij keuzes gemaakt in het materiaal Zitten niet in de ontwikkelomgeving en komen daarom niet als zodanig aan bod In Schrandere Scholier worden wel lijsten gebruikt die feitelijk een meer algemene vorm van een array zijn Probleem oplossende vaardigheden Worden aangesproken in de opgaven in het lesmateriaal Decompositie In lichte mate in Mollen Meppen door met een procedure te werken in de versie die de leerlingen krijgen maar er wordt hier niet direct op gestuurd In Schrandere Scholier moeten leerlingen zelf een procedure maken Parameters In Schrandere Scholier worden deze genoemd maar de leerlingen hoeven er nog niet mee aan de slag Algoritmes In lichte mate in Mollen Meppen door het laten tellen van missers en het inbouwen van een score In lichte mate in Schrandere Scholier door het laten berekenen welk cijfer er gehaald moet worden voor een 8 gemiddeld

104 In Meteoor bij het werken met de hellingshoek van het mobiele apparaat 15

105

106 Hoofdstuk 4 Tot slot Het materiaal zoals het er nu ligt is wat ons betreft nog niet af. Er staan nog een aantal onderwerpen in de rij. Na het doorlopen van de onderwerpen raden we aan om leerlingen eerst individueel een App te laten bedenken en maken. Hiermee kun je toetsen of alle leerlingen iets hebben opgestoken van de programmeerconcepten. Vervolgens is het misschien leuk om leerlingen in groepjes een wat grotere App te laten bedenken en maken. Hierbij is het wellicht leuk om leerlingen educatieve Apps te laten maken die aansluiten bij één van de andere vakken die ze hebben zoals biologie, geschiedenis, aardrijkskunde enzovoorts. 17

107

108 Hoofdstuk 5 Referenties Kaasbøll, J.J. (1998). Exploring didactic models for programming. Tapir, pp Merriënboer, J.J.G. van (1992). Programmeren door completeren. TINFON, 1(2), pp Saeli, M. (2012, February). Teaching Programming for Secondary School: a Pedagogical Content Knowledge Based Approach. Technische Universiteit Eindhoven. 19

109

110 F. Lesmateriaal Voor updates en de bijbehorende resources zie

111

112 Android Apps met App Inventor Coen Crombach Robin Eggenkamp François Vonk 4 juni 2012

113

114 Voorwoord Dit boek is geschreven in het kader van Onderzoek van Onderwijs aan de Eindhoven School of Education, Technische Universiteit Eindhoven. Het boek is bedoeld voor gebruik als introductie tot programmeren in het vak Informatica in de bovenbouw van het voortgezet onderwijs. Aan de hand van enkele applicaties voor Android telefoons zul je de principes van programmeren leren. Gebruikte notaties In dit boek worden enkele notaties gebruikt om het voor jou als lezer makkelijker leesbaar te maken. In deze sectie geven we hier een opsomming van. Block Blocks zul je gebruiken om te programmeren. Blocks in App Inventor worden weergegeven als puzzelstukjes. Knop of menu Menuopties of knoppen worden op deze manier aangegeven. Term Belangrijke termen worden schuingedrukt om deze extra te benadrukken. iii

115 iv t Hints Naast de tekst worden soms belangrijke hints of tips gegeven. Opgaven Opgaven worden aangeduid met een blauwe balk. Opgave 0.1 Hier staat de vraag. Uitwerking: In sommige gevallen wordt ook een uitwerking gegeven. Waarschuwing In sommige gevallen willen we je een belangrijke waarschuwing of tip geven. Deze worden voorzien van een rode balk. Waarschuwing Hier staat een waarschuwing, lees deze zorgvuldig! Uitproberen! Regelmatig kom je de afbeelding hiernaast tegen. Dit betekent dat je de app waar je op dat moment mee bezig bent uit mag proberen op je telefoon of in de emulator.

116 Inhoudsopgave Voorwoord Gebruikte notaties iii iii 1 Installatie 1 2 Ontwikkelomgeving 5 3 Mollen Meppen Willekeurig opduiken van de mol Geluid toevoegen als je de mol raakt De mol op een timer laten bewegen Tellen van het aantal maal dat je mis slaat Score toevoegen Mol sneller laten bewegen bij hoge score Bonus opgaven Testen op je telefoon Schrandere Scholier Een nieuw project aanmaken Gebruikersinterface Rekenen Verbeteren Weer rekenen Facultatieve uitbreidingen v

117 vi INHOUDSOPGAVE 5 Meteoor Vooraf De Orientation Sensor De raket Besturing Kantelen xmax Geen Orientation Sensor? Raket onderaan scherm Obstakels Meerdere meteoren Botsing En weer verder Mogelijke uitbreidingen... 56

118 Hoofdstuk 1 Installatie De App Inventor ontwikkelomgeving draait in een webbrowser. Om toegang tot App Inventor te krijgen heb je een Google account nodig. Je kunt zo n account aanvragen op: nl. Als je een Google account (aangemaakt) hebt kun je inloggen via de volgende link: mit.edu. Nadat je ingelogd bent zie je een scherm zoals afgebeeld in figuur

119 2 Hoofdstuk 1 Installatie Figuur 1.1 My Projects scherm Op school is alle software die App Inventor nodig heeft al voor je geïnstalleerd. Maar als je thuis aan de slag gaat is dat misschien niet zo. Daarom volgen hierna de instructies om thuis te zorgen dat de App Inventor ontwikkelomgeving goed werkt. Als je al een werkende omgeving hebt kun je meteen door naar het volgende hoofdstuk. Het is nu belangrijk dat je de software installeert die App Inventor nodig heeft om de Blocks Editor en de emulator uit te voeren. Deze termen zullen je nu misschien nog niets zeggen en dat is op dit moment niet erg. Verderop in het materiaal, als je ze nodig hebt, zullen ze in detail behandeld worden. Het is nu belangrijk om op de Learn link te klikken, zie figuur 1.2.

120 3 Figuur 1.2 Locatie van de Learn link Als we dit hebben gedaan zien we het scherm zoals afgebeeld in figuur 1.3. Zoals je kunt zien zijn we op dit moment geïnteresseerd in de Setup link. Via deze link komen we namelijk te weten wat we allemaal moeten installeren om te kunnen werken met alle functionaliteit die App Inventor ons te bieden heeft. We moedigen je echter ook aan om op de andere links te klikken en even rond te neuzen wat je daar kunt vinden. Sommige links zijn handig als je later nog eens iets op wilt zoeken.

121 4 Hoofdstuk 1 Installatie Figuur 1.3 Locatie van de Setup link Nadat je op de Setup link hebt geklikt, zie figuur 1.3, kom je op een pagina met installatie instructies. Voorlopig hoef je alleen Step 1 te doen Set up your computer, zie figuur 1.4. De tweede stap mag je overslaan omdat we die in dit lesmateriaal met je gaan doorlopen. Figuur 1.4 Locatie van de Set up your computer link

122 Hoofdstuk 2 Ontwikkelomgeving Waarschuwing Voordat we van start gaan met App Inventor een kleine waarschuwing. De ontwikkelomgeving is niet altijd even snel en het gaat niet sneller door veelvuldig op links of knoppen te klikken. Sterker nog: dit zorgt er voor dat de omgeving nog langzamer wordt en dat er fouten op gaan treden. Om dit te voorkomen vragen we je om geduld te hebben en te wachten als de omgeving je daarom vraagt! Als het goed is heb je het scherm voor je zoals afgebeeld in figuur 1.1 en heb je nog geen projecten. Het eerste dat we daarom gaan doen is een project uploaden. Dat wil zeggen dat we een project dat iemand anders voor ons gemaakt heeft gaan binnenhalen in de ontwikkelomgeving. Om dit te doen klikken we op de More Actions - knop en kiezen vervolgens voor Upload Source, zie figuur

123 6 Hoofdstuk 2 Ontwikkelomgeving Figuur 2.1 Locatie van Upload Source Figuur 2.2 Upload Project pop-up In ons geval gaan we het MollenMeppen project binnenhalen. Als we op Upload Source hebben geklikt krijgen we de pop-up zoals afgebeeld in Figuur 2.2. Via deze pop-up kunnen we bladeren naar de locatie van het project dat we willen binnenhalen. Vraag je docent waar je het project kunt vinden. Als we het projectbestand hebben gevonden dan selecteren we het en klikken vervolgens op OK. Nadat we op OK hebben geklikt wordt het project MollenMeppen in ons scherm toegevoegd, zie figuur 2.3.

124 7 Figuur 2.3 My Projects scherm met MollenMeppen project Korte tijd nadat het project is toegevoegd zal de ontwikkelomgeving automatisch naar het Design-scherm springen waarin we het ontwerp van de applicatie zien, zie figuur 2.4. Om weer naar het My Projects scherm te gaan kun je deze aanklikken in de ontwikkelomgeving.

125 8 Hoofdstuk 2 Ontwikkelomgeving Figuur 2.4 Design scherm van MollenMeppen

126 Hoofdstuk 3 Mollen Meppen We hebben zojuist ons eerste project geladen en het ontwerp ervan kort gezien. Voor we uitgebreid naar het één en ander kijken gaan we de applicatie eerst een keer uitvoeren. Dit doen we door vanaf de Design pagina de Blocks Editor te openen via de Open the Blocks Editor link, zie figuur 3.1. Nu moet je even goed opletten omdat het kan zijn dat je browser toestemming vraagt om een aantal dingen te mogen doen. 9

127 10 Hoofdstuk 3 Mollen Meppen Figuur 3.1 Locatie van de Open the Blocks Editor link Als eerste wordt het AppInventorForAndroidCodeblocks. jnlp bestand geopend. Als je browser je hierover een vraag stelt moet je op openen klikken. Vervolgens wordt het bestand geladen door Java en kan het zijn dat je toestemming moet geven om het bestand uit te voeren. Vervolgens wordt de Blocks Editor geopend en zie je wat er in figuur 3.2 is afgebeeld.

128 11 Figuur 3.2 Blocks Editor van MollenMeppen Om de applicatie uit te voeren moeten we eerst een emulator opstarten. Dit doen we via de New emulator link zoals aangegeven in figuur 3.4. Als de emulator is opgestart ziet deze er uit zoals afgebeeld in figuur 3.3. De emulator staat nu nog op slot, we kunnen het slot verwijderen door met de muis op het slotje te klikken, de muisknop ingedrukt te houden, de muis in de richting van de pijl te bewegen zoals aangegeven in figuur 3.3 en de muisknop weer los te laten. Figuur 3.4 Locatie van de New emulator link Figuur 3.3 De emulator

129 12 Hoofdstuk 3 Mollen Meppen Als we de emulator van slot hebben gehaald kunnen we verbinding maken met de emulator. Dit doe we door op de Connect to Device link te klikken en vervolgens emulator-5554 te kiezen, zie figuur 3.5. Figuur 3.5 Locatie van de Connect to Device link Nadat we op de link geklikt hebben wordt onze applicatie in de emulator geladen. Als het laden klaar is zien we wat er is afgebeeld in figuur 3.6 en kunnen we de applicatie gebruiken. Klik op de mol en kijk wat er gebeurt. Wat er gebeurt is nog niet zo heel spannend en uitdagend maar daar kun je wat aan doen! Hieronder volgt een serie opdrachten waardoor je Mollen Meppen tot een echt spel kunt maken. We raden je aan om na iedere opgave waarin je de code aanpast deze uit te testen op de emulator. Veel succes! Figuur 3.6 De Mollen- Meppen applicatie

130 3.1 Willekeurig opduiken van de mol Willekeurig opduiken van de mol De mol beweegt zich erg voorspelbaar op dit moment en dat maakt het spel saai. In de Blocks Editor kunnen we zien waarom de mol zich zo gedraagt. Opgave 3.1 Bekijk de code van de procedure verplaatsmol en beredeneer waarom de mol zich verplaatst zoals je ziet wanneer je erop klikt. Wat we hier feitelijk willen is dat de x en y positie van de mol (de ImageSprite) willekeurig bepaald worden. Hiervoor kunnen we een block vinden onder de Built-In tab bij Math, zie figuur 3.7. Blocks uit de Blocks Editor kunnen we simpelweg in het blokkenveld slepen en daar neerzetten of in elkaar klikken. Als je per ongeluk een verkeerd block hebt gebruikt kun je het verwijderen door het naar de prullenbak rechts onder in het scherm te slepen en het block los te laten.

131 14 Hoofdstuk 3 Mollen Meppen Figuur 3.7 Locatie van de Built-In Math link Opgave 3.2 Verander de code van de procedure verplaatsmol zo- dat de mol zich willekeurig verplaatst binnen het veld. t Hint: Wat is het Engelse woord voor willekeurig? 3.2 Geluid toevoegen als je de mol raakt Als de mol geraakt wordt is het leuk als we dat ook horen. Gelukkig kunnen we dit programmeren in App Inventor. Zoek een leuk geluidje op via internet en maak de volgende opdracht. Opgave 3.3 Voeg een geluid toe aan het spel en speel dat geluid af op het moment dat de mol geraakt wordt.

132 3.3 De mol op een timer laten bewegen De mol op een timer laten bewegen Op het moment is het zo dat de mol zich alleen verplaatst als je hem een mep verkoopt. Het is leuker als de mol af en toe uit zichzelf ergens anders opduikt. Om dit voor elkaar te krijgen gebruiken we een zogenaamde timer. Deze kunnen we vinden via de Clock component in het Basic palette, zie figuur 3.8. Een component kun je in het Viewer gedeelte van je ontwikkelomgeving slepen. Je ziet dat de component ook toegevoegd wordt in het Components gedeelte van je ontwikkelomgeving. Dit is de plaats waar je componenten een andere naam kunt geven en verwijderen. Figuur 3.8 Locatie van de Clock control in het Basic palette

133 16 Hoofdstuk 3 Mollen Meppen Opgave 3.4 Voeg een Clock control aan het spel toe en kijk goed waar deze neergezet wordt. Beredeneer wat er gebeurt en waarom. Nadat we de Clock control hebben toegevoegd kunnen we de timer programmeren. Hiervoor moeten we in de Blocks Editor zijn. Je weet intussen hoe je die moet openen of je hebt hem nog open staan. Onder de My Blocks tab staat nu een Clock 1 link omdat we de Clock control hebben toegevoegd, zie figuur 3.9. Klik op de link en je ziet bovenaan een Clock1.Timer block. Figuur 3.9 Locatie van de My Blocks Clock1 link t Hint: Kijk eens bij de My Blocks My Definitions link. Opgave 3.5 Voeg het timer blok toe en zorg dat de mol zich om de zoveel tijd uit zichzelf verplaatst.

134 3.4 Tellen van het aantal maal dat je mis slaat Tellen van het aantal maal dat je mis slaat Naast het bijhouden hoe vaak een speler de mol raakt willen we ook graag bijhouden hoe vaak de speler misslaat. In je Components staat een HorizontalArrangement1 die ervoor zorgt dat je componenten horizontaal in je scherm kunt rangschikken. De componenten erin ( Label1 en Label2 ) komen overeen met aantal geraakt en 0 in je Viewer. Opgave 3.6 Breid de bestaande HorizontalArrangement1 uit met de tekst aantal gemist en de bijbehorende teller. Breid bovendien je programma in de Blocks Editor uit zodat het aantal keer dat de speler misslaat wordt bijgehouden. 3.5 Score toevoegen Het bijhouden van het aantal keer raak en misslaan is leuk maar een score is nog leuker. Voor iedere keer dat een speler de mol raakt krijgt hij/zij 3 punten. Voor iedere keer dat de speler de mol mist verliest hij/zij een punt.

135 18 Hoofdstuk 3 Mollen Meppen Opgave 3.7 Voeg een HorizontalArrangement toe in de Viewer waarin je de score informatie laat zien. Breid bovendien je programma in de Blocks Editor uit zodat de score wordt bijgehouden. 3.6 Mol sneller laten bewegen bij hoge score Naarmate de tijd vordert en hopelijk de score hoger wordt blijft de uitdaging van het spel op dit moment gelijk. Het spel vereist helaas niet steeds meer van het reactievermogen van de speler maar dat kunnen we veranderen. Opgave 3.8 t Hint: Als je de Clock component selecteert in bijvoorbeeld de viewer zie je bij Properties een veld dat TimerInterval heet. Kun je iets vergelijkbaars vinden in de Blocks Editor? Zorg ervoor dat voor elke 50 punten die de speler heeft de mol 50 milliseconden sneller beweegt. Houd rekening met een grens voor de snelheid. 3.7 Bonus opgaven Je kunt op dit moment nog niet afgaan bij het spel. Je kunt dit veranderen door de speler af te laten gaan wanneer hij/zij onder de 0 punten zakt. Een alternatief is door levens in te bouwen in het spel en deze onder bepaalde voorwaarden af te pakken tot de speler geen levens meer over heeft.

136 3.8 Testen op je telefoon 19 Opgave 3.9 Voeg naast de mol ook een andere dieren toe aan het spel. Laat deze dieren af en toe verschijnen in plaats van de mol. Deze dieren mag je niet meppen en als een speler dit toch doet verliest hij/zij een leven. Wanneer de speler geen levens meer heeft is het spel afgelopen. t Tip: Laat vaker andere dieren verschijnen naarmate de speler een hogere score bereikt. 3.8 Testen op je telefoon Tot nu toe heb je de app enkel getest in de emulator. Leuker is natuurlijk om de app ook op je eigen telefoon te draaien, je kunt hem dan ook thuis laten zien! Vanuit de design omgeving kun je rechtsboven kiezen voor Package for Phone en vervolgens Show barcode. Na verloop van tijd (afhankelijk van de drukte kan dit enkele minuten duren) krijg je een venster met daarin een zogenaamde QR-code. Deze code kun je scannen met de camera van je telefoon. Hiervoor heb je een app nodig, een voorbeeld is Qr Barcode Scanner, je kunt deze downloaden in de Play Store. Na het openen van Qr Barcode Scanner kies je voor Scan Barcode, je kijkt nu door je camera. Richt de camera op de barcode op het scherm. De app leest de barcode en geeft je de optie de URL die hierin verstopt is te openen in de browser. Na het openen van de browser wordt de download van een.apk bestand gestart. Na het downloaden open je het bestand. Wat er precies gebeurt is afhankelijk van je telefoon en de ver-

137 20 Hoofdstuk 3 Mollen Meppen sie van Android. Waarschijnlijk krijg je eerst de melding dat de installatie is geblokkeerd. Android telefoons zijn standaard ingesteld dat ze enkel applicaties vanuit de Market of Play Store kunnen installeren. Door Onbekende bronnen aan te vinken in het Beveiliging onderdeel van Instellingen kun je dit toestaan. Nadat je dit hebt gedaan open je de.apk opnieuw. Je krijgt nu de vraag of je de applicatie wilt installeren, je kiest voor de knop Installeren. Na enkele ogenblikken is de applicatie geïnstalleerd en kun je deze Openen. De volgende keer dat je de applicatie via een barcode wilt installeren zal de telefoon vragen of je de applicatie wilt vervangen, dit bevestig je door op OK te klikken en de applicatie vervolgens op dezelfde manier te Installeren.

138 Hoofdstuk 4 Schrandere Scholier In het vorige hoofdstuk hebben we een leuk spel gemaakt, we kunnen echter ook serieuze applicaties schrijven. Waarschijnlijk vraag je jezelf wel eens af welk cijfer je moet halen voor een toets om een 8 gemiddeld te blijven staan voor een vak. In dit hoofdstuk gaan we hier een hulpmiddel voor ontwikkelen. We zullen de applicatie stap-voor-stap opbouwen. We maken een begin met de gebruikersinterface in het design scherm. Daarna zullen we in de Blocks - editor ervoor zorgen dat de gebruiker cijfers kan invoeren waarmee we vervolgens kunnen gaan rekenen. Tot slot zorgen we ervoor dat de gegevens opgeslagen worden zodat we niet bij elke start opnieuw hoeven te beginnen. 21

139 22 Hoofdstuk 4 Schrandere Scholier 4.1 Een nieuw project aanmaken We beginnen met het aanmaken van een nieuw project. In hoofdstuk 2 heb je een project aangemaakt door een bestaand project te uploaden. Dit keer beginnen we vanaf het begin. Figuur 4.1 "New App Inventor for Android Project"pop-up Als je nog niet in het My Projects scherm bent, ga hier dan nu naar toe. Klik op de knop new om het venster zoals is weergegeven in figuur 4.1 te zien. Vul hier de naam van het project in, in dit geval "SchrandereScholier". Na een klik op OK wordt je nieuwe project aangemaakt en kom je terecht in het design -scherm. 4.2 Gebruikersinterface We beginnen met het ontwerpen van de gebruikersinterface. Voordat we hiermee aan de slag gaan kijken we naar de verschillende onderdelen van het scherm zoals je kunt zien in figuur 4.2.

140 4.2 Gebruikersinterface 23 Figuur 4.2 De verschillende onderdelen van het design-scherm 1. De knoppenbalk In deze balk vind je knoppen om het project op te slaan, nieuwe schermen toe te voegen en om je project op een telefoon of in de emulator uit te voeren. 2. Palette Het palette is de plek waar je alle ingebouwde componenten terugvindt om te gebruiken in jouw app. Om een component te gebruiken sleep je deze naar het scherm in de Viewer. 3. Viewer In de viewer kun je de gebruikersinterface ontwerpen. 4. Components Dit is een overzicht van alle componenten die op dit moment in gebruik zijn. Door op een component te klikken kun je zijn eigenschappen bekijken bij Properties. 5. Media In een applicatie kun je gebruik maken van bijvoorbeeld afbeeldingen, deze kun je hier toevoegen en beheren.

141 24 Hoofdstuk 4 Schrandere Scholier 6. Properties In dit deel van het scherm pas je eigenschappen van een component aan, bijvoorbeeld de kleur. t Geef componenten altijd een duidelijke naam, dit maakt het programmeren makkelijker! Nu je een idee hebt van de interface kunnen we deze gaan gebruiken. We beginnen eenvoudig met het toevoegen van enkele labels, TextBoxen en een knop. Sleep hiervoor eerst een Label vanuit het Palette naar de Viewer. Componenten worden automatisch uitgelijnd, het label komt daardoor linksboven te staan. Pas nu de tekst van het zojuist aangemaakte Label aan in het Properties paneel naar Toets 1. Om onze applicatie overzichtelijk te houden pas je ook de naam van het component aan. Hiervoor selecteer je het label in het Components paneel en gebruik je de knop Rename om het label te hernoemen naar Toets1Label. Om te zorgen dat er ook cijfers ingevoerd kunnen worden voeg je een TextBox toe. Sleep dus een TextBox naar de Viewer. Geef de TextBox de naam Toets1. Herhaal deze handelingen totdat je drie toetsen kunt invoeren. Zodra de gebruiker de cijfers heeft ingevoerd zul je het cijfer moeten uitrekenen wat de gebruiker moet halen voor de volgende toets om een 8 gemiddeld te halen. De berekening doen we later, maar we voegen nu al wel een knop toe en twee labels om het resultaat weer te geven. Een knop voeg je toe door een Button vanuit het Palette naar de Viewer te slepen. Net als bij een label kun je een text opgeven in het Properties paneel, vul hier Bereken in. Geef de Button vervolgens de naam Bereken.

142 4.2 Gebruikersinterface 25 Opgave 4.1 Maak nu de gebruikersinterface verder af, zodat deze er hetzelfde uit ziet als in figuur 4.3. Figuur 4.3 Gebruikersinterface van de Schrandere Scholier Je hebt nu de gebruikersinterface gemaakt, je kunt de applicatie nu dus al uitproberen op je telefoon of in de emulator! Je zult zien dat je al cijfers kunt invoeren, er gebeurt echter nog niks als je op de knop drukt. Daar gaan we nu iets aan doen!

143 26 Hoofdstuk 4 Schrandere Scholier 4.3 Rekenen t Een uitgebreidere uitleg vind je in hoofdstuk 2 We gaan nu zorgen dat de applicatie daadwerkelijk kan rekenen. Hiervoor moeten we programmeren en dit doen we in de Blocks Editor. Deze open je via de knop Open the Blocks Editor rechtsboven aan. Het scherm is nog helemaal leeg. Aan de linker kant staan de verschillende ingebouwde codeblokken, opgedeeld in verschillende categorieën, die je kunt gebruiken. Naast de ingebouwde codeblocks zijn er ook blocks speciaal voor jouw applicatie, deze vind je onder My Blocks. Voor elk component dat je hebt aangemaakt in de gebruikersinterface kun je hier codeblocks vinden. We willen dat er gerekend gaat worden zodra er op de knop Bereken geklikt wordt. Hier is een speciaal block voor genaamd Bereken.Click. Je gebruikt dit block door eerst op Bereken te klikken en vervolgens Bereken.Click naar rechts te slepen. Alle codeblocks die je in dit block hangt worden uitgevoerd als er op de knop geklikt wordt. Figuur 4.4 My Blocks van de Schrandere Scholier t Blocks in App Inventor passen enkel op elkaar als de aansluitingen compatibel zijn. Dit is net als bij puzzelstukjes. We beginnen met het verzamelen van de gegevens waarmee we straks kunnen rekenen. De cijfers moeten we uitlezen uit de TextBoxen, ook hiervoor staan er blokken klaar onder My Blocks. Het block Toets1.Text geeft je de inhoud van Toets1 terug. Sleep deze naar rechts om het te gebruiken. Zoals je waarschijnlijk ziet kun je nog niks met dit blok, de aansluiting komt namelijk niet overeen met de beschikbare aansluiting van Bereken.Click. We hebben dus nog andere blocks nodig. We willen straks gaan rekenen, een logische plek om

144 4.3 Rekenen 27 naar een passend block te zoeken is dus de categorie Math. Sleep bijvoorbeeld het optel block naar rechts. Je zult zien dat je hier Toets1.Text in kunt hangen. Niet al deze blocks hebben dezelfde aansluiting. Hoe komt dit? Deze aansluiting betekent dat het block een bepaalde waarde (bijvoorbeeld een tekst of getal, maar ook de uitkomst van een som) vertegenwoordigt, dit noemen we een expressie. In Bereken.Click passen enkel blocks die een actie vertegenwoordigen, dit wordt ook wel een statement genoemd. Opgave 4.2 Na het rekenen zullen we de uitkomst in TeBehalen moeten plaatsen. Zoek nu een block op waarmee je de uitkomst van een expressie in TeBehalen kunt zetten. Voeg dit block toe aan Bereken.Click. De expressie die weergegeven moet worden is de som van Toets1 en Toets2. Uitwerking: Het programma zou er nu uit moeten zien zoals in figuur 4.5. Figuur 4.5 Uitwerking Voordat we verdergaan: probeer uit of het programma werkt zoals je verwacht. Als het werkt dan wordt het tijd om ons programma uit te breiden. Er vanuit gaande dat alle cijfers dezelfde weging hebben, hoe kunnen we dan

145 28 Hoofdstuk 4 Schrandere Scholier het cijfer berekenen dat de gebruiker nodig heeft om een 8 te staan? De som van alle vier cijfers moet samen minimaal 8 4 = 32 zijn. Het benodigde cijfer is dus gelijk aan 32 min het totaal van de al behaalde punten. Opgave 4.3 Implementeer de bovenstaande berekening en zet het antwoord in TeBehalen. Je hebt hiervoor, naast de al bekende blocks, ook het min-block nodig en een constant getal. Een constant getal geef je aan met het block in figuur 4.6. Figuur 4.6 Constant getal Uitwerking: Het programma zou er nu uit moeten zien zoals in figuur 4.7. Figuur 4.7 Uitwerking Als je dit programma uitprobeert met een aantal combinaties van cijfers zullen je merken dat het nog niet optimaal werkt. Maar het werkt, en dat met maar enkele blocks! In de volgende paragraaf zullen we deze applicaties verder gaan uitwerken. Je zult daarbij meer zelfstandig aan de slag gaan met App Inventor. 4.4 Verbeteren De eerste verbetering die we zullen doorvoeren is het toevoegen van meer cijfers, waarschijnlijk heb je geen

146 4.4 Verbeteren 29 enkel vak waarbij je maar vier toetsen krijgt. Opgave 4.4 Zorg ervoor dat er vier cijfers kunnen worden ingevoerd, waarna het vijfde cijfer wordt berekend. Noteer op welke plaatsen je een aanpassing hebt moeten maken. Als het goed is weet je nu precies welke wijzigingen je moet maken om een nieuwe toets te voegen. Zouden we dit kunnen automatiseren? Dan kunnen we de gebruiker zelf toetsen laten toevoegen. Uiteraard is dit mogelijk! De makkelijkste oplossing zou zijn om de gebruiker nieuwe velden te laten toe voegen, dit is echter niet mogelijk in App Inventor. Om dit probleem toch te kunnen oplossen heeft App Inventor de mogelijkheid van lijsten. We kunnen het probleem nu implementeren door gebruik te maken van één TextBox om cijfers toe te voegen aan de lijst. Deze lijst kan vervolgens worden weergegeven en gebruikt om te rekenen. Dit gaan we in deze sectie implementeren. Allereerst maken we in de Blocks Editor de lijst aan. Je doet dit door het make a list block (uit het lists palette) het werkblad op te slepen. Zoals je ziet kun je in dit block items toevoegen, dit kan bijvoorbeeld een number zijn. Een voorbeeld zie je in figuur 4.8. Om de lijst te kunnen gebruiken in de rest van de code plaatsen we de lijst in een variabele. Hiermee geven we de lijst een naam zodat we hier vanuit andere blocks naar kunnen verwijzen. Je maakt een variabele aan via het def block in de categorie definitions zoals je kunt zien in figuur 4.9. Figuur 4.8 make a list block Figuur 4.9 De lijst in een variabele

147 30 Hoofdstuk 4 Schrandere Scholier Opgave 4.5 De interface kunnen we nu aanpassen. Maak de interface zoals is weergegeven in figuur Er staan twee labels in het ontwerp waarvan we later de tekst gaan uitpassen vanuit de Blocks editor. Denk ook nu aan een duidelijke naamgeving van de componenten. Figuur 4.10 Nieuwe gebruikersinterface

148 4.4 Verbeteren 31 Ga nu weer naar de Blocks editor. Als je de knop enkel hebt hernoemd heb je hier nog een block Toevoegen.Click staan. Indien dit niet het geval is voeg je deze toe vanuit My Blocks. In deze procedure moeten we het nieuw ingevoerde cijfer toevoegen aan de lijst. Een item toevoegen aan de lijst kun je doen via add items to list in het Lists palette. Dit block heeft twee blocks nodig als parameter, namelijk een list en een nieuw item. Bij list voeg je het def block toe welke je kunt vinden bij My definitions binnen het My Blocks palette, bij item voeg je een block Cijfer.Text toe. Om nu de ingevoerde cijfers weer te geven op de daarvoor bedoelde plaats moeten we nieuw soort block gebruiken, de foreach. Dezeloop gaat alle items uit een list langs en voert voor elk van deze items een actie uit. In dit geval kunnen we dit gebruiken om de cijfers in de list allemaal onder elkaar te zetten. Hoe je dit doet zie je in figuur Opgave 4.6 Implementeer het Toevoegen.Click block zoals is aangegeven in figuur 4.11 en probeer te doorgronden hoe dit werkt. t Weet je wat de \n betekent in deze implementatie?

149 32 Hoofdstuk 4 Schrandere Scholier Figuur 4.11 Implementatie Toevoegen.Click Probeer de app nu uit op je telefoon of in de simulator en controleer of je de code goed hebt begrepen. 4.5 Weer rekenen Onze oude methode om het benodigde cijfer te berekenen werkt nu niet meer, daar moeten we iets aan doen. Omdat we alle cijfers in een lijst hebben staan moeten hier weer een loop block voor gebruiken. Om te voorkomen dat onze code onoverzichtelijk wordt zullen we de berekening in een aparte procedure laten plaatsvinden. Een procedure is een groepje statements die worden uitgevoerd als je de procedure aanroept. Op deze manier kun je statements die bij elkaar horen groeperen. Een procedure kan ook een resultaat teruggeven.

150 4.5 Weer rekenen 33 Een nieuwe procedure kunnen we aanmaken door het procedurewithresult block, te vinden in het Definition palette, naar het canvas te slepen. Je kunt in op drie plekken blocks aanhangen. Allereerst bij arg, hier kun je een argument meegeven aan de procedure, dit zullen we hier nog niet gebruiken. Bij do voeg je de acties toe die moeten gebeuren. Bij return geef je een waarde die wordt teruggegeven nadat deze procedure is uitgevoerd, in ons geval zal dit het te behalen cijfer zijn. Figuur 4.12 procedurewithresult block In het do gedeelte van de procedure kunnen we hetzelfde foreach block gebruiken als in Toevoegen.Click. De naam van de variabele zullen we wel aan moeten passen, aangezien elke naam maar eenmaal gebruikt mag worden. We beginnen met het optellen van alle resultaten. Dit kunnen we doen op een vergelijkbare manier als het aan elkaar plakken van de teksten, zoals we gedaan hebben in figuur We gebruiken nu echter hetzelfde + block als we eerder hebben gebruikt. Het tussenresultaat sla je op in een nieuw aan te maken variabele zoals is te zien in figuur Ook voor het eindresultaat maak je een variabele aan genaamd tebehalen. Gebruikmakend van de som kun je nu als volgt het te behalen cijfer berekenen: (aantalopgegevenci j f ers+ 1) 8 som Het resultaat van deze berekening moet je teruggeven door het block tebehalen aan result te hangen. Figuur 4.13 som variabele

151 34 Hoofdstuk 4 Schrandere Scholier Figuur 4.14 Implementatie van berekentebehalen Opgave 4.7 Implementeer de procedure voor het berekenen van het te behalen cijfer volgens de bovenstaande beschrijving. Uitwerking: Als het goed is ziet de procedure er nu uit zoals in figuur 4.14 is getoond. Figuur 4.15 Aanroepen van de bereken procedure De laatste stap is nu een klein stukje toevoegen zodat het te behalen cijfer wordt weergegeven. Dit doe je met de blocks in figuur Voeg deze blocks toe aan Toevoegen.Click en test de app uit! Tip Wellicht valt je op dat er ook cijfers in de lijst staan die je niet via de app hebt ingevoerd? Als dit zo is dat heb je in de Blocks Editor nog invulling staan bij het aanmaken van de lijst. Haal deze weg en probeer het opnieuw!

152 4.6 Facultatieve uitbreidingen Facultatieve uitbreidingen Je hebt ondertussen waarschijnlijk al een hoop uitbreidingen op deze app bedacht. Voeg een aantal van de onderstaande functies toe, of bedenk een eigen functie in overleg met jouw docent. Een 8 gemiddeld, Waarom geen 9? Laat de gebruiker zelf kiezen welk cijfer hij gemiddeld wil staan. Niet alle toetsen tellen even zwaar, zorg ervoor dat de gebruiker het gewicht van een toets kan bepalen. Geef de app een mooier uiterlijk. Zorg ervoor dat de cijfers worden bewaard bij het opnieuw opstarten van de app Maak de app geschikt voor meerdere vakken. Maak het onmogelijk om foutieve cijfers in te voeren. Jouw idee...

153

154 Hoofdstuk 5 Meteoor 5.1 Vooraf In dit hoofdstuk gaan we een simpel spel zelf maken. We gebruiken hiervoor de Orientation Sensor van de mobiel, die aangeeft of het apparaat rechtop gehouden wordt of gekanteld is. We bouwen het stapje voor stapje op. Allereerst verkennen we een stukje van de Orientation Sensor. Dan gaan we hiermee een zogenaamde ImageSprite aansturen, dat is een plaatje dat je makkelijk over het scherm kunt bewegen. In dit spel wordt de ImageSprite gebruikt voor een raket. De raket wordt bestuurd door de telefoon naar links of rechts te draaien. Ook worden aanwijzigingen gegeven hoe je het zonder de Orientation Sensor kunt maken, mocht je mobiel niet zo n sensor hebben of voor het geval je aan- 37

155 38 Hoofdstuk 5 Meteoor gewezen bent op de emulator van App Inventor. Vervolgens zien we hoe we meteorieten over het scherm kunnen laten bewegen die ontweken moeten worden. Door te detecteren als de raket tegen een meteoriet botst weet het programma wanneer je af bent. 5.2 De Orientation Sensor Allereerst hebben we in App Inventor een nieuw project nodig. Wij noemen het project meteoor maar je kunt zelf als je wilt een andere naam kiezen. Het eerste wat we doen is het zichtbaar maken van wat de sensor voelt. Daarvoor gebruiken we labels. Sleep drie labels (Uit het basic palette ) op het screen. Het is een goed gebruik onderdelen van je programma meteen een duidelijke naam te geven, maar deze labels gebruiken we alleen om de waarden van de sensor zichtbaar te maken, ze verdwijnen verderop weer, dus we hebben meteen een uitzondering op de regel. In het palette Sensors vind je de OrientationSensor. Sleep ook deze op het screen. Er komt OrientationSensor1 te staan onder het scherm onder de tekst: Non-visible components. Tijdens het uitvoeren van het programma is deze sensor namelijk niet zichtbaar, maar tijdens het ontwikkelen willen we natuurlijk wel ergens aan kunnen zien dat de sensor er staat. Open de Blocks Editor met de knop Open the blocks editor. Klik links op de tab My Blocks, dan in het rijtje eronder op

156 5.2 De Orientation Sensor 39 Orientation Sensor1, waardoor de mogelijkheden die we met dit component hebben zichtbaar worden. Eén ervan is een block met daarin de tekst: OrientationSensor1.OrientationChanged. Dit is een event (gebeurtenis) dat optreedt als je de mobiel draait. Als het event optreedt worden de codeblocks die in dit block geplaatst worden uitgevoerd. Sleep het block naar rechts op het programmaveld. Bovenaan het block aan de rechterkant staan drie parameters met de namen azimuth, pitch en roll. Klik onder MyBlocks op de naam van het eerste label, en sleep dan het block met de tekst set Label1.Text to in de opening in OrientationSensor1.OrientationChanged. Figuur 5.1 Het begin is er... We willen in dit label de waarde laten zien van de eerste parameter: azimuth. Deze is bereikbaar via tab: My Blocks My Definitions : sleep value azimuth naar het programmeerveld, klik hem met het puzzel-blobje aan de set Label1.Text to vast. Doe hetzelfde voor het tweede en derde label met de waarden voor pitch en roll.

157 40 Hoofdstuk 5 Meteoor Figuur 5.2 waarden Zet het programma op de mobiel en start het op. Draai het apparaat in verschillende richtingen en kijk naar de getallen. De waarde van roll is 0 als je het toestel waterpas houdt. Als je het naar links overhelt geeft dit getal aan hoeveel graden (90 als je toestel op zijn kant houdt), naar rechts ook maar dan met een min ervoor ( 90 als je het toestel op zijn kant houdt). Met wat fantasie kun je het programma dat we nu hebben al gebruiken als een soort waterpas. t Hint: Je kunt als je er niet uitkomt op internet de woorden azimuth en pitch nazoeken Opgave 5.1 Probeer zelf eens uit te vinden wat de andere twee getallen aangeven! 5.3 De raket We gaan nu een raket maken die we gaan besturen met de roll-waarde. In App Inventor kunnen de Labels voor pitch en azimuth weg. Selecteer ze één voor één

158 5.3 De raket 41 en klik daarna op de button Delete. Als je met alt+tab naar de block editor gaat zie je dat de bijbehorende blocks ook verdwenen zijn. Onder palette Animation vind je een ImageSprite. Deze willen we op het scherm laten zien. Een ImageSprite heeft echter een zogenaamd Canvas nodig om getoond te worden op een scherm. Sleep daarom een Canvas (palette Basic ) op je Screen. Klik op het Canvas zodat het geselecteerd is. In de rechterkolom op het scherm (onder Properties ) zie je een aantal eigenschappen (inderdaad: properties in het engels). De bovenste is de BackGroundColor. Door op de kleur te klikken kun je een andere kleur kiezen. Ook met de andere waarden kun je een beetje experimenteren naar behoefte. Het meest interessant voor nu zijn echter de onderste twee: Width en Height. Stel beiden in op: Fill parent.... Je ziet dat de breedte zo breed wordt als het scherm is, echter de hoogte blijft klein. Selecteer onder Components het Screen1 en zet Scrollable op uit, dan zal het Canvas gelijk hoger worden. Daarmee zijn we klaar om de ImageSprite (palette Animation ) op het Canvas te slepen. Zet hem ongeveer midden op het scherm. Dit wordt de raket. In de kolom Components helemaal onderin staat een balkje Media, met een knop Add.... Gebruik de browse-button om een plaatje van een raket toe te voegen. Wij raden aan er voor nu een te nemen uit de directory plaatjes (bijvoorbeeld raket2.jpg ), maar als je een beetje handig bent kun je zelf een ander (niet te

159 42 Hoofdstuk 5 Meteoor groot) plaatje ervoor in de plaats zetten. Experimenteer en leer... Selecteer de ImageSprite en kies rechts bij de Properties voor Picture het zojuist toegevoegde Canvas kun je nu je raket bewonde- plaatje. Op het ren. 5.4 Besturing Laten we zeggen dat we als de telefoon 45 graden naar links helt (roll = 45) de raket links op het scherm (xpositie is dan 0) moet staan, bij 45 graden naar rechts (roll = 45) rechts op het scherm. Rechts op het scherm wil zeggen dat de x-coördinaat bijna gelijk is aan de breedte van het Canvas (Canvas.Width), echter de breedte van de raket moet daar vanaf gehaald worden. Ofwel: de maximale x-coördinaat is Canvas.Width ImageSprite.Width Aangezien de waarde van deze expressie constant is slaan we deze op in een variabele, die we noemen: xmax. We hebben dan dus twee waarden van roll en twee bijbehorende waarden van de x-coördinaat: Roll x-coördinaat xmax Van wiskunde ken je het lineaire verband: we hebben twee waarden voor roll en willen een berekening (lees: functie) die de bijbehorende x-coordinaat uitrekent. Bij wiskunde zou je het opschrijven als:

160 5.4 Besturing 43 x f (x) = ax + b xmax Raak niet in de war komt doordat hier de x aan de linkerkant staat! We kunnen de technieken uit de wiskunde mooi gebruiken om de formule op te stellen. Dit kan op verschillende manieren, je hebt er bij wiskunde vast wel een geleerd. Aangezien 45 en 45 even ver aan beide kant van de y-as liggen weten we dat voor x = 0 (dus ertussenin) de f (x) ook tussen 0 en xmax (dus op 0.5 xmax ) ligt, ofwel: waaruit volgt dat: f (0) = a 0 + b = 0.5 xmax b = 0.5 xmax dus de gezochte functie ziet er uit als: f (x) = a x xmax t In de wiskunde wordt a x afgekort tot ax, maar in de informatica is dat geen handige afspraak omdat variabelen vaak een naam krijgen langer dan één letter. Door een bekende x in te vullen kunnen we de waarde van a berekenen. Opgave 5.2 Laat zien dat hier uitkomt: a = xmax/90 dus we weten: f (x) = xmax x/ xmax

161 44 Hoofdstuk 5 Meteoor of (controleer dat dit hetzelfde betekent): f (x) = (x/ ) xmax Terugvertaald naar de notatie met roll en de x- coördinaat staat er dan: f (roll) = (roll/ ) xmax 5.5 Kantelen Terug naar de situatie: we waren aan het bepalen wat er moest gebeuren als het apparaat wordt gekanteld, ofwel als event OrientationSensor1.OrientationChanged optreedt. De waarde van roll krijgen we als parameter binnen en we willen dus de x-coordinaat van de raket zetten op: (roll/ ) xmax ofwel (roll/ ) wat een optelling is van 0.5 en roll/90 Dit verkrijgen we door een deling te doen met de waarde van roll door 90. We hebben dus een vermenigvuldiging van een optelling van een deling (een hele mond vol) en de uitkomst willen we plaatsen in de x-coordinaat van de ImageSprite, dus in het block OrientationSensor1.OrientationChanged voegen we een block toe uit My Blocks, ImageSprite1,

162 5.6 xmax 45 namelijk Set ImageSprite1.x to. In het to -vak voegen we allereerst een block toe voor de vermenigvuldiging. Onder tab Built-in, als we op Math klikken, vinden we een rij blocks die met rekenen te maken hebben. De eerste hiervan die we nodig hebben is het block voor de vermenigvuldiging:, en er zitten twee openingen in waar de twee waarden of expressies in moeten die vermenigvuldigd moeten worden. Figuur 5.3 positie 5.6 xmax We zijn nu op het punt aangekomen dat we de variabele xmax nodig hebben. De definitie van een variabele gebeurt ergens op het programmeerveld: Built-in definition def variable as slepen we op het programmeerveld. Het woord variable moeten we vervangen door de naam van de variabele, in ons geval dus xmax. Klik op variable en typ xmax gevolgd door enter. Hiervan wordt eenmalig de waarde gezet op Canvas.Width ImageSprite.Width, dus een verschil (plaats een block met een - aan def xmax as, echter dat mag niet op de plek van de DEFinitie, daar

163 46 Hoofdstuk 5 Meteoor moet eerst een constante waarde in de variabele gezet worden, bijvoorbeeld 0. Figuur 5.4 global xmax In het block waar we de waarde nodig hebben gaan we de berekening doen en het resultaat zetten we in de variabele. Sleep een block set global xmax to (uit My Blocks My Definitions) naar het block OrientationSensor1.OrientationChanged, onder het commando dat de waarde van roll in de textbox zet. In set global xmax to komt een block -. In de linkse opening komt Canvas.width (het block vind je onder My blocks Canvas1), in de rechtse ImageSprite.width (vind dit onder My blocks in ImageSprite1 ). De waarde van xmax wordt nu berekend Figuur 5.5 Introductie global xmax en we gaan nu de waarde van deze variabele gebruiken in de vermenigvuldiging die we in OrientationSensor1.OrientationChanged aan het opbouwen waren. Aangezien a b gelijk is aan b a mag je zelf kiezen of je in de linker- of in de rechter opening het global xmax -block zet (dat je kunt vinden onder my blocks my definitions).

164 5.7 Geen Orientation Sensor? 47 In de andere opening komt de optelling van 0.5 en de breuk, ook hier maakt niet uit welke aan de rechterkant staat. De 0.5 krijg je door onder Math een number 123 -block te nemen en na het plaatsen op de 123 te klikken om dit te veranderen in 0.5. In het andere gat moet de deling roll/90 komen. Zoek deze blocks zelf (kun je zelf bedenken waar ze te vinden of moet je eerst alle categorieën doorklikken?). Merk op dat de blocks meteen werken als een soort haakjes: het gebouwde betekent dus echt en niet bijvoorbeeld xmax (0.5 + (roll/90)) ((xmax 0.5) + roll)/90 t Let op: De volgorde in de breuk maakt wel uit. Probeer het gebouwde programma dat je tot nu toe hebt eens uit: hou de mobiel schuin en kijk wat de raket doet. Figuur 5.6 Je kunt nu de raket besturen 5.7 Geen Orientation Sensor? Als je geen mobiel hebt loop je hier wel tegen een uitdaging aan: de Orientation Sensor test je niet zo-

165 48 Hoofdstuk 5 Meteoor t De y-waarde moet blijven wat ie was! maar uit in een emulator. Om dit op te lossen hebben we het volgende alternatief bedacht: In de block editor, in de categorie ImageSprite1 onder My Blocks vind je een block ImageSprite1.Dragged. Sleep dit block eens op het programmeerveld en kijk eens of je snapt wat het doet: hiermee is het mogelijk de raket te gaan besturen door met je vinger te draggen. Figuur 5.7 Drag de raket Als je beide manieren om de raket te sturen tegelijk ter beschikking hebt geeft dat een vreemd effect: je dragt de raket bijvoorbeeld naar links en hij gaat daar ook naar toe, maar zo gauw je de mobiel ook maar enigszins beweegt springt de raket weer terug naar de plek die door de oriëntatie bepaald wordt. Als je dit irritant vindt kun je één van de twee uitzetten. Eén manier waarop dit kan is door op block OrientationSensor1.OrientationChanged óf op block ImageSprite1.Dragged te rechtermuisklikken

166 5.8 Raket onderaan scherm 49 en dan in het contextmenu dat verschijnt Deactivate te kiezen. Vooral tijdens het ontwikkelen kan het soms handig zijn iets tijdelijk uit te kunnen zetten. Opgave 5.3 (optioneel) Als je heel handig bent kun je misschien zelfs maken (bijvoorbeeld met behulp van een CheckBox dat de gebruiker op de mobiel kan kiezen welke van de twee manieren hij wil gebruiken. 5.8 Raket onderaan scherm We hebben nu een raket gemaakt die we kunnen besturen, we komen echter nog geen obstakels tegen op onze weg door het heelal. Daar gaan we nu verandering in brengen. Maar eerst moet de raket onderaan op het scherm staan, dat wil zeggen dat de y-coördinaat maximaal moet zijn, maar wel zo dat de raket nog op de canvas staat en zichtbaar is: de waarde van de y-coordinaat moet daarom zijn: canvas.height imagesprite1.height We hebben één belangrijke vuistregel bij het programmeren tot nu toe niet goed toegepast: onze raket heeft namelijk de naam ImageSprite1, niet bepaald een duidelijke naam. Zo gauw er meerdere objecten in beeld zijn kan dat natuurlijk niet meer. We hernoemen daarom ImageSprite1 naar Raket. Selecteer hiervoor in

167 50 Hoofdstuk 5 Meteoor App Inventor ImageSprite1 (onder Components ) om het te selecteren. Een stukje eronder zie een button Rename. Klik er op en hernoem de raket naar Raket. In de Blocks Editor kun je controleren dat alles er nog staat maar dan met de aangepaste naam. Aangezien de raket altijd op dezelfde hoogte blijft hoeven we deze waarde maar 1 keer te zetten, namelijk bij het initieel opzetten van het scherm. We boffen, want tijdens het initieel opbouwen (in computertermen initializing) van het screen worden de commando s uit het block Screen1.initialize (zie My blocks Screen1 ) uitgevoerd. Zet hier een Set Raket.Y to -block in. Als je dit niet weet te vinden, zoek dan enkele bladzijden terug waar de ImageSprite1.X vandaan kwam. Bouw hier de volgende formule op: Figuur 5.8 Zet Raket onder in scherm 5.9 Obstakels De raket staat nu dus onderaan het scherm. Sleep uit het palette Animation een Ball op het canvas. Een Ball lijkt qua mogelijkheden veel op een ImageSprite, maar is zo rond als een bal. Je kunt het plaatje niet zelf uitkiezen. Hernoem ( Rename )

168 5.9 Obstakels 51 Ball1 tot Meteoor. Als je heel precies het verschil tussen een ImageSprite en een Ball wilt weten kun je in het palette op de vraagtekens rechts van de ImageSprite en Ball klikken. In het algemeen is het slim als je ergens meer van wilt weten de help te bekijken. Behalve dat je daar vaak het antwoord op je vraag vindt, vind je er veel nuttige info. Als we de meteoor willen bewegen kunnen we natuurlijk de x en y-coördinaten gaan veranderen. Als je echter de meteoor selecteert en kijkt in de rechterkolom bij de Properties kijkt zie je eigenschappen als Heading, Interval en Speed. Zet de Speed (inderdaad, de snelheid) van de meteoor eens op 40 en kijk wat er gebeurt. Het Interval staat waarschijnlijk op Dat betekent dat elke 1000 milli-seconde (inderdaad, dat is 1 seconde) de meteoor met zijn snelheid vooruit wordt gezet. Als de beweging schokkerig overkomt kun je het Interval kleiner maken. Maak er maar eens 200 van en kijk wat er gebeurt. De beweging is minder schokkerig, maar ook sneller. Welke kant beweegt de meteoor op? Opgave 5.4 Met behulp van de Heading (dit is een hoek in graden) kun je aangeven welke kant de bal op moet bewegen. Probeer het uit of lees het in de help. Pas de waarde van Heading aan zodat de bal van boven naar beneden beweegt, dus in de richting van de raket. Als alles tot zover is gelukt zie je dat het meteoorletje erg

169 52 Hoofdstuk 5 Meteoor klein is, maar als je de Radius op bijvoorbeeld 25 zet zie je dat de bal al heel wat groter is. Als het spel af is kun je uitproberen wat jouw favoriete grootte is en snelheid Meerdere meteoren Als de meteoor echter beneden is aangekomen blijft ie liggen. We willen eigenlijk dat ie dan weer van boven het scherm binnenkomt, wellicht in een andere grootte of kleur. Gelukkig helpt App Inventor ons ook hier weer uit de brand, namelijk met een event EdgeReached, dat optreedt als de bal (in het geval van Meteoor.EdgeReached, wat te vinden is onder Meteoor onder My Blocks ). Als de meteoor beneden tegen de rand aan vliegt willen we dat de y-coordinaat weer 0 is, zodat de bal weer bovenaan begint. Als je Ball1.EdgeReached op het programmeerveld sleept zie je dat deze een parameter name edge heeft. Hiermee kun je kijken tegen welke kant de meteoor gevlogen is. Aangezien wij de bal omlaag laten vliegen hoeven we niet te kijken, we weten al dat ie onder is aangekomen en boven opnieuw moet beginnen. In het block komt de code om de bal weer bovenaan het scherm te zetten. Figuur 5.9 Opnieuw boven beginnen

170 5.11 Botsing 53 Het ziet er al bijna uit als een spel. De raket beweegt echter nogal schokkerig. Verder heeft een botsing geen gevolgen en tot slot blijft de meteoor steeds op dezelfde plek naar beneden komen. Het schokkerige kunnen we een eind oplossen door de het Interval van de raket kleiner te maken, net als we bij de ball ook gedaan hebben. Klik op de raket en zet het interval op 100. Hoe kleiner het getal, hoe vaker de raket getekend wordt en dus hoe soepeler de beweging er uit ziet. Je zult echter wel snappen dat de mobiel het dan ook drukker heeft Botsing Nu gaan we kijken naar het botsen. Ook hiervoor bestaat weer een event: BlockEditor My Blocks Meteoor Meteoor.CollidedWith Het event treedt op als de Meteoor tegen een ander voorwerp botst en uit de parameter other kunnen we concluderen met welk voorwerp. Aangezien we al weten dat het de Raket is hoeven we dit niet te controleren: zo gauw het event optreedt weten we dat de Raket tegen een Meteoor geknald is. Voor nu zetten we dan de Meteoor stil, al is dat niet erg spectaculair. Sleep de code bij elkaar:

171 54 Hoofdstuk 5 Meteoor Figuur 5.10 Botsing Opgave 5.5 Hoewel in het echt in vacuüm natuurlijk geen geluid te horen is wordt het spel wel spectaculairder als je het geluid van een botsing toevoegt als de Raket tegen een Meteoor botst. Als we de meteoor succesvol ontwijken willen we dat ie op een willekeurige plek bovenin het scherm terugkomt, oftewel in het EdgeReached code-block willen we een willekeurige x-coordinaat zetten. set Meteoor.x to, onder Math vind je een random integer -block. Hierin kun je from en een to-parameter invullen. Neem From = 0 en To = xmax, de eerder door ons berekende maximale x-coordinaat (zie my blocks my definitions) die we hier handig kunnen hergebruiken. Figuur 5.11 Botsing

172 5.12 En weer verder En weer verder Als de meteoor stil staat en je klikt er op ( Meteoor.Touched ) moet het spel weer verder gaan. Er moet een nieuwe meteoor komen van boven: hiertoe moeten we de y op 0 zetten en de snelheid (die we bij de botsing op 0 hebben gezet) weer op een goede waarde. We gebruiken een willekeurige (random) waarde tussen 30 en 70. Verder moeten de meteoren allemaal hun eigen grootte krijgen, ook random (willekeurig) dus. Figuur 5.12 Botsing Het Label waar nog steeds de waarde van roll in gezet wordt kan inmiddels wel weg. Selecteer het in de screen editor en druk op delete (knop in kolom Components, rechterkant).