2.6 Les outils de développement

Une application interactive a essentiellement besoin d'animer des formes géométriques à l'écran et de lire les données en provenance des dispositifs d'entrée. Le développement d'une application complète avec des librairies graphiques et des librairies d'entrée bas-niveau constitue cependant un travail titanesque. C'est pourquoi les outils de type Xlib ont rapidement cédé la place à des librairies de plus haut niveau comme la X Toolkit [McCormack and Asente, 1988]. Ces boîtes à outils graphiques ou boîtes à outils d'interaction proposent des jeux d'objets interactifs réutilisables (widgets) et un mécanisme de gestion des entrées basée sur la notion d'événements. La plupart du temps, l'implémentation de la partie interactive d'une application se résume alors à l'instanciation et au positionnement déclaratif de widgets, dont la manipulation est gérée automatiquement par des mécanismes d'aiguillage événementiel et des comportements prédéfinis au sein des widgets. Ces mécanismes seront décrits plus en détail par la suite.

Si les appréciations divergent quant à la facilité d'utilisation des boîtes à outils graphiques, tous les développeurs s'accordent à dire qu'elles sont difficiles à étendre (du moins, ceux qui s'y sont essayé) [Accot et al., 1998]. Cette difficulté est encore bien plus marquée du point de vue de l'interaction en entrée. En effet, fidèles au modèle de l'interaction standard, les boîtes à outils sont toutes câblées pour une utilisation exclusive et stéréotypée de la souris et du clavier (voir la section 1.1.1 pour une définition de l'interaction standard et la section 1.4.1 pour une discussion sur ses faiblesses). Les principales difficultés proviennent de ce qu'elles prennent en charge un ensemble limité et statique de types d'événements (souris et clavier), emploient des mécanismes d'aiguillage complexes dont l'architecture est floue, et entremêlent les aspects graphiques et comportementaux.

Depuis les premières boîtes à outils, de grands progrès ont été faits du point de vue graphique: des abstractions simplifient grandement la gestion de l'affichage et des effets visuels toujours plus sophistiqués sont pris en compte. Ces avancées ont une certaine influence sur l'interaction en entrée: le dessin structuré^2.2 permet d'implémenter plus facilement des techniques de manipulation directe [Beaudouin-Lafon et al., 1990] et la prise en charge d'effets visuels avancés tels que la transparence ou les déformations encouragent l'innovation dans les techniques d'interaction [Roussel, 2002]. Malgré tout, les paradigmes d'interaction Post-WIMP avancés nécessitent pour être décrits un remaniement non négligeable voire complet du modèle standard de gestion des entrées. C'est encore plus le cas lorsque l'on désire obtenir une certaine configurabilité de l'interaction. Or même les outils modernes comme Java Swing [Eckstein and Loy, 2002] reposent sur un modèle vieux de plusieurs décennies.

Dans cette section, nous donnons un large aperçu des boîtes à outils qui remettent en cause de façon significative le modèle d'entrée rigide conventionnel. Nous commençons par décrire les outils qui modélisent les paradigmes d'interaction standard de façon claire et extensible, et que nous nommons boîtes à outils WIMP avancées. Puis, nous décrivons les outils qui reposent sur des architectures dédiées à d'autres paradigmes d'interaction, et que nous nommons boîtes à outils Post-WIMP spécialisées.

2.6.1 Les boîtes à outils WIMP avancées

L'objectif des boîtes à outils WIMP avancées est de fournir de bons modèles et de bons outils permettant d'une part de faciliter la construction d'interfaces WIMP ou à manipulation directe conventionnelles, d'autre part de favoriser la description de techniques plus spécifiques ou moins conventionnelles. Comme preuve d'extensibilité, ces boîtes à outils prennent en charge un ensemble minimal de techniques d'interaction non-standard.

Les deux contributions les plus importantes dans ce domaine sont les boîtes à outils Surbactic [Hudson and Smith, 1996a] et Garnet/Amulet [Myers, 1990,Myers et al., 1997]. Nous les présentons ici, et détaillons les mécanismes qu'elles emploient pour la gestion des entrées. Nous analysons ensuite leurs apports respectifs, ainsi que leurs limites.

2.6.1.1 Subarctic Toolkit

Subarctic Toolkit [Hudson and Smith, 1996a] est une boîte à outils Java qui prend en charge des effets visuels avancés et les animations [Hudson and Stasko, 1993], et possède un moteur de contraintes^2.3 pour la gestion de l'organisation spatiale des widgets [Hudson and Smith, 1996b]. Le modèle d'entrée de cette boîte à outils a été introduit dans Artkit [Tyson R. et al., 1990], le prédécesseur de Subarctic développé en $C^{++}$ . L'objectif principal de ce modèle est de décrire les mécanismes d'aiguillage employés par les boîtes à outils traditionnelles de façon claire et extensible, pour pouvoir y intégrer ensuite de nouveaux mécanismes. En plus des interactions habituelles, Subarctic prend en charge trois paradigmes d'interaction non conventionnels, à savoir l'interaction gestuelle [Tyson R. et al., 1990], les champs de gravité^2.4 [Tyson R. et al., 1990,Hudson, 1990], et les lentilles sémantiques^2.5 [Hudson et al., 1997].

Dans toute boîte à outils, l'aiguillage des entrées consiste à distribuer les événements d'entrée aux objets appropriés dans l'arbre des widgets. La façon dont Subarctic distribue ces entrées est synthétisée sur la figure 2.23. Les rectangles représentent des objets (au sens programmation par objets) qui sont de type Politique d'Aiguillage ou Agent d'Aiguillage.

**Figure:** La gestion des entrées dans Subarctic [Hudson and Smith, 1996a].
$\begin{figure} \begin{center} \includegraphics[scale=0.6]{subarctic_input} \end{center} \end{figure}$

Le gestionnaire d'entrées de Subarctic peut être étendu afin de prendre en charge d'autres techniques d'interaction. De nouveaux agents ou politiques d'aiguillage peuvent être implémentés, éventuellement en dérivant un objet existant, puis insérés à l'endroit voulu dans la liste de priorité. Par exemple, une boîte de dialogue modale peut être implémentée par une politique hybride focus/positionnel qui transmet les événements de façon positionnelle aux enfants d'un widget qui détient le focus. L'interaction gestuelle et les champs de gravité ont tous deux été implémentés par des agents d'aiguillage de type focus.

Pour le premier, un agent Segmentation a été dérivé de l'agent Inking Drag, lui-même dérivé de l'agent Move Drag auquel il ajoutait un retour graphique de type trace. Cet agent transforme les événements souris en séries de segments pour les transmettre à un moteur de reconnaissance. Des types particuliers d'objets, les zones sensibles, ont été créés pour servir d'intermédiaires entre l'agent de segmentation et le widget qui possède le focus gestuel. Il s'agit de widgets invisibles qui encapsulent une zone gestuelle et le vocabulaire gestuel associé. Quant à la seconde technique, elle emploie un agent Snap qui étend l'agent Move Drag en ajoutant à son protocole d'entrée les événements snap_feedback et unsnap_feedback. Ces événements notifient le widget manipulé de son passage à proximité d'un site actif sémantiquement valide. Les sites actifs sont des points qui agissent comme des champs de gravité et qui sont déclarés par les widgets cibles. Il peut s'agir par exemple de cibles de connexion dans un éditeur de diagrammes.

2.6.1.2 Garnet/Amulet

L'objectif principal de la boîte à outils Garnet [Myers, 1990] et de son successeur Amulet [Myers et al., 1997] est de simplifier le développement d'applications hautement interactives en séparant du noyau applicatif les principaux aspects de l'interaction (principalement, la gestion de la présentation, des entrées et du annuler/refaire), et en fournissant des outils et des abstractions adaptés à chacun de ces aspects. Garnet est implémenté dans le langage CommonLisp, qu'il étend avec un modèle objet à prototypes et un paradigme de programmation par contraintes ; Amulet repose sur une infrastructure $C^{++}$ , qu'il instrumentalise de la même manière.

Le principe des interacteurs [Myers, 1990] introduit dans Garnet offre un modèle de haut-niveau pour la gestion des entrées. Ce modèle part de l'observation que dans les boîtes à outils traditionnelles, la programmation du comportement d'un widget, c'est-à-dire sa réaction aux événements souris et clavier, est pénible et répétitive: il est notamment fréquent de devoir décrire plusieurs fois les mêmes mécanismes. Dans Garnet, ces comportements sont décrits indépendamment des aspects graphiques, encapsulés dans des objets réutilisables appelés interacteurs. Suivant une taxonomie très semblable à celle de Foley [Foley et al., 1984], six types d'interacteurs sont fournis pour couvrir la plupart des comportements couramment observés dans les interfaces graphiques:

Pour rendre un objet graphique sensible aux événements d'entrée, le programmeur a simplement besoin d'instancier l'interacteur approprié avant de l'associer à l'objet. L'interacteur décrit la partie C du modèle MVC (voir section 2.2.2), et vient s'intercaler entre les événements de bas-niveau de type souris et clavier, qu'il interprète, et l'objet graphique, qu'il manipule à travers un protocole. Un seul interacteur peut opérer sur plusieurs objets graphiques, par exemple l'ensemble des objets manipulables dans une zone d'édition graphique. Certains objets graphiques peuvent également comporter plusieurs interacteurs: par exemple, une barre de défilement emploie un interacteur de type Menu pour ses deux boutons et un interacteur de type Move-Grow pour le pouce.

Un interacteur prend en charge tous les aspects de la technique d'interaction qu'il décrit, y compris les feedbacks transitoires comme la création et l'animation d'un objet fantôme dans une technique de cliquer-glisser. À titre d'exemple, l'interacteur Gesture produit un feedback de type trace et comprend un classificateur paramétrable qui interprète des séries d'événements souris en données textuelles ou en commandes. En outre, chaque interacteur connaît plusieurs variantes d'une même technique d'interaction, et peut être spécialisé par paramétrage. Voici, à titre d'exemple, les principaux paramètres partagés par tous les interacteurs:

Les paramètres autorisent la plupart du temps des types de valeurs sophistiqués comme des groupes d'événements: par exemple, la valeur :anykeyboard :except #\control-G affectée au paramètre :stop-event terminera l'interaction lorsqu'une touche est appuyée sauf s'il s'agit de la combinaison control+G. Des formules (ou contraintes) peuvent également être spécifiées en tant que valeur^2.6. À titre d'exemple, la technique d'interaction consistant à déplacer les objets du bouton gauche de la souris et à les redimensionner du bouton droit pourra être décrite ainsi [Myers, 1990]:

(Create-instance 'move-or-grower Move-Grow-Interactor
(:start-event '(:leftdown :rightdown)) ; Démarrer avec le bouton gauche ou droit.
(:start-where '(:element-of all-objs-aggregate)) ; Démarrer sur tout objet du
; conteneur graphique.
(:grow-p (formula (eq :rightdown (gvl :start-char)))) ; Redimensionner si l'événement
; initial est le bouton gauche,
; sinon déplacer.
(:window mywindow))

Les mécanismes d'aiguillage événementiel et les modes sont essentiellement gérés à travers le paramètre Active, qui associé à une formule permet l'activation ou la désactivation conditionnelle d'un interacteur, et à travers le paramètre Priority, qui permet de définir des niveaux de priorité lorsque plusieurs interacteurs sont candidats au même événement.

Tous les interacteurs sont écrits autour du même automate à états, reproduit sur la figure 2.24. Cet automate suppose que toute interaction peut être démarrée, arrêtée, terminée ou suspendue. Implémenter un nouvel interacteur revient à associer une action à chaque transition dans cet automate à états.

**Figure:** La machine à états décrivant le comportement générique d'un interacteur *Garnet*. Chaque transition est déclenchée par un événement, qui peut être dans certains cas spécifié par paramétrage, et déclenche une action, qui peut être décrite par programmation.
$\begin{figure} \begin{center} \includegraphics[scale=0.27]{garnet_states} \end{center} \end{figure}$

2.6.1.3 De Lapidary à Gamut

Une myriade d'outils visuels de construction d'interface ont été développés comme compléments à Garnet et Amulet, et la plupart d'entre eux offrent une interface graphique aux interacteurs. Dans Lapidary [Myers, 1990,Zanden and Myers, 1995], l'outil de construction d'interfaces livré avec Garnet, les interacteurs peuvent être paramétrés à travers des boîtes de dialogue. Le modèle à contraintes de Garnet permet ainsi d'associer la programmation textuelle déclarative à la programmation visuelle.

Une partie des comportements, notamment certains types de feedback, peut être directement décrite graphiquement dans Lapidary. Par exemple, un feedback de type case à cocher sera dessinée et liée par des contraintes à un élément de menu présent à l'écran, et ces contraintes sont généralisées automatiquement à toute cible potentielle de l'interaction. Ce type de technique combinant manipulation graphique et inférence est connue sous le nom de programmation par démonstration [Myers, 1992].

Les techniques de programmation par démonstration employées dans Lapidary seront reprises et étendues par la suite, dans Tourmaline [Werth and Myers, 1993], Marquise [Myers et al., 1993], Pursuit [Modugno, 1993], Silk [Landay and Myers, 1995], Topaz [Myers, 1998b], Turquoise, et enfin Gamut [McDaniel and Myers, 1998]. L'objectif de ce dernier est de construire des jeux interactifs complets uniquement par démonstration, c'est-à-dire en donnant des exemples des comportements désirés. Gamut se distingue des autres outils par un moteur d'inférence extrêmement sophistiqué, qui repose sur des techniques d'intelligence artificielle. Ces techniques sont toutefois très dépendantes du domaine.

2.6.1.4 Discussion sur les apports et les limites de Subarctic et Garnet/Amulet

Ces deux boîtes à outils WIMP avancées procèdent d'approches différentes, mais chacune apporte des éléments essentiels dans la modélisation de l'interaction en entrée. L'approche de Garnet est intéressante car elle se veut la plus fidèle possible au modèle MVC. Dans l'implémentation originale de ce modèle en SmallTalk [Krasner and Pope, 1988], la vue et le contrôleur étaient hautement dépendants l'un de l'autre, et le contrôleur devait être réimplémenté à chaque fois que la vue avait changé et vice-versa. Par la suite, la plupart des boîtes à outils s'inspirant de ce modèle, comme Andrew [Palay et al., 1988], Interviews [Linton et al., 1989] ou Swing [Fowler, 1999] ont regroupé la vue et le contrôleur dans un même objet nommé Vue, UI ou Look&Feel. Dans Garnet, un protocole de communication assure une certaine indépendance entre la vue et le contrôleur, même si cette indépendance est restreinte par le fait que chaque type d'interacteur définit son propre protocole. Le grand mérite du modèle de Subarctic est quant-à-lui d'avoir explicité les mécanismes d'aiguillage standard qui, dans les boîtes à outils traditionnelles comme Swing, étaient implémentés de façon obscure, et par conséquent très difficiles à comprendre et à étendre.

Si Subarctic n'a pas pour objectif de rendre l'interaction personnalisable, le paramétrage est un aspect important de Garnet, et garantit une certaine configurabilité de l'interaction en entrée. Associé au paradigme de programmation par contraintes, il constitue de plus un outil extrêmement puissant. En outre, il se prête relativement bien à un paradigme visuel de construction d'interfaces. Les paramètres des interacteurs de Garnet sont assez nombreux pour couvrir la plupart des techniques existantes. Cependant, lorsque le nombre de paramètres est excessif, le comportement d'un objet peut devenir difficile à comprendre et à configurer. C'est un peu le cas de certains interacteurs « à tout faire » de Garnet, comme le Menu ou le Move-Grow. Cela explique peut-être que les outils de visuels de Garnet/Amulet se soient orientés vers des techniques de programmation par démonstration.

Malheureusement, ces outils restent modérément ouverts à l'ensemble des paradigmes Post-WIMP. Subarctic prend en charge un ensemble très restreint de techniques post-WIMP et Garnet se limite à l'interaction gestuelle simple. Or la faiblesse majeure de l'approche de Garnet, en particulier, est le caractère très ad-hoc de son modèle d'entrée. Ses six types d'interacteurs se sont certes révélés suffisants dans les nombreux projets où ils ont été employés, mais ne sont pas adaptés à de nouveaux types d'entrée comme la parole [Myers et al., 1997], et n'encouragent pas la description de techniques d'interaction novatrices. Certains outils de base fournis pour le développement de nouveaux interacteurs sont également ad-hoc: par exemple, l'automate à états nécessite d'être étendu pour gérer des techniques comme le rollover ou l'ajustement^2.7.

Dans Subarctic, l'ajout de nouvelles techniques d'interaction, bien que facilité, n'est pas non plus gratuit. La plupart des nouveaux paradigmes d'interaction ne s'insèrent pas naturellement dans l'architecture existante, et nécessitent chacun une extension importante du modèle (Multimodal Subarctic, décrit dans la section 2.6.2, en est une). Cela reste vrai pour des modifications mineures: par exemple, dans Artkit c'est la position initiale du geste qui détermine sa cible, et la prise en compte d'autres zones actives comme le centre du rectangle englobant nécessiterait l'ajout d'un nouveau type de politique d'aiguillage [Tyson R. et al., 1990]. En outre, des problèmes de conflit qui interdisent par exemple l'abonnement simultané au clic et au double-clic nécessitent pour être résolus l'implémentation de nouveaux agents de médiation [Tyson R. et al., 1990].

Mais l'aspect dispositifs d'entrée reste le facteur le plus limitant pour l'accès aux paradigmes Post-WIMP: ni Subarctic ni Garnet ne gèrent les dispositifs multiples et leurs modèles restent conçus pour les dispositifs standard. Peut-être par souci de portabilité, Subarctic repose exclusivement sur les mécanismes d'AWT et Swing, auxquels il délègue une partie de son modèle: ainsi, les événements natifs AWT sont passés en paramètre dans tous les événements Subarctic, afin notamment que les widgets puissent accéder aux touches modificatrices. En outre, le fait que les événements « bas-niveau » traités par Subarctic et Garnet soient en réalité des événements génériques standard (produits par Swing pour le premier et par X pour le second) ne permet pas d'exploiter au mieux les capacités des dispositifs même standard.

2.6.2 Les boîtes à outils Post-WIMP spécialisées

Contrairement aux boîtes à outils WIMP avancées, les boîtes à outils Post-WIMP sont conçues dès le départ pour décrire des paradigmes d'interaction non-conventionnels. Bien que certaines d'entre elles soient extensibles, elles reposent en général sur un paradigme ou un modèle d'interaction spécifique.

L'approche de Multimodal Subarctic [Mankoff et al., 2000], tout en étant relativement générale, intègre dans le mécanisme événementiel la notion d'ambiguïté, qui est propre à des modalités particulières comme la parole ou le geste. Nous décrivons dans un premier temps cette boîte à outils qui constitue une contribution importante dans le domaine.

Les approches que nous décrivons par la suite sont plus spécifiques et concernent, dans l'ordre, l'interaction gestuelle, l'interaction multi-pointeurs, les outils semi-transparents, l'interaction 3D et les nouveaux paradigmes comme la sensibilité au contexte et les interfaces tangibles. Pour compléter, nous étudierons la question de l'accessibilité.

2.6.2.1 L'interaction ambiguë avec Multimodal Subarctic

Depuis Artkit, les efforts sur la boîte à outils Subarctic ont essentiellement porté sur l'aspect graphique [Hudson and Smith, 1996b]. Récemment cependant, Subarctic a été étendue pour prendre en compte de nouvelles modalités comme la parole et le geste [Mankoff et al., 2000]. Il s'agit d'une version non encore distribuée qui se distingue notablement de la version courante, et que nous baptiserons ici Multimodal Subarctic. Le modèle de gestion des entrées y a été entièrement remanié dans le but de gérer les ambiguïtés et les techniques de médiation, aspects essentiels de l'interaction multimodale. Nous exposons brièvement ses principes.

**Figure:** Une stratégie de médiation de type *n-best list* appliquée à une application de dictée vocale et une application de prototypage gestuel d'interfaces [Mankoff et al., 2000].
$\begin{figure} \begin{center} \includegraphics[scale=0.4]{subarctic_mediation} \end{center} \end{figure}$

Avec des modalités telles que la parole ou le geste, des ambiguïtés peuvent survenir lors de la conversion d'un événement bas-niveau en un événement plus haut-niveau. Par exemple, une trace pourra être interprétable comme un cercle ou comme un rectangle, avec des indices de confiance comparables. Dans les applications existantes, l'ambiguïté est la plupart du temps résolue automatiquement en optant pour la probabilité la plus forte. Les techniques les plus efficaces consistent cependant à faire intervenir l'utilisateur, par exemple en lui proposant une liste de choix (figure 2.25), ou en lui demandant de répéter. Ce sont ces techniques, appelées médiations, que Multimodal Subarctic se propose de prendre en charge.

Dans la situation d'ambiguïté décrite précédemment, l'événement cercle et l'événement rectangle sont tous deux générés par Multimodal Subarctic, puis propagés et interprétés comme n'importe quel événement. Les événements ambigus étant provisoires, la réversibilité est assurée à travers un modèle à événements hiérarchiques [Myers and Kosbie, 1996], où un graphe orienté relie événements-source et événements interprétés. La résolution d'une ambiguïté (qui se fait plus tard, voir plus bas) consistera à accepter certains événements et en rejeter d'autres. L'acceptation d'un événement impliquera l'acceptation de ses événements-source, ainsi que le rejet des événements avec lesquels il est en conflit. Le rejet d'un événement conduira quant-à-lui au rejet de toutes ses interprétations.

**Figure:** Événements hiérarchiques résultant de deux gestes à la souris [Mankoff et al., 2000].
$\begin{figure} \begin{center} \includegraphics[scale=0.4]{subarctic_hierarchical} \end{center} \end{figure}$

La figure 2.26 reproduit une situation de prototypage gestuel d'interfaces, où une forme mi-rectangle mi-cercle est tracée par l'utilisateur, suivie d'un geste de type texte (en haut de la figure). Cette interaction peut signifier soit l'ajout d'une case à cocher, soit l'ajout d'un bouton radio. Les événements hiérarchiques créés sont représentés par un graphe dont les n $\oe$ uds sont des événements de bas niveau (ellipses à contour noir), des événements synthétiques non ambigus (ellipses grisées) ou des événements synthétiques ambigus (ellipses à contour discontinu). Ici, l'acceptation de l'événement Checkbox induirait l'acceptation de l'événement Rect, puis le rejet de l'événement contradictoire Circle, impliquant à son tour le rejet de l'événement Radiobutton.

C'est le système de médiation qui se charge initialement d'accepter ou rejeter des événements. Il reçoit les événements ambigus après leur propagation, et les transmet successivement à ses médiateurs, des objets qui savent résoudre un type particulier d'ambiguïté. Un médiateur intéressé peut choisir de résoudre immédiatement l'ambiguïté (en général en interagissant avec l'utilisateur), ou bloquer cette ambiguïté pour la résoudre plus tard. Le système de médiation emploie de préférence des stratégies paresseuses, où la médiation est à la fois repoussée dans les couches d'abstraction supérieures et différée dans le temps, dans le but de:

2.6.2.2 L'interaction gestuelle

Le geste, cas particulier d'entrée ambiguë, est une modalité dominante dans les applications dites gestuelles et dans les systèmes à stylet. Si Multimodal Subarctic ainsi que Subarctic et Amulet proposent un ensemble minimal de techniques d'interaction gestuelle, certains outils plus conventionnels mais spécialisés offrent une prise en charge plus complète des diverses techniques gestuelles existantes. C'est le cas du système d'exploitation PenPoint [Carr, 1991] et des boîtes à outils Flatland [Mynatt et al., 1999] et Satin [Hong and Landay, 2000]. Nous présentons ici Satin, dont l'architecture en entrée est assez représentative tout en étant l'une des plus abouties aujourd'hui.

Satin [Hong and Landay, 2000] est une librairie Java qui couvre la plupart des techniques gestuelles existantes (voir figure 2.27) et les intègre en partie à Swing. Satin emploie son propre modèle graphique (avec prise en charge du dessin structuré, des couches, des vues multiples et des effets de zoom) et définit une architecture d'interaction gestuelle par-dessus les événements souris standard.

Les événements souris sont convertis en traces qui sont propagées dans la hiérarchie graphique de Satin comme des événements positionnels (à ceci près qu'une trace est uniquement transmise aux objets qui la contiennent entièrement) et traitées au sein de chaque objet par plusieurs types d'interpréteurs. Les interpréteurs gestuels comportent un moteur de reconnaissance qui à partir d'une trace produisent une liste de commandes reconnues, ordonnée par probabilité décroissante. Les interpréteurs d'encre comportent des algorithmes de traitement permettant de couper, joindre, simplifier des traces ou les transformer en segments.

Satin distingue également les interpréteurs discrets des interpréteurs progressifs qui peuvent effectuer des actions durant un geste, et introduit la notion de multi-interpréteurs, des interpréteurs composites munis d'une stratégie de choix. Cette dernière consiste en général à transmettre une trace aux interpréteurs-fils jusqu'à ce qu'elle soit consommée, mais peut également gérer des modes: le multi-interpréteur zoom sémantique, par exemple, active ou désactive des interpréteurs en fonction du niveau de zoom actuel.

Enfin, Satin ajoute à Swing un widget gestuel de type Marking Menu, et modifie dans son « Pen Look & Feel » certains widgets Swing dans le but de faciliter la manipulation au stylet (suppression du double-clic et élargissement de certains éléments).

**Figure:** *Denim*, une application de prototypage de sites web basée sur les paradigmes d'interaction gestuelle et d'interface zoomable, développée avec la boîte à outils *Satin* [Hong and Landay, 2000].
$\begin{figure} \begin{center} \includegraphics[scale=0.6]{denim} \end{center} \end{figure}$

2.6.2.3 L'interaction multi-pointeurs

Un petit nombre de prototypes boîtes à outils ont été proposées dans le but de décrire des techniques de travail collaboratif où plusieurs utilisateurs interagissent avec la même application sur le même poste de travail, ou pour décrire des techniques d'interaction bimanuelle. Il s'agit principalement de MMM [Bier and Freeman, 1991], Bimanual Whizz [Chatty, 1994], et MID [Hourcade and Bederson, 1999]. Ces trois outils ont en commun la prise en charge de dispositifs de pointage multiples.

MMM (Multi-Device Multi-User Multi-Editor). MMM [Bier and Freeman, 1991] est un prototype d'application interactive pouvant être contrôlée à la souris par plusieurs utilisateurs. Cette application consiste principalement en des menus et des hiérarchies d'éditeurs, qui sont des zones rectangulaires contenant des objets géométriques manipulables, des zones de textes ou encore d'autres éditeurs. Bien qu'il ne s'agisse pas à proprement parler d'une boîte à outils, MMM a été développé dans le but de valider à la fois un modèle d'interaction et une architecture logicielle adaptés à l'interaction multi-utilisateurs.

Le modèle d'interaction de MMM distingue tout d'abord utilisateurs et dispositifs: après s'être saisi d'une souris, chaque utilisateur s'enregistre en cliquant sur sa zone personnelle, un petit rectangle portant son nom (voir figure 2.28). En outre, les modes d'interaction sont dupliqués pour chaque utilisateur: chaque utilisateur possède sa propre sélection (qui représente aussi le focus clavier et le focus commande pour les menus), ses attributs par défaut (police de texte, couleur), une position de caret (curseur textuel), et bien évidemment une position de pointeur. Chacun de ces modes comporte un feedback ; certains comme les attributs par défaut sont visualisés dans la zone personnelle de l'utilisateur (figure 2.28), d'autres comme les pointeurs et les sélections sont affichés dans la couleur personnelle de l'utilisateur pour pouvoir être distingués. Ces derniers sont superposables graphiquement, y compris les sélections graphiques et textuelles. Les menus sont des objets partagés qui peuvent néanmoins être dupliqués par les utilisateurs pour être placés dans leur zone de travail. Enfin, MMM autorise l'interaction concurrente avec une granularité assez fine. Par exemple, un utilisateur peut déplacer un éditeur pendant que l'autre modifie l'un de ses objets.

**Figure:** La *zone personnelle* d'un utilisateur dans *MMM*, à travers laquelle il peut s'enregistrer et y visualiser une partie de ses modes d'interaction. À gauche, un rectangle illustre la couleur de remplissage par défaut. À droite, la zone personnelle indique la police courante. [Bier and Freeman, 1991]
$\begin{figure} \begin{center} \includegraphics[scale=0.4]{MMM_userhome} \end{center} \end{figure}$

Pour prendre en charge ces techniques, MMM repose sur un modèle de gestion des entrées spécifique. Les événements souris traditionnels ont été repris et étendus avec un champ identifiant le dispositif, un champ identifiant l'utilisateur, et un champ contenant l'état des autres dispositifs. Ces événements sont générés puis transmis à travers la hiérarchie des éditeurs jusqu'à être consommés, selon le mécanisme d'aiguillage classique. La différence est que chaque éditeur possède sa propre file d'événements qu'il interprète dans son propre fil d'exécution. À cette concurrence s'ajoutent des mécanismes de synchronisation qui permettent d'éviter les modifications incohérentes. D'abord, la conversion en coordonnées locales d'un événement positionnel lors de sa transmission à un éditeur n'est pas effectuée tant que la position de cet éditeur risque d'être en cours de modification, c'est-à-dire tant que le processus de son parent est actif (les événements clavier par contre, sont transmis sans attendre). Ensuite, l'événement est interprété en deux temps par l'éditeur: lorsqu'une modification de la sélection ou du focus positionnel est nécessaire, l'éditeur envoie une requête de mise à jour à un processus extérieur avant de replacer l'événement dans sa file pour une seconde phase de traitement. Enfin, le réaffichage est également effectué de manière asynchrone, selon un mécanisme analogue à celui de Java Swing [Eckstein and Loy, 2002].

Bimanual Whizz. Bimanual Whizz [Chatty, 1994] est le nom que nous donnons à l'extension bimanuelle de Whizz [Esteban, 1997]. Whizz est une boîte à outils qui décrit l'interaction par un modèle à flot de données, et est dotée d'un outil de programmation visuelle (voir la section 2.7.2 sur l'éditeur graphique Whizz'Ed). Whizz repose essentiellement la boîte à outils $X_{TV}$ [Beaudouin-Lafon et al., 1990], écrite pour le développement d'applications à manipulations directe avec

. $X_{TV}$ constitue une bonne infrastructure pour la gestion de dispositifs multiples car ses événements possèdent la notion de dispositifs-source.

Bimanual Whizz implémente un modèle d'interaction bimanuelle qui distingue trois paradigmes [Chatty, 1994]: l'interaction indépendante (les deux mains sont employées en série, par exemple pour sélectionner un outil avant de l'utiliser), l'interaction parallèle (les deux mains effectuent simultanément des tâches distinctes) et l'interaction combinée (les deux mains collaborent sur la même tâche). Son modèle d'interaction prend également en compte l'aspect asymétrique de l'interaction bimanuelle, en remplaçant pour la main non-dominante le point actif du pointeur par une zone circulaire.

Bimanual Whizz modifie peu le modèle à événements standard de $X_{TV}$ , d'abord pour préserver la compatibilité avec le modèle original, et ensuite parce que ce modèle possède déjà une notion de dispositifs qui permet de distinguer des événements souris de sources différentes. Dès lors, il est possible de résoudre certains problèmes de concurrence, et de décrire par exemple des boutons sensibles à n'importe quel événement Press mais filtrant ensuite tout événement autre que le Release du dispositif à l'origine du Press. Les interactions parallèles continues de type cliquer-glisser posent d'autres problèmes de concurrence qui sont résolus dans Bimanual Whizz en instanciant à chaque interaction un objet analogue à un interacteur de Garnet, qui prend en charge de façon autonome les transitions d'états, la manipulation et le feedback.

**Figure:** Utilisation de filtres dans *Bimanual Whizz* pour décrire des techniques d'interaction bimanuelle combinée. Sur le *schéma de gauche*, le pointeur droit est utilisé pour déplacer un segment ; lorsque le pointeur gauche clique sur une extrémité de ce segment, le flot est redirigé par le filtre *Switch* et le segment est déformé. Le *schéma de droite* décrit une technique de fusion temporelle, où un filtre spécialisé ferme l'application lorsqu'il reçoit deux événements dans un intervalle de temps spécifié. [Chatty, 1994]
$\begin{figure} \begin{center} \includegraphics[width=\textwidth]{bimanual_whizz2} \end{center} \end{figure}$

Pour les interactions combinées, Bimanual Whizz distingue deux types de fusion. Dans une combinaison de type mode+événement, le premier dispositif spécifie un mode d'interaction pour le second: par exemple, la manipulation de l'extrémité d'un segment est interprétée comme une translation sauf si l'autre extrémité est maintenue par un autre pointeur. Le modèle de Whizz permet d'introduire aisément ce type de mode par l'ajout d'un module dans le flot de données (voir figure 2.29, image de gauche). Dans une combinaison de type événement+événement, deux événements simultanés sont interprétés en un événement de plus haut niveau: par exemple, cliquer simultanément sur deux boutons peut fermer l'application. Ce type de fusion temporelle nécessite simplement dans Whizz la définition d'événements synthétiques supplémentaires et l'ajout d'un filtre dans le flot de données (voir figure 2.29, image de droite).

MID (Multiple Input Devices). MID [Hourcade and Bederson, 1999] est une librairie qui étend le modèle AWT de Java pour gérer des dispositifs de pointage multiples. Elle ne définit pas de nouveaux types d'événements, mais étend la définition d'un événement souris en y introduisant la notion de dispositif-source, selon une approche très similaire à Bimanual Whizz. Les applications Java existantes nécessitent peu de modifications pour être rendues compatibles avec MID, et seules les opérations consistant, pour les widgets, à s'enregistrer comme observateurs d'événements souris nécessitent d'être traduites. L'application peut ensuite être modifiée afin d'exploiter les identifiants de dispositifs. MID a servi à implémenter une application de dessin multi-utilisateurs nommée KidPad.

MID introduit dans l'AWT la notion de dispositifs de pointages multiples d'une manière relativement séduisante, sans modifier les principes fondamentaux de cette boîte à outils. Cependant, l'approche de MID est essentiellement pragmatique et de bas-niveau. En particulier, il n'aborde pas les problèmes de la gestion concurrente des événements positionnels que nous avons précédemment évoqués.

2.6.2.4 Les outils semi-transparents

Les boîtes à outils que nous décrivons ici constituent en quelque sorte des évolutions des boîtes à outils multi-pointeurs: elles gèrent l'interaction bimanuelle, mais y ajoutent de nouvelles techniques d'interaction basées sur la semi-transparence (voir section 1.3.3). Elles sont cependant peu représentées. En introduisant le premier modèle d'interaction basé sur ce paradigme, Bier et al [Bier et al., 1993] décrivent par la même occasion une extension de la boîte à outils MMM utilisée pour implémenter ces techniques. Nous la décrivons dans un premier temps. Par la suite, Kurtenbach et al. [Kurtenbach et al., 1997] ont étendu de façon intéressante ce modèle d'interaction bimanuelle avec leur application T3 (Tablets, Two-hands, Transparency), notamment en augmentant le nombre de degrés de contrôle (deux dispositifs positionnels sensibles à la rotation sont employés). Cependant, ils ne proposent pas de nouvelle boîte à outils. Enfin, une autre application-prototype, CPN2000 [Beaudouin-Lafon and Lassen, 2000], a été développée sur un modèle d'interaction similaire, et a permis d'introduire une nouvelle architecture de boîte à outils Post-WIMP. Nous décrivons également cette architecture.

MMM remanié. Le modèle d'interaction bimanuelle basé sur les outils semi-transparents a été décrit par Bier et al [Bier et al., 1993] dans le but de montrer comment l'emploi combiné de palettes flottantes semi-transparentes composées d'outils divers et de lentilles magiques peut faciliter des tâches de création, d'édition, ou de sélection d'objets graphiques. Ces interactions ont été implémentées avec la boîte à outils MMM (voir section 2.6.2), après des remaniements importants de son modèle d'affichage et de son modèle d'entrée.

Cette boîte à outils a été tout d'abord modifiée pour interpréter de façon spécifique les événements en provenance d'un dispositif trackball, afin qu'il puisse être employé par la main non-dominante pour déplacer et redimensionner les objets flottants et naviguer dans la fenêtre graphique. En outre, l'introduction d'outils flottants déstructure le modèle hiérachique des objets graphiques pour lequel le mécanisme d'aiguillage était conçu (voir figure 2.30). Les événements positionnels doivent ainsi remonter vers l'application après avoir été transmis aux objets graphiques et éventuellement modifiés par ceux-ci. Les deux types de modification sont l'annotation et le changement de position.

L'annotation a pour but de s'assurer qu'un objet ne recevra pas deux fois le même événement, et permet de transmettre des commandes. Une palette flottante, par exemple, ajoute une commande à l'événement et le retourne à l'application, qui se charge ensuite de passer cet événement aux objets qui se trouvent en-dessous et ainsi de suite. Les commandes sont concaténées pour permettre l'usage combiné de plusieurs palettes. Quant aux lentilles magiques, dont la plupart sont déformantes, elles modifient la position de chaque événement afin qu'il soit correctement dirigé vers l'objet qui apparaît sous sa position.

**Figure:** Les outils flottants ajoutent à la notion de hiérarchie celle de *couche graphique*: les trois outils représentés ici sont au même niveau dans la hiérarchie des widgets, bien qu'ils soient superposés et affichés dans un ordre déterminé (de droite à gauche dans l'arbre) [Bier et al., 1993].
$\begin{figure} \begin{center} \includegraphics[scale=0.4]{mmm_toolglass} \end{center} \end{figure}$

L'architecture CPN2000. CPN2000 [Beaudouin-Lafon and Lassen, 2000] est une application complète d'édition de réseaux de Pétri colorés, employant un modèle d'interaction instrumentale (voir section 2.5.2) mêlant efficacement manipulation directe et bimanuelle, palettes d'outils conventionnelles ou semi-transparentes, Marking Menus (voir section 1.3.2), guides magnétiques de type Snap-Dragging, et un modèle de documents basé sur une métaphore de classeurs. Ce modèle privilégie la redondance (il existe de multiples manières d'effectuer une tâche) et autorise par des quasi-modes l'accès simultané à plusieurs outils.

L'architecture de CPN2000 est de type MVC, avec une structure de document (M), une structure d'affichage (V) et une structure d'entrée (C) clairement séparés et faiblement couplés. La structure d'entrée est composée d'instruments d'interaction, qui gèrent des entrés physiques et possèdent une présentation. Les instruments consultent la structure graphique pour le picking mais opèrent directement sur les éléments (n $\oe$ uds) du document structuré avec un protocole simple à base de commandes.

Plusieurs instruments spécifiques à une classe particulière de n $\oe$ ud peuvent être combinés en un instrument générique. En outre, un instrument est lui-même un document, ce qui lui permet d'être manipulé par d'autres instruments (par exemple, les outils d'une palette peuvent être déplacés avec un instrument Move). Pour finir, l'activation et la désactivation de chaque instrument est géré par deux machines à états, un par dispositif.

2.6.2.5 L'interaction 3D

Par opposition aux scènes 3D statiques, les scènes animées en temps réel comportent des éléments (caméras, sources lumineuses, objets) dont les attributs (position, forme, couleur) sont variables au cours du temps. Dans le domaine de la 3D, l'interaction est considérée comme un cas particulier d'animation, où les attributs n'évoluent plus de façon autonome mais en fonction de valeurs en provenance des dispositifs d'entrée ou de dispositifs « virtuels » (la plupart du temps, des widgets 2D). Ces dispositifs sont vus comme des groupes de canaux produisant des valeurs de façon continue.

Ainsi, la majorité des nombreuses boîtes à outils 3D modernes décrivent l'interaction par des contraintes ou des flots de données liant des canaux à des attributs: citons par exemple UGA [Zeleznik et al., 1991], Inventor [Strauss and Carey, 1992], TBAG [Elliott et al., 1994], WorldToolkit [Sense8, 2003], Virtools [Virtools, 2001] ou des approches plus récentes comme OpenTracker [Reitmayr and Schmalstieg, 2001] et 3dml/inTml [Figueroa et al., 2002]. Un petit nombre d'opérateurs mathématiques simples (par exemple, des opérateurs permettant d'agir sur la vitesse ou l'accélération d'un objet plutôt que sur sa position) suffit à décrire la plupart des techniques de contrôle continu et statique tels qu'on les trouve dans les outils de navigation 3D ou les jeux. L'essentiel du comportement de ce type d'application est pris en charge par des outils de simulation mécanique, et les actions discrètes sont traitées comme de simples commandes (par exemple, l'appui d'un bouton lance l'animation d'un tir de missile).

En revanche, les applications de conception et d'édition où des objets sont manipulés ont des besoins plus proches de ceux des interfaces 2D, et les modes y jouent notamment un rôle important. Les modes et en particulier le multiplexage temporel et spatial sont habituellement traités dans les boîtes à outils 3D comme des remaniements explicites du graphe de contraintes ou des reconnexions dynamiques dans le flot de données. Les stratégies de picking employées pour les dispositifs 2D sont similaires à celles des boîtes à outils conventionnelles, alors que la sélection 3D nécessite des techniques plus avancées comme le Go-Go^2.8, techniques qui sont rarement prises en charge.

2.6.2.6 D'autres paradigmes en cours d'exploration

De nouvelles boîtes à outils continuent à être proposées pour prendre en charge, du moins en partie, de nouveaux paradigmes d'interaction encore en cours d'exploration. Nous décrivons brièvement le Context Toolkit utilisé pour construire des applications sensibles au contexte et les Phidgets, employés pour construire des interfaces tangibles.

Context Toolkit. Les applications sensibles au contexte (voir section 1.3.5) sont difficiles à construire, étant donné leur nature distribuée et l'emploi de dispositifs non-standard (capteurs) de nature très hétérogène. Le Context Toolkit [Salber et al., 1999] propose une architecture basée sur la notion de widgets de contexte, qui communiquent entre eux par TCP/IP et XML.

Les widgets de contexte maintiennent un état en fonction de données en provenance de générateurs, qui sont des abstractions des senseurs physiques. Ils se chargent également de notifier l'application de tout changement dans cet état. Par exemple, le widget Présence notifie de l'identité de chaque arrivant et son heure d'arrivée dans un lieu donné à partir de systèmes à badge ou d'analyse biométrique, et le widget Activité informe de tout changement dans le niveau d'activité en fonction de données en provenance de microphones ou de caméras vidéo.

Les widgets de contexte sont composables: par exemple, un widget Réunion peut détecter le début ou la fin d'une réunion en fonction du nombre de personnes dans la salle et du niveau d'activité. Les Serveurs sont des conteneurs plus importants de widgets, qui peuvent par exemple notifier l'application de chaque début et fin de réunion dans l'ensemble d'un immeuble.

Les Phidgets. Dans les interfaces tangibles (voir section 1.3.5), une même métaphore peut être mise en $\oe$ uvre par des techniques très diverses. Les interfaces basées sur la capture vidéo nécessitent avant tout des librairies qui prennent en charge l'acquisition, l'analyse et l'interprétation d'images en provenance de caméras ou web-cams. D'autres interfaces font usage de dispositifs spécialisés comme les capteurs 3D, d'autres encore reposent sur des dispositifs « maison ». Si les dispositifs exotiques du commerce sont souvent ardus à programmer, il est encore plus difficile de construire soi-même des dispositifs même simples.

L'objectif des Phidgets [Greenberg and Fitchett, 2001] est de fournir des composants physiques agençables prêts à l'emploi et aisément accessibles à travers une API unifiée. La partie physique des phidgets communique à travers le protocole USB, et la partie logicielle repose sur les standards COM et ActiveX de Microsoft. Le composant logiciel principal, le gestionnaire de phidgets, notifie l'application des connexions et déconnexions de phidgets et instancie un objet d'accès à chaque connexion. Ce dernier comporte une interface générique permettant notamment d'identifier le dispositif de façon unique, et une interface spécifique permettant de lire et/ou modifier son état, et être notifié de ses changements.

Un phidget peut également être relié et synchronisé à un widget: Par exemple, un slider peut être utilisé pour contrôler un potentiomètre motorisé, visualiser sa position, ou simuler son comportement lorsqu'il est absent. La librairie WidgetTap [Greenberg and Boyle, 2002] offre maintenant des outils d'inspection permettant d'attacher des phidgets à des widgets d'applications Windows conventionnelles (voir également la section 1.3.5 à ce sujet).

2.6.2.7 L'accessibilité

S'il n'existe pas à notre connaissance de boîte à outils prenant spécifiquement en charge des techniques d'interaction adaptées à des entrées appauvries, certaines boîtes à outils proposent des solutions simples pour améliorer l'accessibilité. La plupart d'entre elles offrent ainsi aux utilisateurs experts et ceux ne pouvant employer une souris des moyens d'interagir avec les widgets par l'intermédiaire du clavier.

L'API d'accessibilité de Swing [Sun, 2002] va plus loin en définissant un contrat entre l'interface et les technologies d'accessibilité extérieures, qui consiste principalement à attribuer à chaque widget un nom, une description et des moyens de naviguer dans sa hiérarchie. L'objectif de cette API est de fournir une « vue » textuelle des applications pour qu'elles puissent être perçues et contrôlées indépendamment de leur présentation graphique.

Aucune de ces techniques n'étant en mesure de garantir l'accessibilité effective d'une application, les guides d'accessibilité publiés à l'usage des développeurs en constituent un complément indispensable [Dunn, 2000,Schwerdtfeger, 2000]. Ces derniers conseillent par exemple de s'assurer que tout widget peut être traversé par le mécanisme de focus, et que des raccourcis sont définis pour tout élément de menu et fonction importante de l'application.

2.6.2.8 Discussion sur les apports et les limites des boîtes à outils spécialisées

Malgré leur spécialisation, les boîtes à outils Post-WIMP contribuent de façon importante à la compréhension de l'interaction en entrée. L'apport de Multimodal Subarctic, par exemple, est d'avoir rationalisé les techniques de médiation qui étaient déjà employées par certaines applications mais mal comprises. Cette boîte à outils introduit une architecture claire et propose des outils efficaces pour la gestion des entrées ambiguës, et est par conséquent bien adaptée au paradigme de l'interaction multimodale. Un autre apport de ce modèle est d'avoir explicité un aspect à notre avis important de l'interaction en entrée, à savoir l'existence de niveaux d'abstraction définis par des chaînes de traitements successifs. Cette notion n'apparaissait que de façon implicite dans Subarctic où chaque agent recevait les mêmes événements bas-niveau. Ces chaînes de traitement deviennent réellement explicites dans le modèle à flot de données de la boîte à outils Whizz et son extension à l'interaction bimanuelle. L'architecture de CPN2000 offre quant-à-elle une base solide aux techniques de type instrumental et décrit une implémentation efficace du modèle MVC.

Les boîtes à outils spécialisées sont plus ouvertes aux entrées que les boîtes à outils WIMP, mais chacune d'entre elles comporte ses limites. Bien que Multimodal Subarctic ait ajouté des modalités (parole, geste et contexte) à Subarctic, sa prise en charge des dispositifs non-standard reste limitée, et le clavier et la souris continuent à y jouer un rôle prépondérant. Comme dans Satin, l'interaction gestuelle repose exclusivement sur les événements souris conventionnels. Les boîtes à outils multi-pointeurs et de semi-transparence exploitent efficacement des entrées positionnelles multiples, mais de façon ad-hoc et avec des dispositifs de type spécifique: MMM décrit des techniques adaptées à l'interaction multi-utilisateurs avec la souris et sa version bimanuelle gère un trackball et une souris de manière câblée. Bimanual Whizz ne reconnaît que les souris, bien qu'il les gère de façon très extensible.

Les boîtes à outils 3D sont celles qui savent le mieux exploiter les entrées enrichies. Leurs modèles à canaux permettent d'obtenir, avec peu d'abstractions, une certaine indépendance par rapport aux entrées, que certains outils comme WorldToolkit exploitent au maximum en prenant en charge un grand nombre de dispositifs. Ces modèles autorisent en outre une grande flexibilité dans la description d'interactions et se prêtent bien à la programmation visuelle (voir plus loin, section 2.7). Cependant, leur pouvoir d'expression se limite au contrôle d'attributs d'objets 3D, et ces outils ne sont pas adaptés à la complexité de l'interaction 2D. Bien qu'il prenne en charge moins de dispositifs non-standard, Bimanual Whizz tire avantage du même type de modèle à flot de données pour décrire certaines techniques d'interaction 2D Post-WIMP.

Aucun de ces outils, y compris les plus ouverts en entrée, n'a été prévu pour l'accessibilité. Les recherches actives dans ce domaine se posent généralement pour objectif de définir des architectures applicatives où l'on puisse greffer des modalités de sortie et d'entrée alternatives, ce qui suppose tout d'abord de rendre le modèle de l'application (ou la structure du document, pour les navigateurs Web) explicite. Si les implémentations incomplètes du modèle MVC comme celui de Swing autorisent dans une certaine mesure la substitution des présentations (utiliser une modalité sonore au lieu de visuelle, par exemple), elles n'externalisent pas suffisament le contrôle pour être exploitables du point de vue des entrées.

L'introduction de l'API d'accessibilité a néanmoins fait de Swing une boîte à outils considérée comme l'une des plus avancées dans le domaine, car l'on considère actuellement qu'une application est accessible dès lors qu'elle est compatible avec les technologies d'accessibilité existantes comme les « lecteurs d'écran ». Malgré tout, une réelle accessibilité exige des applications qu'elles proposent des techniques d'interaction adaptées à la fois au handicap et à la tâche. Or l'accessibilité des applications repose toujours sur des outils extérieurs, et nous ne connaissons à ce jour aucune boîte à outils capable d'aider le développeur à construire des applications directement accessibles.

2.6.3 Conclusion

Alors que chaque boîte à outils tente de proposer un modèle graphique le plus générique possible, chacune d'entre elles emploie un modèle d'entrée ad-hoc, qui convient à « ce que l'on veut faire ». Certaines boîtes à outils tentent certes de proposer des mécanismes généraux, mais sans réellement y parvenir. Ainsi, si les techniques gestuelles simples se décrivent bien dans les boîtes à outils WIMP avancées, la plupart des autres paradigmes nécessitent des changements incrémentaux importants. Le fait que nombreuses de ces extensions fassent l'objet de publications complètes est assez révélateur.

Cette grande hétérogénéité dans les boîtes à outils est naturelle. Tout d'abord, les paradigmes Post-WIMP sont très variés et leur unification pose un problème évident de complexité. Même si des applications comme CPN2000 parviennent à composer des techniques multiples, certaines publications font état de la complexité de combiner deux paradigmes comme l'interaction gestuelle et coopérative [Hong and Landay, 2000]. En outre, un développeur d'outils se fixe en général pour objectif soit de prendre en charge les techniques propres à un paradigme d'interaction dans lequel il est expert (interfaces conventionnelles pour Garnet, interfaces gestuelles pour Satin), soit de prendre en charge un nouveau modèle d'interaction à des fins de démonstration (MMM remanié).

Les boîtes à outils Post-WIMP n'en permettent pas moins de construire des applications bien plus contrôlables dans le sens où elle prennent en charge des techniques d'interaction avancées. Cette contrôlabilité est néanmoins limitée par le fait que ces techniques s'appuient soit sur des dispositifs conventionnels (boîtes à outils gestuelles), soit sur un ensemble fixe de dispositifs qu'elles exploitent de façon efficace mais rigide (boîtes à outils multi-pointeurs). La version étendue de MMM, par exemple, gère de façon très spécifique le trackball d'une part, et les pointeurs conventionnels d'autre part.

Seules les boîtes à outils 3D parviennent à obtenir une certaine indépendance par rapport aux entrées en permettant de connecter librement des dimensions physiques multiples à des attributs d'objets 3D. Et bien qu'elles soient loin de balayer l'espace des dispositifs non conventionnels existants, certaines d'entre elles prennent en charge des dispositifs 3D nombreux et divers. Elles exploitent cependant un paradigme Post-WIMP spécifique (le contrôle parallèle et direct) en ignorant presque tout des techniques avancées du domaine de la 2D (outils transparents, gestes, reconnaissance vocale, etc).

Aucune boîte à outils WIMP avancée ou Post-WIMP ne prend en charge l'accessibilité, c'est-à-dire l'interaction avec des entrées appauvries, autre que par des moyens standard (raccourcis clavier). La plupart offrent une certaine configurabilité orientée-programmeur dans la mesure où elles sont un peu plus extensibles et mieux construites que les boîtes à outils traditionnelles. Cependant, la grande majorité ne permet pas de configurer l'interaction sans programmation. Les exceptions sont Garnet/Amulet, qui permet de paramétrer les interacteurs, et les outils 3D qui offrent parfois un éditeur interactif, approche dont s'inspire également Whizz'Ed dans la 2D. Les éditeurs visuels d'interaction connus seront décrits de façon plus générale et détaillée dans la section suivante.