<< >> Up Title Contents

4.2 Design

4.2.1 General Goals

LiveWorld was designed to support certain basic qualities of interaction: all parts of the system should be concretely represented and accessible, the system should feel reactive, it should permit exploratory or improvisatory programming, and there should be a clear learning path that leads a user from simple to more complex modes of use.

4.2.2 A World of Lively Objects

Creating animate systems requires the creation and organization of many different kinds of parts, including worlds, actors (graphic objects, also called creatures), agents (behavior generators). Each of these parts in turn can have parts of its own or aspects affecting its appearance and function. The number of objects can be quite overwhelming unless deliberate steps are taken to present the complexity in a form that a novice can comprehend.

The approach used by LiveWorld is in the tradition of Smalltalk and Boxer, in that it tries to make computational objects real for the user. Objects should be concrete--that is, they should appear to have a solid existence, metaphorically rooted in the properties of physical objects, and tangible--they should be accessible to the senses and actions of the user.

The techniques used to achieve these goals include a simple yet powerful object-oriented programming system with prototype-based inheritance (arguably more concrete in its operation than class-based inheritance); and the integration of the object system with an equally simple-yet-powerful direct manipulation interface (see Figure 4.1). Together object-oriented programming (OOP) and direct manipulation serve to make computational objects appear as concrete and tangible. These properties allow users to make use of their visual and motor abilities to interact with computational objects. LiveWorld is designed to support agent-based programming, or programming with an animate flavor. It is not itself constructed from agents[11], but is intended to support the creation of agents, both computationally and from a design standpoint. Object-oriented programming is the existing programming paradigm best capable of supporting animate thinking (see 3.3.2), so LiveWorld starts from that basis. Objects are animate in the sense of being capable of acting, but only in response to messages from outside themselves. This is a powerful paradigm, fully capable of representing a wide range of computational activity, but its metaphorical implications may be limiting. OOP presents a picture of objects as passive, taking action only in response to a stimulus from the outside. For LiveWorld, we want objects to seem capable of acting as animate creatures.

As set out in Chapter 3, the three salient characteristics of animacy are purposefulness, autonomy, and reactivity. The agent systems described in Chapter 5 are more directly concerned with these issues, but the underlying level is capable of providing some basic support for the latter two. Autonomy is supported by special objects called animas, which provide a facility similar to processes, but in a style designed to support agent-based programming. Animas provide a "power source" which can be combined with other objects to produce independent behavior, running independently from user activity and from each other. They form the underlying basis of some of the simpler agent systems detailed in section 5.1. Reactivity is supported by sensors that allow objects to detect other objects or conditions in their environment, and by the more general computed-slot facility that allows values to be automatically updated from changing environments.

4.2.3 Spatial Metaphor and Direct Manipulation

To make computational objects real for the novice, who has not yet developed the skills to mentally visualize them, objects can be given some of the properties of physical objects, such as appearance, location, and responsiveness to action. In other words, they should be brought out to the user by means of a direct manipulation interface (Shneiderman 1983). The interface should disappear as a separate entity; instead the user should be able to think of computational objects as identical with their graphic representation (Hutchins, Hollan et al. 1986, p97).

LiveWorld presents itself as a collection of recursively nested graphic objects, arrayed in space and manipulable by the user. This idea is largely borrowed from Boxer (diSessa and Abelson 1986), following the design principle referred to as naive realism. LiveWorld retains Boxer's basic metaphor of recursively nested boxes, but differs from Boxer in the way it treats its basic object. In Boxer, boxes are understood in reference to a textual metaphor. A Boxer box is like a character in a text string that can have internal structure, which will be other lines of text that also may include boxes. Boxes have no fixed spatial position, but are fixed in relationship to the text line that contains them. There are no classes of boxes (except a few built-in system types) and no inheritance. In contrast to Boxer, LiveWorld boxes are to be understood as graphic objects that may be moved with the mouse. While Boxer's interface is rooted in word processing (specifically in the Emacs text editor (Stallman 1981) from which Boxer derives its command set), LiveWorld's is rooted in object-oriented drawing programs. Both systems extend their root metaphor by allowing for recursive containment.

LiveWorld's object system supports the idea that a user should always be able to access internal data, but shouldn't have to see detail that is irrelevant to her needs. Complex objects can be treated atomically as necessary, but opened up so that their workings can be viewed and their parameters can be changed.

4.2.4 Prototype-based Object-oriented Programming

Object-oriented programming (OOP) makes programs more concrete by giving them a feeling of locality. Under OOP, each piece of a program is closely associated with a particular object or class of objects. Rather than an abstract set of instructions, a routine is now a method, belonging to a particular object and intended to handle a specific class of communication events. It has a location, and in a sense its function is made more concrete by its association with a class of objects. Prototype-based languages (Lieberman 1986) (Ungar and Smith 1987) are an alternative to the class-based object schemes used in more traditional OOP languages such as Smalltalk, CLOS, or C++. Prototype-based OOP arguably offers additional concreteness by dispensing with classes. In a class-based object system, every object is an instance of a class, and methods are associated with a class rather than with particular concrete objects. While classes are usually represented by objects, these objects are of a different order than normal objects and are sometimes called meta-objects to emphasize this distinction. In contrast, a prototype-based system has no distinction between classes and instances or between objects and meta-objects. Instead of defining objects by membership in a class, they are defined as variations on a prototype. Any object may serve as a prototype for other objects.

