This lesson demonstrates how a slight manipulation of a conditional statement can allow for the creation of a new and powerful tool in constructing programs, a **while** loop. Students are introduced to a **while** loop by analyzing the flow chart of a conditional statement in which the "true" branch leads back to the original condition. Students design their own flowcharts to represent a real-world situation that could be represented as a **while** loop, and they learn how to recognize common looping structures, most notably infinite loops. Students then move to App Lab, creating a **while** loop that runs exactly some predetermined number of times. While learning about creating **while** loops, students will be introduced to many of the common mistakes early programmers make with **while** loops and will be asked to debug small programs. They finally progress to putting if statements inside a while loop to count the number of times an event occurs **while** repeating the same action. This activity will recall the need for counter variables and foreshadows their further use in the following lesson.

In this lesson, students gain more practice using **while** loops as they develop a simulation that repeatedly flips coins until certain conditions are met. The lesson begins with an unplugged activity in which students flip a coin until they get 5 heads in total, and then again until they get 3 heads in a row. They will then compete to predict the highest outcome in the class for each statistic. This activity motivates the programming component of the lesson in which students develop a program that allows them to simulate this experiment for higher numbers of heads and longer streaks.

This lesson introduces arrays as a means of storing lists of information within a program. The class begins by highlighting the difficulties that arise when trying to store lists of information in a variable. Students then watch a short video introducing arrays and a subset of the operations that can be performed with them. Students will work in Code Studio for the remainder of the class as they practice using arrays in their programs. At the conclusion of the sequence, students build a simple app which can be used to store and cycle through a list of their favorite things. In the next lesson, students will continue working with a version of this app that can display images and not just text strings.

Students will extend the **My Favorite Things** app they built in the previous lesson so that it now manages and displays a collection of images and responds to key events. Students are introduced to the practice of refactoring code in order to keep programs consistent and remove redundancies when adding new functionality. As part of learning to use key events, students are shown that event handlers pass a parameter which contains additional information about the event. This lesson also serves as further practice at using arrays in programs.

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.