Moving the bloggings

Just a quick note to RSS readers or whoever actually browses here.  I’m going to move away from blogging here on and start just posting to the blog hosted on my own domain.  (Browsing a bit on other sites via mobile without AdBlock finally made me notice how annoying the ads can be!)

The new site has been a little flaky so I’ve hesitated to put anything new up, but I think it’s stable now so I’ve finally published something I wrote a few weeks ago.  So if you want to read some thoughts on “multiple intelligences” then go give it a look.  (And email or tweet me if the site gives you weird errors!)

Mini-tutorial: roll your own drawing tool

I’ve written up a short introduction on how to try creating your own digital drawing tool in Processing.  However it’s over at my .com site, because, I don’t know, I actually managed to snag a .com for the domain name that I’ve had a .org of for years and years now, and publishing an app seemed like a good occasion to make use of it.

Quick, go check out this other post before I start sleep-deprived rambling even more here. Go!

New app by me: Swarmpaint


The generative drawing app that I’ve been working on for the last few months has finally gone live on the Google Play store for Android.

Swarmpaint is an extension of ideas that took root back before I switched to a teaching career. I was taking New Media classes (taught by Kenneth Newby, an excellent and interesting artist and teacher) and came across the idea of “computational expresssionism“. If we take on computational tools as a drawing medium, then by designing our own software we can use computation as an additional way of shaping and expressing what we draw.

More recently, I just taught a Digital Media Arts course at a local middle school. One assignment had students using Scratch to generate their own visual art. The results were often chaotic, but they often stumbled upon something truly amazing.

After a while I realized we could easily turn this assignment into a drawing program by having it follow the mouse. A few students even discovered this themselves (if my shaky memory serves me). And it was amazing how easily we could turn a boring line into something fantastic just by adding a few command blocks.

This inspired me to return to my own computational expressionism sketches from those four-or-so years ago and see what I could do with them on Android. In the end, I overhauled the actual drawing engine to something more physics-y, added a lot of controls and hopefully enough polish that you all agree it’s worth the (really cheap!) price of admission.

So, I invite you all to try out a taste of what a computational drawing medium could let you do. And if you’re curious about how to make a computational drawing tool truly your own, keep an eye out here or let me know on Twitter as I’m considering putting some sample code online to get people started.

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 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.


  • 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.


  • 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.)

Closing thoughts on Mindstorms posts, stolen from Alan Kay interview

From an interview with Alan Kay, an early computing pioneer whose vision of a Dynabook computing environment puts our ed tech iPad mania to shame, here are some great thoughts on how our current ubiquitous mobile computing compares to the early visions of educational computing:

The interesting thing about this question is that it is quite clear from the several early papers that it was an ancillary point for the Dynabook to be able to simulate all existing media in an editable/authorable form in a highly portable networked (including wireless) form. The main point was for it to be able to qualitatively extend the notions of “reading, writing, sharing, publishing, etc. of ideas” literacy to include the “computer reading, writing, sharing, publishing of ideas” that is the computer’s special province.

For all media, the original intent was “symmetric authoring and consuming”.

Isn’t it crystal clear that this last and most important service is quite lacking in today’s computing for the general public? Apple with the iPad and iPhone goes even further and does not allow children to download an Etoy made by another child somewhere in the world. This could not be farther from the original intentions of the entire ARPA-IPTO/PARC community in the ’60s and ’70s.

And on the importance of people and social context when using ed tech:

I’ve used the analogy of what would happen if you put a piano in every classroom. If there is no other context, you will get a “chopsticks” culture, and maybe even a pop culture. And this is pretty much what is happening.

In other words, “the music is not in the piano”.


Go read the whole interview, it’s worth it. (via Computing Education Blog)

Mindstorms, LOGO and Scratch: What happened to procedural thinking?

One of the key ‘powerful ideas’ that comes up in Mindstorms is the idea of procedural thinking. I can’t recall if Papert uses this phrase, but what I mean by it is, being able to think about a sequence of actions and break it down into smaller sub-procedures.  This is a fundamental practice in computer programming, although in modern object-oriented programming it also extends to grouping a problem’s set of data and procedures into smaller subdomains called ‘objects’.  Still, with or without objects, writing your own procedures (or functions or methods or whatever they’re called in your language of choice) is how we take the massive task of “Do this huge set of actions” into smaller parts that the programmer can wrap their brain around at once.  In LOGO this is done by essentially defining a new word: “TO DOTHIS” would create a new verb, DOTHIS, in the sense of “To do this thing, you should …”etc.

Papert extends this idea into the realm of a metacognitive “powerful idea” in a few different directions.  Once someone has the idea of breaking down a complicated task into smaller, “mind-sized bites” (in the words of a grade 7 student quoted in the book), they can apply this to other complex tasks outside of computing.  Papert even extends this to physical education with a research study done by one of his colleagues on teaching students to juggle, breaking it down to smaller sub-skills of “TOSS RIGHT”, “TOSS LEFT”, etc.

