9.3 Boîtes à outils

Il serait difficile de vouloir comparer MAGGLITE à toutes les boîtes à outils proposées aux développeurs pour l'implémentation d'applications interactives. Nous avons donc choisi de la positionner par rapport aux travaux de recherche les plus significatifs dans ce domaine.

9.3.1 Pour les IHM avancées

Bien que plus utilisées pour développer des interfaces «conventionnelles», des boîtes à outils telles que Garnet/Amulet [Myers et al.1997] et Subarctic [Hudson et Smith1996] ont introduit des fonctionnalités avancées pour simplifier la programmation des interfaces, comme par exemple la gestion automatique d'arrangement spatial basée sur les contraintes. Ils utilisent aussi des mécanismes plus complets, génériques et extensibles que les boîtes à outils traditionnelles pour décrire les entrées et les événements [Myers1990,Henry et al.1990]. Pourtant, même si elles introduisent quelques techniques post-WIMP, comme de la reconnaissance de gestes, ces boîtes à outils ne supportent qu'un ensemble limité de périphériques d'entrée et nécessitent des modifications importantes pour y inclure de nouveaux paradigmes d'interaction. En opposition, la palette de périphériques d'entrée et de techniques d'interaction que propose MAGGLITE est très étendue, mais aussi facilement extensible grâce à l'architecture des graphes d'interaction.

9.3.2 Post-WIMP

La plupart des boîtes à outils dites post-WIMP sont spécialisées dans un paradigme d'interaction. Satin [Hong et Landay2000], par exemple, étend Swing pour y inclure des techniques d'interaction avancées à base de gestes et de traits. Malheureusement, cette extension est basée sur des événements souris standard et ne permet pas l'utilisation de stylets sensibles à la pression et de traits haute résolution comme le fait MAGGLITE avec la gestion avancée des périphériques que fournit ICON.

