Technologies · Foundation

Active learning ideas

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.

• ACARA Content Descriptions
• AC9TDIK02
• AC9TDIP03

• 20–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Plan-Do-Review
• 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.

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.

What to look for

Show students a simple program in ScratchJr with a button that makes a sprite change color when clicked. Ask: 'What action did you do to make the sprite change?' and 'What part of the program made the change happen?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 02

• Plan-Do-Review
• 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.

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.

What to look for

Give students a card with a picture of a common app interface element (e.g., a slider, a play button). Ask them to write one sentence describing what happens when they interact with it and one word for the type of action they performed.

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 03

• Plan-Do-Review
• 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.

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.

What to look for

Ask students to think about a tablet game they play. 'What happens when you tap on a character? What happens when you swipe the screen? How is that like the programs we are making?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 04

• Plan-Do-Review
• 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.

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.

What to look for

Show students a simple program in ScratchJr with a button that makes a sprite change color when clicked. Ask: 'What action did you do to make the sprite change?' and 'What part of the program made the change happen?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

A few notes on teaching this unit

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.

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

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

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

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

  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.

• 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.

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

---

Methods used in this brief

• Plan-Do-Review