« J’ai inventé une lampe de poche qui fonctionne à l’énergie solaire, elle n’a qu’un dernier défaut, elle ne marche qu’en plein soleil »
A. FRANQUIN.
Sommaire
6.1 Introduction . . . 148 6.2 Supporter l’interaction avancée . . . 148
6.2.1 Architectures graphiques . . . 149 6.2.2 Périphériques d’entrée et interactions non-standard . . . 149
6.3 Prototypage et configuration visuels . . . 151 6.4 ICON: une solution pour l’adaptabilité en entrée . . . 152
6.4.1 Dispositifs et slots . . . 153 6.4.2 Configurations d’entrée et exécution réactive . . . 153 6.4.3 Niveau de contrôle des applications avec ICON . . . 155
CHAPITRE 6. UNE ÉVOLUTION NÉCESSAIRE
6.1 Introduction
Lorsque nous avons débuté le développement de SVALABARD, nous nous sommes rapidement heurté à des problèmes d’ordre technique. Ces problèmes d’implémentation ne remettaient pas en cause notre approche et ses principes, mais les rendaient difficilement réalisables avec les outils logi-ciels actuels pour trois raisons majeures :
1. Tout d’abord, l’environnement graphique de SVALABARDrepose sur des techniques avancées, mêlant des effets visuels tels que transparences, déformations, animations, etc.
2. Ensuite, la métaphore de table à dessin naît en partie de l’usage de dispositifs d’entrée avancés liés à de multiples techniques d’interaction non-standard (reposant en majeure partie sur le dessin).
3. Enfin, il nous parait essentiel pour une telle approche novatrice de s’appuyer sur une architecture flexible facilitant le prototypage (afin de pouvoir affiner et remettre en question nos choix lors de la conception du système), l’adaptabilité et l’accessibilité (lors de l’utilisation) et l’évolution. Ces trois points (modèle graphique, dispositifs d’entrée/techniques avancées et adaptabilité) ont souvent été abordés dans le domaine des boîtes à outils d’interaction et de nombreuses solutions y ont été apportées. Pourtant, ils n’ont que rarement été considérés sous un angle commun permettant d’unifier leurs solutions. Dès lors, il n’existe pas d’outil regroupant les solutions proposées dans un même modèle d’architecture logicielle et à plus forte raison dans une boîte à outils unique.
Nous aurions pu, en nous appuyant sur les outils logiciels actuels, apporter une solution particu-lière et dépendante de nos besoins pour l’implémentation de SVALABARD. Cette approche monoli-thique aurait demandé un gros effort de programmation. Nous avons jugé plus important, essentiel-lement pour les perspectives que cela offrait, d’unifier ces solutions dans un modèle d’architecture logicielle cohérent et de le réaliser au niveau d’une boîte à outils, indépendante des applications. Ce choix ne garantissait pas moins d’efforts et un développement plus rapides, la réalisation de la boîte à outils MAGGLITEayant nécessité un lourd travail de développement. Par contre, l’implémentation de SVALABARD en a été considérablement réduite, nous permettant alors de concentrer nos efforts sur sa conception. Cette approche de développement parallèle nous a de plus permis d’avoir un exemple concret d’utilisation de la boîte à outils, mais aussi d’en raffiner les mécanismes pour des besoins applicatifs réels.
Dans ce court chapitre introduisant la deuxième partie de nos travaux, nous aborderons la situation actuelle vis à vis des trois points cités plus haut au travers d’un rapide survol des boîtes à outils les plus représentatives (pour un état de l’art plus complet, nous renvoyons le lecteur au chapitre 2 de la thèse de doctorat de Pierre DRAGICEVIC[Dragicevic, 2004b]).
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.
6.2. SUPPORTER L’INTERACTION AVANCÉE Tous s’attachent à offrir un modèle graphique bien défini et générique, relativement complet et évo-lutif. 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’in-teraction 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.) [Roussel, 2002].
Nous verrons en particulier, dans la section 7.2 page 159 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 gra-phique 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 Les boîtes à outil WIMP
Les boîtes à outils WIMP, deX Toolkit [McCormack et Asente, 1988] à Java Swing [Eckstein et Loy, 2002], 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 stan-dard, elles sont alors très difficile à étendre pour le support de périphériques et de techniques d’inter-action avancées, de par l’encapsulation de l’interd’inter-action dans les widgets.
Les boîtes à outil WIMP avancées
Les boîtes à outils WIMP avancées, comme Subarctic [Hudson et Smith, 1996] (évolution de Artkit) et Garnet/Amulet [Myers, 1990; Myers et al., 1997], par exemple, ont pour objectif de fa-ciliter 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,
CHAPITRE 6. UNE ÉVOLUTION NÉCESSAIRE 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.).
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’inter-action. Ainsi, Satin [Hong et Landay, 2000] se focalise sur l’interaction gestuelle, MMM [Bier et Freeman, 1991],Whizz [Esteban, 1997; Chatty, 1994] et MID [Hourcade et Bederson, 1999] sur les pointeurs multiples (travail collaboratif et interaction bimanuelle), lesPhidgets [Greenberg et Fitchett, 2001] etWidgetTap [Greenberg et Boyle, 2002], ou iStuff [Ballagas et al., 2003] pour les interfaces tangibles, etc.
Un cas particulier est celui deCPN2000/CPN Tools [Beaudouin-Lafon et Lassen, 2000], une ap-plication 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 à ou-tils, CPN2000 démontre la possibilité de faire cohabiter ces différentes techniques dans une architec-ture claire en utilisant un modèle d’interaction adapté (l’interaction instrumentale [Beaudouin-Lafon, 2000]).
À l’exception de certaines boîtes à outils 3D et leurs modèles différents de gestion des entrées (Virtools [Virtools SA, 2001], 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’exploita-tion des entrées enrichies, reposant souvent sur des architectures à événements tradil’exploita-tionnelles. Même lorsqu’elles sont spécialisées dans un paradigme fortement lié aux entrées (comme les pointeurs mul-tiples), les dispositifs sont exploités de façon ad hoc.
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
6.3. PROTOTYPAGE ET CONFIGURATION VISUELS 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-Lafon, 2004].
Du point de vue des outils pour le développement d’application post-WIMP, les solutions propo-sé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 re-dé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 co-habiter 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 don-né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 per-mettrait 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 concep-tion des IHM. Il est alors nécessaire de proposer une approche plus flexible qui rend graphismes, in-teractions et dispositifs d’entrée réellement indépendants tout en supportant les outils et mécanismes permettant l’évolution et le prototypage.
6.3 Prototypage et configuration visuels
Que ce soit pour simplifier le travail des programmeurs, fournir à des concepteurs d’interfaces non programmeurs (graphistes, etc.) des outils adaptés à leurs compétences ou même permettre à l’utilisateur final de paramétrer et de personnaliser son application, la communauté de recherche en IHM a proposé beaucoup d’outils graphiques pour la conception d’interfaces.
Cette préoccupation était aussi l’une des nôtres lors de la réalisation de SVALABARD : pouvoir prototyper rapidement des interactions avancées et novatrices, mais aussi, du fait de l’emploi de tech-niques non-standard, permettre à l’utilisateur de pouvoir forger son propre outil pour une transition plus « douce » et personnelle (adapter le système aux dispositifs, changer les techniques d’interaction, personnaliser les comportements, etc.).
gra-CHAPITRE 6. UNE ÉVOLUTION NÉCESSAIRE phique (comme par exempleVisual Basic pour les interfaces WIMP ou des boîtes à outils utilisant des documents graphiques issus de logiciels de dessin pour les interfaces avancées [Chatty et al., 2004]), ils nécessitent toujours d’avoir recours à la programmation pour décrire les comportements de l’appli-cation. Des approches plus évoluées, notamment avec Garnet/Amulet [Myers, 1990] et ses nombreux constructeurs d’interfaces basés sur la programmation par démonstration (Lapidary [Vander Zanden et Myers, 1995], par exemple), ont permis d’aller plus loin dans la description graphique des com-portements, mais leur champ d’application reste relativement limité aux interfaces WIMP dans des domaines bien particuliers.
En plus de leur peu d’ouverture aux techniques d’interaction avancées, il est évident que de telles approches n’étaient pas envisageables pour notre application. Car même si elles avaient facilité son développement, elles n’auraient pas permis le haut niveau de description et de configurabilité désiré pour les interactions et les filtres de traitement du dessin.
Pierre DRAGICEVICa montré dans sa thèse que les systèmes basés sur un modèle à flot de données offraient non seulement plus de flexibilité au niveau de l’architecture, mais aussi une aptitude certaine à la description graphique des entrées et des interactions. En approfondissant les approches existantes basées sur ce principe (éditeurs de comportements pour la 3D, l’éditeurWhizz’Ed [Esteban, 1997]), il a proposé la boîte à outils ICONcomme solution pour une partie des problèmes que nous avons évoqués [Dragicevic et Fekete, 2001; Dragicevic, 2004b].
6.4 IC
ON: une solution pour l’adaptabilité en entrée
ICONest une boîte à outils, programmée en Java, complétée par un éditeur interactif permettant de créer des applications interactives hautement configurables, c’est à dire des applications contrôlables avec un grand nombre de périphériques d’entrée et de techniques d’interaction non-standard. ICON in-troduit une architecture réactive en flot de données qui permet de décrire des configurations d’entrée à partir de modules interconnectés en cascade. ICOM, le modèle d’ICON, est basé sur les dispositifs (figure 6.1), généralisation des dispositifs d’entrée : ils peuvent produire des valeurs de sortie, mais peuvent aussi en recevoir.
Slots de sortie
Entrées
implicites Sortiesimplicites
Slots d’entrée
6.4. IC ON : UNE SOLUTION POUR L’ADAPTABILITÉ EN ENTRÉE 6.4.1 Dispositifs et slots
Un dispositif est une « boîte noire » qui interagit avec son environnement par l’intermédiaire de canaux typés, appelés slots (d’entrée ou de sortie). Un dispositif peut aussi communiquer avec l’envi-ronnement extérieur (autre que des dispositifs) par des entrée/sorties implicites, traduisant la réception ou l’émission de données par des flux d’informations autres que les slots d’entrée ou de sortie. Le dis-positif est alors considéré comme actif (ou asynchrone).
Chaque dispositif peut également déclarer un ensemble de paramètres permettant de spécialiser son comportement. Dans le langage graphique du configurateur, chaque type de slot possède une repré-sentation distincte (cercles pour les Booléens, triangles pour les entiers, etc.) et peuvent être groupés hiérarchiquement pour composer des types structurés.
Le modèle ICOM définit trois catégories de dispositifs : les dispositifs système, qui décrivent des ressources système comme les périphériques d’entrée (souris, claviers, tablettes, reconnaissance vo-cale, etc.) ; les dispositifs utilitaires, qui sont des dispositifs indépendants du système allant de simples opérateurs booléens jusqu’à des feedbacks ou interactions avancées tels que des curseurs, « tool-glass » et interpréteurs de gestes ; les dispositifs d’application, qui sont les dispositifs qui contrôlent les objets de l’application (du domaine). Les dispositifs système et utilitaires sont fournis par la boîte à outils, alors que les dispositifs d’application doivent être conçus par les programmeurs de l’applica-tion.
6.4.2 Configurations d’entrée et exécution réactive
Un slot de sortie d’un dispositif peut être relié à un ou plusieurs slots d’entrée compatibles d’autres dispositifs par des connexions représentées par des lignes (voir figure 6.2 page suivante). Un en-semble de dispositifs connectés définis alors une configuration d’entrée exécutable par le noyau réactif d’ICON. Cette exécution se déroule en deux étapes :
1. le lancement, qui correspond à la préparation de la configuration d’entrée. Celle-ci est décom-posée et les dispositifs sont ensuite ouverts afin d’être initialisés. Cette initialisation permet au noyau d’exécution de récupérer le processeur de chaque dispositif : son comportement en exé-cution (traitement et mise à jour des slots). Ces processeurs sont enfin triés topologiquement en fonction du graphe de dépendances des connexions.
2. l’exécution en pas atomiques ou ticks. Cet algorithme mets à jour les dispositifs dont les valeurs ont changées et propage ces changements dans les dispositifs qui en dépendent (connectés) en une seule passe grâce au tri topologique des dispositifs.
Ce modèle d’exécution, inspiré des langages réactifs impératifs, est basé sur le principe du syn-chronisme parfait [Berry, 2000], modèle dans lequel les processus sont capables au niveau concep-tuel de s’exécuter et d’échanger des informations en un temps nul. Ce paradigme quelque peu dé-routant pour les programmeurs « classique » est un standard pour les théoriciens du contrôle ou les concepteurs de circuits électroniques. Son adaptation à la gestion des entrées a ouvert la voie d’une gestion réactive de l’interaction, à un niveau où le standard des files d’évènements est peu adapté, garantissant ainsi une réaction immédiate aux actions de l’utilisateur. Mais plus que la simple connexion de périphériques d’entrée, la description d’interactions a aussi été largement explorée par l’auteur d’ICON dans le cadre de la spécification d’interactions avancées [Dragicevic, 2004b; Dragicevic et Fekete, 2004] ou de l’association de son système avec une approche orientée contrôle [Dragicevic et al., 2004].
CHAPITRE 6. UNE ÉVOLUTION NÉCESSAIRE
Dispositifs
Système la bibliothèqueDispositifs de
Configuration d’entrée
Dispositifs de l’application
FIGURE6.2 –Une configuration d’entrée décrit une manière de relier des dispositifs système à des dispositifs d’application.
La description de l’interaction avec ce modèle devient à la fois simple et flexible. Simple, parce qu’elle permet de représenter l’interaction de manière graphique et dans une logique linéaire, moins compacte que la propagation d’événements traditionnelle. La connexion d’un périphérique aux in-teractions de manière directe et visuelle à l’exécution du programme permet de se rendre compte rapidement du résultat en « suivant les données du regard ». Flexible, car les dispositifs peuvent êtres remplacés facilement par d’autres, à tous les niveaux (périphériques d’entrée, retours graphiques, techniques d’interaction, comportements). Ce paradigme de flot de données permet une description de l’interaction avec une granularité plus fine que par l’utilisation d’une file d’événements.
En effet un type d’événement spécifique est en général associé à chaque type de périphérique d’entrée. Ces événements sont aussi fortement liés aux interactions et objets de l’implémentation pour que ceux-ci sachent adapter leur comportement. Ainsi, pour introduire la gestion d’un nouveau périphérique (manette de jeu, stylet sensible à la pression, par exemple) ou de nouvelles interactions (gestuelles, vocales ou manipulations directes avancées), il faut :
1. définir un nouveau type d’événement ;
2. modifier et adapter le mécanisme de propagation des événements ; 3. étendre les objets qui doivent réagir à ces événements.
Avec ICON, il suffit de créer un dispositif pour gérer le nouveau périphérique ou d’implémenter une nouvelle interaction sous la forme d’un dispositif. Une fois cela fait, le périphérique ou la technique d’interaction peuvent être réutilisés dans nombre de configurations d’entrée.
6.4. IC ON : UNE SOLUTION POUR L’ADAPTABILITÉ EN ENTRÉE L’éditeur graphique (voir figure 6.3) permet de mettre en correspondance les périphériques d’en-trée et l’application de manière interactive. Les périphériques d’end’en-trée disponibles sur le système ainsi que tous les dispositifs de la bibliothèque d’ICONsont organisés par dossiers et présentés sur un pan-neau. Il suffit de les placer dans la zone de configuration de l’éditeur pour les utiliser. La mise en correspondance met en œuvre l’insertion et la connexion de dispositifs qui décrivent des techniques