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.

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.

Students will take a sequence of events or steps for some process and create an algorithm. This could apply to any content area. They will display the algorithm in flowchart form. This activity can be modified for all grade levels and content areas.

In this lesson students look at a simple example of how a computer could be used to complete the decision making step of the data problem solving process. Students are given the task of creating an algorithm that could suggest a vacation spot. Students then create rules, or an algorithm, that a computer could use to make this decision automatically. Students share their rules and what choices their rules would make with the class data. They then use their rules on data from their classmates to test whether their rules would make the same decision that a person would. The lesson concludes with a discussion about the benefits and drawbacks of using computers to automate the data problem solving process.

To conclude this unit, students design a recommendation engine based on data that they collect and analyze from their classmates. After looking at an example of a recommendation app, students follow a project guide to complete this multi-day activity. In the first several steps, students choose what choice they want to help the user to make, what data they need to give the recommendation, create a survey, and collect information about their classmates' choices. They then interpret the data and use what they have learned to create the recommendation algorithm. Last, they use their algorithms to make recommendations to a few classmates. Students perform a peer review and make any necessary updates to their projects before preparing a presentation to the class.

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.

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.

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 preparation for this chapter's final project, students will learn how to develop a prototype of a physical object that includes a Circuit Playground. Using a modelled project planning guide, students will learn how to wire a couple of simple circuits and to build prototypes that can communicate the intended design of a product, using cheap and easily found materials such as cardboard and duct tape.

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.

In preparation for delving deeper into programming with App Lab, students will explore how a handful of different programs written in both Game Lab and App Lab handle taking input from the user. After comparing and contrasting the approaches they saw in the example apps, students group up to act out the two different models for input (conditionals in an infinite loop and asynchronous events) to gain a better understanding of how they work.

Students take what they've learned through chapter one, and develop an app of their own design that uses the board to output information.

Students complete two unplugged card sorting activities to explore the meaning of processing and its relationship to problem-solving. The first activity has few constraints and is used to introduce a high-level definition of processing. The next introduces more constraints that force students to develop an algorithm that will always successfully process the cards. Students iteratively develop, test, and share their algorithms with classmates. A wrap-up discussion has students reflect on the different types of problem-solving they used in these activities and the value of producing an algorithm to solve a problem.

This lesson reviews the input, output, storage, and processing aspects of a computer in a context that is relevant and familiar to students: apps. In pairs, students evaluate smartphone applications to analyze the specific problems that they were designed to solve, the inputs that they need to work, and the processing that turns those inputs into the desired output, and what information they would want to store for later. The class concludes with a discussion that connects the lesson to apps students are more familiar with.

To conclude their study of the problem solving process and the input/output/store/process model of a computer, students will propose an app designed to solve a real world problem. This project will be completed across multiple days and will result in students creating a poster highlighting the features of their app that they will present to their classmates. A project guide provides step by step instructions for students and helps them organize their thoughts. The project is designed to be completed in pairs though it can be completed individually.

The primary purpose of developing paper prototypes is that they allow for quick testing and iteration before any code is written. This lesson is focused on giving teams a chance to test their prototypes before moving to App Lab. Teams develop a plan to test with users before running prototype tests with multiple other students in the class (and potentially outside the class). In order to test the prototype with the users, the students will have to assign roles in the testing (the “narrator”, the “computer” and the “observers”) as well as have some questions prepared for the user to answer after the test is complete.

Before starting to design apps, we need to help students to better scope their expectations. Because students will eventually be prototyping these apps in App Lab, they will be in better shape if their ideas align with the kinds of apps that are easily prototyped in App Lab. Teams start this scoping by looking through several example apps designed to demonstrate apps that can be created with App Lab. Teams then can chose one (or more) of the apps as a basis for their own. From there, teams have some time to discuss the basic functionality of their app before using 3x5 index cards to develop paper prototypes.

Following the mini design project, students look towards the next phase of design - prototyping a product that attempts to address user needs. In teams, students examine a paper prototype for a chat app called "Txt Ur Grndkdz". Through using this paper prototype, students get a chance to see how a simple paper prototype can be used to quickly test ideas and assumptions before we ever get to the computer. After "using" the provided prototype students begin to identify ways to improve the next iteration.