Learnable Programming: Blocks and Beyond

A global push to broaden participation in computer science has led to an explosion of interest in blocks-based programming. Visual blocks are used by numerous programming tools (see the sidebar). Millions of students receive their first exposure to programming via these tools in courses and activities like Code.org’s Hour of Code. Blocks allow beginners to compose programs without struggling with the frustrations of syntax (Figure 1).

Back to Top

There is increasing interest in developing and studying blocks languages. At VL/HCC 2015, a small workshop session called Blocks and Beyond^a ballooned to a large event, with 51 submissions and 36 presenters. Researchers shared work in new blocks languages, interface innovations, domain-specific applications of blocks, and ways to make blocks languages more effective and accessible for diverse coders.

This article explores how blocks impact the learnability of programming. We begin by reviewing studies on the effectiveness of blocks languages. Then we discuss the key features of blocks languages and how they relate to learning. Finally, we look at applications of blocks in new domains and discuss tools for creating your own blocks language.

Watching beginners create their first programs with blocks can be simultaneously inspiring and unsettling. Empowered by blocks, novices will rapidly build complex, often-delightful creations. But just as quickly, they fill their screen with clumsy and intricate code.²² A seasoned programmer inspecting a beginner’s disordered assembly might worry that snapping together colorful blocks has nothing to do with “real code.” But what is “real code,” and why learn it?

What is “real code?” The purpose of a blocks-based tool is to make programming easy to learn. But programming education can have two distinct endpoints: Development of expertise to support professional programming, and the ability to accomplish other goals by creating programs.

The two objectives are not necessarily the same. The designers of Scratch note that for users “who see programming as a medium for expression, not a path toward a career, Scratch is sufficient for their needs.”²⁸ The GP blocks environment is being designed to enable “casual programmers” to create ever more sophisticated programs, while removing limits that would force them to switch away from blocks.²⁴ Before discussing the learning effects of blocks-based programming, we begin with a caution that it would be shortsighted to assume that tomorrow’s programmers will program with the same languages and systems as today’s. Each generation of programmers shifts the culture of coding, and the definition of “real code” will continue to evolve.

However, core learning questions remain. For students who continue with the study of traditional programming, we can ask if a blocks-based introduction to programming is helpful or not. This question has been directly tested in classrooms.

Measuring learning transfer: Research indicates that learning a blocks language can improve later learning of a traditional textual language. In a study of 10^th graders learning C# or Java,¹ those who had taken a Scratch course in 9^th grade learned more quickly, understood loops better, and were more engaged and confident than their peers who had not. However, in the final test, a significant difference was seen in only one of three cognitive dimensions. In a study at two colleges,²⁵ students with little or no previous programming experience and weak math preparation completed a CS0 programing class using Alice before beginning a Java CS1 course. Starting with Alice improved student grades (GPA of 3.0 vs. 1.2 for non-Alice students) and the percentage of students taking further CS courses (88% compared to 47%).

The question of whether such effects are simply due to giving students more preparation in an extra class has been tested by creating courses that combine a blocks-based introduction with a transition to a traditional language. Reports from courses using Scratch before Java or C indicate improved student engagement and understanding of some concepts.^19,39 In one study focused on learning transfer,⁸ introductory Java course at CMU was modified to begin with Alice. Students in this class that used both languages averaged 10% or more better performance on every section of the same Java final exam, including expression evaluation, control structures, arrays, and working with class definitions.

That result is remarkable because one might assume that spending more time programming with blocks meant less time to learn Java. The study used a version of Alice that generated Java code from Alice blocks, and a mediated transfer pedagogy that made explicit connections between programming concepts in Alice and Java.

Other studies of CS1 courses that switch from blocks to text without these features have identified potential challenges to learning with blocks.^10,27 Switching from a blocks language to text can involve both a change in syntax and semantics, and Shapiro and Ahrens propose teaching the transitions separately, by introducing syntax before generalizing semantics.³² Additional research is needed to identify the circumstances under which blocks are effective.

