6.2 Supporter l'interaction avancée

Nous considérons trois catégories d'outils de développement d'applications interactives:

1. les boîtes à outils WIMP;
2. les boîtes à outils WIMP avancées;
3. les boîtes à outils post-WIMP spécialisées.

Tous s'attachent à offrir un modèle graphique bien défini et générique, relativement complet et évolutif. Il n'en est toutefois pas de même pour la gestion des entrées et de l'interaction, chacune de ces approches raffinant ou proposant des modèles pour des objectifs différents.

6.2.1 Architectures graphiques

Du point de vue graphique, de grands progrès ont été faits dans les boîtes à outils d'interaction. La grande majorité d'entre elles proposent des modèles clairs, basés sur des abstractions simplifiant la gestion de l'affichage et permettant des effets visuels toujours plus sophistiqués. L'impact sur l'interaction est alors évident, ces architectures permettant de réaliser plus simplement des techniques de manipulation directe ou d'innover dans l'interaction grâce à des effets visuels avancés (transparences, déformations, animations, etc.) [Roussel2002].

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.

6.2.2 Périphériques d'entrée et interactions non-standard

6.2.2.1 Les boîtes à outil WIMP

Les boîtes à outils WIMP, de X Toolkit [McCormack et Asente1988] à Java Swing [Eckstein et Loy2002], sont les plus standards et probablement les plus utilisées actuellement. Mais elle ne permettent en l'état que la réalisation d'applications WIMP, postulant dès lors que les dispositifs d'entrée utilisés seront une souris et un clavier. Elles n'offrent qu'un support dit par compatibilité des dispositifs d'entrée avancés, reposant sur la gestion qu'en offre le système d'exploitation, sans tirer partie de leur capacités (ils sont vus comme une souris).

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.

6.2.2.2 Les boîtes à outil WIMP avancées

Les boîtes à outils WIMP avancées, comme Subarctic [Hudson et Smith1996] (évolution de Artkit) et Garnet/Amulet [Myers1990,Myers et al.1997], par exemple, ont pour objectif de faciliter la construction d'interfaces WIMP (ou à manipulation directe) et d'améliorer l'insertion de techniques moins conventionnelles dans ce type d'interfaces. L'effort majeur porte sur l'architecture, dans le but de fournir l'extensibilité faisant défaut aux boîtes à outils standards. Les mécanismes proposés ont favorisé quelque peu l'ajout de nouvelles techniques et l'extension des boites à outils: interaction gestuelle, champs de gravité et lentilles sémantiques dans Subarctic [Tyson R. et al.1990,Hudson et al.1997] ainsi que les entrées ambiguës (association gestes/parole) [Mankoff et al.2000]; Amulet améliore entre autre Garnet par l'ajout d'interaction gestuelle [Myers et al.1997], etc.

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.).

6.2.2.3 Les boîtes à outil post-WIMP

Les boîtes à outils post-WIMP sont conçues pour prendre en compte et décrire des paradigmes d'interaction non-conventionnels. Mais bien qu'elles spécifient et implémentent de manière claire des modèles et des architectures assez génériques, elles restent spécialisées dans un paradigme d'interaction. Ainsi, Satin [Hong et Landay2000] se focalise sur l'interaction gestuelle, MMM [Bier et Freeman1991], Whizz [Esteban1997,Chatty1994] et MID [Hourcade et Bederson1999] sur les pointeurs multiples (travail collaboratif et interaction bimanuelle), les Phidgets [Greenberg et Fitchett2001] et WidgetTap [Greenberg et Boyle2002], ou iStuff [Ballagas et al.2003] pour les interfaces tangibles, 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.

6.2.2.4 Synthèse

Dans un souci de généralité et de portabilité, les boîtes à outils standards ont rendu rigide et stéréotypé le développement d'applications interactives. Ainsi, bien que des boîtes à outils WIMP avancées aient introduit des architectures et des modèles plus souples, elles n'en restent pas moins relativement inefficaces pour supporter les nouveaux paradigmes d'interaction, ainsi que les entrées non-standard. Leurs extensions dans ce sens se font souvent au prix d'un remaniement plus ou moins profond de leur architecture et de leur implémentation. Cette tendance s'observe d'ailleurs par le nombre élevé de publications portant sur l'ajout d'un nouveau style d'interaction dans une boîte à outils existante (des gestes [Henry et al.1990] à l'interaction multimodale [Mankoff et al.2000] dans Subarctic, par exemple). Bien que cette approche apporte des solutions aux problèmes de généricité des modèles d'implémentation actuels ou permette d'en formaliser certains aspects, elle n'est pas à notre avis une solution aux problèmes de la flexibilité et de la modularité nécessaires à la cohabitation et au prototypage de nouvelles techniques. Elle se concentre plus sur la conception des interfaces que celle des interactions [Beaudouin-Lafon2004].

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.