La version 1 du programme 'voitures' propose une animation (le déplacement d'une voiture) qui n'a aucun lien fonctionnel avec l'activité du sujet (la réalisation d'une série d'additions). Cette animation est susceptible de rendre la tâche plus attrayante ou d'éveiller l'attention de l'utilisateur sur les événements qui vont suivre. Ces effets ne sont cependant ni garantis, ni importants. En outre, ils ont tendance à décroître si l'animation est utilisée systématiquement. L'abus d'animations purement décoratives peut même conduire à des effets négatifs, ntamment en attirant l'attention de l'utilisateur sur des éléments non pertinents de la tâche à accomplir.
Les versions suivantes utilisent l'animation comme moyen de feed-back, c'est-à-dire d'information sur la qualité de la réponse de l'utilisateur. Dans le version 2a, ce feed-back prend sa forme minimale: il précise à l'utilisateur si sa réponse est correcte ou erronée. Le feed-back positif est constitué par l'animation de la voiture, le feed-back négatif par l'explosion d'une bombe. L'utilisateur doit pouvoir déterminer si une animation constitue un feed-back positif ou négatif. Dans l'exemple de la bombe, la sémantique est explicitement négative. Par contre, il n'est pas clair que le déplacement de la voiture constitue un feed-back positif. Cette animation pourrait correspondre à un feed-back négatif par comparaison à une animation semblable mais plus rapide, ou illustrant un véhicule plus rutilant. La voiture ne se charge ici d'une valeur positive que par opposition à la bombe dont la valeur négative est explicite. Notez que certains utilisateurs pourraient commettre des erreurs uniquement pour le plaisir de voir la bombe exploser!
La discrimination entre les deux feed-back est renforcée par des sons qui sont respectivement connotés positivement et négativement. Toutefois, le support du son souffre de la même ambiguïté que l'image. Aussi, dans la version 2b, la sémantique du feed-back est explicitement décrite par une message de type 'Bonne réponse!". En cas d'erreur, le feed-back verbal précise la réponse attendue, information qui n'est pas présente dans le feed-back animé. En bref, l'information dans cette seconde version est plus riche et essentiellement véhiculée par les messages verbaux. L'animation n'y joue plus qu'un rôle décoratif.
La version 3 illustre une autre forme de feed-back pour laquelle l'animation semble plus pertinente. Elle consiste à informer l'utilisateur de sa position par rapport à un objectif. Dans cet exemple, l'objectif est illustré par la destination finale du véhicule (Mexico). Ce véhicule se déplace sur une route graduée. Il avance de deux pas lorsque l'élève répond correctement et recule d'une case lorsqu'il se trompe. Ce procédé est fortement utilisé dans les jeux, tantôt pour situer le joueur face à son objectif, tantôt pour lui indiquer l'évolution de certaines contraintes (par exemple, l'épuisement des batteries ou des réserves d'oxygène). Authorware gère automatiquement une animation correspondant à ce genre de feed-back: le petit cadran qui compte à rebours pour indiquer (si on le demande) les limites de temps imposées à l'utilisateur.
Dans la version 4, l'animation est naturellement utilisée pour étudier un mouvement, ici le fonctionnement d'un moteur de voiture. Dans certains cas, il est en effet préférable d'observer une animation représentant un mouvement plutôt que d'observer le mécanisme réel (ici observer un vrai moteur), par exemple lorsque le phénomène observé est trop rapide (moteur à explosion), trop lent (tectonique des plaques), trop petit (mécanismes d'une montre), trop grand (mouvement des planètes), caché (par exemple, se déroule à l'intérieur d'un tube) ou trop complexe. Dans ce dernier cas, l'animation permet d'illustrer le mouvement sur une vision partielle et/ou schématisée du phénomène. La simplification est une fonction très importante des représentations graphiques. Toutefois, l'atout majeur d'une animation interactive est le contrôle du phénomène, en particulier de sa vitesse (plus vite, moins vite, pas à pas), de sa taille (zoom in / zoom out) ou de son déroulement (marche avant / marche arrière). Dans le cas des simulations, l'utilisateur a généralement accès à d'autres paramètres, propres au phénomène étudié, qui influencent les effets observés. Ce contrôle n'est pas limité à l'animation de schémas sur ordinateur mais également au contrôle d'images réelles. Il faut cependant noter qu'un image ou une animation sur écran d'ordinateur offre certains inconvénients, tels que la perte de la notion d'échelle, la faible précision de certains écrans, la fatigue visuelle, le besoin d'interpréter certaines images pour y percevoir la troisième dimension, le coût de développement et de diffusion.
Le critère essentiel énoncé au point précédent concerne le contrôle de l'animation. Le contrôle d'un phénomène observé appartient à l'arsenal des procédés qui facilitent la compréhension. Parmi ces procédés, on trouve également la mise en relation de deux représentations d'un même phénomène. Dans la version 5, le déplacement d'une voiture est représenté d'une part de façon semi-concrète par le déplacement d'une figure le long d'un axe et, d'autre part, de façon abstraite, par un graphe espace-temps. L'animation de la voiture et l'élaboration du graphe sont réalisés en parallèle: le point le plus avancé du graphe correspond en permanence à la position de la voiture. De cette manière, l'utilisateur peut inférer le sens de la représentation abstraite à partir de sa compréhension de la représentation semi-concrète. Cette mise en relation résulte du synchronisme des deux animations. Nous avons en effet tendance à interpréter comme liés deux événements qui se produisent simultanément.