6.4 ICON: une solution pour l'adaptabilité en entrée

ICON est 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 introduit 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.

Figure 6.1: Un dispositif ICON avec ses slots d'entrées (à gauche) et ses slots de sortie (à droite).

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'environnement 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 dispositif 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 vocale, 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, «toolglass» 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'application.

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). Un ensemble 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écomposé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.

Figure 6.2: Une configuration d'entrée décrit une manière de relier des dispositifs système à des dispositifs d'application.

Ce modèle d'exécution, inspiré des langages réactifs impératifs, est basé sur le principe du synchronisme parfait [Berry2000], modèle dans lequel les processus sont capables au niveau conceptuel 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 [Dragicevic2004b,Dragicevic et Fekete2004] ou de l'association de son système avec une approche orientée contrôle [Dragicevic et al.2004].

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

L'éditeur graphique (voir figure 6.3) permet de mettre en correspondance les périphériques d'entrée et l'application de manière interactive. Les périphériques d'entrée disponibles sur le système ainsi que tous les dispositifs de la bibliothèque d'ICON sont organisés par dossiers et présentés sur un panneau. 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 d'interaction prédéfinies (par exemple, le dispositif de reconnaissance de geste est conçu pour être inséré entre un dispositif de pointage et un dispositif recevant du texte en entrée) aussi bien que la description de nouvelles techniques par la combinaison de dispositifs de traitement plus simples.

Figure 6.3: Input Configurator. Le configurateur graphique d'ICON.

6.4.3 Niveau de contrôle des applications avec ICON

Pierre DRAGCEVIC a définit les différents niveaux de contrôle possible des applications avec le modèle ICOM:

1. Le contrôle par défaut, niveau de contrôle par défaut d'une application «hors ICON», en conservant la gestion des entrées effectuée implicitement au niveau système et boîte à outil, et en l'étendant ou non.
2. Le contrôle générique de surface, stratégie de contrôle positionnel des widgets de boîte à outils, à son niveau le plus haut (sélection de widgets, focus, clic par exemple).
3. Le contrôle générique de modèle, stratégie de contrôle spécifique à un type de widget, décrivant les interactions avec une classe de widget existante (pouvant donc court-circuiter les méthodes d'entrée de la boîte à outils).
4. Le contrôle dédié, la stratégie la plus puissante décrivant le contrôle complet d'une application par des dispositif d'application dédiés.

Il a aussi introduit la notion de «dispositifs de boîte à outil graphique, situés à mi-chemin entre la catégorie des dispositifs utilitaires et celle des dispositifs d'application, (ils) permettent un contrôle générique de ces dernières» [Dragicevic2004b]. Les dispositifs réalisés alors ont permis le contrôle de surface et le contrôle de modèle avec des boîte à outils comme Swing ou Jazz. Par contre, atteindre le contrôle dédié nécessite de développer des applications prévues pour et d'externaliser leurs outils sous la forme de dispositifs d'application.

Fort de ce modèle réactif, d'une bibliothèque étendue et extensible de dispositifs, et d'un configurateur graphique, ICON permet de décrire de façon homogène la chaîne de gestion des entrées des périphériques jusqu'à l'application, avec un grand pouvoir d'expression (des interactions les plus standards aux plus avancées). En outre, ce paradigme implique un haut niveau de configurabilité des applications, renforcé par sa réalisation dynamique qui permet la définition des configurations d'entrée à l'exécution de l'application. C'est ainsi une première réponse aux problèmes que nous avons soulevés dans ce chapitre: permettre l'utilisation de dispositifs d'entrée non standard et de techniques d'interactions avancées dans un même environnement, tout en offrant des outils de configuration interactifs et dynamiques.