Figure 1. Snap! is an example of a blocks-based programming environment. Users drag blocks from a palette of programming elements (left) into workspace (center), where blocks can be assembled into programs. Snap! also provides an output window (top-right) and a sprite picker (bottom-right).

Today, many introductory computer science courses use a blocks-before-text approach. In Harvard’s CS50, students move from Scratch to C; Berkeley’s CS10 progresses from Snap! to Python; Project Lead The Way’s Computer Science Principles (CSP) course uses both Scratch and App Inventor before moving on to Python; and Code.org’s CSP App Lab course moves from Droplet blocks to JavaScript.

Back to Top

Why Blocks Are Learnable

In 2004, Ko, Myers, and Aung¹⁵ identified six learning barriers encountered by non-programmers in programming tasks. Three of these—selection, use, and coordination—reflect the difficulty of simply assembling a program. We believe the learnability of blocks languages arises from how they address the usability challenges underlying these three learning barriers:

1. Learning a programming vocabulary is difficult. Blocks simplify this problem because picking a block from a palette is far easier than remembering a word: blocks rely on recognition instead of recall.
2. Code is difficult to use because it presents a high cognitive load for new programmers. Blocks reduce the cognitive load by chunking code into a smaller number of meaningful elements.
3. Assembling code is error-prone. Blocks help users assemble code without basic errors by providing constrained direct manipulation of structure (for example, two incompatible concepts do not have connecting parts).

Recognition versus recall. Programming with a simple language or library typically involves a vocabulary of about 100–200 words. For example, HTML has 100 tags and 100 attributes, and SQL has about 200 keywords; Scratch is similar, with 130 blocks. Recalling 100–200 concepts can overwhelm a newcomer.

Unlike text languages, blocks languages are intimately tied to their programming environments, and nearly all block environments have adopted a few interface conventions that address key usability problems. One such convention is tackling vocabulary by organizing blocks in functionally related palettes on the screen.

Palettes differ from autocomplete menus in professional code editors because they persist instead of disappearing and they organize concepts by topic instead of by name. This design simplifies discovery and exploration. Figure 2a shows the Sound palette in Scratch. It is an instructive reference showing all 13 methods for audio in that environment. Similar organization is seen in larger blocks environments. To help manage the complexity of creating mobile apps, App Inventor provides a dynamic set of blocks, with additional blocks available in programs that have interactions with more components (Figure 2b). Yet, the basic idiom is the same as Scratch: explorable palettes organized by function.

Figure 2. The sound palette in Scratch (a) and a voice synthesis palette in App Inventor (b). Palettes simplify the selection of programming elements by exploiting the ease of recognition over recall. Palettes organize concepts by topic, not name, and they remain open when used, allowing the user to discover and tinker with blocks based on their function.

Remembering the order, type, and valid values of operands is also daunting for newcomers. Many block languages address this by supplying blocks with default operand values, drop-down menus and specialized editors to specify operands, and extra words to indicate operand meanings (Figure 3a).

Figure 3. Blocks show structure visually (a. Scratch) instead of using punctuation. They can aid learnability using plain language, default values, and value pickers.

Chunking information with blocks. Programming languages present a high cognitive load to a student who is learning a new syntax. For example, consider the for loop in JavaScript syntax:

for (var i = 0; i < 50; i++) {___)

This dense notation is a barrier to beginners. In the words of one student, JavaScript “is really confusing to understand with all the parentheses and brackets and all of that.”³⁸

To understand the difficulty, consider that this code contains five words (for var i i i), 10 pieces of punctuation (( = ; < ; + + ) { } ), and two numbers (0 and 50), a total of 17 units of information. Studies of human cognitive capacity have established that people have a working memory of about seven chunks of information.²³ Trying to understand this line of code as 17 separate items may overwhelm the working memory of a new programmer.

