Week 8: Field Activity. Electronics & Programming: Digital Fabrication with kids.¶
Assignments¶
- FIELD ACTIVITY: planning and delivery
- Reflection Questions
FIELD ACTIVITY: planning and delivery¶
My field design activity consisted on planing and delivering a programming-based lesson plan.
This is the link to the lesson in SCOPES-DF: Lesson in SCOPES-DF
Context¶
I am currently working in a makerspace with a small group of primary students attending after-school workshops. This will be the first time I deliver a lesson to this group, but I know they are familiar with Scratch.
I intend to use this previous knowledge to build on it and deliver a hands-on activity that requires very simple electronics, coding, and making skills. I only have a 1-hour lesson, so I need to prepare the resources and timings very well.
Developing and testing the prototype¶
For the activity I am going to use an educational microcontroller called the micro:bit, which is very popular in schools (at least in Europe) to introduce coding, since it uses a block-based coding environment and the board incorporates many integrated inputs and outputs.
There are many projects available on the MakeCode site, and many others posted online by teachers and users.
As I need to keep the lesson very simple, I decided to base it on a project called “Reaction Game,” which students can build quickly with just a few materials and work in pairs to code.
I built a prototype to understand the materials and tools required and to test the code.
Lesson delivery¶
Reflection Questions¶
1. How well did the activity align with your intended curriculum or standards, and what adjustments (if any) would strengthen this alignment?
The activity was delivered as an after-school session, but it aligns well with the Spanish Primary Education curriculum and could be integrated into classroom learning. The curriculum highlights digital competence and the application of computational thinking to solve problems through design projects. In this lesson, students followed and modified a simple algorithm using block-based programming (sequence, timing, and repetition) and tested outcomes to improve performance, which supports interpreting and adjusting simple algorithms (game rules, sequential instructions, loops, and repetitive patterns). The activity also promoted key transversal competencies, including cooperation, respect, teamwork, and sportsmanship, as students took turns, followed agreed rules, and supported peers during testing and debugging.
To strengthen alignment further, I would extend the lesson into a short project-based sequence where students progress through the design cycle (design, prototyping, testing, and communication).
2. In what ways did students’ ZPD guide your decisions about pacing, scaffolding, or complexity of the activity?
Prior to delivering the activity, I knew students had some experience with block-based programming, particularly Scratch. Nonetheless, I began with a quick prior-knowledge warm-up using a simple MakeCode program and the prompt, “What do you think this will do?” This helped me gauge who already understood basic program flow and microcontroller input/output, so I could adjust the pace and the level of support before moving on.
I scaffolded the build phase by providing an electrical diagram and preparing the materials in advance. As a result, students could assemble the circuit in about 10 minutes, leaving sufficient time for coding, testing, and debugging, the parts of the lesson where they most needed guided support.
To avoid cognitive overload, I structured the activity in clear chunks: warm-up, demonstration of the game goal, physical build, and only then the programming logic (variables, random delay, and a while loop).
The baseline code was intentionally minimal, with two inputs, one output, one state variable, and a simple winner condition, so the core task was challenging but achievable for learners with Scratch experience.
Finally, I included optional stretch challenges (reaction-time display, false-start, and a countdown). This provided an extension pathway for students who were ready to move beyond the core task, while allowing others to consolidate the fundamentals without being pushed beyond their current capability.
3. What supports did you provide in the lesson plan to support diverse student needs? How did these supports work in the overall lesson?
I provided a combination of visual and step-by-step build supports and the lesson was broken into manageable phases (warm-up, demo, build, coding, testing). After each phase, I used brief check-ins “Show me your screen/circuit”, “check that the microcontroller is connected and you can upload the code”.
Students worked in pairs, which supported collaboration, reduced anxiety for learners who struggle independently, and created natural peer tutoring without putting all responsibility on one student.
I also included differentiation through an extension challenge that gave more advanced students additional complexity without requiring everyone to complete the same level.
4. After testing the lesson, what changes would you make to better meet diverse learner needs or to better maintain the learning objectives?
The activity worked well overall and every group successfully completed the baseline version of the reaction game, which indicates that the learning objectives were achievable for this group. After testing the lesson, I would make the following changes to better meet diverse learner needs.
Design the activity with a more project-based approach with structured design phases. I would extend the activity over more time so students can move through the design cycle (design, prototyping, testing, iteration, communication). This would provide more opportunities for creative personalization and reinforcing computational thinking through repeated test-and-improve cycles.
Build in time for reflection and concept clarification. I would include a short reflection and discussion section, so students can articulate what their code is doing and why. For example, one pair asked whether creating game_started also required a game_finished variable. This became a useful opportunity to reinforce Boolean logic and state: within this program, game_started=false already represents “the game is not active,” so an additional variable was unnecessary. In a future lesson, I would plan time for these questions and use them to consolidate understanding of variables and program logic.
Tools¶
- Make it: code it / Reaction game Micro:bit project for reaction game