Looking back: How my Scratch-based class went last year

Last year, I started off a new Digital Media Arts (DMA) program at a local middle school.  Here’s a rundown of how I laid out the class, what worked, what I had to tweak as I went, and what might be worth trying or extending next time.

First, some context. DMA isn’t a course that’s prescribed by the Ministry exactly; it’s a fairly common inclusion with a middle school’s courses around here, often as part of an ‘Explorations’ set of classes that includes Fine Arts, Woodworking / Trades, Cooking, etc.  It’s sometimes taught as a Fine Art class and targeting those learning outcomes.  In my case, however, the class was brought in as part of our school’s Tech hours for the IB Middle Years Program.  What this added up to was a class fulfilling Tech hours but with an Arts spin, and with almost no prescribed learning outcomes. I had space to make this into what I wanted.

I’d found examples of other IB MYP schools using Tech hours to simply do straight-up digital art, eg. a unit on Photoshop.  I tossed ideas around for a while and in talking with other Explorations teachers I realized that I should focus on my passion – getting kids doing some fun coding.  Scratch fit this perfectly, and so that became the focus for my DMA Year One.

The class would run for about 30 hrs per group of kids, with three 1-hr-long classes per week and three semesters of kids rotating through.  So, enough time to cover one thing in depth and do a bit of other stuff.  (The other stuff turned into a bit of dabbling in typing lessons and Word document formatting.) The classes themselves were grades 6 and 7, with probably the widest range of demographics in our district.

I started with the Scratch Curriculum Guide Draft. It outlined a 20-class unit with a mix of smaller one-class assignments, group work, and building up to a longer student-driven project in the end.  Going in, I had only a rough idea of what to expect from middle school students in this area. I had taught a similar Info Tech course to high school students using other tools (one with Storytelling Alice, another with LabView and Lego Mindstorms) and I expected a wide range of ability and comfort levels. However I wasn’t sure how long it would take Gr6-7 kids to complete the assignments outlined, so I just dove in and found out the hard way. I did not try to stick tightly to the guide’s schedule, though, as I was already kind of disrupted for timing due to only starting a couple weeks into the school year and not quite having 20 classes left in the first semester by the time I got things rolling with Scratch.

I quickly found that if I wanted to give everyone time to complete even the early ‘Dance Party’ assignment (from session 4 of the guide) that I would have to give them more than one class to do it. I also eased off on a lot of the ‘analog’ lesson ideas, such as session 3’s plan of spending a whole hour having kids practice procedural thinking by giving each other dance instructions.  (Could be a LOT of fun with a smaller, focused group of kids, but I had 28-30 kids in a not-that-large computer lab.  We just didn’t have the space even if I’d wanted to try it!)

In the end the run of Scratch assignments ended up being an intro day of “make a scene with the sprites”, the Dance Party, the Automatic Drawing (later in the year coupled with a make-your-own-paint-program variation), a 1-day Make A Maze walkthrough (later coupled with another 1-day Make A Platformer walkthrough), and then a bunch of time given to their ‘Final Project’.

I kept the Final Project very open-ended, with the only requirement being that it had to be interactive.  However it ended up steered pretty strongly towards making games.  There was a lot of student interest in that direction so most of my descriptions and examples were based on that.  I also experimented with leading kids to the option of making an interactive story, which had a couple of good results. (In the first semester I got a handful of groups using Inklewriter, which was sort of awesome but I had to give up on it after that first try purely for assessment reasons.  Inklewriter is 90% writing skill, 10% thinking about interactivity, and I just wasn’t the one teaching the kids how to write.)

The big Final Project thing turned out pretty fantastic.  Kids could work solo or in pairs; I had a few groups of three in my first semester and it generally didn’t work well, due to Scratch not really being made for multiple-computer group work.  They kept a basic, guided Design Journal with a couple of introductory planning pages followed by a simple “What did you work on today? Did you have to change your plan? What are you working on next class?” sort of prompted daily log. The level of technical skill that students showed was all over the map, but nearly everyone found something they were inspired to make and got excited about it.  Horse races, skateboarding, messed-up fairy tales, mini RPGs, and a lot of platformers and mazes. And everyone got a taste for what it’s like to plan and implement a large-ish creative project.

The only thing that was troubling about it were the number of kids who got stuck on the ‘maze game’ example and didn’t go beyond just adding more levels to the maze game.  What was meant to be a quick introduction to interactive controls ended up being a template that a lot of kids couldn’t see beyond. This was the biggest reason why I tried adding a second walkthrough-assignment on how to make a simple platformer instead, hoping that they’d see there were options.  (It maybe worked, a bit.  Or at least seeing kids’ stuck-in-the-template platformer games was more fun for me than the maze games.)

