Dans cette section, nous analysons sous un angle pragmatique la pertinence de notre approche du point de vue du développeur d'applications. Nous en avons déjà abordé un aspect en faisant état des difficultés relatives aux choix de conception. Ici, nous commençons par déterminer en quoi ICON induit une nouvelle façon de programmer l'interaction, et énumérons les concepts auxquels doivent s'habituer les programmeurs ayant jusque-là employé des outils conventionnels. Puis, nous décrivons dans quelle mesure et avec quelle facilité ICON peut être employé avec des boîtes à outils graphiques et des applications existantes. D'autres considérations pratiques sont ensuite abordées, à savoir la réutilisabilité des configurations, la prise en charge effective des dispositifs d'entrée physiques, et enfin les questions de performance.
L'implémentation de dispositifs ICON est relativement simple en soi, car comme nous l'avons vu dans la section 4.3.1, elle consiste essentiellement à déclarer des slots puis à spécifier les actions à effectuer lorsque la valeur d'un slot d'entrée a changé (ou plus exactement, lorsque celui-ci a reçu a signal). Il peut exister néanmoins des difficultés qui découlent d'un style de programmation différent des outils habituels. Nous énumérons ici les principaux paradigmes et concepts pouvant poser problème, en évoquant notamment les erreurs-type déduites de l'observation et du suivi de deux programmeurs ayant employé ICON pour développer une application (voir section 4.5). Nous commençons par un concept essentiel dans ICON, à savoir l'indépendance par rapport aux entrées. Puis, nous évoquons trois notions « exotiques » découlant de notre modèle d'exécution, à savoir la réactivité, la simultanéité et le déterminisme. Enfin, nous décrivons les problèmes liés à l'utilisation d'objets dans les configurations d'entrée.
L'indépendance par rapport aux entrées: Nous avons déjà constaté dans une discussion précédente que les développeurs habitués aux boîtes à outils conventionnelles avaient quelques difficultés à maîtriser la philosophie d'« indépendance par rapport aux entrées ». Dans ICON, cette philosophie impose que les dispositifs soient construits sans préjugé sur la façon dont ils seront contrôlés. Or, il est courant de constater des erreurs consistant à déclarer des dispositifs d'application qui comportent, à titre d'exemple, des slots d'entrée nommés shift ou mouseClick. Une autre erreur typique consiste à implémenter dans l'application, ou dans le dispositif d'application, des mécanismes qui sont en réalité des techniques d'interaction, et qu'il est nettement préférable de décrire dans la configuration d'entrée. Par exemple, un dispositif d'application est déclaré avec un slot sélectionner, qui sélectionne un dossier lorsque sa valeur passe de faux à vrai ou alors ouvre celui-ci lorsqu'il passe deux fois de faux à vrai dans un intervalle de temps assez court. Il s'agit d'un comportement modal de type double-clic, qui constitue une technique d'interaction et doit être décrit à l'extérieur du dispositif d'application. Si ce type d'erreur est facile à comprendre, la limite entre ce qui doit être décrit dans ICON et ce qui doit être décrit dans l'application n'est pas toujours triviale.
La réactivité: La programmation réactive est un paradigme peu connu des programmeurs utilisant des langages impératifs, et certains de ses concepts comme le temps de propagation nul peuvent leur paraître difficiles à appréhender. Cependant, ni l'utilisateur de l'éditeur interactif ni le programmeur n'ont à se soucier de ces concepts, car ICON gère intégralement et de façon transparente la propagation de l'information entre les dispositifs. Le modèle réactif impose cependant des contraintes sur le temps d'exécution de chaque dispositif (méthode update()). Des erreurs courantes consistent à effectuer, dans cette méthode, des initialisations lourdes au lieu de les placer dans la méthode open(), à effectuer des opérations qui réclament du temps (gros calculs ou routines graphiques) au lieu de les lancer dans un fil d'exécution séparé, ou à créer des objets à chaque tick là où ce n'est pas indispensable. Dans ce dernier cas, et bien que la distinction puisse être subtile, il convient de différentier les créations discontinues d'objets (par exemple, créer un objet à chaque clic) des créations continues (par exemple, créer un objet à chaque mouvement de la souris) qui alourdissent l'exécution et occupent rapidement la mémoire.
La simultanéité et la gestion des états: Une autre caractéristique d'ICON découlant de son modèle réactif est la notion de simultanéité. La simultanéité est absente de la programmation événementielle classique, où les événements sont traités séquentiellement en fonction de leur ordre d'arrivée dans la file. Dans le modèle réactif d'ICON, il est fréquent que plusieurs signaux arrivent au même moment dans différents slots d'un dispositif d'entrée (ils peuvent également arriver dans le désordre). L'ordre dans lequel ces signaux sont traités a alors son importance. Par exemple, le dispositif de dessin à main levé d'ICONDraw (voir section 4.2.4) comporte un mode « utilisé » dans lequel il dessine et un mode « non utilisé » dans lequel il anime simplement une brosse. La position de la brosse est contrôlée par les slots x et y, et le changement de mode est déterminé par le slot use. Pour ce dispositif, il convient de vérifier si le slot use a reçu un signal avant de traiter les valeurs x et y. La simultanéité complique généralement la gestion des modes et des états, car diverses combinaisons possibles de signaux doivent être prises en compte, y compris les combinaisons contradictoires (par exemple, un signal vrai est reçu simultanément sur des slots on et off). En outre, les choix qui sont faits n'apparaissent pas à l'extérieur du dispositif, si ce n'est à travers sa documentation. C'est pourquoi nous pensons que la programmation de certains dispositifs dans ICON gagnerait à reposer sur des outils adaptés, idée qui sera développée dans la section 5.8.1.
Déterminisme et non-déterminisme: ICON fait la distinction entre déterminisme et non-déterminisme, autres concepts auxquels un développeur n'est pas nécessairement habitué. Les dispositifs non-déterministes sont simplement des dispositifs qui emploient des informations en provenance de l'environnement, système qui englobe tout ce qui ne fait pas partie de la configuration d'entrée. Nous disons dans ICON qu'ils comportent des entrées implicites (voir section 3.4). Par ailleurs, nous disons d'un dispositif qui modifie l'environnement qu'il comporte des sorties implicites. ICON ne déduit pas automatiquement la présence d'entrées/sorties implicites, et le développeur du dispositif doit explicitement les déclarer en dérivant les deux accesseurs booléens correspondants. Cette opération, bien que simple, peut être facilement omise par le programmeur. Elle est pourtant indispensable car premièrement, un dispositif non-déterministe est traité différemment par la machine réactive: celui-ci est activé à chaque tick afin qu'il puisse, même en l'absence de signaux d'entrée, surveiller l'évolution de l'environnement et éventuellement transmettre des valeurs en sortie. Ensuite, la présence d'entrées et de sorties implicites est une information qui contribue à une bonne compréhension d'une configuration d'entrée, car elle permet de voir clairement à quels endroits cette dernière communique avec l'extérieur (utilisateur et application notamment).
Manipuler des objets dans les configurations d'entrée: Une configuration d'entrée opère sur des types primitifs, structurés ou non, tels que des entiers ou des booléens. La manipulation d'objets y est également possible grâce aux slots de type object, mais celle-ci requiert toutefois certaines précautions. Il existe trois principales manières d'employer des objets dans les configurations d'entrée: la transmission de références, la création d'objets et la manipulation d'objets. La transmission de références consiste à transmettre d'un dispositif à l'autre des références à des objets qui proviennent initialement de l'environnement. Les dispositifs sélecteurs/manipulateurs, illustrés notamment par la technique du pick, constituent un exemple de cette utilisation (voir section 4.2.3). Cet emploi ne pose aucun problème. La création d'objets consiste à créer des objets au sein d'un dispositif avant de les passer par référence. La création d'objets ne pose pas de problème tant qu'elle ne nuit pas à l'hypothèse réactive (voir la discussion précédente). Plus problématique est la manipulation d'objets qui consiste, au sein des dispositifs, à lire ou à écrire dans les objets transmis. Ces opérations peuvent en effet engendrer des dépendances cachées entre les dispositifs et rendre une configuration d'entrée implicitement non-déterministe. C'est le cas par exemple de la configuration de la figure 5.10. Lorsque c'est possible, il est toujours préférable de composer des slots primitifs plutôt que d'employer des objets, car les flux d'information et la structure des données manipulées y sont explicites. Dans le cas contraire, tout objet lu ou modifié doit être considéré comme faisant partie de l'environnement, et les dispositifs concernés déclarés comme ayant des entrées et/ou des sorties implicites.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{objets_conf}
\end{center}
\end{figure}](img210.png) |
Les boîtes à outils graphiques gèrent les entrées sans les séparer clairement de l'aspect graphique. À l'inverse, ICON ne s'occupe que du premier aspect, et laisse le second aux boîtes à outils graphiques. Il peut par conséquent fonctionner avec plusieurs d'entre elles. Pour l'heure, ICON fournit les dispositifs minimaux pour l'interaction avec les applications Swing, ainsi qu'une prise en charge expérimentale des applications Jazz. À l'avenir, la bibliothèque de dispositifs pourra être enrichie d'autres dispositifs de boîte à outils. Rappelons cependant qu'une application peut être contrôlée indépendamment de la boîte à outils graphique sur laquelle elle repose, avec des dispositifs d'application décrits par le programmeur.
Des applications non-java peuvent également être contrôlées avec ICON. Plusieurs stratégies sont possibles: une interface de communication externe peut être définie dans l'application (un protocole réseau, par exemple), et des dispositifs ICON qui implémentent cette interface peuvent être ajoutés à la bibliothèque. Une application interactive existante peut également être contrôlée sans modification de son code, lorsque celle-ci implémente déjà un protocole bien défini. Nous avons ainsi pu contrôler l'application Microsoft Word (zoom du document, commandes telles que le copier/coller) en implémentant un dispositif qui s'appuie sur le protocole COM (Component Object Model).
Ce type de contrôle a cependant pour inconvénient la perte du feedback graphique et du court-circuitage de la gestion événementielle standard, car dans la version actuelle d'ICON ces fonctionnalités sont implémentées par des dispositifs de la boîte à outils Swing. Néanmoins, ces deux aspects sont conceptuellement indépendants de la boîte à outils. Un feedback graphique peut être implémenté au niveau système, à condition que celui-ci fournisse les services graphiques nécessaires comme l'incrustation et la transparence. De même, dans la mesure où le système d'exploitation le permet, les événements standard peuvent être interceptés à leur source.
Le problème principal posé par la connexion d'ICON avec des boîtes à outils graphiques ou des applications existantes est qu'elle requiert une coopération minimale de ces dernières: leur contrôlabilité repose fortement sur les services qu'elles sont capables de fournir (les services utiles ont été décrits dans la section 5.5.2), mais également sur une gestion fine et correcte des modifications concurrentes. Swing, par exemple, est capable d'exposer ses widgets à deux niveaux: un niveau modèle spécifique au widget, et un niveau événementiel générique. Les modèles sont exposés avec le niveau de détail qui convient, et gèrent parfaitement la concurrence. Le niveau événementiel, sur lequel reposent les techniques de contrôle de surface comme le contrôle multi-pointeurs, comporte cependant quelques faiblesses.
Premièrement, chaque widget Swing gère ses propres événements positionnels et peut donc être contrôlé indépendamment, mais certains liens implicites entre ces widgets induisent des comportements inappropriés lors d'un contrôle multi-pointeurs: par exemple, cliquer sur un widget avec un pointeur fermera un menu ouvert par un autre pointeur. Ce type de mode global trahit une gestion incomplète et câblée de l'interaction concurrente.
Deuxièmement, il n'est pas surprenant de constater qu'un widget Swing est incapable de gérer deux flux d'événements positionnels (par exemple, deux drags simultanés): la granularité du contrôle de surface se limite donc à celle du widget, ce qui est principalement gênant pour de gros widgets. Une liste, par exemple, est gérée comme un seul widget et non comme un ensemble d'éléments. Une barre de défilement constitue également un widget monolithique.
Plusieurs stratégies peuvent être envisagées pour résoudre ce problème. Nous
avons déjà proposé une façon de modifier les boîtes à outils existantes en
substituant à l'architecture M[V+C] [Fowler, 1999] une architecture
[Dragicevic and Fekete, 1999,Fekete and Dragicevic, 2000]. Cette dernière permet de rendre les
widgets à nouveau modulaires en éliminant la gestion des entrées dans
[V+C] et en la remplaçant par un protocole générique permettant de
manipuler individuellement chacune des zones manipulables du widget (figure
5.11, image de gauche). L'objet [V+C] est ainsi remplacé par
l'objet 
(Vue/Zones/Manipulateurs), qui au lieu de recevoir les
événements d'entrée est manipulé par un ou plusieurs contrôleurs de vue.
Le modèle est, quant à lui, directement manipulé par des contrôleurs de
modèle (figure 5.11, image de droite).
![\begin{figure}
\begin{center}
\includegraphics[scale=0.38]{vzm}
\end{center}
\end{figure}](img212.png) |
L'avantage de l'architecture est qu'elle permet de conserver la
structure en classes de widgets d'une boîte à outils existante. Nous avons
étendu plusieurs widgets Swing avec cette architecture et montré comment ils
pouvaient être efficacement contrôlés avec des pointeurs multiples
[Dragicevic and Fekete, 1999]. Cependant ces extensions nécessitent de modifier la machine
virtuelle Java, et en particulier de remanier les sources de Swing, qui ne sont
pas un modèle de clarté ni de maintenabilité. Nous étudions actuellement une
autre approche consistant à exploiter des boîtes à outils graphiques Java
employant un modèle graphique structuré comme Jazz [Bederson et al., 2000] ou
Piccolo [Bederson, 2003] afin de contrôler les applications à l'échelle de la
forme géométrique (voir également les projets liés à ICON dans la section
4.5).
Il est essentiel pour le programmeur d'applications que les configurations qu'il décrit soient réutilisables. Tout d'abord, elles doivent pouvoir être chargées et exécutées sur d'autres systèmes que le sien. Ensuite, le fait de pouvoir réutiliser des configurations ou des parties de configurations d'une application à l'autre faciliterait la tâche du programmeur, mais garantirait également à l'utilisateur une certaine cohérence de l'interaction entre les diverses applications compatibles ICON.
Les systèmes interactifs traditionnels garantissent la compatibilité matérielle par des mécanismes d'abstraction: les pilotes de dispositifs se chargent de fournir une abstraction connue du matériel spécifique connecté à l'ordinateur. Notre approche place le problème de la réutilisabilité au second plan au profit d'outils permettant à chaque utilisateur de configurer au mieux l'interaction avec son propre matériel. De ce fait, afin d'exploiter au mieux les spécificités de chaque dispositif, ICON n'emploie pas d'abstractions ad-hoc comme les classes prédéfinies de dispositifs. Dans ICON, chaque dispositif (marque, modèle) étant distinct des autres, il n'y a pas notion de dispositifs « compatibles ».
Pour pouvoir partager les configurations, nous avons cependant intégré dans ICON un mécanisme de sérialisation et désérialisation de dispositifs extrêmement souple basé sur les descripteurs (section 4.3.3). Ce mécanisme permet en fonction des besoins de définir des « classes » de dispositifs interchangeables à l'aide d'un langage nommé ICSCRIPT, afin de permettre à ICON, lors du chargement de la configuration, de rechercher le dispositif qui convient le mieux parmi ceux présents. Simple mais puissant, ce langage autorise notamment les descriptions incomplètes et leur composition logique. En outre, il permet de définir des descripteurs plus ou moins stricts, ce qui est, comme nous l'avons vu dans la section 4.3.3, d'importance capitale car si une configuration destinée à la distribution se doit d'être tolérante sur la définition d'un dispositif d'entrée, sur un système multi-dispositifs donné il est important de retrouver les mêmes dispositifs d'une session à l'autre.
Le mécanisme de descripteurs d'ICON comporte toutefois encore certaines limites: par exemple, il permet de décrire des équivalences sémantiques entre slots de noms différents (par exemple, « le slot stylus sur une tablette Wintab correspond au slot button1 sur une souris DirectInput ») mais ne permet pas d'apparier des types de données incompatibles (par exemple, « les slots dx et dy de la souris plus une conversion en coordonnées absolues peuvent être substitués aux slots x et y de la tablette »). Actuellement, il est nécessaire de traiter les différents cas dans des configurations séparées. Une autre faiblesse de ces mécanismes est qu'ils reposent sur une description logique des dispositifs d'entrée qui ignore la plupart des propriétés intrinsèques des dispositifs dont Buxton a suffisamment souligné l'importance (voir la section 1.2.1). Intégrer au niveau logiciel un modèle pragmatique des entrées comme celui de Buxton est un problème qui n'a à ce jour pas été résolu.
Dans les systèmes interactifs traditionnels, les techniques d'interaction standard (pointage, menus, widgets, etc.) sont réutilisables d'une application à l'autre et surtout, offrent une cohérence globale dans l'interface utilisateur. Dans ICON, le développeur de chaque application est libre de décrire les techniques d'interaction qu'il souhaite. L'avantage est bien sûr de pouvoir employer des interactions dédiées à la tâche, mais la réutilisabilité inter-applications reste un critère essentiel pour le programmeur et les utilisateurs.
ICON autorise à travers son modèle modulaire une certaine cohérence dans les techniques d'interaction. Plusieurs configurations d'entrée peuvent ainsi reposer sur les mêmes mécanismes de base déjà décrits par les dispositifs utilitaires. En outre, les techniques d'interaction « clé en main » peuvent être facilement réemployées d'une application à l'autre. La façon dont ces techniques sont composées et exploitées dans une application peut varier cependant, et des techniques totalement inédites peuvent facilement être décrites. ICON ne propose pas de modèle haut-niveau pour structurer l'interaction, et est en outre indifférent quant aux conventions employées (par exemple, la sémantique du bouton droit de la souris). La cohérence de l'interaction d'une application à l'autre reste donc un problème, et si les développeurs d'applications peuvent s'inspirer des conventions usuelles de la plupart des configurations reposant sur des dispositifs standard, les conventions relatives à l'interaction post-WIMP sont encore inexistantes.
Enfin, est-il possible de fournir des configurations d'entrée qui fonctionnent dans toutes les applications ? La réutilisabilité stricte des configurations d'entrée suppose une abstraction partagée par toutes les applications interactives. Les dispositifs de boîte à outils graphique fournissent un tel niveau de réutilisabilité, car ils permettent de contrôler l'ensemble des applications reposant sur la même boîte à outils. Bien que ce contrôle se fasse par compatibilité, des interactions non standard peuvent néanmoins être décrites, et il est possible par exemple de proposer des configurations d'accessibilité génériques5.5. En outre, des boîtes à outils graphiques évoluées comme Jazz permettent de décrire des techniques d'interaction génériques encore plus sophistiquées.
Malgré tout, le principe de configuration générique est incompatible avec celui de l'interaction dédiée à la tâche, et seuls des modèles d'application spécifiques permettront de décrire des interactions à la fois puissantes et réutilisables. Nous avons déjà évoqué la possibilité de fournir une bibliothèque de dispositifs abstraits dédiés au domaine, dispositifs pouvant être partagés par un petit nombre d'applications de même nature (par exemple, applications de dessin ou applications 3D). Cette solution semble constituer un compromis tout à fait acceptable, qui reste encore à explorer.
ICON s'appuie sur un petit nombre d'APIs d'entrée existantes pour la prise en charge des dispositifs non standard (voir la section4.2.1 pour les détails). Les dispositifs d'entrée connectés au poste de travail et qui sont compatibles avec l'une de ces APIs apparaissent dans ICON et peuvent être employés dans les configurations d'entrée. Les APIs actuellement prises en charge ne couvrent cependant pas l'ensemble des dispositifs d'entrée existants, et les autres dispositifs nécessitent d'être implémentés dans ICON avant de pouvoir être utilisés. Cette opération peut se révéler fastidieuse, mais elle reste avantageuse pour le programmeur car elle permet de tirer parti du nouveau dispositif dans n'importe quelle application interactive Java.
Notons pour finir que la multiplicité des APIs d'entrée tend nettement à disparaître au profit du standard USB [USB/HID, 2001], et que la prise en charge de ce standard dans Java fait actuellement l'objet d'un projet d'IBM officiellement accepté comme extension candidate au langage [Maximilien et al., 2001] ainsi que d'un projet open-source indépendant [Jusb, 2003]. Les deux projets proposent déjà une implémentation Linux quasi-complète. Il y a donc fort à parier qu'à terme, la prise en charge effective des dispositifs non standard dans ICON ne constituera plus un obstacle à la description de techniques d'interaction non conventionnelles. Par ailleurs, les possibilités potentielles offertes par l'accès aux dispositifs USB dans un langage multi-plateformes rendra encore plus indispensable l'existence d'un outil approprié pour les exploiter au mieux dans les applications.
ICON repose sur un modèle d'exécution réactif, bien différent du modèle classique où les événements d'entrée sont accumulés dans une file pour être traités. Le modèle événementiel est de type conversationnel: l'ordinateur est maître de l'interaction et le client attend d'être servi. Dans un modèle réactif, c'est l'environnement (donc l'utilisateur) qui est maître de l'interaction, et toute action de sa part est traitée sans délai.
La machine réactive offre par conséquent des garanties en termes de temps réel. En revanche, le modèle réactif n'est valable que tant que l'hypothèse réactive est vérifiée, c'est-à-dire lorsque les événements sont traités plus rapidement que la vitesse où ils arrivent. La transgression de l'hypothèse réactive a des conséquences importantes sur la fiabilité du système et sur l'interaction elle-même, car des événements peuvent être perdus.
La souplesse actuelle des pilotes de dispositifs (qui gèrent notamment des mémoires tampon) fait qu'en pratique, la réactivité minimale acceptable dépend de critères pragmatiques plutôt que techniques. Ainsi, pour la plupart des techniques d'interaction, un temps de réaction de l'ordre de 1/50 de seconde permet de conserver l'information pertinente, et correspond à une réactivité et un taux de rafraîchissement considérés comme largement acceptables du point de vue de l'utilisabilité. Ce temps doit être sensiblement diminué pour certaines techniques comme la reconnaissance gestuelle, où le débit d'informations à traiter (du moins au niveau bas) est plus important.
Le temps d'exécution d'une itération (tick) est la somme du temps de propagation des signaux entre les dispositifs et de leur traitement au sein des dispositifs. Nous avons constaté que le premier était négligeable par rapport au dernier. L'algorithme de propagation employé dans ICON et décrit en annexe C est minimaliste et performant, même implémenté en Java. Pour donner un ordre de grandeur du temps de propagation, une configuration comportant 1000 dispositifs simples (se contentant de transmettre une valeur) connectés en série s'exécute en environ 0.5 ms (taux de rafraîchissement de 1800 Hz) sur une station Silicon Graphics 540 avec un processeur cadencé à 550 MHz.
Le temps de traitement évolue linéairement par rapport au nombre de dispositifs présents dans la configuration, et est au moins égal à celui du dispositif le plus lent. Ce temps doit être maintenu le plus bas possible, ce qui nécessite un style de programmation particulier pour les dispositifs (voir section 5.6.1). Dans l'hypothèse où l'instanciation d'objets est minimale et où les traitements coûteux sont lancés dans des fils d'exécution séparés, ICON s'exécute en « temps-réel ».
Les performances dépendent également des ressources processeur disponibles. Le fil d'exécution d'ICON est prioritaire par rapport à celui qui gère le rendu graphique. Cependant, afin de permettre au rafraîchissement graphique de se faire, ICON permet de spécifier une fréquence d'exécution afin de laisser entre les ticks l'initiative aux autres processus. Le temps d'exécution de chaque tick est mesuré afin de savoir si à un moment l'hypothèse réactive est violée. Il est également possible d'analyser les performances d'une configuration d'entrée, et de déterminer la contribution de chaque dispositif au temps d'exécution.
et qu'au même
moment, B émette une référence vers un objet 
. Le
dispositif printBefore affichera
ou
selon qu'il s'exécute avant ou après
addItem. Or, comme il n'existe aucune dépendance
explicite entre ces deux dispositifs, il n'y a aucun moyen de
savoir lequel sera exécuté avant l'autre. Le comportement de
printBefore, non-déterministe, dépend de la manière dont
le tri topologique est effectué.