Support to build and maintain animations

Most animations systems require expertise of the user in using either a programming or a scripting language. This poses a burden on the user and discourages many potential users from building anima-tions. Our approach tries to overcome these difficulties by simplifying the user interaction a much as possible. This also requires automating as many tasks as possible, even at the risk of obtaining less attractive animations than manually (Brown, 1998).

We have designed a simple process to build animations based on the metaphor of office appli-cations. Metaphors are a well-known way of explaining a concept by means of different concepts.

They are often used in computer science, being the desktop metaphor the most widely known. Other authors have proposed different categories of metaphors (Madsen, 1994). Our use of metaphors is pragmatic: we emphasize their use as a particular kind of seeing as governed by previous situations

and examples rather than by rules and fixed categories. We also acknowledge that our metaphor is probably incomplete, but claim that it is useful to explain our approach. Metaphors are often used in animations in order to simplify either their production or their play. Thus, the video player metaphor is typically used in most systems (Gloor, 1998) to control the direction and pace of animations. It con-sists of a set of standard buttons (play, pause, rewind, etc.) and a speed control, often complemented with algorithm-specific controls. Another stimulating metaphor for playing animations is comic strips (Biermann and Cole, 1999).

Metaphors have also been used for modeling the different parts of a complex animation system, from construction to play. A theater metaphor has been used to explain Jeliot facilities (Haajanen et al., 1997). Thus, an animation can be considered a theatrical performance, an algorithm to be visualized can be considered a script, etc. Electronic books is also a common metaphor that helps in understanding the structuring of hypermedia elements to form a lesson or a set of lessons on algorithms (Brown and Najork, 1996; Brown and Raisamo, 1997).

2.3.1 The office metaphor

We use the metaphor of office applications in order to understand the construction and maintenance of animations. There are many kinds of office products: documents, spreadsheets, slide presentations, web pages, etc. However, they share some common properties. For instance, they are usually pro-duced by typing and selecting menu operations. Documents are easily modified by customizing their typography (fonts, sizes etc.). Depending on the kind of document, they also are composed of diffe-rent, standard parts: text, graphics, scripting code, etc. Finally, documents are produced and stored;

afterwards, they can be retrieved, modified and stored again.

Following the office metaphor, visualizations and animations are products delivered with an ap-plication (here, a programming environment) and they should be easily constructed, customized and amenable to be stored, retrieved and modified.

An important feature of office applications is their facility to produce automatically documents, without the need to know complex languages. There are documental languages (e.g. L^ATEX) which allow generating sophisticated documents, but office applications prevent the user from learning them.

WinHIPE gives support to (semi)automatically generate visualizations and animations. Both tex-tual visualizations and graphical visualization of lists are produced automatically, since they are a

Figure 2: Interface of an animation.

predefined elements of the language. On the other hand, the graphical visualization of trees requires binding their graphical format to a binary tree data type by specifying the identifiers of tree construc-tors. A configuration file saves the user from explicitly making this binding, but he/she can redefine it wherever he/she wants.

Animations are created on the fly by playing visualizations with the “animations window" shown in Figure 2. The raw material for building an animation is the set of visualizations of expressions generated during an evaluation. By default, an animation consists of all of the expressions, but the user may exclude irrelevant ones (according to his/her subjective criterion) by marking a check box within the “visualizations window".

This way of defining animations requires a global view of all the visualizations. An additional

“reductions window" provides a summary view of all the visualizations in the same way as PowerPoint does for slide shows. Showing reduced views of visualizations in a meaningful way is a technically difficult problem (Naharro-Berrocal et al., 2002) that has not been definitively solved.

Figure 3 shows all the visualizations obtained evaluating step-by-step the reversal of a given binary tree.

Figure 3: An improved grid of reduced visualizations.

2.3.2 Customization

WinHIPE allows the programmer to customize, by means of simple dialogs, the visualization of inter-mediate expressions in several ways (Vel´azquez-Iturbide and V´azquez-Presa, 1999):

• The programmer can select either pure textual or mixed text-graphics visualization of expres-sions.

• The typography of visualizations can be customized either by demonstration (pretty-printing formats) or using Word-like dialogs (graphical elements).

• Long expressions can be automatically abbreviated by a “fish-eye" technique (Vel´azquez-Iturbide, 1998), only showing the parts most relevant to understand the current evaluation state.

Figure 4 shows three different displays of an expression obtained while reversing a given binary tree. The second image is similar to the first one, with different typographic properties and without highlighting the redex; the third image is an abbreviation of the first one.

Customization does not only affect to a single visualization, but to all the visualizations or to the animation. In order to keep coherence, a customization of any of the previous three kinds propagates to any of the generated visualizations.

Sometimes, not only typography changes, but also the expression to evaluate, e.g. input data to an algorithm, such as the value of an element in a data structure. A facility is provided to rebuild such an animation given new input data, in an easy and consistent way. This facility is automatic when modifications in input data do not alter execution behavior, i.e. the nature and number of rewriting steps remains constant, but it can also deal with changes in the rewriting process.

Figure 5 shows the “rebuilding animation" dialog. The left side displays a vertical list of all the rewriting operations performed during an evaluation (represented with the same letters as in Section 2.1). This list of operations can be transferred to another list, at its right, representing the new list of operations from which to rebuild the animation. Here, operations can be included or deleted if necessary when input data changed. Finally, a button rebuilds the whole set of visualizations by applying this list of rewriting operations.

2.3.3 Storage and retrieval

Following the office metaphor, an animation can be stored as any other document. We allow two storage formats for animations. The simplest one only requires a directory to store the visualizations and a definition file. Such a file specifies whether by default the animation is to be played automatically or to be controlled manually; in the former case, the speed of transition between snapshots must also be specified. In a later session, the user can retrieve an animation in order to play or modify it.

Animations can also be stored as Web pages (Naharro-Berrocal et al., 2001b). Web pages

gener-Figure 4: Three visualizations of the same expression.

Figure 5: Dialog to rebuild a given animation.

ated by WinHIPE have a structure appropriate for lessons on algorithmic problem solving, composed of four parts: problem statement, algorithm description, program, and animation. This format allows integrating explanations and animations for educational use. A preliminary set of Web pages

contain-ing visualizations generated with WinHIPE can be found athttp://dalila.sip.ucm.es/~cpareja/winhipe/demos/demos.htm.

Animations stored in either format can be retrieved and modified. In animations stored with the simplest format, individual visualizations and the animation style are retrieved. In animations stored as Web pages, the program and explanations are also retrieved. In particular, retrieval of the program gives the possibility of going on with a programming session.

Both kinds of animations make sense on their own. The most typical usage is using the first format for animations of programs in progress, and the second one for animations of definitive programs, so that they are complemented with code and user explanations. The latter case will be used by teachers to prepare lessons, or by students to document assignments or to reinforce self-study.

3 Validation of animation capabilities for education

In this section, we use Anderson and Naps’ framework (Anderson and Naps, 2001) to assess algorithm animation systems as educational tools. They propose an “instructional design continuum" to measure the degree and fashion by which an animation system supports student interaction. It consists of eight levels, from simple to complex support. Assessing any system (in particular, WinHIPE) with the instructional design continuum has two consequences:

• We can know the strengths and weaknesses of the system for student interaction.

• We can identify opportunities for improvement.

Let us review the eight levels.