This lesson will probably take two days to complete. It introduces students to algorithms that process lists of data. The students will do two unplugged activities related to algorithms and program some of them themselves in App Lab. The **for** loop is re-introduced to implement these algorithms because it’s straightforward to use to process all the elements of a list. The lesson begins with an unplugged activity in which students write an algorithm to find the minimum value in a hand of cards. Students then move to Code Studio to write programs that use loops and arrays. Students are shown how to use a **for** loop to visit every element in an array. Students use this pattern to process an array in increasingly complex ways. At the end of the progression, students will write functions which process arrays to find or alter information, including finding the minimum value - a problem they worked on in the unplugged activity. Finally, an unplugged activity has students reason about linear vs. binary search and attempt to write pseudocode for a binary search.

In this lesson students are introduced to the **return** command and learn to write their own functions that return values. Students first complete a simple unplugged activity based on the game **Go Fish** to introduce the concept of a return value. They will then complete a short sequence of exercises in Code Studio, which introduces preferred patterns for writing functions that return values. At the end of the sequence, students write and use functions that return values in a simple turtle driver app.

To conclude their introduction to programming, students will design an app based off of one they have previously worked on in the programming unit. Students will choose the kinds of improvements they wish to make to a past project in order to show their ability to make abstractions and implement complex algorithms. The project concludes with reflection questions similar to those students will see on the AP® Create Performance Task. Students can either complete the project individually or with a partner. Every student will need a collaborative partner with whom they will give and receive feedback.

Students continue to practice working with arrays and are introduced to a new user interface element, the canvas. The canvas includes commands for drawing simple geometric shapes (circles, rectangles, lines) and also triggers mouse and key events like any other user interface element. Over the course of the lesson, students combine these features to make an app that allows a user to draw an image while recording every dot drawn on the canvas in an array. By processing this array in different ways, the app will allow students to redraw their image in different styles, like random, spray paint, and sketching. Along the way, students use their knowledge of functions with return values to make code which is easy to manage and reuse.

Students will be introduced to a new feature of App Lab: **Design Mode**. Design Mode allows students to easily design the User Interface (UI) of their apps using a drag-and-drop editor. Students learn how to create UI elements they have seen before such as images, text labels and buttons, but they will see many more options for styling these elements with colors, font sizes and so on. Students also learn how to add **event handlers** - code that listens for and responds to user-events. Students also explore some common errors that come up in event-driven programming and will learn some important skills for debugging programs, chief among them being responding to error messages. Students end the lesson by creating the foundation of a simple "chaser game" which they will add onto in the next lesson.

Students continue learning about Event Driven programming in this lesson by learning how to add multiple "screens" to an app and adding code to switch between them. More techniques of debugging are presented, namely using `console.log`, a command that allows them to print out text which the user cannot see. It is useful for displaying messages to yourself to figure out what is happening as your program runs. Students will end the lesson by creating an improved version of the “chaser” game which has multiple screens.

This lesson gives students time to familiarize themselves with the process of making event-driven apps before we move on to deeper content. They will design and create a (minimum) 4-screen app on a topic of their choosing. There are some other constraints on the project to help guide students in their thinking. Students are also encouraged to do independent work, but alongside a "coding buddy" or "thought partner" to be a help along the way.

**Note:** This activity **is not intended to be a Practice PT** but could be used similarly. The aim is to give an opportunity to get comfortable with Design Mode and the structure of event-driven programming in a creative way. Another goal is to intentionally build in an environment of informal collaboration, even when doing individual work. Suggestions for containing the scope of the project and amount of time allocated to it can be found in the lesson plan.

This lesson gets into the basic mechanics of working with variables in programs. The lesson shows students how to create and assign values to variables and navigates through a series of common misconceptions about variables and how they work. Along the way, the lesson tries to build up the student’s mental model of how computers and programs work, which is essential for being able to reason about programs.

In this lesson, students add variables to two different exemplar apps to keep track of a score, or a count of some number of button clicks. The major topic is **variable scope** and understanding the differences, benefits, and drawbacks, of using global versus local variables. This lesson focuses more on using global variables, since in event-driven apps that’s what you need to keep track of data across multiple events.

The very basics of a **simple if statement** are also presented in this lesson, mostly to highlight the difference between the = and == operators. Finally, students are asked to apply what they’ve learned about variables, scope, and if statements, to make their own “clicker” game modeled after one of the exemplars they saw during the lesson.

In this lesson, students are introduced to the string data type as a way of representing arbitrary sequences of ASCII characters. They will use strings to accept input from a user as they work on mastering two new UI elements, the text input and the text area. Students combine these skills to develop a simple Mad Libs® app.

