Nous verrons en particulier, dans la section 7.2 du chapitre suivant, l'intérêt des graphes de scène, modèle issu de la 3D et de plus en plus utilisé pour les boîtes à outils 2D. Mais bien que modulaires et flexibles pour l'utilisation ou la création d'objets graphiques, la réalisation de ce type d'architecture dans les boîtes à outils actuelles lie encore trop fortement la description de la partie graphique et de l'interaction, par encapsulation dans des widgets et dans une architecture à événements. Il est alors difficile de découpler ces deux aspects, ce qui ne favorise pas la flexibilité et l'évolution de la boîte à outils sur les deux tableaux.
Ainsi, pour introduire de nouvelles techniques d'interaction avancées ou en utiliser plusieurs dans une même application (comme SVALABARD), il est encore nécessaire de modifier plus ou moins en profondeur les abstractions et objets graphiques de la boîte à outils.
Basées sur une architecture à événements fortement liée aux données reçues des dispositifs standard, elles sont alors très difficile à étendre pour le support de périphériques et de techniques d'interaction avancées, de par l'encapsulation de l'interaction dans les widgets.
Ces approches ont permis d'étendre et d'améliorer notablement l'architecture standard basée sur les événements, en décrivant à plus haut niveau leur lien avec les widgets (les interacteurs de Garnet) ou en explicitant mieux les mécanismes pour leur aiguillage (les Dispatch policies et Dispatch agents de Subarctic). Mais elles restent encore relativement fermées aux techniques d'interaction avancées des interfaces post-WIMP, nécessitant encore un travail de fond et des changements importants pour insérer de nouveaux paradigmes d'interaction dans leurs architectures. Pour la gestion des entrées, elles étendent les mécanismes de AWT (pour Subarctic) ou de X (pour Garnet) et ignorent donc de fait les particularités des dispositifs d'entrée avancés ou leur multiplicité (pointeurs multiples, interaction bimanuelle, etc.).
Un cas particulier est celui de CPN2000/CPN Tools [Beaudouin-Lafon et Lassen2000], une application complète d'édition et de simulation de réseaux de Pétri colorés qui combine manipulation directe, Marking Menus, palettes d'outils semi-transparentes, etc. Bien que n'étant pas une boîte à outils, CPN2000 démontre la possibilité de faire cohabiter ces différentes techniques dans une architecture claire en utilisant un modèle d'interaction adapté (l'interaction instrumentale [Beaudouin-Lafon2000]).
À l'exception de certaines boîtes à outils 3D et leurs modèles différents de gestion des entrées (Virtools [Virtools SA2001], par exemple, utilise un modèle à canaux pour la connexion statique ou dynamique de nombreux dispositifs d'entrée), les boîtes à outils restent limitées dans l'exploitation des entrées enrichies, reposant souvent sur des architectures à événements traditionnelles. Même lorsqu'elles sont spécialisées dans un paradigme fortement lié aux entrées (comme les pointeurs multiples), les dispositifs sont exploités de façon ad hoc.
Du point de vue des outils pour le développement d'application post-WIMP, les solutions proposées ont pris le chemin contraire, en proposant des solutions adaptées à un cadre, un paradigme précis. Dès lors, construire une application qui tire partie de différentes techniques d'interaction avancées, tel que nous le voulions avec SVALABARD, nécessite de réaliser des assemblages plus ou moins cohérents de ces différents modèles (en écrivant une application basée sur plusieurs boîtes à outils) ou de tout redévelopper autour d'un modèle d'interaction particulier à l'application (comme dans CPN2000/CPN Tools).
Cette hétérogénéité n'est pas pour autant contestable, du fait de la complexité évidente à faire cohabiter des paradigmes parfois contradictoires. Toutefois, il nous semble que c'est surtout les modèles d'architecture logicielle proposés qui, bien qu'ils soient souvent très avancés et approfondis, sont figés par l'utilisation d'une architecture standard à événements. Cette association limite souvent l'emploi de dispositifs non-standard et nécessite des extensions trop complexes pour prendre en compte les données ou flux propres aux interactions avancées (commandes, nombreux degrés de libertés, dispositifs multiples, etc.).
L'utilisation d'un modèle concret d'implémentation suffisamment flexible et générique pour faire cohabiter différentes techniques et dispositifs dans un même environnement de développement permettrait de reporter ce contrôle de la cohérence lors de la création des applications. Le problème ne serait alors plus d'ordre technique mais d'utilisabilité de l'interface, aspect primordial de la conception des IHM. Il est alors nécessaire de proposer une approche plus flexible qui rend graphismes, interactions et dispositifs d'entrée réellement indépendants tout en supportant les outils et mécanismes permettant l'évolution et le prototypage.
stuf