The Bootstrap Blog

Building a Block Language: Getting Started

You Bootstrap guys should really use blocks. Hadi Partovi, CEO of Code.org

Hadi wasn't the first person to say it. For years, people have asked us why we don't use blocks. The truth is, we love visual scaffolds, and have been thinking about visual syntax for more than a decade! In fact, we developed the Circles of Evaluation back in 2005 (two years before Scratch was released), as a visual syntax for thinking about Order of Operations, Function Composition, and Racket syntax. We've built multiple block environments along the way, starting with one of the first web-based block environments ever in 2008, a Blockly implementation in 2012, and then a yearlong partnership with Code.org in which we co-developed a block language that would allow them to adapt Bootstrap to their own CS in Algebra curriculum.

At Bootstrap, we don't do anything without thinking it through. We learned a great deal building those prototypes, and we learned a lot more working alongside Code.org to build, ship and then train teachers with a block language. In 2015 we authored a paper on some of these lessons.

Block Languages have long been considered an ideal way to introduce novice programmers to programming constructs. Block languages tend to fall into one of two categories, depending on how they use their limited-but-powerful set of visual cues:

1. Syntactic Scaffolds - Block languages made with PencilCode are good examples of this. In these languages, the block shape is designed to hint at the physical shape of the equivalent text expression.
2. Conceptual Scaffolds - Blockly, Scratch, Snap! and AppInventor are good examples of these kinds of languages. Each of them uses shape, color, connectors, etc. to communicate concepts. In Scratch, for example, all yellow bricks generally denote control-flow, while green blocks denote arithmetic expressions.

There is some degree of overlap between the two. For example, some PencilCode implementations use color to denote type, and Scratch uses shape (in certain circumstances) to suggest that if-expressions have "branches". But in general, most block languages are firmly rooted in one sphere, making only small forays into the other.

Things we love about blocks

1. Blocks lower the barrier for entry - Why should we require a student to type, in order for them to start thinking about programming? If we can make it possible for young children to start thinking about logic and structure, that's a win!
2. Less frustration - Even experienced programmers make typos, and syntax errors are annoying. It would be nice to have fewer of them.
3. Useful hints - Block languages can use color and shape to provide extra information for users. Syntax-coloring is a nice feature of tools like Eclipse, but blocks can do so much more.
4. Visual reinforcement of structure - Constructs like for-loops and if-then-else clauses have a conceptual "shape", but it's not always easy to see that shape by looking at loads and loads of ASCII text.

Things we don't love about blocks

1. Penalizes fast typers - Beyond a certain number of words-per-minute, dragging blocks around is just plain slower than typing. And that magic wpm threshhold? We don't have a hard number, but in our PD experience it's far lower than we expected.
2. Higher demand on short-term memory - Blocks often take up more space on-screen than their textual equivalent. When a student can't see code from even a few lines away from their cursor, they need to remember more of their program when working, or else interrupt what they're doing to scroll/drag.
3. Small space of visual cues - The most obvious visual cues are color and shape, but those are limited. How many colors are easily distinguishable on a screen or classroom projector? Block languages quickly run out of cue-space, and wind up overloading colors and shapes in an attempt to express more concepts than the color-and-shape options allow.
4. Poor Accessibility - A drag-and-drop modality makes strong assumptions about the user having both sight and fine motor skills. A language that leans heavily on shape and color to communicate structure often puts non-sighted users at a disadvantage.

These trade-offs cease to be worthwhile for students beyond a certain level of sophistication and/or typing speed - but for those below that threshold, a well-done block language can be enormously valuable.

Bootstrap has never been about the syntax of a language (indeed, our curriculum spans more than one!), so we chose to make our block language a conceptual scaffold. Given the limited scope of visual options in our toolbox, the next logical question is "which concepts matter most for our learning goals?" Sounds like a good topic for our next post on the subject...