L’historique d’action

Nous nous sommes intéressés aux historiques d’actions car il s’agit d’un service utile pour l’exploration mais surtout parce qu’il s’agit en soi d’une structure : constitués de l’ensemble des actions réalisées par l’utilisateur, les historiques sont des regroupements d’éléments organisés séquentiellement. En tant que structure, il est important qu’ils puissent être supportés par des services qui satisfont les exigences que nous avons définies. Cette structure n’est pas construite par l’utilisateur, elle est définie par les actions qu’il réalise dans son activité de conception exploratoire, il s’agit donc d’une structure implicite.

Les historiques satisfont peu les exigences définies. Ils sont généralement masqués à l’utilisateur dans les éditeurs graphiques. Le seul moyen de savoir s’ils contiennent des actions annulables ou réutilisables est donné par le bouton représenté généralement par une flèche qui n’est plus grisé. En étant masqué, l’historique ne permet pas d’identifier quelles sont les actions qui le constituent (R1.4 identifier les ensembles), de rechercher ou de désigner une action particulière (R1.1 rechercher, R1.2 désigner), on ne peut accéder qu’à celle en tête de pile. En tant que structure implicite, on ne modifie pas volontairement l’ensemble (R1.3), c’est l’utilisation des commandes annuler et refaire ainsi que les actions réalisées dans l’espace de travail qui modifie la structure. Certains outils proposent cependant une visualisation simple de celui-ci (Figure 91). L’utilisateur peut alors être informé des actions passées et il peut rapidement revenir à un état précédent de sa conception en sélectionnant la dernière opération à restaurer, sans avoir à annuler toutes les actions suivantes une par une. Bien que cela augmente la capacité de désignation, cela ne permet toujours pas de désigner une action particulière sans avoir à annuler toutes les précédentes.

Par ailleurs, la modification de la structure n’est pas perceptible en raison des changements abrupts survenant lors de l’annulation d’une opération (R2.4 percevoir les conséquences). Le support à la conception exploratoire (R3) est limité en raison de la linéarité des historiques : il n’est pas possible de faire des comparaisons autres que temporelles, et seulement pour deux états juxtaposés.

Figure 91. L’historique de l’outil de dessin Paint.NET. Les actions sont visibles et sélectionnables.

2. Transitions d’états animées

L’utilisation des commandes annuler et refaire permettent de revenir à l’état précédant la réalisation d’une opération ou de revenir à des états suivants. Cette fonctionnalité peut être utile pour comparer deux états juxtaposés d’une conception, en répétant successivement les commandes annuler et refaire, l’utilisateur peut faire apparaitre les différences entre les deux états de la scène et l’évaluer (Terry & Mynatt, 2002a). Ce mode de comparaison a pour inconvénient d’être temporel et non spatial, l’utilisateur doit mémoriser les différences entre deux états pour pouvoir les comparer. Qui plus est, le changement est abrupt : il peut être difficile de visualiser les changements si la scène est dense (par exemple, dans une scène contenant un nombre important de trajectoires d’avions), si le changement diffère très peu ou s’il a lieu hors de l’espace visible. Les transitions d’états animées sont des moyens pouvant permettre aux utilisateurs de mieux percevoir le changement (R2.4)(Schlienger, Conversy, Chatty, Anquetil, & Mertz, 2007). Par exemple, Gliimpse (Dragicevic, Huot, & Chevalier, 2011) est un outil qui exploite les transitions animées dans un contexte d’édition textuelle afin d’aider à percevoir les modifications de texte entre des vues différentes. En modifiant du texte dans une vue d’édition différente de la vue de rendu (exemple : une page html, du code LaTex, une page de wiki), il n’est pas aisé de repérer ce qui a été modifié lors du basculement dans l’autre vue. Gliimpse permet, grâce à la transition animée, de suivre des éléments textuels d’une vue à l’autre, et ainsi de ne pas perdre le focus sur des éléments d’intérêts (Figure 92).

Les deux préoccupations que nous avions concernant la perception des changements étaient de pouvoir retrouver les objets concernés et de pouvoir percevoir les différences. Nous avons alors implémenté dans l’éditeur graphique un mécanisme de transition animées afin d’éviter les changements abrupts entre deux états d’une scène : tout changement de propriété est animé à chaque utilisation des commandes annuler et refaire. Par exemple, en cas d’une annulation d’un changement de position d’un objet, celui-ci se voit déplacé de sa position actuelle à sa position précédente (Figure 93). Ceci permet à l’utilisateur de suivre l’objet, et ainsi de savoir où se trouve son ancienne position, ce qui peut s’avérer difficile si le déplacement se fait instantanément ou s’il est hors du champ de vision. La Figure 94 montre l’état d’une scène comportant un grand nombre de trajectoires générées aléatoirement, avant et après annulation d’une opération de translation partielle d’une trajectoire. Un changement abrupt rend très difficile la perception des différences entre les deux scènes. Grâce à l’animation, l’utilisateur peut suivre les points modifiés jusqu’à leur position d’origine sans les perdre de vue.

Figure 93. Annulation d’une opération de translation d’un rectangle. Une transition animée permet de suivre son déplacement de sa position actuelle à sa position d’origine.

Dans le cas où l’objet modifié n’est pas présent dans l’espace visible de travail (suite à une opération de défilement par exemple), animer la modification n’est pas suffisant. Une autre alternative pour percevoir ces changements serait d’utiliser des signaux visuels. Des travaux de recherche ont été menés autour des alarmes visuelles dans les interfaces graphiques. Bien qu’appliqués plus particulièrement au domaine du contrôle aérien, Chatty, Bustico, & Athènes, (1999) présentent des signaux animés afin d’attirer l’attention de l’utilisateur sur des évènements survenant dans l’interface. (Baudisch, (2003) présente également des travaux utilisant les alarmes visuels dans des petites surfaces (smartphones). L’utilisation de tels signaux (flash en périphérie, cercles concentriques rétrécissants) permettent d’informer l’utilisateur de modifications ayant eu lieu hors de la scène visible et ainsi de trouver les objets qui ont été modifiés.

Les déplacements ne sont pas les seules propriétés animées. En fait, tout changement de propriété visuelle est sujet à une transition animée. Un changement d’épaisseur de contour, ou un redimensionnement dévoilera progressivement la nouvelle taille ou épaisseur. Un changement de couleur de fond ne sera pas non plus instantané : l’objet prendra progressivement la nouvelle couleur selon une interpolation entre celle d’origine et celle à atteindre. Sur un objet de type évènement d’agenda, changer la durée fera augmenter (ou réduire) sa longueur puisque cette propriété est visuellement représentée par la longueur de l’objet. Ainsi, l’utilisateur peut se rendre compte des différences sur l’objet avant et après modification.

Figure 94. La scène contient un entrelacement de trajectoires. L’utilisateur annule la dernière action : une translation de la trajectoire marquée par une flèche dans la vue de gauche. La vue de droite décrit la transition qui permet de repérer la trajectoire lorsqu’elle revient à sa position d’origine.

Les animations suivent le principe du « slow-in/slow-out » (Thomas & Johnston, 1981) : elles sont lentes au début, accélèrent progressivement et ralentissent à la fin. Cela rend l’animation plus réaliste et agréable à observer qu’une animation à vitesse constante (Kochanek & Bartels, 1984). Les animations sur les changements de propriétés peuvent améliorer la compréhension du système et faciliter le suivi des objets d’intérêts.