4.4 Interface Details

• 4.4.1 Selection
• 4.4.2 Menus
• 4.4.3 Mouse Operations
• 4.4.4 Cloning
• 4.4.5 Inheritance
• 4.4.6 Interestingness
• 4.4.7 Box Sizes and Positions

An interface is what gets in between you and what you want to do.

­ Carl Havermiste (Havermiste 1988)

4.4.1 Selection

LiveWorld's interface command structure is based on the standard select-then-operate user interface model. Once a box is selected, it may be operated on by menu commands, keyboard commands, or mouse gestures, all of which can be customized for particular boxes and their spinoffs. Multiple selection is partially supported. Several frames can be selected together and operated on as a group. For instance, if a group of actors is selected they can all be sent a :grow message with a single menu selection. However, not all operations make sense for all groups of selected boxes. This is especially true when boxes on different levels are selected. In particular, if a box and one of its containing boxes are both selected, dragging becomes problematic, because the base against which the inner box is moving is itself moving.

4.4.2 Menus

LiveWorld has three menus of its own. The LiveWorld menu contains global controls and items that operate on the selected box. This is about the same set of operations described in the mouse-gesture table below, plus some additional commands for saving and restoring frame structures to files. The Slots menu shows what slots (annotations) are accessible for the selected box. Both local and inherited slots are included. Slots are organized under the prototype box in which they appear in the regular box view, and the prototypes are arranged in inheritance order, providing self-documentation of the inheritance structure.

Figure 4.6: Slots and Ask menus, in this case for the box named
#/theater-1/cast/rectangle-2.

