Practical End User Programming with Stagecast Creator

by Allen Cypher and David Canfield Smith

Programming by Demonstration (PBD) seems like the most promising approach to bringing the power of programming to non-programmers. The main obstacle to its effective use is the problem of Inferring the User’s Intent: When the user demonstrates an action, there are many reasonable interpretations of that action. Stagecast Creator is a practical end-user programming environment that side-steps many of the problems of inferring intent.
Creator is an environment for creating interactive simulations. Let’s consider what an “ideal” environment for creating simulations would be like, and then see how Creator modifies this idealized environment to produce a truly practical implementation. Suppose the user wants to create a simulation where a character walks to the right and jumps over fences. In an ideal PBD environment, the user would create this program by telling the environment to “watch what I do” and then dragging the character to the right and over the fences as shown in the figure.
Creating an appropriate program from this input requires a considerable amount of inferencing. It is not clear whether the ground is relevant, whether this is a single action or a series of actions, and what the program should do when other characters are present on the screen.
A classical PBD system would be able to infer the answer to all of these questions. It might conclude that the ground is relevant, since it appears throughout the example. It could note the similarity in context for the two fences and break the action down into individual “walk right” and “jump over fence” actions. Finally, since no other characters are present in the example, it could infer that this program does not apply when other characters are present.
This classical approach would be successful for this example. However, as the situations and demands on the system increase in complexity, it becomes harder and harder to provide an inferencing system that is clear and comprehensible to the user and that is effective in generating the desired programs. Although there is not yet a working, practical PBD system that relies on this sort of inferencing, that does not mean that this approach is infeasible. Rich McDaniel’s work, for instance, is making significant progress in this direction. Stagecast Creator has been designed with the explicit goal of offering a simple, powerful, and practical environment for creating interactive simulations. To achieve practicality, it side-steps many of the difficult problems in inferring the user’s intent.

1. Segmenting.

Creator does not attempt to infer how a given activity should be broken down into individual actions. The user must decide what actions to include in a rule. For instance, the user could choose to create a single rule for the entire activity of walking 4 steps to the right, jumping over a fence, walking 3 more steps, and jumping over a second fence. We teach users early-on that it is preferable to create small rules for specific situations, since these rules will apply in a greater variety of situations. The above rule would only apply when there were fences 5 and 10 squares in front of the character. It is preferable to create a “walk right” rule, and one or two rules for jumping over a fence.

2. Specifying context.

Creator does not attempt to infer which nearby objects are relevant to a given rule. Rather, the first step in creating a rule is to drag out a region called the “spotlight”. This region explicitly specifies the context of the rule. If the user includes the gound squares beneath the character in a “walk right” rule, then the character will only walk when it is on ground. If the user makes a “walk right” rule that does not include these squares, then the character will be able to walk through the air.

3. Defaults.

A very simple and effective way to infer intent is to include default behavior. However, defaults are not very powerful, since they can only make generic inferences. Overly intelligent defaults are perceived by the user as being inconsistent. Creator uses defaults in many situations to make the process of creating rules easier.

3a. Appearances.

In Creator, characters can have more than one appearance. For instance, there may be one appearance for facing left, and another appearance for facing right. The user must decide whether a rule should apply to just the current appearance of a character, or to all appearances. We have found that in the majority of cases, the appearance of the “self” character is important in the rule, while the appearance of other characters in the rule is not important. Therefore, by default, Creator automatically adds a test to each rule to require that the appearance of the “self” character matches the appearance in the rule.

3b. “Don’t care” squares.

When a square in a rule is empty, there are two possible interpretations: either the rule requires that this square be empty, or it doesn’t care what is in the square. By default, we assume the square must be empty. The user can then mark a square as “don’t care” if desired.

3c. Add value vs. Put value.

When the user makes a rule that changes the value of a variable from 4 to 5, the user probably wants to increment the variable by 1. But it is also possible that the user meant to Put 5 in the variable, or perform some other calculation. However, if the current value is 86 and the user makes a rule that changes the value to 5, the most likely meaning is “Put 5”, rather than “Subtract 81”. We believe that the best default behavior is to infer an increment or decrement for small changes, and a Put otherwise. However, other people on the programming team felt that this would be too inconsistent, so the default is always a “Put”.

In our presentation at the workshop, we will present a live demo of Creator and discuss the role of inference in end-user programming.

Allen Cypher cypher@stagecast.com
David Canfield Smith
Stagecast Software, Inc.
(650) 354-0739