Experienced JavaScript programmers have no problem understanding the line of code noted here because they have learned to interpret the code in larger chunks. Because a for loop follows a very common pattern, it can be read in just two chunks: first, the typical for loop that uses the conventional looping pattern (i starting at 0 and incrementing by 1); second, the particular choice of 50 as the upper limit. Figure 4 illustrates different ways of chunking the code.

Figure 4. Three ways of reading a for loop in chunks. A naive reading of code (top) interprets the code as 17 chunks, but an expert reading of code (middle) interprets the most common form of loop as a single chunk, with a second chunk for the loop limit 50. An alternative (bottom) reading interprets three clauses as chunks. Code.org uses the middle rendering when introducing loops to high-school students for the first time, and switches to the bottom rendering when students are familiar with for loops.

Blocks help reduce cognitive load by showing new programmers how to read larger chunks. In the Code.org Computer Science Principles course, blocks for JavaScript for loops are drawn just as an expert would see the code: as two chunks with a single block with a single socket for the loop upper bound. Complexity can also be reduced by nesting chunks within chunks. For example, Code.org reveals finer-grained for structure in more advanced portions of the same course, as illustrated at the bottom of Figure 4.

The use of blocks to chunk code aids readability even for simple commands, because blocks can forgo the punctuation that text code uses to denote structure and use explanatory words instead. For example, as illustrated in Figure 3b, a simple call in Python requires reading delimiters and knowing argument order, whereas the equivalent block in Scratch reads naturally, using appropriate abstractions (for example, a piano keyboard).

By organizing code as visible chunks, blocks help new programmers concentrate on what the code means rather than the notation that is used to write it.

Direct manipulation of visible structure. The visual form of blocks alleviates the burden of assembling syntactically correct units by typing one character at a time. But there are other advantages of directly manipulating program fragments that have visual constraints.

One benefit is the blocks can help prevent errors by making the grammar of the program visible. Blocks can be seen as a form of syntax-directed editing with constrained direct manipulation. In 1981, creators of an early structure-editing tool noted, “Programs are not text; they are hierarchical compositions of computational structures and should be edited, executed, and debugged in an environment that consistently acknowledges and reinforces this viewpoint.”³⁵

Block shapes help beginners understand which grammatical phrases (expressions vs. commands vs. declarations) are legal in what contexts. In Scratch, commands connect vertically with nubs and notches, whereas expressions are smooth shapes that fit into smooth holes. Constraints on drag-and-drop prevent the two types from being confused (Figure 5). Students report that the puzzle shapes are helpful for assembling programs.³⁸

Figure 5. Block shapes show and enforce rules composition. Scratch commands compose vertically, and expressions fit into holes. Here, a Boolean expression (diamond shape) is being dropped into a matching hole for a loop test condition.

Visualization of types by shape can be applied to richer type systems: OpenBlocks provides 14 connector shapes to represent different types,²⁹ and researchers have created experimental block languages with dynamically generated shapes to represent compositional type systems.^18,36 Directly manipulable blocks also encourage bottom-up tinkering with program pieces in ways not directly supported by raw text. Blocks programmers experiment with blocks by connecting them to build islands of code fragments on the programming surface that are isolated from the main program.^22,38 In blocks environments supporting liveness,²⁰ these fragments can be executed by pointing and clicking, providing a key benefit of interpreted text-based languages without a read-eval-print loop console separate from the editor. The program gradually grows as it is augmented by dropping in these fragments when they behave as desired.

Learnability Beyond Blocks. Blocks aid in the construction of code, but blocks alone are not enough to make a programming language learnable. Users new to a language face additional learning challenges:

• They must wrestle with practical aspects like installing language tools, saving/loading programs, and so on;
• They must learn the vocabulary of the language and understand the concepts denoted by its words;
• They need to understand runtime semantics such as flow of control and changes in state over time; and,
• They eventually need to learn common patterns of use, moving beyond isolated concepts.

Each of these learning hurdles can be helped or hindered by the programming environment, and each of these problems is an area of active research and development.

