I find it useful to map out the space these tools lie in so that I may come to understand the design space, and I will attempt to do so here. Understand, however, that I have not found a language for such concepts that is common to most of the people I have talked to that do simple animations, so this is my own taxonomy.
I think one basic axis along which animation tools sit is cell-based vs. in-betweened. Cell-based tools are built on the concept that an animation is presented as a number of still frames shown in rapid succession. In these tools, the animator must specify what each frame looks like, one after the other. Usually, these tools allow the animator to divide up the moving objects into tracks or "characters," so that the sequence of frames for one object can be disconnected and managed separately from other objects. These tools are fairly simple, conceptually, but they are extremely time consuming. Also, the user must specify a frame rate early on, and it is virtually impossible to change that frame rate later.
Professional animators simplify this process with "In-betweening," in which a number of "key frames" are specified, along with some instructions for moving from one key frame to the next, and another party (either a computer or an animator with a lower salary) specifies the frames in between. This kind of animation is sometimes called "path based" because part of the motion instructions for an object can be a path for that object to follow. Other types of instructions can govern rotations, scaling, warping, or anything as high-level as the in-betweener can understand. In the computer animation world, in-betweened tools are usually similar to cell-based tools because users still need some way to specify the key frames and to separate characters from each other. However, these tools have the potential to be much simpler because a user does not have to specify each frame, and it may be possible to change the frame rate later if a poor frame rate was chosen initially. The challenge for these tools is to create an engine for in-betweening that is powerful, yet simple to use, since most of the user's time will be spent figuring out how to tell the computer to in-between the way he wants.
In all animations tools, there seems to be a concept of a "character," an object or set of objects that move as a unit, and for whom motion is specified as a unit. Animation tools also differ on what these characters are composed of. Are they an image or sequence of images, or are they points in a pen stroke? If they are images, then the tool can perform only limited transformations between frames, such as translations or rough image rotations or scales. If they are sequences of pen strokes, or regions specified by vectors, then the tools can perform more complicated transformations.
Most tools don't lie at the extremes of these axes, but have a little of both mixed together. I'll give a brief overview of the design process for both Macromedia tool, as well as an overview of the tool Prof. Landay and I were thinking of building.
Director is almost completely a cell-based, image-based tool. Characters are bitmaps, and in-betweening is limited to translation. This translation does not have to be on a straight line, but the facilities for specifying a curve are very limited.
The animator begins by creating "casts." Each cast contains a set of images that may belong to one character or many characters. The images can be created with a simple paint tool or imported. If the animator wishes for a character to move across the screen, he can wait to specify this in the "score," which coordinates the motions of all characters and which is where in-betweening is done. However, if the user wants to specify a rotation, he must create an image for each frame of rotation. Director can help to generate these images. The user can interactively rotate the object to a new position and specify a number of intermediate steps, and Director will create a new image for each step.
With a number of characters created, the user can open the score and begin specifying the frames of an animation. A frame rate is chosen, and the user can place sequences of images in "tracks." Each track can contain one image in one location in any one frame. In betweening translation is done by specifying the position of an image in two frames and selecting the "In Between" menu command to fill in the frames between. If the user specifies three positions instead of two, then the "In Between Special" command can be selected which will pop up a curve dialog box. The three positions are treated as control points of a spline, and the user can set several options for that spline before the system creates the new frames.
When this in-betweening method is not powerful enough for a certain effect, the user has two main ways to proceed. He can place an object, step forward one frame, and repeat, or he can place all objects in a sequence in one frame and then use the "Space to Time" command. This takes the images in a selected set of tracks and moves them into a single track at subsequent moments in time.
The user can view the animation at any moment and click a "play" button to run it. The frames cannot be modified while the animation is running. Also, changes to one frame affect that frame only, so moving an image to the right by one inch in every frame means modifying every frame (unless there is some trick that I missed).
Flash is much more stroke-based and in-betweened than Director. The makers of Flash went to great pains to keep the representation of the moving objects small, so that it could be transmitted quickly over a network. As a result, the objects are composed of curves fitted to pen strokes and fill regions. Imported images are supported, but not recommended. Since objects are mostly strokes, there is much greater support for in-betweening in flash. Animators can specify key frames and in-between them with translations, rotations, scales, or even motion along a path.
The user can begin either by creating a set of objects called "symbols" which are put in a library and brought out for later use, or by painting directly on the page. A score window is used that is similar to the one in director. At any given moment, the user is painting on or manipulating one of many tracks or "layers."
The user can proceed either by painting each subsequent frame anew, repositioning the objects in subsequent frames, or turning the frame into a "key frame" which will cause the system to compute the intermediate positions of objects in the empty frames leading to the next frame. The user can can simply specify the position, orientation, and scale of the object in that frame and let the system figure out how to get it there. This works most of the time, but sometimes the system's decisions on how to in-between may not be quite what the user had in mind, and more key frames must be inserted to fix the problem.
Another way to in-between position and orientation is with a "motion-guide." Each layer can have a corresponding motion guide layer (used only for that layer) which consists of an arbitrary curve. In-betweening can be done by creating this motion-guide curve, and then fixing the object to a position on that curve in two key frames. The system will then in-between along that curve, and will even rotate the object to point straight down that curve if the user specifies it.
The concept of fixing an object to a curve is a bit confusing. In actuality, the user only needs to place the object so that it is touching the curve in each key frame, but I did it with the "snapping" feature which was much more complicated, because I didn't know this until I was done. There is also a confusing interplay between motion guides and other types of in-betweening. If two key frames are specified with an object at two positions along a curve, then Flash can in-between along that curve and orient that object to point down the curve. However, if the user does not rotate the object in the second key frame to the exact rotation it WILL HAVE from the motion guide, then the object will jump to a new rotation at that point in the animation. This is one example of a number of types of little corrections that man need to be made in the course of specifying an animation.
Finally, the user can view the animation at any moment and click a "play" button to run it. The frames cannot be modified while the animation is running. Also, changes to one frame affect all empty frames after that frame. The frame rate is fixed at 10 frames per second.
We envision a simpler tool that frees the user from most of these details and may enable them to create some animations much more quickly. Plans are not solid enough to give a complete description here, but I will describe a few general points so that we can evaluate possibilities for our own design in the experiments that follow.
We envision a completely in-betweened, stroke-based tool. By "completely in-betweened" I mean that there is exactly one key frame, the first frame, and all later frames are deduced from this frame by instructions specified on the page with the objects. By "completely stroke-based" I mean that the user creates objects as a series of pen strokes, and even specifies motion instructions as a series of pen strokes.
The type of animations this system will be able to create will be determined by the language of pen strokes that the user can use to specify motions. Obviously, having a stroke language powerful enough to do all the things Director and Flash can do would be very unwieldy, so the trick to to support just enough so that users can do what they would probably want to do in a simple, rough animations.
Right now, we envision motion guides similar to the ones used in Flash, perhaps with an added dimention of time embedded in them with tic marks (i.e. each tic mark shows where the object will be at 1/4 second intervals or something like that). We also believe we can specify rotations by marking a center of rotation on an object, and drawing out a path which indicates the angles the object will rotate through. We will not provide any facility for scaling or warping.
In Flash, the user coordinates motions by specifying key frames at important points and then in-betweening. If two objects collide, for instance, the user will create a key frame at a moment before the collision and at the moment of collision, in-betweening the rest. Since we only have one key frame, we need some other way of coordinating events. We believe we can may do with strokes to indicate 1) collision in two motion paths, 2) one motion triggering another, 3) the appearance of an object, 4) the disappearance of an object. It will be difficult to evaluate these choices without building a prototype, but we will try to do so by looking at how users coordinate motions with current tools.