Un éditeur graphique de configurations possède de nombreux avantages par rapport à des langages de script ou de programmation. Par exemple, dans l'hypothèse où toute notion de classe a été évacuée, les moyens d'accéder à un nouveau dispositif d'entrée ne peuvent pas être rendus explicites dans un langage textuel: il est nécessaire de consulter une documentation ou de faire des requêtes préalables sur le dispositif pour connaître le nom de ses différents canaux. Dans l'éditeur d'ICON, les interfaces des dispositifs sont explicites, et il suffit de connecter les canaux du dispositif d'entrée pour pouvoir l'utiliser.
Cependant, les langages visuels possèdent également de nombreux inconvénients. En particulier, ils supportent mal la complexité, et un programme peut rapidement devenir illisible et difficile à maintenir. ICON n'échappe pas à cette règle (voir par exemple les configurations des figures 5.6 et 4.33). Dans cette section, nous étudions plus en détail le problème de la complexité visuelle dans ICON.
![]() |
Sur la figure 5.6 est représentée la configuration d'entrée par défaut d'ICONDraw. C'est une configuration minimale mais complète permettant de contrôler, avec les dispositifs standard, les trois outils de dessin, les attributs de la brosse, ainsi que les widgets standard de Swing. Bien que l'on puisse y deviner une technique de multiplexage, cette configuration est illisible. Non seulement les nombreux croisements entre les connexions (impossible à éviter ici) nuisent à sa lecture, mais il est également difficile de déterminer les rôles respectifs des différents dispositifs.
La figure 5.7 montre une autre
représentation de la même configuration. Certains dispositifs ont
été dupliqués à plusieurs endroits de l'espace de travail en
employant des liens (voir 4.4.1). Les
dispositifs ont ensuite été regroupés afin de mettre en évidence
les différentes parties fonctionnelles de la configuration: la
partie
décrit le contrôle standard des composants Swing. La
partie
décrit la sélection de l'outil au bouton droit de la
souris, selon une technique de multiplexage temporel. La partie
décrit le contrôle des attributs de la brosse au clavier,
selon une technique simple d'incrémentation/décrémentation (la
brosse est un dispositif « virtuel » fourni par ICONDraw, qui
se contente de décrire une structure et transmettre en sortie les
données reçues en entrée). Enfin, les parties de
à
décrivent le contrôle des trois outils de dessin.
![]() |
Cet exemple montre que la lisibilité d'une configuration d'entrée repose en grande partie sur une bonne structuration spatiale. Nous pensons que même des configurations d'entrée extrêmement complexes peuvent être structurées en sous-configurations qui peuvent être comprises et modifiées de façon indépendante. Cette structuration est facilitée dans ICON par les techniques de manipulation directe et par le principe des liens, qui sont représentés dans la dimension verticale perpendiculairement aux flots de données. En outre, le redimensionnement relatif des dispositifs et l'encapsulation de sous-configurations dans des dispositifs composites permettent de mettre en évidence certaines parties de la configuration ou de définir des niveaux de détail. Toutes les techniques n'ont pas été explorées: par exemple, l'annotation des configurations à des fins de documentation, ou l'utilisation du zoom sémantique pour naviguer dans la hiérarchie des dispositifs composites sont deux techniques qui semblent prometteuses.
Dans le chapitre précédent, nous avons décrit une technique de pointage vocal employant deux pointeurs interdépendants, le premier étant sensible au niveau sonore et le second à la commande reconnue (configuration de la figure 4.33). Cette technique d'interaction sophistiquée est principalement implémentée par le dispositif SpeechCursor, un adaptateur qui renseigne la position des deux pointeurs en fonction des commandes qu'il reçoit.
![]() |
Le comportement du dispositif SpeechCursor a été entièrement décrit avec des opérateurs élémentaires d'ICON afin de tester la puissance d'expression du langage (figure 5.8). Nous ne nous attarderons par à décrire ces configurations, notre but étant simplement de montrer que malgré les deux niveaux de composition, chaque configuration-fille est relativement complexe et difficile à lire.
Cet exemple montre les limites du « tout-visuel » ou du « tout-modulaire » consistant à décrire n'importe quel comportement, même très complexe, par composition d'opérateurs simples. Bien que nous ayons à plusieurs reprises insisté sur les avantages apportés par un modèle modulaire en termes de configurabilité, nous avons également montré l'intérêt d'employer des dispositifs monolithiques (implémentés en Java) pour décrire des comportements complexes, et en particulier des techniques d'interaction connues. Nous pensons en effet qu'à partir d'un certain niveau de granularité, il devient inutile de décomposer les comportements car la complexité l'emporte sur la souplesse. En effet, un dispositif monolithique mais paramétrable est toujours plus configurable (dans le sens que nous avons défini dans la section 1.4.2) qu'une configuration d'entrée dont on n'arrive pas à comprendre le fonctionnement. Il nous semble cependant difficile d'établir précisément cette granularité-limite.
La figure 5.9 illustre deux techniques de tracé de lignes que nous avons déjà évoquées dans le chapitre précédent, et qu'il nous semble utile de reproduire ici. La configuration du haut décrit la technique de cliquer-glisser standard couramment employée pour spécifier deux points avec un seul pointeur. Celle-ci a été ensuite modifiée (configuration du bas) pour prendre en compte un deuxième dispositif de pointage. La configuration obtenue est bien plus simple que la configuration originale, d'abord parce que le multiplexage n'est plus nécessaire: deux dispositifs contrôlent deux dimensions. Ensuite, parce que la tablette graphique fournit des données directement compatibles avec celles du dispositif d'application (la souris nécessite la conversion de positions relatives en positions continues).
Cet exemple montre que la complexité d'une configuration d'entrée dépend d'une certaine manière du type d'interaction qu'elle décrit. Les techniques d'interaction standard, parce qu'elles utilisent des entrées relativement pauvres et génériques, emploient des techniques d'interaction essentiellement basées sur le multiplexage, nécessitant l'usage de modes et de structures conditionnelles. Ces comportements peuvent être à l'origine de configurations d'entrée relativement complexes. À l'inverse, les configurations d'entrée les plus simples, où la transformation des données est majoritaire par rapport à leur contrôle, décrivent des techniques de contrôle direct avec des dispositifs multiples. La technique d'interaction bimanuelle décrite ci-dessus en est un exemple, tout comme le contrôle d'une interface zoomable avec un dispositif à six degrés de liberté (figure 4.25).
Il est intéressant de constater que dans l'exemple décrit précédemment, la technique d'interaction considérée comme la plus naturelle se décrit aussi le plus aisément. Une technique d'interaction simple d'utilisation ne se décrit pas nécessairement de façon simple dans ICON (par exemple, un dispositif d'entrée et un objet de l'application peuvent être compatibles du point de vue cognitif mais être modélisés différemment). En outre, la simplicité d'une configuration d'entrée ne garantit rien, bien sûr, quant à l'utilisabilité de la technique qu'elle décrit (la suppression aléatoire d'une connexion simplifie la configuration mais pas l'interaction). Malgré tout, nous pensons qu'il existe un rapport entre la simplicité d'une configuration d'entrée et certaines « bonnes » propriétés de l'interaction, en particulier celles qui caractérisent les paradigmes post-WIMP (voir section 1.3.1).
En effet, nous pensons tout d'abord qu'un critère d'utilisabilité essentiel pour une technique d'interaction de type instrumental5.4 est sa faculté d'être facilement compréhensible par l'utilisateur: celui-ci doit pouvoir l'assimiler facilement mais surtout ensuite pouvoir prédire son comportement, et pour ce faire, s'être construit un modèle mental précis de son fonctionnement. En conséquence, les mécanismes de cette interaction doivent pouvoir se décrire facilement dans le formalisme qui convient. Nous pensons par ailleurs que les langages à flots de données, et ICON en particulier, sont bien adaptés à la description de la plupart des interactions de type Post-WIMP, car ils encouragent la description de techniques d'interaction directes, amodales et parallèles.