_Mad Libs® is a trademark of the Penguin Group (USA) LLC., which does not sponsor, authorize or endorse this site._

We take a whole lesson to learn about `if` statements, what they are, the terminology around them, and what they have to do with "selection" in programs. Students trace simple robot programs on paper to develop a sense of how to read and reason about code with `if` statements in it. Students also try their hand at writing code by hand to handle a robot situation.

In this lesson, students write `if` and `if-else` statements in JavaScript for the first time. The concepts of conditional execution should carry over from the previous lesson, leaving this lesson to get into the nitty gritty details of writing working code. Students will write code in a series of "toy" problems setup for them in App Lab that require students to do everything from debug common problems, write simple programs that output to the console, or implement the conditional logic into an existing app or game, like "Password Checker" or a simple Dice Game. The lesson ends with a problem requiring nested `if` statements to foreshadow the next lesson.

In this lesson, students will be introduced to the boolean (logic) operators NOT, AND, and OR as tools for creating compound boolean conditions in if statements. Students will learn how to more efficiently express complex logic using AND and OR, rather than deeply nested or chained conditionals. Students will work through a worksheet that covers the basics and a few problems with evaluating logical expressions, then write code in App Lab to practice using && and || in if statements. Finally, students will improve the Movie Bot so it can respond to multiple keywords and provide recommendations based on both the genre and rating provided by the user.

This lesson contains a series of activities you can use to help students familiarize themselves with Explore Performance Task, how it is scored, and some example tasks provided by the College Board.

Students review the Submission Requirements and Scoring Guidelines for the Explore PT. Subsequently they review three example scored Explore PT submissions with commentary to better understand how the Submission Requirements and Scoring Guidelines are used together. In a wrap-up conversation they identify a piece of advice, a "gotcha", and a remaining question they have about the Explore PT.

Note: Most the exemplar task, scores, and commentary on scoring shared in this lesson come directly from the College Board. Code.org's commentary is noted where applicable.

This lesson uses the [r explore-pt-survival-guide] as the backbone for a series of activities to ramp up to doing the actual Explore PT. It contains some brainstorming activities around what qualifies as a "computing innovation" for the task as well practical advice and strategies for handling some of the nuances of the task such as distinguising between a "harmful effect" and a "data security or privacy concern."

The lesson concludes by providing students with resources to make a plan to complete the task staring in the next lesson.

It is finally time for students to take on the Explore Performance Task. For a minimum of 8 class hours, students should work on their projects with only types of teacher support allowed (essentially: Advise on process, don’t influence or evaluate ideas).

The lesson includes reminders about how you can interact with students while they are working on their projects, and suggestions about time line. The Explore PT requires a minimum of 8 hours of class time. At the end, students will submit their computational artifact and written responses through their AP digital portfolio.

This lesson contains a series of activities you can use to help students familiarize themselves with Create Performance Task, how it is scored, and some example tasks provided by the College Board.

Students review the Submission Requirements and Scoring Guidelines for the Create PT. Subsequently they review three example scored Create PT submissions with commentary to better understand how the Submission Requirements and Scoring Guidelines are used together. In a wrap-up conversation they identify a piece of advice, a "gotcha", and a remaining question they have about the Create PT.

Note: Much the sample tasks, scores, and commentary on scoring shared in this lesson come directly from the College Board. Code.org's commentary is noted where applicable.

This lesson uses the [r create-pt-survival-guide] as the backbone for a series of activities to ramp up to doing the actual Create PT. It contains activities to help students understand the algorithm and abstraction requirements of the task, as well as activities to help them narrow down and brainstorm ideas for their actual project.

The lesson concludes by providing students with resources to make a plan to complete the task staring in the next lesson.

It is finally time for students to take on the Create Performance Task. For a total of 12 class hours, students should work on their projects with only types of teacher support allowed (essentially: Advise on process, don’t influence or evaluate ideas). Students may also work with a collaborative partner in *in development of their program* - written responses must be done on their own.

The lesson includes reminders about how you can interact with students while they are working on their projects, and suggestions about time line. The Create PT requires a minimum of 12 hours of class time. At the end, students will submit their program code, program video, and written responses through their AP digital portfolio.

In this kickoff to the Data Unit, students begin thinking about how data is collected and what can be learned from it. To begin the lesson, students will take a short online quiz that supposedly determines something interesting or funny about their personality. Afterwards they will brainstorm other sources of data in the world around them, leading to a discussion of how that data is collected. This discussion motivates the introduction of the Class Data Tracker project that will run through the second half of this unit. Students will take the survey for the first time and be shown what the results will look like. To close the class, students will make predictions of what they will find when all the data has been collected in a couple weeks.