General approach to animation.

** General

The goal of animation is that the user will understand
the algorithm better. The basic situation is that the user
heard a lecture on the algorithm, but is not sure concerning
details and even some phases of the algorithm. 

Simulation must be on-line: calculations for each next step
are executed exactly before showing its results. This is in
order have an interactive system, i.e., to take care of any
(allowed) changes made by the user before ordering this step.
(In contrast, if the calculations are made in-advance, such
interactiveness is impossible.)

** Work organization

The project must be prepared and submitted to the supervisor,
BEFORE the implementation, on paper or white-board, in detail 
and in colors, simulating the screen animation. 

There are usually changes/additions during the programming,
originated from both students and supervisor, since it is hard
to know in-advance how the implementation will go. So, several
meetings with the supervisor, with presentation of a working
version of the program are usually needed.

** Wasting time

1) If you encounter time-consuming difficulties in attempts
to implement something, ask the supervisor on:
 - whether this "something" is necessary,
 and if yes,
 - whether the way you chose is ok.

2) Problems with LEDA may be solved via:
 - consulting source+execution of previously done (mini-)projects
 and
 - asking Haggai.David@ecitele.com or LEDA authors (if needed much,
   and very politely).

** Problem instances and examples:

Several relevant examples (e.g., a graph, a TM with an input string)
must be available.

User must be given a possibility to change the chosen example and
to construct his own instance of the problem.

After any run, the current problem instance is suggested
as the default instance for the next run; desirably,
its change will be possible.

** Distinguishing

After each program step, the important parts of the picture are
distinguished by colors; different colors show different meanings.
Currently important points are shown in red (the special color).

** Current explanations:

After each program step, on the screen there must be relevant and
clear explanations of:

 - past step: what has happened currently (i.e., what we see), and

 - next step: what will happen next.

(divided by an empty line).

Besides, in the first line there can be the name of the current
phase of the algorithm, and in the last line the way of pushing
the program farther (all things divided by empty lines).

At each begin-of-phase and each end-of-phase there must be a stop
with a comment.

IMPORTANT: at the FIRST show of the program to the supervisor,
	   there must be ALL explanations present at their places.
	   However, they can be in a preliminary form, say,
	   a couple of words each.

** Menus, help

  At each break, some menus must be available.
In particular, the interface help and the theoretic help must be
ALWAYS available (with return to the current execution).

** Possible break options:

 - to break after each small step;
   pressing Space to continue;

 - to break after each phase;
   pressing Space to continue;

 - to execute the entire algorithm.

** Break control.

  At any moment, the user must be able to change to another
break option. Change to the first option must be extremely easy,
for example, pressing Space. Then the execution breaks, and
it is possible to choose the desired option without time pressure.

** Delays.

  In the automatic option, each screen change must have a certain
minimal delay after the previous change, for example, 1-2 seconds.

Sometimes, it is desirable to have a control of the rate of steps.


---------------

Last modified on April 4, 2000.