back to ... Table of Contents Watch What I Do

The entire Rehearsal World theater, showing the STAGES menu at the left, all the available Troupes, and a descriptive help message about the BasicTroupe.


Rehearsal World:
Programming by Rehearsal[ ]

William F. Finzer
Laura Gould


Programming by Rehearsal is a visual programming environment that non-programmers can use to create educational software. It combines many of the qualities of computer-based design environments with the full power of a programming language. The emphasis in this graphical environment is on programming visually: only things that can be seen can be manipulated. The design and programming process consists of moving "performers" around on "stages" and teaching them how to interact by sending "cues" to one another. The system relies almost completely on interactive graphics and allows designers to react immediately to their emerging products by showing them, at all stages of development, exactly what their potential users will see.

The process is quick, easy, and enjoyable; a simple program may be constructed in less than half an hour. The beginning set of 18 primitive performers, each of which responds to about 70 cues, can be extended as the designers create new composite performers and teach them new cues.

We were motivated to undertake this project by our desire to give programming power to those who understand how people learn; we wanted to eliminate the need for programmers in the design of educational software. Programming by Rehearsal is implemented in the Smalltalk-80 programming environment and runs on a large, fast, personal machine: the Xerox 1132 Scientific Information Processor (the Dorado).

Computers and Intuition

In the spring of 1980 our attention was focused on a topic we called Computers and Intuition. It seemed to us that newly available, high-resolution computer images, combined with interactive control over these images, constituted a new medium for the presentation of information and concepts.

We were particularly concerned with the implications that this interactive computer graphics medium might have for education. We were also thinking about how paradoxical it was that the computer was often viewed as an engine for improving cognitive and analytical skills, while it might turn out that because of its superlative dynamic graphics, its main new contribution to education might be in the enhancement of non-analytical, intuitive thought.

Such ideas were certainly not new. Even 15 years ago, a few farseeing people proposed that computer graphics would have a profound effect on human learning. As Brown and Lewis wrote in 1968, "In the same way that books support man's linear and verbal thinking. Machines will support his graphic and intuitive thought processes." (See [Dean 68].) Similarly, in 1969 Tony Oettinger wrote "Computers are capable of profoundly affecting science by stretching human reason and intuition, much as telescopes or microscopes extend human vision." (See [Oettinger 69].) It seemed that now we had both the software and hardware to realize these visions.

From these ruminations grew the design and implementation of a system called TRIP which attempted to give students an intuitive understanding of algebra word problems through the manipulation of high-resolution pictures. (See [Gould 82b].) TRIP, implemented in the Smalltalk-76 system (see [Ingalls 78]) on research hardware, a Xerox Alto, took about two months to design and four months to implement. It was structured in the form of a kit so that teachers could add new time-rate-distance problems fairly easily; it included a diagram checker, an animation package, an expression evaluator, and an extensive help system. Members of the computing profession were impressed that we were able to bring to life such a complex, general, graphical, yet robust and helpful system in such a short time. Educators, however, were usually aghast that so much time and effort were needed to produce a single system and that the result was, in their view, so limited.

After we had pilot-tested TRIP and were thinking about what project to take on next, we realized that our interest had shifted up one level, from the actual design of educational software to the design of a "design environment" for educators. As our colleagues were busy building the Smalltalk-80 environment (see [Goldberg 84], [Goldberg 83], and [Krasner 83]), we undertook the task of extending and reifying that environment to allow curriculum designers who did not program to implement their own creative ideas.

Designer Control

The work described here is based on the belief that it should be possible to place the control of interactive computer graphics in the hands of creative curriculum designers, those with an understanding of the power of such systems but not necessarily with the ability or willingness to write the complex programs that are necessary to control the systems. Design and implementation constitute two phases of a feedback loop. In most design situations, in which programming is a separate and specialized skill, the designer must somehow convey embryonic ideas to a programmer, perhaps by sketching on paper or talking. Then the programmer goes away to write a program so that something shows on the screen to which the designer can respond. This process introduces interruption, distortion, and delay of creative design.

