The true tale of the Recycled Orchestra of Paraguay, an orchestra made up of children playing instruments built from recycled trash. The resources includes a lesson plan/book card, a design challenge, and copy of a design thinking journal that provide guidance on using the book to inspire students' curiosity for design thinking. Maker Challenge: Students will create their own musical instruments with recyclable materials.

A document is included in the resources folder that lists the complete standards-alignment for this book activity.

Tony Sarg was a puppeteer and marionette master who invented the first, larger than life, helium balloons for the annual Macy’s Thanksgiving Day Parade. The resource includes a lesson plan/book card, a design challenge, and copy of a design thinking journal that provide guidance on using the book to inspire students' curiosity for design thinking. Maker Challenges include: (1) Dash/Sphero: Develop a Macy’s Day Parade route using tape on the ground with a partner. Then, switch routes with another group and program the robot of your choice to navigate the parade route using code. (2) Ozobot: Develop a synchronized dance routine for both Ozobots for the stage of the Macy’s day parade using https://ozoblockly.com/editor (3) Create a moveable puppet that will be featured in the Macy’s Day Parade.

A document is included in the resources folder that lists the complete standards-alignment for this book activity.

The true, inspiring story of Beauty, the bald eagle, who was shot, rescued, and received a 3D-printed prosthetic beak. The resource includes a lesson plan/book card, a design challenge, and copy of a design thinking journal that provide guidance on using the book to inspire students' curiosity for design thinking. Maker Challenges: (1) Use paper and pencil to design a prosthetic body part for a human or animal. Then use tinkercad.com to create a prototype. Finally, use a 3D printer to print the prosthetic. (2) Have students research animals who use prosthetics. Then, improve the design in Tinkercad and 3D Print.

A document is included in the resources folder that lists the complete standards-alignment for this book activity.

Using scrap metal and spare parts, William Kamkwamba created a windmill to harness the wind and bring electricity and running water to his Malawian village. The resource includes a lesson plan/book card, a design challenge, and copy of a design thinking journal that provide guidance on using the book to inspire students' curiosity for design thinking. Maker Challenge: Develop a way to harness the wind by designing with Strawbees.

A document is included in the resources folder that lists the complete standards-alignment for this book activity.

Ralph Baer’s family fled Nazi Germany for the US when he was a child. Using wartime technology, Baer thought outside the box and transformed the television into a vehicle for gaming. His invention was the birth of the first home console, the Odyssey, a precursor to the Atari gaming system. The resource includes a lesson plan/book card, a design challenge, and copy of a design thinking journal that provide guidance on using the book to inspire students' curiosity for design thinking. Maker Challenges: (1) Think outside the box. What’s something you use everyday, but not for its “intended” purpose? Examples: A broom to clean the snow off your car windshield, a trash bag as a sled. Now, think of a problem you might have at school, home, et al. Invent an item that would solve this problem. (2) Let’s think outside the box! Design the latest and greatest technology for kids to hit the market! Make it the *most* fun anyone has ever had. You may NOT use anything on the market - any technology currently on the market is off limits. Use your imagination, do not put limitations on it, and be as creative as you can. (3) Use household items to create a prototype of your new invention.

A document is included in the resources folder that lists the complete standards-alignment for this book activity.

In this lesson students design a structure to represent their perfect day using the binary representation systems they've learned in this chapter. Students will first write a short description of their perfect day and then review with a partner to identify the key pieces of information they think a computer could capture. As a class students will decide how a punch card of bytes of information will be interpreted to represent those pieces of information. Students will then use the ASCII, binary number, and image formats they have learned to represent their perfect days. Students then trade punch cards and try to decode what the other student's perfect day is like. The lesson ends with a reflection.

In this multi-day lesson, students use the problem solving process from Unit 1 to create a platform jumper game. They start by looking at an example of a platform jumper, then define what their games will look like. Next, they use a structured process to plan the backgrounds, variables, sprites, and functions they will need to implement their game. After writing the code for the game, students will reflect on how the game could be improved, and implement those changes.

Students will plan and build their own game using the project guide from the previous two lessons to guide their project. Working individually or in pairs, students will first decide on the type of game they'd like to build, taking as inspiration a set of sample games. They will then complete a blank project guide where they will describe the game's behavior and scope out the variables, sprites, and functions they'll need to build. In Code Studio, a series of levels prompts them on a general sequence they can use to implement this plan. Partway through the process, students will share their projects for peer review and will incorporate feedback as they finish their game. At the end of the lesson, students will share their completed games with their classmates. This project will span multiple classes and can easily take anywhere from 3-5 class periods.

