A trained model becomes an application when it connects to interaction, output and purpose
Across four lessons students move from a game driven by a fixed rule, to two applications driven by models they train themselves, to a structured evaluation of one of those models with real evidence. The best applications solve a problem that matters to real people, so the unit ends by asking whether the sign translator would actually help the deaf community.
How the four lessons build
| Lesson | Students build | Kind of AI | Tools | Evidence kept |
|---|---|---|---|---|
| 22 | Motion-controlled ball game with score, 30-second timer and start screen | Rule-based: no training. A fixed threshold on pixel change | CCG Blocks, Video Sensing extension | .sb3 file; motion readings; threshold choice and reason |
| 23 | Sound DJ Mixer: clap, snap and "GO!" trigger animations | Trained audio classifier, 4 classes | Teachable Machine Audio, CCG Blocks | .sb3 file; model link; one documented limitation |
| 24 | Sign recogniser that displays and speaks five signs | Trained image classifier, 6 classes, 70% confidence threshold | Teachable Machine Image, CCG Blocks, Text to Speech | .sb3 file; model link; data variety record; ethics reflection |
| 25 | Evaluation of the L24 model | Testing a trained model | Results grid and chart on this page | Results table; per-sign accuracy chart; three-step improvement plan; journal entry |
Vocabulary to use consistently
- Rule-based system: behaviour set by a rule a person wrote (if motion > 30, move).
- Trained model: behaviour learned from labelled examples.
- Class: one category the model can choose (Clap, Hello).
- Background class: examples of "nothing important happening", so the model has somewhere to put noise.
- Threshold: the cut-off a value must pass before the program acts.
- Confidence: how sure the model is of its top answer, from 0% to 100%.
- False alarm: the program acts when it should not (speaks a word while hands are down).
- Miss: the program fails to act when it should.
- Accuracy: correct attempts divided by all attempts.
Assessment across the unit
- Can explain the difference between a rule and a trained model, using L22 and L24 as examples.
- Can design training data with deliberate variety, and say what variety was missing.
- Can connect a model's output to program behaviour and explain why a threshold is needed.
- Can test a model systematically, calculate accuracy and state comparisons precisely.
- Can propose an evidence-based improvement and discuss responsibilities to the people an application is for.
How to use this walkthrough
Each lesson page gives a timed sequence for a 60-minute lesson, the exact scripts students build, questions to ask, and fixes for what usually goes wrong. Tick steps as you go: ticks, notes and Lesson 25 results are kept in this browser only, on this device.
Before you teach
All four lessons use CCG Blocks, and Lessons 23 and 24 also use Teachable Machine. Test both on a student account on a school device before the unit starts.
About CCG Blocks
CCG Blocks is CCG's version of the Scratch 3 editor, at ccg.education/editor. It looks and works like Scratch, and adds a Teachable Machine extension that runs the image and sound models students train. Standard Scratch cannot do this. There are no accounts: students save projects to their own computer with File, then Save to your computer, as .sb3 files.
"Open CCG Blocks" buttons in this walkthrough open the editor on this page, so you can build alongside the steps. Close it to return to the walkthrough; your project stays open until you leave the page.
Open the tools
CCG Blocks opens on this page; Teachable Machine opens in a new tab. Use Chrome.
The model-to-editor route students follow in L23 and L24
Starter projects
Each lesson has a starter for students and a complete version for you. They open in CCG Blocks on this page; students save their own copy with File, then Save to your computer.
| Lesson | Starter already contains | Students build | Open |
|---|---|---|---|
| 22 | Start, Arena and Game over backdrops; Ball and Target sprites; score, time left and threshold variables; finished Stage scripts (start screen, timer) | Ball and Target scripts | Starter · Complete |
| 23 | Teachable Machine extension; Drum, Star and Indicator sprites with costumes; model link block that also turns the camera off | Clap, Snap, GO and listening scripts | Starter · Complete |
| 24 | Teachable Machine and Text to Speech extensions; Word sprite with six costumes named to match the classes; green flag set-up script | The forever loop that shows and speaks each sign | Starter · Complete |
Lessons 23 and 24 need a trained model before the project does anything: paste a model link into the green block, then click the green flag.
Backup models
Train these once before the unit, about 20 minutes each, so that any pair whose training fails can still build and test. Use the class names exactly as written.
Audio model for Lesson 23
- Teachable Machine, Audio Project.
- Background Noise: 20 seconds of normal classroom noise (talking, chairs), not silence. Record a second 20 seconds in another room if you can.
- Clap: at least 40 samples from 3 or more people, soft and loud, near and far.
- Snap: at least 40 samples, both hands, 3 or more people.
- GO: at least 40 samples from 3 or more voices, including a child's if possible, near and far.
- Train Model. In Preview, check each sound, then talk normally: it should stay on Background Noise. Export Model, Upload my model, copy the link.
Image model for Lesson 24
- Teachable Machine, Image Project, Standard image model.
- Background: at least 40 images: empty frame, a person with hands down, hands moving without signing, two different backgrounds.
- Hello, Yes, No, Please, Thank You: at least 60 images each from 3 or more people, including a left-handed signer, in bright and dim light, close and far.
- Use Hold to Record in 2-second bursts, changing one condition between bursts.
- Train Model. In Preview, check each sign and the empty frame. Export Model, Upload my model, copy the link.
Your backup model links
Kept in this browser onlyChecklist
Scratch Hand Sensing game
Students build a complete game controlled by hand movement, then tune its motion threshold. The point is that nothing here is learned: Scratch compares video frames and measures how many pixels changed under a sprite. That makes it the baseline against which the trained models in Lessons 23 and 24 are compared.
- Students make
- Playable game: start screen, motion-controlled ball, moving target, score, 30-second countdown
- Tool
- CCG Blocks with the Video Sensing extension
- Kind of AI
- Rule-based motion detection, no training
- Keep
- .sb3 file, motion readings, final threshold and the reason for it
Name the extension correctly
The extension is called Video Sensing. Its blocks report video motion on sprite from 0 to 100 and video direction on sprite in Scratch's own direction system, from -180 to 180 (90 is right, -90 is left, 0 is up, 180 is down). Because it uses the same system as point in direction, the direction value can be dropped straight into that block.
Teaching sequence
How does the computer know my hand moved?
"If I waved a book instead of my hand, would the game notice the difference?"
Measure before building
Build the game from the scripts below
Change one number, retest, note the effect
Rules versus a trained model
Motion readings and threshold
For your demonstration or a pair's readings| Hand over the sprite | video motion reading (0 to 100) |
|---|---|
| No movement | |
| Slow wave | |
| Fast wave |
Example values shown until you type your own. The suggestion is halfway between the still reading and the slow-wave reading, so a resting hand never moves the ball but a deliberate slow wave does.
Scripts to build
Stage
Ball sprite
Target sprite
The outline's rule "move when video motion > 30" is built with a threshold variable instead of a fixed 30, so tuning is a slider drag rather than an edit inside the script.
Questions to ask
- What value does the sensor give when nothing moves? Why is it not always zero?
- Why does the ball only respond when your hand is over it?
- What happens if someone walks behind you? Is that the game's fault?
- What would you need to give a computer so it could tell a wave from a thumbs-up?
Misconceptions to address
- "The computer can see my hand." It sees changed pixels, from anything.
- "A higher threshold is always better." Too high and the game ignores real moves.
- "This is machine learning." Nothing was trained, and it behaves the same way on day one as day one hundred.
If something goes wrong
The stage stays black when video is turned on
Chrome has blocked the camera, or another tab or app is using it. Click the camera icon in the address bar, allow access, close other video tabs and reload.
The ball never moves
Motion is measured only under the ball, so the hand must be over it. Check the threshold slider is not above the fast-wave reading.
The ball drifts or jitters on its own
Flickering lights, a busy background or people moving behind the student. Raise the threshold a little or turn the device to face a wall.
The ball moves the opposite way to the hand
The video is mirrored by default so it behaves like a mirror. Check turn video on rather than on flipped.
The game keeps running after time ends
The Ball and Target need their when I receive game over scripts. Check the broadcast name matches exactly.
TM audio classifier game
Students train a four-class audio model and connect it to a Sound DJ Mixer: a clap plays a drum animation, a snap changes the backdrop colour, saying "GO!" triggers a special animation, and background noise shows a listening indicator. Testing in a noisy classroom exposes the model's first real limitation.
- Students make
- Sound DJ Mixer in CCG Blocks driven by their own audio model
- Tools
- Teachable Machine (Audio Project), CCG Blocks with the Teachable Machine extension
- Classes
- Background Noise, Clap, Snap, GO
- Keep
- .sb3 file, model link, one documented limitation
Teaching sequence
Show the finished mixer
"Last lesson a rule decided what happened. Today nobody writes the rule: the model learns it from your examples."
Record the four classes, background first
Connect the model to the mixer
The noisy classroom test, in two rounds
Document one limitation precisely
Scripts to build
Drum sprite
Stage
Star sprite
Indicator sprite
Green blocks come from the Teachable Machine extension. Label names in the blocks must match the Teachable Machine class names exactly, including capitals and spaces.
Questions to ask
- Why must Background Noise be recorded first, and in a noisy room rather than a silent one?
- Your model has to pick one of four answers every moment. What does it do with a cough?
- Would your model work for a student whose clap and voice are not in the data?
- In round 2, whose sounds was your model hearing?
Limitations students usually find
- Neighbours' claps trigger their mixer.
- Loud talking is classed as GO.
- Snaps are missed when the snapper stands further away than in training.
- Background trained in silence, so ordinary chatter triggers Clap.
If something goes wrong
The model link will not load
Copy the link from Upload my model (the shareable link), not the download option. It ends with a forward slash. Paste it, click the green flag, and wait: loading can take several seconds on school Wi-Fi.
Labels never trigger anything
Tick sound label to see what the model is outputting. Usually the class name in the block differs from the one in Teachable Machine, for example "Go" against "GO".
Everything triggers Clap
Background Noise was recorded in silence or has too few samples. Re-record it in normal room noise, retrain, upload again and paste the new link.
The microphone is not working
Allow the microphone for both teachablemachine.withgoogle.com and ccg.education via the icon in Chrome's address bar.
Training failed or the pair ran out of time
Give them your backup model link so they can still build and test. Their limitation can then be about a model trained on someone else's voice and hands.
Sign Language Translator
Students train a six-class image model on hand signs and connect it to Text to Speech, so the program shows and speaks a recognised sign only when it is at least 70% confident. The lesson closes with a reflection on what it would take for this to be useful to deaf people, and who should decide.
- Students make
- A recogniser that displays and speaks Hello, Yes, No, Please, Thank You
- Tools
- Teachable Machine (Image Project), CCG Blocks with the Teachable Machine and Text to Speech extensions
- Classes and minimum images
- Background 20; Hello, Yes, No, Please, Thank You 25 each
- Keep
- .sb3 file, model link, data variety record, list of who contributed data (needed in L25)
Be precise with students about what this model can and cannot do
The World Federation of the Deaf estimates there are about 70 million deaf people worldwide, using more than 300 sign languages. Many signs involve movement, and sign languages also use facial expression and body position as grammar. An image model classifies one still frame, so it learns a hand shape at one moment, not the sign. What students build is a recogniser for five hand shapes, which is a useful first step and also the main point of the ethics reflection.
Teaching sequence
Purpose and respect
"Who should decide whether a sign language app is any good?"
Six classes, deliberate variety, several contributors
Translator script with threshold and speech
Every student tests it live
Ethics reflection
Training data variety record
One per pair, or one for your demonstration modelScript to build
Word sprite
Below 70% confidence the extension reports an empty label, so the length of check ignores frames the model is unsure about. The last word variable stops the program speaking the same word several times a second while a sign is held; lowering the hands to Background re-arms it, so the same sign can be spoken again.
Ethics reflection prompts
- What does a sign language include that our model cannot see?
- What would it take to make this genuinely useful to deaf people, and who should be involved in building it?
- Where could a wrong translation cause harm, for example at a doctor's appointment?
- What responsibilities come with building accessibility AI: consent for data, honesty about limits, testing with real users?
Questions during training
- Which two signs look most alike in a single photo?
- If only right-handed students record, what happens for a left-handed signer?
- Why does Background need images of hands moving without signing?
If something goes wrong
It keeps saying a word when nobody is signing
Background is too narrow. Add images of hands down, hands moving and different people in frame, retrain and upload again.
A sign is never recognised
Its confidence never reaches 0.7. Add more varied images of that sign, or check it is not too similar to another sign in one frame.
The word repeats over and over
The last word check is missing or the variable is not being reset when the label is Background.
The costume does not change
Costume names must match class names exactly, including the space in "Thank You".
No speech
Check device volume. Text to Speech needs an internet connection.
Testing and evaluating the Sign Language Translator
Pairs test their Lesson 24 model under a fixed protocol, record every attempt, draw a per-sign accuracy chart and write a three-step improvement plan from the evidence. A final live demonstration closes the unit.
- Students make
- Results table, per-sign accuracy chart, improvement plan, journal entry
- Tested across
- 5 signs × 2 lighting conditions × 2 testers × 5 attempts = 100 attempts, plus 10 background checks
- Accuracy means
- Correct attempts ÷ all attempts. "Nothing spoken" counts as not correct.
- Keep
- Completed results, chart, plan, journal sentence
Teaching sequence
Commit to a prediction
"The most distinct sign is likely to be the most accurate. Which is it in your data?"