The advantages of prototype-based programming are simplicity, concreteness, and the possibility of a better cognitive match between program construct and the thinking style of the programmer. It eliminates whole classes of metaobjects, and simplifies the specification of inherited properties. In a sense it is object creation by example.

For example, the properties of elephants might be defined by a prototypical elephant (Clyde) who has color gray and mass heavy. Properties of Clyde become defaults for the spinoffs, so all elephants will be gray and heavy unless their default is overridden, as in the case of pink elephants. With prototypes, the specification of defaults and exceptions are done in exactly the same way, that is, simply by specifying concrete properties of objects. In a class system, one would generally have to use separate sorts of statements to express both "all members of the class elephant are gray" and "except for the pink ones".

There are some indications that mental representation of categories is structured around prototypes (Lakoff 1987). Whether this translates into any cognitive advantage for prototype-based computer languages is open to question. What prototypes do accomplish for programming is to smooth out the development process, by easing the transition from experimentation to system-building.

LiveWorld's prototype-based object system is a modified version of Framer (Haase 1992), a knowledge representation tool that provides a hierarchical structure for objects, prototype-based inheritance, and a persistent object store. It is based on a single structure, the frame, which can take the place of a number of constructs that are usually separate. Framer is a representation-language language in the tradition of RLL-1 (Greiner 1980). In this type of language, slots of a frame are first-class objects (frames) in their own right. This ability to put recursive slots-on-slots makes it relatively easy to implement advanced programming constructs that are difficult or impossible to realize in conventional object systems, such as facets, demons, dependency networks, and histories. For example, any slot-frame can have a demon added to it, which will be stored on a slot of the slot.

Framer was not designed as an object system for dynamic environments like LiveWorld, and required a few modifications, additions, and speedups. I chose Framer for this task because of its hierarchical structure, which was a perfect match for the Boxer-like interface I envisioned for LiveWorld, because of its simplicity, because of its prototype-based inheritance scheme, and because the ability to recursively annotate slots made it a very flexible vehicle for experimentation. LiveWorld's graphic representation for the frames is the box, which is described below. From the user's perspective boxes and frames are identical, and for the most part I will use the terms interchangeably.

4.2.5 Improvisational Programming

A programming system for novices ought to support experimentation and improvisation. The model of use should not assume that the user has a fully worked-out model of the task. Rather, the system should assume that the user is engaged in an activity that consists of incremental and interleaved design, construction, debugging, and modification. This means that each part of the user's cyclical path between idea, execution, and evaluation has to be short and relatively painless.

Figure 4.1: How LiveWorld supports improvisational programming.

Improvisational programming relies on the ability to build programs incrementally[12]. This facility is an important part of dynamic programming environments for novices such as Boxer or Smalltalk, since novices need the short feedback cycle that incremental programming can provide. From the standpoint of interface design, incremental programming is akin to non-modal interface design: conventional programming requires constant switching between writing and testing, while incremental programming attempts to reduce or eliminate that modal switch.

A graphic browsing and editing interface contributes to the improvisatory feel of a system by laying out all the available parts and options for the user, encouraging combination, modification, and experimentation. Lisp and Logo generally have not included such a facility, but Boxer and Smalltalk have made browsing interfaces a prominent part of their design.

The combination of object system, incremental programming, and graphic construction gives the system the feel of a construction kit. A construction kit essentially provides a set of parts that are both more complex than "raw material" and are designed to fit together. Kits support improvisation because they reduce the effort needed to try new configurations.

Prototype-based object systems are arguably better at supporting improvisation than their class-based equivalents. A class-based system makes it hard to create one-of-a-kind objects, so building something is always at least a two stage process (first defining the class, then instantiating an instance). Prototype-based systems eliminate this barrier, freeing users to build concretely without having to first turn their concrete ideas into abstract classes.

The immediate feedback of the system closes the gap between execution and evaluation. Graphic displays that provide affordances for action can involve the user in object manipulation and suggest courses of action.

4.2.6 Parsimony

Also borrowed from Boxer is the idea that a single structure, the box, can be made to serve a multitude of purposes. In most languages, variables, data structures, sets, graphics, classes, buttons, and palettes are very different sorts of things with very different interfaces. In Boxer and LiveWorld all of these structures are replaced by the box, which is flexible enough that it can perform all of their functions. This technique is of great value in reducing the complexity of the interface, since only a single set of manipulation skills needs to be learned.

4.2.7 Metacircularity

