Thoughts on Scratch

January 22, 2024

Last Monday, I found myself standing in front of eight kids, trying to explain what a y-coordinate is.

“Um, it’s kinda like a street address…?”

How did I end up there? Well, my kids go to a Montessori school, and one of the traditions at the school is afternoon projects run by parents. These cover all kinds of different subjects: yoga, gardening, climbing, chess, etc. And I volunteered to run a project about programming — one 90-minute session per week for five weeks.

In the first session, we covered the basics. What is programming? What is a computer even? This week, we moved onto Scratch. And that’s how I found myself trying to explain 2D coordinates to the kids.

This was actually my first time doing anything serious with Scratch, and while it’s fresh in my mind, I thought I’d write up my experiences.

What worked well

Overall, our first session with Scratch worked out pretty well. There were a few aspects in particular that stuck out to me.

Browser-based

At the school, they have two types of devices the kids can work on: Windows laptops, and iPads with keyboard cases. We ended up having a mixture of both in the project.

Being able to use Scratch in the browser was a huge win here. A native app would have been much more difficult. First of all, we’d need something that would work on both Windows and iOS. Second, the iPads are managed by the school and we couldn’t install any apps on them ourselves.

Touch support

It also impressed me how well Scratch worked on the iPads. In the latest version, it’s clear that they’ve put a lot of work into making it work well without a keyboard. The kids had no issues using it, and at no point did I think it would be better if it were a native app.

In fact, I’d say that an iPad with a keyboard seems like the ideal hardware for Scratch. For kids of this age, most of whom aren’t super familiar with using a mouse or trackpad, a touch screen is certainly the easiest to work with.

Accounts

Another thing that worked well: I made the decision to create a single account for the course and to sign into that account on all the devices. That made it easy for me to see an overview of the projects and to use the backpack, which is a feature of Scratch where you can share blocks of code between different projects. I was able to set up some custom blocks ahead of time that were in the backpack for any kid to use.

Sharing a single account may not be the ideal way of doing this, but it was certainly simple and worked quite well. The only possible issue I could see is that kids could edit someone else’s project, but that wasn’t an issue for us in such a small group.

Powerful primitives & good documentation

Scratch comes with a pretty powerful set of primitives, and you can pretty quickly build some fun things with it. There’s also great documentation, and plenty of resources to guide you through common tasks. I was pretty pleased that it only took me an hour or so to build a simple clone of the Chrome dinosaur game:

After all of these years, I'm finally learning @scratch.

Gotta say, I'm pretty proud that I managed to make this.

(And yes I know I have a bug in my scoring logic 😆) pic.twitter.com/YRRzuoiwmJ

— Patrick Dubroy (@dubroy) January 15, 2024

In the classroom, the kids were quickly able to build the beginnings of a game — making their character jump, move around, etc. Two of the kids independently discovered the “glide to” block, and ended up incorporating it in different ways. One of them had a baseball that the player needed to avoid, and the other had donuts flying around that the player should catch.

Challenges

Of course, not everything worked out as well as I’d hoped. Certainly some of it was due to my own inexperience — but there were also some challenges due to Scratch itself.

Distraction

Once the kids were on the Scratch website, there were a couple sources of distraction that made it hard to keep everybody on track and working on the same thing.

The first was all of the blocks that you can see in the toolbox. Rather than trying to do something specific or listen to any kind of explanation, the kids were immediately pulling any and every possible block out of the toolbox and clicking on it and seeing what would happen.

This wasn’t a huge deal — at a certain point they kind of got bored and realized that they didn’t really know what they’re doing. But, a nice feature to have would be the ability to restrict some of the blocks that are available so that the kids aren’t immediately distracted by blocks which aren’t relevant to their level of knowledge and skill yet.

The second source of distraction is all the different games on the Scratch website. At various points during the class, one or two of the kids got bored with working on their own game, and started poking around the Explore page. They’d quickly find a game to play, and within about 30 seconds, they’d be surrounded by other kids.

Honestly, Scratch could (and should) do better here. The Explore page is filled with clickbait-y thumbnails. The sort order defaults to “trending”. And the non-game categories (“Art”, “Animation”, “Music”, etc.) are filled with games. I’d expect this from a VC-backed startup who’s focused on their engagement metrics, but not from a non-profit like Scratch.¹

Drawing

A second challenge I ran into was with the vector editor, used for drawing costumes and backdrops. My first instinct was to have the kids draw their own characters, rather than using the default cat character. The problem is the default drawing tool in Scratch is a fairly conventional vector editor:

