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].
Dans ce même article, Michel BAUDOUIN-LAFON considère ce problème sous deux angles:
Il propose alors deux approches pour la réalisation d'une telle boîte à outils.
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'autre9.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.
|
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.
stuf