As much as possible, the interface of LiveWorld is defined in the language itself, giving the user control over its appearance and operations. Framer's recursive structure makes it easy to use frames to represent information about frames, and LiveWorld makes frequent use of this capability. For instance, display information for frame boxes is stored in (normally invisible) frame annotations to each displayed frame (%box-position, for instance). If you display these frames, they get their own display annotations, recursively. Because LiveWorld represents its internal processes in the same way as its user-level information, it may be considered as capable of a degree of computational reflection (Maes 1987) (Ferber and Carle 1990) in that it is possible for programs within LiveWorld to modify their underlying interpreter and related mechanisms.

4.2.8 Graphic Realism and Liveness

LiveWorld strives for a feeling of real objects interacting in real-time. The principle of naive realism is heightened in LiveWorld by displaying boxes and actors as solid objects that retain their solidity as they are moved around. This simple but important technique serves to heighten the realistic and concrete feel of the medium.[13]

Figure 4.2: A cloned sensor about to be dropped into a turtle actor.

When a box or actor is in transit (for instance, just after being cloned but before being dropped in its home) it appears to float over the world, casting a shadow to indicate its transitional state (see figure 4.2). The "liveness" of LiveWorld requires that many activities are ongoing simultaneously. This means that screen objects must be able to move concurrently, and also that screen animation can proceed concurrently with user interaction. The feeling of liveness is enhanced by updating displays immediately. For instance, dragging an object will cause any related displays to update continuously, not only after the object is released. Also, autonomous screen objects continue to act during user interaction, and responsive objects may change their behavior as a result of user motion, again even before the operation is complete. The goal of the system is to encourage users to interact with the systems they build.

Many systems that allow interactive editing of a runnable system use global mode switching as a predominant feature of their interface (for example, the NeXT Interface Construction Kit has a big icon of a knife switch for this purpose). These systems impose a barrier between construction and use that should be unnecessary. LiveWorld avoids the need for global mode switching,[14] encouraging users to modify their systems as they run. This has the effect of tightening the debugging loop as well as making the interface less modal.

4.2.9 Learning Path

A programming system for novices should be both easy to learn and powerful. It is too much to expect a powerful system to be learned all at once, so the system needs to provide a learning path consisting of techniques that allow a user to progressively learn and adopt features of the system. Each layer of the system should provide "conceptual scaffolding" that allows the learning of the next layer to be rooted in existing skills. Complexity needs to be hidden until it is needed, at which time it should reveal itself in understandable terms.

In LiveWorld, there are a number of distinct levels of usage that exist within an integrated framework. The intent is that simple modes of use should be easily learnable and also lead the user into the more complex modes. For example, a user whose only experience is in using direct-manipulation graphics programs can approach the use of LiveWorld as she would a drawing program. Unlike a drawing program, however, LiveWorld makes the properties of the object into manipulable objects in their own right, and can thus introduce this novice user to the idea of properties; slots; and values.

The learning path of a novice might follow these steps:

The coexistence of several modes of use that shade naturally into each other creates a learning curve. Mastery at one level can function as scaffolding for learning the next.

4.2.10 Rich Starting Environment; Libraries

One important stage of use in the scaffolding model is programming by copying and combining pre-built objects and behaviors from libraries. Later, users may open up these objects to see how they work and change them. Alan Kay has termed this style of use "differential programming" (Kay 1981). The idea behind differential programming is to support the common desire to make an object that is almost identical to an existing one, but with a few small modifications. This is quite different from Logo's approach (see section 1.3.3), while Boxer is somewhere in between. Logo environments generally begin as blank slates, containing only a turtle. A new Boxer environment presents a blank slate to the user, but the educational community around Boxer has also developed a style in which the user begins with an already-constructed microworld containing both working examples and components that can be used in new simulations.

LiveWorld goes beyond Boxer in that it is designed to permit easy modification and combination of pre-existing components by direct manipulation. Any existing object (from a library or elsewhere) can be cloned, and the clone can then be modified incrementally without affecting the original. If a modification turns out to have an undesirable effect, the modification can be undone by deletion, and the object will revert back to the properties and behavior of the original. LiveWorld's hierarchical object system allows library objects to be combined into new configurations: i.e., a user might combine a graphic representation for an actor cloned from a library of pictures and add to it sensors and agents cloned from separate libraries.

Aside from their use as sources of prototypes and components, the libraries also act as sources of examples. That is, each entry in a library may be treated as a closed object, which is used as is, or an open object that can be modified or inspected.

[11] Section 6.3.5 dicusses the prospect of building a system that is entirely based on agents.

[12] Sometimes the ability to build programs incrementally is conflated with the distinction between interpreted and compiled languages. While the idea of interactive incremental program construction has its roots in interpreted languages, modern programming environments support incremental compilation, so that the benefits of compilation and incremental construction can be combined.

[13] The ability to do smooth double-buffered dragging was made possible by the Sheet system developed by Alan Ruttenberg.

[14] LiveWorld does have a master switch to turn off animation, but its use is optional--editing can take place while things are running.

<< >> Up Title Contents