Event-Driven Programming and User Interfaces

Active learning lets students experience the pause-and-wait behavior of event-driven programs firsthand. When children pair program a button and observe the sprite’s response, they see how code stays quiet until an input arrives, building an authentic mental model of event handlers.

• Foundation
• Technologies
• 4 activities
• 20 min–40 min

Learning Objectives

1. Design a simple program that changes its output when a user interacts with an input element like a button.
2. Explain the function of an event handler in making a program respond to user actions.
3. Identify how different user interface elements, such as sliders, can trigger specific events within a program.
4. Analyze the sequence of actions that occur when a user input triggers an event in a program.

Inquiry Circle

⏱ 25 min·Pairs

Pairs Coding: Button Response Challenge

In pairs, students drag a 'when button pressed' event block to a sprite, then add output blocks for color change or sound. Partners alternate coding and testing, predicting what happens before running the program. Discuss adjustments if the response does not match expectations.

Prepare & details

Design a program that responds to various user inputs (e.g., keyboard, mouse, touch).

Facilitation Tip: During Pairs Coding, circulate and ask each pair to verbalize the event they just programmed before they test it.

Setup: Groups at tables with access to source materials

Materials: Source material collection, Inquiry cycle worksheet, Question generation protocol, Findings presentation template

• Analyze
• Evaluate
• Create
• Self-Management
• Self-Awareness

Inquiry Circle

⏱ 40 min·Small Groups

Small Groups: Multi-Input Sprite Game

Groups build a sprite that moves left/right on arrow keys and jumps on spacebar using separate event handlers. Assign roles for coder, tester, and recorder. Rotate roles midway and share one feature with the class.

Prepare & details

Explain the concept of an 'event handler' and its role in interactive programs.

Facilitation Tip: In Small Groups, assign one student to be the ‘event recorder’ who logs every input and the resulting output in a simple table.

Setup: Groups at tables with access to source materials

Materials: Source material collection, Inquiry cycle worksheet, Question generation protocol, Findings presentation template

• Analyze
• Evaluate
• Create
• Self-Management
• Self-Awareness

Inquiry Circle

⏱ 30 min·Whole Class

Whole Class: Slider Control Demo

Teacher models a slider event changing sprite size, then students remix as a class by suggesting block additions. Vote on best outputs and test collectively. Follow with 5-minute individual tweaks.

Prepare & details

Analyze how different user interface elements (buttons, sliders) trigger events and affect program flow.

Facilitation Tip: For the Whole Class Slider Demo, invite volunteers to predict the slider’s value before dragging and compare predictions to the actual output.

Setup: Groups at tables with access to source materials

Materials: Source material collection, Inquiry cycle worksheet, Question generation protocol, Findings presentation template

• Analyze
• Evaluate
• Create
• Self-Management
• Self-Awareness

Inquiry Circle

⏱ 20 min·Individual

Individual: Touch Event Story

Each student creates a short interactive story where touching objects triggers speech or movement. Start with two events, test on devices, then add one more. Share screenshots in a class gallery.

Prepare & details

Design a program that responds to various user inputs (e.g., keyboard, mouse, touch).

Facilitation Tip: Have students place a sticky note on their Touch Event Story that names the event they chose and the sprite’s reaction.

Setup: Groups at tables with access to source materials

Materials: Source material collection, Inquiry cycle worksheet, Question generation protocol, Findings presentation template

• Analyze
• Evaluate
• Create
• Self-Management
• Self-Awareness

Teaching This Topic

Start with concrete, miniature challenges so students feel the shift from linear to event-driven flow. Avoid long lectures; instead, model one quick test, then step back so learners can iterate and debug in real time. Research shows that rapid cycles of cause-and-effect testing build lasting understanding of event-driven behavior better than abstract explanations.

What to Expect

By the end of the activities, students will explain that user actions trigger specific code blocks and will design at least one interface element that responds correctly each time it is used. They will also compare different input types and justify why each needs a different event handler.

Watch Out for These Misconceptions

Common Misconception

During Pairs Coding, watch for students who run the program once, see no movement, and assume the code is broken.

What to Teach Instead

Prompt them to tap the button again and narrate aloud, 'The program is waiting for us to tap; let’s try that again.'

Common Misconception

During Small Groups Multi-Input Sprite Game, watch for students who treat the button and slider as interchangeable.

What to Teach Instead

Ask groups to swap roles: one student uses only the button while another uses only the slider, then compare outputs using the event recorder’s table.

Common Misconception

During Whole Class Slider Control Demo, watch for students who believe a slider triggers its event only at the start and end of the drag.

What to Teach Instead

Have the demo leader pause mid-drag and ask, 'What is the slider’s value right now?' so students notice continuous updates.

Assessment Ideas

Quick Check

After Pairs Coding, show the class a short ScratchJr program with a button that makes a sprite change color when tapped. Ask each student to whisper the specific user action that triggers the change and the sprite behavior that follows.

Exit Ticket

During Multi-Input Sprite Game, hand each student an index card with a picture of a button or a slider. Ask them to write one sentence describing what happens when they interact with it and one word for the type of action they performed.

Discussion Prompt

After the Whole Class Slider Control Demo, ask students to turn to a neighbor and share one tablet game they know. Tell them to name two different user actions in the game and describe what happened in each case, connecting their real-world experience to the programs they built.

Extensions & Scaffolding

• Challenge: Add a second button that resets the sprite’s position while keeping the first button functional, then share the code with another pair.
• Scaffolding: Provide starter code with the event block already snapped in so students focus only on the output action.
• Deeper exploration: Introduce a two-event sequence where the first event sets a variable and the second event uses it, then have students draw a flowchart of the program’s flow.

Key Vocabulary

Event	An action that a program can detect, such as a mouse click, a key press, or a touch on the screen.
Event Handler	A specific block of code that runs when a particular event happens, making the program react to the user's action.
User Interface (UI)	The visual elements on a screen, like buttons, sliders, and characters, that a user interacts with to control a program.
Input	Information or actions provided to a program by the user, such as tapping a button or typing on a keyboard.
Output	What the program does or shows in response to an input or event, like moving a character or playing a sound.