Selecting an item from the Slots menu finds or creates a slot frame as an annotation to the selected frame, declares that slot interesting (see 4.4.6) so that it will be visible, and selects it. Since this has the effect of moving down one level in the box hierarchy, the Slots menu also includes an inverse operation, Up, which allows the user to navigate up the box hierarchy by selecting the box enclosing the current selection. The Ask menu lists all available methods or slots with values for the selected frame. Choosing an item from the menu sends the corresponding message to the selected frame, that is, it is equivalent to a call to the Lisp ask procedure (see section 4.5.2). If the message corresponds to a method that takes arguments, the user will be asked to supply them. The menu items indicate whether or not they take arguments and if they have an equivalent keyboard command (see section 4.5.3. If the ask procedure returns a value it is displayed next to the Ask menu.

Both menus are customized for the selected box or boxes. In the case of multiple selection, the Ask menu shows only methods or slots that are valid for each of the selected boxes. It's more difficult to define a sensible behavior for the Slots menu when more than one box is selected; currently it simply shows the slots for a single selected object.

4.4.3 Mouse Operations

Many operations in LiveWorld can be performed with mouse gestures. A mouse gesture is a combination of a mouse click on some part of a box together with some set (possibly empty) of modifier keys.

The use of modifier keys is somewhat unfortunate, since they are not a particularly easy-to-learn interface technique. Ideally, there would be an affordance (that is, a visible and clickable part) for every possible action. If this were so then there would be no need for modifier keys. But the limitations of screen real estate, together with the large number of operations possible, does not allow this. The combination of separate box regions and modifier keys is a compromise measure. To ameliorate the difficulty this may cause, several rules are adopted: * All gesture operations can also be accessed from the LiveWorld menu.

* The interface tries to maintain consistency of meaning among the particular modifier keys. For instance, the command modifier usually indicates an editing operation, while the command-option-control modifier indicates a deletion (of a frame, value, or prototype, depending on the region of the click).

Boxes can customize their handling of mouse gestures by changing the value of annotations within a set of frames knows as click tables. For example, buttons (Figure 4.7) work by providing an entry in the body-click-table for ordinary clicks that calls a user-specified action (and makes control-click take over the ordinary function of drag, so the button can still be moved). A separate click table can be defined for each part of the box (body, resizer, prototype, and so forth). For the purposes of mouse click handling, the graphic representation of an actor is considered a region and has its own table. Click tables also serve as documentation for mouse gestures

Figure 4.7. Illustrating the use of click-tables. The left-hand box is a button which performs an action when clicked (it can be dragged with control-click). The box on the right is a turtle actor, which will be rotated rather than resized (the default) when given a cmd-click mouse gesture.

4.4.4 Cloning

New objects are usually made by cloning existing objects with a mouse gesture. The steps involved are as follows: * The user clones an existing box with a mouse gesture.

• A new box is made that has the original as its prototype. The new box lives in a special frame called #/limbo.
• The new box appears to float over the world, casting a shadow (see figure 4.2). As it is dragged, potential homes are indicated by highlighting them. Some boxes specify that they can only be dropped into particular types of boxes (for instance, sensors can only be dropped into actors).
• The new object is dropped into its home when the user releases the mouse.
• Install methods are run (see section 4.7.4).

4.4.5 Inheritance

LiveWorld objects that are cloned from a prototype maintain a live link back to that prototype, and continue to look up values for local annotations in the prototype until local values are defined. This results in what I call dynamic inheritance, meaning that changes in prototypes can affect spinoffs, a fact which is reflected in the interface. This is most noticeable in the case of actors, whose properties can be affected by mouse motions. If an actor with spinoffs is resized, for example, and the spinoffs are inheriting size values from it, they will also change as the mouse moves. This gives a strong tactile feeling for the nature of inheritance. However, it can also lead to expectation violations. An attempt was made to mitigate this by the use of special dragging handles that indicate which objects will be affected by a drag or resize operation (see Figure 4.8).

Figure 4.8: Dragging handles. oval (on the left) is selected, so it has solid handles that allow the user to change its position or size slots. oval-1 inherits its xsiz and ysiz slots from oval, so it has hollow handles to indicate that it too will change if those properties are modified in oval.

Dynamic inheritance is a useful feature for conveying the idea and feel of inheritance, but it is somewhat in tension with the realist metaphor. Although it is based on realistic cognitive models it does not correspond to the behavior of real world objects. While you might understand your neighbor's car in terms of a "prototypical car" (perhaps your own) you do not expect the neighbor's car to change colors if you should happen to paint your own! This issue is an example of what (Smith 1987) refers to as "the tension between literalism and magic". There is a tradeoff between adherence to a real-world metaphor and providing access to the useful properties of the computational world that might appear to violate that metaphor. In this case I was particularly interested in exploring the properties of an interface that incorporated dynamic inheritance, so the decision was made to allow this "magical" property into the system. A system aimed solely at novices might choose to adhere more closely to the literal metaphor, or perhaps make dynamic inheritance available as an option.

4.4.6 Interestingness

Framer creates local annotations for slot references. This means, for example, if a rectangle object inherits its color from a parent, it will nonetheless get a local color annotation on the first reference. This is done primarily for efficiency--the local annotation serves as a cache that will speedup future lookups. However, it means that there are many slots in existence which are not of direct interest to the user. A newly created rectangle has about 12 such local slots, with only 2 of them (the x and y positions) actually containing information unique to that rectangle. To deal with this problem, LiveWorld defines an interestingness predicate for frames which controls whether or not they are displayed. Essentially a frame is deemed interesting if it is acting as other than a local cache. This is true if it fulfills at least one of the following criteria:

• It has a local value;
• Its prototype is other than the default;
• It contains an interesting annotation; or
• It has been explicitly marked as interesting by the user.

The last clause allows users to make local slots visible, usually for the purpose of modifying their value. For instance, when a user creates a new frame using the Slots menu it is marked as interesting to ensure that it actually appears. Some frames have this property set by the system, such as the cast and stage annotations of theaters, because such frames should always be visible.

4.4.7 Box Sizes and Positions

The size and position of a box are specified by internal annotations on the corresponding frame. These annotations are internal, that is, they are not normally seen by the user (see section 4.7.2). Using the system to represent information about itself has several advantages:

• Sizes and positions are automatically saved and restored along with the rest of a set of boxes when they are closed or written out to a file.
  
• Box sizes and positions inherit dynamically, just as those of actors do. This means that dragging or resizing a box might change the position or size of a spinoff. This behavior might be disconcerting, but can also serve to reinforce the reality of inheritance relationships to the user.
  
• A user can choose to make the internal frames visible, which results in a dynamic display of the internal workings of the system. By default, boxes will automatically resize themselves to be just large enough to contain their contents. This too is done on a dynamic basis, so if an internal box is being dragged, its container will resize itself during the drag. This process is known as "shrink-wrapping". Of course a user might also want to specify the size of a box by hand, for instance if she was planning to drop a large set of new items into it and wanted to make the space in advance so they could be arranged properly. To deal with this a box has a third internal slot, preferred-size, which contains the user-specified preferred size or nil if the default shrink-wrapping behavior is desired.