LiveWorld in its current state has a few shortcomings and inconsistencies in its design, which are discussed here. Solutions to some of these problems are also discussed in Chapter 6.
The workings of the theater/stage/cast mechanism is somewhat ad hoc relative to the rest of the user interface metaphor. These boxes have special relationships between each othber that are not found elsewhere in LiveWorld and are not capable of being explained by the basic mechanisms of the system. This magical mechanism is motivated by the need to have multiple views of actors. They must be capable of being seen both as graphics and as structured objects, and so the interface goal of having a perceived identity between object and screen representation must be relaxed.
This is not a severe problem for the interface; the relationship between the views is not hard to understand. Nevertheless it is annoying that a special mechanism is required in this case. Furthermore, the need for multiple views may not be confined to graphic objects, and this suggests that the solution to the ad hoc-ness of the theater mechanism should be a general mechanism for supporting multiple views. A related issue has to do with the need for actors to be able to change their appearance. LiveWorld allows graphic properties of actors to be changed, but not the general form, which is determined by the actor's prototype. Some other actor-based systems (i.e. Rehearsal World (Finzer and Gould 1984)) separate out an object's appearance into a separate object called a costume, which can be attached to an actor and easily changed.
One solution to these problems is to introduce the idea that an object is distinct from its graphic appearance and that it can have multiple appearances. Both costumes and the dual views of actors and boxes can be handled by a more general mechanism. This view mechanism might even be able to subsume other aspects of the system such as composite actors and specialized slots. The problem with this solution is that it significantly increases the complexity of the system by introducing new objects, and it might interfere with the feeling that users are manipulating real objects rather than representations of them.
LiveWorld's box was designed to fulfill many functions with a single uniform construct. This makes learning the system easier, but may impose certain cognitive penalties as well. The elements of the LiveWorld system appear rather uniform, both in terms of graphic appearance and at the functional level. For instance, objects and slots look the same--they are both boxes--and so it is possible, during the course of an interaction, to confuse one for another. The ability for boxes to have icons that indicate their type or states was a late addition to LiveWorld and helps ameliorate the uniformity problem. However, there is still a tension in the design between the desire for uniformity and particularity.
The deeper issue is one of abstract vs. concrete constructs. The box, which is designed to be capable of being a great many different things, is necessarily abstract in comparison with, say, a button that serves a single purpose and has only one operation it supports. While constructing a broad class of functions out of a small set of structural elements is elegant, esthetically pleasing, and reduces the number of things to learn, it can also cause difficulties for novices (diSessa 1986). The difficulty arises because the minimal elegant elements are necessarily abstracted from the concrete functional goals of the user. In contrast, systems in which each component is specialized by an expert for a particular use are less flexible, but they can be carefully designed so that each component is distinguishable, as are, for instance, the various elements of the standard Macintosh user interface (Apple Computer 1987).
In the early versions of LiveWorld, sensors had to be contained directly within an actor. This caused a problem when trying to define libraries of drop-in behaviors. The behaviors were dependent upon the presence of the appropriate sensors, so cloning the behavior alone from the library would not, by itself, produce the needed behavior. Somehow the behavior needed to bring the sensor along with it. A number of solutions were considered (and some were implemented). This design issue, while fairly minor, is typical of many such issues that arise in an environment like LiveWorld.