Dans cette section, nous positionnons ICON par rapport aux principales autres approches, dans le but de dégager les points communs et les complémentarités, et d'évaluer l'originalité d'ICON par rapport aux travaux existants. Nous proposons ensuite différentes pistes de recherche pour des travaux futurs.
La plupart des modèles de référence (voir section 2.2) décrivent un composant présentation ou interaction qui gère à la fois les entrées et l'affichage. Le modèle MVC, tout comme celui d'ICON, sépare l'interaction en entrée (gérée par le contrôleur) de l'interaction en sortie (gérée par la vue). L'objectif d'ICON est de décrire la partie contrôleur de la triade, sans s'occuper de la structure des deux autres composants.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.8]{icon_mvc}
\end{center}
\end{figure}](img213.png) |
La figure 5.12 illustre l'architecture d'ICON dans le paradigme MVC. La configuration d'entrée constitue le contrôleur, hormis ses dispositifs d'application qui décrivent chacun une partie du modèle et/ou de la vue de l'application interactive. Les dispositifs d'application sont en quelque sorte l'interface entre le contrôleur et le reste de l'application. Une configuration d'entrée peut également, avec des dispositifs de feedback, décrire des vues indépendantes. Les dispositifs de boîte à outils ne sont pas explicitement représentés dans ce schéma ; nous les considérons ici comme des dispositifs d'application qui se distinguent uniquement par leur caractère générique.
L'objet M+V de la figure décrit l'application interactive de façon monolithique, sans distinguer son noyau fonctionnel de sa représentation. En pratique bien sûr, le modèle M et la vue V peuvent être explicitement séparés, de même qu'ils peuvent être structurés en objets M+V plus petits. Les dispositifs d'application créent déjà une certaine structuration en encapsulant des objets M+V individuels, qui peuvent refléter ou non une structure pré-existante dans l'application. Les widgets constituent un exemple de structure pré-existante exploitée par les dispositifs de boîte à outils.
Notons pour finir que les dispositifs d'application ne sont pas tous destinés à être utilisés en « bout de configuration ». Certains d'entre eux, les points de retour, peuvent comporter des slots de sortie et être employés à n'importe quel niveau de la configuration (notre schéma n'en comporte pas pour des raisons de lisibilité). Des dispositifs comme le Pick peuvent ainsi être employés pour réinjecter dans la configuration de l'information en provenance de l'application.
Les outils commerciaux de développement d'interfaces et la majorité des boîtes à outils Post-WIMP proposées par la recherche (voir 2.6) reposent sur des modèles à événements pour la gestion des entrées. ICON emploie un modèle à flot de données réactif où la notion d'événement est absente, et où le paradigme de développement est par conséquent tout autre. Les mécanismes comme l'aiguillage, l'abonnement et les callbacks, en particulier, sont remplacés par des connexions directes entre modules.
Les deux approches ne sont cependant pas incompatibles, et dans certains cas elles peuvent se révéler complémentaires5.6. Le modèle d'ICON, nous l'avons vu, est particulièrement adapté à la description de techniques d'interaction réactives et de bas-niveau. Certains modèles d'interaction, en particulier l'interaction multimodale, nécessitent des notions de plus haut-niveau, comme celles des événements ambigus et des stratégies de médiation employées par Multimodal Subarctic (voir section 2.6.2). Néanmoins, toute interface, y compris les interfaces multimodales, comporte une partie réactive de bas-niveau. Une interface gestuelle, par exemple, a besoin d'accéder aux dispositifs d'entrée physiques, de produire en temps réel des traces et de les afficher.
Nous pensons que tout paradigme d'interaction gagnerait à reposer sur une infrastructure de type ICON. Une telle infrastructure procure de nombreux avantages, et garantit en particulier une grande souplesse par rapport aux entrées. Pour reprendre l'exemple de l'interaction gestuelle, d'autres dispositifs que la souris ou la tablette (par exemple, un dispositif de suivi oculaire) sont susceptibles de produire une trace. Même des dispositifs de nature non positionnelle peuvent être exploités avec des algorithmes et des mécanismes de reconnaissance gestuelle: une succession de touches au clavier est interprétable comme un geste, par exemple. Le modèle d'ICON, et sa notion d'adaptateurs en particulier, facilite et même encourage les utilisations multiples des dispositifs d'entrée. Au contraire, l'approche événementielle, qu'elle soit ou non ouverte aux entrées non conventionnelles, requiert une classification des dispositifs et l'attribution d'un rôle figé à chacun d'entre eux.
Dès lors, il ressort une question essentielle, à savoir jusqu'à quel niveau l'interaction doit être décrite avec ICON ? Nous n'avons pas étudié les manières de combiner notre modèle avec des architectures Post-WIMP de plus haut-niveau. Cependant, nous avons montré comment ICON pouvait permettre de décrire des techniques d'interaction de type « instrumental » dans un certain niveau de granularité. Cette expérience nous a notamment permis de réaliser qu'il serait par trop simplificateur de décomposer la gestion de l'interaction en couches figées. En effet, certains éléments contrôlables d'une application interactive (ou points d'entrée, dans notre terminologie) sont de bas-niveau et peuvent être manipulés avec des techniques de contrôle direct. Par exemple, la plupart des widgets sont des dispositifs « virtuels » qui peuvent, à la manière des Phidgets, être directement associés à des dispositifs réels. C'est également vrai pour certaines structures propres à l'application. Des parties de l'interaction peuvent par conséquent être intégralement décrites avec des flots de données réactifs, des dispositifs physiques jusqu'à l'application. Une architecture interactive employant un modèle du type ICON comme couche basse devrait par conséquent autoriser ce type de « court-circuitage », sous peine d'ignorer les techniques de contrôle direct ou de les décrire avec des mauvaises abstractions.
Les réseaux de Pétri et les automates à états sont des approches orientées contrôle, orthogonales à la notre. Elles décrivent particulièrement bien les mécanismes de multiplexage temporel et les modes employés dans les interfaces conventionnelles. À l'inverse, les interfaces Post-WIMP de type instrumental comportent relativement peu de contrôle et sont plutôt caractérisées par des flots de données. Cependant, à moins de disposer d'un dispositif physique pour chaque objet d'intérêt, toute interface comporte nécessairement une partie contrôle. En outre, pour des raisons d'accessibilité, nous nous devons de prendre en charge les situations d'entrées appauvries. Ce que nous faisons actuellement, mais en encapsulant les techniques d'accessibilité dans des adaptateurs.
S'il est difficile d'intégrer le contrôle et les données dans le même paradigme, deux types d'approches hybrides sont envisageables: au niveau macroscopique à l'extérieur d'ICON et au niveau microscopique à l'intérieur des dispositifs. La première approche consisterait à rendre les configurations d'entrée dynamiques et contrôler les reconnexions dans des automates ou des réseaux de Pétri, à la manière de VRED (voir section 2.7.3). Bien que nous ayons déjà motivé une approche essentiellement statique et que nous estimons que le problème de l'hybridation n'a pas encore été résolu de façon convaincante au niveau du langage visuel, ce type d'approche mérite d'être étudié.
L'approche consistant à décrire une partie des comportements des dispositifs avec des machines à états nous paraît une piste prioritaire. Un langage impératif comme Java permet d'implémenter facilement des dispositifs, mais ne dispose pas des outils adaptés pour décrire des machines à états complexes. Une extension syntaxique comme celle proposée par [Blanch, 2002] permettrait d'employer les approches à flot de données et à flot de contrôle de manière orthogonale et réellement complémentaire. L'agencement visuel de blocs reposerait ainsi sur un paradigme à flot de données, et les mécanismes internes à ces blocs seraient décrits avec un langage programmation conventionnel mais sachant prendre en charge les transitions d'états.
ICON se situe à la frontière de plusieurs approches. Tout d'abord, le
principe de flots de données sur lequel il repose a été exploité dans de
nombreuses applications, principalement dans les domaines de traitement et
d'analyse d'images et de composition musicale. Ensuite, ICON emploie un
langage visuel pour décrire l'interaction, comme le font beaucoup de
logiciels commerciaux et d'outils produits par le monde de la recherche.
Cependant, les nombreuses approches du type Visual 
de
Microsoft, et y compris celle de Garnet/Amulet (voir section
2.6.1) se concentrent principalement sinon exclusivement sur
l'agencement de composants visuels. Les éditeurs de comportement comme
Thinglab ou Fabrik (voir section 2.7.2) peuvent
permettre de décrire certains aspects touchant à l'interaction en entrée, mais
sont plus adaptés à la partie modèle (synchronisation entre plusieurs modèles
et entre modèles et vues) et graphique (maintien de contraintes géométriques)
de l'application.
L'approche consistant à utiliser un langage visuel basé sur un modèle à flot de données pour décrire l'interaction en entrée a été très peu explorée dans le domaine de l'interaction 2D. L'un des rares exemples est la boîte à outils Whizz et l'éditeur Whizz'Ed (section 2.7.2). Si ce langage visuel a été principalement créé pour décrire des interfaces animées et des interactions simples, son extension à l'interaction bimanuelle (section 2.6.2) donne des exemples de configuration d'entrée assez proches de ce que l'on pourrait construire avec ICON. Whizz'ed donnait déjà une bonne idée de la puissance du modèle à flot de données pour décrire le contrôle d'applications hautement interactives. ICON approfondit et étend cette approche, tout d'abord en posant les principes d'un modèle d'entrée basé sur des dispositifs généralisés regroupant dispositifs physiques, points d'entrée et adaptateurs, ensuite en proposant un modèle d'exécution basé sur les langages réactifs. Enfin, ICON explore plus loin ce paradigme, en exploitant des dispositifs d'entrée multiples et bien d'autres techniques d'interaction non-standard.
Si notre approche est novatrice dans le monde de l'interaction 2D, elle peut néanmoins sembler familière aux développeurs d'applications 3D. Nous avons vu que la plupart des boîtes à outils 3D reposaient sur un modèle d'entrée à flot de données, et que quelques unes proposaient des éditeurs visuels comparables au notre. C'est notamment le cas de Virtools Dev (voir section 2.7.3). Ces outils sont bien adaptés à la description d'interactions 3D, et plus particulièrement à la manipulation directe d'objets 3D avec des dispositifs sophistiqués. ICON applique à l'interaction 2D les techniques qui font le succès des applications 3D, à savoir l'usage de dimensions physiques multiples dans des techniques contrôle direct. En outre, ICON prend en charge des dispositifs plus divers et intègre des techniques 2D que les outils 3D étaient incapables de décrire, notamment parce que ces techniques sont beaucoup plus variées et complexes, comportent des modes et des feedbacks, et opèrent sur des objets de nature bien plus diverse que les attributs d'objets 3D.
ICON, en tant que travail exploratoire, ouvre de nombreuses voies. Nous en avons souligné quelque-unes sur la figure 5.13. Nos contributions y sont évoquées en gris, à savoir le paradigme de cascades de dispositifs (en bas) et ses applications successives: le modèle ICOM, la boîte à outils et l'éditeur d'ICON, les configurations d'entrée que nous avons construites et enfin leurs applications. Ces contributions sont agencées selon l'axe application, qui constitue une première direction d'exploration possible pour les perspectives. Les deux autres axes sont la validation de notre approche (cet axe dépend en partie des applications développées, d'où son orientation diagonale) et l'extension de celle-ci.
Le modèle ICOM décrit les mécanismes de l'infrastructure data-flow d'ICON. Plusieurs orientations sont possibles pour celui-ci: d'abord, une formalisation permettrait d'une part de valider la fiabilité de notre modèle, d'autre part de vérifier des propriétés sur les configurations. Nous avons déjà évoqué la possibilité d'exploiter des outils de vérification de langages réactifs comme Esterel [Fekete et al., 1998,Fekete and Dragicevic, 2000]. Diverses voies sont possibles quant à l'extension du modèle ICOM: l'intégration avec des modèles existants, en particulier des formalismes orientés-contrôle et des modèles d'interaction plus haut-niveau (voir 5.8.1) ; la prise en charge de types étendus pour faciliter la construction de configurations d'entrée et de cascades implicites éditables pour exposer efficacement les modèles physiques des dispositifs. Ces deux dernières idées seront développées plus loin.
En dehors de son infrastructure ICOM, ICON peut être divisée en deux parties: la partie boîte à outils qui décrit la librairie extensible de dispositifs, et l'éditeur interactif de configurations. Chaque de ces deux parties peut être validée par une évaluation: la première pour prouver la pertinence de l'outil vis-à-vis du programmeur, et la seconde pour déterminer l'utilisabilité du configurateur interactif. Nous avons déjà constaté que les deux développeurs que nous avons suivis étaient capables, après un temps d'assimilation, de produire rapidement des dispositifs d'application à chaque fois que cela s'avérait nécessaire, et de maîtriser toutes les potentialités de l'éditeur interactif. Nous ne nous attendons cependant pas à ce qu'un utilisateur moyen emploie l'éditeur de la même manière. Au lieu de cela, nous avons montré en quoi l'utilisateur, selon ses compétences, pouvait tirer parti de ce langage visuel pour des tâches simples. Une évaluation permettrait de déterminer plus précisément en quoi consistent ces tâches. Nous nous doutons cependant que la mise en place de telles expérimentations serait loin d'être triviale, en particulier s'il s'agit d'évaluer la pertinence d'ICON par rapport à d'autres outils. Ainsi, si les boîtes à outils conventionnelles permettent de développer facilement des interfaces WIMP, elles ne prennent pas en charge la majeure partie des techniques d'interaction qu'ICON permet de décrire. La comparaison est difficile, faute de cibles de comparaison.
La bibliothèque d'ICON, bien que déjà très complète, gagnerait cependant à être étendue avec de nouveaux dispositifs. Les principaux dispositifs système que nous projetons d'implémenter, dans le but de couvrir une plus vaste palette d'entrées non standard, sont les périphériques MIDI, USB, et l'analyse vidéo. Nous avons depuis peu à notre disposition un certain nombre de boîtes à potentiomètres MIDI dont l'exploitation dans ICON nous semble très prometteuse. L'interface HID des périphériques utilisateur USB, en plus d'être générale, est très détaillée et intègre bon nombre d'informations pragmatiques sur le dispositif physique (même si malheureusement, les constructeurs n'implémentent pas toujours cette interface entièrement). L'interaction multidigitale [Rekimoto, 2002], maintenant réalisable avec des dispositifs tactiles matriciels du commerce [Tactex, 2003,FingerWorks, 2003], nous paraît également avoir un fort potentiel. Nous projetons également d'ajouter d'autres dispositifs utilitaires à ICON, dont divers adaptateurs d'accessibilité (techniques à simple bouton, notamment), d'autres techniques d'interaction prêtes à l'emploi, et des dispositifs dédiés au feedback reposant sur un modèle graphique multicouche similaire à [Fekete, 1996b]. Enfin, nous avons déjà évoqué un projet en cours dont le but est de décrire de nouveaux dispositifs de boîte à outils pour contrôler les applications zoomables développées avec Piccolo [Bederson, 2003]. L'objectif de ces dispositifs est l'intégration complète d'ICON à une boîte à outils graphique avancée.
Nous avons déjà proposé dans ce mémoire quelques améliorations pour le configurateur interactif d'ICON: par exemple, l'annotation des configurations à des fins de documentation et une technique de zoom sémantique pour naviguer dans les dispositifs composites. Les utilisateurs non-experts pourraient également bénéficier d'une version allégée du configurateur interactif qui leur serait spécialement destinée: nous développerons les idées à la base d'ICONLITE par la suite.
À un niveau au-dessus se situent les configurations d'entrée construites avec ICON. Bien qu'elles soient déjà nombreuses, bien d'autres techniques peuvent être décrites avec les dispositifs existants. En particulier, nous pensons que le potentiel des techniques d'interaction de bas-niveau type « pointage augmenté » mérite d'être davantage exploré. En outre, au fur et à mesure qu'ICON se verra enrichir par de nouveaux dispositifs, d'autres configurations exploitant ces dispositifs viendront s'ajouter à celles existantes.
L'objectif des configurations d'entrée est de décrire l'interaction avec des applications. À ce jour, toutes les applications reposant sur Swing peuvent être contrôlées avec ICON (nous avons également décrit le contrôle partiel de Microsoft Word et de Jazz, mais uniquement à titre expérimental). En dehors des applications-jouets comme ICONDraw, deux projets d'applications employant ICON ont été évoqués (voir section 4.5). Nous projetons de décrire le contrôle d'applications de natures plus variées et en particulier des applications gourmandes en entrées tels que les jeux vidéo et les applications d'animation 3D. Les visages animés comme ceux des agents Haptek [Haptek, 2003] notamment, comportent un grand nombre de dimensions qui peuvent être contrôlées simultanément. Nous espérons également que notre distribution d'ICON sera employée dans des projets de développement extérieurs. Enfin, comme nous l'avons vu dans la section 4.5, ICON a également servi à monter une expérimentation visant à comparer plusieurs techniques d'interaction. Nous pensons qu'ICON pourra être d'une aide non négligeable dans ce type de tâche, car il offre un accès aisé aux dispositifs non-standard et permet de prototyper rapidement des techniques d'interaction, de les affiner et d'en étudier plusieurs variantes. En outre, ICON rend explicite toute la chaîne de traitements, et la représentation visuelle qu'il donne de cette chaîne est un outil de compréhension qui peut être mis à profit pour illustrer des études comparatives.
Nous terminons cette section par trois perspectives d'extension que nous venons d'évoquer et qui méritent d'être un peu plus développées: les types étendus, les cascades implicites éditables, et ICONLITE.
Il existe de nombreuses raisons d'étendre notre système de typage avec des types plus restrictifs. Tout d'abord, les remises à l'échelle sont fréquentes dans ICON, et il est difficile d'employer l'opérateur de transformation linéaire sans connaître les domaines de départ et d'arrivée5.7. Il nous semblerait par conséquent utile d'inclure les domaines dans les types de slot, information qui pourrait par exemple être exploitée par des adaptateurs de domaine automatiques, ou comme pré-conditions dans des dispositifs d'application.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.65]{valeur_repos}
\end{center}
\end{figure}](img216.png) |
Les pré-conditions et post-conditions pourraient être généralisées à bien d'autres propriétés, notamment dans le but de prendre en compte certaines caractéristiques pragmatiques des dispositifs [Buxton, 1983]. Ces propriétés doivent pouvoir être aisément propagées à travers les dispositifs. C'est le cas des valeurs particulières, qui peuvent dans certains cas être transformées par la fonction d'exécution5.8. Dans [Dragicevic, 1998], nous décrivons des propriétés pragmatiques qui rentrent dans ce cadre. Un slot, par exemple, peut conserver sa valeur lorsque l'utilisateur n'exerce plus d'action sur les dispositifs physiques, ou bien revenir à une valeur au repos. Cette valeur au repos permet de spécifier des pré-conditions extrêmement intéressantes dans les dispositifs d'application (figure 5.14). D'autres propriétés comme la précision et la latence peuvent être également prises en compte, et propagées de façon spécifique.
Les types étendus avec des pré-conditions et des post-conditions permettraient à la fois de proposer des adaptateurs évolués facilitant significativement la construction de configurations, et de vérifier certaines propriétés dans la configuration d'entrée. Par exemple, une précision minimale pourrait être requise en entrée d'un pointeur ou d'un dispositif gestuel. Malgré les nombreuses applications, cette approche demande un vaste travail et pose plusieurs problèmes: tout d'abord l'utilisation de types étendus complique l'implémentation des dispositifs qui doivent calculer explicitement certaines post-conditions5.9. En outre, les post-conditions ne peuvent pas toujours être déduites précisément, et deviennent rapidement vagues au fur et à mesure des traitements. Enfin, les informations concernant les dispositifs d'entrée physiques (par exemple, la valeur au repos) ne sont pas toujours disponibles.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.75]{fluxsimule}
\end{center}
\end{figure}](img217.png) |
Lorsqu'un dispositif d'entrée ICON fournit une vue logique assez éloignée du modèle concret du dispositif, il serait intéressant à des fins d'explication de rendre le dispositif concret visible dans la configuration, et de reproduire la cascade implicite (ou une cascade possible) de traitements en aval de ce dispositif (figure 5.15). Le dispositif de reconnaissance vocale, par exemple, pourrait apparaître comme un dispositif de traitement connecté à un microphone physique.
La cascade implicite peut même être rendue modifiable si les dispositifs
qui la composent sont réels et non plus simulés, et qu'ils sont
inversibles. Un dispositif de fonction de transfert 
est
inversible s'il existe un dispositif de fonction de transfert 
telle que
(voir également [Accot et al., 1997]). Or supposons que
désigne une cascade implicite divisée en une partie
non-inversible 
et une partie inversible 
. Si la partie est modifiée
en 
, il suffirait pour prendre en compte cette modification d'appliquer la
fonction de transfert
en sortie du dispositif logique.
Ainsi, dans l'éditeur graphique, les dispositifs de seraient non
modifiables mais la cascade pourrait être modifiée comme tout élément de la
configuration. Le traitement réel
resterait cependant
invisible à l'utilisateur.
Les applications potentielles des cascades implicites éditables sont nombreuses. Sur la configuration de la figure 5.15 par exemple, il serait possible de se servir de la vue matricielle de la boîte à boutons pour calculer la moyenne des (x,y) enfoncés et contrôler grossièrement un pointeur. Le dispositif concret pourrait fournir des informations spatiales également utiles. Un modèle de manette intégrant les différentes grandeurs physiques (déplacement réel, force exercée sur le manche), par exemple, permettrait de donner un sens aux valeurs numériques produites par le pilote de dispositif [Dragicevic, 1998]. La cascade implicite pourrait également remonter jusqu'à un modèle d'utilisateur comportant des post-conditions qui décrivent ses capacités motrices (par exemple, la force maximale qu'il est capable d'exercer).
Le calcul de l'inverse devrait être à la charge de chaque dispositif, qui implémenterait une fonction du type Device createInverse(). L'inconvénient, là encore, réside dans la difficulté pour le développeur de programmer de tels dispositifs, en particulier si les inversions sont employées en combinaison avec des types étendus5.10.
Notre expérience avec ICON nous a conduit à penser qu'il est possible, en poussant plus loin l'exploitation de la métaphore de la connexion logicielle (voir section 3.2.1), de construire un éditeur de configurations à l'usage de l'utilisateur moyen, qui soit à la fois simple d'utilisation et puissant. Ceci à condition de concevoir les techniques de visualisation et d'interaction appropriées.
L'éditeur Whizz'Ed (voir section 2.7.2) emploie des représentations iconiques des dispositifs, ce qui facilite leur identification. Les Phidgets (voir section 1.3.5) exploitent une technique de configuration extrêmement naturelle, consistant à brancher un dispositif USB puis à l'associer à un widget présent à l'écran par un simple clic. Si la contrôlabilité et la configurabilité offerte par les Phidgets est bien en deçà d'ICON, le paradigme de connexion dynamique peut être étendu et exploité dans une version allégée d'ICON.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.55]{apple}
\end{center}
\end{figure}](img226.png) |
Les dispositifs d'entrée connectés peuvent être représentés graphiquement dans une barre de dispositifs inspirée du dock de Mac OS X [Apple, 2002] (figure 5.16, image de gauche). Lorsqu'un nouveau dispositif est branché, cette barre apparaît pour permettre d'établir une connexion avec les éléments présents à l'écran. Les connexions sont affichées en incrustation à la manière d'Interface Builder [Apple, 2003] (figure 5.16, image de droite) dans le mode de construction, et disparaissent dans le mode d'interaction. Le mode de construction peut être réactivé à tout moment pour modifier les connexions.
Une palette d'adaptateurs permettrait d'insérer des traitements supplémentaires dans les connexions (par exemple, une répétition automatique pour un bouton). Ceux-ci doivent être simples d'utilisation et contrairement à la version actuelle de notre éditeur, avoir une représentation graphique iconique explicite. Des mécanismes de connexion « intelligents » doivent pouvoir permettre l'insertion automatique d'adaptateurs (adaptateurs de domaine, notamment), ainsi que les connexions groupées de slots entre objets compatibles.
En outre, des objets d'application non visuels (par exemple, le pan ou le zoom) doivent pouvoir être réifiés et affichés, par exemple dans une palette propre à l'application. Il en est de même pour des objets système comme les pointeurs.
Deux objets compatibles (par exemple, une souris et un curseur) peuvent être directement reliés, ce qui ne nécessite pas la présence explicite de slots. En revanche, il est indispensable que les objets puissent être affichés avec plusieurs niveaux de détail. Par exemple, un clavier peut être relié à un éditeur de texte, mais des connexions de touches individuelles doivent également être possibles.
Pour finir, il serait intéressant d'explorer les différents moyens d'étendre matériellement nos systèmes afin de déplacer une partie de la tâche de configuration vers le niveau physique. Par exemple, l'organisation de la barre de dispositifs peut reproduire l'agencement spatial des prises USB, ces dernières pouvant notamment être placées sous l'écran. Chaque prise USB pourrait se voir assigner un rôle différent, et des adaptateurs matériels pourraient également être employés (des adaptateurs USB portant un identifiant reconnu par ICONLITE suffiraient). Certains utilisateurs disposeraient par exemple d'adaptateurs d'accessibilité personnels. Enfin, étant donné qu'un dispositif de pointage est toujours nécessaire pour connecter des dispositifs à des objets graphiques, un écran tactile pourrait être employé et dédié à cet effet.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.9]{perspectives}
\end{center}
\end{figure}](img214.png)
de la manette (à
droite) contrôle la dimension 
de ce bouton (qui est aussi celle du doigt) est émise, puis discrétisée,
et enfin convertie en code touche.