Now that we've started in on Scratch, we're going whole hog! Our last lesson, we took some time to create Scratch accounts and explore the interface with our incredible Makey Makey kits. Now, we're starting to focus on the nitty-gritty of using the interface to make our own projects.
At this point, we're switching over from code.org's lessons to Scratch's Creative Computing curriculum. It's an excellent sequence of lessons that start with exploration and gradually expand horizons to investigate animations, story telling, and interactive programs. The lessons are mostly self-paced, with some brief whole-class intros done before sending kids off to apply skills.
Since we had already created accounts, we were able to, for the most part, skip the Unit 0 activities. In two classes, we did Scratch Surprise and Critique Group lessons first; however, I found that students really had a hard time figuring out how to use Scratch and give/receive feedback, so now I'm skipping around instead. Today, we did Step-By-Step and 10 Blocks lessons.
I began with a brief presentation outlining our objectives for the lesson and providing an overview of the process students would use. This took only about five minutes and was really just an opportunity for me to provide a little closer guidance for students to know where and how to start.
Then, I sent students off to complete the Step By Step project. I ran two-sided copies of the student activity sheets for this and the 10 Blocks lessons so kids could get a little more help if needed.
Step By Step is dead simple for the teacher: essentially, there's a 13-step tutorial already built into Scratch that students follow to complete their first project. It shows them the different types of blocks, has them experiment with a few steps, and gives us a good entry into sharing projects in studios.
After students completed their tutorial projects, I showed them how to share their project. Students were required to include their first name in their project title, give instructions on how to interact with their program, and credit themselves so others knew who created the program. Then, I created studios in advance that were labeled with the teacher name and the challenge. Students had to go to that URL and figure out how to add their project (it's as easy as clicking the big grey "ADD PROJECTS" button!).
Students finished this first tutorial at varying times. Some kids have personal Scratch accounts already and are experienced, so they flew through the tutorial; others were first-timers and needed more time to complete. Whatever the case, students could start right in on their 10 Block challenge when they finished.
In this challenge, students can use as many sprites (the various 2-d character images that make up most projects) and backdrops as they want, but they are limited to only using 10 types of blocks to create something interesting. This restriction helped force kids to get creative with how they could implement a vision they had in their minds with only a certain set of resources. Once finished, they once again shared their projects and added them to another studio I had set up already.
It was a pretty tight squeeze fitting all this into one hour. In the future, I'll probable stretch this out over two days, or plan longer blocks of time to allow kids more time to create their 10 Block projects. Another thing I'm considering is progressing through the curriculum as planned, but setting aside one day here and there to go back to prior programs and build on what they've done already.
The other big issue I'm running into with Scratch is this: it's so open, and kids are so excited to make projects, that they're getting way off task. Several times today, I had to redirect students to complete the tutorial as it's written instead of going off and doing their own thing. Looking through the Step By Step studios I made for different classes, I can tell quickly that several students didn't follow the tutorial at all!
While I do want to encourage their creativity and build off their interests, I also want to make sure they are exposed to a variety of project types so that they don't just continue to do a limited number of things on Scratch. If all they ever use are "when space key is pressed, say 'Hello!'" blocks, they may not uncover to cool story/movie projects, or educational simulations, or another unique project type that you can discover by learning the platform well.
I'm struggling with how to rein kids back in. I could start assessing their projects in the studio for how strongly they applied the focus for the lesson, but I'm hesitant scoring creative pieces. I'm constantly circulating around the room, check in individuals, but it's easy to pass right by students who are working hard on something that has nothing to do with what we're learning that day. I need to figure out SOME platform for holding students accountable for learning, practicing, and applying these fundamental pieces before moving onto their own interests...
Any ideas?
Friday, November 21, 2014
Monday, November 17, 2014
Computer Science Day 12 - The Moment We've Been Waiting For...
Today was a HUGE day.
So far, students have been learning computer programming through code.org's excellent course materials. They've learned how to create algorithms to complete various tasks, they used loops to write cleaner, more efficient code, and they've learned conditional statements to make interactive, "smarter" programs. However, all of their experience up to this point has been in completing pre-defined tasks that code.org has created.
Today, the students themselves were able to create.
This summer, I was able to work as a Mobile App Developer for a company called FX Palo Alto Laboratories. I was placed through via this amazing organization called IISME (Industry Initiatives for Science and Math Education). Basically, you apply through IISME, who partners with a ton of various companies in the Bay Area (and other markets as well) to place teachers in summer fellowships. It was an incredible experience, and one that I whole-heartedly recommend to every teacher who has a free summer.
IISME also funds a grant called the Fund for Innovation. I applied this fall and was selected to receive a grant to purchase pedometers for a separate sixth grade PBL project (I may blog about that and other PBL-related adventures somewhere else) and Makey Makey kits.
If you haven't heard of a Makey Makey, go to their website now and watch their videos. You simply have to check this thing out. If you're at all interested in computer science or electronics, do it. Do it now.
I'd heard of the Makey Makey, and had bought one for myself, but it wasn't until I saw on Twitter that Makey Makeys were being used to control Scratch projects. I immediately thought of the possibilities for students to get creative, making a program in Scratch and then creating some hugely imaginative interaction system that would captivate users. The Fund For Innovation grant made this possible - I was able to purchase 16 kits, meaning students in classes could pair up and program something cool.
Well, it was like Christmas morning last week: the kits arrived.
I had planned on teaching code.org's The Big Event lesson to teach students about event handlers. I scrapped that - instead, I quickly showed students how to grab event listener blocks in Scratch for various key presses, just enough to get by, then spent time with the Makey Makeys.
First up: we needed to create Scratch accounts. Every student got a laptop, went to scratch.mit.edu, and created their user account (using their teacher's e-mail address for parent/guardian e-mail). Then, half the class signed out again and returned their laptop. The rest of the class simply closed their laptop screens and followed along with me at the front.
I started with the board on its own first, without showing them any videos. This allowed me to keep their attention as we briefly discussed electronics. We looked at the board, its labels, etc. I explained to students how it basically works - when plugged into a computer, the Makey Makey appears as a keyboard. Then, as you close circuits attached to various parts of the board, the computer just thinks a particular key was pressed. I drew a simple circuit diagram on the board and talked about electron flow and current (confession: I'm really not strong with electronics, so I kept it vague so as not to mislead students). This was all just a way of communicating to students that in order for current to flow, the circuit must be closed. I drew an example of what that might look like and emphasized to the class that if I want to make an interactive banana, I must hook myself up to ground, the banana up to "space bar", and then touch the banana.
We discussed a few possibilities, then I showed them the video. As with everyone who has seen the demo video, the kids were floored. It looked like magic!
At this point, many kids were DYING to get a kit and begin. So I let them! This was mainly an exploration day, an opportunity for them to get acquainted both with Scratch and with the Makey Makey. Kids ran into all kinds of obstacles, the most common of which was not closing the circuit properly (I don't know how many kids connected an alligator clip to a pencil drawing only and then complained that it wasn't doing anything when they touched it; they hadn't hooked themselves up to ground!)
All in all, though, kids were free to start coming up with different ways of interacting with Scratch programs. One pair created interactive hair; several groups drew game pads using pencils and paper that controlled the Scratch Cat; many groups high-fived each other to a variety of sounds; one pair made paper clip drums.
This was all over the course of 25 minutes to 45 minutes. Not a lot of time, since this was our first intro experience, but it was enough for students to figure out how to make stuff happen in Scratch and test out a variety of materials to see if they could get their Makey Makey working.
I am SO excited now to see what students come up with! I've already heard of one pair of students planning on making an interactive map of the world to play a geography quiz game!
At this point, we're pretty much done with code.org. I've opened up the site to students to work on at home (they could do that all along, but I told them not to when we first started) so that they can continue practicing on their own. At this point, though, we're going to make a switch over to Scratch's Creative Computing curriculum. We'll explore how Scratch works and practice a variety of skills, then begin working on students' own projects when we come back from Christmas break.
I really can't remember a time when students were so excited, engaged, and productive; and I'm really looking forward to doing this same lesson in four more classes to see what else they can come up with!
Next up: Scratch Surprise and sharing/gathering feedback using Scratch Studios!
So far, students have been learning computer programming through code.org's excellent course materials. They've learned how to create algorithms to complete various tasks, they used loops to write cleaner, more efficient code, and they've learned conditional statements to make interactive, "smarter" programs. However, all of their experience up to this point has been in completing pre-defined tasks that code.org has created.
Today, the students themselves were able to create.
 |
| from http://gotomarketguy.com/genba-magic-happens/ |
IISME also funds a grant called the Fund for Innovation. I applied this fall and was selected to receive a grant to purchase pedometers for a separate sixth grade PBL project (I may blog about that and other PBL-related adventures somewhere else) and Makey Makey kits.
If you haven't heard of a Makey Makey, go to their website now and watch their videos. You simply have to check this thing out. If you're at all interested in computer science or electronics, do it. Do it now.
I'd heard of the Makey Makey, and had bought one for myself, but it wasn't until I saw on Twitter that Makey Makeys were being used to control Scratch projects. I immediately thought of the possibilities for students to get creative, making a program in Scratch and then creating some hugely imaginative interaction system that would captivate users. The Fund For Innovation grant made this possible - I was able to purchase 16 kits, meaning students in classes could pair up and program something cool.
Well, it was like Christmas morning last week: the kits arrived.
I had planned on teaching code.org's The Big Event lesson to teach students about event handlers. I scrapped that - instead, I quickly showed students how to grab event listener blocks in Scratch for various key presses, just enough to get by, then spent time with the Makey Makeys.
First up: we needed to create Scratch accounts. Every student got a laptop, went to scratch.mit.edu, and created their user account (using their teacher's e-mail address for parent/guardian e-mail). Then, half the class signed out again and returned their laptop. The rest of the class simply closed their laptop screens and followed along with me at the front.
I started with the board on its own first, without showing them any videos. This allowed me to keep their attention as we briefly discussed electronics. We looked at the board, its labels, etc. I explained to students how it basically works - when plugged into a computer, the Makey Makey appears as a keyboard. Then, as you close circuits attached to various parts of the board, the computer just thinks a particular key was pressed. I drew a simple circuit diagram on the board and talked about electron flow and current (confession: I'm really not strong with electronics, so I kept it vague so as not to mislead students). This was all just a way of communicating to students that in order for current to flow, the circuit must be closed. I drew an example of what that might look like and emphasized to the class that if I want to make an interactive banana, I must hook myself up to ground, the banana up to "space bar", and then touch the banana.
We discussed a few possibilities, then I showed them the video. As with everyone who has seen the demo video, the kids were floored. It looked like magic!
All in all, though, kids were free to start coming up with different ways of interacting with Scratch programs. One pair created interactive hair; several groups drew game pads using pencils and paper that controlled the Scratch Cat; many groups high-fived each other to a variety of sounds; one pair made paper clip drums.
This was all over the course of 25 minutes to 45 minutes. Not a lot of time, since this was our first intro experience, but it was enough for students to figure out how to make stuff happen in Scratch and test out a variety of materials to see if they could get their Makey Makey working.
I am SO excited now to see what students come up with! I've already heard of one pair of students planning on making an interactive map of the world to play a geography quiz game!
At this point, we're pretty much done with code.org. I've opened up the site to students to work on at home (they could do that all along, but I told them not to when we first started) so that they can continue practicing on their own. At this point, though, we're going to make a switch over to Scratch's Creative Computing curriculum. We'll explore how Scratch works and practice a variety of skills, then begin working on students' own projects when we come back from Christmas break.
I really can't remember a time when students were so excited, engaged, and productive; and I'm really looking forward to doing this same lesson in four more classes to see what else they can come up with!
Next up: Scratch Surprise and sharing/gathering feedback using Scratch Studios!
Friday, November 14, 2014
Computer Science Day 11 - Coding with Cards
We're getting into the good code.org stuff now - last time's relay programming lesson was used practically as-is, and so was this lesson.
The implications of what students learn in this lessons are huge; once students learn how to use conditional statements (if and if-else statements), there's a whole world of potential applications they can write. This is really where their programs start to become more interactive and interesting. They can create a program such that it's not always doing the same things every time!
However, there's a very low entry point for conditionals. They can seem deceptively simple and easy to master. In one class, I started the whole lesson with one simple if statement, and kids instantly knew what to do:
if (student) {
sitDown();
clearDesk();
beQuiet();
}
This was not rocket science, but we took the time to discuss what everyone did in the class. We all - teachers included - did a check. Then, based on the results of that check, we either sat down, got quiet, and cleared our desks, or we did nothing.
This was an important point: teachers evaluated the condition and, when we realized it was not true, we skipped ALL of the commands in curly brackets. They didn't apply to us. This comes back later in the lesson...
In two of my classes, it just so happened that this lesson took place on a dress-up spirit day. This was an excellent opportunity to bring in something familiar and interesting to the class:
if (dressedForSpiritDay) {
standUp();
}
Another statement, another simple response from the class. At this point, we needed to move things along a bit:
if (dressedForSpiritDay) {
standUp();
} else {
facePalm();
}
The if-else statement was also not too tricky - if the "if" condition is false, you run the "else" set of commands. If the "if" condition is true, you run its set and skip the "else" set. We talked about how this created a situation in which EVERYONE did something. There was no longer a chunk of the class that did nothing. When might this be useful? What's the result of adding the "else" set? Kids discussed quickly while I listened in.
We took a quick step back and talked about how these conditionals are used in programs kids use every day, about how conditionals are pretty much the foundation of games! In Mario Bros., IF you land on the top of a goomba, it dies. IF you the timer runs to zero, you die. After you die, IF you don't have more than one life, it's game over; else, you lose a life.
Now, I really had 'em hooked!
The trickiest part of this lesson was nesting conditionals. This time, I used students' birthdays:
if (birthdayIsInSummer) {
if (birthdayIsInJuly) {
say("Happy birthday to me!");
} else {
standUp();
}
}
Kids started to stumble at this point. MANY students stood up, even though they had September or January birthdays. Some didn't, though, and I thought they had caught on. I asked them to explain why they weren't standing.
I'm really trying to step back from student conversations in class over the course of these lessons. When I ask a challenging question to the class, I'm doing my best to not step in and say, "Yes, you're right!" Instead, I continue asking, "Who agrees? Who disagrees? Why?" until the majority of the class seems to get it. This has led to some pretty interesting class discussions. Kids participate more (and MORE kids participate more) as they try to make sense of what their classmates are saying. It's kind of sad - it seems like, most of the time, students don't pay attention to what their peers are saying, they only tune into the teacher to hear what's correct or incorrect. I'm really trying to remove that crutch so that they have to work a little harder making sense of new information.
Eventually, students reached the understanding that if the outer statement is false (your birthday is not in summer), you skip EVERYTHING inside its brackets. That means that if birthdayIsInSummer is false for you, you don't do ANYTHING. You don't stand up, because you never even reach the birthdayIsInJuly check - you've skipped it because your birthday isn't in summer!
Next, I introduced some of the code.org Conditionals with Cards games from online. I used one deck of cards, and we did some teacher vs. class games starting with the simplest rules:
if (card.color == RED) {
points.yours += 1;
} else {
points.other += 1;
}
This was very easy to understand, and a very boring game. It's too simple! We went to the next version:
if (card.color == RED) {
points.yours += 1;
} else {
if (card.value > 9) {
points.other += 1;
else {
points.yours = points.yours + card.value;
}
}
With a couple of rounds of play, students really started to get how to evaluate situations and determine what should happen when various cards were pulled. We played the game for a few minutes until most of the students were able to accurately describe how points were scored.
Then, I introduced them to a game I came up with last year when we reached this point: Find the Queen! It's a bit trickier than the others since it also uses a while loop, but the students were able to figure it out pretty quickly. We talked about some errors and things that could be improved (it currently never ends, since you always end up pulling a card that causes you to re-shuffle the deck), then played a few rounds. With if's inside of if's inside of a while loop, it challenged students to figure out how to navigate through the code. However, once we got into a groove and students saw how to check line by line, skipping chunks of code when a condition was false, students were more successful.
Ideally, with more time, I'd like to have students make up some of their own games and write them using Javascript-ish pseudocode. However, we were crunched for time as it was and couldn't keep going.
Maybe this will be something we come back to after Scratch...
The implications of what students learn in this lessons are huge; once students learn how to use conditional statements (if and if-else statements), there's a whole world of potential applications they can write. This is really where their programs start to become more interactive and interesting. They can create a program such that it's not always doing the same things every time!
However, there's a very low entry point for conditionals. They can seem deceptively simple and easy to master. In one class, I started the whole lesson with one simple if statement, and kids instantly knew what to do:
if (student) {
sitDown();
clearDesk();
beQuiet();
}
This was not rocket science, but we took the time to discuss what everyone did in the class. We all - teachers included - did a check. Then, based on the results of that check, we either sat down, got quiet, and cleared our desks, or we did nothing.
This was an important point: teachers evaluated the condition and, when we realized it was not true, we skipped ALL of the commands in curly brackets. They didn't apply to us. This comes back later in the lesson...
In two of my classes, it just so happened that this lesson took place on a dress-up spirit day. This was an excellent opportunity to bring in something familiar and interesting to the class:
if (dressedForSpiritDay) {
standUp();
}
Another statement, another simple response from the class. At this point, we needed to move things along a bit:
if (dressedForSpiritDay) {
standUp();
} else {
facePalm();
}
The if-else statement was also not too tricky - if the "if" condition is false, you run the "else" set of commands. If the "if" condition is true, you run its set and skip the "else" set. We talked about how this created a situation in which EVERYONE did something. There was no longer a chunk of the class that did nothing. When might this be useful? What's the result of adding the "else" set? Kids discussed quickly while I listened in.
We took a quick step back and talked about how these conditionals are used in programs kids use every day, about how conditionals are pretty much the foundation of games! In Mario Bros., IF you land on the top of a goomba, it dies. IF you the timer runs to zero, you die. After you die, IF you don't have more than one life, it's game over; else, you lose a life.
Now, I really had 'em hooked!
The trickiest part of this lesson was nesting conditionals. This time, I used students' birthdays:
if (birthdayIsInSummer) {
if (birthdayIsInJuly) {
say("Happy birthday to me!");
} else {
standUp();
}
}
Kids started to stumble at this point. MANY students stood up, even though they had September or January birthdays. Some didn't, though, and I thought they had caught on. I asked them to explain why they weren't standing.
I'm really trying to step back from student conversations in class over the course of these lessons. When I ask a challenging question to the class, I'm doing my best to not step in and say, "Yes, you're right!" Instead, I continue asking, "Who agrees? Who disagrees? Why?" until the majority of the class seems to get it. This has led to some pretty interesting class discussions. Kids participate more (and MORE kids participate more) as they try to make sense of what their classmates are saying. It's kind of sad - it seems like, most of the time, students don't pay attention to what their peers are saying, they only tune into the teacher to hear what's correct or incorrect. I'm really trying to remove that crutch so that they have to work a little harder making sense of new information.
Eventually, students reached the understanding that if the outer statement is false (your birthday is not in summer), you skip EVERYTHING inside its brackets. That means that if birthdayIsInSummer is false for you, you don't do ANYTHING. You don't stand up, because you never even reach the birthdayIsInJuly check - you've skipped it because your birthday isn't in summer!
Next, I introduced some of the code.org Conditionals with Cards games from online. I used one deck of cards, and we did some teacher vs. class games starting with the simplest rules:
if (card.color == RED) {
points.yours += 1;
} else {
points.other += 1;
}
This was very easy to understand, and a very boring game. It's too simple! We went to the next version:
if (card.color == RED) {
points.yours += 1;
} else {
if (card.value > 9) {
points.other += 1;
else {
points.yours = points.yours + card.value;
}
}
With a couple of rounds of play, students really started to get how to evaluate situations and determine what should happen when various cards were pulled. We played the game for a few minutes until most of the students were able to accurately describe how points were scored.
Then, I introduced them to a game I came up with last year when we reached this point: Find the Queen! It's a bit trickier than the others since it also uses a while loop, but the students were able to figure it out pretty quickly. We talked about some errors and things that could be improved (it currently never ends, since you always end up pulling a card that causes you to re-shuffle the deck), then played a few rounds. With if's inside of if's inside of a while loop, it challenged students to figure out how to navigate through the code. However, once we got into a groove and students saw how to check line by line, skipping chunks of code when a condition was false, students were more successful.
Ideally, with more time, I'd like to have students make up some of their own games and write them using Javascript-ish pseudocode. However, we were crunched for time as it was and couldn't keep going.
Maybe this will be something we come back to after Scratch...
Wednesday, November 12, 2014
Computer Science Day 10 - Relay Programming/Debugging
As I've been going through this CS experience, I've found that quite a few of the lesson plans provided by code.org need some serious revision. For example, when code.org recommended having students create paper airplanes using a mixed-up algorithm, I quickly found out that the benefit of having kids sequence steps and follow them in order was outweighed by the management costs. I adapted the lesson to be more teacher-led, but student-guided, by making a PB&J sandwich using students' instructions.
Today's lesson was a serious exception from that rule: I was able to do the code.org Unplugged Activity - Relay Programming almost completely as-is, and it was a hit!
Last year, I completed Relay Programming in teachers' classrooms by posting puzzles up on the front whiteboard wall and having students break into teams with hardly any restrictions. In some classes, we didn't even do this - we just passed the puzzle and group paper around their table groups! They were only able to write one instruction, but other than that they were free to talk and collaborate as much as they wanted. This kind of fell through, though - in many groups, there was one student telling all the others exactly what to do. In these cases, the majority of students in groups had to do very little thinking, they just had to listen to their classmate.
This year, I set up one classroom (at one of my schools, this was the Multi-Purpose Room) so that I could set up the environment to challenge students more. Now, puzzles were flat on a desk so that students waiting in line couldn't see where we left off or what their classmates did. Students were lined up farther away from the puzzles so they couldn't shout orders to the student at the table. And if you caught a mistake, ALL YOU COULD DO was circle it.
Last year, groups figured out pretty quickly that they could just go up and write whatever they wanted on the sheet, and then one "checker" student would fix any and all mistakes so the rest of the group could keep working. That put enormous pressure on the checker, and allowed the rest of the group to get really loosey-goosey with their attention to detail. This year, as recommended in the code.org lesson plan, if a mistake was caught, the only thing you could do was circle it. Then, the next student could come up and fix the mistake, and then head back to the line so the next teammate could continue working.
This led to much tighter group interdependence. This time, students were really checking in with each other. They had to communicate extensively and support classmates who were struggling, otherwise the whole team would suffer. It certainly led to more interesting reflections!
To begin this lesson, I had students in classrooms take turns giving me one instruction for how to write an algorithm for a heart picture. This was a good whole-class intro to the notion of relying on each other to say the correct commands. We took only about a minute to practice, then evaluated our algorithm to see if it worked. In all cases but one, there was a mistake (pretty interesting, considering most classes were only able to produce about 9-12 commands in the one-minute timeframe). This showed them early on that their task would be difficult: if you made 1 mistake in every 9 commands, and we only took one minute, how do you think you would work on a larger picture with more time?
I set expectations and stated their objective, and then we headed to the room I had set up earlier (I just used some empty space and a desk for each group; students sat on the floor until it was their turn to enter a command). For our first puzzle, I set a 6 minute timer and let them go.
After six minutes, we gathered back together to reflect on how things went. Again, in nearly all classrooms, students felt that they did poorly (in two classes, I asked, "Okay, so how did that go?" and they answered with a loud, resounding, "TERRIBLE!"). I took notes on the projector with the things they felt contributed to their poor performance, and then I checked in to see if any groups though things actually went WELL! We recorded those as well.
Finally, we discussed strategies for improvement as they prepared to solve another puzzle as a group. Many groups picked up on the fact that they weren't communicating much (the first time through, the classroom was VERY quiet for a fast-paced, collaborative activity), so they planned what and how they would communicate (groups that worked well came up with the idea that when you write a command, on your way back you should tell the next student what you just did and where you left off, then tell the rest of the line how progress is going). Other groups talked about bug checking and how to do that efficiently (I told the class about "locking down" code by grouping commands into logical lines so that, when they finished a line and checked it, they could be sure that it worked and no longer had to debug it).
Pretty much every group, the second time around, worked MUCH better. Many were able to solve the puzzle correctly within the six minutes I gave for round two; several groups were able to catch and fix mistakes much more quickly; one particularly clever group had all group members put a marker cap on the space in the puzzle where they left off, leaving behind a clue for the next group member to know where they were. After six minutes, we did a final debrief.
Students really seemed to get the idea that it's easy to make mistakes, particularly when you're one member in a team of six and different people have different strategies. They worked slowly and deliberately so that they made fewer mistakes, and they really learned to rely on each other (at least for this activity!).
I was really happy with how this lesson went!
Here are links to the resources I used:
Today's lesson was a serious exception from that rule: I was able to do the code.org Unplugged Activity - Relay Programming almost completely as-is, and it was a hit!
Last year, I completed Relay Programming in teachers' classrooms by posting puzzles up on the front whiteboard wall and having students break into teams with hardly any restrictions. In some classes, we didn't even do this - we just passed the puzzle and group paper around their table groups! They were only able to write one instruction, but other than that they were free to talk and collaborate as much as they wanted. This kind of fell through, though - in many groups, there was one student telling all the others exactly what to do. In these cases, the majority of students in groups had to do very little thinking, they just had to listen to their classmate.
This year, I set up one classroom (at one of my schools, this was the Multi-Purpose Room) so that I could set up the environment to challenge students more. Now, puzzles were flat on a desk so that students waiting in line couldn't see where we left off or what their classmates did. Students were lined up farther away from the puzzles so they couldn't shout orders to the student at the table. And if you caught a mistake, ALL YOU COULD DO was circle it.
Last year, groups figured out pretty quickly that they could just go up and write whatever they wanted on the sheet, and then one "checker" student would fix any and all mistakes so the rest of the group could keep working. That put enormous pressure on the checker, and allowed the rest of the group to get really loosey-goosey with their attention to detail. This year, as recommended in the code.org lesson plan, if a mistake was caught, the only thing you could do was circle it. Then, the next student could come up and fix the mistake, and then head back to the line so the next teammate could continue working.
This led to much tighter group interdependence. This time, students were really checking in with each other. They had to communicate extensively and support classmates who were struggling, otherwise the whole team would suffer. It certainly led to more interesting reflections!
To begin this lesson, I had students in classrooms take turns giving me one instruction for how to write an algorithm for a heart picture. This was a good whole-class intro to the notion of relying on each other to say the correct commands. We took only about a minute to practice, then evaluated our algorithm to see if it worked. In all cases but one, there was a mistake (pretty interesting, considering most classes were only able to produce about 9-12 commands in the one-minute timeframe). This showed them early on that their task would be difficult: if you made 1 mistake in every 9 commands, and we only took one minute, how do you think you would work on a larger picture with more time?
I set expectations and stated their objective, and then we headed to the room I had set up earlier (I just used some empty space and a desk for each group; students sat on the floor until it was their turn to enter a command). For our first puzzle, I set a 6 minute timer and let them go.
After six minutes, we gathered back together to reflect on how things went. Again, in nearly all classrooms, students felt that they did poorly (in two classes, I asked, "Okay, so how did that go?" and they answered with a loud, resounding, "TERRIBLE!"). I took notes on the projector with the things they felt contributed to their poor performance, and then I checked in to see if any groups though things actually went WELL! We recorded those as well.
Finally, we discussed strategies for improvement as they prepared to solve another puzzle as a group. Many groups picked up on the fact that they weren't communicating much (the first time through, the classroom was VERY quiet for a fast-paced, collaborative activity), so they planned what and how they would communicate (groups that worked well came up with the idea that when you write a command, on your way back you should tell the next student what you just did and where you left off, then tell the rest of the line how progress is going). Other groups talked about bug checking and how to do that efficiently (I told the class about "locking down" code by grouping commands into logical lines so that, when they finished a line and checked it, they could be sure that it worked and no longer had to debug it).
Pretty much every group, the second time around, worked MUCH better. Many were able to solve the puzzle correctly within the six minutes I gave for round two; several groups were able to catch and fix mistakes much more quickly; one particularly clever group had all group members put a marker cap on the space in the puzzle where they left off, leaving behind a clue for the next group member to know where they were. After six minutes, we did a final debrief.
Students really seemed to get the idea that it's easy to make mistakes, particularly when you're one member in a team of six and different people have different strategies. They worked slowly and deliberately so that they made fewer mistakes, and they really learned to rely on each other (at least for this activity!).
I was really happy with how this lesson went!
Here are links to the resources I used:
Sunday, November 9, 2014
Project Stream of Consciousness
Lightning has just struck my brain. I have an idea. It's still percolating and forming and all of that, but I had to write it down before losing it forever into the depths of my mind.
So, lately, I've been kind of addicted to Serial. It's a podcast from This American Life that tells a single story over about 12 episodes, and for its first season it's recounting Sarah Koenig's investigation into a 1999 murder in Baltimore. It's kind of a big deal, and it will suck you in and obsess every idle thought.
Can we leverage this for the classroom?
Here's what's happened to me since listening:
A friend posted on Facebook about the podcast. I was curious, so I listened to the first episode after school one day while doing some mindless work. I was drawn in instantly, and consumed the next three episodes that very afternoon. The next day, I listened to three more and abruptly hit the limit; the podcast is still in process, and new episodes aren't posted until Thursday mornings.
However, there's a whole subreddit full of folks just like me (some with an even worse case of Serial obsession). People are posting links to old Baltimore Sun articles from the time of the case. There are interactive Google maps with markers posted for key locations in the mystery. There are threads dedicated to recounting and discussing the various persons of interest's roles and timelines. Someone found the appeal briefings that were just recently filed.
Let me tell you, I've NEVER had an interest in reading appeal briefings. I follow the news, but haphazardly and kind of without focus. I listen to a morning radio show, but that's about the extent of informational audio I consume in the average day.
But man...I'm like a junkie right now. The mystery has sucked me in, and I'm doing everything I can to try and piece this thing together and make sense of the case.
I've just started thinking that this high level of engagement could work with students, too. What if I (we) were able to create such an engrossing story that kids felt a strong desire to pursue whatever information they could find? What if students were expected to put together briefings, piece together information from a variety of sources to present evidence? To use collaborative tools like Google My Maps and Docs to compile information and share/discuss theories? We could hook students much the same way as SK (Sarah Koenig, as they refer to her on the subreddit) by releasing weekly, episodic chunks of information that students could listen to over and over and analyze?
The engagement would not be universal, no doubt; the podcast has a lot of followers, but not everyone will be as hooked and engaged as I and many others are. However, we could probably get kids who ARE hooked to consider and peruse all kinds of things they otherwise wouldn't! We could create news articles, nonfiction reports, and info snippets for students to discover. We'd be hitting almost all the CCSS ELA anchor standards in one fell swoop!
I know this kind of thing has been done before. I remember in sixth grade being part of a mock trial, and I know there are countless simulations you can find at teacher supply stores that hope to have the same effect on students. Has anything web-based been done yet, with high production standards and cognitively demanding tasks? If there has, I'd love to see it; I kinda think I would've heard of such a thing, though.
I may have to get on this. I'll try to crowdsource as much as I can, and bring together a variety of folks to play different roles. First thing I need to do is find an idea. It's awfully tempting to go cheesy an make an ancient civilization mystery, or an explorers mystery. I don't think there's anything necessarily wrong about this, but it limits the content to one grade level, really, and I doubt it'd resonate with kids as much as something modern day would. I'll have to think about this some more...
So, lately, I've been kind of addicted to Serial. It's a podcast from This American Life that tells a single story over about 12 episodes, and for its first season it's recounting Sarah Koenig's investigation into a 1999 murder in Baltimore. It's kind of a big deal, and it will suck you in and obsess every idle thought.
Can we leverage this for the classroom?
Here's what's happened to me since listening:
A friend posted on Facebook about the podcast. I was curious, so I listened to the first episode after school one day while doing some mindless work. I was drawn in instantly, and consumed the next three episodes that very afternoon. The next day, I listened to three more and abruptly hit the limit; the podcast is still in process, and new episodes aren't posted until Thursday mornings.
However, there's a whole subreddit full of folks just like me (some with an even worse case of Serial obsession). People are posting links to old Baltimore Sun articles from the time of the case. There are interactive Google maps with markers posted for key locations in the mystery. There are threads dedicated to recounting and discussing the various persons of interest's roles and timelines. Someone found the appeal briefings that were just recently filed.
Let me tell you, I've NEVER had an interest in reading appeal briefings. I follow the news, but haphazardly and kind of without focus. I listen to a morning radio show, but that's about the extent of informational audio I consume in the average day.
But man...I'm like a junkie right now. The mystery has sucked me in, and I'm doing everything I can to try and piece this thing together and make sense of the case.
I've just started thinking that this high level of engagement could work with students, too. What if I (we) were able to create such an engrossing story that kids felt a strong desire to pursue whatever information they could find? What if students were expected to put together briefings, piece together information from a variety of sources to present evidence? To use collaborative tools like Google My Maps and Docs to compile information and share/discuss theories? We could hook students much the same way as SK (Sarah Koenig, as they refer to her on the subreddit) by releasing weekly, episodic chunks of information that students could listen to over and over and analyze?
The engagement would not be universal, no doubt; the podcast has a lot of followers, but not everyone will be as hooked and engaged as I and many others are. However, we could probably get kids who ARE hooked to consider and peruse all kinds of things they otherwise wouldn't! We could create news articles, nonfiction reports, and info snippets for students to discover. We'd be hitting almost all the CCSS ELA anchor standards in one fell swoop!
I know this kind of thing has been done before. I remember in sixth grade being part of a mock trial, and I know there are countless simulations you can find at teacher supply stores that hope to have the same effect on students. Has anything web-based been done yet, with high production standards and cognitively demanding tasks? If there has, I'd love to see it; I kinda think I would've heard of such a thing, though.
I may have to get on this. I'll try to crowdsource as much as I can, and bring together a variety of folks to play different roles. First thing I need to do is find an idea. It's awfully tempting to go cheesy an make an ancient civilization mystery, or an explorers mystery. I don't think there's anything necessarily wrong about this, but it limits the content to one grade level, really, and I doubt it'd resonate with kids as much as something modern day would. I'll have to think about this some more...
Monday, November 3, 2014
Computer Science Day 9 - More on Loops
I strayed from my general CS Curriculum overview for this session, since I figured that loops are such an important skill for students to use effectively they warrant a second look.
Last time I introduced students to the syntax and component of a for loop, then simplified things by focusing on Scratch and code.org's simpler "repeat" loops. I felt that it was really important for students to see how loops REALLY work, but that meant that we didn't have time to get into the nitty-gritty application of repeat loops. As a result, there were lots of sad noises coming from iPads and laptops as students stumbled through their loop puzzles.
It's clear that, at least at the fifth grade level, students have a hard time visualizing how a repeat loop works. For example, let's say you need to move a bird in a diagonal stair-stepping line like this:
____
|
___|
|
___|
|
___|
Without loops, students would use a code like this:
moveForward();
turnLeft();
moveForward();
turnRight();
moveForward();
turnLeft();
moveForward();
turnRight();
...
until they reached the end. That's fine, but it takes a lot of blocks to do something that, on the surface, should be easy! Students' first inclination, then, is to use repeat blocks. However, if they don't stop to first identify the simplest, clearest pattern, they're lost when it comes to what blocks to put inside the loop and how many times to iterate through the loop.
What I did for my lesson today was to draw this puzzle up on the board and, without ANY repeat loops, write the full code. Even though students saw a pattern emerge very quickly, we continued through the hard way to ensure that the pattern held.
Step two was to make the pattern abundantly clear to everyone in the class. It was actually easier to see the pattern in its written form (the commands we used) than it was to see it visually (in the diagram). You could clearly see commands being repeated over and over. This step made the pattern very concrete - see how we go forward, turn left, go forward, and turn right over and over? Without those commands, students would just say, "You go diagonally over and over" or "You go up the steps over and over." While that may be true, it doesn't help students see repeated patterns of commands that can be abstracted into a repeat loop!
Step three was looking at the visual map of the puzzle and circling the portion that was being repeated. This was our connection from the commands to the actual puzzle. At this point, once students could see which particular blocks were being repeated, we were then able to more clearly see how many times we would need to repeat the commands! We went back to the initial drawing and circled sections to reflect how far we would go with our repeated commands.
Now, with this information, we were able to complete the task using a repeat block correctly so that students were not simply guessing and checking. I've stated to students multiple times that their goal should always be to get puzzles correct on the first try - if they have to guess and check over and over, they're not working efficiently and they're probably also not learning a whole lot.
That may have to be my next blog topic...
Anyways, this second day helped emphasize with students the computational thinking process: decompose a problem into its components, look for patterns, abstract to make broad statements and applications, and then finally write algorithms. I will be continuing to emphasize this work as we explore debugging, continue to practice loops, and learn conditionals.
Last time I introduced students to the syntax and component of a for loop, then simplified things by focusing on Scratch and code.org's simpler "repeat" loops. I felt that it was really important for students to see how loops REALLY work, but that meant that we didn't have time to get into the nitty-gritty application of repeat loops. As a result, there were lots of sad noises coming from iPads and laptops as students stumbled through their loop puzzles.
It's clear that, at least at the fifth grade level, students have a hard time visualizing how a repeat loop works. For example, let's say you need to move a bird in a diagonal stair-stepping line like this:
____
|
___|
|
___|
|
___|
Without loops, students would use a code like this:
moveForward();
turnLeft();
moveForward();
turnRight();
moveForward();
turnLeft();
moveForward();
turnRight();
...
until they reached the end. That's fine, but it takes a lot of blocks to do something that, on the surface, should be easy! Students' first inclination, then, is to use repeat blocks. However, if they don't stop to first identify the simplest, clearest pattern, they're lost when it comes to what blocks to put inside the loop and how many times to iterate through the loop.
What I did for my lesson today was to draw this puzzle up on the board and, without ANY repeat loops, write the full code. Even though students saw a pattern emerge very quickly, we continued through the hard way to ensure that the pattern held.
Step two was to make the pattern abundantly clear to everyone in the class. It was actually easier to see the pattern in its written form (the commands we used) than it was to see it visually (in the diagram). You could clearly see commands being repeated over and over. This step made the pattern very concrete - see how we go forward, turn left, go forward, and turn right over and over? Without those commands, students would just say, "You go diagonally over and over" or "You go up the steps over and over." While that may be true, it doesn't help students see repeated patterns of commands that can be abstracted into a repeat loop!
Step three was looking at the visual map of the puzzle and circling the portion that was being repeated. This was our connection from the commands to the actual puzzle. At this point, once students could see which particular blocks were being repeated, we were then able to more clearly see how many times we would need to repeat the commands! We went back to the initial drawing and circled sections to reflect how far we would go with our repeated commands.
Now, with this information, we were able to complete the task using a repeat block correctly so that students were not simply guessing and checking. I've stated to students multiple times that their goal should always be to get puzzles correct on the first try - if they have to guess and check over and over, they're not working efficiently and they're probably also not learning a whole lot.
That may have to be my next blog topic...
Anyways, this second day helped emphasize with students the computational thinking process: decompose a problem into its components, look for patterns, abstract to make broad statements and applications, and then finally write algorithms. I will be continuing to emphasize this work as we explore debugging, continue to practice loops, and learn conditionals.
Subscribe to:
Posts (Atom)