The main aim of this project is to develop an animation system for simple geometric objects. Of course this is not a very clear definition of what is required. While working on this project, the objectives to be reached have gradually evolved, and have become much more specific. The animation system resulting from this project should allow someone using it to build arbitrarily complex animation sequences using a series of simple commands. The key to achieving this is to ensure that the user need not plan an entire animation sequence in advance. It should be possible to divide the implementation of a sequence into parts, each of which can be implemented with relative ease. The objects in the system should be persistent - an object should be an independent entity which responds to messages passed to it by performing animation sequences. Ideally, a geometric figure in the workspace should always correspond to the same object in the animation system. Such a close correspondence would increase the consistency of the inte1face between the animation system and the user. When a user builds a more complex figure out of a series of simple animation objects, it should be possible to define this as an object in its own right, and manipulate it accordingly. It should also be possible to build still more complex objects out of several complex ones, so that objects of arbitrary complexity can be constructed in a flexible manner. This increases the usefulness of the system, because any collection of objects that the user perceives as an object in its own right can be treated as such by the system. Messages would normally be passed to the objects in the animation system through the Scheme transcript window. Effectively a user would be executing the methods of various objects in the system just as they would be executed from any Scheme program. This approach has the advantage that the same system acts both as an interactive program and a library of animation functions. Few users of the -system would really need so much flexibility, however. A graphical user interface would be a very useful addition to the animation system, as it would make communication between the user and the system more flexible. The user could enter information by typing in characters, selecting a menu item, or indicating a screen position with the mouse. Menus of the available animation functions would be provided. A novice could then learn to use the system by browsing through the menus and trying various commands. In the ordinary version of the system, the position of an object must be specified either in . terms of cartesian coordinates, or by specifying its new position relative to the old. This makes the placement of objects a trial-and-error process, because it is very difficult to visualise a shape when it is expressed in cartesian coordinates. The menu system could allow a user to directly specify the position of objects in the animation workspace, using the Macintosh mouse. This would give him or her immediate visual verification that an object is correctly placed. An important requirement not actually stated in the original specification of the project is that the system be as usable as possible. While usability is difficult to quantify, it seems clear that there are two basic principles adhered to (as much as possible) by this system which generally make a program easier to use. Firstly, it is important that the system should allow problems to be broken up into smaller and smaller pieces, which can be solved individually much more easily than the problem could be solved as a whole. Secondly, it is important that the user inte1face provided by the system should match as closely as possible what the user perceives as being the model's current state. The more closely the user and machine views of the animation system correspond, the less likely the user is to be confused by the way in which the model interprets a particular command.