Text is Keeping Kids from Coding

We ran into a big blocker when designing SpriteBox Coding, a learn-to-code game for kids ages 5+. For some kids, code was simply unapproachable.

With our previous game LightBot, we’d already proven that kids ages 5+ were capable of writing complex programs with icons. The goal for our next title was to get kids engaged and familiar with ‘real’ text programming so that they could advance to real programming languages.

Problem is, many newcomers, kids and adults alike, believe that code is inherently complex simply because it looks complex. Our first challenge became ‘How do we make code look friendly?’

Source: “Please Don’t Learn to Code” TechCrunch

We guessed that the likely culprits were the unusual symbols you see. We thought we’d succeed if we got rid of anything atypical, adopted simple vocabulary and used an interface that didn’t allow for syntax errors. We’d soon find out that this wasn’t the case. Here is what we came up with:

Textual Code in SpriteBox : Code Hour, our first try at the app

We showed the above to playtesters (kids and parents) who told us what we didn’t want to hear: the game looks complicated. The text deterred player confidence and led to confusion more than anything.

We couldn’t believe it. From our perspective, we’d simplified the code to what looks like plain English. When we asked parents what they imagined the target age group for the app to be, we got responses that estimated ages 9, 10 and up- much older than the demographic we wanted to hit.

As a test, we replaced the text with icons, and many playtesters’ initial fears dissipated. Players were more confident in approaching the game and parents estimated that the target age for the app was much lower.

Icons in LightBot vs Icons in SpriteBox : Code Hour

It dawned on us that, for some people, the problem was simply that text itself was intimidating. It felt somewhat silly, and yet, learning textual code was the mental blocker for a good portion of our playtesters.

Coding is hard because text is scary.

At this point, we looked to draw inspiration from other educational games. In particular, we looked at DragonBox Algebra: a game for teaching algebra for young kids. The team there seemed to find that numbers and variables were intimidating for their players if introduced early on.

Consequently, DragonBox Algebra starts players off with pictures and explains the mechanics of algebra in an icons-only environment. As the game progresses, it phases those pictures out for numbers and variables.

This approach was so effective, a study was done that showed that 92.9% of kids using the app achieved mastery of basic algebra after 1.5 hours of play.

DragonBox Algebra 5+ : Source: http://dragonbox.com/products/algebra-5

We wondered if we could model SpriteBox Coding similarly. We would keep the early game icons-only…

… but transition to textual code later. Icons would simply be “phased out”.

The response to this version was pronouncedly more positive. Playtesters felt less intimidated and were engaged longer. Little by little, SpriteBox swaps out all icons for instructions written in text format.

SpriteBox Coding with Swift syntax

So why does this work? We believe that by focusing on icons first, players don’t have to juggle learning two things at once, instead learning programming logic first and textual representation after. Moreover, when text code is introduced, players’ previous knowledge of the game’s mechanics keeps their confidence up as they solve familiar puzzles.

Could this approach work for other educational games? How many more kids could we get engaged in maths, science and programming by using perceptually simpler visuals first, and avoiding text until the last minute?

UPDATE: SpriteBox Coding is now on iOS and Android: spritebox.com