Since the late 1960s, program language designers have been trying to develop approaches to programming computers that succeed with novices. None has gained widespread acceptance. We have now developed an entirely new approach that eliminates traditional programming languages in favor of a combination of two technologies: programming by demonstration (PBD) and visual before-after rules. This combination was never tried before. The result is the first commercial product based on PBD technology—Stagecast Creator, introduced in March 1999—enabling even children to create their own interactive stories, games, and simulations. Here, we describe this approach, offer independent evidence that it works for novices, and discuss why it works when other approaches haven’t and, more important, can’t.
The computer is the most powerful tool ever devised for processing information, promising to make people’s lives richer (in several senses). But much of this potential is unrealized. Today, the only way most people are able to interact with computers is through programs or applications written by other people. This limited interaction represents a myopic and procrustean view of computers—like Alice looking at the garden in Wonderland through a keyhole. Until nonprogrammers can program computers themselves, they’ll be able to exploit only a fraction of a computer’s power.
The limits of conventional interaction has long motivated researchers in end-user programming. An end user in this context uses a computer but has never taken a programming class—a definition describing the vast majority of computer users. We use the term “novice programmer” to describe end users who want to program computers. Is novice programmer an oxymoron? Is it a reasonable goal? Certainly there are “novice document writers,” “novice spreadsheet modelers,” and even “novice Internet surfers.” But in more than 30 years of trying, no one has come up with an approach that enables novices to program computers. Elliot Soloway, director of the Highly Interactive Computing project at the University of Michigan, estimates that even for novices who do take a programming class, less than 1% continue to program when the class ends. We’ll explore the reasons for this, but first we explore our own new approach to programming that seems to work for novices.
Stagecast Creator, a novice programming system for constructing simulations, from Stagecast Software, Inc., founded by the authors and others in 1997, is the culmination of a seven-year research and development effort, the first five at Apple Computer [3, 10, 11, 12]. The project, initially called KidSim, was later renamed Cocoa, and finally became Creator. The goal was to make computers more useful in education. For a variety of reasons, the co-inventors of Creator—the authors Smith and Cypher—focused on simulations, a powerful teaching tool for making abstract ideas concrete and more understandable. Simulations encourage experimentation, helping children develop sequential, causal reasoning, in other words, the scientific method. The goal of the Creator project evolved into empowering end users—teachers and students—to construct and modify simulations through programming.
Until nonprogrammers can program computers themselves, they’ll be able to exploit only a fraction of a computer’s power.
Our initial approach was much like that of other language developers, seeking to invent a programming language that would be acceptable to end users. We tried a variety of syntaxes; all failed dismally. That experience, together with the history of programming languages during the past 30 years—from Basic to Pascal, from Logo to Smalltalk, from HyperTalk to Lingo—convinced us we could never come up with a language that would work for novices. Our first insight was that language itself is the problem and that any computer language represents an inherent barrier to user understanding. Learning a new language is difficult for most people. Consider the years of study required to learn a foreign language, and such languages are natural languages. A programming language is an artificial way of dealing with the arcane world of algorithms and data structures. We concluded that no programming language would ever be widely accepted by end users.
Without a Programming Language
How can a computer be programmed without a programming language? Our solution combined two existing techniques: PBD and visual before-after rules. In PBD, users demonstrate algorithms to the computer by operating the computer’s interface just as they would if they weren’t programming. The computer records the user’s actions and can then reexecute them later on different inputs. PBD’s most important characteristic is that everyone can do it. PBD is not much different from or more difficult than using the computer normally. This characteristic led us to consider PBD as an alternative approach to syntactic languages.
A problem with PBD has always been how to represent a recorded program to users. It’s no good allowing users to create a program easily and then require them to learn a difficult syntactic language to view and modify it, as with most PBD systems. In Creator, we first sought to show the recorded program by representing each step in some form, either graphically or textually. Some of the representations were, in our opinion, elegant, but all tested terribly. Children would almost visibly shrink from their complexity. We eventually concluded that no one wanted to see all the steps; they were just too complicated.
Our second insight was to not represent each step in a program; instead, Creator displays only the beginning and ending states. Creator has a syntax—the parts of a rule, the lists of rules in an object, and the lists of tests and actions in a rule—but people can program for a long time without having to deal with it or even be aware of it. Creator uses language as an optional element, not a requirement.
As an example of the Creator approach, suppose we want the engine of a train simulation to move to the right. We move the engine by defining a visual before-after rule for the engine. Rules are the Creator equivalent of subroutines in other languages. Each rule represents an arbitrary number of primitive operations, or statements in other languages. Visually, Creator shows a picture of a small portion of the simulation on the left, then an arrow, then a picture of what we want the simulation to look like after the rule executes. Figure 1 shows the interactive, visual process of creating a rule.
First, we define the initial rule. Notice that the left and right sides start out the same; all rules begin as identity transformations. Users define the behavior of the rule by editing the right side. Here, we grab the engine with the mouse and drag it to the right. When we drop the engine, it snaps to the grid square it is over. That’s all there is to it. Nowhere did we type begin-end, if-then-else, semicolons, parentheses, or any other language syntax. The rule we just created may be read as follows:
- if the engine is on a piece of straight track and there is straight track to its right
- then move the engine to the right.
Notice that programming is kept in domain terms, such as engines and track, rather than in computer terms, such as arrays and vectors. And instead of dealing with objects indirectly through coordinates, users program them by manipulating them directly; that is PBD (see Table 1).
A similar commercial software-development system called AgentSheets developed by Alexander Repenning, a professor at the University of Colorado in Boulder, also uses visual before-after rules [7] (see Repenning and Perrone’s “Programming by Analogous Examples” in this section). It is delightful and the closest of any software system we know of to Creator. However, it does not use PBD. Instead, users assemble the tests and actions for a rule by explicitly dragging them into the rule from a palette of optional elements.
Since a rule in Creator may not show all the steps involved, just their beginning and ending states, it is not a representation for the steps, suggesting instead what the steps actually do. The rule acts as a memory jogger for users. This turned out to be the key technique we used in Creator for helping users understand recorded programs, even those written by others.
Theoretical Foundations
Why does Creator’s approach to programming (apparently) work where syntactic languages don’t? We hinted at the answer earlier. An essential ingredient is certainly the PBD technique, which eliminates the need for any syntactic language during program construction. The technique of using visual before-after rules finishes the job, eliminating the need for any syntactic language for program representation. But why would these two techniques be acceptable to the typical novice programmer? The answer is interesting, illustrating why traditional approaches haven’t and, more important, can’t work.
The main problem novice programmers have when programming computers is the gap between the representations the brain uses when thinking about a problem and the representations a computer will accept. “For novices, this gap is as wide as the Grand Canyon,” as Don Norman, noted interface design author, documented in his 1986 book User Centered System Design (see Figure 2). He argued that there are only two ways to bridge the gap: move the user closer to the system or move the system closer to the user [5]. Programming classes try to do the former. Students are asked to master a programming language. But what they really want to do is learn how to make software—something else entirely. An essential ingredient of such classes is teaching how computers work; students have to learn to think like a computer. This radical refocusing of the mind’s eye is difficult for most people. Even if they learn to do it, they don’t like where they end up. They don’t want to think like a computer; they want to control computers to accomplish tasks they consider meaningful.
In Creator, we’ve tried to do the opposite of what programming classes do; we want to bring the system closer to the user. We did this by making the representations used when programming the computer more like the representations used in the human brain. But first, we had to select a theory that would be helpful to us and found two, one developed by Aaron Sloman, one by Jerome Bruner.
Sloman’s approach. In 1971, Aaron Sloman divided representations into two general types: analogical and “Fregean,” after Gottlob Frege, the inventor of predicate calculus [9]. In an analogical representation, Sloman wrote, “the structure of the representation gives information about the structure of what is represented” [9]. A map is an example; from a map, one can tell the relationships between streets, the distance between two points, the locations of landmarks, and which way to turn when you come to an intersection.
Programming is kept in domain terms, such as engines and track, rather than in computer terms, such as arrays and vectors.
By contrast, Sloman wrote, “In a Fregean system there is basically only one type of ‘expressive’ relation between parts of a configuration, namely the relation between ‘function-signs’ and ‘argument-signs.’ … The structure of such a configuration need not correspond to the structure of what it represents or denotes” [9]. We can, for example, represent some of the information in a map through predicate calculus statements, such as:
- g: “Gravesend”
- u: “UnionVille”
- m: “Manhattan Beach”
- s: “Sheepshead Bay”
- East(g, u)
- EastSouthEast(s, g)
- South(m, s)
“The generality of Fregean systems may account for the extraordinary richness of human thought … It may also account for our ability to think and reason about complex states of affairs involving many different kinds of objects and relations at once. The price of this generality is the need to invent complex heuristic procedures for dealing efficiently with specific problem-domains. It seems, therefore, that for a frequently encountered problem domain, it may be advantageous to use a more specialized mode of representation richer in problem-solving power” [9].
Most programming languages use Fregean representations, aiming to be general and powerful. Creator emphasizes ease of use over generality and power. While Creator is “Turing equivalent,” meaning it can compute anything, it addresses only the specialized problem domain of visual simulations. It doesn’t try to do everything well but is very good at what it does. A better way to describe it than Turing equivalent may be “PacMan equivalent.” Creator is powerful enough to let kids program the game PacMan. That’s all we’re trying to do.
Creator uses analogical representations in its rules. For example, a rule for moving a train engine, as shown in Figure 1, can do the same thing as Fregean HyperTalk code, which can include dozens of arcane commands, as in the list in Figure 3. It is obvious which is easier to understand.
Bruner’s approach. In 1966, the educational psychologist Jerome Bruner asserted that any domain of knowledge can be represented in three ways [2]:
- “By a set of actions appropriate for achieving a certain result (‘enactive’ representation). We know many things for which we have no imagery and no words, and they are very hard to teach to anybody by the use of either words or diagrams and pictures.” In other words, you can’t learn to swim by reading a book.
- “By a set of summary images or graphics that stand for a concept without defining it fully (‘iconic’ representation).” In other words, children learn what a horse is by seeing pictures of horses or actual living breathing horses.
- “By a set of symbolic or logical propositions drawn from a symbolic system that is governed by rules or laws for forming and transforming propositions (‘symbolic’ representation).”
The first two ways are analogical representations; the third is Fregean. Jean Piaget, the noted Swiss psychologist best known for his work in the developmental stages of children, believed children grow out of their early enactive and iconic mentalities, and that becoming an adult means learning to think symbolically. By contrast, Bruner recommends encouraging children to retain and use all three mentalities—enactive, iconic, and symbolic—when solving problems. All three are valuable in creative thinking.
Creator seeks to involve all three mentalities in programming. Enactive mentality results from PBD when users manipulate images directly; drag-and-drop functions are enactive. Iconic mentality results from visual before-after rules and the domain of visual simulations. And symbolic mentality results from Creator’s use of variables, which can help model deeper semantics in simulations. For example, predator-prey-type simulations can be modeled through just a few variables.
Empirical Evidence
We’ve also gathered evidence that the Creator approach to programming works with novices. This evidence has taken three forms: informal observation, formal user studies, and anecdotal user reports.
Teachers and parents who worked with prerelease versions of Creator used it for years. We and our associates conducted hundreds of hours of direct tests on children and adults for the past five years, most on children ages 6 to 12 in school settings.
We implemented three computer prototypes of Creator, each smaller and faster and closer to product quality than the previous one, testing each on progressively larger audiences of novice users, and the final one—Cocoa—to an audience of hundreds of novice users. We distributed Cocoa through the Internet, just as we have with Creator, but our most important source of information was longitudinal studies in several elementary school classrooms in California. Teachers integrated the prototypes into year-long curriculums designed to improve their students’ problem-solving skills. They contrived problems that required programming for their solutions; one had her class program ocean-science simulations. Our most gratifying success was when one class asked to extend the school year so students could continue to work on their simulations. For the next six weeks of vacation, a third of the class continued to come to school once a week to program. The surprising thing is not that two-thirds of the children decided not to participate but that any of them wanted to keep going to school during summer vacation. These kids did not find programming an onerous task.
Independent researchers at several universities in the U.S. and England conducted formal user studies of the Creator prototypes KidSim and Cocoa [1, 4, 6, 8]. While each identified areas for improvement, all answered affirmatively what we consider the two most important questions: Can kids program with this technology? And do they enjoy it?
We found that within 15 minutes, most novice-user children were able to create running simulations with moving interacting objects. The studies found no gender bias, although boys and girls often build different kinds of simulations. Left to their own imaginations, boys often produce conflict games; girls often produce games involving cooperation. The studies suggest that the technology is usable by novices and is flexible enough for implementing a variety of ideas.
One of our early concerns was whether Creator would have enduring interest for children. We’ve now heard from some users and their parents and teachers that it does. For example, in Cedar Rapids, Iowa, Steve Strong, who teaches computer programming to students ages 14 to 17, lets each one choose the language he or she would like to learn, including C, Java, and Creator. Since adding Creator to the curriculum, he reports that as many girls as boys now take his course; students who use Creator have well-developed projects to show at the end of the class, while those using traditional languages typically have only a small part of their project implemented; and students learning Creator first and other languages later are better programmers than those who go directly into a traditional language.
Figure 4 shows a bizarre but hilarious game created by a 12-year-old boy in which a spaceship beams up cows. A user controls the ship’s direction with the arrow keys and the beam with the space bar. The goal is to beam up all the cows. Because of the high-level nature of the Creator rules, this game required only 13 rules to implement.
Figure 5 shows a model created by an 11-year-old girl of the way owls hunt mice in winter when mice dig tunnels under the snow. But the owl had better watch out, because a wolf wants to eat it. A user controls the owl with the arrow keys. The trick is to drop the owl on the mouse just as it passes under its claws. The goal is to catch five mice without getting eaten yourself. This game (actually two games in one) required 57 rules.
Conclusion
Early evidence suggests the approach to programming being pioneered by Creator is more acceptable to novice programmers than traditional approaches. Creator uses PBD, which is inherently enactive and iconic, for program construction. It also uses an analogical representation—visual before-after rules—for programs. The programming domain is limited to visual simulations, helping Creator bring the system closer to the user. Moreover, Creator shifts the language design emphasis from computer science to human factors. For example, the system’s designers left out such powerful programming-language features as object inheritance when tests showed that they were too complicated for novices.
Figures
Figure 1. Defining a rule by demonstration.
Figure 2. The Grand Canyon gap between the representations the human brain uses when thinking about a problem and the representations a computer will accept.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment