Les éditeurs graphiques d'interaction permettent de construire ou de modifier des applications interactives ou des parties d'applications interactives par manipulation, assemblage, et connexion de blocs élémentaires.
Les outils de construction d'interfaces de type Visual
Basic [Frantz, 2000] ou Visual 
[Chapman, 2003] ne permettent
de décrire que la partie présentation des interfaces graphiques, et ne
seront pas évoqués ici. Parmi les outils permettant de spécifier le
comportement des interfaces, nous distinguons deux catégories: les
éditeurs de simulations interactives 2D qui permettent de spécifier
simultanément la présentation et le comportement d'applications interactives
2D, et les éditeurs de comportement 3D qui sont destinés à la
description de comportements d'applications 3D.
Chaque éditeur possède un style de programmation visuelle qui lui est propre, selon qu'il met l'accent sur l'aspect flot de données, flot de contrôle ou encore la programmation par contraintes. Certaines de ces approches sont communes aux éditeurs 2D et 3D. Nous les décrivons dans un premier temps. Puis, nous présentons les deux catégories d'éditeurs, en décrivant les principaux outils existants puis en analysant leurs avantages et leurs inconvénients.
Les éditeurs graphiques de comportements emploient des objets graphiques interconnectés assimilables à des graphes. La sémantique de ces graphes diffère selon l'approche de programmation visuelle utilisée:
Les éditeurs de simulations interactives emploient des langages visuels où certaines primitives graphiques sont manipulables à l'exécution, ce qui permet de décrire simultanément la présentation et le comportement d'interfaces graphiques. Ils peuvent être employés pour décrire le comportement de widgets mais également la façon dont ils sont contrôlés par des événements de bas-niveau.
La plupart de ces éditeurs emploient des paradigmes de programmation par contraintes, d'autres ont une approche flot de données, d'autres encore ont une approche mixte. Dans cette section, nous décrivons ces trois types d'éditeurs.
Thinglab [Borning, 1979] est l'un des premiers systèmes à employer des techniques de programmation visuelle pour décrire des comportements interactifs. Implémenté dans le langage SmallTalk, Thinglab repose sur la PPC tout en restant volontairement très proche des concepts de la programmation orientée objet : classes, objets, méthodes, hiérarchie d'héritage et hiérarchie compositionnelle. Les objets prédéfinis de ThingLab, pour la plupart des objets géométriques simples, consistent en des structures d'objets liés par des contraintes, et possédant une représentation graphique manipulable. De nouvelles classes d'objets peuvent être construites par composition, en assemblant graphiquement plusieurs objets existants et en spécifiant des contraintes supplémentaires.
Une fenêtre de ThingLab est représentée sur la figure 2.31. La partie supérieure de la fenêtre contient l'explorateur d'objets. Les classes de ThingLab sont listées dans le premier panneau, à gauche. Le second panneau permet d'afficher l'objet courant sous différentes formes (graphique, structurelle ou valeurs), le troisième permet d'appeler ses méthodes, et le dernier contient les arguments de ces méthodes. Une partie importante de l'interaction (instanciation et composition d'objets, définition des contraintes) s'effectue par appel de ces méthodes. La partie inférieure de la fenêtre contient la représentation graphique manipulable de l'objet courant.
À gauche de la zone inférieure, un opérateur d'addition a été construit par composition d'objets élémentaires. Ces objets élémentaires sont le point numérique (point géométrique possédant une valeur numérique interne) et la piste numérique (association d'un point numérique et d'un segment), ainsi qu'un cadre permettant d'afficher un symbole. L'opérateur est construit en composant trois pistes numériques et un cadre, et en spécifiant les contraintes géométriques et numériques qui les lient. Une piste numérique peut être affichée et rendue éditable en lui associant un champ de saisie. À droite, un convertisseur de températures a été construit par assemblage de ces objets. Les zones de saisie, fixées par des ancres, sont considérées comme des constantes par le solveur.
La figure 2.32 illustre deux autres exemples construits avec ThingLab. L'exemple de gauche est un document comportant quatre nombres visualisés sous deux formes : une forme textuelle et une forme graphique. Ces deux vues sont manipulables et synchronisées. L'exemple de droite est une fenêtre découpée en zones redimensionnables, construit en composant puis en contraignant des rectangles.
Thinglab a eu un grand impact en tant que système de simulation interactive à visée pédagogique. D'autres outils ont suivi ses traces avec succès, comme les applications d'enseignement de la géométrie Cabri Géomètre [Capponi and Laborde, 1991] ou Chamois [Bourit, 2000]. Avec Thinglab II, l'accent est davantage mis sur les applications interactives réelles [Maloney et al., 1989]. Mais bien que des optimisations algorithmiques aient été introduites, aucun exemple réellement nouveau n'a été décrit.
Fabrik [Ingalls et al., 1988] est un système similaire à Thinglab, qui a été davantage conçu pour la description d'interfaces graphiques. Fabrik est basé sur un modèle de type data-flow compositionnel, mais qui autorise les connexions bidirectionnelles de type PPC. Certains de ses objets effectuent des calculs, d'autres sont interactifs et permettent de saisir des données (zone de texte, bouton) ou de les afficher (présentation de listes, images).
La figure 2.33 montre, à gauche, un convertisseur d'unités de température construit avec Fabrik. Celui-ci comporte deux blocs interactifs de type « barre de défilement » reliés par un bloc de calcul, défini à l'aide d'opérateurs atomiques dans la partie droite de la figure.
Les graphèmes constituent une autre particularité intéressante de Fabrik. Ce sont des blocs qui transforment des valeurs en objets géométriques élémentaires (lignes, rectangles) et qui permettent de décrire la présentation d'une interface. La figure 2.34 montre l'intérieur des blocs slider utilisés dans le convertisseur de la figure 2.33. Ce graphe comporte deux graphèmes de rectangles prenant les valeurs topleft et bottomright en entrée. Ils correspondent aux deux rectangles internes du slider, représenté à droite. La position du premier est fixe, et celle du second est calculée à partir des mouvements de la souris.
Les langages visuels à flots de données ont été employés avec succès dans des domaines tels que le traitement d'images ou le traitement du son. LabView [Santori, 1990], logiciel de traitement de données provenant d'appareils de mesure, en est un exemple. Des éditeurs de ce type existent pour décrire des comportements d'interfaces graphiques.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.3]{intercons2}
\end{center}
\end{figure}](img128.png) |
InterCONS [Smith, 1988] est l'un de ces systèmes. Il emploie primitives graphiques appelées outils, qui possèdent des connecteurs en entrée et en sortie de type entier. Ces blocs sont des éléments interactifs ou des opérateurs simples.
La figure 2.35 montre, à gauche, une technique de défilement construite avec InterCONS. Une barre de défilement simple et deux boutons ont été connectés à une vue pour contrôler son défilement horizontal. InterCONS permet de masquer les objets comportementaux afin de ne laisser apparaître que les éléments interactifs, puis de réorganiser visuellement ces derniers: au centre de la figure 2.35, la construction a été complétée avec un contrôle vertical avant d'être visuellement remaniée. À droite de la figure est représentée une autre application, une calculatrice, construite avec InterCONS.
Whizz'Ed [Esteban et al., 1995,Esteban, 1997] est un langage visuel dédié à la construction d'interfaces à manipulation directe, qui emploie un paradigme de data-flow compositionnel. Contrairement aux éditeurs vus précédemment, la présentation de l'interface graphique est dissociée du langage visuel. Whizz'Ed comporte néanmoins des briques qui affichent des primitives graphiques, similaires aux graphèmes de Fabrik. Parmi les autres types de briques disponibles, les tempos émettent régulièrement des valeurs de type booléen dans le but d'effectuer des animations, et les réactions émettent des événements utilisateur.
La figure 2.36 illustre une horloge construite avec Whizz'Ed: L'horloge, représentée à droite de la figure, possède une aiguille d'alarme, réglable par manipulation directe, qui sonne lorsqu'elle coïncide avec l'heure courante. Cette fonction, ainsi que l'apparence de l'horloge et sa mise à jour sont décrites par le programme visuel reproduit sur la figure.
La gestion des événements dans Whizz'Ed se fait par un mécanisme d'abonnement: une primitive graphique est rendue sensible à un type d'événement lorsqu'elle est reliée à un bloc de réaction. Ce lien est représenté sur la figure 2.36 par des pointillés. Les réactions étant dissociées des primitives graphiques, ce mécanisme permet de rendre explicite l'interprétation des événements. De plus, de nouveaux types d'événements synthétiques peuvent être ajoutés avant d'être associés aux primitives graphiques.
La plupart des éditeurs de simulations interactives présentent l'avantage de pouvoir spécifier simultanément l'apparence et du comportement d'une interface graphique. Cependant, le comportement d'une interface peut difficilement être spécifié indépendamment de sa présentation : lorsque celui-ci change, la présentation de l'interface change également. InterCONS résout en partie ce problème en permettant de masquer certains composants graphiques.
ThingLab et ses successeurs ont montré que la PPC était bien adaptée à la description de certains mécanismes d'interaction: les comportements géométriques des interfaces (positionnement, proportions, alignements de widgets), et le maintien des consistances entre les objets de l'application et les objets de l'interface graphique ou entre des vues multiples. Il semble toutefois que ce paradigme soit beaucoup moins employé pour décrire l'interaction en entrée en tant que telle. De plus, ces outils restent dédiés aux simulations interactives utilisées dans des buts pédagogiques, plutôt qu'à la construction d'interfaces utilisateur réelles. Premièrement, ce paradigme ne permet de décrire que des relations mathématiques simples entre des objets. Ensuite, un ensemble important de contraintes est difficile à résoudre et à spécifier (système sous-contraint ou sur-contraint).
Le paradigme à flot de données semble plus prometteur pour décrire les comportements complexes des applications interactives, en particulier les techniques d'interaction. En effet, ces comportements gagnent à être décrits de manière concrète, en termes de liens de causalité entre objets [Esteban et al., 1995]. Parmi les outils existants, Whizz'Ed est actuellement l'un des plus aboutis du point de vue comportement et gestion des entrées. Bien qu'il ait été principalement conçu pour construire des animations, il a servi à décrire une application iconique complète de type Macintosh [Esteban, 1997].
Les outils que nous avons passé en revue mettent globalement l'accent sur la
construction de comportements « autonomes », qui mettent en 
uvre des
animations ou des calculs complexes. Certains exemples comme la calculatrice
montrent qu'il est possible de créer des applications complètes, et non
seulement leur partie interface. Ces applications-jouets montrent qu'il est
possible de construire avec une fine granularité des composants interactifs
relativement complexes.
Malheureusement, l'accent sur les comportements semble se faire au détriment de
l'interaction: dans tous les exemples mis en uvre, l'interactivité et la
contrôlabilité des applications est relativement pauvre. Si les modèles de type
data-flow sont naturellement adaptés à l'interaction concurrente, les outils
actuels, de par leur vision des entrées, ne permettent pas une interaction
riche avec des dispositifs multiples: les entrées se limitent aux événements
standards. En outre, une grande partie de la gestion des entrées est implicite
et non configurable.
Whizz'Ed, dédié aux applications hautement interactives, semble le plus avancé dans ce domaine. S'il est adapté à la description des interfaces à manipulation directe, sa vision de l'interaction en entrée reste cependant relativement limitée. Seuls les événements souris classiques sont pris en compte dans la version originale de Whizz, bien que son extension à l'interaction bimanuelle soit également capable d'exploiter les pointeurs multiples de façon très efficace (voir la section 2.6.2 sur cette extension). Mais le mécanisme d'abonnement de Whizz ne permet pas, sans programmation, de gérer de nouveaux types d'événements provenant de dispositifs concrets. En outre, certains mécanismes de gestion des entrées restent implicites, tels que le picking.
Certains outils comme Maya RTA [Alias, 2001], Blender [Roosendaal and Wartmann, 2003] et Virtools Dev [Virtools, 2001] permettent de créer des applications 3D hautement interactives en construisant des comportements par manipulation directe. L'objectif de ces éditeurs est de permettre aux artistes de rendre leurs créations vivantes et interactives sans nécessité de programmation.
Les éditeurs de comportements 3D sont essentiellement basés sur les paradigmes d'association d'actions (mapping) ou de flot de données. Certaines approches plus expérimentales décrivent également des éditeurs visuels hybrides données/contrôle. Nous décrivons ces trois types d'éditeurs.
Maya RTA (Maya Real-Time Author) [Alias, 2001] permet de construire des applications 3D interactives dans le format Shockwave 3D, en connectant des senseurs et des actions (figure 2.37). Les senseurs réagissent de façon binaire à des propriétés de la scène (collision, distance entre objets) ou des dispositifs d'entrée (touche du clavier, bouton de la souris). Connectées aux senseurs, les actions déclenchent des commandes de haut niveau (démarrer une animation, jouer un son, changer de caméra). Un senseur peut également déclencher plusieurs actions en parallèle ou en séquence. L'éditeur de Maya emploie un modèle événementiel binaire très simple, qui ne permet de décrire que des relations directes (mappings) entre des contrôleurs à deux états et des actions.
La fenêtre interactive de Blender [Roosendaal and Wartmann, 2003] emploie un modèle légèrement plus sophistiqué à base de briques logiques. Les briques logiques comprennent les senseurs et les actuateurs (l'équivalent des actions de Maya RTA), ainsi qu'un troisième type de brique, les contrôleurs. Ces derniers comprennent les opérateurs logiques et les scripts Python. Ils s'insèrent entre les senseurs et les actuateurs, et permettent de décrire des conditions plus complexes pour les déclenchements d'actions. Tout comme l'éditeur de Maya, les briques logiques de Blender sont essentiellement basées sur des associations d'actions où les événements sont binaires. L'accès à des données comme les coordonnées de la souris est possible, mais nécessite l'écriture de scripts.
Un grand nombre d'outils de construction d'applications interactives 3D reposent sur des modèles à flot de données (voir section 2.6.2). Ce paradigme se prêtant bien à une programmation visuelle, certains d'entre eux proposent en complément un éditeur interactif. C'est le cas par exemple de WorldUp [Sense8, 2003], Cult3D Designer [Cycore, 2003] ou Virtools Dev [Virtools, 2001].
Le modèle à base de flots de données de l'éditeur de Virtools Dev
[Virtools, 2001] est parmi les plus sophistiqués sur le marché. Virtools
comporte un grand nombre de scripts comportementaux prédéfinis, graphiquement
représentés par des blocs de construction. Associé à un objet 3D, un
script comportemental permet par exemple d'animer ou de contraindre ses
mouvements. Tout comme les briques logiques, chaque bloc comprend des entrées
et des sorties d'activation (contrôle), mais peut également traiter des données
typées à travers des paramètres d'entrée et paramètres de sortie.
Les blocs peuvent être librement interconnectés à travers leurs entrées/sorties
et leurs paramètres pour décrire des comportements complexes. Les blocs
« contrôleur » (souris, clavier, joystick) permettent d'ajouter de
l'interaction. Les blocs sont composables, et de nouveaux blocs atomiques
peuvent être définis sous forme de scripts en ou de DLLs.
La figure 2.38 montre un jeu d'action programmé avec Virtools. La fenêtre de jeu est visible dans la partie supérieure gauche de la fenêtre, la structure de la scène apparaît dans la partie supérieure droite, et une partie du script décrivant le contrôle du vaisseau est visualisée en bas. Ce script emploie quatre blocs Key Event (gauche, droite, bas, haut) dont deux sont visibles ici. Chacun de ces blocs est connecté à un bloc Variate Value qui, à partir des paramètres de déplacement du vaisseau (vitesse, accélération, direction), émet des messages vers la partie inférieure du script qui se charge de calculer puis d'appliquer les transformations géométriques sur l'objet.
VRED [Jacob et al., 1999] est un éditeur d'interaction expérimental qui s'appuie sur un modèle mixte à flot de données et à flot de contrôle pour décrire les aspects à la fois continus et discrets de l'interaction. Son objectif est d'incorporer les deux aspects dans le même langage visuel dans le but de décrire facilement des techniques « Non-WIMP ». Il a été principalement employé pour spécifier des techniques d'interaction simples de réalité virtuelle.
VRED se compose d'un éditeur de flot de données pour décrire des relations entre des grandeurs continues, et d'un éditeur de diagrammes de transition d'états (voir section 2.3.1) pour décrire des modes. Chaque mode active des liens et en désactive d'autres dans le flot de données.
La figure 2.39 illustre une technique simple de manipulation d'objets dans une application de réalité virtuelle, où une main dont la position est captée par un Polhemus déplace des objets lorsqu'un bouton est maintenu enfoncé (le picking n'est pas représenté). Dans le flot de données (en haut), les ellipses représentent des valeurs continues (avec en-dessous leur type) et les rectangles des transformations (avec en-dessous leurs conditions d'activation). La position fournie par le Polhemus est liée à celle d'un curseur, elle-même liée à celle de l'objet. Le premier lien est statique et le le second est uniquement actif dans le mode DRAGGING. La prise en charge des événements discrets de type bouton est décrite par un diagramme de transition d'états (en bas), qui active le mode DRAGGING tant que le bouton est enfoncé.
Les modèles à base de senseurs et de canaux des éditeurs 3D offrent une vision détaillée des entrées, qui permet d'exploiter au mieux les dispositifs étendus. Ils sont par conséquent beaucoup plus ouverts aux dispositifs non-standards que les outils d'édition 2D, et permettent de décrire des interactions qui emploient des entrées extrêmement riches. Les modèles de connexion naïfs comme ceux de Maya RTA et de Blender offrent par contre un pouvoir d'expression assez faible, qui ne permet pas de décrire des comportements complexes.
Les éditeurs de type VirTools Dev ont comblé ce manque en exploitant le paradigme de data-flow. VirTools Dev, de par son grand pouvoir d'expression, a pu servir à développer des jeux vidéo commerciaux tels que Syberia [Microïds, 2002]. D'autres outils 3D emploient des éditeurs de comportements similaires [Sense8, 2003,Cycore, 2003]. Le principal inconvénient de ces outils est leur complexité d'utilisation qui requiert des compétences qui sont proches de celles du programmeur.
Les éditeurs 3D du commerce sont uniquement adaptés à la description d'interfaces 3D, où les attributs géométriques des objets d'une scène sont contrôlés plus ou moins directement par l'utilisateur. Si ce type d'interface est très stéréotypé, les éditeurs 3D sont peu adaptés au contrôle d'applications 2D, où les objets du domaine et les techniques d'interaction sont plus variés et souvent plus complexes.
VRED est une approche expérimentale qui constitue l'une des rares tentatives visant à réconcilier les aspects flot de données et les rassembler dans le même langage visuel. Cependant, il emploie deux notations bien différentes et oblige pour chaque aspect de l'interaction à opter pour un modèle continu ou à événements. Les difficultés liées à l'interprétation d'un flot de données dynamique ont en outre été évoquées par l'auteur lui-même, qui propose d'encapsuler un flot de données dans chaque état du diagramme de transition et d'étendre l'éditeur avec un paradigme d'interfaces zoomables. Outre les difficultés de lecture que cette nouvelle approche peut poser, cet éditeur n'a pas encore vu le jour.
Les éditeurs graphiques d'interaction constituent un pas en avant non négligeable vers des interfaces graphiques configurables en entrée. Malheureusement, il existe encore une trop grande séparation entre les éditeurs 2D qui sont puissants mais possèdent une vision événementielle stéréotypée des entrées, et les éditeurs 3D qui ont une vision générique et bas-niveau des dispositifs d'entrée mais ne permettent pas de décrire des techniques d'interaction complexes. En outre, les premiers (excepté Whizz'Ed) reposent en général sur des modèles à base de contraintes, ce qui les rend plus adaptés à la description de comportements géométriques qu'à des flux d'entrée.
Nous remarquons également que les éditeurs sont soit "orientés-édition", soit "orientés-modèle". La première approche consiste, comme Maya RTA, à construire un éditeur interactif destiné à l'utilisateur final employant des métaphores simples, mais reposant sur un modèle simpliste de l'interaction, avec un faible pouvoir d'expression. La seconde approche consiste, comme VRED, à bâtir un éditeur visuel par-dessus un modèle existant, en général puissant, mais sans se focaliser sur l'utilisabilité et sans prendre le temps d'implémenter les techniques d'interaction et de visualisation appropriées.
Pour finir, les outils d'édition 2D comme 3D semblent tout ignorer des techniques d'interaction avancées telles que l'interaction gestuelle, les outils transparents ou la reconnaissance vocale. Un outil de configuration de l'interaction en entrée gagnerait à s'inspirer des approches employées dans les deux domaines, tout en fournissant un support pour ces techniques d'interaction non standards.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{thinglab1}
\end{center}
\end{figure}](img124.png)
![\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{thinglab2}
\end{center}
\end{figure}](img125.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{fabrik1}
\end{center}
\end{figure}](img126.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{fabrik3}
\end{center}
\end{figure}](img127.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{whizzed}
\end{center}
\end{figure}](img129.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{maya_RTA}
\end{center}
\end{figure}](img130.png)
![\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{virtools}
\end{center}
\end{figure}](img131.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.4]{VRED3}
\end{center}
\end{figure}](img132.png)