C.2 Extension de la librairie de dispositifs d'ICON

Nous avons aussi, afin d'augmenter encore les possibilités d'ICON et donc de MAGGLITE, développé de nouveaux dispositifs offrant à la fois une meilleure portabilité de la boîte à outils mais aussi des possibilité pour l'exploration d'autres méthodes d'interaction.

C.2.1 Dispositifs système

Nous avons introduit dans ICON une gestion des périphériques d'entrée basée sur la librairie java Jinput [Sun Microsystems, Inc2004a] afin de proposer un support unifié des périphériques sous plusieurs systèmes d'exploitation (Windows, Linux et MacOS). La première version de la boîte à outils proposait en effet des accès bas-niveau aux périphériques par des API souvent dépendantes du système d'exploitation, limitant alors la portabilité de la boîte à outil, mais aussi des configuration d'entrée.
Jinput propose un accès unifié à un grand nombre de périphériques d'entrée, en déléguant la gestion du bas-niveau à des greffons. Ainsi, sur une même configuration matérielle, les mêmes dispositifs d'entrée sont disponibles, quel que soit le système d'exploitation, résolvant en partie le problème de l'hétérogénéité des APIs d'entrée soulevé par la première version d'ICON.

Nous avons aussi complété la librairie d'ICON par des dispositif d'acquisition d'image, basés sur la librairie Java Media Framework [Sun Microsystems, Inc2005]. Cet ensemble de dispositifs permet l'accès bas-niveau à des périphériques tels que des webcams ou des cartes d'acquisition vidéo connectées à la machine hôte. Ces dispositifs (voir figure C.2) permettent l'émission d'images dans des configuration d'entrée, sous la forme de signaux ponctuels à déclenchement contrôlé par un événement (capture d'une image) ou en flux continu (capture video).

Figure C.2: Dispositif de capture d'images. La figure (a) montre l'utilisation d'un dispositif de capture video dans une configuration d'entrée. Celui-ci est connecté en entrée d'un dispositif adaptateur, lui-même connecté au dispositif manipulateur d'un conteneur d'images. Le flux vidéo est alors affiché dans l'interface (figure (b)). Dans la figure (c), un adaptateur permettant le filtrage de couleurs a été inséré dans les traitements. Il peut par exemple être utilisé pour manipuler un curseur.

Des dispositifs adaptateurs asynchrones dédiés au traitement des images peuvent être réalisés à partir d'un squelette de dispositif. Celui-ci permet d'externaliser les algorithmes de traitement d'images à l'aide du principe des entrées/sorties implicites, assurant que ces dispositifs coûteux en ressources ne pénaliserons pas l'exécution réactive de la configuration d'entrée (la thèse de Pierre DRAGICEVIC donne plus de détails sur la réalisation de dispositifs à haut débit d'informations).
Parmi les adaptateurs, nous proposons un dispositif de conversion d'images et un filtrage des couleurs. Le premier permet la conversion vers différents types d'images (pour l'affichage, par exemple, comme dans la figure C.2(b)). Le second peut permettre le contrôle d'un curseur par suivi de gestes^C.1, comme présenté dans la figure C.2(c).

Enfin, un nouveau dispositif système permet de jouer des fichiers audio (en complément de celui d'origine qui n'utilisait que les périphérique de sortie de type Midi). Il permet de configurer simplement un retour sonore dans les interfaces, en spécifiant dans la configuration d'entrée l'action qui va déclencher le son.

C.2.2 Techniques d'interaction et dispositifs spéciaux

Nous avons aussi complété la librairie des dispositifs par des techniques d'interaction avancées telles que la reconnaissance de gestes, les marking menus, ou des dispositifs permettant d'enregistrer des flot de données.

Interpréteur de gestes
Le dispositif de reconnaissance de gestes que nous avons développé dans ICON  facilite la réalisation d'interfaces gestuelles (voir figure C.3(a)). Il utilise les interpréteurs de la bibliothèque Satin [Hong et Landay2000], ainsi que l'outil Quill [Allan Christian Long, Jr et Landay1999,Allan Christian Long, Jr2001] pour la création et l'édition interactive des gestes.

Figure C.3: Dispositif de reconnaissance de gestes et l'outil de création/édition de gestes Quill [Allan Christian Long, Jr2001].

À partir des entrées reçues (position et activation), le dispositif analyse la marque tracée conformément aux gestes définis. Il émet alors le nom et le groupe (les gestes peuvent être regroupés par catégories) du geste reconnu, ou la commande «unrecognized», et les informations géométriques sur le geste tracé (sa boîte englobante et ses points de départ et d'arrivé). Ainsi, de nombreuses configurations avancées peuvent êtres construites autour de ce dispositif, de la simple commande gestuelle, jusqu'à la sélection d'objets comme nous l'avons fait pour la saisie des contraintes dans SVALABARD (voir les sections 4.3.2 et 8.4.3).

Ce dispositif est interchangeable avec d'autres dispositifs de commande (clavier, reconnaissance vocale, etc.), permettant ainsi d'ajouter facilement de la reconnaissance de geste dans une application, même si celle-ci n'était pas à l'origine prévue pour.

Figure C.4: Interchangeabilité des dispositifs de commande. Le dispositif de reconnaissance vocale de la figure (a) est simplement remplacé par le dispositif de commande gestuelle dans la figure (b).

Par exemple Pierre DRAGICEVIC avait utilisé le contrôle vocal pour manipuler une barre de défilement dans une application Swing (voir figure C.4(a)). Le dispositif de reconnaissance vocale émet les commandes reconnues (plus, un peu moins, minimum, etc.) qui sont alors envoyées au dispositif de contrôle conditionnel switch (qui active une commande en fonction de la chaîne de caractères reconnue). En remplaçant le dispositif de reconnaissance vocale par celui de reconnaissance de gestes, en ayant au préalable défini un vocabulaire de gestes compatible (voir figure C.4(b)), il est alors possible de manipuler la barre de défilement à l'aide de gestes. Des configurations plus complexes pourraient être construites en utilisant les informations sur la marque tracée pour déterminer l'objet d'intérêt (sélection de la barre de défilement) et le taux de défilement, par exemple.

C.2.2.1 Marking Menus

Nous avons déjà présenté et discuté l'emploi de ces menus dans la description des interaction de SVALABARD, page . Rappelons simplement qu'ils combinent menus circulaires (« pie menus») et gestes rectilignes simples afin de sélectionner l'entrée désirée. Dans [Kurtenbach et Buxton1994], les auteurs ont montrés les avantages qu'ils procurent par rapport à des menus linéaires (mémorisation musculaire, différents niveaux d'expertise) et leurs apports dans les interfaces à stylet (cohérence, rapidité et apprentissage).

Figure C.5: Dispositif Marking Menu. Le dispositif de Marking Menu est paramétrable (graphismes et comportement) et peut être utilisé dans toutes les applications.

L'implémentation des Marking Menu que nous proposons en fait une technique générique, sous la forme d'un dispositif. Dans la figure C.5, nous avons représenté ce dispositif connecté dans une configuration, sa boîte de paramètres et son retour graphique. Le menu est contrôlé par une souris et activé par le bouton gauche. Il faut ensuite configurer quelques paramètres, en particulier les items du menu: ceux-ci sont saisis dans des zones de textes de la boîte de paramètres. Le retour graphique du menu sera créé selon ces items, dont nous avons limité le nombre à sept ^C.2.

Les autres paramètres du dispositif sont les options graphiques (taille, couleurs, opacité, tracés et police) et les options de comportement du menu: délai avant l'apparition du menu ou de ses sous-menus, taille de la zone centrale. Le menu peut alors être utilisé dans la configuration: un clic sur le bouton de la souris permet de l'activer. Au bout du temps paramétré, le menu apparaît et permet de sélectionner l'item voulu, validé par le relâchement du bouton (un retour en zone centrale annule l'action). Si un item a été choisi, son nom est alors émis par le slot de sortie command du dispositif. Évidemment, si le geste est terminé avant le délai d'apparition du menu, le comportement est le même (envoi du nom de l'item correspondant au geste). Ce slot de sortie de commande peut être connecté à un dispositif switch, qui converti la chaîne de caractère reçue en une commande pour l'envoyer à un dispositif de contrôle (application ou outil), comme dans la figure C.5.

Enfin, plusieurs de ces dispositifs peuvent être composés afin de créer des cascades de sous-menus. Il faut pour cela utiliser les slot de sortie sub du dispositif. Le slot sub.this d'un menu de niveau N permet de le connecter au slot d'entrée parent de son sous-menu de niveau N+1. Ensuite, les slots de sortie sub.command, sub.x et sub.y permettent le contrôle du sous-menu.

Figure C.6: Dispositifs de Marking Menu en cascade. Les dispositifs peuvent être associés dans une même configuration afin de former des sous-menus en cascade. En haut à gauche, le sous-menu New du menu principal; en haut à droite, le sous-menu SaveAs du sous-menu Save du menu principal.

La figure C.6 illustre de telles associations. Il y a tout d'abord un menu principal, le dispositif Main menu. Celui-ci propose les commandes «open», «new», «save», «close» et «quit». La sortie principale (command) de ce dispositif est connectée à un dispositif Switch qui va être assigné au traitement des items qui ne nécessitent pas de sous-menu: «open», «close» et «quit». Par contre, les items «new» et « save» nécessitent un sous-menu: la sortie sub.command va donc être connectée à un autre dispositif Switch qui va traiter les commandes «new» et «save» afin de les repartir sur les dispositifs de sous-menu. La commande «open» est transmise au sous-menu New menu, la commande «save» au sous-menu Save menu.
Le sous-menu New menu propose alors six items: «class», «package», «beans», etc. Ces sorties sont elles-mêmes connectées à un dispositif Switch qui va traiter les commandes émises par ce menu. Dès lors, lorsque l'utilisateur choisis l'item «new» du menu principal, le sous-menu New menu apparait et propose six nouveaux items. Il en est de même pour l'item « save» qui déclenche le sous-menu Save menu, pouvant lui aussi déclencher le sous-menu SaveAs menu.

Nous accordons qu'une telle configuration peut paraître assez complexe, mais elle obéit à une simple logique d'aiguillage des signaux, propre à l'architecture en flot de données qui est assez vite assimilée de par sa logique. Bien que l'utilisateur final puisse modifier les configurations, cela reste tout de même plus le travail du concepteur de l'interface. Nos dispositifs lui permettront de créer très rapidement des Marking menu, de les tester, les raffiner et les réorganiser sans même avoir à écrire une seule ligne de code. Et il est encore une fois évident que des configurations alternatives peuvent être proposées (reconnaissance vocale, gestes, etc.).

C.2.2.2 Enregistreur et utilisateur virtuel

Enfin, les dispositifs que nous décrivons maintenant ont étés conçus tout particulièrement pour la pratique d'études utilisateurs. Ils permettent d'enregistrer et de re-émettre les flux traversant une configuration d'entrée, en n'importe quel nœud de celle-ci.

Figure C.7: Dispositif d'enregistrement. Le dispositif inputRecorder, intercalé à n'importe quel niveau d'une configuration, permet d'enregistrer les valeurs reçues en entrée dans un fichier XML. Ce fichier pourra être « rejoué» par le dispositif virtualUser (figure C.8).

Le premier, nommé inputRecorder, est un dispositif d'enregistrement que l'on peut intercaler à n'importe quel point d'une configuration d'entrée. Par exemple, dans la figure C.7, il se situe entre le dispositif souris et les adaptateurs qui lui sont normalement connectés pour propager ces valeurs dans le reste de la configuration. Lorsque la configuration est lancée, le dispositif d'enregistrement accumule toutes les valeurs qu'il reçoit des dispositifs qui lui sont connectés, la souris dans notre exemple. Bien entendu, il ne bloque pas ces valeur et les transmet par ses slots de sortie. Lorsque la configuration d'entrée est stoppée, le dispositif sérialise ces données accumulées dans un fichier XML.

Dans cet exemple, les données enregistrées sont reçues directement d'un périphérique d'entrée afin d'enregistrer tous ses déplacements et actions. Il serait évidemment possible d'enregistrer les sorties d'autres dispositifs, en utilisant même plusieurs enregistreurs dans une configuration.

Les données recueillies pourront ensuite être analysées pour des mesures de performance ou un simple suivi des actions réalisées. Mais il est aussi possible de «rejouer» les actions qui se sont déroulées en utilisant le dispositif virtualUser.,Il permet de re-émettre des données enregistrées dans une configuration d'entrée. Il peut être connecté dans la même configuration d'entrée, en lieu et place du dispositif d'enregistrement (voir figure C.8) et de tous les dispositifs qui lui étaient connectés afin de simplement «rejouer» les actions enregistrées. Il peut aussi être connecté dans une configuration alternative, comportant des dispositifs d'analyse, ou même d'autres interactions compatibles avec les données enregistrées.

Figure C.8: Dispositif d'entrées virtuelles. Le dispositif virtualUser permet de rejouer des fichiers enregistrés par le dispositif inputRecorder. Il suffit de le replacer dans la même configuration d'entrée afin qu'il émette les valeurs enregistrées.

Ces dispositifs peuvent aussi cohabiter dans une même configuration. Il est alors possible de définir un tampon d'échange entre eux (à l'aide des paramètres des dispositifs). Ce tampon peut servir, par exemple, à l'enregistrement d'actions répétitives qui pourront alors être rappelées dans le même contexte et lors de la même tâche, dans l'esprit de macros. Il serait alors envisageable d'étudier les possibilités de telles configurations dans le cadre de paradigmes de programmation par démonstration.