Scratch

I have been teaching an after-school class for 2nd to 4th graders. My approach has been to give them some basic programs to start. I make them enter in the basic part of the program and we discuss why it works. Then, I let them modify it. Some of that time is just messing with the drawing editor and the sounds and that is OK. But, I also encourage them to add new capabilities. I note that teams of 3 work best because they tend to help each other and also tend to stay on track. The approach I used was:
1. 1st day: no computer, just go through terms and ideas and how to think like a programmer. I find this helps a lot. I use a cutout of mario and a grid to with obstacles. This helps them understand the difference between look-and-decide (what a player would do), pre-arrange (animation), and conditional based decisions (such as always turn left when possible, etc). By introducing control, loops, conditions, variables, you really help them learn to think this way. I tell them to use the next few days to think about any task they are given (such as brushing teeth) and to divide it up into parts and conditions and loops.
2. Next day, I give them a simple animation example with scratch. The 1st step is a repeat loop with turn 45 deg and move 50 steps. This is to get them to think about control and loops. It goes way too fast. So, they then, modify to add wait(0.5) to make it reasonable. Again, it emphasizes the steps of programming. Finally, next-costume and a change to the "hat" (to if-space-key). I do this so they learn how to use Scratch. I then let them play with what it looks like, add sound, add more sprites, etc. They need to "own" it.
3. Next time, I move them to a ball chase game (one sprite is chasing the controllable one). This allows use of key motion, random, conditions, variables (hit counter), collision, etc. They love this because they can play. But, I let them then add a second ball for them to chase. They add new variables and all. Some guidance may be needed, but they usually do this just fine. The more advanced ones will change it to a two player game. Again, customizing is fine, just keep them focused. If you tell them that they are to show the rest of the class what they have done, they are more likely to work on it rather than playing with sound recording.
4. After that, I move to a ball firing "cannon" shooting the dragon. This allows broadcast and receive and emphasizes object oriented concepts. If done right, they can clone the dragon (and change its look) as many times as they like. The hit and miss counters will still work, etc. I leave a few bugs in like not initializing the hit counter. They "discover" this (or I point it out if needed) and then we work out how to resolve it.
5. Finally, I challenge each team to outline a new game they want to do. This then can be reviewed. I work with them to cut the 1st version down to a manageable size and work out how they could add to it incrementally. This is a crucial step in programming: learning to balance ambitions with what is achievable and learning to build in a more modular way. Scratch is not perfect for this due to the lack of "by reference" scripting (so copies become different if you change one), but it is still viable with some care.
My experience is that if they are getting cool playable results each time, they are more likely to focus on it. Good luck.

Last edited by pkimelma (2007-04-21 00:54:07)

Thanks for the tips - pkimelma, do you have the sample projects that you mentioned posted anywhere on the Scratch projects page?  The ball chase game sounds like it would be especially useful for the students I'm teaching. 

As somebody with a background in painting, not programming, I'm always interested in seeing how a project is "really" done (as opposed to me guessing around and faking it a bit...)

I agree that mutual exclusion is hard in scratch, but I have found it very useful to have multiple scripts running at once on a sprite---as long as they are doing different things.
For example, it is very useful to separate the sounds and looks from the motions, so you can have a sprite glide across the screen while alternately changing costume to walk.

Since scratch has so few features, it is important to make the best use of the ones it has.
I believe that multi-threading is perhaps the most important feature of scratch, and encourage students to do multi-threaded code to modularize and simplify things.

Debugging multi-threaded code that lacks semaphores, atomic actions, or other mutual exclusion primitives is tough, but it is good practice for the future---better preparation (I think) than coming up with serial simulations of inherently parallel actions.

Hi from Mexico,
I teach  computing to 1st through 6th grade , my groups are quite full (30-37 kids).  My little helper is a program called synchron-eyes, I can guide them as how to start and show them little by little how to add new sprites and scripts into the program. 
With some of the groups I've experimented by starting a program from scratch, but with others I make them open one from the gallery and adapt it to a new topic.  Then as the project flows, some might need more help, ex. ... if they want to change the place where the sprite will appear or what they believe it has to do. 
We had been working with Drape (drawing programming environment) and Logo.  So for them using Scratch was easier since they need not worry about syntaxis.
Take a look at my gallery and you'll see what I mean.  The projects are alike but unique at the same time.
Good luck.