ICON permet de spécifier des techniques d'interaction en termes de configurations d'entrée, mais ne décrit pas précisément comment ces configurations doivent être décomposées en dispositifs, ni la façon dont ces dispositifs doivent être décomposés en slots. Nous avons en partie répondu à cette question dans le chapitre précédent par de nombreux exemples de dispositifs et de configurations. Dans ICON, la plupart des choix de conception restent cependant à la charge du développeur.
Le dispositif est la brique de base dans ICON, et il est essentiel de se demander ce qui le caractérise et ce qu'il représente. Du point de vue des entrées, la plupart des dispositifs physiques sont des objets autonomes dont les parties constituantes sont indissociables: faire correspondre à un dispositif physique un dispositif dans ICON est par conséquent une bonne approximation. La décomposition d'une application en dispositifs d'application est cependant moins triviale, et les choix relatifs à cette décomposition incombent au programmeur d'application. La décomposition d'une configuration d'entrée en techniques d'interaction pose également la question du bon niveau de granularité.
Dans cette section, nous définissons plus précisément les rôles et les fonctions des dispositifs système d'entrée, des dispositifs de boîte à outils et d'application, et des dispositifs utilitaires. Nous décrivons notamment les services que ces dispositifs, et en particulier les dispositifs d'application et de boîte à outils, sont sensés fournir. Nous énumérons également les difficultés que le programmeur peut rencontrer pour décrire correctement ces dispositifs, et proposons des directives d'implémentation permettant de guider le développement de nouveaux dispositifs.
Un dispositif d'entrée ICON est un dispositif système qui décrit un périphérique utilisateur physique. En pratique, le rôle des dispositifs d'entrée dans ICON est de fournir une vue unifiée et bas-niveau des dispositifs décrits par les diverses APIs d'entrée.
L'implémentation de dispositifs système d'entrée peut poser un certain nombre de difficultés, que nous décrivons par la suite.
Le modèle de chaque dispositif système (structure et nom des slots, en particulier) sera intimement lié à l'API sur lequel il repose, et sur les choix qui y auront été faits. Les APIs existantes étant assez hétérogènes, deux dispositifs système représentant le même dispositif physique mais provenant d'APIs différentes pourront ainsi avoir une structure toute différente. En particulier, il n'existe pas de convention de nommage pour les slots.
L'hétérogénéité des APIs n'est cependant pas limitative dans le sens où ICON ne nécessite ni abstraction ni sémantique dans son modèle de configurations. Un utilisateur d'ICON a simplement besoin de voir apparaître les dispositifs concrets dont il dispose, et d'être capable d'identifier ces dispositifs et la sémantique de leurs canaux. Cette identification repose uniquement sur le choix (en général judicieux) des noms (nom du dispositif, nom de ses canaux) faits par les fabricants des dispositifs et de pilotes.
Le problème de la réutilisabilité des configurations d'entrée d'un système à l'autre sera abordé plus loin dans cette discussion (section 5.6.3). Enfin, notons que le problème de l'hétérogénéité pourrait être en partie résolu par l'emploi exclusif d'une API « universelle » telle que le USB Human Interface Device [USB/HID, 2001].
Il existe à proprement parler au moins trois niveaux « bas » : le bas-niveau logique (données numériques en provenance du pilote de dispositif), le bas-niveau électronique (les signaux électroniques) et le bas-niveau physique (ou mécanique). Ce dernier est le plus pertinent, car il est en contact direct avec l'utilisateur, et contribue le plus à l'image mentale que celui-ci se fait du dispositif et de ses actions sur celui-ci. Or les APIs d'entrée se situent au mieux au niveau logique, c'est-à-dire au plus bas niveau logiciel. Et il n'existe pas nécessairement de correspondance directe entre ce niveau logique et le modèle physique du dispositif.
Non seulement une modélisation très bas-niveau n'est pas toujours réalisable, mais elle n'est pas non plus adaptée à tous les contextes d'utilisation. À titre d'exemple, un clavier devra apparaître comme un ensemble de slots booléens (un slot par touche) pour être fidèle à son modèle physique. Cette structure est pertinente lorsque l'on doit s'intéresser à un ensemble restreint de touches (touches fléchées, par exemple). Mais elle devient trop lourde lorsque l'on doit appliquer un filtre à l'ensemble du clavier, car elle nécessite de connecter chaque touche parmi les centaines existantes. L'utilisation de données sérialisées à base de codes touches peut s'avérer nécessaire.
Ces considérations nous amènent à définir trois propriétés souhaitables pour les dispositifs d'entrée, propriétés qui doivent guider les programmeurs:
Abstraction physique: Les slots qui décrivent le dispositif doivent être choisis et structurés en fonction des caractéristiques physiques de ce dispositif. Les données qui proviennent de ces canaux doivent être brutes, ou subir des transformations sans perte si elles ne coïncident pas avec le modèle physique du dispositif.
Redondance: Si le besoin s'en fait sentir, il peut être nécessaire de fournir des manières alternatives d'accéder aux données du dispositif, par des slots supplémentaires de plus haut niveau (valeurs absolues en plus de relatives, informations synthétiques sur plusieurs canaux, etc.).
Paramétrisation: Si le besoin s'en fait sentir, il peut également être nécessaire de définir des comportements alternatifs pour un même dispositif. Les traitements de données qui implémentent ces comportements seront bien identifiés et choisis par l'utilisateur dans les paramètres du dispositif.
Le rôle principal des dispositifs d'application et de boîte à outils est de fournir des points d'entrée: pour les premiers, il s'agira d'exposer une interface de contrôle pour une application donnée et de prendre en charge ce contrôle. Pour les seconds, il s'agira d'exposer une interface de contrôle générique pour l'ensemble des applications qui reposent sur la même boîte à outils graphique.
Une autre fonction de ces dispositifs est de fournir des points de retour. Ces derniers sont concrétisés par des dispositifs comportant des entrées implicites et produisant des sorties, et qui peuvent être employés pour effectuer des requêtes vers l'application ou la boîte à outils. Les sélecteurs de Swing comme le pick, décrits dans le chapitre précédent, sont des exemples de tels dispositifs.
Dans la suite, nous décrivons un ensemble minimal de services utiles que pourraient fournir à ICON les applications et les boîtes à outils, sous forme de points d'entrée et de retour.
Jean-Daniel Fekete [Fekete, 1996a] a identifié trois services du noyau sémantique indispensables à l'interaction: la notification, la prévention des erreurs, et l'annulation. Ces trois services, s'ils sont pris en charge par l'application, peuvent être externalisés sous forme de points d'entrée ou de points de retour:
La notification et l'annulation sont deux services qui peuvent également être fournis à travers les boîtes à outils graphiques. Voici les autres services de boîtes à outils graphiques susceptibles d'être employés dans les configurations:
Des dispositifs d'application peuvent être développés pour tout type d'application interactive. Il n'existe pas de modèle générique pour ces dispositifs, chaque développeur devant déterminer quel modèle est pertinent pour son application spécifique. Bien que des modèles génériques adaptés à des types particuliers d'application (dessin, traitement de texte, modélisation 3D) puissent être susceptibles de guider les développeurs dans l'implémentation des dispositifs d'application, il est bon de rester à l'écart des modèles simplificateurs et garder l'accent sur l'aspect hautement spécifique des tâches propres à chaque application interactive.
Les objets d'application ne sont pas toujours aussi bien délimités que les dispositifs physiques. En particulier, les développeurs peuvent hésiter devant le niveau de granularité à adopter. Ainsi, chaque commande d'une application (les commandes de menus, par exemple) peut être individuellement exposée sous forme de dispositif, ou toutes ces commandes peuvent être regroupées dans un dispositif plus grand. En outre, les programmeurs peuvent choisir ou non d'exposer certains objets ou mécanismes, selon le degré de configurabilité qu'ils désirent atteindre, et l'effort qu'ils comptent y consacrer.
Nous avons déjà décrit dans le chapitre précédent une taxonomie orientée-objet des dispositifs d'application, utile pour guider les choix: les dispositifs de classe, les dispositifs d'instance statiques et les dispositifs d'instance dynamiques (voir section 4.2.4). Des exemples de dispositifs d'instance dynamiques sont les outils de dessin d'ICONDraw: chaque dispositif employé dans la configuration crée une instance dans l'application. Les manipulateurs de Swing, en revanche, sont des dispositifs de classe, qui opèrent sur des instances variables de la même classe.
Une fois les points d'entrée identifiés, il convient de les décrire correctement. Cette opération comporte des difficultés similaires à celles que nous avons déjà évoqué pour les dispositifs d'entrée. Nous avons par exemple constaté, chez les débutants en développement ICON, des difficultés à appréhender la notion d'« indépendance par rapport aux entrées », difficultés qui ont été à la source d'erreurs de conception. Pour cette raison, il n'est pas inutile de guider les développeurs en leur fournissant, comme nous l'avons fait avec pour dispositifs d'entrée, des directives d'implémentation une fois que les objets à exposer ont été clairement identifiés:
Abstraction applicative: Les slots qui décrivent le dispositif doivent être choisis et structurés en fonction des caractéristiques de l'objet applicatif et uniquement celui-ci. L'objectif qu'il faut garder à l'esprit est l'indépendance par rapport aux entrées: le dispositif doit être construit sans préjugé sur la façon dont il sera contrôlé.
Redondance et paramétrisation: En fonction des utilisations envisagées, et tout comme avec les dispositifs système, il peut s'avérer nécessaire de fournir plusieurs manières de contrôler un dispositif d'application ou de le rendre paramétrable. Une valeur numérique pourra par exemple être contrôlée soit par affectation, soit par incrémentation/décrémentation.
Le rôle des dispositifs utilitaires est de permettre de connecter à travers des transformations de données et du feedback un ensemble de dispositifs d'entrée à un ensemble de dispositifs d'application. Ces dispositifs sont à la fois des adaptateurs et des techniques d'interaction, et peuvent être composés pour former des adaptateurs et des techniques d'interaction plus complexes.
C'est au niveau des dispositifs utilitaires que le problème de la décomposition est le moins trivial. Même si les dispositifs d'ICON sont composables, et qu'il est donc possible de décrire des comportements sur plusieurs niveaux d'abstraction, il convient de choisir jusqu'où s'arrête cette décomposition. Autrement dit, quelle doit être la granularité des dispositifs atomiques ?
Bien que séduisante, la démarche consistant à fournir un ensemble de dispositifs de fonctionnalité minimale qui soit suffisant pour décrire n'importe quelle technique d'interaction est critiquable du point de vue pratique: d'abord, il n'est pas évident de déterminer à priori cet ensemble minimal. Ensuite, la description graphique de comportements complexes peut se révéler rapidement pénible, comme nous l'avons vu dans notre discussion sur la complexité visuelle.
Aussi, nous pensons qu'il est essentiel de pouvoir disposer d'une bibliothèque de dispositifs mathématiques et logiques simples, mais également d'une bibliothèque évolutive d'adaptateurs monolithiques de complexité variable. L'utilisateur a ainsi la possibilité de manipuler et d'implémenter des techniques d'interaction à part entière, de composer des adaptateurs de complexité moyenne, et d'utiliser des dispositifs minimaux là où les outils existants font défaut. Nous avons déjà donné des exemples de ces différentes approches dans la section 4.4.4.