Jazz [Bederson et al.2000] est une boîte à outils Java pour développer des interfaces zoomables. Son architecture graphique est aussi basée sur les graphes de scène, avec ce niveau très fin de granularité par rapport aux widgets monolithiques. Mais les auteurs ont reconsidéré leur approche, proposant comme évolution la boîte à outils Piccolo [Bederson et al.2004]. Toujours basée sur les graphes de scène, cette boîte à outils se veut un compromis entre une approche monolithique classique et les approches décomposées trop finement comme Jazz qui favorisent, selon les auteurs, une prolifération des classes pouvant nuire à la prise en main et la compréhension des mécanismes de la boîte à outils pour le programmeur. Ainsi, plutôt que de proposer une classe d'objet graphique pour chaque capacité envisagée, Piccolo propose une classe maîtresse regroupant toutes les fonctionnalités communes, que les développeurs peuvent instancier ou étendre.
Mais cette vision ne prend en compte que les problèmes dus à la réalisation d'objets graphiques, postulant que l'interaction sera définie dans un paradigme standard (les interactions de Piccolo sont décrites avec une architecture à événements standard encapsulée dans les nœuds du graphe de scène). Notre approche et notre vision de ce problème sont différentes. Elle conserve un niveau de granularité fin (pour permettre le contrôle externe de l'interaction), tout en proposant des mécanismes efficaces pour éviter la prolifération des classes d'objets graphiques: les dispositifs de comportement et les associations calques-Outils internes. Ces outils permettent de définir ou d'ajouter de nouvelles capacités graphiques et interactives aux objets de base sans avoir à programmer de nouvelles classes.

Ubit [Lecolinet2003] est aussi basée sur les graphes de scène, mais introduit la métaphore d'architecture «moléculaire»: des objets graphiques de base (atomes) sont assemblés pour construire des widgets (molécules). Ubit propose un langage de script, plus léger qu'un langage de programmation. Toutefois, les possibilités de prototypage sont limitées par le manque d'un éditeur graphique. Comme CPN2000/CPN Tools [Beaudouin-Lafon et Lassen2000] et MMM [Bier et Freeman1991], Ubit permet de concevoir des interfaces à pointeurs multiples, basées sur les périphériques de pointage standard, mais ne gère toutefois pas de périphériques et d'interactions avancées.

Plus généralement, les boîtes à outils graphiques post-WIMP gèrent efficacement un ensemble limité de périphériques d'entrées, mais par compatibilité: soit elles utilisent les mécanismes fournis par le système d'exploitation (qui n'est pas loin de supposer que «tout est souris ou clavier»), soit elles proposent une implémentation ad hoc pour des dispositifs particuliers limitant alors leur extensibilité (physique et logicielle).
De la même manière, elles se concentrent sur un style d'interaction particulier pour un type de tâches (le dessin, par exemple), un problème précis auquel elles répondent efficacement. Leur utilisation dans d'autres contextes, ou en association avec d'autres paradigmes, n'est pas impossible mais nécessite de gros efforts d'adaptation et de développement.

CPN2000/CPN Tools est un exemple flagrant d'application dont le développement à nécessité de partir de zéro pour supporter un modèle graphique et un modèle d'interaction originaux. En effet, une telle application ne peut reposer que sur une boîte à outils construite explicitement dans ce sens: permettre une intégration cohérente de différents types d'interactions avancées (outils transparents, interaction bimanuelle, menus circulaires, etc., voir figure 9.3) [Beaudouin-Lafon et Lassen2000].

Figure 9.3: CPN2000/CPN Tools intègre de nombreuses techniques d'interaction avancées.

Dans ce même article, Michel BAUDOUIN-LAFON considère ce problème sous deux angles:

1. étudier comment ces techniques peuvent êtres combinées entre elles ou avec des techniques standards. Cela requiert, selon lui, de définir de nouveaux modèles d'interaction comme l'interaction instrumentale utilisé dans ce cas [Beaudouin-Lafon2000].
2. proposer les outils logiciels basés sur un tel modèle (boîtes à outils) qui vont permettre aux développeur d'introduire des techniques d'interaction avancées «avec autant de flexibilité que de nouveaux widgets» dans une boîte à outils standard.

Il propose alors deux approches pour la réalisation d'une telle boîte à outils.

1. Développer la boîte à outils autour du modèle pour en préserver la généricité. Cette approche soulève alors la question de l'adéquation de ces outils pour la réalisation d'applications complètes et complexes.
2. Construire une application à grande échelle basée sur le modèle pour en isoler les points spécifiques à la réalisation ultérieure d'une boîte à outils.

C'est la deuxième solution qui a été choisie pour la réalisation de CPN2000 et la boîte à outils n'a, à notre connaissance, pas encore vu le jour.

Bien que SVALABARD, notre application de dessin pour la modélisation 3D créative, n'était pas voué comme CPN2000 à une diffusion à grande échelle, elle reste tout de même une réalisation complexe, plus qu'une simple application jouet. Et nous avons sensiblement rencontré les mêmes problèmes d'intégration et de développement. Nous avons par contre proposé une méthode de résolution à la frontière des deux propositions précédentes: le développement conjoint d'une boîte à outils et de l'application, l'une permettant l'évolution continuelle de l'autre^9.1. Nous avons alors pu conserver la généricité et la flexibilité de la boîte à outils, tout en prouvant son adéquation au développement d'applications complètes.

9.3.3 Entrées multiples

Figure 9.4: Les Phidgets [Greenberg et Fitchett2001] sont des composants physiques pouvant être mis en relation avec des composants logiques de l'interface.

Récemment, beaucoup de travaux ont étés menés sur des boîtes à outils pour les entrées multiples, tout spécialement dans les domaines de l'informatique ubiquitaire et de la réalité augmenté [Salber et al.1999,Greenberg et Fitchett2001,Ballagas et al.2003]. Ces approches tendent à proposer un accès unifié et flexible à beaucoup de périphériques d'entrée, mais elles reposent toutefois sur des modèles d'interaction minimalistes. La bibliothèque de « Phidgets/WidgetTaps» [Greenberg et Fitchett2001] permet de relier des «widgets» à leurs représentations physiques (voir figure 9.4). Le «Patch-Panel»  de la boîte à outils iStuff [Ballagas et al.2003] permet la même connexion entre périphérique et fonction. Le principe de «connexion dynamique» de ces outils est très similaire à MAGGLITE.

Mais dans ces approches, seule la connexion des périphériques est explicite, reposant sur un configurateur graphique. Pourtant, les interactions mises en œuvre dans la majorité des interfaces utilisateurs avancées ne peuvent pas se réduire à de simples mises en correspondance entre des boutons et des commandes. De fait, il est nécessaire d'utiliser des techniques d'interaction avancées pour pouvoir adapter efficacement n'importe quel périphérique à n'importe quelle tâche, ce que ces systèmes ne permettent que par implémentation dans un paradigme de programmation standard.

MAGGLITE va plus loin que les outils existants en offrant plus de pouvoir d'expression et de flexibilité de ce point de vue. Notre approche montre comment introduire plus de flexibilité et de contrôle en décrivant les entrées multiples avec les graphes d'interaction connectés à des graphes de scène à un niveau de granularité plus fin. De plus, le principe des interactions génériques permet d'adapter l'interaction aux entrées, mais aussi de proposer plusieurs styles d'interaction dans un même contexte.