Students explore the challenges of communicating how to draw with shapes and use a tool that introduces how this problem is approached in Game Lab. The warm up activity quickly demonstrates the challenges of communicating position without some shared reference point. In the main activity students explore a Game Lab tool that allows students to interactively place shapes on Game Lab's 400 by 400 grid. They then take turns instructing a partner how to draw a hidden image using this tool, accounting for many challenges students will encounter when programming in Game Lab. Students optionally create their own image to communicate before a debrief discussion.

This lesson introduces students to the process they will use to design games for the remainder of the unit. This process is centered around a project guide which asks students to define their sprites, variables, and functions before they begin programming their game. In this lesson students begin by playing a game on Game Lab where the code is hidden. They discuss what they think the sprites, variables, and functions would need to be to make the game. They are then given a completed project guide which shows one way to implement the game. Students are then walked through this process through a series of levels. As part of this lesson students also briefly learn to use multi-frame animations in Game Lab. At the end of the lesson students have an opportunity to make improvements to the game to make it their own.

Students are introduced to Game Lab, the programming environment for this unit, and begin to use it to position shapes on the screen. They learn the basics of sequencing and debugging, as well as a few simple commands. At the end of the lesson, students will be able to program images like the ones they made with the drawing tool in the previous lesson.

In this lesson students continue to develop their familiarity with Game Lab by manipulating the width and height of the shapes they use to draw. The lesson kicks off with a discussion that connects expanded block functionality (e.g. different sized shapes) with the need for more block inputs, or "parameters". Students learn to draw with versions of `ellipse()` and `rect()` that include width and height parameters. They also learn to use the `background()` block. At the end of the progression students are introduced to the `randomNumber()` block. Combining all of these skills students will draw a randomized rainbow snake at the end of the lesson.

In this lesson students learn how to use variables to label a number in their program or save a randomly generated value. Students begin the lesson with a very basic description of the purpose of a variable. Students then complete a level progression that reinforces the model of a variable as a way to label or name a number. Students use variables to save a random number to see that variables actually store or save their values, allowing them to use the same random number multiple times in their programs.

Using a _for loop_ to iterate over all of the elements in an array is a really useful construct in most programming languages. In this lesson, students learn the basics of how a _for loop_ can be used to repeat code, and then combine it with what they've already learned about arrays to write programs that process all elements in an array. Students use for loops to go through each element in a list one at a time without having to write code for each element. Towards the end of the lesson students will apply this with the `colorLed` list on the board to create an app that changes all of the LEDs each time a button is clicked.

In this final project for the course, students team to develop and test a prototype for an innovative computing device based on the Circuit Playground. Using the inputs and outputs available on the board, groups will create programs that allow for interesting and unique user interactions.

An array is an ordered collection of items, usually of the same type. In this lesson, students learn ways to access either a specific or random value from a list using its index. They then learn how to access the colorLEDs array that controls the behavior of the color LEDs on the Circuit Playground. Students will control the color and intensity of each LED, then use what they have learned to program light patterns to create a light show on their Circuit Playground.

In Unit 4 students learned a very simple approach to app development in App Lab that required a separate screen for most interactions. To expand the kinds of apps that students can make, and to encourage them to think in new ways about how users interact with apps, we introduce the `setProperty()` block. This command can be used to set the content and properties of various UI elements, allowing students to write programs that update information on a single screen, instead of manually creating duplicate screens. In this lesson students build up simple apps that only require a single screen, the content of which is changed using `setProperty()`.

In this lesson students get their first opportunity to write programs that use the Circuit Playground. After first inspecting the board visually and hypothesizing possibly functionalities, students move online where they will learn to write applications that control an LED. By combining App Lab screens with the Circuit Playgrounds, students can gradually start to integrate elements of the board as an ouput device while relying on App Lab for user input.

This lesson transitions students from consider the Circuit Playground as strictly an output device towards using it as a tool for both input and output. Starting with the hardware buttons and switch,sing the hardware buttons and switch, students learn to use `onBoardEvent()`, analogously to `onEvent()`, in order to take input from their Circuit Playgrounds.

In this lesson, students explore how the three analog sensors (sound, light, and temperature) can be used to write programs that respond to changes in the environment. The use of these sensors marks a transition in terms of how users interact with a program. By using sensors as an input, the user of an app doesn't have to directly interact with it at all, or may interact without actually realizing they are doing so.