In the creation of educational software, it is particularly important that the design decisions be made by someone who understands how students learn and what they enjoy rather than by someone whose expertise is in how computers work. Too much of the educational software we see today has a lot of fancy graphics but little real learning content. We hope that if educators have more direct control of the computer, they will create high-quality software.

In the environment we describe here, the designer begins by sketching the description, not in words or on paper, but directly on the computer screen. This sketching is not free-form but is done with the aid of specially provided graphical entities. If the designer's ideas are rather vague, the process of sketching may help to define them; if the ideas are well defined, they can be quickly accepted, rejected, or improved. In either case, nothing is lost in the translation process, as the only intermediary between the designer and the product is a helpful, graphical computer system that gives immediate response. Since there is no waiting, the designer is involved in a collaborative, creative process in which there is minimal investment in the current production; thus a poor production can be rejected quickly and easily, and a good one pursued and improved.

The Rehearsal Metaphor

A large, supportive design environment needs a potent metaphor in which the unfamiliar concepts of programming will have familiar, real-world referents. Our goal was that the metaphor would serve as a guide to the designers without getting in their way.

Smalltalk is an object-oriented language. This means that all the basic elements of programming--strings, numbers, complex data structures, control structures and procedures themselves--are treated as objects. Objects interact with other objects by sending messages. Logo is an example of a programming language with one object, a Turtle, which can be sent a limited number of messages such as FORWARD 20. Smalltalk has many kinds of objects that respond to a wide variety of messages.

Our immersion in Smalltalk led us to extend the object-message metaphor to a theater metaphor in which the basic components of a production are performers; these performers interact with one another on a stage by sending cues. We call the design environment the Rehearsal World and the process of creating a production Programming by Rehearsal.

Everything in the Rehearsal World is visible; there are no abstractions and only things that can be seen can be manipulated. Almost all of the designer's interactions with the Rehearsal World are through the selection (with a mouse) of some performer or of some cue to a performer. Assuming that a designer has the germ of an idea, the creation of a Rehearsal World production involves:

A Scenario

Static words and pictures on paper are a poor substitute for direct experience with a dynamic, interactive, computer design environment. Nevertheless, we shall try to give the flavor of what it is like to use the Rehearsal World through a simple scenario involving two novice designers, Laura and Bill. Suppose that these designers are interested in the language curriculum and would like to make some sort of word game. We'll follow their efforts, skimming over many of the details of their interactions with the Rehearsal World with an eye to understanding some of the design decisions of Programming by Rehearsal itself. Although one person can manage both mouse and keyboard quite well, we'll assume that Laura is in charge of the mouse and Bill is typing on the keyboard. In what follows, the paragraphs describing the action of the designers have been italicized.
Figure 1. The control panel and the prompter's box, showing an initial help message. The icon in the corner is an eraser.

Bill and Laura know from their brief introduction to the Rehearsal World that all of the performers are clustered together in troupes waiting to be auditioned for parts in a production. They know also that the Rehearsal World includes a help facility that gives assistance and descriptive information about how to proceed.

Laura starts by selecting the HELP button from the control panel at the bottom of the screen (see Figure 1). Selection of the HELP button causes the "prompters box" to fill immediately with "procedural help" suggesting something that the designers might want to do next. When they select HELP initially, the procedural help message that appears explains that they can always obtain "descriptive help" about anything that they can see on the screen.

The fact that everything that can be seen is capable of self-description is an important component of the Rehearsal World and one that makes it accessible to non-programmers.

When they ask for descriptive help about the STAGES button, they learn that if they select the STAGES button, they will get a menu of troupes and productions. Laura selects the STAGES button which presents her with a menu of troupes and productions (see figure on first page of this chapter). She finds a Text performer in the Basic Troupe that she wants to audition to learn what it can do. Laura starts by asking it to describe itself and is told by the help system that if she selects the Text performer, she can edit the text that it displays. This editing is the default action of the Text performer. Laura and Bill spend a minute becoming familiar with the simple editor that the Text performer provides.