Programming online. To simplify installation, programming tools are moving online. When a programming environment is in a Web browser, a new programmer is just a few clicks away from creating a first program. A cloud-based programming tool can provide a complete and consistent programming environment with fewer potential problems.

Although blocks programming environments for beginners have long been offered online, text-based programming environments are also becoming available online. With tools such as Cloud 9, CodeAnywhere, and CodeEnvy, programmers of all levels can benefit from working online.

Words, concepts, and abstractions. The names chosen for language constructs can have an impact on learnability. Empirical studies by Stefik and Seibert³⁴ have found that common keywords like for or operators such as != serve as hard-to-learn jargon, and are not as easily learnable as familiar words such as repeat or unequal. They found the syntax of languages such as Java and Perl are no more learnable than a synthetic programming language with randomly selected punctuation used for keywords. Even more important for learnability are the abstractions chosen by language designers to allow users to build simple programs with compelling behavior. For example, the designers of Alice worked with users to develop intuitive abstractions for controlling 3D animations. During their design process, the Alice team eliminated jargon such as transformation matrices and substituted more intuitive concepts like object-relative motions. These new abstractions made it easier for users to specify 3D animations.⁷

---

By organizing code as visible chunks, blocks help new programmers concentrate on what the code means rather than the notation that is used to write it.

---

Designing languages and libraries focused on learnability based on empirical evidence is a major area for future work.

Runtime understanding. The dynamic state of a program can be made more understandable by making its state visible. For example, Code.org highlights the individual block actively running so the correspondence between code and action can be seen. Snap! provides widgets for every variable to show the current state.

Even with highly visible state, understanding actions in the past or future can be difficult. Liveness²⁰ is one approach to addressing this problem. A live system aims to make actions concrete by applying them immediately to the current state. For example, in App Inventor, Scratch, and Snap!, many edits to a running block program take effect immediately, without the need to restart the program.

Another approach for making the evolution of state understandable is to allow the programmer to travel in time by inspecting, advancing or rewinding the timeline of a program. The concept of omniscient debugging was first described in the early 1970s as a capability to trace backward in time through execution history to identify the location of the fault that caused a later observed failure.⁴⁰ TRAKLA2,²⁶ UUhistle³³ and Online Python Tutor¹² provide this capability for Java and Python.

Examples and reuse. The activity of programming has changed with the availability of large repositories containing examples of shared code. Programmers of all levels report finding and adapting examples as a core programming activity.^6,9 In response, professional programming and end-user programming environments are beginning to incorporate example support.^5,31 Novices, too, want to learn via examples, but may struggle to do so.³⁰

Blocks-based languages like Scratch and Looking Glass use online sharing and remixing programs to provide example access. But there is a trade-off between the simplicity of reuse and the robustness of reused code. For example, Scratch simplifies sharing of code examples for novices by providing a “backpack” for collecting program snippets and assets that can be shared and dragged into a new project. However, the backpack does not necessarily guarantee the code will run correctly in a new project.

In contrast, Looking Glass uses a more complex process for reuse in which users select the beginning and end of behavior they want to use. Coupled with execution history information, this can ensure the selected code will function within the context of a new program. A Play & Explore feature allows users to connect program output to the line or lines of code that caused it, helping users to understand and begin to modify reused code.

Back to Top

Scaling Blocks Code

Why don’t professionals program with block interfaces? One reason is that direct manipulation has efficiency disadvantages when making small edits. When creating an expression such as (a/2 + b/2) in blocks, the programmer must find and drag blocks for each of the three arithmetic operators, and then fill in holes with variables and numbers. Similarly, when rearranging an expression from (a/2 + b/2) to (a+b)/2, the expression tree must be pulled apart and put together again, requiring more gestures and more forethought than making the edits in text. HCI researchers observed that visual programming languages can have a higher viscosity than text code because they make small changes more difficult.¹¹

Beyond viscosity, blocks environments can have several other usability disadvantages compared to textual programming languages:

