The Bootstrap Blog

Building a Block Language: Folding and Errors

You can read our other entries on the subject: Getting Started and Functions & Applications.

Goal 4: Control Complexity

One tradeoff between blocks and text is density: text is simply more compact that the corresponding block. Consider the example of the distance formula (shown here), which contains quite a few nested blocks. Visual complexity makes code difficult to reason about. All these blocks take up a lot of space! A teacher might want to focus on the fact that we're summing two squares, or perhaps view this expression in the context of a larger program. Both of these goals are hindered by the lack of density that comes from leaving the world of text.

There's also a learning goal at work here. Math is all about abstraction, and math teachers take advantage of this fact all the time! Being able to "box up" a chunk of arithmetic has tremendous pedagogical value, and has natural extensions into function definition. To manage visual complexity, we added code folding for blocks. Essentially, any non-literal block can be in a collapsed or expanded state, and this state can be toggled with the left and right arrow keys.

This is also a win for visually-impaired users: with block-folding, navigation can be breadth-first, rather than depth-first: users can simply hop from expression to expression, for example, only delving inside an expression when they choose to.

User Interface: we use left- and right-arrow keys to manage collapsing. If a collapsable block is active and expanded, hitting left-arrow will collapse it (otherwise a beep is heard). if a collapsable block is active and collapsed, hitting right-arrow will expand it (power-user shortcut: hitting right-arrow on an expanded block will active the block's first child, and hitting left-arrow on a child will activate the parent!). We use the standard aria-expanded attribute to make sure assistive devices will do the right thing.

Goal 5: Let Students Learn from Mistakes

Just because blocks can prevent mistakes doesn't mean they should! At Bootstrap, we think that certain mistakes are valuable learning opportunities, and we've published several papers about our approach to error messages (Marceau, Fisler, and Krishnamurthi, 2011, Marceau, Fisler, and Krishnamurthi, 2011; Wrenn and Krishnamurthi, 2017). Give how seriously we take error messages, we want to explictly allow for them in our block language. Anyone who's walked through code in front of a class knows that code goes from correct state to correct state...often by way of incorrect intermediate steps. We think blocks shouldn't rule that out. We also think there's a downside to over-scaffolding expressions to the point where "if the block fits, it must be right." We need our block language to let users write invalid code.

With a little parser tweaking, we can allow grammatically-invalid code to render in blocks. These blocks show up a little differently to provide a hint that something is wrong, but we still let students create, edit and evaluate them.

When a grammatically-incorrect program is evaluated in Bootstrap, students get a helpful error message. We're proud of the error messages we've built into our software. Our block language includes hooks, allowing the editor to highlight any portion of a block expression for parser and runtime errors. This provides a perfect parallel to the existing error messages in our environment, building a smooth road-map to text-based programming later on.