Figure 2. A BasicTroupe, containing a Text, a Number and a Counter, and a category menu for the Text performer.

The Rehearsal World uses a three-button mouse for pointing at things on the screen. The SELECT mouse button causes a performer to execute its default action. The NAME button always causes the name of the entity to appear at the cursor point; if this name is dropped in the prompter's box, a description of the entity appears. Finally, the MENU button raises a pop-up menu for the performer, enabling the designer to send cues to it. In interacting with a finished production, only the SELECT button is used; that is, the NAME and MENU buttons are not needed by the student user.

Laura uses the MENU mouse button to see the category menu for the Text performer (see Figure 2). Certain commonly used cues are at the top of this menu in lowercase while others are grouped under categories in upper case. Most of the cues and categories are shared by all performers. Only the categories at the bottom of the menu (in bold) are particular to the Text performer.

Figure 3. A Smalltalk browser showing the Rehearsal-Graphics category, the PictureView class, its ALTER category, the message named reverse from that category, and the method associated with that message.

In its current prototype form, the Rehearsal World contains 18 primitive performers, each of which responds to a standard set of 53 cues and an average of 15 cues particular to that performer. To understand what this means, imagine a BASIC with a thousand reserved words. This complexity would be intolerable without a hierarchical organization and a simple way for the designer to browse that organization. The Smalltalk-80 system provides a window, called a Browser (see Figure 3), whose visual structure reflects the hierarchical organization of the objects and methods in the system. In the Rehearsal World, functionality is organized around performers grouped together into troupes; the cues that each performer understands are grouped into categories. The result is that designers never have to scan too much information at a time, and, because each level in the hierarchy has a different screen appearance, they never lose track of where they are in that hierarchy.

Our novice designers proceed to rehearse the Text performer by sending it various cues. Laura tries move and resize and gets a pleasant surprise when the fonts change so that the text always fits within the performer's borders. She selects the SET category and gets a cue sheet showing the list of cues that have to do with setting text (see Figure 4). Some cues like setText: take parameters that are indicated by parameter lines next to the cue. They use the help system to discover that they can type any string as a parameter to the setText: cue. Bill types "goodbye" on the parameter line. When Laura selects the cue, "goodbye" appears in the Text performer.

