Dans cette section, nous introduisons le paradigme des dispositifs en cascade, en développant le principe de la connexion logicielle de dispositifs. Ce paradigme suppose d'abord deux types d'entités: les dispositifs d'entrée physiques et l'application. Nous serons par la suite amenés à introduire quatre autres notions essentielles: les points d'entrée, les adaptateurs, les dispositifs généralisés, et enfin les cascades.
![\begin{figure}
\begin{center}
\includegraphics[scale=0.45]{connexion_logicielle}
\end{center}
\end{figure}](img133.png) |
Le paradigme de connexion logicielle de dispositifs (figure 3.1) dérive de la notion plus familière de connexion physique : lorsque nous voulons utiliser un dispositif, nous le connectons. Dans le monde quotidien, la plupart des dispositifs électriques ou électroniques nécessitent d'être branchés sur le secteur (fer à repasser, chargeur de téléphone portable), ou sur un autre dispositif (casque audio sur une chaîne hi-fi, guitare électrique sur un amplificateur) pour être utilisés. Dans le deuxième cas, la connexion sert à établir un échange d'informations entre un dispositif mobile à usage humain, et un dispositif fixe qui lui est lié.
Il est intéressant de noter que lorsque l'échange d'informations se fait du dispositif humain vers le dispositif fixe, il est possible d'établir un parallèle avec l'interaction instrumentale dans le monde réel [Beaudouin-Lafon, 1997]. Dans ce cas particulier de manipulation instrumentale, l'opération de connexion initie l'utilisation d'un instrument (le dispositif mobile) tout en désignant l'objet du monde sur lequel il va agir (le dispositif fixe). C'est le cas lorsque l'on branche une guitare sur un amplificateur, ou un dispositif de commande sur certains appareils industriels ou domotiques. Mais cela peut également s'appliquer lorsque l'on branche un dispositif d'entrée sur un ordinateur (d'autant plus que les progrès technologiques autorisent dorénavant des connexions à chaud de dispositifs d'entrée [USB/HID, 2001]).
![\begin{figure}
\begin{center}
\includegraphics[scale=2.2]{ampli}
\end{center}
\end{figure}](img134.png) |
En outre, différents branchements possibles sur un dispositif fixe peuvent multiplier le nombre d'objets manipulables. Les différentes entrées de certains amplificateurs de guitare permettent ainsi de manipuler plusieurs sons (figure 3.2). Mais malheureusement, les systèmes informatiques actuels ne permettent qu'une utilisation unique et globale d'un dispositif (voire zéro, s'il n'est pas reconnu par les applications). Le paradigme de connexion logicielle permet d'aller plus loin dans ce domaine, en passant virtuellement d'un objet manipulable unique (l'ordinateur) à des objets multiples de granularité plus fine (les applications et leurs différentes fonctionnalités). La connexion logicielle étend la connexion physique des dispositifs d'entrée, tout en se basant sur le même paradigme.
Tout logiciel interactif possède un certain nombre de besoins en termes d'entrée, ou points d'entrée: ce sont des données qui sont fournies par l'utilisateur. Il existe plusieurs manières de décrire ces points d'entrée indépendamment des dispositifs. L'une de celles-ci, que nous utiliserons temporairement pour les besoins de cette introduction, consiste à les identifier comme autant de tâches d'interaction au sens de Foley [Foley et al., 1984]. Pour rappel, ces tâches d'interaction sont essentiellement des types de données.
![\includegraphics[scale=0.42]{points_dentree}](img135.png)
|
Ainsi, un logiciel de traitement de texte pourra avoir besoin de données de
type Position pour spécifier l'emplacement du point d'insertion, et de
données de type Text pour insérer du nouveau texte. Il comportera ainsi
deux points d'entrée. Si le logiciel gère les annotations, il pourra également
déclarer un point d'entrée supplémentaire de type Stroke (figure
3.3).
Chaque point d'entrée définit une destination de connexion possible pour un
dispositif d'entrée. Même si dans les applications classiques les points
d'entrée de type Text et Position sont invariablement connectés à
un clavier et à une souris, les tâches d'interaction sont théoriquement
indépendantes des dispositifs d'entrée. Dans la section suivante, nous verrons
quelques exemples de connexions standards et alternatives.
![\includegraphics[scale=0.83]{connexions_foley}](img136.png)
|
La figure 3.4 illustre, à l'aide de connexions, diverses méthodes de saisie possibles pour notre logiciel de traitement de texte. Du côté gauche sont représentés un certain nombre de dispositifs d'entrée potentiellement utilisables (souris, manette, bouton à deux états, clavier, microphone, tablette) et du côté droit les trois points d'entrée (tâches d'interaction de Foley) vers l'application. Seules quelques-unes parmi toute les possibilités de connexion sont représentées sur la figure.
Certaines connexions font intervenir des utilisations non triviales des dispositifs d'entrée (par exemple, émettre des positions avec un clavier). Les données émises par le dispositif et celles reçues par le point d'entrée étant incompatibles, ces couplages nécessitent l'utilisation de boîtes adaptatrices, ou adaptateurs. Chaque adaptateur traite les données en provenance d'un dispositif pour les rendre compatibles avec un point d'entrée donné. Ils peuvent éventuellement posséder un état et produire des retours (graphique, sonore, etc...) qui ne sont pas représentés sur la figure.
Il est intéressant de remarquer que chacun de ces adaptateurs décrit une technique d'interaction. Ainsi, l'utilisation d'une manette ou d'un clavier comme dispositifs positionnels implique l'utilisation d'une technique de contrôle du mouvement ou contrôle du second ordre (l'utilisateur contrôle la vitesse et non la position du pointeur). Des techniques d'animation (dites de scannage) sont utilisées pour spécifier des positions avec des dispositifs d'accessibilité à deux états, tels que les boutons. De même, pour pouvoir fournir du texte, le signal d'un microphone nécessite d'être interprété à travers un module de reconnaissance vocale.
Sur la figure, par souci de simplicité, les connexions standards ne comportent pas d'adaptateurs. En pratique, certaines d'entre elles peuvent nécessiter des traitements de base (telles que des remises à l'échelle pour les dispositifs de pointage) ou un retour graphique simple (pointeur, par exemple). Les données brutes du clavier nécessitent également d'être traitées (le cas du clavier sera développé un peu plus loin).
Nous avons introduit trois types d'objets pour décrire des exemples pratiques de connexion de dispositifs: les dispositifs d'entrée, les adaptateurs, et les points d'entrée vers l'application. Nous allons unifier ces trois entités.
Remarquons d'abord qu'il est possible de connecter deux types d'objets à un point d'entrée: un dispositif ou un adaptateur. Or du point de vue de l'application, un adaptateur se comporte exactement comme un dispositif d'entrée. Par exemple, l'adaptateur "contrôle du mouvement" fournit des données comparables à celles d'une souris.
Notons également qu'un point d'entrée peut également se comporter comme un dispositif d'entrée. Ainsi, des positions peuvent générer du texte à travers un clavier graphique. Des tracés peuvent également produire du texte à travers un module de reconnaissance de l'écriture (figure 3.5).
Chaque dispositif d'entrée, adaptateur et point d'entrée peut jouer le rôle de dispositif. Nous regroupons par conséquent ces objets sous le terme générique de dispositifs généralisés, ou plus simplement dispositifs. Les dispositifs système tels que le clavier ou la souris, sont des cas particuliers de dispositifs. Les points d'entrée vers une application seront également appelés dispositifs d'application.
Nous avons vu jusqu'ici deux types de connexions: les connexions directes et les connexions avec adaptateur unique. Dans les systèmes interactifs cependant, l'interprétation des actions de l'utilisateur se fait en général à travers une série de traitements successifs. Cette sérialisation répond souvent au besoin d'accéder à un dispositif sur plusieurs niveaux d'abstraction. Elle apporte en outre l'avantage d'une modularité accrue et d'une meilleure structuration. Le mécanisme de gestion du clavier, que nous étudierons dans cette section, fournit un exemple de traitement en cascade.
A chaque fois qu'une touche d'un clavier est appuyée, on peut considérer qu'elle passe d'un état faux à un état vrai. Ces changements d'états sont traduits par le clavier en codes touches, qui à leur tour sont convertis en symboles dont la combinaison est interprétée comme une chaîne de caractères dans l'éditeur de texte.
Cette série de traitements peut être représentée par une chaîne de dispositifs
allant du dispositif concret au dispositif de l'application (figure
3.6) [Fekete and Dragicevic, 2000]. Chaque adaptateur convertit les
données qu'il reçoit dans son format propre. Le générateur de codes touches
associe à chaque touche du clavier un code positionnel. Le générateur de
symboles traduit les codes touches en symboles, selon la langue du clavier.
Enfin, le générateur de caractères traduit les symboles en chaînes de
caractères, selon une méthode d'entrée spécifique. Il permet par exemple de
composer des lettres accentuées telles que Ê, ou de produire n'importe
quel caractère spécial en utilisant la touche Alt et les touches du pavé
numérique.
La figure 3.7 illustre un exemple de traitement en cascade dans une technique de défilement de document: les données en provenance d'un dispositif souris concret sont converties en coordonnées écran pour contrôler un dispositif curseur, puis encore traitées pour déplacer une barre de défilement. Ici, l'ajout de deux dispositifs « virtuels », l'utilisateur et le document permet de mettre en évidence un flux d'informations implicite: l'utilisateur contrôle la souris, le curseur émet des informations visuelles en destination de l'utilisateur, et la barre de défilement (ici, le point d'entrée vers l'application) manipule un document (caché dans l'application) qui émet à son tour des informations visuelles vers l'utilisateur.
Le flux d'informations implicite mis ici en évidence expose différents niveaux de feedback vers l'utilisateur. Il montre comment à une cascade explicite de dispositifs peut correspondre une cascade implicite de feedback orientée en sens inverse.
![\includegraphics[scale=0.4]{connexions_foley2}](img137.png)
![\includegraphics[scale=0.8]{cascade_clavier1}](img138.png)
![\begin{figure}
\begin{center}
\includegraphics[scale=0.3]{feedback2}
\end{center}
\end{figure}](img139.png)