Assessment! Oh goodness, it was not easy. Did I mention, first year teaching middle school kids, and no explicit PLOs? What’s worse is that I had kids handing in assignments online using a Moodle-based site, but a lot of these kids either forgot to hand things in or outright avoided it because they forgot their login info. So the end of the semester involved a lot of reminding / nagging kids, “Please actually check your grade on the assignments page! Hand stuff in!” and chasing down the worst offenders so that these kids who I had actually watched do all of the assignments in-class could show up in my gradebook as passing. (I may just ditch digital handins entirely next year and do all marking in person. Takes a lot of time in-class, but more immediate feedback, keeps me from procrastinating and avoids this extra login nonsense.)

I did not try to do anything as ambitious as SBG, despite my love for the system. I didn’t have set PLOs, I didn’t know how far was too far to expect them to go with abstract coding concepts, and after a couple of months I realized that I wasn’t there to teach programming anyway.  I was there to teach kids that “creativity” just means creating which just means go out there and make stuff, and that computers aren’t just a passive media consumption tool.  Exposing them to coding along the way was a bonus but I wasn’t going to expect them to fully wrap their minds around all of the ideas that they were playing with in Scratch.

Next time around, we’ll see.  I know what’s reasonable to expect of students at that level now, and I am a bit dissatisfied with how loosely I was grading things.  However, I’m still running a spectrum of learning goals across both arts and tech (and waiting to find out what next year’s schedule will look like for me) so I’m not pinning things down too specifically yet.

The plus side: I got to basically do all the fun stuff with kids and didn’t have to hammer them over the head if they didn’t really get the deep implications of how the event system works in Scratch or whatever.

Things I didn’t try that I might in the future

• A small code-reading and debugging assignment: what does this Scratch code do? If we want it to do this instead, what do we change?
• Actually picking a few veeeeeery basic CS concepts and assessing for them properly. (Note to me: Learn more about which basic CS concepts are worth assessing properly.)
• Grading on a full-course portfolio with specific areas and skills to check for. (This feels like SUCH a good idea, but it’ll only happen if I’m ready to define good criteria.)

Takeaway for other teachers:

Scratch really is fantastic for open, exploratory learning about programming / CS concepts for middle school kids. I think any projects that take longer than 10 hrs to finish would require some instruction on how to organize and plan out a project well, though, as a lot of kids were already hitting the common visual-coding problem of Too Much Clutter.  (Run-on files and classes in text-based coding can be a problem, but at least the code blocks don’t actually hide each other by overlapping on the screen.)

Giving exposure to programming to middle school kids is easy.  Actually expecting and assessing for mastery over any of those concepts is another matter entirely.

The Scratch Curriculum Guide Draft is fantastic, but don’t be afraid to adapt like crazy.

If you have a lot more time than 20-30 hrs to spend on a middle school course using Scratch, you could probably expand on the draft curriculum guide above by breaking things apart into 2-3 themed “Big Projects” instead of just one.  Maybe choose a focus based on the areas mentioned in the guide – Story, Arts, Games – and choose which technical skills you’d focus on for each (but expect some required overlap).

Alternately, maybe detour into other accessible coding languages / environments.  I had at least a few grade 7 kids already trying to build things in GameMaker without my help; it’s a great game creation tool, not a great first tool for actually teaching coding but might be a great extension.  I love Processing and tried the briefest of introductions with a couple of advanced students, but didn’t give it a fair go to say whether it was a win.  My only takeaway from that was that you can’t just give a middle-school kid something like sketchpad.cc and expect them to get far on short notice without some help. Installing the actual Processing IDE would probably have been better.

Technical footnote – Scratch 2.0

With the official release of Scratch 2.0 near the end of the school year, I let some kids give it a try and had a number of them use it for their big Final Project.

Pros:

• Build your own blocks! …except I did not take time (or really have much time) to help build up kids’ understanding of how powerful this is.  The interface for this is pretty good, but definitely not obvious to kids just testing it out on their own.
• Sprites now have direct access to changing the background – no more message-passing ‘broadcast’ blocks required.

Cons:

• Sprites now have direct access to changing the background – no more message-passing ‘broadcast’ blocks required.  (Took away a major reason for kids to learn how to use broadcasts, although maybe it’s better that it’s put off until later.)
• Web-only model is NOT conducive to helping kids w/ access to their files.  The old downloaded Scratch saves files in an obvious, expected location, and when a kid needs help getting at a group project that was saved on a missing member’s login, I had admin access to fix that.  On the web version, that kid is now wasting a class.

If you are doing any sort of group work in a school computer lab environment, wait for the downloaded version of Scratch 2 and use that instead.  (Unless you reeeeally need the BYOB functionality.)