Figure 4. A cue sheet for the SET category of a Text performer. The string `goodbye' has been typed on the parameter line of its first cue.

They discover through rehearsal that the setJumbled cue produces a random permutation of the characters in the text. They enjoy looking at the different bizarre configurations that jumbling a word can produce and decide to explore no more, but to make a jumble game as their first design exercise. As often happens, interaction with the design environment itself leads to a creative idea.

One would not expect jumbling of text to be a basic capability of a programming language. A programmer who encountered a need for such a function would expect to write a simple routine. In a design environment, however, we expect to find a great deal of high-level functionality, chosen with care by the implementors of the environment, so that the designer's attention is not diverted from the design task itself.

Laura and Bill's initial idea for their simple production is to use two Text performers, one to be placed above the other on the stage. The top Text is to contain the word to be jumbled and the bottom one is to act as a soft button (a button on the screen which, when the student selects it with the mouse, causes something to occur). In this case its action will be to cause the jumbling of the top Text (see Figure 5). Laura uses the copy cue to put a Text performer on an empty stage.

Figure 5. A stage containing two Text performers, the top one showing a jumbled word and the bottom one acting as a button which the user can select to cause the jumbling to occur.

Any existing performer can be copied. Thus each performer acts as a prototype from which other performers can be generated; each new copy will have exactly the same characteristics as its prototype.

Laura and Bill use the resize cue to make the Text performer fill most of the top half of the stage, and then they copy it to make a second Text performer (exactly the same size as the first) in the bottom half of the stage. Bill types the word JUMBLE into it, as this is what they want the user to see. With the blocking thus completed, they decide to give each of their performers a mnemonic name that describes its purpose; they call the performers JumbledWord and JumbleButton. Now they are ready to define the action of the bottom Text, which they want to act as a button.

Any performer can become a button. By turning a performer into a button, the designers get to decide what will happen when the user selects that performer. One of the categories on every category menu is BUTTON; its cue sheet contains the cue becomeAButton (see Figure 6).

After Laura sends the becomeAButton cue to the JumbleButton, it no longer responds to selection by providing an editor; instead, it simply flashes. It is now a soft button on the screen, but it has no action. They must show it what to do.

Figure 6. The cue sheet for the BUTTON category of the performer named JumbleButton. The square brackets on the parameter line indicate that the designer should write some code between them.

They do this by using the cue codeForButtonAction:[] to which every performer responds. Bill and Laura understand that they are expected to provide a block of code between the square brackets to describe the action that should occur when the user selects the JumbleButton. The action they want is very simple; they just want the JumbledWord to receive the setJumbled cue. Bill knows that he does not have to type the code; instead the Rehearsal World will "watch" while they show it what to do.

To the left of each parameter line is a tiny icon representing a closed eye. When Laura selects it, the eye opens to indicate that the system is indeed watching. Then Laura sends the setJumbled cue to the JumbledWord by selecting it. The code JumbledWord setJumbled appears within the square brackets of the codeForButtonAction:[] cue of the JumbleButton and the eye closes again (see Figure 7).

Figure 7. The code, written by watching, which indicates what the JumbleButton should do whenever it is selected by the user.

Two significant obstacles to learning a programming language are mastering the language's syntax and learning the vocabulary. In the Rehearsal World, the designers rarely have to know either the syntax or the vocabulary as most writing of code is done by watching. While the eye is open, the designers rehearse a performer and the system makes a record of this rehearsal. The Rehearsal World's ability to watch, in combination with a mouse-driven interface, means that the designers do remarkably little typing. The designers know whether or not the code is correct not so much by reading it but by observing whether the effect produced on the stage is the desired one.

Immediately after Laura sends the codeForButtonAction:[] cue, she can select the newly defined button to see if it behaves as expected. Each time she selects the JumbleButton, it flashes and the JumbledWord jumbles its text.

In a traditional programming environment the programmer moves back and forth between programming mode, in which typing code is the dominant activity, and running mode, in which testing takes place. In Programming by Rehearsal, the designer does not feel any shift from one mode to another.

Even though their production is very simple, Laura and Bill decide to document it. They have already given the two Text performers appropriate names: JumbledWord and JumbleButton. They use the help system to get the default comment for the JumbledWord and edit it to be more specific (see Figure 8).

Figure 8. The default comment associated with every Text performer (top) and the edited comment to be associated only with the performer named JumbledWord (bottom).

As a designer creates new productions and new performers, the Rehearsal World becomes more complex. The default descriptive help messages can be changed by the designer by simply editing what appears in the prompter's box and selecting the ACCEPT button. This provides a quick and pleasant method for providing descriptive comments for productions, performers and cues.

Figure 9. A stage named Jumble1 with a menu plus a cue sheet for its STORE category.

It takes our two designers less time to produce their first jumble game than it takes to read about it. Although they have some ideas about how to make the game more interesting and educationally worthwhile, they decide to store what they have implemented so far. It is the stage itself that must be instructed to do the storing. The stage has its own category menu and one of its categories is STORE. They store their efforts under the name Jumble1 (see Figure 9).

No fixed set of functions provided in a design environment will ever be satisfactory; the designers will always run up against the limits of that set and wish for more capabilities. The fact that stages understand cues suggests one of the mechanisms for extensibility in the Rehearsal World: every stage can be converted into a new performer and every stage can be taught new cues. A designer who needs a new kind of performer can construct one by aggregating existing performers on a stage, teaching that stage some appropriate new cues, and converting the result into a new performer.

There are many circumstances in which the designers may wish to aggregate performers: several performers belong together as a logical and spatial unit; a group of performers are to be used repeatedly within a production or in several different productions; a production is very complex, and creating a new performer allows a factorization of the entire problem into smaller ones.

Figure 10. An improved game named Jumble5, which evolved from Jumble1.

Bill and Laura's jumble game goes through four revisions until it finally becomes the one shown in Figure 10. This improved game contains four Text performers and a Number performer. The large Text at the bottom is used simply to give feedback to the student. The Text labeled "New Word" has been turned into a button; its button action is to cause a new secret word to be chosen from a List and presented in jumbled form in the top Text performer. This performer has also been turned into a button; its button action is to rejumble itself. The number of rejumblings is shown by the Number performer next to it. The Text performer in the center of the stage is to be edited by the student who will type the answer there. Every time that Text is changed, it will cause the answer to be checked against the secret word and suitable feedback to be provided. It does this by means of its change action.

When a performer changes in some fundamental way, as when a Number performer changes its value or a Text performer changes its text, it executes its change action. The default change action of a performer is to do nothing, but the designer can define this action for any performer. Certain other performers have additional possible actions: the Repeater performer has a repeat action, the List performer has a selection action, and the Traveler performer has a move action.

Figure 11. The wings of the Jumble5 game, showing a List performer in which the current secret word is selected.

In the Jumbles game Laura and Bill use a List performer to keep a list of secret words. Since they don't want the user to see the List, they place it in the wings (see Figure 11).

While everything should be visible to the designers, not everything should be visible to the user of the production. Wings can hold performers waiting to appear on stage, data structures like the List of secret words, or temporary variables used in computations.

A very simple game grew and prospered as our designers implemented it, changing in response to their new understanding of what they were doing, and to the needs and interests of users and other designers who experimented with it. It became something real that people wish to play with and from which they can get some increased intuitive understanding of the rules underlying English orthography.

Beneath the Rehearsal World--Through the Trapdoor

The Rehearsal World in some ways may be thought of as a visible Smalltalk. Although our original intention was to remove the need for programming at the Smalltalk level, it is paradoxically true that the Rehearsal World provides an excellent entry point for an incipient Smalltalk programmer. Designers may drop through the trapdoor of the Rehearsal World; beneath they will find all the tools of the Smalltalk-80 programming environment. A Rehearsal World tool found there is called the Performer Workshop. It looks like a simplified Smalltalk browser and provides a mid-level mechanism for creating new primitive performers and defining new cues.

For each kind of performer there is a corresponding Smalltalk class that is a subclass of class Performer. The inheritance mechanism of Smalltalk allows the subclass to inherit the message interface of class Performer. Each production corresponds to a subclass of class Stage. When designers store a production, the Rehearsal World defines a new subclass of class Stage. Interestingly, a stage is so much like a performer that class Stage is actually a subclass of class Performer.

Figure 12. A stage on which a Debugger performer has been placed temporarily so that the designer may observe the code for each successive action.
When designers create new performers, the Rehearsal World defines a new subclass of Performer and writes the code for the appropriate additional methods that the class will need for layout and for cues. Because the code written by the Rehearsal World is indistinguishable from code written by a programmer, one can inspect it and modify it in either a Performer Workshop or a Smalltalk browser (see Figure 3). There are two important features of Smalltalk that are not present in the Rehearsal World. The first is the ability to create a hierarchy of objects. In Smalltalk, when one constructs a new kind of object--that is, a class--one usually constructs it by defining a subclass of the existing class that is most like the new class. In that way the new class can inherit a great deal of the desired behavior. In the Rehearsal World, there is no concept of class. A designer who wants a new production that is similar to an existing one can modify the existing production and store it under a different name. A major weakness of this method is that modifications made to the first production will not be automatically reflected in the modified one. In contrast, a modification made to a Smalltalk class will be automatically reflected in its subclasses. The second difference between Smalltalk and the Rehearsal World is that in Smalltalk there is a distinction between a class and an instance of that class. The class is the abstraction; an object is always an instance of some class. A class may have any number of instances. Any changes to the class will be immediately reflected in all its instances. In the Rehearsal World, there are no abstractions, thus no classes. Everything is visible. Any performer can serve as a prototype and one gets new performers through copying. What is lost is the ability to have changes made to the original reflected automatically in the copies.


Ordinarily the sooner a program gives evidence that something is wrong, the easier it is for the programmer to diagnose the problem. Designers in the Rehearsal World find that bugs manifest themselves very quickly because nearly all state information is visible and because the flow of control from performer to performer is fairly obvious to the eye. Even so, a situation will occasionally arise in which the designer cannot easily account for some behavior on a stage. It seems appropriate in Programming by Rehearsal that help should come in the form of another performer, the Debugger performer (see Figure 12).

A Debugger, when placed on a stage, intercepts all the actions that performers execute, shows their code, and waits for the designer to tell it to go on. While the actions of the production are thus halted, the designers can investigate the cause of a problem using any of the normal Rehearsal World activities such as opening up cue sheets and sending cues. Additional actions that may be initiated are placed in the Debugger's queue for later execution.

Animation and Multiple Processes

An intuitively pleasing, though incorrect, model for the Rehearsal World would be that each performer goes about its business independently of the others except when it needs another performer to answer a question or do something. Performers would be like people in the real world, capable of independent action but interacting through requests. Animation, you might think, would be easy because each performer would have its own rules for moving around on the screen. In this model, which we call the one-process-per-performer model, each performer would essentially have its own processor for its private use. Trouble comes when performers have to share resources and coordinate that sharing. Several schemes for dealing with these problems have been developed over the years.

Our own solution to the problems introduced by having one process per performer was to allow each user action to initiate a single independent process that either runs to completion or, as with animation, continues in an infinite loop. A single production can, at any given time, have any number of different processes running in it. (Beyond that, there can be several stages on the screen at a time, each running its own processes). This one-process-per-user-action model has so far proven to be both intuitive and powerful, though we see it as an area where further research is necessary.

Designers at Work

Since the Rehearsal World is a prototype system, very few designers have had a chance to experiment with it. The first one to actually use the system was Joan Ross, a curriculum designer from the University of Michigan. Joan created many interesting productions using the Picture and Turtle performers. She helped us to debug the system and to understand how to improve it on all levels as we prepared for a pilot study. We spent a month responding to the issues that Joan raised as a result of her experiences and then invited Dan Fendel and Diane Resek, curriculum designers and faculty members of the Mathematics Department at San Francisco State University, to visit for three days to see what they could create in the Rehearsal World. They are very experienced designers, familiar with the power of interactive computer graphics, but they are not programmers.

We gave them a tour of the system and within 45 minutes Dan and Diane had taken over and were using the Rehearsal World themselves. They started by investigating a simple production we had made about probability and soon suggested and implemented some improvements. They found out how it worked by looking at the button actions and change actions of the performers, both on stage and in the wings. By the end of the first afternoon, they had turned it into a game that bore only a slight resemblance to our original exploratory activity. In the process, they had auditioned Texts, Numbers, Lists, and Repeaters to discover their capabilities, dealt some with the blocking of the stage, written a fair amount of code by watching, and understood about button actions, change actions, and repeat actions.

Figure 13. The GoldRush game and its complicated wings, showing more performers backstage than are on stage.

Dan and Diane spent an hour the next morning away from the machine, designing with words and a pencil. In the course of this design session, they refined their embryonic ideas for a fraction game through discussion of both the pedagogical issues and the fantasy through which they should be transmitted. They also considered which Rehearsal World performers they would need in their proposed game. The fantasy involved a cave filled with gold dust. They envisioned the ceiling of the cave as an irregular set of stalactites, they saw the floor as tiled. The student's problem would be to sweep a vertical broom through this cave, one floor tile at a time, trying to collect as much gold dust as possible without ever allowing the broom to touch the ceiling. The broom would stretch or shrink by a certain fractional amount which the student would specify before each move. For example, if the student edited the fraction to read 2/1, the broom would become twice as tall when it moved.

They had other design criteria as well. They wanted the game to configure itself differently every time the START button was selected, and they also wanted to make it easy for a designer to specify an easy cave, with broad floor tiles and very little variation in the ceiling, or a hard one. They wanted to have a score that was expressed as a percentage of the available gold dust; they wanted some sort of disaster to occur if the student made the fraction too large and the broom touched the ceiling. They decided to call their production GoldRush (see Figure 13).

We found this description quite overwhelming for an initial project, as we had expected them to embark on something at the level of the Jumble Game described earlier. Rather than starting with a toy example for practice, they were embarking on a real-world task after only one day's experience. We worried that they had chosen something too difficult for them to accomplish in the remaining two days.

By lunch time they had figured out how to use the turtle to draw the floor. They said, "We need a Floor Director to be in charge of drawing the floor," and placed a button in the wings labeled FloorDirector for that purpose. They used this same strategy to make a CeilingDirector, a Checker to test whether or not the broom was touching the ceiling, and a DisasterDirector in charge of what should happen when it did. Certain performers had become, if you will, visible procedures. They invented this strategy on their own, led to it by the Rehearsal World's emphasis on buttons.

Next to these directors in the wings, they placed the performers that would be needed by the directors to accomplish their tasks. These performers fulfill the role of variables; since everything in the Rehearsal World must be visible, all variables must be represented by performers. By grouping their performers in a logical manner, they could debug their program easily by selecting a button, like the CeilingDirector, and simply watching what happened, both on stage and in the wings.

Their next task was to implement the broom (for which they used a Rectangle), the START button, and the MOVE button. The action of the START button was simply to cause the FloorDirector and the CeilingDirector to perform their button actions. The action of the MOVE button was first to move the broom and then to ask the Checker to determine whether or not the broom was touching the ceiling. If it was, it asked the DisasterDirector to perform its action. If it wasn't, the Checker computed the score. That they had not yet even designed the disaster didn't matter; they were using top-down programming techniques, realizing that they could return later and replace the empty code block of the DisasterDirector with whatever they wanted.

By the end of the day, the FloorDirector and the CeilingDirector were both working properly and they could move the broom through the cave. They started to plan the randomness that they wanted to build into the button action of the START button.

The next day they made a fraction to be edited by the user, creating it from two Numbers and two Rectangles, one to act as the line between the Numbers, the other to act as a frame. This looked and worked fine, but they soon discovered that it was a great disadvantage to be dealing with four independent performers instead of a single unified one: whenever they decided that their fraction was the wrong size or in the wrong place, they had to resize or move four performers commensurately.

Consequently they felt the need to create a new Fraction performer, which they did by placing two Numbers and a Rectangle for the central line on an otherwise empty stage. Since other performers would need to use the values of the numerator and denominator of this Fraction performer they taught this stage the new cues getNumerator, getDenominator, and getValue. Then they told it to convert itself into a new performer named Fraction and promptly used it in their production.

By the end of the third day, they had a game that worked, that they could respond to, that they liked, and that still needed improvement.

An extra day of work was devoted to adding new features. A Number performer called Parts was added that could be edited by the user; its change action was to show the broom divided into the number of parts indicated. This additional piece of design arose from their interaction with the production; had they been working entirely from a paper sketch, this improvement might not have occurred to them.

They then invited others in our research center to play. Although it had been designed for third-graders, our colleagues found the game interesting and fun to play. They were impressed with the quality of the game and especially with the fact that the designers were non-programmers, yet had implemented something so complicated in only a few days.

Eventually we found some children of an appropriate age to be students; they also enjoyed playing the game and spent many hours trying to make a perfect score. Diane now plans to reimplement GoldRush at San Francisco State using the Rehearsal World design as a prototype but changing it to run on different hardware which might include color and have a different pointing mechanism.

Research Questions

Our experiences with designers have given us confidence that our general ideas about how to make the power of computers accessible to non-programmers are correct. We believe that interactive, graphical programs could and should be built inside an interactive, graphical programming environment. We believe that for such programs, some sort of visual, spatial programming will eventually supplant the current process of writing lines of textual code. Nevertheless, we have many unanswered questions about the nature of visual programming.

An important aspect of the Rehearsal World is that everything is made visible: only things that can be seen can be manipulated. Thus, rather than thinking abstractly, as is necessary in most programming environments, a designer is always thinking concretely, selecting a particular performer, then a particular cue, then observing the cue's instant effect. We know that much of the initial accessibility of the system is due to this concrete, visual, object-oriented approach. What we don't know are its shortcomings.

As designers create increasingly large and sophisticated productions, they may find it a nuisance to have to instantiate everything (even temporary variables) in the form of a performer. There are problems with space on the screen and with visual complexity. Some of these problems are addressed by the ability to collapse a large set of performers into a single new one, which can be made very small while still retaining its original functionality. This helps not only with space but with factoring the production into significant pieces.

While beginning designers benefit from the concreteness, more experienced ones will benefit from being able to think in more general and abstract terms. They are led to think in general terms by the fact that all performers respond to a large set of common cues; they are led to think in abstract terms through the manipulation of Lists and Repeaters. Still, it may be difficult to build productions, for example, that need to access large amounts of data. At some point, the concreteness may become a barrier rather than an advantage. We know that the "watching" facility is very important to beginners and makes it possible for them to write code without learning a language. But it's really very simple and is in no way "programming by example"; it employs no generalizations but merely makes a textual record of a performer being sent a cue, perhaps with parameters. Again, advanced designers might be led to think abstractly rather than specifically if the Rehearsal World provided a more powerful watching facility that was capable of some form of generalization.

In the Rehearsal World, button action and change action are the major mechanisms for expressing the interactions of all performers. A few performers, like the Repeater, the List, and the Traveler, have other special actions as well. Designers find these actions very natural and so far have had no difficulty describing their needs in these terms. However, the Rehearsal World does not provide designers with the facility to create new types of actions for new performers, and this may become a problem in the future.

The Rehearsal World supports multiple processes in such a natural way that our designers are not surprised by the existence of this facility as they interrupt whatever they're doing to do something else. However, we have little experience with designers using multiple processes in some production and expect a variety of conceptual and mechanical difficulties to arise.

Designers express actions in a procedural fashion, instructing a performer to send a cue under certain conditions. We are curious about how designers would deal with a constraint-based Rehearsal World in which the relationships between performers were expressed in terms of conditions that should always hold true (for example, that the value of a Number should always be twice that of another Number). We hope that researchers working on similar design environments will explore these questions.

Rehearsal World

Uses and Users

Application domain: Design environment for educators

Intended users: Designers of educational software who are not programmers

User Interaction

How does the user create, execute and modify programs?
Objects have button actions and change actions.
To specify how an object is to behave, the user can create programs for these button and change actions. Although this can be done by writing programs in Smalltalk, it is possible to instruct Rehearsal World to "watch" and then perform an action. The Smalltalk code corresponding to that action is recorded by the system.
Supports incremental development of software through creating new performers and teaching new cues.


Inferencing: No inferencing

Program constructs:
Supports assigning functions to be invoked when an object is clicked on, or when it changes in some way.
But only single actions are recordable. No programming constructs are available via demonstration.


Machine, language, size, date: Xerox Dorado, Smalltalk-80, 1984.

back to ... Table of Contents Watch What I Do