Button Inputs

Overview

In this lesson, students learn that buttons can act as inputs that trigger code. They will program a Micro:bit to display different images when Button A or Button B is pressed, practicing clear organization and formatting in their program plan and writing.

Learning intentions

• Students will be able to explain how inputs (button presses) change what a Micro:bit does.
• Students will be able to write a simple event-driven program using Button A and Button B.
• Students will be able to evaluate and test their code to confirm it matches the intended behavior.
• Students will be able to introduce and organize information about their program using headings and a simple visual/table plan.

Success criteria

• I can describe what an “input” is and give an example using Button A or Button B.
• I can create code so Button A shows one image and Button B shows a different image.
• I can test my program and fix at least one issue using a debugging strategy.
• I can write a short, organized explanation of my program using a clear structure (intro + steps + results) and include a simple graphic or table.

Curriculum links

• Writing: History/Social Studies, Science, and Technical Subjects — Standard: introduce a topic clearly, preview what follows, organize ideas into broader categories, and include formatting/graphics when useful.
• Mathematics 6.EE.A.3 — generate equivalent expressions using properties of operations (used here in mini-logic checks for code structure, such as simplifying repeated conditions).
• Mathematics 6.EE.A.2c — evaluate expressions at specific values (used here when students reason about outcomes for specific button “states,” like A pressed vs. B pressed).
• Mathematics 6.NS.A.1 — interpret/compute quotients of fractions and solve division word problems (used as a quick, word-problem warm-up to connect “action rules” to real-world scenarios).

Lesson structure (45 minutes)

1. 0–5 min · Hook and quick demo. Teacher shows a Micro:bit prototype briefly: press A for one image, press B for another, then ask, “What caused the change?” Students turn-and-talk, then share one idea: input → output.
2. 5–12 min · Mini direct teach: event-driven thinking. Teacher explains that button presses are “events,” and code runs when an event happens; models block-based or text-based structure on the board (if Button A pressed → show image A; if Button B pressed → show image B). Students annotate their notes with two lines: “Input:” and “Output:”.
3. 12–20 min · Guided practice: plan first (write + organize). Teacher gives a one-page “Program Plan” template with headings (Purpose, Button A Behavior, Button B Behavior, Test Results) and a small table for expected outcomes. Students fill the template for their chosen images and write a 2–3 sentence introduction previewing what the program does.
4. 20–33 min · Build: code Button A and Button B. Teacher circulates while students program the Micro:bit to display images for each button press. Students run the program, press A and B, and compare actual results to their table; they record “matches” or “needs fix” in the Test Results row.
5. 33–40 min · Debug sprint: fix one issue. Teacher introduces a simple debugging checklist: (1) Check the button condition, (2) Check the image command, (3) Check that code uploaded correctly. Students choose one problem (wrong image, no response, swapped buttons) and fix it, then re-test and update their plan.
6. 40–45 min · Exit and reflection. Teacher asks two questions posted on the board and collects an exit ticket: (1) “What input did your code use?” (2) “What output happens for Button A and for Button B?” Students submit and also self-rate confidence: 1–3.

Resources

• Micro:bit devices (one per student or per pair)
• USB cables for uploading programs
• Computer stations with the Micro:bit coding environment installed/open
• Image set (built-in Micro:bit display icons) or a teacher-provided list of 5–8 options
• “Program Plan” printable with headings and a two-row table (Button A / Button B)
• Basic debugging checklist card
• Projector/board for modeling event-driven code structure
• Optional: small sticky notes for exit ticket answers

Assessment

• Formative checks during guided practice: teacher reviews “Program Plan” headings and that students can state A vs. B outcomes.
• Formative checks while building: teacher observes whether students successfully connect button events to display outputs.
• Exit ticket: verifies students’ understanding of input/output mapping for both buttons.
• Documentation check: whether students updated Test Results after testing (evidence of evaluation).

Differentiation

• Support: provide sentence starters for the “Purpose” paragraph (e.g., “When Button A is pressed, the Micro:bit will…”).
• Support: give a partially completed coding example and ask students to swap only the image choices.
• Extension: challenge students to add a third behavior using a simple additional input (only if time allows and with teacher approval), or to create multiple images using a short sequence when a button is held.
• EAL/SEN: allow students to write in short phrases; emphasize the two-part mapping (Input → Output) and use the table as the primary response structure.

Materials for “Program Plan” template (what to hand students)

• Headings: Purpose; Button A Behavior; Button B Behavior; Test Results
• Table with columns: Button / Expected Image / Actual Result / Notes (optional)
• Prompt under Purpose: “This program uses button inputs to display images. It works by… (preview the steps).”