View source for PRE2024 1 Group1:

{| class="wikitable"
|+Group members
!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.<ref name=":0">Kaplancali, U. T. (2017). Teaching Coding to Children: A Methodology for Kids 5+. ''International Journal of Elementary Education'', ''6''(4), 32. <nowiki>https://doi.org/10.11648/j.ijeedu.20170604.11</nowiki></ref>

=== '''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<ref>Engelhardt, A. (2023, July 21). ''Shortage of skilled workers in mechanical engineering''. Encoway. <nowiki>https://www.encoway.de/en/blog/skilled-worker-shortage-in-machine-building/</nowiki></ref>. A lot of young people do not choose for a career in technology<ref>Edgar, G. (2022, March 8). ''Why young people are being put off a career in tech - Diversity in Tech''. Diversity in Tech. <nowiki>https://www.diversityintech.co.uk/why-young-people-are-being-put-off-a-career-in-tech/</nowiki></ref>. 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)<ref>''Debugging: The key to unlocking the mind of a novice programmer?'' (2019, October 1). IEEE Conference Publication | IEEE Xplore. <nowiki>https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9028699&tag=1</nowiki></ref>. Additionally, using a robot for visual debugging can encourage experimentation and improve overall debugging skills (Grimm, 2002)<ref>Grimm, V. (2002). VISUAL DEBUGGING: a WAY OF ANALYZING, UNDERSTANDING AND COMMUNICATING BOTTOM‐UP SIMULATION MODELS IN ECOLOGY. ''Natural Resource Modeling'', ''15''(1), 23–38. <nowiki>https://doi.org/10.1111/j.1939-7445.2002.tb00078.x</nowiki></ref>. 

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.

'''<u>Group 1: Physical Debugging-First Approach</u>'''

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.

'''<u>Group 2: Bottom-Up Coding Approach</u>'''

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.

'''<u>Comparative Test Process</u>'''

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 6<sup>th</sup> 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 7<sup>th</sup> 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 is a comprehensive teaching package designed to introduce students to coding. It includes a 20-minute presentation on the fascinating aspects of coding and a brief introduction to debugging. The package features a robot programmed using Arduino © and an online coding environment where students can practice their coding skills and track their progress.

The code written in the online environment closely mirrors what is implemented in Arduino, providing a seamless learning experience. To aid in the learning process, we included predefined functions that students could use. These functions were particularly useful for teaching coding in Dutch, making the material more accessible.

Although we did not create a formal lesson plan, the project effectively integrates hands-on learning with theoretical knowledge. The robot provides a tangible way for students to see the impact of their code, making abstract concepts more accessible. This approach also helps students learn debugging by observing the robot’s actions and making necessary corrections to their code.

The online coding environment was crucial for researchers to track the students’ progress, although this aspect was not of great importance to the children themselves.

=== 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 questionnaire 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:<nowiki>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</nowiki>

''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'''
[[File:Enquête Pabo.png|thumb|369x369px|An enquête to require other insights from an educational point of view about our curriculum.]]
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!'''[[File:VenusExplorationRobot.png|thumb|Robot used for this project. |left|183x183px]]
=== 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. We were 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 conclude that for this project we were unable to do this. Thus the robot was wired while uploading with a 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, and place objects back.[[File:Webpage.png|thumb|left]]

=== The web interface ===
The web interface we have created for the students is grouped by subject.

We have two different interfaces for each of the test groups with the same style and layout. To appease the age group, we have tried to make the design suited for children by incorporating vibrant colours, minimizing empty space, and making most objects rounded, while still being suitable for educational settings by keeping the colours, although vibrant, in the same colour palette and making the patterns repetitive.[1] The design is kept simple and intuitive, both for students and teachers.

For recreating the web interface, see the following GitHub Repository, <nowiki>https://github.com/GijsKruize/0LAUK0</nowiki>. The readme file will guide you through the steps needed to get the same setup.

=== Exercises ===
For both groups, the goals 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:
{| class="wikitable"
|+
!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 created a map on A0 where the robot could drive. 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 the checkpoint and then drive backwards to the point where it should go right. This is to simulate a dead end and practice driving backwards.
[[File:Map A0.png|center|thumb|377x377px|Coloured version of A0 map that was used for the exam exercises]]

=== Survey ===
The survey is designed according to the MCC Survey Guidelines<ref>Babbie, E., Converse, J. M., Presser, S., Dillman, D., Fowler, F. J., Pelosi, M. K., Sandifer, T. M., & Sekaran, U. (1990). ''Guidelines and standards for survey research''. Wadsworth Publishing Company. <nowiki>https://www.mesacc.edu/sites/default/files/pages/section/about-mcc/research-planning/MCCSurveyGuidelines.pdf</nowiki></ref>. Furthermore, 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. 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.  
{| class="wikitable"
|+All questions in the survey are asked on a 7 point Likert scale
|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. 

4. Ik denk dat ik beter ben geworden in coderen tijdens dit project. 

5. Als ik de code zie, weet ik precies wat de robot gaat doen. 

6.  Ik begrijp het doel van elk onderdeel van de code die ik heb geschreven of mee heb gewerkt. 

7.  Ik denk dat ik elk probleem dat komt door de code van de robot kan oplossen. 

8. Ik denk dat ik beter werd in coderen na elke opdracht 

9. Ik kan een groot probleem meestal opdelen in kleinere stappen. 

10. Ik probeer verschillende oplossingen wanneer mijn code niet werkt zoals verwacht. 

11. Ik vind het fijn wanneer ik mijn code kan testen om te zien of deze correct werkt. 

12. Het is gemakkelijk voor mij om te begrijpen wat de code doet.  

13. Wanneer ik de code verander, weet ik wat de robot gaat doen. 

14. Wanneer ik een probleem tegenkom in de code, kan ik meestal zelf de oplossing vinden. 

The questions are divided into 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.<ref>''Lesvoorbereidingsformulier vakdidactiek fysica KU Leuven''. (n.d.). Overleaf, Online LaTeX Editor. <nowiki>https://www.overleaf.com/latex/templates/lesvoorbereidingsformulier-vakdidactiek-fysica-ku-leuven/jfckfnfrmjty</nowiki></ref>" This lesson plan is in Dutch, therefor the following paragraph is also in Dutch. 

==== '''<big>Lesplan op basis van debugging</big>''' ====
'''Identificatiegegevens'''
{| class="wikitable"
|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'''
{| class="wikitable"
|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: <nowiki>https://dsdwiki.wtb.tue.nl/wiki/PRE2024</nowiki> 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'''
{| class="wikitable"
|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.

==== <big>Lesplan traditionele lesstructuur</big> ====
'''Identificatiegegevens'''
{| class="wikitable"
|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'''
{| class="wikitable"
|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: <nowiki>https://dsdwiki.wtb.tue.nl/wiki/PRE2024</nowiki> 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'''
{| class="wikitable"
|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
|}
[[File:Werkblad Probleemoplossings cyclus.png|thumb|255x255px]]
'''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.

== '''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 ===
[[File:Codering van de observaties.jpg|thumb|257x257px|Observations of testing]]

The observations are coded in five different categories, namely Enthusiasm, Care for the robot, Apparent understanding of coding, Attention during explaination and Behavior. 

===== Enthusiasm =====
In both situations all children were initially enthusiastic about the robots and coding in general. However, in the debugging group, the enthusiasm soon declined. At the end there were only a handful of children working on the assignment. On the contrary, all except two participants in the build code up group kept working until the end. Strategy 2 seemed to lead to more enthusiasm, possibly because the participants felt like they did it themselves, instead that is was being done for them. Some participants even said that there were unhappy that class was already over. 

===== Care of the robot =====
The care of the robots is more or less similar between the two groups. The only difference was that some participants in the debugging group forcefully corrected the robot when it did not do what they wanted. Both group took good care of the robots initially, corrected peers that did not take good care, and played with the robot form time to time. 

===== Apparent understanding of the code =====
The debugging group had a lot of difficulties with all exercises and needed a lot of explanation. All participants in this group needed help with almost all exercises. In the other group, participants needed a lot of help at first. The syntax was unclear and the participants used "normal language" to try and make the robot work. For instance, they typed "go forward 20cm" instead of forward(20). Once this was clear, they went through the exercises quicker then the debugging group. They also seemed to understand the syntax and details of coding better then the debugging group. Both groups understood that the Arduino application was what made the robot move, so some of them programmed the exercises in there instead of in the online learning platform.

===== Attention during the explanations =====
In the group that builds the code up, there was a lot more attention given to the explanations. They children were quiet and present when there group got help. This was not the case for the debugging group. Some of the participants were distracted or walked away when their group got help.

===== Behavior =====
In the group that build the code from scratch, everyone immediately sat in such a way that everyone could see the screen. This was not the case in the debugging group, where there was usually one "coder" and a couple of helpers. The debugging group was also more playful then the other group, for instance, racing against each other and making the robots walk infinite amounts. In the debugging group, children that actually were motivated, would join up and work together as a new self-formed group. 
[[File:Survey results of strategy 1.png|thumb|Survey results of strategy 1]]
[[File:Survey results strategy 2.png|thumb|Survey results strategy 2]]

=== Results of surveys ===
All survey results were added together per strategy, as can be seen in the images on the right. The mode will be used to draw conclusions, the average of abstract concepts like "eens" and "oneens" cannot be computed. 

=== 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.
[[File:Quantitative results graph.jpg|thumb|Results of quantitative tests]]

==== Observations of results ====
Due to the low amount of data (which has turned out lower as expected) it is hard to draw conclusions from these results. One thing we can see for sure 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 submissions 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 ==
Regarding our 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?''

We can draw the following conclusion based on our gathered results.

''The bottom-up approach is more effective then a debugging-first method n terms of students' problem-solving skills and code comprehension?''


lthough our quantitative results have not reached the preferred numbers, due to overall lower results of our tests. The observations gave us a lot to work off. The pace the second group (bottom-up strategy) showed while working trough the assignments was significantly higher which can be confirmed by the quantitative results in some degree. This in combination with the enthusiasm and level of questions the second group had, we, as observers had the idea that the students executing the bottom-up approach had a greater understanding of what they did, and why they did it.

== 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<ref>''Scratch - imagine, program, share''. (n.d.). <nowiki>https://scratch.mit.edu/</nowiki></ref> and Blockly<ref>''Blockly Games''. (n.d.-b). <nowiki>https://blockly.games/</nowiki> </ref> are some of the most populair programming languages of this type, but there are also other such as Tynker<ref>Tynker - Coding for Kids. (2022, September 15). ''Coding for kids, kids online coding classes & games | Tynker''. Tynker.com. <nowiki>https://www.tynker.com/</nowiki> </ref> 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<ref>Schmeets, H., Cornips, L. (2021), Talen en dialecten in Nederland.''Centraal Bureau voor de Statestiek.'' <nowiki>https://www.cbs.nl/nl-nl/longread/statistische-trends/2021/talen-en-dialecten-in-nederland</nowiki> </ref>, therefor this is not a viable option for most preschool children. However, the programming languages for children such as Hedy<ref>''Hedy - Textual programming made easy''. (n.d.). <nowiki>https://www.hedycode.com/</nowiki> </ref> 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<ref>B-Bot. (2024b, October 15). ''Bee-Bot''. B-Bot. <nowiki>https://b-bot.nl/educatieve-robots/bee-bot</nowiki> </ref> and Code & Go Programmable Robot Mouse<ref>Chou, P., & Shih, R. (2021). Young Kids’ Basic Computational Thinking: An analysis on educational robotics Without computer. In ''Lecture notes in computer science'' (pp. 170–180). <nowiki>https://doi.org/10.1007/978-3-030-91540-7_19</nowiki> </ref>

'''Arduino based robots'''

There are multiple robots such as mBot<ref>''MBot: Kid’s first robot kit for coding and STEM Learning|Makeblock''. (n.d.). Makeblock. <nowiki>https://www.makeblock.com/pages/mbot-robot-kit</nowiki></ref>  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<ref>''LEGO Education SPIKE''. (n.d.). <nowiki>https://spike.legoeducation.com/</nowiki> </ref> and the Lego Mindstorms<ref>Üçgül, M. (2013). History and Educational Potential of LEGO Mindstorms NXT. Mersin Üniversitesi Eğitim Fakültesi Dergisi, 9(2), 127-137. </ref>. 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'''<ref>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. <nowiki>https://doi.org/10.1371/journal.pone.0088941</nowiki></ref>

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'''<ref>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''. <nowiki>https://doi.org/10.1145/3173574.3173970</nowiki></ref>

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+'''<ref name=":0" />

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'''<ref>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)''. <nowiki>https://doi.org/10.1109/latice.2018.000-5</nowiki></ref>

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'''<ref>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. <nowiki>https://doi.org/10.1016/j.compedu.2016.03.003</nowiki></ref>

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 <ref>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. <nowiki>https://doi.org/10.1016/j.jecp.2017.03.013</nowiki></ref>''' 

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'''<ref>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. <nowiki>https://doi.org/10.1007/s10956-019-09792-w</nowiki></ref>

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'''<ref>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). <nowiki>https://doi.org/10.1186/s41239-022-00319-9</nowiki></ref>

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'''<ref>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)</ref>    

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.<ref>Zhang, L. (2004). Field-dependence/independence: cognitive style or perceptual ability?––validating against thinking styles and academic achievement. <nowiki>https://doi.org/10.1016/j.paid.2003.12.015</nowiki></ref> 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'''<ref>Blancas, Maria & Valero, Cristina & Mura, Anna & Vouloutsi, Vasiliki & Verschure, Paul. (2019). "CREA": An inquiry-based methodology to teach robotics to children. </ref> 

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 
{| class="wikitable"
|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 
{| class="wikitable"
|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
{| class="wikitable"
|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
{| class="wikitable"
|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
{| class="wikitable"
|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  
|16
|-
|Tom 
|Meetings(1+4+2h) + contact with school (1h) + creating new research questions (1h) + research (1h)
|10
|}
Week 6
{| class="wikitable"
|Who 
|What 
|Hours 
|-
|Gijs 
|Meetings(1+2+1h), Database redesign (1,5h), Backend programming (2,5h), Frontend programming (2,5h), setting up actual server environment (2h)
|12,5
|-
|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
{| class="wikitable"
|Who 
|What 
|Hours 
|-
|Gijs 
|Testing at the school(6h), Finalalizing webinterface (3h), filling in the assignments (1.5h), Finishing the network (1.5h), Server debugging (1.5h), publishing the GitHub Repo (3h),  rewriting the assignments (3h), meeting(1+1h), wiki (1h) 
|23,5
|-
|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), debugging the robots (1h), preparing laptops (1h), Meeting(1+1h), wiki(1h), writing the assignments (2h)
|11
|-
|Tom 
|Testing at the school(3h+2h) 
|
|}

=== Reference list ===
<references />