One of the reasons I love Scratch as an introductory language is that most blocks are intuitive.  The old “low floor”.  One concept that does need to be explicitly taught is broadcast and receive blocks.  I’ve had difficulty getting students to buy into the use of broadcast and receive blocks over “wait” blocks.  My hunch is that they’re difficult to understand because of the lack of a visual reaction on the Scratch stage.  Besides being able to use broadcast and receive blocks efficiently, I want students to understand:

• Broadcast/receive blocks are not explicitly tied to “say” blocks. Students tend to think a sprite “saying” something is the same as broadcasting that message and the other way around.  I try to stress that it’s more of a “secret signal”.
• When a sprite broadcasts a message, another sprite must receive it and respond with an action.
• The same message can be broadcast and received multiple times.

Unplugged activities to the rescue!  Traditionally, I lead students through an exercise in which they’re each told to wait a certain amount of seconds before doing their task and it devolves into the chaos intended.  Then, they repeat the activity, but are told to wait until they see someone complete a specific task and respond with their action.  Though it usually takes a few tries, proves to be a much more organized sequence of events. (Print out the list of actions and cut into slips for the students to pick from a cup.  Make sure you make a cup for each activity and keep them separate.)  I am then able to use this as a reference when I demonstrate the code.

In order to accommodate the possibility of some or all of my students being remote this year, I thought I’d mix it up.  Before class, I got a short coding picture book from the library (How to Code a Sandcastle by Josh Funk) and I asked a few students to go “undercover” for me.  One, I asked to stand up and spin around every time I turned a page.  Another I told to clap twice when I turned a page.  A third, I told to wave their hand when I said the robot’s name.  I really wanted to stress the idea of this being a secret message that only a few sprites might be “listening” for and that it could happen multiple times.  After discussing what “strange” behavior they saw from their classmates during the reading, I introduced and demonstrated broadcast and receive blocks using a short conversation between two random sprites.

Though they’re still working on their project in which they will use this skill (Interview with a Changemaker), the first day of coding was much more successful than in the past.  I think I can attribute this to a few key details:

• Just-in-time learning – After introducing the project, I give them the first class period to do their research, collect their sprites, etc.  I wait to introduce the coding concepts until right before they’re ready to use them.
• Using the right language – I stress that this is a secret message that we can’t see or hear.  This helps differentiate between the action that is happening and the broadcast message.
• Model good message names – When I show them examples, I talk about how valuable the name of the message will be when organizing your code.  I usually model the name of the message being what just happened, but you could also have the students get in the habit of naming the message what is about to happen.
• Refer back to unplugged activity – As students debugged and asked questions, I reminded them of their classmate’s actions during the story.

These lessons are always a work in progress.  I’d love to hear about other ways to introduce such an abstract concept to 5th grade!