PRE2024 1 Group1:
Name | Student Number | Study |
---|---|---|
Naomi Han | 0986672 | CS |
Gijs Kruize | 1656882 | CS |
Tom de Leeuw | 1893904 | PT |
Morgan van Tilburg | 1557947 | EE |
Our research
A lot of research and products are already available for teaching robotics. There are both a lot of programming languages and robot types for many different age groups. We noticed however that there are no robots for preschoolers that can be programmed using text based programming languages. All programmable robots we have found are programmed using block based code, such as the Robitic Lego, or not programmable by code at al, such as the sequential robots.[1]
Problem statement
With the rapid growth in all kinds of technological fields, such as AI and engineering in cars, there is a large shortage of people with a career in technology[2]. A lot of young people do not choose for a career in technology[3]. This is partially because there is no proper introduction to technology in the education of young children.
Users/Stakeholders
There are several stakeholders for the end product of this project. The children that will interact with the simplified programming language are the first major stakeholder. Further, there are the parents of the children, as well as the teachers. Another important stakeholder are technical universities and large tech companies. Lastly there is the education system.
The children
The primary user of this technology are the children that use the product. They will need a safe and challenging learning environment for them to engage in. The product has to be interesting and fun for them, so they will pay attention to the subjects that are taught. On top of that, the product should be at a level that they can understand. The primary goal of the product is to give the children a gentile introduction to the world of programming and robotics.
The parents
The most important aspect of the product for the parents is that their children are safe. The children should not be exposed to dangerous elements in the product, such as small parts, lose wires and fast spinning motors they can get stuck in. Further, when there is an online environment in the product, their children's data should be stored in a safe space, so their data is not all over the internet. The second most important thing for the parents is that their children are actually learning something, and they get their money’s worth.
Teachers
The product should be easily integrated into the existing educational program, in order to reduce the amount of work for the teachers. Further, the product should be engaging for the student and have different difficulty levels to fulfill the individual needs of every student. On top of that, the product should be intuitive to understand for the teachers so they can answer possible questions that the students may have. This can be achieved by making a teacher’s guide that explains the program in detail.
Technical universities and large tech companies
The program is meant to encourage young children to pick a technological career path. This is done by introducing them to technology and its many different aspects at an early age. Technical universities and large tech companies have a major interest in the possible outcome of this project, since they are the ones who benefit the most.
Educational system
The educational system is the main stakeholder that decides if the product is suited for the current educational program. Again, the project should be easily integrated into the exiting educational format. Also for this stakeholder, the product has to be properly tested on classes in an ethically correct environment.
Research Question
How does a physical debugging-first approach to coding robots compare to a bottom-up coding approach in terms of students' problem-solving skills and code comprehension?
Hypothesis
Debugging is a crucial aspect of coding. Traditionally, coding education begins with learning syntax and basic programming concepts, with debugging introduced later. However, emphasizing debugging from the outset can provide coding novices with a deeper understanding of the coding process and the language they are using. This approach can also enhance their coding and problem-solving skills more effectively (Lowe, 2019)[4]. Additionally, using a robot for visual debugging can encourage experimentation and improve overall debugging skills (Grimm, 2002)[5].
Our hypothesis is that the debug group will, on average, complete one more exercise than the bottom-up approach group, as we expect them to be faster. The test group focusing on debugging will have more practice with visual debugging compared to the bottom-up group, potentially reaping greater benefits. Since both groups will need to debug errors in the final assignments, we anticipate that the group starting with debugging will have an advantage in problem-solving skills and code comprehension.
This hypothesis will be tested through surveys and classroom observations. The results will undergo statistical analysis to determine their significance, complemented by qualitative research analysis of the observations to form a comprehensive conclusion.
Test Plan
In this study, students will be divided into two groups, each using a different method to learn how to program robots.
Group 1: Physical Debugging-First Approach
Students in this group will start with incomplete or faulty code. They will:
- Run the robot and observe its behavior to identify what is going wrong.
- Physically debug by adjusting the code based on what they see happening with the robot (e.g., the robot moving in the wrong direction, not picking up objects, etc.).
- Over time, they will progress from fixing small issues to writing more substantial parts of the program themselves. However, they will always start by observing and debugging the robot's physical actions.
This approach emphasizes connecting the robot’s real-world behavior with code changes, helping students develop problem-solving skills by learning how their code affects the robot directly.
Group 2: Bottom-Up Coding Approach
This group will begin by writing code from scratch. Students will:
- Start with simple robot tasks (e.g., making the robot move in a straight line).
- Gradually build up complexity as they master each function, moving from basic actions to more complex behaviors like turning, grabbing objects, and avoiding obstacles.
- Continue building layer by layer until they can write programs to complete complex challenges.
This method focuses on systematically developing coding skills by starting from basic robot control and gradually adding more complexity to their programs.
Comparative Test Process
To compare the effectiveness of these approaches, students will go through several iterations of practice tasks followed by a standardized exam task.
- Practice Tasks: Each group will work on three tasks using their assigned method—either physical debugging or bottom-up coding. These tasks will vary in difficulty but are designed to reinforce the core learning technique of each group.
- Exam Tasks: After completing the three practice tasks, both groups will be given the same exam task. This task will be presented without any additional guidance or code aids. The exam task will require both groups to use the robot to complete a challenge, but without the specific support from their previous method (e.g., no pre-written code for the debugging group or no step-by-step build-up for the coding group).
This process will be repeated in several cycles: three practice tasks followed by one exam task. By doing this multiple times, we will collect enough data to compare how both groups perform.
Metrics for Comparison
To evaluate the two approaches, we will focus on the following key metrics:
- Number of attempts per exam task: How many tries does each group need to successfully complete the exam task?
- Time taken: How long does each group take to solve the exam task?
- Quality of the final solution: How accurate and efficient is the program they write for the robot?
- Learning progression: How do both groups improve over time? Are they able to solve exam tasks faster and with fewer attempts as they progress?
Getting a place to test
We sent the following email to elementary schools in Eindhoven, of which we already got multiple enthusiastic replies:
Onderwerp: Samenwerking voor Techniekworkshop op uw Basisschool
Geachte [Naam van school],
Wij zijn vier enthousiaste studenten van de Technische Universiteit Eindhoven en wij willen graag uw basisschool benaderen met een uniek en educatief aanbod. Ons doel is om kinderen te enthousiasmeren voor techniek door middel van een interactieve en leuke workshop.
Wij stellen voor om een middag op uw school te komen en de leerlingen in groepjes te leren programmeren met behulp van een kleine robot. Deze activiteit is ontworpen om de creativiteit en probleemoplossende vaardigheden van de kinderen te stimuleren, terwijl ze op een speelse manier kennismaken met de basisprincipes van programmeren en technologie. De kinderen hebben geen voorkennis nodig over programmeren. We richten ons op kinderen tussen de 9 en 12 jaar.
Wij zorgen voor alle benodigde materialen en begeleiding, zodat de leerkrachten zich geen zorgen hoeven te maken over de organisatie. Het enige wat wij vragen is eenmalig een middag van uw tijd en de enthousiaste deelname van de leerlingen. Zou dit mogelijk zijn in week 41 of 42?
Wij geloven dat deze workshop een waardevolle aanvulling kan zijn op het huidige curriculum en een inspirerende ervaring voor de kinderen zal bieden. Wij hopen dan ook dat u openstaat voor deze samenwerking.
Graag horen wij van u of u geïnteresseerd bent in dit initiatief en of we een afspraak kunnen maken om de details verder te bespreken.
Met vriendelijke groet,
Project Planning
During the first week the focus has been preliminary research into robotics education on preschools.
In the second week we delved deeper into similar existing resources for early childhood robotics education and formulated our research question, defined the requirements for the design of our teaching package, and created a schedule for our research and finalized the ERB and consent forms.
In the third week of our research we are going to decide on our test group, program several predefined functions and start on the frontend the preschool students are going to use. Aside from that we are also going to send out surveils to students of the PABO in Tilburg, such that we can incorporate any feedback they have.
In the fourth week the implementation of the link between the GUI and the robot shall be established.
In the 6th week of our research we will finalize the teaching environment and finish the questionnaires for the participants of the study and their caregiverst/parents.
In the beginning of the 7th week we will carry out our lessons for our target group and proccess all the data.
In the last week of our research we will present our findings.
Final Product / Research
Our final product will consist of a teaching package designed as an introductory course consisting of 2 to 3 lessons that integrate an online coding environment, a physical robot, and a comprehensive teacher manual. The curriculum will use a simplified text-based programming language, rather than a block-based one, to offer a more authentic coding experience. To make the learning process approachable for beginners, the language will include predefined functions that will gradually become less predefined in each lesson, encouraging students to take on more coding responsibilities. Each lesson will focus on key skills such as debugging, completing existing code, and writing code independently.
The inclusion of a physical robot is a deliberate choice, as it provides a tangible way to visualize the code's impact, making abstract concepts more accessible. This hands-on approach also serves as an effective method for students to learn debugging by observing the robot’s actions and correcting their code accordingly. Additionally, we will develop a coding manual tailored to the needs of teachers, particularly those who may not be familiar with coding. The manual will include clear, step-by-step instructions and explanations to ensure that teachers can confidently guide their students through the lessons.
Goal of the Study
The comparison will help us determine which method—physical debugging-first or bottom-up coding—leads to better outcomes in terms of problem-solving, code comprehension, and robot control. By tracking how both groups perform on exam tasks, we will see which approach develops stronger programming and debugging skills in students learning to control robots.
Design
The curriculum is designed according to the following MoSCoW criteria:
Must Have
- A physical robot to keep kid’s attention
- A Hedy like language as introductory programming language
- Teacher manual about the languages used, the basics of programming
- The teaching package must be affordable for schools, since not all schools have large budgets for this
- Learning steps from Physical debugging, to filling in pre-defined functions, to writing own
Should Have
- A classical part to the lessons where the coding and robotics principles are explained, and group-based challenges where the groups work on challenges to make the robot do stuff.
- Adaptive challenges based on the level of the students, if a group does well it should get harder challenges do not rush through the existing challenges
- An interactive digital learning environment where the explanations are given, and the programs are written
- The teaching package should emphasize how the robot running the program is being used in the real world, and thus show the importance of it. So, linking some challenges in the teaching program to a real-world problem that could be solved with the robot.
Could Have
- Integration with other subjects (like spelling and math)
- Translation courses for Dutch programming to English programming as a good transition to real programming languages.
- Teachers can create their own functions to diversify their class
- Play/playground functions(?)
- Wireless communications with the robot
Wont have
- Block based
- Too much preparation time for the teacher
Enquête: Lespakketten voor Robotica in het Basisonderwijs
To design the curriculum we have also sent out a questionnaire to obtain insights from the future teachers, as they can give is unique insights from an educational point of view. Since these participants were al members of the PABO study, the questionnaire was conducted in Dutch. The questionaire was made in MS Forms and the responses are anonymous. Only the first question has been made manditory, in which the students agrees to have read and accepted the terms in the consentform. The suggestions and feedback from the enquête has been incorporated in the design of the lessonplan.
Enquête: Lespakketten voor Robotica in het Basisonderwijs
Beste student, In het kader van ons onderzoek zijn wij benieuwd naar jouw mening over het ontwerp: lespakketen voor robotica in het basisonderwijs. Jouw feedback draagt bij aan ons onderzoek en helpt bij het ontwikkelen van een educatief, inspirerend en effectief lespakket.
Vul de enquête in en deel jouw ideeën en inzichten met ons. Alvast hartelijk dank voor je deelname aan dit onderzoek
1. Door deel te nemen aan deze enquete verklaar ik het Consent form te hebben gelezen en hiermee akkoord te gaan.
Deze is te vinden op:https://tuenl-my.sharepoint.com/personal/n_s_han_tue_nl1/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Fn%5Fs%5Fhan%5Ftue%5Fnl1%2FDocuments%2F0LAUK0%20%2D%20USE%20%2D%20Robots%20everywhere%20project%2FFormulieren%20en%20communicatie%2FConsentFormPabo%2Epdf&parent=%2Fpersonal%2Fn%5Fs%5Fhan%5Ftue%5Fnl1%2FDocuments%2F0LAUK0%20%2D%20USE%20%2D%20Robots%20everywhere%20project%2FFormulieren%20en%20communicatie&ga=1
Verplichte bevestiging
Informatie over de Lespakketten
In dit onderzoek willen we jouw mening vragen over twee verschillende lespakketten voor robotica-onderwijs in het basisonderwijs. In beide lespakketten zullen de leerlingen samenwerken in groepjes en zullen ze code schrijven in een versimpelde programmeertaal. Deze code zullen ze vervolgens naar de robots kunnen uploaden.
Lespakket A: In dit lespakket leren leerlingen de basis van programmeren op een gestructureerde manier, met duidelijke instructies voorafgaand aan het zelfstandig schrijven van code. Dit pakket biedt een traditionele leerbenadering waarbij leerlingen eerst grondig worden begeleid door uitleg en voorbeelden, voordat ze zelf aan de slag gaan met het programmeren van hun eigen oplossingen.
Lespakket B: In dit lespakket zullen leerlingen op een unieke manier om te leren programmeren door zich te richten op één van de belangrijkste vaardigheden in softwareontwikkeling: debuggen. In plaats van alleen maar code te schrijven, leren leerlingen hoe ze bestaande, foutieve code kunnen analyseren, fouten kunnen vinden en deze effectief kunnen oplossen.
Vragen over lespakket A
2. Wat vind je van het idee van dit lespakket in het algemeen? Denk je dat een traditionele manier van uitleg en opgaves maken goed aansluit bij de behoeften van leerlingen in het basisonderwijs?
1 (helemaal niet geschikt) tot 5 (Zeergeschikt)
3. Wat vind je van het idee van dit lespakket voor Robotica lessen specifiek? Denk je dat het goed aansluit bij de behoeften van leerlingen in het basisonderwijs?
1 (helemaal niet geschikt) tot 5 (Zeergeschikt)
4. Hoe lang zouden de theorie uitleg voor elk onderwerp moeten zijn in pakket A. (Traditioneel lesplan)
Meerkeuze: 5 min, 10 min, 15 min, anders namelijk ....
5. Wat verwacht je dat de grootste voordelen zijn van dit lespakket?
Open vraag
6. Wat verwacht je dat de grootste nadelen zijn van dit lespakket?
Open vraag
7. Heb je nog adviezen voor het opstellen van dit lessenplan?
Open vraag
Vragen over lespakket B
De volgende vragen zullen gericht zijn op het lespakket waarbij de leerlingen leren programeren door middel van debuggen.
8. Wat vind je van het idee om leerlingen te laten leren door het verbeteren van vooraf gegeven foutieve antwoorden in het algemeen? Denk je dat deze aanpak goed aansluit bij de behoeften van leerlingen in het basisonderwijs?
1 (helemaal niet geschikt) tot 5 (Zeergeschikt)
9. Wat vind je van het idee om leerlingen dit lessenplan toe te passen voor Robotica lessen specifiek? Denk je dat deze aanpak goed aansluit bij de behoeften van leerlingen in het basisonderwijs?
1 (helemaal niet geschikt) tot 5 (Zeergeschikt)
10. Hoe lang zouden de theorie uitleg voor elk onderwerp moeten zijn in pakket B. (Debug lesplan)
Meerkeuze: 5 min, 10 min, 15 min, anders namelijk ....
11. Wat verwacht je dat de grootste voordelen zijn van dit lespakket?
Open vraag
12. Wat verwacht je dat de grootste nadelen zijn van dit lespakket?
Open vraag
13. Heb je nog adviezen voor het opstellen van dit lessenplan?
Open vraag
Vergelijkingen tussen de twee lessenpakketten.
De volgende vragen zullen zich richten op het verschil tussen Lespakket A (Traditioneel lesplan) en Lespakket B (Debug lesplan)
14. Welk lespakket denk je dat leerlingen het meest enthousiast worden? Geef toelichting waarom je dit denkt.
Open vraag
15. Van welk lessenpakket denk je dat de leerlingen het meeste leren? Geef toelichting waarom je dit denkt.
Open vraag
16. Zijn er nog onderwerpen die we niet hebben besproken, maar waarover je graag iets zou willen delen?
Open vraag
Bedankt voor je hulp!
The robot
For the robots, robots of the old curriculum DBL Venus Exploration course are borrowed. These have some flaws and thus need to be debugged before usage. The robot is equipped with servos for the wheels, encoders on those wheels, a gripper to grab items and an ultrasound sensor to detect obstacles in front of it. It has an Arduino Uno on it. It originally also comes with a ZigBee wireless communication module, but this one will not be used for this project since it only makes communication between robots possible and not with the computer.
Next to this existing robot, we would like to add a Bluetooth module to the robot so it can be wirelessly updated with the code. For this we are looking into the Bluetooth HC-05 module RF transceiver Master en Slave that can be bought for €11,- at TinyTronics, a local electronics store in Eindhoven. With this module it would be possible to upload the code wirelessly. This would decrease the waiting time for the children since they are not allowed to plug in the robot themselves. After thoroughly trying to make this method work, we sadly had to come to the conclusion that for this project we were unable to do this. Thus the robot was wired while uploading with and USB-B to USB-A cable to the laptop.
With all this equipment the robot can do the following things: Drive forward, make turns (left, right, at certain degrees), stop, detect objects in front of it, grab objects, place objects back.
The web interface
For the web interface we have created for the student is grouped by subject.
We have two different interfaces for each of the testgroups with the same style and lay-out. To appease to the age-group we have tried to make the design suited for children by incorporating vibrant colors, minimizing empty space and making most objects rounded, while still being suitable for educational settings by keeping the collors, although vibrant still in the same collor pallet and making the patterns repatative.[6] The design is kept simple and intuitive, both for students and teachers.
Exercises
For both the groups the goal of the exercises will be similar. The debug group will however get faulty code while the other group will start writing from scratch.
These exercises are the following:
Exercise | Explanation of the exercises | What is wrong in the faulty code |
---|---|---|
practise exercise 1, driving forward | Drive the robot forward by 25 cm | The robot only moves forward by 10 cm |
practise exercise 2, driving forward | Make the robot drive forward, turn left, drive forward, turn clockwise until you get back to the route you were on and drive it back to the first spot | The robot makes the first turn to the right, when moving clockwise it has one turning left in there. |
practice exercise 3, turning | Make the robot go forward, turn left, drive forward, turn left and then make the robot go backwards over this same route | The robot does the backward route (turning right twice) without going backwards (forgot the minus in the forward) |
Exam exercise driving | Follow the route on the A0 sheet | (No code is given) |
practice exercise 5, obstacle detection | There is an obstacle(their own hand) in 20 cm, the robot stops 10 cm before the hand | The robot is programmed to stop 20 cm before the obstacle |
practice exercise 6, obstacle detection | There is an obstacle(their own hand) in 20 cm, the robot stops 10 cm before the hand | The robot starts driving backwards instead of stopping |
practice exercise 7, moving object | Open the arms for 2 seconds | The robot only opens them for 1 second |
practice exercise 8, moving object | Open the arms for a second, close them for a second, open them for a second, close them for a second, drive forward for 20 cm | The robot does this in the wrong order (open, closed, closed, open, drive forward) |
Exam exercise obstacle detection and moving objects | Drive the route on the A1 sheet with obstacle detection while picking up and delevering an object | (No code is given) |
Map
We also created a map on A0 where the robot could drive on. The students had to measure the distances themselves and then code this into the robot so it could follow the route. The idea was that the robot had to drive to checkpoint and then drive backward to the point where it should go right. This to simulate a dead end and practice the driving backwards.
Survey
The survey is designed according to the MCC Survey Guidelines[7]. Further it is adjusted to suit the target group, in this case children between the ages of 9-12. This means that language is simplified and more images are added in order to make the questions clearer to understand. Also the same question is asked multiple times with different phrasings, in order to prevent ambiguous question biases. The questions are in a random order to prevent question order bias.
1 = Helemaal niet mee eens | 2 = niet mee eens | 3 = niet helemaal mee eens | 4 = ik ben neutraal | 5 = een beetje mee eens | 6 = mee eens | 7 = helemaal eens |
The questions are as follows:
Hoe oud ben je?
Wat is je groepsnummer?
Ik heb ervaring met coderen.
1. Wanneer ik een nieuw stuk code zie, kan ik uitleggen wat het doet zonder het te testen.
2. Wanneer de robot zich niet gedraagt zoals ik wil, kan ik meestal ontdekken wat het probleem is.
3. Ik denk dat het testen van de robot mij heeft geholpen de code beter te begrijpen.
1. Ik denk dat ik beter ben geworden in coderen tijdens dit project.
1. Als ik de code zie, weet ik precies wat de robot gaat doen.
1. Ik begrijp het doel van elk onderdeel van de code die ik heb geschreven of mee heb gewerkt.
2. Ik denk dat ik elk probleem dat komt door de code van de robot kan oplossen.
1. Ik denk dat ik beter werd in coderen na elke opdracht
2. Ik kan een groot probleem meestal opdelen in kleinere stappen.
2. Ik probeer verschillende oplossingen wanneer mijn code niet werkt zoals verwacht.
3. Ik vind het fijn wanneer ik mijn code kan testen om te zien of deze correct werkt.
1. Het is gemakkelijk voor mij om te begrijpen wat de code doet.
3. Wanneer ik de code verander, weet ik wat de robot gaat doen.
2. Wanneer ik een probleem tegenkom in de code, kan ik meestal zelf de oplossing vinden.
The questions are divided in 3 categories as can be seen by the number in front of them. Category 1 questions are about understanding the code, category 2 questions are about problem solving skills and the 3rd category are questions about the learning process. The only question that has no category is about their prior knowledge.
Lesson plan
The lesson plans are created in by the template "Lesvoorbereidingsformulier vakdidactiek fysica KU Leuven by Nils van Dessel.[8]" This lessonplan is in Dutch, therefor the following paragraph is also in Dutch.
Lesplan op basis van debugging
Identificatiegegevens
Naam: Naomi Han, Gijs Kruize,
Tom de Leeuw, Morgan van Til- burg |
Start op: 10:30 | Duur: 1.5 uur | School: Basisschool Rapenland |
Schooltype: Basis onderwijs | Lokaal: Klaslokaal met Digibord | Aantal lln.: 24 | Graad, jaar en studierichting: Groep 7 |
Lesgegevens
Schoolvak: | Roboticales |
Lesonderwerp: | Robot programeren met behulp van versimpelde codeertaal |
Leerplannummer en onderwijskoepel: | De leerlingen zullen door middel van debuggen leren hoe ze zelf code kunnen schrijven. |
Gevolgd leerboek: | n.v.t. |
Andere bronnen: | Digitale leeromgeving waar de leeringen in zullen programmeren. |
Bijlagen bij de lesvoorbereiding: | Github: , wiki: https://dsdwiki.wtb.tue.nl/wiki/PRE2024 1 Group1: |
Verwachte voorkennis bij de leerlingen
Er is geen voorkennis. De school heeft aangegeven geen robotica te geven in hun techniek curriculum
Situering in lessenreeks
Dit is een individuele gastles.
Andere aspecten van de beginsituatie
(organisatie van het leslokaal, aard van en/of diversiteit in de klasgroep, attitudes, andere aspecten die om aandacht vragen en/of van belang zijn voor het lesverloop)
De leerlingen hebben eerst pauze. De kinderen zullen van tevoren verteld zijn over deze gastles. Het klaslokaal zal van tevoren opgezet worden, waarna de kinderen daarna pas binnen komen. De leerlingen zullen in groepjes gaan zitten. Elk groepje bestaat uit 4 of 5 kinderen, waarbij gestreefd wordt om zo veel mogelijk groepen van 4 te vormen.
Benodigdheden en materiaal
(Voorbereiding voor aanvang van de les, veiligheidsvoorzieningen, didactisch materiaal...)
Elk groepje zal een laptop nodig hebben die al van tevoren is ingesteld. Daarnaast heeft elk groepje een robot tot zijn beschikking, met een parcours uitgeprint op papier met kartonnen obstakels. Elk groepje heeft ook hulpbladen voor het programeren tot zijn beschikking.
Lesindeling
Onderdeel | Duur | Rol van de leraar | Media | Onderwijsactiviteit leerkracht Werkvormen en didactische principes | Leeractiviteit leerlingen
(Bij voorkeur niveau Bloom en aspecten CD aangeven) |
Lesopening | 10:30-
10:35 |
Gastheer | geen | De klas tot rust roepen en de aandacht vragen | Plaats nemen en stil zijn. |
Introductie | 10:35-
10:40 |
Presentator | Whitebord/
beamer |
Toelichten onderwerp, tevens enthousiasmeren | Actief meedoen in conversatie. |
Theorie robot | 10:40-
10:45 |
Didacticus | Whitebord/
beamer |
Algemene uitleg over de robot geven | Aandachtig luisteren |
Theorie fout op-
sporingscyclus |
10:45-
10:50 |
Didacticus | Whitebord/
beamer |
Uitleg geven over debuggen aan de hand van de
foutopsporingscyclus |
Aandachtig luisteren, meeschrijven op werkblad
foutopsporingscyclus |
Debug-opdracht
1 |
10:50-
11:00 |
Didacticus/
Pedagoog |
Robot, laptop | Rondlopen, vragen beantwoorden, leerlingen
helpen bij het doorlopen van de foutopsporings- cyclus. |
In groepsverband ”opdracht 1 Bewegen” maken |
Eind-opdracht 1 | 11:00-
11:15 |
Didacticus/
Pedagoog |
Robot,
laptop |
Rondlopen, vragen beantwoorden, leerlingen
ondersteunen bij het leerproces. |
In groepsverband ”opdracht 1 Parcours” maken |
Omschakelen | 11:20-
11:25 |
Presentator | geen | Klasikaal terug de aandacht pakken. Volgende
opdracht introduceren |
Aandachtig luisteren |
Debug-opdracht
2 |
11:25-
11:35 |
Didacticus/
Pedagoog |
Robot,
laptop |
Rondlopen, vragen beantwoorden, leerlingen
helpen bij het doorlopen van de foutopsporings- cyclus. |
In groepsverband ”opdracht 2 Obstakel ” |
Eindopdracht 2 | 11:35-
11:50 |
Didacticus/
Pedagoog |
Robot,
laptop |
Rondlopen, vragen beantwoorden, leerlingen
helpen bij het doorlopen van de foutopsporings- cyclus. |
In groepsverband ”opdracht 3 Wegversperring” |
Afsluiting | 11:50-
12:00 |
Afsluiter | geen | De lesstof afsluiten, herhalen wat we vandaag
hebben gedaan en enquêtes uitdelen |
enquêtes maken |
Visualisering van de inhoud en structuur van de les. Voeg een bordschema toe als dat relevant is.
(Indien specifiek van toepassing. Vaak zullen deze elementen opgenomen zijn in de bijgevoegde presentatie.)
Er zal een powerpoint en werkbladen worden gedeeld. Verder is er een parcours voor de robot op A1 formaat voor elk groepje.
Evaluatie
(Hoe wordt de onderzoeksvraag en hypothese beantwoord. Op welke manier worden gegevens voor het onderzoek verzameld?)
Aan het einde van de les zullen enquêtes worden uitgedeeld over hun ervaringen met de gastles. Er zullen ook observaties worden uitgevoerd, tijdens de les.
Lesplan traditionele lesstructuur
Identificatiegegevens
Naam: Gijs Kruize,
Tom de Leeuw, Morgan van Til- burg |
Start op: 13:00 | Duur: 1.5 uur | School: Basisschool Rapenland |
Schooltype: Basis onderwijs | Lokaal: Klaslokaal met Digibord | Aantal lln.: 24 | Graad, jaar en studierichting: Groep 7 |
Lesgegevens
Schoolvak: | Roboticales |
Lesonderwerp: | Robot programeren met behulp van versimpelde codeertaal |
Leerplannummer en onderwijskoepel: | De leerlingen zullen leren hoe ze zelf code kunnen schrijven. |
Gevolgd leerboek: | n.v.t. |
Andere bronnen: | Digitale leeromgeving waar de leeringen in zullen programmeren. |
Bijlagen bij de lesvoorbereiding: | Github: , wiki: https://dsdwiki.wtb.tue.nl/wiki/PRE2024 1 Group1: |
Verwachte voorkennis bij de leerlingen
Er is geen voorkennis. De school heeft aangegeven geen robotica te geven in hun techniek curriculum
Situering in lessenreeks
Dit is een individuele gastles.
Andere aspecten van de beginsituatie
(organisatie van het leslokaal, aard van en/of diversiteit in de klasgroep, attitudes, andere aspecten die om aandacht vragen en/of van belang zijn voor het lesverloop)
De leerlingen hebben eerst lunchpauze. De kinderen zullen van tevoren verteld zijn over deze gastles. Het klaslokaal zal van tevoren opgezet worden, waarna de kinderen daarna pas binnen komen. De leerlingen zullen in groepjes gaan zitten. Elk groepje bestaat uit 4 of 5 kinderen, waarbij gestreefd wordt om zo veel mogelijk groepen van 4 te vormen.
Benodigdheden en materiaal
(Voorbereiding voor aanvang van de les, veiligheidsvoorzieningen, didactisch materiaal...)
Elk groepje zal een laptop nodig hebben die al van tevoren is ingesteld. Daarnaast heeft elk groepje een robot tot zijn beschikking, met een parcours uitgeprint op papier met kartonnen obstakels. Elk groepje heeft ook hulpbladen voor het programeren tot zijn beschikking.
Lesindeling
Onderdeel | Duur | Rol van de leraar | Media | Onderwijsactiviteit leerkracht Werkvormen en didactische principes | Leeractiviteit leerlingen
(Bij voorkeur niveau Bloom en aspecten CD aangeven) |
Lesopening | 13:00-
13:05 |
Gastheer | geen | De klas tot rust roepen en de aandacht vragen | Plaats nemen en stil zijn. |
Introductie | 13:05-
13:10 |
Presentator | Digibord/
beamer |
Toelichten onderwerp, tevens enthousiasmeren | Actief meedoen in conversatie. |
Theorie robot | 13:10-
13:15 |
Didacticus | Digibord/
beamer |
Algemene uitleg over de robot geven | Aandachtig luisteren |
Voorbeeld
programmeer opdracht |
13:15-
13:20 |
Didacticus | Digibord/
beamer |
Voordoen van de voorbeeld programmeer op-
dracht. |
Luisteren, aantekeningen maken |
Oefenopdracht
1 |
13:20-
13:45 |
Didacticus/
Pedagoog |
Robot, laptop | Rondlopen, vragen beantwoorden, leerlingen bij
problemen in het programmeren |
In groepsverband ”opdracht 1 Bewegen” |
Eind-opdracht 1 | 13:45-
14:05 |
Didacticus/
Pedagoog |
Robot, laptop | Rondlopen, vragen beantwoorden, leerlingen
ondersteunen bij het leerproces. |
In groepsverband ”opdracht 1 Parcours” maken |
Omschakelen | 14:05-
14:10 |
Presentator | geen | Klasikaal terug de aandacht pakken. Volgende
opdracht introduceren |
Aandachtig luisteren |
Oefenopdracht
2 |
14:10-
14:25 |
Didacticus/
Pedagoog |
Robot, laptop | Rondlopen, vragen beantwoorden, leerlingen bij
problemen in het programmeren |
In groepsverband ”opdracht 2 Obstakel ” |
Eindopdracht 2 | 14:25-
14:45 |
Didacticus/
Pedagoog |
Robot, laptop | Rondlopen, vragen beantwoorden, leerlingen
helpen bij het doorlopen van de foutopsporings- cyclus. |
In groepsverband ”opdracht 3 Wegversperring” |
Afsluiting | 14:45-
14:55 |
Afsluiter | geen | De lesstof afsluiten, herhalen wat we vandaag
hebben gedaan en enquêtes uitdelen |
enquêtes maken |
Visualisering van de inhoud en structuur van de les. Voeg een bordschema toe als dat relevant is.
(Indien specifiek van toepassing. Vaak zullen deze elementen opgenomen zijn in de bijgevoegde presentatie.)
Er zal een powerpoint en werkbladen worden gedeeld. Verder is er een parcours voor de robot op A1 formaat voor elk groepje. FOTO VAN DE WERKBLADEN TOEVOEGEN NA MAANDAG!!!!
Evaluatie
(Hoe wordt de onderzoeksvraag en hypothese beantwoord. Op welke manier worden gegevens voor het onderzoek verzameld?)
Aan het einde van de les zullen enquêtes worden uitgedeeld over hun ervaringen met de gastles. Er zullen ook observaties worden uitgevoerd, tijdens de les.
Research Findings & Results
In this sections we will be discussing how our research has gone, and what our findings are from the testing day. For this we will start with the observations of the two different lessons we have given.
Observations
Results of surveys
Quantitative results of the programming website
The goal of programming in a web interface was to be able to keep track of certain statistics for the group's progress. As mentioned in the observations the lesson for the first strategy did not really go to plan. This ment that students of the first group did not really came far when you look at the given assignments. Either way we will compare some statistics between strategy 1 (debugging) and strategy 2 (building code up). The most valuable quantitative comparisons we can me make is comparing the average submission count and time spent per assignment between the two strategies.
Observations of results
Due to the low amount of data (which has turned out lower as aspected) it is hard to draw conclusions from these results. One thing we can see for shure is that the second strategy has more submissions for assignment 3 and 4 since more groups reached those assignments in the given time.
For the differences in submission counts one could argue that a lower amount of submissons could mean that the group has done it in less tries thus understands it better. On the other hand one could argue that more tries means that the children are more actively working on the assignments
For the first two assignments we can clearly see that the the second strategy on average takes quite a bit less time then strategy 1. For the latter two assignments this is not clearly visible, in contradict the first strategy is even quicker on average. This is not full picture, looking at the amount of submissions we can see these significantly drop for strategy 1, also confirmed by the observations not as many groups had time to seriously make the last two assignments.
So a really far sighted observation can be that overall strategy 2 took less time on average for the students to get to an answer for the assignment.
Conclusion
Discussion
Dit moet nog onderbouwd worden uit de observations
In our final testing setup almost al translation to standardised functions for the Arduino happened locally on the Arduino, this ment that the code file downloaded by the website was almost the same as what they have learned. This in combination with the fact that downloading the code and uploading it to the Arduino took quite a bit of time and was a rather hard task for the students to perform. Some groups started correcting their code in the arduino software. This had an effect on our test results, since we could only do quantitative testing on results generated by our website.
A solution to this is to do the translation on the website side of the code, therefore the code the children can see in the Arduino software is not something they have learned. As they don't have the understanding of the code they see, they are forced to the familiar which is our website.
Dit is misschien meer een aanrader voor volgend onderzoek
We where not able to implement wirelessly sending our code to the robots, our first alternate option was bluetooth which unfortunately we did not get to work in time. But in an ideal case our teaching portal (which ran on a local server) should have been able to send the code directly to the correct robot, this would have free'd up a lot of time for the students to actually write code instead of tinkering about with getting the code on the robot.
nog een recommendation
Our teaching portal in fact was quite dumb, meaning it simply converted code and spit it out. This meant that groups got their first compilation check in the Arduino software, then needing to go back to the teaching portal editing their code, downloading it again, and loading it into the Arduino software before they could check it again. This, being demotivating for students, could be easily solved by doing a simple compilation check for thing that are not in the system children/non-programmers like
- Indentations
- Opening and closing brackets {}
- And semicolons ;
Although these where included in the body that where pre-filled in the assignments, students really only looked at the lines of code.
nog een reccomendation --> simpelere syntax
While the debug group was given code quite similar to the working code they quite often removed all the code to start writing what they thought was the code. For example for turning there was "draai(links);", the students would however remove this and write "[rechts]". This however was also the case for the bottoms-up approach group that would just write "[rechts]" instead.
If the group would have gotten more time they would have been able to do more exercises and find more use in the faulty code given.
Overview of existing research
Overview of existing resources for early childhood robotics education
Programming languages for kids
There are all different types of programming languages catered to children. In these programming languages we can make the distention between text based programming languages and block based programming languages.
Block based programming languages
A block based programming language is a of visual programming by using blocks. These coding blocks can be dragged and dropped after each other to create a program. The absence of written code eliminates any syntax errors from arising. The visual aspect of this teaching method makes it especially suitable for young children. Scratch[9] and Blockly[10] are some of the most populair programming languages of this type, but there are also other such as Tynker[11] a website that contains games, blockbased programming and text based programming languages all in the same interface, trying to engage children by presenting it as a game.
Text based programming languages
There are also a lot of text based programming languages for children. There are both text based languages specially made for children as well as normal programming languages with tutorials for children. With the latter, the main issue for educating children is the language barrier. Since nearly all programming languages are in English, there is a language barrier for children who do not master English to a sufficient level. In the Netherlands only in 1.6% of the households English is the primarily spoken language[12], therefor this is not a viable option for most preschool children. However, the programming languages for children such as Hedy[13] are often translated in many different languages. This in combination with lessons catered specifically aimed at children, leads to a higher popularity amongst the texted based programming languages for children.
Robots for children
Sequential robots
A type of robots made for children from ages 5-8 years are sequential robot. These robots do not need any code from the children, but make use of buttons. Once these buttons are pressed in a specific order, the robot will move according to the defined sequence. Some examples of these types of robot are BEE-bot[14] and Code & Go Programmable Robot Mouse[15]
Arduino based robots
There are multiple robots such as mBot[16] which are Arduino based. These are easy to assemble and are often programmed using block based languages like Scratch. The usage of Arduino chips, allows the robots to be relatively cheap. These Arduino’s make them also more fragile for young kids than other alternatives on the market.
Robotic LEGO
The toycompany LEGO has developed 2 different lines of robotic LEGO, LEGO Spike[17] and the Lego Mindstorms[18]. The first one is created for educational use with builds for all different age groups, whereas the second is mainly for personal use. Both series allow you to build your robot and program it using block based programming. LEGO differentiates itself from other robots due to being easily build and reusable multiple times. These products allow the children to learn more about both the coding of the robots, as well as the building.
Research papers
An Evaluation Framework and Comparative Analysis of the Widely Used First Programming Languages[19]
This paper looks at a framework to assess the suitability of widely used first programming languages (FPLs), where they consider both technical and environmental factors. This study doesn’t find a perfect language that meets all their criteria. Their framework, however, can guide educators in making an informed decision about which FPL to pick.
Non-Native English Speakers Learning Computer Programming: Barriers, Desires, and Design Opportunities[20]
In this paper, the challenges of non-native English speakers in learning computer programming are described. They found that non-native English speakers struggle with reading and writing code, understanding technical materials, and simultaneously learning both English and programming. The paper recommends that a learner-centred approach be taken for these non-native speakers. This should incorporate bilingual programming tools, more visual aids, culturally neutral examples and simplified English.
Teaching Coding to Children: A Methodology for Kids 5+[1]
This paper talks about teaching kids how to code and which parts of coding are essential to learn first. There are already methods for learning kids programming like Scratch and Tynkers but these would lack comprehensive methodologies for effectively teaching fundamental coding concepts. The paper suggest to start the learning process with algorithms, loops and if-conditionals.
Transitioning from Block-Based to Text-Based Programming Languages[21]
This paper looks at what happens at the switch from block-based programming to text-based programming languages. It describes how block-based languages lower the barrier to learning programming since they eliminate syntax complexities. Transitioning from a block-based language to a text-based language comes with challenges like reduced confidence and incorrect programming habits. Which in return might discourage students from using syntax-heavy languages. They would recommend letting block-based programming languages have a form of automatic syntax placement so it would automatically teach syntax.
Visual programming languages integrated across the curriculum in elementary school: A two year case study using “Scratch” in five schools[22]
This study follows 107 primary school students using a programming language called Scratch for 2 years. This research demonstrates that the implementation of creative computing showed that using a visual programming language (VPL) actively improves a student’s grasp of programming concepts, logic, and computational practices. It highlights that students effectively learned about sequences, loops, parallelism, and events in programming.
Programming experience promotes higher STEM motivation among first-grade girls [23]
In this paper demonstrates that early exposure to programming can significantly boost girls interest in tecnology-related fields like computer science and engineering. The study found that only a brief experience with programming robots reduced the gender gap in technology motivation. It however didn't alter existing gender stereotypes about programming and robotics.
The Effects of Gender Role Stereotypes in Digital Learning Games on Motivation for STEM Achievement[24]
This study investigated how different gender depictions of a scientist in digital learning games affect STEM-based learning motivations among various age groups. It found that younger children were more affected by the traditional view of scientists, very masculine men and less feminine women. Older children were influenced more by the sex of the scientist. According to the study, personalising characters in these games might help lessen the impact of these stereotypes while also increasing interest in STEM disciplines among kids from diverse backgrounds.
Debugging behaviors of early childhood teacher candidates with or without scaffolding[25]
This study has looked at the how preschool teachers learn how to code with and without the scaffolding method. The scaffolding method is a teaching strategy where support is provide and slowly decreased the further in education goes. In this research the group taught via scaffolding, were using a hypothesis based approach in the debugging, where when stuck, the participants of the study had to form 3 possible hypotheses of why the code was not running. Besides having to try to answer these questions, the instructors were less quick to help out these participants. In the second test group without scaffolding, the participants where not asked to formulate hypotheses for why the code was not running and where given more direct solutions from the instructors while stuck. The research showed that the first group with scaffolding methods, tried for longer to fix their code and gave up less quickly. Even though the research was quite interesting and a good possibility to use going forward, it is important to note that the entire test group was rather small and did also have 2/18 participants with prior knowledge of coding.
Developing preschool children’s computational thinking with educational robotics: the role of cognitive differences and scaffolding[26]
In this paper, the researchers used aa BEE-Bot to test different teaching strategies in robotic teachings. They looked at the impact of two different scaffolding methods on both field dependent (FD) and field independent (FI) students.[27] The participants where divided amongst 3 groups. Two of the groups where using scaffolding methods and a third control group. Each group had a equal distribution of both FI and FD students. While there was not much difference noted between the two different scaffolding groups, both groups performed better than the control groups while using the scaffolding aids. When these aids where removed, there was not much difference between the FI students of the scaffolding groups or the control group. The FD students of the scaffolding groups did much worse than the FD students after the aid was removed.
“CREA”: An Inquiry-Based Methodology to Teach Robotics to Children[28]
This paper is about the CREA-methodology, an inquiry-based approach to teaching programming and robotics to children. It focusses on hands-on activities with visual programming tools like Visualino and was tested on an international primairy school in Barcelona. CREA consists of six sessions where students observe, analyze, and program robots, promoting problem-solving, teamwork, and creativity. Although some found Arduino’s syntax challenging, most appreciated the discovery-based learning and collaborative nature of the sessions. The paper has shown that this method increases the understanding from the children.
Hours log
Week 1
Who | What | Hours |
Gijs | Research (2h), Meetings&Lecture(2+2h) | 6 |
Morgan | Research (9h), Meetings&Lecture(2+2h) | 13 |
Naomi | Research (7h), Meetings&Lecture(2+2h), Administrative(0.5h) | 11.5 |
Tom | Research (7h), Meetings&Lecture(2+2h) | 11 |
Week 2
Who | What | Hours |
Gijs | Research (3h), Writing out final product (1h), Testplan (1h) , Research on software systems (2h) Meetings(1+4h) | 12 |
Morgan | Research (4), Meetings(1+4h), talking to teachers(1h), final product(1h), Arranging Robots(1h) | 12 |
Naomi | Research (5.5h), Meetings(0.5+4h), Consent forms + ERB (3h), Wiki (3h), Working out research plan (2h) | 18 |
Tom | Research (4h), Meetings(1+4h), wiki (1.5h), planning (2h) | 12.5 |
Week 3
Who | What | Hours |
Gijs | Meetings(1+4h), Setting up backend env local (3h), setting up frontend env local (1.5h), research in systems (3.5h) | 13 |
Morgan | Meetings(1+4h), making and researching pre-defined functions(4h), writing email to elementary schools(0.5h), editing wiki (0.5h) | 10 |
Naomi | Meetings (1+4h), wiki +research (3h) (ill since weekend) | 8 |
Tom | Meetings (1+4h), wiki + research (1h), contact with schools (3h) | 9 |
Week 4
Who | What | Hours |
Gijs | Meetings(1+4h), Software research (1.5h), programming (2.5h) | 9 |
Morgan | Meetings(1+4h+0.5), debugging physical robot (3h), writing pre-defined functions (4h), researching wireless transfer of program and the items (1h) | 13.5 |
Naomi | Meetings(1+4+0.5+0.5h) + enquite (1h) (still ill during the week) | 6 |
Tom | Meetings(1+4+0,5h) + contact with schools (2h) | 7,5 |
Week 5
Who | What | Hours |
Gijs | Meetings(1+4h), Software research (1.5h), programming (2.5h) | 10 |
Morgan | Meetings(1h+4h+2h)+ writing more pre-define functions (2h) +starting on connecting wireless transfer (1h) | 10 |
Naomi | Meetings(1+4+2h) + Frontend (8h) + enquêtes(1h) + Wiki (nog te doen voor deadline deze week) | 16 |
Tom | Meetings(1+4+2h) + contact with school (1h) + creating new research questions (1h) + research (1h) | 10 |
Week 6
Who | What | Hours |
Gijs | Meetings(1+2+1h) | |
Morgan | Meetings(1+2+1h)+ working on the bluetooth module(3+3+3+5h), design and write code for the exercises (2h) + wiki (1.5h) | 21.5 |
Naomi | Meetings(1+2+1h) + Lesplan (5h) + enquêtes(0.5h) + Ontwerpen opgaves (2h) + Werkblad (1h) + Wiki (1h) | 13.5 |
Tom | Meetings(1+2+1h) |
Week 7
Who | What | Hours |
Gijs | Testing at the school(3h+2h) | |
Morgan | Testing at the school(2h+2h), debugging the robots (6h), preparing laptops (3h), making and printing the final exercise sheet on A0 (2h), writing different exercises and the codes(4h), preparing presentation for the school (1h), meeting(1+1h), wiki (2h) | 22 |
Naomi | Testing at the school(3h) | |
Tom | Testing at the school(3h+2h) |
Reference list
- ↑ 1.0 1.1 Kaplancali, U. T. (2017). Teaching Coding to Children: A Methodology for Kids 5+. International Journal of Elementary Education, 6(4), 32. https://doi.org/10.11648/j.ijeedu.20170604.11
- ↑ Engelhardt, A. (2023, July 21). Shortage of skilled workers in mechanical engineering. Encoway. https://www.encoway.de/en/blog/skilled-worker-shortage-in-machine-building/
- ↑ Edgar, G. (2022, March 8). Why young people are being put off a career in tech - Diversity in Tech. Diversity in Tech. https://www.diversityintech.co.uk/why-young-people-are-being-put-off-a-career-in-tech/
- ↑ https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9028699
- ↑ https://onlinelibrary.wiley.com/doi/pdfdirect/10.1111/j.1939-7445.2002.tb00078.x
- ↑ https://motionmill.com/2021/11/website-ontwerpen-voor-kinderen/
- ↑ https://www.mesacc.edu/sites/default/files/pages/section/about-mcc/research-planning/MCCSurveyGuidelines.pdf
- ↑ https://www.overleaf.com/latex/templates/lesvoorbereidingsformulier-vakdidactiek-fysica-ku-leuven/jfckfnfrmjty Nils Van Dessel
- ↑ https://scratch.mit.edu/
- ↑ https://blockly.games/
- ↑ https://www.tynker.com/
- ↑ Schmeets, H., Cornips, L. (2021), Talen en dialecten in Nederland.Centraal Bureau voor de Statestiek. https://www.cbs.nl/nl-nl/longread/statistische-trends/2021/talen-en-dialecten-in-nederland
- ↑ https://www.hedycode.com/
- ↑ https://b-bot.nl/educatieve-robots/bee-bot
- ↑ https://www.learningresources.co.uk/stem-code-gotm-robot-mouse
- ↑ https://www.makeblock.com/pages/mbot-robot-kit
- ↑ https://spike.legoeducation.com/
- ↑ https://en.wikipedia.org/wiki/Lego_Mindstorms
- ↑ Farooq, M. S., Khan, S. A., Ahmad, F., Islam, S., & Abid, A. (2014). An evaluation framework and comparative analysis of the widely used first programming languages. PLoS ONE, 9(2), e88941. https://doi.org/10.1371/journal.pone.0088941
- ↑ Guo, P. J. (2018). Non-Native English speakers learning computer programming. CHI ’18: Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3173574.3173970
- ↑ Moors, L., Luxton-Reilly, A., & Denny, P. (2018). Transitioning from Block-Based to Text-Based Programming Languages. 2018 International Conference on Learning and Teaching in Computing and Engineering (LaTICE). https://doi.org/10.1109/latice.2018.000-5
- ↑ Sáez-López, J., Román-González, M., & Vázquez-Cano, E. (2016). Visual programming languages integrated across the curriculum in elementary school: A two year case study using “Scratch” in five schools. Computers & Education, 97, 129–141. https://doi.org/10.1016/j.compedu.2016.03.003
- ↑ Master, A., Cheryan, S., Moscatelli, A., & Meltzoff, A. N. (2017). Programming experience promotes higher STEM motivation among first-grade girls. Journal of Experimental Child Psychology, 160, 92–106. https://doi.org/10.1016/j.jecp.2017.03.013
- ↑ Hawkins, I., Ratan, R., Blair, D., & Fordham, J. (2019). The effects of gender role stereotypes in digital learning games on motivation for STEM achievement. Journal of Science Education and Technology, 28(6), 628–637. https://doi.org/10.1007/s10956-019-09792-w
- ↑ Kim, C., Vasconcelos, L., Belland, B.R. et al. Debugging behaviors of early childhood teacher candidates with or without scaffolding. Int J Educ Technol High Educ 19, 26 (2022). https://doi.org/10.1186/s41239-022-00319-9
- ↑ Georgiou, Kyriakoula; Angeli, Charoula Paper presented at the International Association for Development of the Information Society (IADIS) International Conference on Cognition and Exploratory Learning in the Digital Age (CELDA) (16th, Cagliari, Italy, Nov 7-9, 2019)
- ↑ Zhang, L. (2004). Field-dependence/independence: cognitive style or perceptual ability?––validating against thinking styles and academic achievement. https://doi.org/10.1016/j.paid.2003.12.015
- ↑ Blancas, Maria & Valero, Cristina & Mura, Anna & Vouloutsi, Vasiliki & Verschure, Paul. (2019). "CREA": An inquiry-based methodology to teach robotics to children.