1. Review and demonstration (2+ minutes):
Begin by asking coders to talk with a neighbor for 30 seconds about something they learned last time; assess for general understanding of the practices and concepts from the previous project.

Explain that today we are going to animate a joke. Display and demonstrate the sample project (or your own remixed version).

Video: Project Preview (1:04)
Video: Lesson pacing (1:48)

This can include a full class demonstration or guided exploration in small groups or individually. For small group and individual explorations, you can use the videos and quick reference guides embedded within this lesson, and focus on facilitating 1-on-1 throughout the process.

Example review discussion questions:

• What’s something new you learned last time you coded?
  • Is there a new block or word you learned?
• What’s something you want to know more about?
• What’s something you could add or change to your previous project?
• What’s something that was easy/difficult about your previous project?

2. Discuss (3+ minutes):
Have coders talk with each other about how they might create a project like the one demonstrated. If coders are unsure, and the discussion questions aren’t helping, you can model thought processes: “I noticed the sprite moved around, so I think they used a motion block. What motion block(s) might be in the code? What else did you notice?” Another approach might be to wonder out loud by thinking aloud different algorithms and testing them out, next asking coders “what do you wonder about or want to try?”

After the discussion, coders will begin working on their project as a class, in small groups, or at their own pace.

Note: Discussions might include full class or small groups, or individual responses to discussion prompts. These discussions which ask coders to predict how a project might work, or think through how to create a project, are important aspects of learning to code. Not only does this process help coders think logically and creatively, but it does so without giving away the answer.

Example discussion questions:

• What would we need to know to make something like this in Scratch?
• What kind of blocks might we use?
• What else could you add or change in a project like this?
• What code from our previous projects might we use in a project like this?
• What kind of jokes might we animate?
  • What kind of sprites might we see in that joke?
    • What kind of code might they have?

4. Create a storyboard (10-15+ minutes):
Walk through the process of creating a storyboard by asking the following questions, then giving coders time to document their answers through physical or digital means:

1. What joke(s) are you going to animate?
2. What might we include in our storyboard for creating an animated joke?

• What are some of the media we might use in a project like this (pictures, sounds, sprites, backdrops, etc.)?

3. How will your sprites tell or show the joke?

• What code will you use to do that?

4. How might a user interact with the joke?

• How might we use code to create that interaction?

When coders are ready, have them show you their storyboard and ask questions for clarification of their intent (which may change once they start coding and get more ideas). If approved, they may continue on to the next steps (logging in and creating their scenic walk); otherwise they can continue to think through and work on their storyboard.

Resource: Example storyboard templates
Resource: Storyboard questions for displaying
Resource: School appropriate jokes ;)

Note: Some coders do really well with open projects, while others thrive within constraints. It may make more sense to suggest a range of sprites and backdrops so coders aren’t overwhelmed with possibilities. This can also help with better predicting how long it might take to create the story.

Storyboarding Tip: Coders can color their storyboard (or mark with symbols) what they know, have questions about, and don’t know. For example: mark something green if coders know how to create the algorithm for that sprite/action; mark yellow if a coder has questions; mark red if a coder is unsure how to do something.

Suggestion: If coders need additional help, perhaps pair them with someone who might help them with the storyboarding process. Or, you could have coders meet with a peer to discuss their storyboard before asking to share it with yourself. This can be a great way to get academic feedback and ideas from a peer.

5. Talking sprites (15+ minutes):
1+ minute demonstration
Display and demonstrate the sample project (or your own remixed version) one more time. Ask coders to chat with a neighbor about how they might get a sprite to look like it’s talking.

9+ minute reverse engineering
Ask coders to see if they can figure out how to use the paint editor tools and their code blocks to create an algorithm that makes a sprite do something similar to what was demonstrated. Facilitate by walking around and asking guiding questions.

5+ minute demonstration
Walk through each step of the process for creating a talking sprite. Demonstrate one or both methods for moving a mouth or head to simulate talking. Ask coders to image other ways to make a sprite talk (e.g., taking a picture of your mouth in different shapes or expressions). Repeat this process for a couple of sprites and demonstrate how to name the costumes for ease of use.

Create a function using message blocks for moving the sprite’s mouth by switching to the next and previous costumes to simulate talking (see the video or quick reference guide). Point out that we can use this function multiple times by switching to a desired costume and calling our new function to run in parallel with our other code. To stop our function, we simply need to use stop other scripts in sprite blocks when we want to stop the sprite from talking.

Ask how we make sure our sprite doesn’t keep their mouth open when we stop our talking function? (use a switch costume to block to switch to a costume with the mouth closed)

Video: Talking sprites (6:46)
Quick reference guide: Click here

Suggested questions:

• How else could we indicate a sprite is talking in Scratch?
• When should we use text and when should we use recordings to show a talking sprite?
• Why did we use message blocks and not My Blocks?
  • (so we can have this function run in parallel with other code every time a sprite talks)

A note on using the “Coder Resources” with your class: Young coders may need a demonstration (and semi-frequent friendly reminders) for how to navigate a browser with multiple tabs. The reason why is because kids will have at least three tabs open while working on a project: 1) a tab for Scratch, 2) a tab for the Coder Resources walkthrough, and 3) a tab for the video/visual walkthrough for each step in the Coder Resources document. Demonstrate how to navigate between these three tabs and point out that coders will close the video/visual walkthrough once they complete that particular step of a project and open a new tab for the next step or extension. Although this may seem obvious for many adults, we recommend doing this demonstration the first time kids use the Coder Resources and as friendly reminders when needed.

6. Animate your joke(s) (60+ minutes, the majority of at least two classes):
Give coders time to animate their joke(s) by applying their understandings from previous projects to this new project and encourage them to constantly refer back to their storyboard when they’re stuck on what they should do next. Encourage peer-to-peer assistance and facilitate 1-on-1 as needed.

Facilitation Suggestion: Some coders may not thrive in inquiry based approaches to learning, so we can encourage them to use the Tutorials to get more ideas for their projects; however, we may need to remind coders the suggestions provided by Scratch are not specific to our projects, so it may create some unwanted results unless the code is modified to match our own intentions.

Suggested questions:

• How can you use modularity to make your code more organized and easier to read?
• Can you create hidden sprites a user can interact with in your joke?
• Can you make it so the user helps tell a joke?