Nous avons montré dans le premier chapitre l'intérêt des dispositifs d'entrée non standard et des paradigmes d'interaction post-WIMP. Il est par conséquent utile de déterminer dans quelle mesure les outils fournis par ICON et le modèle des dispositifs en cascade sur lequel il repose permettent de décrire ces nouveaux dispositifs et paradigmes d'interaction.
Nous commencerons par évoquer les limitations inhérentes au langage d'ICON et leurs conséquences sur la description de techniques d'interaction en général. Puis, nous nous demanderons si notre modèle permet de prendre en compte l'ensemble des dispositifs non-standard existants et à venir. Enfin, nous tenterons de déterminer en quoi notre approche est adaptée ou non à la description des différents paradigmes d'interaction non-standard évoqués dans le premier chapitre.
Le langage à flot de données d'ICON comporte certaines limitations inhérentes. Nous les justifions ici, et décrivons en quoi elles ne nuisent pas réellement à son pouvoir d'expression.
ICON n'autorise pas les connexions multiples sur un seul slot d'entrée, ce type de connexion n'étant pas souhaitable dans un paradigme réactif. En effet, plusieurs signaux peuvent converger pendant un tick là où l'on suppose qu'un seul signal (et une seule valeur) peut être stocké. La méthode consistant à conserver le dernier signal induit un comportement non-déterministe car l'ordre dans lequel arrivent les signaux n'est pas connu.
Dans ICON, les signaux nécessitent d'être fusionnés explicitement par des dispositifs de type opérateur mathématique ou logique. Cette méthode présente l'avantage d'être déterministe, et permet à l'utilisateur de choisir librement la façon dont il veut combiner plusieurs sources de données sur un seul slot d'entrée.
Les configurations d'entrée sont statiques: elles ne peuvent pas être modifiées pendant l'exécution. C'est en particulier le cas des connexions. Or les techniques d'interaction comportent à la fois des connexions statiques (la souris bouge toujours le même curseur) et des connexions dynamiques (le curseur contrôle différents objets). En effet, s'il est envisageable d'affecter un dispositif à un objet de façon permanente (par exemple, le contrôle du volume), le nombre de dimensions contrôlables d'une application est souvent supérieur aux dimensions disponibles en entrée, d'où la nécessité d'un multiplexage spatial ou temporel.
Le multiplexage peut cependant être décrit avec ICON, de deux manières différentes. La première repose sur des techniques d'activation sélective: les sorties d'un dispositif sont connectées de façon permanente aux entrées de plusieurs dispositifs comportant chacun un slot booléen d'activation, et un mécanisme de sélection s'assure qu'un seul d'entre eux est actif à la fois. La configuration montrant un usage de la Toolglass dans ICONDraw constitue un exemple d'activation sélective (voir figure 4.34).
La deuxième technique de multiplexage emploie des passages de référence: un dispositif agit sur l'objet qui lui a été transmis en entrée par un autre dispositif, et est capable changer d'objet d'intérêt à tout moment. Les sélecteurs et les manipulateurs décrits dans la section 4.2.3 emploient cette technique, et sont notamment utilisés dans la configuration décrivant le contrôle des composants Swing (voir figure 4.18).
Autoriser des reconnexions dynamiques dans les configurations d'entrée compliquerait significativement le modèle d'exécution, et serait source de confusions importantes si le problème de la représentation visuelle adéquate n'est pas étudié sérieusement. Cependant, si notre approche d'activation sélective rend explicite l'ensemble des flux de données possibles, elle ne décrit pas clairement pourquoi et quand les données empruntent un chemin plutôt qu'un autre. Nous reviendrons sur ce problème dans la section 5.8.1 lorsque nous évoquerons les systèmes à transitions.
Nous distinguons deux types de cycles: les cycles explicites, qui sont internes à la configuration, et les cycles implicites, qui transitent par l'environnement. Nous les décrivons séparément.
Les cycles explicites. En tant que langage réactif, ICON n'autorise pas les dépendances cycliques directes: l'algorithme de sa machine réactive repose sur l'existence d'un ordre partiel entre les dispositifs, qui garantit l'exécution de chaque tick en un temps fini. La plupart des langages réactifs résolvent ce problème en autorisant les cycles avec un opérateur de retard, qui transmet le signal au tick suivant.
Un opérateur de retard peut également être implémenté dans ICON pour permettre de décrire des cycles explicites, c'est-à-dire des cycles internes à la configuration. Cependant nous n'avons jamais eu besoin de tels cycles, sauf à une seule reprise, lorsque nous décrivions un comportement à un niveau de granularité très fin5.2. Les cycles de ce type traduisent des mécanismes internes qui se situent, selon nous, à un niveau trop bas pour être pertinent du point de vue de la personnalisation de l'interaction. Notre expérience a montré qu'à un certain niveau de granularité, les comportements peuvent être tous décrits sans faire appel à des cycles.
Nous pensons plus généralement que les flux unidirectionnels de données, où contrôleurs et contrôlés sont clairement séparés, constituent un bon modèle structurant pour l'interaction en entrée bas-niveau. Cette structuration garantit en effet une certaine amodalité, dans la mesure où à un niveau donné dans la cascade de dispositifs (niveau qui correspond à une certaine abstraction des dispositifs physiques comme nous l'avons vu dans la section 3.2.5), l'interprétation des actions de l'utilisateur ne dépend pas de l'état du système en aval.
Les cycles implicites. L'information peut transiter dans n'importe quel sens dans une configuration ICON en passant par les entrées/sorties implicites. Nous qualifions ce type de cycle d'implicite, car il transite par l'environnement. Le comportement d'un dispositif pick, par exemple, dépend de l'agencement spatial des objets qu'il sert en partie à manipuler. Les cycles implicites sont utiles car ils permettent à une configuration d'entrée d'effectuer, à travers des points de retour comme le pick, des requêtes dans l'application ou la boîte à outils tout en la contrôlant.
Les seuls cycles qui nous semblent essentiels dans l'interaction sont par conséquent ceux qui résultent de la communication à double sens entre le contrôle et la vue d'une part (pour le pick, par exemple), et entre le contrôle et le modèle d'autre part (pour le retour sémantique). Ces cycles sont tous implicites et peuvent être décrits par des points de retour. Ils remettent en cause notre modèle unidirectionnel, mais seulement à un niveau de la cascade où la communication bidirectionnelle avec la vue et le modèle devient nécessaire.
Les dispositifs d'entrée non standard sont extrêmement nombreux et variés, et de nouveaux dispositifs apparaissent régulièrement sur le marché ou dans le monde de la recherche. Il est par conséquent indispensable de disposer d'un modèle assez général pour prendre en compte les dispositifs existants et ceux à venir.
Le modèle à base de canaux structurés sur lequel repose ICON est à la fois très simple et très général. Les canaux ont été largement employés dans les modèles de dispositifs d'entrée, et sont aujourd'hui adoptés par les principaux standards [USB/HID, 2001]. En effet, tout dispositif d'entrée peut être décomposé en un ensemble de canaux atomiques. La faiblesse des modèles existants provient non pas de cette décomposition en canaux mais d'une classification figée des dispositifs, qui les rend peu évolutifs et ne permet pas d'exploiter les capacités propres à chaque dispositif. ICON résout le problème en évacuant toute notion de classe ad-hoc. Néanmoins, dans certains cas particuliers que nous détaillons ici, notre modèle peut montrer certaines faiblesses.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.5]{beaucoup_dimensions}
\end{center}
\end{figure}](img202.png) |
La décomposition en canaux rencontre des difficultés dans les cas de dispositifs d'entrée possédant un très grand nombre de dimensions. Le cube déformable de Murakami et al [Murakami et al., 1995], représenté sur la figure 5.5 est une structure recouverte de mousse qui comporte 90 degrés de liberté interdépendants. Le dispositif Smartskin de Rekimoto [Rekimoto, 2002], déjà présenté au premier chapitre et illustré sur la figure 5.5, image de droite, est une matrice de 72 (ou 768 selon le modèle) capteurs capacitifs. Les nombreux canaux de ces dispositifs seraient pénibles à connecter individuellement. En outre, la représentation en « liste de slots » dans ICON n'est pas adaptée à des canaux disposés en matrice. Même si ICON permet d'organiser ces canaux multiples en un unique slot composite, ceux-ci se comporteraient du point de vue de la machine réactive comme des canaux individuels dont la gestion resterait lourde.
Une solution consiste à modéliser ces dispositifs à un plus haut niveau (par exemple, remplacer la matrice de Smartskin par une liste de pointeurs), avec cependant pour inconvénient de faire disparaître le dispositif concret et de rendre implicite une partie importante de la chaîne de traitements. Pour le dispositif clavier d'ICON, une solution intermédiaire a été implémentée, où chaque touche (booléen) est accessible individuellement, en même temps que le code (entier) de la dernière touche appuyée ou relâchée. Cette redondance est nécessaire, car les deux structures sont pertinentes, selon l'utilisation que l'on désire faire du clavier dans la configuration d'entrée.
Certaines entrées comme les signaux audio ou vidéo émettent des flux de données extrêmement denses. Ces entrées provoquent une première difficulté d'ordre technique, car le langage Java n'est actuellement pas capable de traiter un tel débit en temps réel, traitement qui est habituellement implémenté au niveau matériel ou dans un langage très bas niveau. Mais surtout, il est difficile de faire cohabiter dans une même machine réactive des algorithmes de traitement de nature totalement différente, car son temps de réaction total est au moins égal à celui du dispositif le plus lent. Or la réactivité n'est qu'une question d'ordre de grandeur: pour la plupart des configurations d'entrée, un temps de réponse comparable au taux de rafraîchissement de l'écran (de l'ordre de 100 Hz) est plus qu'acceptable du point de vue de l'interaction ; pour les applications de reconnaissance gestuelle, la fréquence acceptable est de l'ordre de 1000 Hz, comparable à celle d'une tablette graphique ; pour les applications de traitement de signal audio, la fréquence est de l'ordre de 10000 Hz.
Dans ICON, il est possible de faire communiquer par des entrées/sorties implicites plusieurs configurations d'entrée qui s'exécutent à des vitesses différentes. Cependant, tout comme pour le problème précédent, les dispositifs à très haut débit gagneraient à être modélisés à plus haut niveau, quitte à violer notre principe selon lequel les dispositifs doivent être décrits à un niveau très bas. En effet, dans un système interactif un échantillon audio isolé n'a pas plus de sens qu'un pixel provenant d'une caméra, et il est plus judicieux de transmettre à travers les canaux de ces dispositifs des paquets audio et vidéo. Le dispositif de commande vocale actuellement implémenté dans ICON est un dispositif d'entrée pur, le flux d'informations entre le microphone et le moteur de reconnaissance vocale étant implicite. Les traitements en amont sont par conséquent configurés par paramétrage du dispositif (mots à reconnaître) au lieu d'être représentés explicitement dans ICON.
À partir d'un nombre limité de dispositifs fournissant les services de base, les possibilités offertes par ICON pour décrire des techniques d'interaction existantes ou inédites sont extrêmement nombreuses. Nous avons construit et testé approximativement une centaine de configurations d'entrée, et nous ne pouvons malheureusement pas toutes les évoquer. Dans le chapitre précédent, nous avons essayé d'en fournir un échantillon représentatif.
Les techniques d'interaction non conventionnelles proposées dans la littérature scientifique sont néanmoins extrêmement nombreuses, et nous n'avons pas pu toutes les décrire à ce jour. Dans cette section, nous exploitons toutefois les résultats obtenus avec les techniques déjà implémentées et tentons de déterminer les capacités potentielles d'ICON pour les autres, dans le but d'identifier les caractéristiques des paradigmes non conventionnels par rapport auxquelles ICON est pertinent et celles pour lesquelles il l'est moins. Nous avons identifié un certain nombre de ces caractéristiques qui nécessitent une prise en charge spécifique: