Ensure all devices are plugged in for charging over night.

(10+ minutes) Read through each part of this lesson plan and decide which sections the coders you work with might be interested in and capable of engaging with in the amount of time you have with them. If using projects with sound, individual headphones are very helpful.

• BootUp ScratchJr Tips
  • Videos and tips on ScratchJr from our YouTube channel
• BootUp Facilitation Tips
  • Videos and tips on facilitating coding classes from our YouTube channel
• Block Descriptions
  • A document that describes each of the blocks used in ScratchJr
• Interface Guide
  • A reference guide that introduces the ScratchJr interface
• Paint Editor Guide
  • A reference guide that introduces features in the paint editor
• Tips and Hints
  • Learn even more tips and hints by the creators of the app
• Coding as another language (CAL)
  • A set of curriculum units for K-2 using both ScratchJr and KIBO robotics
• ScratchJr in Scratch
  • If you’re using ScratchJr in Scratch, this playlist provides helpful tips and resources

2. Discuss (2+ 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 ScratchJr?
• 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 sprites might we use under the sea?
  • What kind of code might they have?

4. Reverse engineering even more ideas (10+ minutes each):

1 minute intro demonstration
Demonstrate one of the following example sprites on the board without displaying the code (they are in order of complexity):

• Spinning starfish
• Moving fish
• Slow whale
• Moving diver
• Growing and shrinking seahorse
• Moving fish with two green flags

4+ minute reverse engineering and peer-to-peer coaching
Ask coders to see if they can figure out how to use 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.

1 minute explanation demonstration
If coders figured out how to get their sprite to do something similar, have them document in their journal, share with a partner, or have a volunteer show the class their code and thought processes that led to the code. Otherwise, reveal the code, walk through each step of the algorithm, and explain any new blocks.

4+ minute application and exploration
Encourage coders to try something similar, and leave your code up on display while they work. Facilitate by walking around and asking questions about how coders might change their code so it’s not the same as yours.

Video: Suggestions for reverse engineering (4:25)

Note: It is not recommended to show each of these ideas at once, but to show one idea, give time for application and exploration, show another idea, give time for application and exploration, etc. This process could take multiple classes. Also, some of these examples may be difficult for young coders, so go slow and encourage copying and modifying code as it’s good practice.

Alternative suggestion: If reverse engineering is too difficult for the coders you work with, you could display the source code and have coders predict what will happen.

Suggested guiding questions:

• What kind of blocks do you think you might need to do something like that?
• Do you see a pattern where we might use a repeat?
• What trigger blocks do you think I used for that sprite?
• Did I use one trigger block or more than one?
  • What makes you think that?

Potential discussion: There is not always one way to recreate something with code, so coders may come up with alternative solutions to your own code. When this occurs, it can open up an interesting discussion or journal reflection on the affordances and constraints of such code.

Suggested application and exploration questions:

• What other code blocks could you use?
• What other sprites might use similar code?