Les dispositifs IAP fournissent plusieurs manières de lier des dispositifs ICON (les périphériques d'entrée, en général) aux composants graphiques du graphe de scène. Nous en distinguons dès lors quatre classes, selon le type de liaison qu'ils permettent:
|
Selon [Foley et al.1990], une technique d'interaction décrit «la manière de se servir d'un dispositif d'entrée» pour accomplir une tâche sur un ordinateur. Conventionnellement, les techniques d'interactions sont décrites de façon abstraite et générique, sans les lier à un périphérique d'entrée et à une tâche (ou un objet) spécifiques (c'est le style d'interaction dans la figure 7.12). Pourtant, leur implémentation concrète s'avère être fortement dépendante du couple {dispositif, tâche}, de par la rigidité des outils actuels. Il est alors souvent fastidieux d'adapter une technique d'interaction à une autre classe d'objets et à d'autres périphériques d'entrée que ceux pour lesquels elle a déjà été implémentée.
|
ICON a permis de séparer la gestion des entrées de la réalisation des interactions, introduisant la notion d'adaptabilité en entrée, offrant plus de flexibilité. Notre modèle permet cette même adaptabilité et flexibilité au niveau de l'interaction et de son objet d'intérêt en externalisant le style d'interaction avec les dispositifs d'interaction (voir figure 7.12).
Au niveau de l'implémentation de la boîte à outils, ces caractéristiques des classes de nœuds sont externalisées en implémentant des interfaces Java: l'interface Moveable, par exemple, rend compatible les futures instances avec les interactions de déplacement d'objets.
Cette modularité rend les interactions utilisables dans toutes les applications, et adaptables dynamiquement à tous types de périphériques pour composer de nouvelles techniques d'interaction. Elles peuvent aussi être étendues à d'autres classes d'objets graphiques (et donc de tâches), il suffit pour cela que ces classes implémentent les capacités compatibles.
Enfin, la dissociation des dispositifs d'entrée, objets d'intérêt et dispositifs d'interaction implique que ces derniers reçoivent les informations nécessaires à leur application par leurs canaux d'entrée. Pour cela, il présentent en général (voir figure 7.13):
MAGGLITE fournit essentiellement des dispositifs de manipulation directe tels que le dispositif Drag de la figure 7.13(b) (nous détaillons en annexe D, section D.2.1, les étapes de la conception de ce dispositif). Mais cette architecture permet aussi la réalisation de techniques de visualisation d'informations, de méthodes de saisie de texte, etc.
Nous avions qualifié ces dispositifs d'implémentations d'Interactions Génériques d'un point de vue du programmeur. Du point de vue de leurs utilisateurs (concepteurs d'interfaces ou utilisateurs) nous pouvons les qualifier d'Interactions Enfichables.
|
Les manipulateurs sont générés dynamiquement et ajoutés à la bibliothèque des dispositifs lorsque des objets graphiques sont instanciés. Ainsi, à chaque capacité spéciale de l'objet correspond un slot d'entrée sur son manipulateur permettant de la déclencher et/ou un slot de sortie permettant d'y accéder (nous détaillerons les mécanismes de génération automatique de ces dispositifs dans l'annexe C consacrée aux extensions que nous avons apportées à ICON).
|
La figure 7.15 présente la connexion d'un dispositif d'entrée isométrique à six degrés de libertés, le Magellan, au manipulateur d'un objet graphique, Thumbnails. Les axes x et z du dispositif physique sont connectés aux slots de déplacement relatif de l'objet (dx et dy) et son axe de rotation u au slot de rotation de l'objet (rotate). Les actions sur ces axes permettent donc d'agir directement sur l'objet graphique. Les signaux de chaque canaux transitent par les dispositifs de la configuration (le graphe d'interaction) et sont transmis à l'objet (le graphe de scène) par son manipulateur (flèches bleues de la figure 7.15). Par contre, du point de vue de l'utilisateur, ce mécanisme est transparent et le périphérique physique est directement couplé, associé à l'objet graphique (flèche rouge pointillée sur la figure). Ce principe d'association directe est une manière simple et efficace de faire de la manipulation directe, en renforçant la notion de contrôle dans l'approche en flot de données.
|
Les dispositifs de comportement décrivent des comportements ou des états génériques (pulsation, surlignage, «collage», etc.) qui peuvent être appliqués à n'importe quel composant ou groupe de composants de la boîte à outils. Leur place et leur fonctionnement dans le modèle des graphes combinés sont très liés aux manipulateurs. En effet, les dispositifs de comportement doivent être connectés aux objets graphique par l'intermédiaire de leurs manipulateurs (voir figure 7.16). Ainsi, il est possible de spécifier lors de l'exécution de l'application quel va (vont) être le(s) comportement(s) graphique(s) d'un objet de l'interface.
Ces dispositifs présentent le double avantage d'externaliser les comportements graphiques des objets de la boîte à outil, afin de pouvoir les réutiliser simplement et dynamiquement sur tout type de composants, et de rendre leur déclenchement complètement configurable. Ainsi, en opposition aux modèles d'architectures logicielles standards qui proposent différentes classes d'objets pour différents comportements, notre proposition permet des associations dynamiques objet-comportement(s) à un niveau de granularité fin et sans avoir recours à de lourdes modifications logicielles (implémentation de nouvelles classes d'objets).
Comportement direct
Nous parlons de comportement direct lorsque le déclenchement du comportement est contrôlé
par le composant graphique qui lui est associé. La figure 7.17 présente une
telle connexion. Le manipulateur de l'objet graphique étoile et le dispositif de comportement
pulsation sont connectés par leurs slots id (sortie du manipulateur) et
magglite (entrée du comportement). Ainsi, le comportement pulsation est associé de manière
unique à l'objet graphique étoile. Le slot de déclenchement est connecté au slot de sortie du
manipulateur picked.prox. Cette connexion permet de déclencher la pulsation de l'objet
graphique dès que le pointeur est dans sa zone de proximité7.3.
Comportement indirect
La notion de comportement indirect est différente du point de vue de l'action qui déclenche
le comportement. Celui-ci n'est plus directement connecté à l'objet en question, mais à un autre
dispositif. Ainsi, comme le montre la figure 7.18, ce peut-être un
périphérique d'entrée (figure 7.18(a)), un manipulateur d'un autre objet
graphique (figure 7.18(b)) ou tout autre dispositif compatible.
Dans le premier cas, la pulsation de l'objet étoile est déclenchée lorsque le bouton gauche de la souris est pressé, dans l'autre, lorsque le pointeur est situé sur l'objet image.
Comportement de groupe
Nous avons vu jusqu'ici les dispositifs permettant l'association d'un ou plusieurs comportements à
un objet unique. Nous proposons un dispositif groupe qui permet de connecter plusieurs
objets graphiques pour les associer à un même comportement. Nous appelons ce mode de configuration
le comportement de groupe. Ainsi, que ce soit en déclenchement direct ou indirect, tous les
objets se verront attribuer le même comportement, déclenché par la même action. La figure
7.19 illustre ce principe par la connexion de trois objets graphiques à un
dispositif de comportement surlignage déclenché par la sélection d'un quatrième objet
(comportement indirect). Lorsque le pointeur survole cet objet, le comportement est appliqué aux
trois autres (voir figure 7.19(c)).
Les exemples que nous avons présentés restent relativement simples et illustratifs. Toutefois, les dispositifs de comportement et les modes d'utilisation que nous leurs avons associés offrent de nombreuses possibilités de prototypage et de conception d'interactions avancées, particulièrement avec des objets graphiques plus évolués ou des configurations plus complexes. En plus des avantages de l'association dynamique objet(s)/comportement(s) en terme de réutilisabilité et de configurabilité, ces dispositifs permettent encore une fois de rendre les retours graphiques de l'interface modifiables et adaptables.
|
Mode local
Les valeurs reçues par les slots d'entrées de coordonnées sont converties dans le système de
coordonnées local de l'objet graphique auquel est attaché l'outil. Ce mode permet une projection
complète de la portée du périphérique d'entrée connecté à l'outil sur la surface visible du
composant. Dans la figure 7.21, l'outil interne de dessin est connecté à une
tablette graphique en mode mode local, mode approprié aux périphériques d'entrée absolus.
Mode global
Dans ce mode, au contraire du mode local, l'outil n'opère aucune conversion sur les
coordonnées et les interprète donc en coordonnées écran. Ainsi, la portée du dispositif d'entrée est
projetée sur l'écran. L'outil n'est alors actif que lorsque les coordonnées reçues sont dans les
limites de l'objet graphique auquel il est attaché. Dans le cas contraire, l'outil est inactif et
les coordonnées sont transmises par ses slots de sortie, sans que son action soit déclenchée. Dans
la figure 7.22, deux outils internes sont connectés l'un à l'autre en mode
global.
Le premier dans la chaîne, nommé GestureZone, est attaché au composant à bord bleu et son action est de reconnaître et interpréter des gestes. Ses slots d'entrée sont connectés à la sortie d'un dispositif tablette graphique. Le second outil est un outil interne de dessin, attaché au bureau de l'application. Ses slots d'entrée sont connectés aux slots de relais de l'outil de geste (outside.use, outside.x et outside.y).
Lorsque les coordonnées écran envoyées par le dispositif tablette sont dans les frontières du composant de reconnaissance de geste, l'outil de geste attaché est activé et ne transmet aucune valeur à l'outil de dessin du bureau. Lorsque les coordonnées sont en dehors des frontière de la zone de gestes, l'outil de gestes est désactivé et il transmet les coordonnées à l'outil de dessin du bureau. L'utilisateur peut donc dessiner n'importe où sur le bureau, excepté dans la zone de gestes où ses traits sont interprétés. Cette projection de zones de l'écran sur les dispositifs d'entrée est une manière efficace de construire des interactions post-WIMP, tout spécialement avec des dispositifs tels que des tablettes, tablettes écran ou écran tactiles.
La boîte à outils propose trois exemples d'outils internes: l'outil interne de dessin, l'outil interne de gomme et un outil interne générique que nous détaillerons dans le chapitre suivant. Les différents mécanismes (modes de gestion des coordonnées, retour graphique et installation de l'outil) sont implémentés dans la boîte à outil et sont donc hérités lors de la création d'un nouveau type d'outil interne. Seule l'action proprement dite de l'outil doit être implémentée (l'annexe D offre plus de détails techniques sur la création d'un outil interne).
Les dispositifs présentés précédemment permettent essentiellement de contrôler les outils, de spécifier des interactions et comportements pour l'interface au niveau des activités que permet l'application (dessin dans des composants, déplacement d'objets, affichage de données, etc.). Le dispositif de l'application ne permet pas le contrôle d'objets graphiques mais des fonctionnalités globales, c'est à dire au dessus du graphe de scène. Ainsi, il peut proposer des fonctionnalités telles que le déplacement ou le redimensionnement de l'environnement graphique global de l'application (fenêtre système), l'ouverture du configurateur graphique ou la fermeture de l'application. La figure 7.23 présente un dispositif d'application.
|
Les fonctionnalités de base qu'il propose sous forme de slots d'entrée sont communes à toutes les applications construites avec la boîte à outils: plein écran, configuration, quitter, etc. La création de ce dispositif est dynamique, lors du lancement de l'application et il est bien sur possible de lui rajouter d'autres fonctionnalités (par programmation).
Ce dispositif fournit donc, au niveau de l'application, les mêmes capacités, principes de conception et d'utilisation que ceux proposés au niveau des outils de l'application. Cela permet de proposer des interactions homogènes et d'éviter pour l'utilisateur une rupture entre les outils proposés et le contrôle global de l'application. En effet, il serait incohérent de proposer une barre de menus standard d'application WIMP (fichier, éditer, etc.) dans une application avancée basée sur le dessin et la reconnaissance de gestes, comme SVALABARD, par exemple. Le dispositif de l'application permet ce contrôle avec les mêmes interactions, et autorise de fait la suppression de tous les contrôles et widgets standards si ceux-ci ne sont pas adaptés.
stuf