• Low density: Blocks take more space on the screen than equivalent text code.
• Search and navigation: It can be challenging to find and navigate to the relevant part of a blocks program in a 2D workspace, only part of which may be visible.
• Source control: collaboration and version control systems are difficult to use without a text representation.

The newest generation of blocks programming tools includes features designed to resolve the tension between usability advantages of text vs. blocks. There are two approaches: text-style entry and bidirectional mode switching.

Text-style entry of blocks. Some new blocks environments, such as Greenfoot’s frame-based Stride editor¹⁶ and GP,²⁴ are designed to be used by programmers to create large programs, so efficient editing is an important design goal.

Both Stride and GP improve efficiency by providing text-based editing shortcuts within a blocks-oriented interface. To allow users to circumvent the step of finding a block on the palette, these systems let programmers enter blocks through an in-line auto-complete mechanism. Blocks can still be chosen from a palette, but a knowledgeable programmer can insert them by typing. The Stride editor also introduces a hybrid approach to editing code, differentiating between low-level and high-level structure (Figure 6). For expression-level code, it hides syntactic structure and allows traditional text editing, providing high-density display and lower viscosity. Visible tree structure and drag-and-drop manipulation are used for higher-level code such as control flow and class declarations.

Figure 6. Greenfoot’s Stride editor combines text-style editing for expression-level details with drag-and-drop blocks for higher-level program structure.

Bidirectional Mode Switching. Some blocks environments provide a bidirectional transformation between a traditional text language and a blocks representation of that language. These include Pencil Code (CoffeeScript)² (Figure 7), Code.org’s App Lab^b (JavaScript), BlockEditor (Java),²¹ and Tiled Grace (Grace).¹³ Alice and Blockly provide non-editable views of text code.

Figure 7. Pencil Code provides bidirectional switching between blocks and text. Mode switching allows users to learn with blocks and edit quickly with text.

The hypothesis that motivates the design of dual-mode tools is that users may benefit from the learnability of blocks in one mode, while they learn syntax and get the efficiency of text in the other mode. This goal requires the views be linked. For text to be safe for users who may want to return blocks, it must be possible to switch between modes.

In dual-mode editors, the text code is the primary representation of the program, and blocks are a projected user interface view derived by parsing. This approach allows the editor to fully represent text information such as spacing, but it also means the editor must allow syntax errors that would not have been possible in blocks. Error-recovery heuristics convert simple text syntax errors to special error blocks, but complex errors can prevent mode switching.

Comparing approaches. There is a trade-off between the two approaches to unifying blocks and text. While the dual-mode editors provide direct support for learning traditional text syntax such as JavaScript or Java, they also impose the cognitive overhead of working with syntax errors that can only be introduced in text mode. Visualization research on multiple coordinated views suggests the benefits of providing more than one view need to be balanced against the cognitive overhead imposed by switching between views.³⁷

Single mode structure editors have the advantage of a conceptual model free of syntax errors, because the primary object being edited is the abstract syntax tree. However, to maintain consistency, many kinds of textual edits must be prevented, and other edits may require special tree-editing commands. These constraints raise editing viscosity, and they may present additional cognitive barriers. Interfaces that effectively bridge the gap between blocks and text are an active area of research.

Back to Top

Applying Blocks: Two Examples

Let us take a look at experimental blocks languages in two specific domains that are unfamiliar to most programmers.

Programming 3D printers. Traditionally, 3D printing models are drawn interactively by direct manipulation using CAD software. Writing custom code to create a model is a powerful alternative approach, but coding for 3D fabrication has traditionally been the province of a few expert programmers. Now, the falling cost and rising availability of 3D printers has made it possible for non-specialists to write their own custom 3D modeling code.

Two recently developed languages bring programming for 3D printing to novice users: BeetleBlocks¹⁷ and Madeup.¹⁴ Although the two systems have different languages, there are several commonalities: both are Web-based interfaces with a live 3D rendering of the shape being created, and both provide a blocks language to simplify learning. Beetle-Blocks follows the principles of turtle graphics: a beetle moves a “pen” that can be turned on and off, and 3D shapes can be created out of iterated strokes. MadeUp (Figure 8) takes a more abstract approach, allowing users to trace out both paths and parametric surfaces. Special functions can rotate or extrude the paths to create solids.

