Whoops, it's been kind of a while since I last wrote an entry. I'm at a bit of a loss with how I should format these entries as we pursue the Scratch Creative Computing curriculum. The lessons, at least up to this point, are not traditionally-structured, since they mainly involve setting a task before students to help them practice new skills and increase their familiarity with Scratch. As such, there's not a ton to write about on here.
For instance, the last two lessons pretty much consisted of me showing students how to get set up on the project, explaining the requirements of the project, and then setting them loose to read the directions and get going. While I kind of like the shift in ownership onto students (they're on their own to investigate and figure out solutions to some of their problems, instead of me talking at them for 20 minutes and spoon-feeding them processes), the structure does not make for good blogging.
That being said, I'll continue to post selections of what we've completed in case you want to know more about some of the lessons from the Scratch curriculum. The entries will be briefer, but maybe that's not a bad thing!
Today, I set students up to complete two different activities from Unit 1 - Exploring: Debug It! and All About Me. I skipped around a bit, since some of the lessons in Creative Computing were pretty similar to our code.org lessons. Also, I had kind of a hard time justifying time spent showing students how to create studios and dance routines, particularly since I'm only in classrooms once per week. That means that so far, here's what we've completed:
- Creating a Scratch account
- Exploring Scratch interactions with the Makey Makey
- Scratch Surprise and Critique Group (this lesson was waaaaay shakey and needs heavy revision to improve; realistically, and entire week could be spent on how to give and receive feedback)
- Step-By-Step and 10 Block Challenge (Should go before the previous lesson, I think, to help students get familiar with Scratch and learn how studios work)
- Debug It! and All About Me - the topic of today's entry!
I really liked today's Debug It! lesson. There's a directions sheet included in the Creative Computing curriculum, but I also re-wrote it in Google Docs and have included the file here. Our district has gone Google, so I'm trying to move over to Google Apps as often as possible and potentially cut out the copies by sharing the document with classes for students to complete online. We'll see how that goes...
We'd done some debugging before on code.org, but these Scratch debugging problems present a much more realistic idea of what it's like to debug a program. On code.org, debugging was typically very obvious and required students to change only one block in a program. They could see the problem with the program and solve it lightning-quick. However, the Scratch programs are much more subtle.
In one program, for instance, Scratch Cat is supposed to do a flip when the green flag is clicked. There are four blocks used properly that, for all intents and purposes, should cause the cat to flip. And indeed, he does flip, he just flips so fast that our eyes can't see it. However, students don't know that he's flipping faster than they can see. They just know that when they click the green flag, it looks like he just stays still.
This is a tough problem for students to solve. In both classes where I taught this lesson, students came up with different results. Some stumbled across the fact that if they replaced the four rotate blocks with a repeat loop, the program slowed down just enough to make out the actual flip. Others had him flip way more than once by changing the number of degrees to a smaller amount and using more blocks - again, this slowed down the program just enough to see the flip. The "best" solution, though - the one that's most reliable and explicitly clear to a reader of the code - is to insert a wait block in between each rotation. This way, no matter the speed of the computer or program, you'll be able to see the cat flip.
It took students quite a bit longer to complete these puzzles than I anticipated. We actually didn't even really get to the second project in one of the classes. I think I'm going to have to slow down on these lessons and really allow plenty of time to focus students' attention at the concepts they need to learn. Ideally, I'd like to take a good chunk of time at the end of the lesson to debrief the debug and share solutions and talk about why certain solutions are better than others. That's definitely the plan for today's sessions with this lesson. For early finishers, I'll have them go back to their 10 Block Challenge projects and flesh them out a bit more.
Oh, and by the way - it's Computer Science Education Week!
I'm working with groups of fifth graders in the classrooms I've been teaching to go around the school to other classes and encourage teachers and their students to participate in the Hour of Code. The idea is to have groups of four go into classrooms that have indicated interest (I sent out a Google Form), show a quick presentation, and then share with the classes some projects they've completed on Scratch and puzzles they solved on code.org.
The problem right now is getting teachers interested in teaching the Hour of Code. I still think a lot of teachers look at this as some extra burden to which they don't want to commit, or something that's shallow and too game-y. Hopefully this can be grassroots, though, by getting one or two on board and asking them to share with everyone else to let folks know that this isn't just something silly and fun - it's hard work and fun!