This seems pretty huge. Computing is definitely not the first or only domain where people have understood breaking large tasks down into smaller sub-tasks.  But it does provide an environment where students can easily create their own complex tasks and wrestle with the complexity.  This is, I think, pretty unusual – in most areas of life, the challenge of a complex task is primarily in actually doing things.  In computing, we are scripting commands and the computer does all the “doing” for us.  So in effect the challenge of “doing” is removed, leaving only the challenge of wrestling with exactly what to do.  Students experimenting in a rich computing environment will end up discovering the problem of managing complexity as a natural effect of playful building, and won’t mistake this for a problem in how they are “doing” the tasks.

Okay. This is all great, seems like an obvious win for creative computing education.

So why did Scratch leave this out?

I know, I know, go download Snap.

In Scratch, kids do get exposure to a pretty nice laundry list of advanced computing concepts: events, parallel programming / threads, objects, variables, lists, and plenty of I/O options.  But Scratch left out the ability to create new “procedures” or blocks.  This omission was glaring enough that a separate project branched off from Scratch with the sole purpose of adding this feature (initially called ‘BYOB’ for Build Your Own Blocks, now rebranded as Snap).

The fact that there’s an “advanced” version with this ability is great and fills the gap.  I’m not really arguing whether they should or shouldn’t have included that in Scratch in the first place.  I’m just kind of startled to realize how weird it is that they left it out.  Procedural thinking seems to be the biggest advantage, the most important “powerful idea” that Papert sees in introducing kids to computing.

I’m sure this was left out on purpose.  I just wish I knew the reason why.  In LOGO, allowing a student to create a new verb was relatively natural.  Was this concept too hard to integrate into the visual model for the UI in a way that younger students would understand?  Or was this tool seen as adding too much complexity – despite the fact that it exists precisely to reduce complexity?

EDIT: John Golden posted this to the Learning Creative Learning MOOC community (a course run by the same MIT lab that founded LOGO and Scratch) and the responses are interesting. In particular, Natalie Rusk offers some behind-the-scenes answers to the questions I had. (Sometimes the internet is fantastic.)

Mindstorms: Powerful Ideas is actually a pretty awesome chapter

So far I’ve done a lot of critiquing and sniping. Let me just finally make one post that straight-up says this is some fascinating stuff in here.

One of the thing that surprised me about Mindstorms was that the phrase “Powerful Ideas” in the book’s subtitle wasn’t just a vague, positive sounding statement.  It’s something that Papert takes a full chapter to elaborate on, as well as working it into much of the rest of the book.

Papert’s “powerful ideas” are the sort of thing we would probably wrap into the fancy-sounding phrase of “metacognition strategies” or something like that.  It’s ideas about how to think.

Papert’s key example in this chapter is a hypothetical discussion between GAL and ARI on the nature of gravity and two falling weights.  ARI believes Aristotle’s view of gravity and claims that a heavier body will fall faster.  GAL poses the case of two identical ten-pound metal weights falling – ARI says, of course they will fall at the same speed, they are independent bodies.

GAL: But now if I connect them with a gossamer thread … is this now two bodies or one?  Will it (or they) take two seconds or four to fall to the ground?

ARI is confounded – if they are one body, then somehow this flimsy thread is making a hurtling metal ball go faster, which seems absurd.  But if they are two bodies … BOGGLE.

The point Papert makes with this example is not just that our Galilean thinker was more clever.  It’s that he had the “powerful idea” of thinking of an object as being made up of smaller objects.  This powerful idea of subdividing and combining objects enabled him to construct a scenario that brought ARI’s misconceptions about gravity to light.

This is probably the most convincing explanation I’ve heard yet for the idea that we as teachers are in the business of teaching kids how to think.  Usually this seems like crazy talk to me – or, really, like the only ones actually getting to do this for a living are the English teachers, and those of us teaching math / computing / science / etc are just caught up in wishful thinking.  But Papert’s idea of the value of computing as metacognitive tool is an interesting one.

He doesn’t limit powerful ideas to computing, but suggests that the advent of popular computing will open up a large number of new “powerful ideas” that previously weren’t part of our everyday lives.  Many of these are along the lines of modelling the workings of our own minds as being similar to computing – we mentally create distinct “threads” (mentioned in the epilogue), we can break down processes into steps and subroutines, etc.  (In the foreward he does mention that he isn’t intending to promote logical, structured thinking as the core model of our mind any more than he sees that as the only useful model of computing, despite most examples being along those lines.)

I wish I knew more about where research has gone with this in the time since this was written.  I vaguely recall from my ed psych class the thought that metacognitive strategies are powerful, but often don’t transfer between subjects/topics unless they’re explicitly reinforced as general strategies.  But perhaps the metaphor of computer as a thinking machine makes the cross-pollination of these ideas from thinking-about-computing to thinking-about-thinking much easier than usual.