Figure 8. Blocks programming in MadeUp. 3D printing is an area of rapid innovation, and blocks make it possible to use new 3D modeling languages without a steep learning curve.

The two languages offer different levels of power and abstraction. Which language is the right one to use? This domain is an excellent example of the advantage of the learn-ability of blocks. Both blocks languages have a very shallow learning curve, and it is easy to try both.

Querying the Semantic Web. The frequent need to query large datasets is another domain where learnability is essential. Consider the problem of querying Resource Description Framework (RDF) data from the Semantic Web. SPARQL is the standard language for querying RDF; it includes several constructs for working with RDF triples that distinguish it from other query languages such as SQL. However, potential users of SPARQL face two hurdles: First, programmers must learn the vocabulary and syntax of SPARQL, with its specialized operators and constructs. Second, querying RDF requires not just knowledge of the language, but also knowledge of instance and schema data.

To address both problems, Paolo Bottoni and Miguel Ceriani have created a blocks language they call the SPARQL Playground.⁴ Rather than helping users learn about sequential programs, their blocks language helps users select, filter, and join data using SPARQL primitives.

The SPARQL Playground is interesting for a second reason: all query results in the playground are also returned as draggable blocks (Figure 9). This feature allows users to save instance data on the programming workspace to be incorporated into new queries. With the SPARQL Playground, it is easy to begin with general queries to explore the types of data available, and then use these discoveries to make refinements.

Figure 9. The SPARQL playground is a blocks-based query execution tool that provides blocks for constructing queries of RDF data. Query results (bottom) are also provided as blocks, and they can be dragged to build into other queries.

Back to Top

Making New Blocks Languages

It is now possible to create your own domain-specific blocks environment using a blocks-based language toolkit. Blocks language authors should be aware of at least three toolkits: Blockly,^c Droplet,³ and OpenBlocks.²⁹ The original blocks metalanguage is MIT OpenBlocks. Created in 2007 by Ricarose Roque as the basis of StarLogo TNG, it allows a large degree of geometric customization. OpenBlocks has also been used in App Inventor Classic and BlockEditor. One drawback of OpenBlocks is that it requires users to download and install the Java JDK. The challenge of installation is addressed by Blockly, an HTML-based block language toolkit by Neil Fraser of Google. Blockly is currently the most popular blocks language toolkit: it is the tool behind App Inventor, the SPARQL playground, and MadeUp, as well as the Code.org Hour of Code puzzles. Future versions of Scratch will also use Blockly. Droplet is the newest of the blocks language creation toolkits, developed by Anthony Bau for use in Pencil Code, and also used by Code.org in their App Lab. It is newer and less mature than Open-Blocks and Blockly, but takes a unique approach that allows seamless bidirectional transformation between all blocks and textual code.

Back to Top

Summary

When a programming language is provided as a user interface that welcomes novice users, rather than as a technical tool only for experienced developers, we arrive at a new picture of what the programming environment should provide:

• Vocabulary should derive from recognition, not recall;
• Cognitive load should be lowered by chunking code;
• Grammar rules and types should be made visible;
• Program chunks should be directly manipulable;
• Low-viscosity editing should also be possible;
• Coding environments should be available without the need for tool installation;
• Simple concepts should be described with clear words and high-level abstractions;
• Runtime state and behavior should be visible; and,
• Examples should be easy to find and apply.

In short, for a programming tool to be usable by new or casual programmers, its design must focus on learnability. Blocks have proven to be effective at solving many of these problems. Although programming is still not nearly as widely learned as it should be, the progress made by blocks language interfaces can inspire us all to see that programming can be made more learnable. The art of programming is the original human-computer interaction, and it remains an unsolved usability challenge. We can still do more to make programming available to all.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top