5.2 Les apports d'ICON du point de vue architectural

ICON repose sur des systèmes interactifs conventionnels (système d'exploitation + boîte à outils), systèmes dont nous avons déjà décrit les limites dans le chapitre 1 (section 1.4.3). Mais à l'inverse de ces systèmes il permet de décrire la manière dont les entrées sont gérées dans un modèle clair et consistant. Dans cette section, nous identifions les différents niveaux de gestion des entrées dans les systèmes interactifs réels, puis nous montrons la façon dont ICON parvient à étendre ce type de système, et ce que cette extension apporte.

5.2.1 Architecture concrète des systèmes interactifs

Figure: Architecture concrète d'un système classique, mettant en évidence les différents niveaux d'implémentation des techniques d'interaction standard.

Dans les systèmes interactifs actuels, les applications s'appuient essentiellement sur des services partagés fournissant une gestion standard des entrées. Dans ces systèmes, les techniques d'interaction standard sont implémentées sur plusieurs niveaux (figure 5.1):

• Niveau matériel: Les entrées peuvent être gérées en partie au niveau matériel, par l'électronique du dispositif. C'est le cas par exemple des boutons de tir automatique sur certaines manettes de jeux, similaires à la fonction de répétition de touches du clavier. Ces mécanismes peuvent être vus comme des techniques d'interaction.
• Niveau système: Au niveau du système d'exploitation, les pilotes de dispositifs fournissent au programmeur des abstractions de bas niveau pour lire les données en provenance des dispositifs. Les pilotes ont également pour charge de transformer les données spécifiques en informations interprétables par le gestionnaire d'entrées standard du système d'exploitation. Certains pilotes de dispositifs non standard permettent ainsi un contrôle par compatibilité en imitant le comportement d'un clavier ou d'une souris. Le gestionnaire d'entrées standard du système d'exploitation fournit des services relatifs aux dispositifs standards, tels que l'affichage d'un pointeur ou la gestion de la langue du clavier, et produit les événements propres à ces dispositifs. Un premier routage de ces événements est effectué par le gestionnaire de fenêtres, qui les transmet à la fenêtre concernée.
• Niveau boîte à outils: La boîte à outils graphique sur laquelle repose l'application interactive se charge, pour chaque fenêtre, de router les événements vers les widgets appropriés. Il existe deux stratégies standard de routage: le multiplexage spatial pour les événements positionnels, et le multiplexage temporel basé sur les techniques de focus. Ces stratégies de routage constituent des techniques d'interaction. Chaque widget de la boîte à outils gère à son tour une technique d'interaction générique. Dans les boîtes à outils qui suivent une approche MVC, le modèle d'un widget est distinct de sa vue et de son contrôleur (regroupés dans un objet UI dans le langage Java). Dans cette approche, les objets modèle peuvent être considérés comme des briques de base de l'application.
• Niveau applicatif: Si les modèles conceptuels d'interaction recommandent une séparation franche entre l'interaction et le noyau applicatif, cette séparation est difficile à mettre en uvre en pratique. En outre, les limitations inhérentes aux boîtes à outils obligent souvent l'implémentation de techniques d'interaction spécifiques au niveau de l'application.

5.2.2 Les niveaux d'accès et de contrôle d'ICON

Figure: Un système interactif concret intégrant ICON.

La figure 5.2 montre comment ICON s'insère dans un système interactif concret. ICON est une boîte à outils d'entrées qui s'interpose entre le système d'exploitation et l'application. Lorsqu'il est intégré à une boîte à outils graphique comme Swing, il s'insère entre ses mécanismes de routage événementiel et ses widgets. ICON peut servir à étendre la gestion standard des entrées, mais est également capable de gérer la quasi-totalité de l'interaction des dispositifs d'entrée à l'application. Le rôle joué par ICON dans la gestion des entrées dépend essentiellement de la manière dont il accède aux entrées et de la façon dont il contrôle l'application.

ICON accède aux entrées à deux niveaux:

• Accès aux événements standard: ICON peut être contrôlé par des événements standard, à travers des dispositifs qui lisent dans la file d'événements du système d'exploitation ou de la boîte à outils. Ces derniers possèdent l'avantage d'être portables d'une plate-forme à une autre. Le dispositif clavier de Swing (voir section 4.2.1) en est un exemple.
• Accès bas niveau aux dispositifs: ICON accède principalement aux dispositifs d'entrée au niveau bas, ce qui permet de tirer parti des spécificités des dispositifs non conventionnels, mais également de celles des dispositifs standard. Ainsi, un dispositif de souris bas-niveau peut émettre des données positionnelles non contraintes aux bords de l'écran (voir section 4.2.1).

ICON peut contrôler une application interactive de quatre manières différentes. Les niveaux de contrôle d'une application, du plus superficiel au plus profond, sont les suivants:

• Le contrôle par défaut: Ce niveau désigne le contrôle d'une application « hors ICON ». ICON permet de conserver la gestion des entrées effectuée implicitement au niveau système et boîte à outils, et de l'étendre ou non avec des interactions décrites explicitement. Par exemple, une application de modélisation 3D conventionnelle peut être étendue pour prendre en compte la manipulation 3D avec des dispositifs dédiés. Les différents mécanismes standard de gestion des entrées peuvent également être désactivés (voir section 4.2.3) pour être redéfinis de façon explicite ou être remplacés par des techniques d'interaction alternatives.
• Le contrôle générique de surface: Ce niveau désigne les stratégies de contrôle positionnel générique des widgets de la boîte à outils, à travers des dispositifs manipulateurs de surface (section 4.2.3). C'est à ce niveau que peuvent être explicitement redéfinies des techniques d'interaction standard telles que le picking. Certaines configurations décrites dans notre chapitre sur la boîte à outils ICON constituent des exemples de contrôle générique de surface: le contrôle positionnel standard des composants Swing (figure 4.18), le contrôle au clavier du focus et du clic (figure 4.20), et l'interaction Swing avec des pointeurs multiples (figure 4.22).
• Le contrôle générique de modèle: Ce niveau comprend les stratégies de contrôle spécifiques à un type de widget, décrites à travers des dispositifs manipulateurs de modèle (section 4.2.3). Avec le niveau précédent, il permet de spécifier des stratégies d'accessibilité génériques compatibles avec les applications existantes. Le contrôle de modèle est générique en ce sens qu'il n'est pas dédié à une application particulière, mais il est cependant plus spécifique que le précédent, car il décrit des interactions avec une classe de widget donnée. La configuration de la figure 4.27, qui décrit le contrôle des barres de défilement à la voix, en est un exemple. Le contrôle d'une interface zoomable (figure 4.25) est un exemple d'utilisation de manipulateurs de modèle dans une boîte à outils graphique non conventionnelle.
• Le contrôle dédié: Ce niveau décrit le contrôle d'une application interactive à travers des dispositifs d'application. C'est le niveau de contrôle le plus puissant, car il permet de décrire des techniques d'interaction dédiées à la tâche. Il ne concerne cependant que les applications qui ont été développées pour être compatibles avec ICON, ou des applications qui ont été modifiées dans ce sens. Les dispositifs d'application sont en principe spécifiques à une application donnée, mais il est également possible d'imaginer des librairies de dispositifs réutilisables adaptés à un type particulier d'application. ICONDraw est un exemple d'application qui supporte le contrôle dédié comme le dessin à la tablette graphique (figure 4.24).

5.2.3 Une gestion des entrées entièrement explicite

Nous avons vu qu'ICON permettait de court-circuiter une bonne partie des services du système d'exploitation et de la boîte à outils afin de gérer la quasi-totalité de l'interaction en entrée. Cette dernière option est la plus avantageuse car elle remplace l'ensemble des boîtes noires standard par une boîte blanche hautement configurable.

Figure: La cascade de traitements dans un système interactif classique, vue de l'application. Le dispositif concret n'a pas d'existence, et les traitements bas-niveau sont cachés.

La figure 5.3 reprend l'exemple de la gestion standard du clavier initialement introduit dans la section 3.2.5 [Fekete and Dragicevic, 2000]. Certaines fonctionnalités comme la répétition des touches, la mémoire tampon, et la gestion des voyants n'ont pas été mis en évidence dans cette exemple, mais celui-ci reproduit néanmoins les principaux mécanismes de gestion du clavier présents dans tous les systèmes interactifs existants. Comme évoqué précédemment, la gestion des entrées est répartie entre différents acteurs, de l'électronique du dispositif jusqu'à l'application.

Si une grande partie de la gestion des dispositifs d'entrée dans les systèmes interactifs actuels peut être décrite par de telles cascades de dispositifs, cette structuration est toujours implicite: les adaptateurs ne sont pas toujours bien distincts, les tâches de traitement sont disséminées à travers différentes couches étanches, et il n'existe finalement pas de mécanisme fournissant une vision globale de la chaîne complète de ces traitements. Bien que les systèmes d'exploitation produisent parfois des données à plusieurs niveaux d'abstraction pour répondre aux besoins des applications et des boîtes à outils (par exemple, symbole ou code touche en plus du caractère), la partie bas-niveau des traitements relatifs à un dispositif concret est entièrement cachée, ce qui restreint considérablement le champ d'action du développeur (figure 5.3).

Figure: Les différents niveaux d'abstraction du clavier, explicités par la cascade de dispositifs.

À l'inverse, ICON est capable d'exposer de façon explicite le dispositif physique^5.1 et tous les traitements effectués en amont. Chez le développeur, la vision synthétique et événementielle d'un dispositif d'entrée est alors remplacée par une vision à niveaux multiples. Le niveau le plus bas est le dispositif concret: le clavier concret est une boîte à boutons, chacun de ces boutons comportant deux états. Cette vision mécanique du clavier est celle qu'expérimente l'utilisateur. Ensuite, chaque adaptateur supplémentaire joue le rôle d'un opérateur logique qui transforme successivement un clavier concret en clavier spatial, puis symbolique, et enfin textuel (figure 5.4). Selon ses besoins, l'application peut se greffer à chacun de ces niveaux: un clavier textuel est pertinent pour une application de traitement de texte, mais un clavier plus bas niveau est mieux adapté à des actions telles que le déplacement d'un curseur (figure 5.4). Il est en outre évident qu'une telle modularité procure une configurabilité bien plus importante.