Timeline authoring tools have conventionally been employed to specify event orders such as sequences of animations. Such conventional timelines are best suited for static, linear sequences (such as MIDI sequencers) and do not lend themselves to interactive content. This forces authors to supplement their timelines with scripted actions, which are not represented. Conventional timelines also force frame accuracy on authors, which interferes with rapid explorations of different designs.
The timeline in conventional authoring tools such as Macromedia's Flash and Director are largely unchanged from their progeny. MusicWorks, the predecessor to VideoWorks, was a program designed to play music on a Macintosh computer. The user was presented with four channels of sound and could insert events into the channels at regular frame intervals, displayed either as a timeline or notes. Time flowed from left to right in discrete frames, the duration of which could be controlled globally by the user. MusicWorks was extended to support animation and became VideoWorks. VideoWorks kept the channel metaphor, including the name “score” but extended the previous technology to support one channel for each graphic object in the screen. VideoWorks became a common tool for presentations and application prototyping. In time, it grew in capabilities and sophistication until being renamed Director in 1988—a name intended to emphasize its role as an interaction design tool rather than just a simple animation tool. Despite this shift in intended usage from non-interactive linear sequences to highly interactive sequences, the central “score” metaphor, the timeline, remained largely unchanged.
Turning to FIG. 19, a conventional timeline 1900 as is presently known in the art is depicted. Conventional timeline 1900 consists of a series of tracks or channels 1910. A track corresponds, more or less, to an object such as a button. The tracks 1910 are divided up into frames 1920. Each frame is an atomic unit of time, for example 1/30th of a second. Behavior is specified by putting events in a particular frame of a particular track. For instance, if a user wants a button to turn red in 10 seconds, they would put a “set the fill color to red” event in the buttons track at frame 300. If a user wants a button to move from location 5 to location 25 over a time of 5 frames, they would put a “set location” event at frame 1 to “5,” at frame 2 to “10,” at frame 4 to “20,” and frame 5 to “25.” This would result in an animation of the button moving.
The timeline metaphor is very easy for users to understand and begin working with. The grid of frames makes it very easy to specify the exact duration, sequence, and synchronization of animation events. Users can easily see exactly what is on the screen at a given instant in time. However, the timeline breaks down when asked to handle the needs of interactive applications.
Conventional timelines have numerous weaknesses or flaws. First, a conventional timeline is a line. It is a linear representation while interactions are inherently non-linear. Thus, when it comes to the representation of loops and conditions, conventional timelines are of no use. A designer or user thus is forced to jump around the timeline, sticking in sequences where they might fit and relying on embedded code to control the playback of time. Furthermore, conventional timelines are global meaning they always show the entire application. Combined with the sequential display, this results in the timeline quickly becoming inefficient for large and complicated projects. As described supra, interactive sequences force the user or designer to arbitrarily cut up the timeline, inserting sequences wherever they might fit and controlling the execution of them with embedded jumps. As timelines stretch to tens of thousands of frames, users often forget where in time they placed different animated sequences. This confusion also exists in the vertical dimension. With potentially hundreds or even thousands of objects in a complex application, there is no straightforward way of knowing which channel contains a particular object at a particular time. The author is forced to try and remember. Additionally, conventional timelines enforce a very literal and exact notion of time on the author. There is no provision for specifying things loosely. The timeline requires authors to say things like “at 5:00, do something for exactly 13.5 seconds.” Authors cannot utilize loose expressions such as “do this after that” or “these have the same amount of time, but I don't know how long that will be.” The inability to “sketch” has been a consistent complaint of authors utilizing conventional timelines. This exacting notion of time prevents a user from working at a rough level during initial exploratory phases of design. Storyboarding is a very common technique in the design of both interactive applications and interactive movies. Tools such as Denim allow a designer to quickly and easily sketch out both the user interface and simple causality in a natural manner. Conventional timelines make exploration and sketching extremely difficult. The user trying different variations is constantly wrestling with the timeline, inserting and deleting frames, pushing things around, and generally rearranging them to fit their needs. As the application develops and the timeline becomes more complex and fragmented, and the author becomes increasingly discouraged with fiddling with the application in fear that a small change may render the application inoperable.
The inability to specify actions in a loose and relative way also makes many tasks overly complicated. Consider the common task of playing an animation while the system is processing some data. The literal conventional timeline provides no way of accomplishing such a task. Instead, the author has to create an animation loop of a fixed duration and control it programmatically. These weaknesses as well as others taken together render the conventional timeline non-optimal for interactive multimedia authoring.
Many have attempted to make the timeline more powerful. Flash MX, for example, supports the notion of hierarchical channels in its timeline, where one layer can contain other layers. These other layers have their own clock and can be hidden when not in use. This makes it easy to script relative animations such as a moon that orbits a planet while the planet orbits the sun. While this helps somewhat to control clutter, it does not address the more serious problem of hiding the interaction. Wolber in “A Multiple Timeline Editor for Developing Multi-threaded Animated Interfaces” extends the timeline metaphor to support multiple synchronous streams. While this makes the authoring of simultaneous tasks easier and reduces timeline clutter, it still does not address the difficulty of viewing interaction. In the end, no conventional system metaphor exposes both temporal sequencing and interaction that facilitates management of application complexity while still enabling the user to work rough.
USPTO Backgrounds
USPTO Backgrounds