The issue is that none of the kids were used to working with a tool like this. My own kids have done quite a bit of drawing on the iPad, but using digital sketching tools like Paper or Procreate. They’re only vaguely familiar with the concepts of selection, resizing, etc. They’re used to seeing a palette of colors to choose from, not an HSV-like color picker.

I was impressed at how well Scratch’s drawing tool worked on the touch screens. And it is quite powerful, which is great for more advanced users. I just wish the design was a bit different, so that younger kids could easily draw something without having to learn about the more advanced concepts.

Concepts

The third challenge I had, which I alluded to at the beginning of this post, was concepts in Scratch that the kids aren’t familiar with yet. Remember, the kids in this course are between 8 and 10 (2nd to 4th grade). So this is at the lower end of Scratch’s target audience (it’s designed for ages 8 to 16).

Here are the first three blocks you see in the toolbox:

This can certainly vary depending on the country and the school, but none of the kids in my course were familiar with measuring angles in degrees, or with the concept of x- and y-coordinates.

I’m a Canadian living in Germany, but for reference, I looked at the US Common Core curriculum to see when these concepts are typically taught in the US. Angle measures are in the 4th grade curriculum, and Cartesian coordinates in the 5th grade.

For the younger kids, it would be nice if Scratch didn’t put these concepts so front and center. For example, they could use a visual representation of the angle, like the point in direction block uses for editing:

For the coordinates, it would be simpler to deal with relative movement. In fact, I ended up creating some custom blocks for just that purpose:

Liveness

One of the things I love about Scratch is its support for live programming. If you click on any block anywhere, its effects will run on the currently selected sprite. For example, if you have the cat selected and you click the “move 10 steps” block, the cat on your stage will move, even though you have not put that block into your program or onto your canvas. You’ve just clicked on it in the toolbox.

This has the advantage that you can just look through the toolbox and click on blocks to see what they do. But I saw that it did cause a little bit of conceptual confusion with the kids. It wasn’t clear to them what things are part of the “program”, and what things aren’t.

You can also have “dead code” — blocks that are on your canvas, but not connected to any events. And you can also click these blocks to run them.

And so I think for the kids, the distinctions between these three stages — blocks in the toolbox, blocks on the canvas, and blocks connected to an event — were a little bit lost. It wasn’t really clear to them that the goal should be to eventually have all their code triggered by an event.

This wasn’t really a big deal, and I wouldn’t necessarily change anything if it were up to me. I was just a little surprised, since I’ve never considered that liveness could be a source of confusion like this.

Other observations

A few other observations and thoughts:

Language levels

Something that would be interesting to see in a Scratch-like environment would be some concept of language levels, kind of like DrRacket has: “beginning student”, “intermediate student”, etc.

As I mentioned, there were some concepts that weren’t appropriate for the age of kids that I have in this course. In this scenario, it could be really useful to have a setting that would restrict the available blocks and simplify the interface of some of them.

Lack of uniformity

As a programmer, there are a few spots where I’m frustrated by Scratch’s lack of uniformity. For example, there are some “pseudo-blocks” — expressions like “mouse-pointer”, “random position”, etc. that can only be used in a few places, but aren’t first-class value blocks.

Also, the selection of “hat” blocks (which are used to trigger scripts) feels somewhat arbitrary. You can’t trigger a script when two sprites collide — you need to do something like this:

Can’t pop the hood

Probably the biggest disappointment for me is that Scratch doesn’t let you “pop the hood” on its primitive blocks. I think this is a huge missed opportunity. There are some blocks that are pretty powerful (e.g. the “glide to” blocks), and it would be really nice if you could open those up and see how they’re implemented in terms of other blocks.

I do appreciate the ability to create custom blocks. I believe that’s something that wasn’t always supported by Scratch. But it’s unfortunate that the built-in blocks can’t be deconstructed in the same way that a custom block can be.

Clipart

One aspect of Scratch that I’m a bit divided on is the clipart. On one hand, I’d really prefer to have the kids draw everything themselves. This would give the work more character, and give kids a stronger connection to the things they create.

On the other hand, most classrooms will not have access to the kind of hardware that’s good for digital sketching: a low-latency tablet and an active stylus (like the Apple Pencil). In my experience, anything less than that makes it hard for kids to immediately be able to draw things they’re happy with.

I’d guess that in most scenarios, Scratch users don’t have any stylus at all. Even if they have a touch screen, they’re limited to finger-painting. And many users might only have a mouse or a trackpad.

So overall, I can understand why they made the decision to include so much clipart. In some ways it’s not ideal, but it seems like a pragmatic decision that makes Scratch easier to use in many settings.