Memoire Final

U NIVERSIT DE N ANTES
COLE DOCTORALE
S CIENCES ET T ECHNOLOGIES
DE LI NFORMATION ET DES
M ATRIAUX
Anne : 2004
N0 B.U. :
Thse de Doctorat de lUniversit de Nantes

Spcialit : I NFORMATIQUE
Prsente et soutenue publiquement par
Pierre D RAGICEVIC
le 9 mars 2004
lcole Nationale Suprieure
des Techniques Industrielles et des Mines de Nantes
Un modle dinteraction en entre

pour des systmes interactifs multi-dispositifs
hautement congurables
Jury :
Prsident
Rapporteurs
Examinateur
:
:
:
:
Directeur de thse
Laboratoire
Co-encadrant
Laboratoire
Henri B RIAND
Michel B EAUDOUIN -L AFON
Philippe PALANQUE
Stphane C HATTY
:
:
:
:
Professeur, Universit de Nantes

Professeur, Universit Paris-Sud
Professeur, Universit Toulouse 3
Intuilab, Toulouse
Grard H GRON
CERMA, CNRS UMR 1563, Universit de Nantes
Jean-Daniel F EKETE
INRIA Unit de Recherche Futurs
No ED 0366-
Table des matires

Introduction
vii
1 Linteraction en entre non standard

1.1
Les dispositifs dentre non standard . . . . . . . . . . . . . . . . . . . . . . . . . .
Des dispositifs adapts la tche . . . . . . . . . . . . . . . . . . . . . . . .
Des dispositifs adapts lutilisateur . . . . . . . . . . . . . . . . . . . . . .
1.2.3
Des dispositifs adapts lenvironnement . . . . . . . . . . . . . . . . . . .
11
1.2.4
Lvolution de lquipement grand public . . . . . . . . . . . . . . . . . . .
13
Nouveaux paradigmes dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.1
Objectifs et enjeux des interfaces post-WIMP . . . . . . . . . . . . . . . . .
15
1.3.2
Linteraction gestuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.3.3
Les outils semi-transparents . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.3.4
Linteraction parallle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.3.5
La ralit mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Linteraction non-standard dans linformatique grand public . . . . . . . . . . . . .
25
1.4.1
Ncessit dune interaction adaptable . . . . . . . . . . . . . . . . . . . . .
26
1.4.2
Dnition de ladaptabilit en entre . . . . . . . . . . . . . . . . . . . . . .
29
1.4.3
1.5
1.2.2
1.4
Linteraction en entre et son vocabulaire . . . . . . . . . . . . . . . . . . .
1.2.1
1.3
1.1.1
1.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptabilit des systmes interactifs actuels . . . . . . . . . . . . . . . . . .
30
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2 Modles et outils pour linteraction en entre
35
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.2
Les modles dinterface de rfrence . . . . . . . . . . . . . . . . . . . . . . . . . .
36
TABLE DES MATIRES

2.2.1
Les modles dinterface formels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Les systmes de transition . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Les interacteurs formels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Les modles de dispositifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
2.4.1
Les modles logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
2.4.2
Les modles physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
2.4.3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Les modles dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
2.5.1
La manipulation directe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
2.5.2
Linteraction instrumentale . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.5.3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Les outils de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.6.1
Les botes outils WIMP avances . . . . . . . . . . . . . . . . . . . . . .
61
2.6.2
Les botes outils Post-WIMP spcialises . . . . . . . . . . . . . . . . . .
67
2.6.3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Les diteurs graphiques dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . .
79
2.7.1
Les paradigmes de programmation visuelle . . . . . . . . . . . . . . . . . .
79
2.7.2
Les diteurs de simulations interactives . . . . . . . . . . . . . . . . . . . .
80
2.7.3
Les diteurs de comportements 3D . . . . . . . . . . . . . . . . . . . . . . .
85
2.7.4
2.8
43
2.3.3
2.7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
2.6
40
2.3.1
2.5
Les modles agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3
2.4
37
2.2.2
2.3
Les modles linguistiques . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
3 Introduction au modle des congurations dentre
93
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.2
Le paradigme des dispositifs en cascade . . . . . . . . . . . . . . . . . . . . . . . .
94
3.2.1
La mtaphore de la connexion logicielle . . . . . . . . . . . . . . . . . . . .
94
3.2.2
Points dentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
3.2.3
Adaptateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
3.2.4
Dispositifs gnraliss . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
ii
TABLE DES MATIRES

3.2.5
Les systmes ractifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
Systmes ractifs et conversationnels . . . . . . . . . . . . . . . . . . . . .
99
3.3.2
Pour une gestion ractive de linteraction . . . . . . . . . . . . . . . . . . . 100
3.3.3
3.4
98
3.3.1
3.3
Cascades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le modle du synchronisme parfait . . . . . . . . . . . . . . . . . . . . . . 100
Les congurations dentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.4.1
3.4.2
Les notions essentielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.4.3
3.5
Les briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Aperu du modle dexcution . . . . . . . . . . . . . . . . . . . . . . . . . 106
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4 La bote outils dentres ICON
109
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2
Les dispositifs dICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.2.1
4.2.2
Les dispositifs utilitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.3
Les dispositifs de bote outils graphique . . . . . . . . . . . . . . . . . . . 114
4.2.4
4.3
Les dispositifs systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Les dispositifs dapplication . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Programmation avec ICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.3.1
4.3.2
Initialisation dune conguration . . . . . . . . . . . . . . . . . . . . . . . . 121
4.3.3
4.4
Implmentation de nouveaux dispositifs . . . . . . . . . . . . . . . . . . . . 118
Srialisation et descripteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Construction et dition de congurations dentre . . . . . . . . . . . . . . . . . . . 127

4.4.1
Lditeur de congurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.4.2
Des congurations standard aux congurations hautement interactives . . . . 131
4.4.3
Congurations dentre pour laccessibilit . . . . . . . . . . . . . . . . . . 135
4.4.4
Les techniques dinteraction avances et novatrices . . . . . . . . . . . . . . 136
4.5
Distribution, contributeurs, et projets utilisant ICON . . . . . . . . . . . . . . . . . . 141
4.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5 Discussion
145
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.2
Les apports dICON du point de vue architectural . . . . . . . . . . . . . . . . . . . 147

iii
TABLE DES MATIRES

5.2.1
5.2.2
Les niveaux daccs et de contrle dICON . . . . . . . . . . . . . . . . . . 148
5.2.3
5.3
Architecture concrte des systmes interactifs . . . . . . . . . . . . . . . . . 147
Une gestion des entres entirement explicite . . . . . . . . . . . . . . . . . 150
Pertinence du modle pour les interactions Post-WIMP . . . . . . . . . . . . . . . . 151

5.3.1
5.3.2
Prise en compte des dispositifs non conventionnels . . . . . . . . . . . . . . 154
5.3.3
5.4
Limitations du langage et pouvoir dexpression . . . . . . . . . . . . . . . . 152
Description de techniques dinteraction non conventionnelles . . . . . . . . . 155
Complexit et lisibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.4.1
5.4.2
Les limites du tout-visuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.4.3
5.5
Le rle de la structuration spatiale . . . . . . . . . . . . . . . . . . . . . . . 157
Complexit et nature de linteraction . . . . . . . . . . . . . . . . . . . . . . 160
Caractrisation des diffrents types de dispositifs . . . . . . . . . . . . . . . . . . . 161

5.5.1
5.5.2
Les dispositifs dapplication et de bote outils . . . . . . . . . . . . . . . . 163
5.5.3
5.6
Les dispositifs systme dentre . . . . . . . . . . . . . . . . . . . . . . . . 162
Les dispositifs utilitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Dvelopper avec ICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

5.6.1
5.6.2
Connexion avec les outils et applications existantes . . . . . . . . . . . . . . 169
5.6.3
La rutilisabilit des congurations . . . . . . . . . . . . . . . . . . . . . . 171
5.6.4
La prise en charge effective des dispositifs dans ICON . . . . . . . . . . . . 172
5.6.5
5.7
Matriser un nouveau paradigme de programmation . . . . . . . . . . . . . . 166
Les performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Les utilisateurs dICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

5.7.1
5.7.2
Les utilisateurs avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.7.3
Utilisateurs scientiques et informaticiens . . . . . . . . . . . . . . . . . . . 176
5.7.4
Dveloppeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.7.5
5.8
Un continuum dutilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Le cycle de vie dune conguration . . . . . . . . . . . . . . . . . . . . . . 177
Positionnement de notre approche et perspectives . . . . . . . . . . . . . . . . . . . 177

5.8.1
ICON et les autres approches . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.8.2
Quelques perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Conclusion et perspectives
187
iv
TABLE DES MATIRES

Remerciements
193
A Structure dune conguration dentre
195
A.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

A.2 Les quatre briques de base et leurs attributs . . . . . . . . . . . . . . . . . . . . . . 197
A.2.1 Dispositifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
A.2.2 Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
A.2.3 Connexions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
A.2.4 Conguration dentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
A.3 Les connexions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
A.3.1 Contraintes sur les connexions . . . . . . . . . . . . . . . . . . . . . . . . . 201
A.3.2 Types et sous-typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
A.3.3 Attributs de connexions drivs des slots . . . . . . . . . . . . . . . . . . . 202
A.3.4 Attributs de slots drivs des connexions . . . . . . . . . . . . . . . . . . . 203
A.3.5 Graphe de dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
A.4 Composition de dispositifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
A.4.1 Slots externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
A.4.2 Connexions externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
A.4.3 Dispositifs composites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
A.4.4 Composition et dcomposition . . . . . . . . . . . . . . . . . . . . . . . . . 207
A.4.5 Slots i-connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
B Aspects dynamiques dune conguration dentre
211
B.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

B.2 Dnitions prliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
B.2.1
Types de slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
B.2.2
Identiants et valuations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
B.2.3
Paramtrages et m-paramtrages de dispositifs . . . . . . . . . . . . . . . . 213
B.2.4
Fonction de mutation et consistance . . . . . . . . . . . . . . . . . . . . . . 214
B.3 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

B.3.1
Mutation dun dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
B.3.2
Propagation des mutations . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
B.3.3
Propagation borne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

v
TABLE DES MATIRES

B.3.4
Exemples de fonctions de mutation . . . . . . . . . . . . . . . . . . . . . . 218
B.4 Oprations sur les congurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

B.4.1
Oprations lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
B.4.2
Oprations consistantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
C Excution dune conguration dentre
223
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

C.2 Dnitions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
C.2.1
Signaux valus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
C.2.2
Historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
C.2.3
Signaux valus multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
C.2.4
Processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
C.2.5
Fonction dexcution dun dispositif . . . . . . . . . . . . . . . . . . . . . . 226
C.3 Lancement et excution dune conguration . . . . . . . . . . . . . . . . . . . . . . 227

C.3.1
Codage des signaux dentre et des processeurs . . . . . . . . . . . . . . . . 228
C.3.2
Cration des valeurs et ouverture des dispositifs . . . . . . . . . . . . . . . . 229
C.3.3
Construction de la machine ractive . . . . . . . . . . . . . . . . . . . . . . 229
C.4 Algorithme dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

C.4.1
Mise jour dun processeur . . . . . . . . . . . . . . . . . . . . . . . . . . 230
C.4.2
La boucle dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
C.5 Lenvironnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

C.5.1
Communication avec lenvironnement : non-dterminisme et effets de bord . 232
C.5.2
Ouverture non-dterministe des dispositifs . . . . . . . . . . . . . . . . . . 233
C.5.3
Lhypothse ractive dans ICoM . . . . . . . . . . . . . . . . . . . . . . . . 233
Bibliographie
249
vi
Introduction
Dautres manires de contrler nos ordinateurs

Linformatique na cess de progresser depuis les premiers calculateurs jusquaux micro-ordinateurs
modernes. Aujourdhui, si les machines de nos foyers continuent voir leur puissance de calcul et
leurs capacits graphiques crotre danne en anne, leur volution parat avoir atteint un point satisfaisant sous bien dautres aspects. En particulier, nous sommes tous habitus taper sur un clavier et
cliquer sur des boutons, ouvrir des menus ou dplacer des icnes avec une souris : notre faon de
contrler les ordinateurs sest standardise, et rien ne semble apparemment en voie de compromettre
ces standards sur lesquels saccordent la fois les fabricants de matriel, les diteurs de logiciels et la
plupart des utilisateurs.
Il existe nanmoins bien dautres manires de contrler des applications interactives. Les manettes
de jeu sont dusage courant, et les ordinateurs de poche modernes sont en train de dmocratiser lemploi du stylet. Des dispositifs dentre moins connus tels que les tablettes graphiques, les instruments
de musique lectroniques ou les contrleurs 3D sont depuis longtemps exploits dans le monde professionnel ou semi-professionnel. Enn, les utilisateurs pour lesquels lusage dun clavier ou dune
souris est difcile voire impossible emploient galement des dispositifs dentre spcialiss.
Au-del de leur grande varit, les dispositifs dentre alternatifs possdent tous un point commun : ils sont particulirement adapts un contexte donn, cest--dire certains types dutilisateurs
(handicaps moteurs, par exemple), de tches (jeux vido ou conception graphique) ou denvironnements de travail (environnement mobile). Ces dispositifs non conventionnels sont indispensables
dans la mesure o les dispositifs standard ne sont pas toujours pertinents. De nombreux travaux de
recherche ont de plus montr quil tait toujours possible de rendre linteraction plus naturelle et plus
productive par lusage de dispositifs dentre ddis au contexte.
vii
INTRODUCTION
Parmi les nombreux dispositifs dentre existants, le clavier et la souris bncient dun statut
particulier en tant que dispositifs gnriques. Ils ont t conus pour tre efcaces dans la plupart des
situations courantes : un environnement de travail de type bureau, un utilisateur moyen , et des
tches courantes comme la saisie dun courrier ou la navigation sur Internet. Or ces dispositifs sont
en ralit peu efcaces, quelle que soit la tche, car ils nexploitent que partiellement nos capacits
motrices et nous obligent des manipulations squentielles plutt que parallles.
Nous utilisons nos deux mains dans presque toutes nos tches quotidiennes et sommes par ailleurs
capables dapprendre coordonner efcacement un grand nombre de groupes musculaires (pour jouer
dun instrument ou conduire une voiture, par exemple). Nos doigts possdent galement des capacits
motrices exceptionnelles. Sur un ordinateur, ces capacits sont assez bien exploites pour la saisie
textuelle mais trs peu pour la manipulation dobjets graphiques. La parole constituerait galement
un complment efcace au contrle moteur. Ces ides ont t depuis longtemps conrmes par des
travaux de recherche, qui montrent quune interaction rellement efcace passe par la multiplication
et la diversication des dispositifs dentre.
Si la qualit de linteraction repose pour beaucoup sur la partie physique de linterface, elle
dpend galement de la faon dont les dispositifs physiques sont exploits au niveau logiciel. Actuellement, utiliser une souris est synonyme de cliquer, double-cliquer ou effectuer des cliquer-glisser sur
des boutons, barres de dlement et autres menus. Le vocabulaire est limit, et les lments graphiques
standardiss ont montr leurs faiblesses : ils entravent la tche relle (rdaction dun document, par
exemple) en occupant de la place et en imposant des dplacements rpts de lattention visuelle. L
encore, de nouvelles approches, visant rendre linteraction plus concise et plus directe, ont t proposes dans bon nombre de travaux de recherche, et prouvent que mme linteraction la souris est
susceptible dtre considrablement amliore.
Des systmes interactifs encore gs

Les standards en Interaction Homme-Machine sont souhaitables car il en dcoule une rutilisabilit qui prote aux programmeurs dapplications, et une cohrence qui prote, dans une certaine
mesure, aux utilisateurs. Nos interfaces actuelles, avec leurs souris, icnes et fentres sinspirent principalement du systme Xerox Star, initialement issu de la recherche. Cependant, ce systme est maintenant vieux de plus de vingt ans et la recherche en IHM a eu le temps dexplorer, mettre en uvre
et tester des mthodes dinteraction alternatives adaptes aussi bien aux situations les plus courantes
qu des contextes trs spciques.
Ces recherches montrent quel point les interfaces dites modernes sont, du point de vue de lutilisabilit, au mieux inefcaces, au pire totalement inadaptes. Elles prouvent galement que pour une
interaction plus naturelle, productive, personnalisable et accessible aux utilisateurs handicaps, il est
essentiel que nos systmes informatiques puissent tre librement contrls avec des dispositifs dentre multiples et varis, dune manire qui prenne en compte les spcicits des dispositifs et les
besoins de lutilisateur.
Malheureusement, les standards ont si profondment structur les systmes interactifs quil est
maintenant difcile de sen dfaire. Alors que certains dispositifs dentre non conventionnels deviennent de plus en plus abordables (tablettes graphiques, webcams, microphones) et de plus en plus
faciles installer, leur prise en charge effective par les systmes interactifs reste quasi-inexistante : la
plupart des dispositifs sont ignors par la majorit des applications (les manettes ne servent que dans
viii
INTRODUCTION
les jeux), et les autres sont sous-exploits (la tablette graphique est vue comme une souris, sa haute
prcision et sa sensibilit la pression sont occultes). Rciproquement, une application est trs difcile, voire impossible utiliser lorsquun dispositif standard manque, ce qui constitue un problme
majeur pour laccessibilit aux handicaps et la portabilit des applications entre les plate-formes de
diffrente nature.
Les applications interactives sont excessivement ges du point de vue de linteraction parce
quelles sont construites avec des outils qui sont tous cbls pour une utilisation exclusive et strotype dun clavier et dune souris. La prise en charge de dispositifs dentre non conventionnels
est en consquence extrmement difcile mettre en uvre par les programmeurs. Les innovations
proposes par la recherche, comme linteraction gestuelle ou vocale, sont pour les mmes raisons trs
rarement employes dans les applications commerciales.
Une problmatique de recherche relle

Un des objectifs de la recherche en IHM consiste concevoir, prototyper et dterminer lutilisabilit dinterfaces novatrices, approche qui a donn de nombreux rsultats, dont venons de tirer des
conclusions. Un autre objectif, essentiel et complmentaire, vise produire des modles et des outils
qui facilitent la construction de ce type dinterfaces. La tche est loin dtre triviale et malgr des
avances importantes, les rsultats obtenus ne sont pas la hauteur des esprances.
Il a fallu dj consacrer une bonne partie des efforts la comprhension et la modlisation des
interfaces conventionnelles, pour lesquelles nous ne disposons toujours pas de modle et doutil de
construction idal. Les recherches se donnant pour but de faciliter la construction dinterfaces non
conventionnelles constituent quant elles un domaine encore trs jeune. En outre, les aspects sorties de linteraction (qui concernent principalement la reprsentation dobjets abstraits destination
de lutilisateur et la prise en charge deffets graphiques sophistiqus) ont assez curieusement suscit bien plus de travaux que les aspects entres (qui dcrivent la manipulation de ces objets par
lutilisateur), pourtant essentiels.
Dans les travaux portant sur les entres non conventionnelles, lintrt sest principalement focalis sur la mise en uvre dune communication langagire avec des interfaces intelligentes , en
abordant des problmes de haut niveau tels que linterprtation des intentions de lutilisateur partir
de sources dinformation htrognes ou la prise en charge de lambigut. Malgr la complexit de
ces problmes et lapport indniable des contributions existantes, trop dapproches continuent de sappuyer sur des modles dentre vieux de plusieurs dcennies ou en reproduire les mmes hypothses
simplicatrices, et mnent invariablement des systmes plus volus mais tout aussi gs.
Actuellement, aucun modle et aucun outil ne permet dexploiter toute la richesse offerte par
les dispositifs dentre et noffre assez de exibilit pour pouvoir prendre en compte des contextes
dutilisation trs divers.
Les objectifs de cette thse

Notre objectif dans cette thse est de proposer des modles et des outils permettant de construire
des systmes interactifs entirement ouverts en entre, cest--dire des systmes qui puissent tre
contrls avec une grande varit de dispositifs dentre, dune manire qui permette dexploiter au
mieux leurs capacits.
ix
INTRODUCTION
Nous pensons quune approche moderne se doit de mettre laccent sur une interaction la fois
riche et accessible, en encourageant lusage simultan de dispositifs physiques multiples tout en offrant une prise en charge adapte pour les entres appauvries, cest--dire plus limites que les dispositifs standard. Nous prnons galement des systmes volutifs et congurables, cest--dire non
limits des classes ges de dispositifs et de modles dinteraction connus, et quil est possible
dadapter nement aux particularits de lutilisateur, de la tche et de lenvironnement.
Nos contributions
Dans notre thse, nous introduisons et motivons un modle original pour la description et la gestion de linteraction en entre, qui sappuie sur la notion de congurations dentre. Une conguration
dentre dcrit la faon dont des dispositifs physiques sont connects une application travers des
adaptateurs. En remplaant lapproche vnementielle traditionnelle par un paradigme ot de donnes ractif, ce modle rend la gestion des entres entirement explicite, du dispositif physique jusqu
lapplication. Il encourage en outre la description dinteractions novatrices et hautement concurrentes.
Le modle des congurations dentre a inspir le dveloppement du systme ICON (Input Congurator), qui permet de construire des applications interactives entirement congurables en entre et
capables dexploiter des dispositifs et des techniques dinteraction conventionnels ou non. Lditeur
interactif dICON donne la possibilit aux dveloppeurs de prototyper et de tester un grand nombre
de congurations dentre potentielles an de rendre leurs applications adaptes des situations spciques dentres appauvries ou enrichies. Lutilisateur nal slectionne la conguration dentre qui
correspond son matriel et ses prfrences personnelles, et peut galement, selon son degr dexpertise, personnaliser cette conguration pour ladapter ses besoins.
Organisation de ce mmoire
Dans le chapitre 1 - Linteraction en entre non standard, nous donnons un large aperu des
dispositifs dentre non conventionnels existants et des contextes dans lesquels ils sont employs,
et prsentons les principales techniques connues permettant dinteragir avec les applications de faon plus efcace et plus naturelle. Nous montrons ensuite en quoi il est essentiel que nos applications
puissent tre contrles de diverses manires, pour une interaction de meilleure qualit et mieux adapte des utilisateurs, des environnements et des tches trs varis.
Dans le chapitre 2 - Modles et outils pour linteraction en entre, nous dtaillons ltat actuel
de la recherche du point de vue de linteraction en entre. Nous prsentons les principaux modles
dinterface et les outils de dveloppement exprimentaux, et dterminons en quoi ils constituent ou
non une avance par rapport aux modles et aux outils conventionnels. Nous concluons par les apports
respectifs de chacune de ces contributions.
Dans le chapitre 3 - Introduction au modle des congurations dentre, nous prsentons notre
modle pour la description de linteraction en entre, aprs avoir dvelopp et motiv du point de vue
conceptuel les principales notions sur lesquelles il repose.
Dans le chapitre 4 - La bote outils ICON, nous dcrivons le systme ICON, dvelopp dans
le but de valider et dafner notre modle dans un contexte rel de dveloppement. Aprs avoir prsent cet outil et ses principales fonctionnalits, nous dcrivons et commentons un certain nombre
x
INTRODUCTION
dexemples dinteractions non conventionnelles quil a permis de dcrire. Nous concluons par les
applications actuelles dICON.
Dans le chapitre 5 - Discussion, nous tentons de rpondre aux nombreuses questions poses
par notre approche, en identiant tout dabord les apports essentiels dICON et de son modle sousjacent, ainsi que leurs limites. Nous afnons et gnralisons par ailleurs quelques aspects de notre
approche, sur la base des enseignements que nous avons pu tirer de notre utilisation dICON. Pour
nir, nous positionnons nos travaux par rapport aux contributions existantes et dveloppons quelques
perspectives.
Dans les annexes A, B et C, nous dtaillons les mcanismes la base du modle des congurations dentre.
La lecture de ce mmoire de thse ne devrait pas ncessiter de connaissances thoriques particulires en IHM. Une certaine pratique dans le dveloppement dinterfaces est cependant requise pour
aborder la plupart des discussions, en particulier dans le chapitre 2 et le chapitre 5. Les annexes rclament des connaissances mathmatiques et algorithmiques trs minimales. Le chapitre 1, et dans
une moindre mesure le chapitre 3, nappellent aucun pr-requis et sufsent se faire une ide trs
gnrale du contexte et de notre approche.
xi
INTRODUCTION
xii
Chapitre 1
Linteraction en entre non standard

Sommaire
1.1
1.2
1.3
1.4
1.5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Linteraction en entre et son vocabulaire . . . . . . . .
Les dispositifs dentre non standard . . . . . . . . . . . . .
1.2.1 Des dispositifs adapts la tche . . . . . . . . . . . . .
1.2.2 Des dispositifs adapts lutilisateur . . . . . . . . . . .
1.2.3 Des dispositifs adapts lenvironnement . . . . . . . .
1.2.4 Lvolution de lquipement grand public . . . . . . . .
Nouveaux paradigmes dinteraction . . . . . . . . . . . . . .
1.3.1 Objectifs et enjeux des interfaces post-WIMP . . . . . .
1.3.2 Linteraction gestuelle . . . . . . . . . . . . . . . . . .
1.3.3 Les outils semi-transparents . . . . . . . . . . . . . . .
1.3.4 Linteraction parallle . . . . . . . . . . . . . . . . . .
1.3.5 La ralit mixte . . . . . . . . . . . . . . . . . . . . . .
Linteraction non-standard dans linformatique grand public
1.4.1 Ncessit dune interaction adaptable . . . . . . . . . .
1.4.2 Dnition de ladaptabilit en entre . . . . . . . . . . .
1.4.3 Adaptabilit des systmes interactifs actuels . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
5
5
8
11
13
15
15
16
19
20
23
25
26
29
30
33
CHAPITRE 1. LINTERACTION EN ENTRE NON STANDARD
1.1 Introduction
Lobjectif de ce chapitre est de donner au lecteur un aperu de la grande varit des dispositifs
dentre, produits commerciaux ou prototypes de recherche, et des contextes dans lesquels leur emploi est pertinent. Nous dcrivons ensuite, de faon plus gnrale, de nouveaux moyens dinteragir
avec les applications, de manire plus naturelle et efcace. Puis, nous montrons lintrt dexploiter
ces diverses techniques dans nos applications conventionnelles, et plus gnralement, pourquoi il est
essentiel quun systme interactif puisse sadapter nimporte quel type dentre. Nous nissons par
montrer en quoi nos ordinateurs actuels ne rpondent pas cette attente.
Avant de commencer, nous prsentons rapidement notre domaine dtude en introduisant les principaux termes qui nous seront utiles par la suite.
1.1.1
Linteraction en entre et son vocabulaire
Certains termes et concepts que nous allons introduire dans cette section sont dans la littrature
scientique plutt quivoques. Notre objectif nest pas de rpertorier et de confronter les dnitions
existantes ni de prtendre lexactitude, mais bien de proposer un vocabulaire minimal cohrent qui
nous sera utile pour structurer la suite de notre discours.
Linteraction en entre
Il est courant de distinguer dans linteraction homme-machine les entres (ux dinformations allant de lhomme vers la machine) des sorties (ux dinformations allant de la machine vers lhomme).
Cette distinction est parfois critique, raison, sur la base dun lien troit entre les entres et les
sorties [H INCKLEY et al. 03] : en premier lieu, tout contrle ncessite un feedback ou retour utilisateur1
(une souris sans pointeur nest pas utilisable). Ensuite, la faon dont sont reprsents les objets de
lapplication joue considrablement sur la faon dont ils peuvent tre contrls (une reprsentation
graphique, en particulier, encouragera les techniques de pointage).
Malgr tout, il apparat clairement dans la littrature scientique que si certains domaines sattachent principalement la reprsentation de donnes, dautres problmatiques et dautres aspects
de linteraction sont concerns par leur manipulation [B UXTON 86 B]. Ce sont ces derniers aspects que
recouvre le terme dinteraction en entre, et que nous dcrivons par la suite.
Composantes de linteraction en entre

Dispositif dentre. Un dispositif dentre est un appareil physique contrl par lutilisateur et qui
met des informations vers lordinateur. Ceci inclut les priphriques comme le clavier et la souris,
et exclut les priphriques de stockage2 . Pour viter certaines lourdeurs, nous emploierons parfois le
terme simpli de dispositif. (Synonymes : priphrique dentre, priphrique de saisie.)
1 Rtroaction est peut-tre la traduction la plus exacte de feedback, mais elle est rarement employe en IHM. Dans
ce domaine, feedback signie en gnral user feedback, qui se traduit assez bien par retour utilisateur. Cependant, nous
prfrerons le raccourci de feedback au simple mot retour.
2 En anglais, le terme human input device (HID) est parfois prfr input device lorsquune confusion est possible.
1.1. INTRODUCTION
Technique dinteraction. Une technique dinteraction dcrit la manire de se servir dun dispositif dentre pour accomplir une tche sur lordinateur [F OLEY et al. 90]. Par exemple, un chier peut tre
supprim la souris, soit laide dun menu contextuel, soit par glisser-dposer dans la corbeille. En
pratique, une technique dinteraction transforme, interprte des donnes et produit le feedback ncessaire lutilisateur. Les techniques dinteraction sont le plus souvent caractrises de faon abstraite
et gnrique : par exemple, le menu contextuel et le glisser-dposer ne sont pas particulirement lis
un dispositif spcique3 , ni la tche spcique de suppression de chiers. (Synonymes : mthode
dinteraction, technique dentre).
Paradigme dinteraction. Un paradigme dinteraction est un ensemble cohrent de techniques
dinteraction qui cooprent de faon troite, ou qui reposent sur les mmes principes techniques ou
conceptuels. titre dexemple, le paradigme dinteraction WIMP4 regroupe des techniques comme
le pointage et les menus. Quand au paradigme de linteraction bimanuelle, il dsigne des techniques
dinteraction exploitant lusage simultan des deux mains. (Synonyme : style dinteraction.)
Linteraction standard
Linteraction standard dcrit lensemble des paradigmes dinteraction actuellement employs
sur les micro-ordinateurs grand public pour permettre un contrle gnrique des applications par
lusage des dispositifs dentre standard que sont le clavier et la souris.
La liste des paradigmes dinteraction standard qui suit est inspire du traditionnel historique des
styles dinteraction [P REECE et al. 94], dans lequel nous avons remplac la manipulation directe par le
paradigme dinteraction WIMP :
Les langages de commande : Interfaces textuelles du type MS-DOS ou terminal Unix o des
commandes sont saisies au clavier. Les diffrentes commandes possibles ne sont pas explicites
et ncessitent une mmorisation.
Les systmes de menus : Un menu est la prsentation dune liste de choix dans laquelle lutilisateur opre une slection au clavier ou par pointage. Une bote de dialogue du type "tes-vous
sr ? oui/non" est assimilable un menu. Un assistant est une succession de menus o la navigation est contrle par le systme.
Les formulaires : Les formulaires complter tendent les systmes de menus en ajoutant des
champs de texte quil est possible de renseigner. Les tableurs en sont une version fonctionnellement plus sophistique.
Linteraction WIMP : Linteraction WIMP est une version standardise et appauvrie du paradigme de la manipulation directe, qui dcrit des interfaces donnant lillusion de travailler
directement sur les objets de la tche plutt que de transmettre des commandes une machine
[S HNEIDERMAN 83, H UTCHINS et al. 86] (ce modle dinteraction sera dcrit dans la section 2.5.1
page 56). Le paradigme de la manipulation directe ne constitue pas un standard mais dcrit les
caractristiques idales de linteraction graphique. Nous dsignons linteraction WIMP comme
tant une combinaison des trois paradigmes dinteraction suivants :
Le glisser-dposer5 : La mtaphore du bureau, popularise par les systmes Macintosh, est
3 Dautres
dispositifs que la souris permettent deffectuer des tches similaires. Nous en voquerons quelques-uns plus
loin.
4 WIMP : Windows, Icons, Mouse, Pull-down menus (fentres, icnes, souris, menus droulants). Terme employ pour
dsigner les interfaces daujourdhui, parfois dans un sens pjoratif.
5 En anglais, drag-and-drop. Le cliquer-glisser dsigne le geste lui-mme.

souvent considre comme lexemple-type de la manipulation directe : les chiers sont des
objets graphiques nomms icnes et les commandes (dplacer, effacer) seffectuent principalement par des cliquer-glisser dune icne vers un objet sensible (autre icne ou conteneur).
Cette technique est galement employe comme mcanisme de communication entre les fentres.
Le fentrage : Les fentres sont des zones rectangulaires de lcran qui sont agenables et
superposables. Lutilisateur choisit la fentre active qui sera lobjet de linteraction. Les documents dans les applications multi-documents reposent sur le mme principe. Le fentrage
met en avant lagencement graphique et le libre accs des applications et des documents
multiples, mais avec une notion dexclusivit.
Les widgets6 : Les widgets sont des objets interactifs gnriques. En gnral regroups dans
des barres doutils elles-mmes contenues dans des fentres, ils comprennent les boutons,
les barres de dlement, les cases cocher, ainsi que les menus et les champs texte dcrits
prcdemment (gure 1.1). Le paradigme des widgets met en avant les aspects dorganisation
spatiale des objets dintrt, laccs direct ces objets, et leur manipulation gnrique.
F IG . 1.1 Quelques widgets standard des nouveaux systmes Apple
[A PPLE 02].
Les interfaces actuelles sinspirent principalement du paradigme WIMP, mais emploient toujours
des formulaires, des systmes de menus et plus rarement, des langages de commande. Lomniprsence des widgets provient principalement de la rapidit avec laquelle elles permettent de construire
des applications interactives. linverse, la manipulation directe proprement parler (cest--dire la
manipulation dobjets sans widgets intermdiaires), ddie la tche, est plus difcile mettre en
uvre et nest employe que lorsque les widgets se rvlent insufsants (infographie, jeux). Les types
de widgets existants sont en nombre limit, et leur apparence (look) et la faon de les contrler (feel)
6 Contraction approximative de Window Objects. Le terme interactor et en particulier sa traduction franaise interacteur sont galement employs, mais dsignent des concepts diffrents dans certains formalismes et outils, et peuvent
par consquent prter confusion. La confusion est plus grande encore avec les appellations control/contrle ou component/composant. Nous leur prfrerons donc le terme original de widget.
1.2. LES DISPOSITIFS DENTRE NON STANDARD

sont standardiss (gure 1.1 page ci-contre). Ils obissent un vocabulaire gestuel simple, comprenant
le pointage, le clic, le double-clic et le cliquer-glisser, avec parfois lemploi de touches modicatrices.
1.2 Les dispositifs dentre non standard

La partie physique de linterface est celle avec laquelle lutilisateur a le contact le plus direct, et
les dispositifs dentre contribuent grandement limage mentale que celui-ci se fait dun lordinateur
[B UXTON 86 B].
Depuis plusieurs annes, la conguration des ordinateurs de bureau na gure volu, et le clavier
et la souris sont depuis longtemps devenus des dispositifs standard. Bien que cette standardisation
puisse sembler souhaitable, il existe un grand nombre de situations o il est prfrable, voire ncessaire, davoir recours des dispositifs non standard. De nombreux travaux ont notamment montr
quil tait essentiel que les dispositifs dentre soient adapts aux tches accomplir, ainsi quaux
utilisateurs et lenvironnement de travail.
Cette section a pour but de donner au lecteur un aperu de la grande varit des dispositifs dentre non standard, produits commerciaux ou prototypes de recherche, ainsi que les contextes dans
lesquels leur emploi est pertinent. Cette prsentation sera organise autour des trois thmes prcdemment cits : tches, utilisateurs et environnement. Pour complter, nous voquerons les volutions
et tendances actuelles concernant les quipements personnels.
1.2.1
Des dispositifs adapts la tche
Le clavier et la souris sont des dispositifs dentre gnriques qui permettent de communiquer avec
une grande varit dapplications. Il existe nanmoins un grand nombre de tches pour lesquelles ces
dispositifs ne sont pas adapts. Nous voquerons deux domaines applicatifs o cette inadquation
suscite frquemment lemploi de dispositifs ddis : la modlisation 3D et les jeux vido. Par la suite,
nous verrons plus prcisment en quoi un dispositif peut tre adapt ou non une tche, et comment
les exigences dune bonne adquation justient limmense varit de dispositifs dentre existants.
Les dispositifs ddis dans la modlisation 3D et les jeux

Six paramtres sont ncessaires pour dcrire la position et lorientation dun objet dans lespace.
Dans les applications danimation ou de modlisation 3D, on dit que ces objets possdent six degrs
de libert : trois en translation et trois en rotation. La manipulation de ces objets est fastidieuse avec
un dispositif 2D comme la souris, qui ne possde que deux degrs de libert en translation. Lune
des techniques consiste utiliser squentiellement plusieurs modes de manipulation, dans lesquels on
contrle deux dimensions de lobjet la fois.
Il existe sur le march des dispositifs six degrs de libert qui sont couramment utiliss pour les
tches de manipulation 3D (gure 1.2, image de gauche) : moins maniables quun pointeur classique,
ils se rvlent toutefois bien plus efcaces pour le positionnement rapide dun objet dans lespace.
Pour des tches de positionnement plus spciques, la mise en place dune solution adapte peut
se rvler encore plus intressante. La gure 1.2 prsente au centre une technique de manipulation
5
F IG . 1.2 Les six degrs de libert dun dispositif 3D Magellan ( gauche), deux objets physiques munis dun
capteur de position dans une application de planication neuro-chirurgicale (au centre), et un gant de donnes
Cyberglove dImmersion 3D possdant 22 capteurs articulaires ( droite).
dun plan de coupe dans une application de planication neurochirurgicale : des capteurs positionnels 3D7 ont t placs sur deux objets physiques, le premier gurant le plan de coupe et le second
lobjet couper [H INCKLEY et al. 94 A]. Enn, dispositif classique dans le domaine de la 3D, le gant de
donnes possde des capteurs angulaires sur les articulations, ce qui le rend particulirement adapt
lanimation de mains virtuelles (gure 1.2, image de droite). Le domaine de la 3D comprend de
nombreux autres dispositifs ddis, commercialiss ou non, que nous ne pouvons tous numrer ici
[H INCKLEY et al. 94 B, Z HAI 98].
F IG . 1.3 gauche, la borne darcade du jeu Out Run de Sega. droite, une lance incendie comme dispositif
dentre dans le jeu Brave Fire Fighters de Sega.
Le domaine du jeu vido fait galement un usage intensif de dispositifs ddis, en particulier dans
les salles de jeu. Les dispositifs conus pour les simulations de pilotage sinspirent des tableaux de
bord rels de voiture ou davion, et sont bien plus appropris que les contrleurs de jeu gnriques
(gure 1.3, image de gauche). Ces dispositifs ddis permettent un contrle plus efcace du jeu,
mme si la plupart sattachent avant toute chose reproduire des situations relles, an dajouter au
ralisme et augmenter limmersion du joueur. Cest le cas par exemple des simulations de sport de
glisse utilisant comme entre les impulsions du joueur sur une planche, ou des jeux de tir utilisant
des reproductions darmes feu, voire des dispositifs de pointage aussi peu maniables que des lances
incendies (gure 1.3, image de droite).
7 Ces
capteurs transmettent la position et lorientation dun objet physique dans lespace.

Origines dune grande diversit : les exigences de la compatibilit
Le march propose une grande varit de dispositifs dentre pour la plupart inconnus du grand
public, et dans laquelle un concepteur dapplications ddies a la possibilit de puiser pour rendre
linteraction bien plus efcace et naturelle. Cette grande diversit nest pas fortuite, et une erreur
courante consiste croire quil suft de choisir le meilleur dispositif parmi ceux qui font la mme
chose . Dans ses travaux, William Buxton met rgulirement en vidence la difcult dorganiser les
dispositifs en classes dquivalence, et de comparer leurs performances de faon absolue. Selon lui,
chaque dispositif possde des caractristiques propres qui le rendent extrmement efcace pour un
petit nombre de tches, et peu appropri pour les autres [B UXTON 86 B].
F IG . 1.4 Deux types de Tlcran : le Etch-a-Sketch ( gauche) et le Skedoodle ( droite) [BUXTON 86 B].
Pour illustrer ses propos, Buxton prend pour exemple deux variantes du jouet Tlcran (gure 1.4).
La premire comporte deux boutons spars pour le dessin, que la deuxime a intgrs dans une simple
manette. Le second systme pourrait tre considr raison comme une amlioration du premier, car
le dessin y est plus ais. Cependant, le premier systme est bien plus efcace pour le dessin de formes
gomtriques base de traits horizontaux ou verticaux (gure 1.5).
F IG . 1.5 Deux tches de dessin : une gure gomtrique ( gauche) et une criture cursive ( droite)
[B UXTON 86 B].
Cet exemple montre la relative subtilit de la notion de compatibilit entre un dispositif et une
tche. La compatibilit stimulus/rponse, cest--dire le degr de similitude entre les actions physiques
effectues sur le dispositif et les effets quelles produisent sur lapplication, constitue une dimension
importante de cette compatibilit. Une autre dimension importante est la compatiblit des proprits
intrinsques du dispositif, en particulier mcaniques, avec les caractristiques de la tche. Ces notions
seront illustres dans un autre exemple imagin par Buxton.
La gure 1.6 page suivante reprsente deux dispositifs possdant chacun deux dimensions de
translation et une dimension de rotation : une manette avec un manche rotatif mont sur ressort, et un
trackball8 sensible la rotation daxe vertical. Ces deux dispositifs, techniquement compatibles, ont
8 Un
trackball est une sorte de souris retourne. Des mouvements rpts de la main font rouler la boule, qui dplace le
curseur lcran.
F IG . 1.6 Une manette 3D ( gauche) et un trackball 3D ( droite) [BUXTON 86 B].
pourtant des applications diffrentes. Le trackball permet de dplacer un objet lcran de faon trs
naturelle, car les mouvements effectus par la main sont trs fortement lis aux dplacements quelles
produisent sur lobjet. Sur la manette, la position du manche joue sur la vitesse et non sur la position de
lobjet contrl9 , do une plus faible compatibilit stimulus/rponse, et un contrle moins ais. Mais
contrairement la manette, le trackball ne permet pas lutilisation simultane de la translation et de la
rotation. Par consquent la manette, de par ses proprits intrinsques, serait un meilleur choix pour
la navigation dans une interface de type cartographique, o il est intressant de pouvoir se dplacer et
zoomer tout la fois.
Imaginons enn une interface de contrle dans une rafnerie de ptrole, o une partie du systme
est reprsente par des tuyaux et des robinets. Le contrleur peut sil le juge ncessaire, pointer sur un
robinet avec la manette, puis le tourner dans le sens dsir. Lutilisation dune manette sera sujette
des erreurs de manipulation, car il est difcile de tourner le manche sans agir sur les autres dimensions.
Le trackball est linverse plus adapt ce type de tche, de par ses proprits intrinsques.
1.2.2
Des dispositifs adapts lutilisateur
Certains dispositifs spcialiss ont t conus pour des utilisateurs qui possdent un savoir-faire
particulier, et leur permettent dtre beaucoup plus efcaces en reproduisant des gestes quils matrisent. Dautres dispositifs ouvrent laccs linformatique aux utilisateurs pour qui la manipulation
dune souris ou dun clavier nest pas possible.
Le transfert dexpertise
Malgr linformatisation rapide du monde du travail, il existe encore des activits pour lesquelles
les bnces dune informatisation classique ne justieraient pas le cot quimposerait la remise en
cause des mthodes de travail traditionnelles. Cest dans ces situations que les dmarches de conception centres sur lutilisateur [N ORMAN & D RAPER 86, M ACKAY et al. 98] prennent toute leur importance,
car elles permettent de maximiser le transfert des savoirs-faire existants sur les systmes informatiss.
Nous verrons par deux exemples que le choix des dispositifs dentre peut prendre une part importante
dans cette dmarche.
9 Le choix de ce type de contrle est li quant lui aux proprits intrinsques du dispositif : on pourrait choisir de lier
la position du manche la position de lobjet, mais la faible rsolution du dispositif et surtout le recentrage automatique du
manche rendrait la tche extrmement difcile.
F IG . 1.7 gauche, un artiste dessinant avec la mthode traditionnelle de Tape Drawing. droite, le Digital
Tape Drawing, simulant le comportement physique dune bande adhsive [BALAKRISHNAN et al. 99].
Dans lindustrie automobile, les concepteurs travaillant sur les silhouettes des nouveaux vhicules
utilisent une technique appele Tape Drawing, o les lignes principales de lautomobile sont dessines
chelle relle en droulant un ruban adhsif noir sur une surface verticale (gure 1.7, image de
gauche). Cette technique prsente beaucoup davantages, dont celui de pouvoir dessiner aussi bien
des lignes droites que des courbes parfaites. Ravin Balakrishnan a conu un systme de Digital Tape
Drawing aprs avoir observ les mthodes de travail de ces artistes [BALAKRISHNAN et al. 99]. Linterface
utilise deux capteurs positionnels 3D comme dispositifs dentres (un dans chaque main) et permet
de reproduire une grande partie des techniques utilises par les experts du Tape Drawing (gure 1.7,
image de droite).
F IG . 1.8 Larmature mcanique Monkey de Digital Image Design. Les parties peuvent tre rassembles pour
former dautres personnages [K NEP et al. 95].
Dans les lms en images de synthse, les animations sont effectues sur des logiciels spcialiss
qui rclament un apprentissage important. Le domaine est encore jeune, et les animateurs trs expriments sont rares. Pour certaines scnes dlicates du lm Jurassic Park, des dispositifs spciaux
ont t conus an demployer lexprience des animateurs image par image traditionnels, dont
le travail habituel est de faire prendre des poses successives des pantins articuls appels armatures [K NEP et al. 95]. Le dispositif dentre, surnomm Dinosaur Input Device, est une armature de
dinosaure enrichie de capteurs angulaires sur les articulations (jusqu 74 au total), et dont les mouvements sont retransmis au modle 3D. Le principe a t rutilis avec succs dans dautres productions,
9

et des dispositifs analogues sont dsormais disponibles dans le commerce, comme larmature modulaire Monkey (gure 1.8 page prcdente).
Laccessibilit aux handicaps

La prcepte selon lequel linformatique doit tre accessible tous guide aujourdhui la plupart des
plans nationaux sur les nouvelles technologies de linformation [GSA 91]. Alors que la plupart des utilisateurs souffrant de handicaps lgers peuvent employer les dispositifs standard moyennant quelques
adaptations logicielles ou matrielles, des quipements spcialiss deviennent indispensables dans
les cas de handicaps plus svres. Grce aux avances technologiques, ceux-ci sont de plus en plus
nombreux et efcaces.
Lobjectif des dispositifs dentre dits daccessibilit est de fournir une alternative au clavier et/ou
la souris lorsquils sont inutilisables. Lactuelle diversit des dispositifs existant traduit peine la
grande varit des handicaps, quils soient visuels, auditifs, moteurs ou cognitifs. Dans la plupart
des cas, une solution est spciquement tudie pour un utilisateur donn. Nous dcrivons dans cette
section quelques techniques couramment employes.
Les alternatives au clavier. Il existe dans le commerce une grande varit de claviers amliors : certains possdent par exemple des grandes touches qui peuvent tre presses par un bton
plac dans la bouche. Les utilisateurs la fois sourds et non-voyants emploient un clavier braille
en combinaison avec un afchage braille. La reconnaissance vocale reste cependant lalternative au
clavier la plus courante [P IEPER & KOBSA 99]. Dautres techniques ont t explores, telles que la lecture automatique des mouvements de lvres [S TORK & H ENNECKE 96] ou celle de la langue des signes
[S TARNER & P ENTLAND 95].
F IG . 1.9 gauche : un dispositif de pointage contrl avec la bouche. droite : un prototype de souris
pied, le Swing Maule [P EARSON & W EISER 86].
Les pointeurs alternatifs. Dautres parties du corps peuvent remplacer les mains dans les tches
de pointage. Une grande varit de dispositifs, allant des manettes spcialises des techniques de
traitement dimage, permettent aux utilisateurs ttraplgiques de dplacer un curseur par des mouvements de la tte, de la bouche ou des yeux. Un dispositif contrl la langue [S ALEM & Z HAI 97] a
notamment permis datteindre des performances seulement de 5 50% infrieures au contrle manuel10 (gure 1.9, image de gauche). Il existe galement un certain nombre de souris contrles au
pied, baptises taupes, dont lun des premiers prototypes est reproduit sur la gure 1.9, image de droite
10 La
langue peut tre contrle plus nement que la plupart des autres muscles. Voir ce propos la gure 1.21 page 20.
10

[P EARSON & W EISER 86]. Les pointeurs alternatifs sont galement conseills aux utilisateurs souffrant de
douleurs tensionnaires rptitives lies lutilisation de lordinateur.

Le simple bouton. Certaines personnes mobilit extrmement rduite sont uniquement capables de dplacer, de faon limite, une partie de leur corps : plier un doigt, cligner de lil, ou
presser une pdale. Ces muscles peuvent agir comme un simple bouton, dont ltat est soit ouvert
soit ferm. Les ondes crbrales peuvent galement tre exploites comme modalit dentre binaire
[D OHERTY et al. 01]. Si la bande passante de ces dispositifs est extrmement faible, linteraction est possible avec des techniques de type Oui/Non [D OHERTY et al. 01] ou des mthodes de scanning, o des
objets (mots ou lettres de lalphabet, par exemple) sont successivement activs lcran et choisis par
lutilisateur au moment voulu [S TERIADIS & C ONSTANTINOU 03]. Des techniques comme le radar mouse
ou le crosshair mouse permettent notamment dmuler le comportement dune souris [W ORDS P LUS 03].
Lorsque les choix possibles sont nombreux, des techniques de slection dichotomique permettent
dacclrer le processus.
1.2.3
Des dispositifs adapts lenvironnement
Les contextes dutilisation de linformatique ne se limitent pas aux environnements de type bureau.
Il existe un grand nombre de situations o lemploi dune souris ou dun clavier est inadapt, voire
impossible.
Bornes interactives et informatique embarque
F IG . 1.10 gauche : une borne dinformation utilisant un cran tactile. droite : la "molette" employe
dans le Distributeur de Billets Rgionaux de la SNCF.
Les bornes interactives sont des appareils dploys dans des lieux publics an de fournir un libre
accs des informations ou un service. Ces appareils doivent rpondre des contraintes importantes lies une utilisation en lieu public : accs immdiat adapt un contexte "libre-service"
(utilisation en position debout par exemple), simplicit et accessibilit aux personnes non habitues
linformatique, et robustesse (en particulier dans les lieux exposs au vandalisme et aux intempries)
[VAN K AMPEN 00]. Lcran tactile, qui rpond ces trois critres, est le dispositif le plus couramment
utilis dans les applications dinformation (gure 1.10, image de gauche). Les distributeurs automa11

tiques emploient des solutions plus spciques, tels que le pav numrique pour les automates bancaires, ou les pointeurs monodimensionnels dans les distributeurs de titres de transport (gure 1.10
page prcdente, image de droite).
Linformatique embarque dsigne des appareils informatiques qui sont intgrs des objets lectroniques ou mcaniques, tels que les appareils hi- et lectromnagers, les vhicules automobiles
ou les avions11 . Ce domaine met laccent sur la miniaturisation et la abilit, mais galement sur les
qualits ergonomiques. Les panneaux de contrle et les tableaux de bord constituent des exemples
typiques de dispositifs dentre ddis la tche, aussi bien par leur conception que par leur agencement spatial. En informatique embarque, il est courant de devoir prendre en compte les spcicits
de lenvironnement : dans une voiture par exemple, le bruit ambiant est important et les mains et les
pieds sont constamment occups.
Informatique mobile et vestimentaire
F IG . 1.11 gauche : un assistant personnel. droite : la technique TiltType, qui permet de saisir du texte sur
des appareils de trs petite taille quips de quatre boutons et dun acclromtre qui distingue huit inclinaisons
possibles [PARTRIDGE et al. 02].
Linformatique mobile ou nomade dsigne des outils informatiques lgers que lon conserve sur
soi lors de ses dplacements. Elle ncessite des dispositifs dentre compacts et compatibles avec
une activit nomade. Ainsi, la plupart des ordinateurs de poche comme les assistants personnels comportent un cran sensitif et la souris et le clavier sont remplacs par un simple stylet (gure 1.11, image
de gauche). En milieu professionnel, un installateur tlphonique peut par exemple employer un ordinateur de poche muni dun systme de communication radio pour saisir et recevoir des commandes
sur son lieu de travail [P REECE et al. 94]. La reconnaissance vocale est galement employe dans linformatique mobile, par exemple pour la composition de numros sur des tlphones portables. Dautres
techniques dinteraction ont t rcemment proposes pour les appareils mobiles : lune de celles-ci
permet dutiliser un ordinateur de poche avec une seule main en agissant simplement sur son inclinaison [R EKIMOTO 96]. Cette mthode a t ensuite adapte la saisie textuelle sur des appareils de trs
petite taille [PARTRIDGE et al. 02] (gure 1.11, image de droite).
Les ordinateurs vestimentaires constituent un domaine particulier de linformatique mobile. Ports comme des accessoires vestimentaires, ces ordinateurs permettent daccomplir des tches informa11 Habituellement,
ce terme inclut galement linformatique mobile, que nous rservons pour la section suivante.
12
F IG . 1.12 volution au l des annes de lquipement de Steve Mann, lun des cyborgs du MIT qui portent
en permanence des ordinateurs vestimentaires dans de but de les tester et de les amliorer [M ANN 96].
tiques courantes ou spciques sans interrompre son activit, lexemple classique consistant rdiger
un courrier lectronique tout en se promenant dans un lieu public. De tels systmes emploient traditionnellement des dispositifs visuels ou sonores non intrusifs associs des dispositifs dentre varis,
allant de simples boutons placs des endroits stratgiques, des systmes base de reconnaissance
vocale. Les chord keyboards, claviers lgers comportant un nombre restreint de touches employes
de faon combine, sont couramment utiliss [JACOB 96]. Des informations en provenance de lenvironnement peuvent galement tre exploites (GPS, capteurs biomtriques). Linformatique peut
galement tre intgre aux vtements grce au textile intelligent qui est, entre autres, sensible au
toucher [M ANN 96].
1.2.4
Lvolution de lquipement grand public
Lvolution de lquipement grand public est lente mais relle. Aprs plusieurs dcennies de stagnation, nous assistons actuellement deux tendances importantes : une complexication des dispositifs
standard dune part, et une dmocratisation de certains autres priphriques dautre part.
Complexication des priphriques standard

Malgr la grande inertie du march des dispositifs dentre grand public, il nest pas rare de
voir les dispositifs standard subir des extensions signicatives. Lajout sur les souris dune molette
servant faire dler les documents, pourtant rcente, est devenue un quasi-standard sur les systmes
Windows.
Aujourdhui, lajout de contrles additionnels sur les priphriques standard est de plus en plus
courant. La plupart des souris modernes possdent un ou deux boutons latraux supplmentaires,
faisant usage du pouce et de lannulaire (Figure 1.13 page suivante, image de gauche). Ces boutons peuvent tre assigns des oprations courantes telles que la navigation dans lhistorique des
pages Internet. Les claviers Internet proposent galement des boutons de navigation, ainsi que des
contrles ddis lcoute de CDs audio (gure 1.13 page suivante, au centre). Enn, la plupart des
manettes modernes possdent un ou deux contrles analogiques supplmentaires : une manette des
13
F IG . 1.13 Trois exemples de priphriques rcents : gauche, la souris Internet Navigator de Logitech et ses
cinq boutons, congurs pour le jeu Half-Life. Au centre, les contrles audio du clavier Intellimouse Explorer
de Logitech. droite, une partie des contrles de la manette de jeu Cougar HOTAS de Thrustmaster.
gaz et un chapeau multidirectionnel servant spcier la direction du regard, et il nest pas rare de
voir jusqu 14 boutons disposs sur lensemble du dispositif (gure 1.13, image de droite).
La complexication des dispositifs de saisie est une consquence naturelle de la diversication et
de la complexication des tches. Dans lindustrie du jeu, la multiplication considrable des contrles
sur les manettes de jeu modernes sexplique par des simulations de plus en plus ralistes et hautement
interactives qui gnrent une demande accrue quant aux capacits des dispositifs de contrle. Sur les
claviers et souris, les extensions physiques proposes par le march ne sont pas toutes essentielles et
pertinentes, et il y a fort parier que toutes ne simposeront pas comme la molette. Cependant, lajout
dun contrle physique peut se rvler fort protable, en particulier lorsquil est assign une tche
rptitive. La plupart des boutons sont programmables, et contrairement aux touches de fonction du
clavier, sont souvent aiss discerner et mmoriser, et possdent un comportement similaire entre
les applications.
Dmocratisation de priphriques non standard
F IG . 1.14 Trois dispositifs grand public prix abordable (microphone, webcam et tablette graphique), ainsi
quun ordinateur personnel congur pour un jeu de course automobile.
Jusque l, seuls les utilisateurs avancs (les joueurs passionns, par exemple) taient prts investir dans des quipements spcialiss coteux. Maintenant, grce la baisse des cots du matriel
et en particulier de certains priphriques, le grand public peut progressivement se rendre compte
de lintrt que peuvent prsenter les dispositifs dentre non standard. Des priphriques comme le
14
1.3. NOUVEAUX PARADIGMES DINTERACTION

microphone, la webcam (que certains jeux spcialiss exploitent [S ONY 03]) et la tablette graphique
(livre gratuitement avec certains logiciels) sont maintenant de plus en plus courants dans les congurations matrielles12 (gure 1.14 page ci-contre). Il y a fort parier que la conguration rigide de
lordinateur de bureau volue terme vers des congurations de plus en plus riches et htrognes en
termes dentre. condition, bien sr, que les applications apprennent les exploiter au mieux.
1.3 Nouveaux paradigmes dinteraction

De nouvelles techniques dinteraction sont rgulirement proposes dans la littrature scientique dans le but de rendre linteraction plus efcace et plus naturelle. La plupart de ces publications
montrent que mme linteraction avec des applications conventionnelles employant des dispositifs
standard est susceptible dtre sensiblement amliore.
Le terme dinterface post-WIMP est couramment voqu pour dcrire des interfaces employant
ces nouveaux paradigmes dinteraction. Bien quil nexiste pas de dnition consensuelle de ces interfaces, nous pouvons en dgager quelques ls conducteurs. Nous les dcrivons ici, avant de passer
en revue des exemples spciques de nouveaux paradigmes dinteraction, savoir : linteraction gestuelle, les outils transparents, linteraction parallle et la ralit mixte.
1.3.1
Objectifs et enjeux des interfaces post-WIMP
Les nouveaux paradigmes dinteraction tendent essentiellement vers des interactions toujours plus
concises et plus directes.
La notion de concision est en rapport troit avec le concept de phras decrit par Buxton [B UXTON 86 A].
Dans une interface conventionnelle, louverture dun menu suivi du choix dun de ses lments peut
se faire en deux clics. Ces clics successifs forment en quelque sorte une phrase. Or selon Buxton,
toute phrase traduit une connectivit conceptuelle entre les tches atomiques, quil est prfrable de
renforcer par une tension physique. Autrement dit, tout concept ou transaction pouvant tre dcrit en
un seul mot ou une seule phrase devrait pouvoir tre articul en un seul geste [B UXTON 86 A]. Lorsquun menu est ouvert par la mthode du cliquer-glisser, la tension musculaire est maintenue entre
louverture du menu et le choix dun lment, ce qui rend impossible toute erreur de syntaxe. Le geste
est en outre plus uide et plus naturel.
La proprit de concision est galement lie la proprit damodalit. Les modes dans les interfaces dsignent des tats dans lesquels les entres sont interprtes diffremment [P OLLER & G ARTER 84] :
par exemple, les modes insertion et remplacement dans un traitement de texte. Les modes
peuvent gnrer des ambiguts et tre la source derreurs appeles erreurs de mode13 [N ORMAN 81].
En outre, les changements de modes sont autant dtapes supplmentaires dans linteraction, et peuvent
la ralentir considrablement (palette doutils). Les nouvelles techniques dinteraction visent supprimer ces changements de mode, ou les rendre plus rapides et naturels (quasi-modes).
Tout le monde saccorde galement dire que linteraction doit tre la plus directe possible, bien
12
titre dexemple, les ventes de webcam aux tats-Unis ont grimp de 36% de 2001 2002 [G ILL 02].
13 Les erreurs de mode ont t lorigine de nombreuses catastrophes. Le crash de lAirbus A320 sur le Mont-Saint-Odile
en 1992 en est un exemple typique : peu avant latterrissage, le pilote, trs occup, a saisi une vitesse de descente de 3300
pieds/mn au lieu dun angle de 3.3 degrs [H OURIZI & J OHNSON 01]
15

que cette notion reste encore relativement vague.
Le principe de la manipulation directe [S HNEIDERMAN 83] a exerc une forte inuence sur le dveloppement des interfaces grand public. En pratique cependant, linteraction est loin dtre toujours
directe : les botes de dialogues et les widgets, en particulier, occupent de lespace sur lcran et dplacent lattention de lutilisateur hors des objets dintrt [B EAUDOUIN -L AFON 97, B EAUDOUIN -L AFON 00].
Le modle de linteraction instrumentale (voir section 2.5.2 page 57) emploie le terme de degr dindirection pour dsigner la fois le dcalage temporel (modes) et le dcalage spatial suscit par ces
techniques. De nouvelles techniques sont rgulirement proposes pour revenir une interaction plus
locale, essentiellement centre sur les objets dintrt.
La compatibilit stimulus/rponse [B UXTON 86 B, N ORMAN 02] que nous avons voque dans la section 1.2.1 page 7 met en avant la compatibilit entre le dispositif dentre physique et la tche. Jacob
et al. [JACOB et al. 94] ont par ailleurs conrm que les performances sont faibles lorsque que des tches
intgrales (comme le placement dun objet 3D) sont morceles par lemploi dun dispositif dont le
nombre de degrs de liberts est insufsant. Lensemble de ces rsultats incite une simplication des
techniques dinteraction travers lusage de dispositifs ddis. Dans les procds de contrle direct
caractriss par la quasi-absence de techniques dinteraction, la sensation de contrle et dengagement
se trouvent intensis. Ces dimensions sont notamment dominantes dans les jeux vido.
Tout comme linteraction concise, linteraction directe suppose une continuit plutt quune squentialit dans les actions.
1.3.2
Linteraction gestuelle
Linteraction gestuelle constitue un moyen non conventionnel demployer les dispositifs de pointage en exploitant notre capacit musculaire mmoriser et reproduire des trajectoires, capacit que
nous employons notamment pour crire.
Exploiter la dynamique du mouvement
F IG . 1.15 Dans les interfaces classiques, lorsquun utilisateur effectue une action de type cliquer-glisser,
seules la position initiale et la position nale du pointeur sont pris en compte, indpendamment de la trajectoire
effectue.
Dans la plupart des interfaces manipulation directe, les dispositifs de pointage servent essentiellement spcier des positions14 . Dans un mouvement de cliquer-glisser par exemple, seules la
position initiale et la position nale sont interprtes (gure 1.15). En exploitant la dynamique du
mouvement, les techniques dinteraction gestuelles permettent denrichir la smantique des actions
lmentaires de lutilisateur [BAUDEL 95].
14 Les
menus hirarchiques constituent une exception [M ERTZ et al. 00], pouvant tout au plus tre considre comme un
16
F IG . 1.16 Exemples usuels de techniques dinteraction gestuelle dans une application graphique : lutilisateur
commence par crer un rectangle, un cercle, et un label. Il supprime ensuite le cercle et duplique le label. Enn,
il regroupe les deux labels et les dplace vers la gauche.
La gure 1.16 illustre quelques techniques dinteraction gestuelle classiques, telles quon peut
les trouver dans des applications comme [M ANKOFF et al. 00] ou [H ONG & L ANDAY 00]. Chaque action de
type cliquer-clisser produit, la manire dun logiciel de dessin, une trace, qui disparat une fois
interprte. La trace pourra tre interprte comme un nouvel objet crer, dont le type la taille et
la position seront dduits des caractristiques du geste. Elle pourra galement tre interprte comme
une commande ddition, dont la nature et les objets cibls seront galement dduits du geste selon
un algorithme prdtermin.
Interfaces gestuelles : des avantages et des inconvnients
Lavantage principal de linteraction gestuelle est quelle permet deffectuer des interactions concises
Ainsi, la plupart des oprations gestuelles de lexemple prcdent rclament habituellement au moins deux tapes dans une interface classique : crer un rectangle ncessite de cliquer sur
loutil rectangle puis de dsigner deux cts opposs du rectangle par un cliquer-glisser. De mme,
la suppression dun objet requiert une slection, puis lappui dune touche ou un clic sur le bouton
supprimer . Or, un geste suft pour spcier la fois une commande et les arguments de cette
commande. En outre, linteraction gestuelle nutilise pas de widgets intermdiaires tels que les barres
doutils, ce qui conomise de la place sur lcran et permet lutilisateur de se focaliser sur les objets
dintrt.
[BAUDEL 95].
Lautre atout de linteraction gestuelle est quelle exploite une mtaphore dj connue, savoir
le dessin sur une feuille de papier. Lutilisation de stylets et lexploitation de gestes iconiques tel
que le geste de rature (gure 1.16) exploitent davantage encore la puissance de cette analogie. Ainsi,
les techniques dinteraction gestuelle ont t largement utilises dans les applications conues selon une approche d interaction informelle 15 et abondamment exploites pour la saisie textuelle
[L ANDAY & M YERS 95]. Linteraction gestuelle est galement la technique de prdilection des ordinateurs de poche, qui utilisent le stylet comme principal dispositif de saisie, et pour lesquels il convient
de maximiser lespace dafchage utile.
Bien que fort prometteuses, les interfaces essentiellement bases sur les techniques gestuelles restent difciles mettre en uvre. Les ambiguts potentielles, par exemple, sont nombreuses : ainsi,
dans lexemple de la gure 1.16, le cercle pourrait tre interprt comme la lettre O , et le dplacement dobjets comme la cration dun segment de droite. Plus encore que les difcults lies
exemple primitif et trs imparfait dinteraction gestuelle.
15 Cette approche vise ne pas faire obstacle aux capacits dexpression crative de lutilisateur en privilgiant des mthodes de saisie naturelles et en acceptant des donnes incompltes ou imprcises (telles que des croquis), tout en minimisant
les interventions de lordinateur.
17

lapprentissage, les erreurs de reconnaissance rsultant dun vocabulaire gestuel complexe sont une
source de frustration considrable pour lutilisateur. La tendance actuelle semble ainsi aller vers lutilisation de gestes simples, plus rapides et plus tolrants aux erreurs de par leur construction logique
[M AC K ENZIE & Z HANG 97, N G et al. 98], mais ce au dtriment de leur facilit dassimilation d leur nature arbitraire.
Les gestes ergotiques

Les gestes permettent dexplorer le monde physique (fonction pistmique), dagir matriellement sur ce monde (fonction ergotique), et de communiquer avec les autres (fonction smiotique)
[C ADOZ 94].
La plupart des techniques conventionnelles emploient des gestes smiotiques. Les quelques exemples
de techniques exploitant les fonctions ergotique et pistmique montrent cependant que celles-ci possdent de nombreux avantages : ce sont des gestes simples, souvent utilisables la souris, qui ne
rclament pas dapprentissage car ils sexpliquent deux-mmes. Ces techniques sont la preuve que
linteraction gestuelle nimpose pas ncessairement de compromis entre facilit dassimilation et efcacit dutilisation.
F IG . 1.17 Slection dune commande dans un Marking Menu, par un novice ( gauche) et par un expert (
droite).
Cest le cas des Marking Menus, version circulaire des menus contextuels [K URTENBACH & B UXTON 94].
Dans un menu circulaire, le choix dun lment se fait en imprimant une direction donne au pointeur,
aprs avoir fait apparatre le dit menu (gure 1.17). Les menus hirarchiques des Marking Menus
induisent des gestes qui sont afchs sous forme de traces (gure 1.17, image de droite). Lutilisateur
novice commencera par maintenir le bouton enfonc an de faire apparatre les menus (gure 1.17,
image de gauche), et pourra ensuite directement effectuer les gestes pour les commandes auxquelles
il est habitu (gure 1.17, image de droite).
La gure 1.18 page suivante illustre un autre exemple tir du logiciel Digistrips, un prototype
de strips lectroniques pour contrleurs ariens [M ERTZ et al. 00]. Les Strips sont des objets disposs
verticalement. Un Strip peut tre dcal vers la droite, ou dplac vers le haut ou vers le bas, auquel
cas il pousse les autres an de conserver lordre. Mais un court mouvement vers la droite suivi dun
dplacement vertical le dsolidarise des autres, ce qui lui permet dtre insr ailleurs. Le passage
ce mode de dplacement se fait par un geste implicite, mcanique , dont la comprhension et
lassimilation sont immdiates.
18
F IG . 1.18 Les gestes reconnus pour la manipulation des Strips [M ERTZ et al. 00].
F IG . 1.19 La lettre f et le mot the saisis avec la technique QuikWriting [P ERLIN 98].
La mthode de saisie textuelle QuikWriting de Ken Perlin constitue un autre exemple de gestes
ergotiques [P ERLIN 98]. Pour la saisie textuelle au stylet sur les ordinateurs de poche, les vocabulaires
gestuels simplis comme Grafti [M AC K ENZIE & Z HANG 97] sont souvent prfres aux techniques
d criture naturelle [PARAGON 03, M ICROSOFT 03 B] qui sont sujettes aux erreurs de reconnaissance.
Cependant, ces vocabulaires gestuels ncessitent dtre appris. La technique QuikWriting se distingue
de ces approches car elle peut tre utilise, tout comme les Marking Menus, de faon exploratoire.
Lespace de saisie de QuikWriting est divise en neuf zones (gure 1.19). Chaque geste commence
dans la zone centrale, puis passe par une ou deux zones avant de revenir au centre. La correspondance
entre caractres et gestes est reprsente de faon synthtique sur lespace de saisie : pour saisir une
lettre, il suft de diriger le geste dans la zone o elle se trouve, puis dans la zone indique par sa
position relative.
1.3.3
Les outils semi-transparents
Les outils semi-transparents16 sont des widgets que lon peut librement dplacer sur lcran, et
qui sont en gnral regroups dans des palettes ottantes appeles toolglass. Ces outils possdent des
zones transparentes qui permettent de voir les objets dintrt situs en-dessous17 .
Lorsquun utilisateur clique sur un outil semi-transparent, celui-ci modie les proprits de lobjet
qui se trouve en dessous, la position du curseur. Sur la gure 1.20 page suivante par exemple, un
utilisateur modie la couleur dun objet graphique en cliquant dessus travers un bouton transparent.
16 en
anglais, see-through tools ou click-through tools.
17 Les Magic Lenses (lentilles magiques) sont une variante o la transparence est remplace par des ltres visuels labors
qui apportent des informations supplmentaires sur les objets.
19
F IG . 1.20 Une toolglass comportant quatre outils de changement de couleur. Lutilisateur clique sur une
ellipse travers lun de ces outils, ce qui a pour effet de modier la couleur de lobjet graphique.
Ce bouton permet daffecter une couleur donne (afche dans le coin infrieur droit de loutil) tout
objet graphique.
Les outils semi-transparents ont t introduits par Eric A. Bier [B IER et al. 93], comme alternative
aux techniques indirectes de manipulation dobjets graphiques, telles que la slection, les barres doutils modales ou les menus contextuels. Contrairement ces techniques, les outils semi-transparents
permettent de spcier la fois lobjet sur lequel on veut effectuer une opration et lopration ellemme. Couple linteraction bimanuelle dcrite quelques lignes plus bas (la Toolglass peut tre
contrle de la main gauche), cette technique permet deffectuer en un seul geste des manipulations
qui, avec les techniques classiques, requirent plusieurs tapes et des dplacements rpts de lattention visuelle.
1.3.4
Linteraction parallle
Nous employons le terme dinteraction parallle pour dsigner lensemble les paradigmes dinteraction faisant un usage simultan de plusieurs dispositifs dentre.
F IG . 1.21 Homoncule reprsentant les zones du cortex moteur responsables de chaque groupe musculaire
[BARLOW et al. 90].
Lefcacit de linteraction peut se dcrire en termes de bande passante, cest--dire de la quantit

20

dinformation que lutilisateur est capable dacheminer vers la machine en un temps donn. Actuellement cette vitesse est bien infrieure la vitesse limite thorique, qui dpend essentiellement de
la bande passante motrice humaine. Lhomoncule reprsent sur la gure 1.21 page ci-contre donne
un aperu de lensemble de cette bande passante, et montre notamment que certains groupes moteurs
peuvent tre contrls plus nement que dautres.
Lhomme est capable, par apprentissage, dutiliser de faon conjugue nimporte quel ensemble de
groupes musculaires. Cest le cas lorsquil apprend jouer dun instrument de musique ou conduire
une voiture. En outre, nombre de gestes quotidiens instinctifs mettent en jeu ce type de coordination
musculaire, et cest galement le cas pour le langage.
Dans les interactions parallles, plusieurs dispositifs dentre sont employs simultanment an
de mieux exploiter la bande passante motrice humaine. Certains des dispositifs alternatifs que nous
avons voqus dans la section 1.2.2 page 10 mettent en jeu des groupes musculaires spciques et
peuvent tre employs en complment des dispositifs standard. Ici, nous nous contenterons de dcrire
les deux principaux paradigmes dinteraction reposant sur linteraction parallle, savoir linteraction
bimanuelle et linteraction multimodale.
Linteraction bimanuelle
Une exprience de William Buxton et Brad Myers [B UXTON & M YERS 86] a mis en vidence que des
techniques dinteraction utilisant deux mains permettaient daccomplir certaines tches plus rapidement. Leur exprience consistait spcier dune part la taille et la position dune cible, et dautre part
naviguer dans un document et slectionner un mot. Dans les deux cas, le paralllisme tait exploit
de faon naturelle et augmentait signicativement les performances.
Au mme moment, Yves Guiard [G UIARD 87] a montr que dans les tches manuelles courantes,
les deux mains travaillent de faon cooprative et asymtrique, et a mis notamment laccent sur limportance de la main non-dominante. Ainsi, la main non-dominante peut servir de rfrentiel spatial
pendant que la main dominante opre sur lobjet tenu par la main gauche, et la premire effectue en
gnral des mouvements de grande amplitude alors que la dernire effectue des mouvements prcis
(exemple du peintre qui tient sa palette). En outre, la main non-dominante prcde souvent le geste,
que la main dominante termine (prendre une feuille de papier pour crire).
F IG . 1.22 Navigation cartographique bimanuelle : les deux pointeurs (que nous avons entour dun cercle
pour plus de clart) sont utiliss simultanment pour zoomer. La carte est ractualise la n de linteraction.
[H INCKLEY et al. 98]
Lemploi de modicateurs clavier et la saisie textuelle deux mains constituent dj des interac21

tions bimanuelles rudimentaires. Mais sur la base des expriences de Buxton et Myers et de la thorie
de Guiard, des techniques bien plus intressantes ont pu tre explores. Appliques linfographie,
de telles techniques permettent, comme le font les dessinateurs, dorienter lespace de travail de la
main gauche tout en dessinant de la main droite [K URTENBACH et al. 97]. La gure 1.22 page prcdente
montre une autre technique bimanuelle o lutilisation simultane des deux mains permet de zoomer
en avant ou en arrire sur une carte, tout en la dplaant [H INCKLEY et al. 98].
F IG . 1.23 Manipulation multidigitale avec Smartskin. gauche, la manipulation dune courbe de Bzier.
droite, une technique de navigation cartographique similaire celle de Hinckley [R EKIMOTO 02]
Dautres techniques dinteraction bimanuelle ont t dcrites dans la littrature scientique. Nous
avons voqu trois dentre elles dans les sections prcdentes : la manipulation dun plan de coupe
(gure 1.2 page 6), le tape drawing (gure 1.7 page 9), et en particulier les outils transparents (gure 1.20 page 20). Rcemment, un dispositif dentre exprimental mais trs prometteur, nomm
Smartskin, a permis dappliquer certaines techniques bimanuelles la manipulation multidigitale ,
comme illustr sur la gure 1.23 [R EKIMOTO 02].
Linteraction multimodale
Selon Laurence Nigay, la multimodalit est la capacit dun systme communiquer avec un utilisateur en employant diffrents types de canaux de communication [N IGAY & C OUTAZ 93]. En gnral,
les interfaces multimodales emploient des entres naturelles mais qui produisent des ambiguts
comme la parole, et les compltent par des entres explicites comme le pointage ou la manipulation directe. Bien que le terme de multimodalit soit parfois employ dans le sens plus gnral dinteraction
parallle, le domaine de linteraction multimodale sattache essentiellement aux problmes lis la
fusion et linterprtation dentres issues de canaux de nature htrogne.
La notion dinterfaces multimodales a t introduite par Richard Bolt [B OLT 80] dans son systme
put-that-there , qui associe des commandes vocales des techniques de pointage (gure 1.24 page
suivante). Pour dplacer un objet, lutilisateur pointe du doigt sur cet objet en prononant met a ,
puis sur sa destination en prononant l . Dautres prototypes ont t construits par la suite an
exprimenter lusage combin de la manipulation directe et du langage naturel textuel [C OHEN et al. 89],
ou des gestes et de la parole [W EIMER & G ANAPATHY 89]. Plus rcemment, des techniques de traitement
vido en temps rel ont t exploites pour amliorer la reconnaissance vocale par la lecture des
mouvements des lvres, et pour contrler une application de visualisation dimages panoramiques en
combinant mouvements oculaires et commandes vocales [YANG et al. 98].
Les interfaces multimodales offrent la possibilit de combiner les avantages des entres naturelles
22
F IG . 1.24 Le systme put-that-there de Bolt [B OLT 80].
mais quivoques comme la parole, et des entres univoques comme la manipulation directe. Lutilisation de plusieurs canaux de communication permet chaque canal de compenser les faiblesses des
autres, lorsquil sagit notamment de rsoudre des ambiguts, mais permet galement la proprit
de redondance, dans laquelle une tche peut tre accomplie de diverses manires. Cette redondance
des entres est souvent dsirable, en particulier lorsque les contraintes lies lenvironnement sont
variables.
1.3.5
La ralit mixte
Ralit Mixte
Environnement
Rel
Environnement
Virtuel
Ralit
Augmente
Virtualit
Augmente
F IG . 1.25 Le continuum rel-virtuel de Milgram.
Paul Milgram [M ILGRAM & K ISHINO 94] a introduit le terme de ralit mixte pour dsigner lensemble des approches combinant environnements virtuels et environnements rels dans des proportions variables. Il dcrit ainsi un continuum entre la ralit et la virtualit partir duquel on peut
distinguer deux grandes approches (gure 1.25) : la virtualit augmente qui consiste intgrer du
rel dans le monde virtuel, et la ralit augmente qui consiste intgrer du virtuel dans le monde
rel. Nous dcrivons ces deux paradigmes.
La virtualit augmente
Nous possdons des capacits innes interagir de faon physique avec des objets du monde rel,
et ces capacits sont trs peu exploites dans les interfaces actuelles o les objets sont essentiellement
virtuels [F ITZMAURICE & B UXTON 97, I SHII & U LLMER 97]. La virtualit augmente traduit une nouvelle
23

tendance dans la recherche en IHM qui vise introduire des objets physiques dans les interfaces
utilisateur conventionnelles.
F IG . 1.26 gauche : interface saisissable , o des briques physiques sont utilises pour manipuler des
objets virtuels [F ITZMAURICE et al. 95]. droite : un assemblage de phidgets est assign des widgets de contrle
sonore [G REENBERG & B OYLE 02].
George Fitzmaurice et Hiroshi Ishii [F ITZMAURICE et al. 95] ont employ le terme dinterfaces saisissables 18 , pour dcrire des interfaces o certains objets interactifs traditionnels sont remplacs par
des objets physiques. Ils voquent un prototype o des briques comportant des capteurs de position
et dorientation sont librement placs sur une table, sur laquelle sont projets des objets graphiques.
Lorsquune brique est pose sur un objet virtuel, celui-ci peut tre librement manipul (gure 1.26,
image de gauche). Plusieurs briques peuvent tre manipules simultanment, soit sur des objets spars, soit sur le mme objet pour le redimensionner ou le dformer. Hiroshi Ishii [I SHII & U LLMER 97]
gnralisera ces concepts dans une perspective plus gnrale de ralit mixte, et introduira le terme
maintenant couramment employ dinterfaces tangibles.
Dans le mme esprit, Saul Greenberg [G REENBERG & B OYLE 02] propose de saider de contrleurs
physiques supplmentaires pour interagir avec les applications existantes. Ses phidgets sont les homologues physiques des widgets qui structurent nos interfaces. Ainsi, des boutons ou des potentiomtres
lectroniques peuvent tre assigns aux fonctions les plus couramment utiliss, puis agencs sur lespace de travail. Sur la gure 1.26, image de droite, une combinaison de potentiomtres linaires est
assigne des fonctions de contrle sonore.
Dans ces interfaces, les objets physiques sont plus efcaces et plus faciles dutilisation car ils
mettent prot nos capacits prhensiles innes [F ITZMAURICE & B UXTON 97]. En outre, ils permettent
et mme encouragent linteraction bimanuelle et le travail coopratif.
La ralit augmente
La ralit augmente [M ACKAY 96] dsigne des techniques consistant superposer au monde rel
des informations gnres par ordinateur. Lexemple typique est un utilisateur (chirurgien, militaire,...)
qui est assist dans sa tche par un systme vestimentaire (voir section 1.2.3 page 12) comprenant
un casque virtuel ou des lunettes translucides. Une autre technique courante consiste projeter des
images sur un espace de travail : les surfaces augmentes telles que les tables, les tableaux ou les murs
interactifs emploient des techniques dinteraction bases sur la capture des mouvements de la main
ou sappuient sur des interfaces tangibles [I SHII & U LLMER 97]. Largile lumineuse [P IPER et al. 02] par
18 Traduction
approximative de Graspable User Interfaces.
24
1.4. LINTERACTION NON-STANDARD DANS LINFORMATIQUE GRAND PUBLIC
F IG . 1.27 gauche : largile lumineuse avec le calcul des courbes de gradient [P IPER et al. 02]. droite : une
dalle de sol intelligent et un des capteurs de charge qui la composent [O RR & A BOWD 00].
exemple, consiste en un matriau dformable destin concevoir des maquettes de paysages, et sur
lequel sont projetes des informations topographiques (gure 1.27, image de gauche). Linteraction
se fait par modelage du matriau, dont la forme est capture en temps rel par un scanner laser.
Linformatique diffuse19 dcrit une ralit augmente o linformatique, saidant de la miniaturisation et de la mise en rseau, se fond avec lenvironnement quotidien jusqu tre invisible et fournit des
informations et des services lendroit et au moment opportuns [W EISER 91]. Ce nouveau paradigme
dinformatique embarque (voir section 1.2.3 page 11) met en avant une interaction naturelle entre
lutilisateur et lenvironnement augment, mais surtout le remplacement des interactions explicites par
une sensibilit au contexte, o des informations provenant de lenvironnement (identit de lutilisateur,
localisation spatiale, objet dintrt, type dactivit) sont automatiquement collectes et interprtes.
Ici, les dispositifs dentre sont remplacs par des capteurs. Le sol intelligent [O RR & A BOWD 00], par
exemple, est un systme non intrusif didentication biomtrique et de localisation bas sur des prols
de charge (gure 1.27, image de droite).
1.4 Linteraction non-standard dans linformatique grand public

Dans cette section, nous appliquons les enseignements tirs des sections prcdentes linformatique grand public. Nous montrons que les dispositifs et les paradigmes dinteraction non standard
ont un rle non ngligeable jouer dans ce domaine, ce qui nous amnera naturellement la notion
dinteraction adaptable20 au contexte.
Dans un premier temps, nous montrons lintrt dune interaction adaptable, ouverte aux paradigmes non conventionnels, par opposition au modle trop rigide de linteraction standard. Nous dnissons ensuite plus prcisment la notion dadaptabilit en entre, dont nous nous servons par la
suite pour tablir un constat sur les applications interactives actuelles.
19 Traduction de Ubiquitous Computing. Les traductions employes sont nombreuses : informatique ubiquitaire, omniprsente, pervasive, dissmine, ou encore ubiquit numrique.
20 Par adaptable, nous nentendrons pas qui sadapte automatiquement , mais plutt quil est possible dadapter .
25
1.4.1
Ncessit dune interaction adaptable
Des contextes dutilisation potentiellement nombreux

Nous avons mis en avant dans les sections prcdentes lintrt demployer des dispositifs dentre
et des techniques dinteraction adapts au contexte dutilisation, en prenant notamment en compte les
caractristiques des utilisateurs potentiels (comptences ou limitations) et ceux de lenvironnement
(espace limit, bruyant, mobile, etc.).
Parmi les exemples que nous avons voqu, les crations les plus originales taient ddies des
contextes dutilisation trs restreints : animation cinmatographique ou planication neuro-chirurgicale,
par exemple. Cela ne signie pas que les techniques non conventionnelles naient dintrt que dans
les applications professionnelles. Il est aussi avantageux dans les applications grand public dadapter
linteraction au contexte, bien que les contextes dutilisation potentiels soient extrmement nombreux.
Nimporte qui est susceptible dutiliser un logiciel de gestion de courrier lectronique, quel que
soit son mtier et ses comptences, et quelque soit son handicap. Il est probable que certaines personnes emploieraient des dispositifs et des techniques trs personnelles, sils en avaient la possibilit.
En outre, un tel logiciel est galement susceptible dtre utilis dans des environnements non conventionnels et sur des plate-formes autres que lordinateur de bureau : sur un ordinateur de poche, une
borne interactive ou dans une voiture, par exemple.
Employer des techniques dinteraction efcaces

Chaque technique dinteraction est adapte un contexte dutilisation particulier : linteraction
gestuelle, par exemple, est extrmement efcace lorsquelle est associe des dispositifs dentre
de type stylet et reste exploitable avec des dispositifs de pointage moins prcis comme la souris,
mais son emploi est nettement moins pertinent avec un clavier. En outre, si linteraction gestuelle
est particulirement intressante dans les applications hautement graphiques, elle lest moins dans les
applications de type calculatrice , du moins dans lhypothse o un clavier est prsent. Dun autre
ct, chaque dispositif physique appelle des tches et des techniques dinteraction particulires :
un clavier est particulirement laise dans les tches de saisie textuelle, pour lesquelles il a t conu,
bien quil puisse galement servir dautres ns.
Il existe ainsi des relations complexes du type va bien avec entre les types dutilisateurs,
les dispositifs dentre, les techniques dinteraction, les types de tches et les types dapplications. De
telles relations lient galement entre elles les techniques dinteraction qui peuvent tre combines (par
exemple, pointage + menu). Ces associations pourraient tre explicites dans une matrice entres
multiples, mais le nombre de dimensions (suprieur deux) et leur nature continue (rendant toute
numration ou classication excessivement simplicatrice) a de quoi dcourager quiconque voudrait
se lancer dans cette tche avec le souci dtre exhaustif.
Malgr tout, dans chaque contexte o lutilisateur, les dispositifs dentre prsents et les tches applicatives sont xs, les techniques dinteraction constituent lunique degr de libert restant. Ladaptabilit en entre, que nous dnirons plus loin, consiste exploiter au mieux ce degr de libert en
fournissant les meilleures techniques dinteraction possibles pour chaque situation.
Aujourdhui encore, on ne saurait cependant dire quelle technique dinteraction est la mieux adapte un contexte donn. La recherche en interaction homme-machine propose rgulirement de nou26

velles techniques dinteraction toujours plus naturelles et efcaces, et ce la plupart du temps pour
des dispositifs dentre et des tches dj connus. On saurait encore moins dterminer les techniques
optimales pour les couples (dispositif, tche) les moins conventionnels (par exemple, quelle est la
meilleure faon dditer une cellule dans un tableur avec pour seuls dispositifs un potentiomtre linaire et un microphone), dont la plus grande partie na dailleurs jamais t explore. Lvolution
constante de notre savoir sur linteraction implique des systmes interactifs ouverts plutt que gs.
Une vraie accessibilit

Laccessibilit dun systme interactif repose en grande partie sur sa capacit concilier les
couples (dispositif, tche) que nous venons dvoquer. Le problme a t trop vite rgl par les nombreux outils dmulation, qui se proposent dimiter partir dun dispositif dentre non-conventionnel
le comportement dun dispositif dentre connu. Bien que parfois satisfaisante, cette solution ignore
une dimension importante de linteraction en entre, savoir que les proprits intrinsques dun dispositif dentre inuent grandement sur lutilisabilit dune technique dinteraction. Voici par exemple
quelques conseils donns par un fabricant dcrans tactiles pour bornes interactives leurs clients :
Utilisez une simple interface base de pointer-et-cliquer : pas de double-clic, pas de cliquer-glisser.
Cachez le curseur, il est inutile si lcran ninduit pas deffet de parallaxe [E LO 02].
Proposer un vaste ensemble de techniques dinteraction prdnies pour permettre de slectionner
celle qui convient le mieux au contexte serait un pas en avant, mais ne rsoudrait pas totalement le
problme, car les techniques dinteraction constituent un continuum au mme titre que les utilisateurs
ou les dispositifs dentre. Il est vrai que les publications dcrivant a et l de nouvelles techniques
dinteraction pourraient laisser croire quil existe un instant donn un ensemble vaste mais dnombrable de techniques connues. Il y a cependant une diffrence importante entre une description
haut-niveau dune technique dinteraction telle quon en trouve dans la littrature scientique ou dans
les documentations et son implmentation concrte.
Pour illustrer ce fait, prenons lexemple des menus hirarchiques. Un manuel dcrivant lutilisation de cette technique pourrait contenir, entre autres, linformation suivante : lorsque le sous-menu
apparat, vous pouvez pointer directement vers lun de ses lments . Dans la plupart des menus hirarchiques, un mcanisme de temporisation empche en effet dautres sous-menus de souvrir pendant
lopration. Toutefois les dlais ont t rgls pour une souris manipule par un utilisateur moyen, et
sont inadapts des utilisateurs plus lents ou des dispositifs dentre qui bornent la vitesse de pointage (voir gure 1.28 page suivante). Le fait que les menus hirarchiques en gnral soient adapts
tout type de dispositif de pointage ne signie pas quune implmentation donne sera utilisable avec
nimporte lequel de ces dispositifs.
Une modication mineure ou une paramtrisation diffrente de la technique des menus hirarchiques peut la rendre nouveau utilisable dans le cas voqu, bien que peut-tre moins productive
dans le cas courant. Plus gnralement, il existe pour chaque technique dinteraction en apparence
gnrique, un grand nombre dimplmentations concrtes (variantes, paramtrisations), chacune tant
adapte ou non un contexte trs spcique. Cest pourquoi une relle accessibilit implique des
techniques dinteraction non seulement varies, mais dont on puisse galement adapter le comportement de manire trs ne pour pouvoir les optimiser en fonction de lutilisateur, des dispositifs et des
tches.
27
F IG . 1.28 Un menu hirarchique utilis avec une souris (en haut) et avec un dispositif de pointage de type
manette (en bas). Dans ce menu, un mcanisme de temporisation vite la cible (ici, Adobe Photoshop) de
disparatre pendant le pointage. Dans le second cas cependant, la disparition prmature de la cible et louverture
dun menu non souhait ne peuvent tre vits.
Personnalits et prfrences individuelles

Il existe diffrents types dutilisateurs. En premier lieu, ceux qui prouvent une rpulsion ou une
peur de linformatique sopposent ceux qui se sentent attirs par ce domaine [S HNEIDERMAN 98].
Mme parmi ces derniers, des querelles amicales opposent les partisans de tel ou tel outil, systme
dexploitation ou style dinteraction : ainsi, si certains puristes mettent en avant la puissance des commandes textuelles, les personnalits cratives penchent le plus souvent pour linteraction graphique et
les diteurs WYSIWYG 21 . Des diffrences fondamentales existeraient galement entre les hommes
et les femmes, notamment en ce qui concerne les choix de jeux vido [S HNEIDERMAN 98].
Ces oppositions montrent, en partie seulement, quel point les personnalits des utilisateurs de
linformatique sont diverses et les prfrences individuelles varies. Une interface ddie lutilisateur moyen ne pourra provoquer quune majorit dinsatisfaits. Chaque utilisateur tant unique, il est
essentiel de prendre en compte ses prfrences propres, notamment en lui permettant de personnaliser
linteraction pour ladapter ses prfrences.
Certains utilisateurs sont prts consacrer du temps pour personnaliser et amliorer les outils
informatiques quils utilisent. Nous les qualions dutilisateurs avancs. Compars aux utilisateurs
moyens, les utilisateurs avancs ont souvent une meilleure connaissance de linformatique. Les niveaux dexpertise sont cependant bien diffrents entre les amateurs passionns, les professionnels qui
utilisent les outils informatiques, et les informaticiens. Cest donc la motivation qui caractrise le
mieux les utilisateurs avancs, qui sont prts fournir des efforts pour amliorer leur productivit.
La facilit de prise en main et la simplicit dutilisation sont des critres essentiels dans les interfaces grand public, et il est dusage notamment de ne pas encombrer lutilisateur de dtails et de choix
inutiles. Cependant, parce que linformatique connat un dveloppement important, les utilisateurs
avancs constituent une catgorie croissante dutilisateurs, et cette catgorie est malheureusement encore peu reconnue par les fabricants logiciels. Car comme nous le verrons par la suite, les interfaces
actuelles noffrent pas doutils de conguration la hauteur de ce que sont en droit dattendre les
utilisateurs avancs.
21 What
You See Is What You Get
28

Les faiblesses de linteraction standard et leurs consquences
La plupart des applications interactives grand public reposent essentiellement sur le modle de
linteraction standard : une souris, un clavier, et un nombre restreint de techniques dinteraction associes (voir section 1.1.1 page 2 sur linteraction standard). Ces dispositifs et ces techniques ont t
conus avec une ide de gnricit. Cette gnricit est protable aux programmeurs car elle leur
garantit une certaine rutilisabilit dune application lautre, et galement aux utilisateurs car elle
garantit une certaine cohrence de linteraction dune application lautre. En outre, les techniques
dinteraction gnriques peuvent tre conues avec soin et testes une fois pour toutes. Cependant, ce
modle possde deux inconvnients de taille :
Les dispositifs et techniques dinteraction standard ne sont jamais totalement appropries : ceuxci visent un utilisateur moyen (utilisateur capable dutiliser une souris et un clavier, et qui sen
contente), un environnement dutilisation moyen (assis devant un bureau dans des conditions normales), et un ensemble de tches moyennes (manipuler des widgets). Parce que ces techniques sont
trop gnriques, elles ne sont jamais totalement appropries, ni au contexte dutilisation, ni aux tches
de lapplication.
Les dispositifs et techniques dinteraction standard peuvent tre totalement inappropries : cest le
cas en particulier lorsque la souris ou le clavier ne peuvent tre employs, en raison de contraintes lies
lutilisateur ou lenvironnement. Des plate-formes alternatives ont t proposes dans lesquelles
linteraction a t repense avec dautres dispositifs (interaction base de stylet, par exemple). Cependant, les applications y sont toujours dveloppes sur le mme modle, cest--dire par-dessus un
ensemble prtabli de techniques dinteraction, ce qui interdit toute portabilit dune plate-forme
lautre.
Enn, le modle de linteraction standard, par sa rigidit, ge lvolution de linformatique grand
public et lempche de suivre les innovations. De nouvelles techniques dinteraction sont publies
chaque anne dans la littrature scientique, et malgr leurs avantages, sont ignores dans les applications commerciales. Seules certaines de ces applications se distinguent des logiciels conventionnels
et sortent des sentiers tracs par le modle de linteraction standard. Bien que ces applications constituent encore une minorit et que leurs capacits soient encore trs limites, elles dnotent un courant
positif dans linformatique grand public, qui va dans le sens de notre discours.
Nous tablirons pour complter cette discussion un constat gnral sur les applications interactives
actuelles, an de mieux constater linuence du modle dinteraction standard sur linformatique
grand public.
1.4.2
Dnition de ladaptabilit en entre
Pour parler de linformatique grand public daujourdhui, il est difcile de ne pas prendre pour
base de comparaison les standards existants. Nous introduisons par consquent les termes dentres
enrichies ou appauvries, par rfrence aux entres standard que constituent la souris et le clavier :
Les entres enrichies dcrivent les dispositifs dentre ou les combinaisons de dispositifs dont la
bande passante est suprieure celle des dispositifs standard. Les exemples vont des contrles supplmentaires sur les dispositifs standard aux dispositifs multi-dimensionnels, large bande passante,
ainsi que les dispositifs multiples.
29

Les entre appauvries dcrivent les dispositifs dentre ou les combinaisons de dispositifs dont
la bande passante est infrieure celle des dispositifs standard. Les exemples vont dun dispositif
standard manquant des entres extrmement pauvres comme le simple bouton.
Nous dnissons ladaptabilit en entre comme une combinaison de trois proprits : la contrlabilit, laccessibilit et la congurabilit.
La contrlabilit est la capacit dun systme interactif exploiter efcacement des entres
enrichies, ou utiliser les dispositifs standard de faon plus efcace. Lutilisation efcace dentres enrichies implique un usage appropri de la bande passante utile et des compatibilits
tche/dispositif. Lutilisation plus efcace des entres standard implique lemploi de techniques
dinteraction plus concises et directes, de type Post-WIMP.
Laccessibilit est la capacit dun systme interactif exploiter des entres appauvries. Lutilisation efcace dentres appauvries implique lemploi de techniques dinteraction assez riches
pour compenser la dgradation de la bande passante et de la compatibilit tche/dispositif.
La congurabilit exprime la capacit pour lutilisateur de choisir librement la manire dont
il veut utiliser ses dispositifs dentre pour contrler lapplication. Cela va de la slection de
dispositifs et de lassignation dactions la spcication dtaille de techniques dinteraction
riches. La facilit de conguration joue galement un rle crucial dans la congurabilit, tout
comme le type dutilisateurs vis et les expertises requises.
1.4.3
Adaptabilit des systmes interactifs actuels
Dans cette section, nous dcrivons ladaptabilit en entre des systmes interactifs actuels. Nous
distinguons deux grands niveaux dadaptabilit : le niveau systme et le niveau applicatif.
Au niveau systme
Les dispositifs dentre sont grs en premier lieu au niveau du systme dexploitation, qui offre
des services de base aux applications interactives. Linteraction avec lensemble des applications interactives peut tre personnalise ce niveau.
La plupart des systmes dexploitation comportent des panneaux de conguration qui permettent
de personnaliser la gestion de la souris et du clavier (gure 1.29 page suivante). Sur les systmes de
type Microsoft Windows, lutilisateur peut ainsi adapter linteraction son niveau dexpertise (vitesse
du double-clic, dlai de rptition des touches du clavier), ses particularits culturelles (choix de la
langue du clavier) ou motrices (inversion des boutons de la souris pour gaucher) et, plus gnralement, ses prfrences individuelles (vitesse et apparence du pointeur, ouverture avec simple clic ou
double clic, etc.). Enn, des options daccessibilit permettent de faciliter laccs aux utilisateurs
handicaps par des techniques simples comme le ltrage des erreurs de frappe ou la rmanence de
touches facilitant lusage de combinaisons.
Malgr les fonctionnalits offertes par les panneaux de conguration, les systmes dexploitation restent extrmement rigides du point de vue des entres. Voici une liste non exhaustive de leurs
faiblesses :
Fusion des entres Les dispositifs de pointage multiples et les claviers multiples sont fusionns
au niveau du systme dexploitation. Lorsque plusieurs dispositifs de pointage (souris, tablette gra30
F IG . 1.29 Conguration de la souris sous Microsoft Windows NT4.
phique) sont connects, ils "poussent" tous le mme curseur, ce qui rend linteraction bimanuelle ou
multi-utilisateurs impossible. Les claviers multiples sont vus comme un seul clavier. Windows, par
exemple, ne permet pas daffecter une langue chaque clavier. La fusion des entres a des consquences ngatives sur la contrlabilit.
Entres tendues ignores : La plupart des dispositifs non-standard (manettes de jeux, dispositifs 3D) ne peuvent pas tre utiliss pour interagir avec les applications classiques. Certains pilotes
proposent un contrle "par compatibilit", mais dans lequel les caractristiques intressantes du dispositif sont ignores. Par exemple, une tablette graphique pourra servir des tches de pointage, mais
sa rsolution et sa sensibilit la pression seront inutilises. Le fait dignorer les entres tendues a
de fortes consquences sur la contrlabilit.
Entres standard requises : La suppression de la souris ou du clavier rend linteraction laborieuse, voire impossible. Les raccourcis-claviers ne sont pas conus pour remplacer la souris, car leur
utilisation exclusive est pnible, et parce quils ne balayent pas lensemble des tches possibles. Quant
aux outils de saisie textuelle par pointage, ils sont inexistants ou peu efcaces (clavier-cran). Linteraction exclusivement gestuelle en particulier, nest pas prise en compte dans les systmes dexploitation de type ordinateur de bureau. La ncessit demployer les dispositifs standard a des consquences
nfastes sur laccessibilit.
Congurabilit pauvre : Bien que parfois utiles, les panneaux de conguration des systmes
dexploitation, mmes surchargs, ne prennent en compte quun nombre xe de cas dj prvus
lavance. Chaque pilote de dispositif propose des outils de conguration bass sur le mme modle,
bien quadapts au type de matriel quil prend en charge. La pauvret de la congurabilit a naturellement des rpercussions importantes sur laccessibilit. Les options daccessibilit dans les systmes
dexploitation sont dailleurs anecdotiques car peu nombreuses, strotypes et souvent inadaptes.
La plupart des techniques daccessibilit courantes, bases sur lmulation de la souris et du clavier,
31

ne sont accessibles qu travers un matriel ou des logiciels spcialiss.
Au niveau des applications
Ladaptabilit en entre varie selon les applications. Nous distinguons quatre types dapplications
courantes : les applications traditionnelles, les applications spcialises, les jeux vido et les applications 3D.
F IG . 1.30 La conguration des touches dans un logiciel de capture dcran.
Les applications traditionnelles : Les applications traditionnelles comme les logiciels de bureautique reposent exclusivement sur les services fournis par le systme dexploitation, ou sur des outils
de dveloppement qui reposent sur ces services. Leur adaptabilit en entre est par consquent limite
celle prcdemment dcrite. Certaines de ces applications permettent travers des options de menu
de spcier des prfrences qui se limitent souvent, du point de vue des entres, la conguration
des raccourcis clavier. Bien que marginales, des techniques dinteraction non standard commencent
apparatre dans certaines applications commerciales. Cest le cas des commandes gestuelles dans les
navigateurs Mozilla [M OZILLA 03] et Opera [O PERA 03], qui offrent par consquent une contrlabilit
amliore par rapport aux applications conventionnelles.
Les applications spcialises : Certaines applications semi-professionnelles comme les logiciels
dinfographie ou de composition musicale gagnent particulirement tre utilises avec des dispositifs spcialiss. Ces dernires peuvent tre en partie contrls par des instruments de musique MIDI.
Le logiciel de dessin Adobe Photoshop gre les tablettes graphiques de faon spcique, et exploite
leur rsolution leve ainsi que leur sensibilit la pression [WACOM 03]. Cependant, la congurabilit
est limite (la pression ne peut tre assigne qu la taille de la brosse, son opacit ou sa couleur) et les
autres dimensions comme linclinaison (tilt) sont ignores. Ces applications spcialises offrent une
meilleure contrlabilit grce la prise en charge dun type de dispositif spcique en plus des dispositifs standard, mais leur utilisation reste trs classique et ils ne sont ni excessivement contrlables, ni
32
1.5. CONCLUSION
excessivement congurables, et encore moins accessibles.
F IG . 1.31 Conguration des entres dans le jeu Quake III [H ONEYWELL 99].
Les jeux vido : Les jeux vido supportent des dispositifs dentre de plus en plus sophistiqus,
tels que les manettes boutons multiples et les dispositifs de simulation. Traditionnellement, ils offrent
lutilisateur le choix entre le clavier, la manette et la souris pour contrler le jeu. La possibilit de
personnaliser les contrles est un aspect important des jeux vido (gure 1.31). Ainsi les boutons ou
les touches sont librement assignables. Cependant lutilisateur a moins de contrle sur la faon dont
les dimensions continues sont employes, et peut tout au plus jouer sur la sensibilit ou linversion
des axes. En outre, les dispositifs non-standard qui ne sont pas ddis aux jeux ne sont pas pris en
compte. Les jeux vido sont bien plus contrlables que les applications traditionnelles, mais ils sont
peine plus congurables, et laccessibilit nest pas une proccupation majeure dans ce secteur.
Les applications 3D : Les logiciels danimation et de modlisation 3D comme WorldUp [S ENSE 8 03]
ou Vega Prime [PARADIGM 03] supportent un grand nombre de dispositifs sophistiqus, tels que les souris 3D ou les capteurs six degrs de libert. En gnral, chaque dimension peut tre librement assigne des attributs dobjets 3D, ce qui offre des interactions la fois riches et congurables. Certaines
applications comme Virtools [V IRTOOLS 01] possdent un diteur graphique dinteraction qui, bien que
complexe dutilisation, multiplie les possibilits de conguration (voir la section 2.7 page 79 pour une
description de ces outils). Mais l encore, seuls les dispositifs et les techniques dinteraction 3D sont
pris en compte. Les applications 3D sont nanmoins les plus contrlables et les plus congurables,
bien que laccessibilit ne soit pas non plus une proccupation majeure dans ce domaine.
1.5 Conclusion
Nous avons montr dans ce chapitre lintrt de linteraction en entre non standard, dabord en
dcrivant des situations concrtes o lemploi de dispositifs dentre alternatifs ddis lutilisateur,
la tche ou lenvironnement est invitable ou permet damliorer considrablement la qualit de
linteraction. Puis, en prsentant les principaux nouveaux paradigmes dinteraction, que lon regroupe
sous le nom dinterfaces Post-WIMP, et qui autorisent des interactions plus concises, directes, parallles et naturelles.
33

Ces techniques sont peu connues ce jour, et la plupart nont t pas t exploites ailleurs que
dans des prototypes de recherche, ou ont t conues pour des situations professionnelles trs particulires. tant donn la dmocratisation des dispositifs non standard, beaucoup dentre elles pourraient
cependant tre employes dans linformatique grand public, dans laquelle les utilisateurs, les environnements de travail, et les tches potentielles sont extrmement varies.
partir de ce constat, nous avons dni pour les applications et les systmes interactifs grand
public une proprit qui nous semble essentielle, celle de ladaptabilit en entre. Ladaptabilit en
entre est la facult de prendre en compte la fois des entres enrichies et appauvries, demployer
des techniques dinteraction adaptes chacune de ces situations, et doffrir lutilisateur le choix de
ces techniques ainsi que la possibilit de les congurer nement.
Nous avons par la suite valu ladaptabilit en entre des applications interactives actuelles, et
constat une dmarcation importante entre les applications interactives conventionnelles et les applications comme les jeux vido et les applications 3D, pour lesquelles la compatibilit avec les dispositifs
non-standard est un critre commercial important. Dans lensemble cependant, les applications que
nous connaissons sont toutes extrmement limites dans leur adaptabilit en entre. Cest le cas aussi
bien des applications grand public que des applications usage semi-professionnel, et cela reste vrai
pour les applications plus spcialises.
La raison principale est que ces applications reposent sur des services et des outils qui sappuient
leur tour sur le modle rigide de linteraction standard, et qui font de ladaptabilit en entre un
objectif extrmement difcile atteindre. Limplmentation de nouvelles techniques dinteraction et
lexploitation des dispositifs dentre non-standard, en particulier, sont des tches extrmement ardues
pour le programmeur. De nombreux modles et outils pour lInteraction-Homme-Machine ont t
nanmoins tudis et proposes par la recherche, et le sont encore aujourdhui. Ces modles et outils
feront lobjet du prochain chapitre.
34
Chapitre 2
Modles et outils pour linteraction en

entre
Sommaire
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Introduction . . . . . . . . . . . . . . . . . . . .
Les modles dinterface de rfrence . . . . . . .
2.2.1 Les modles linguistiques . . . . . . . . .
2.2.2 Les modles agents . . . . . . . . . . . .
2.2.3 Conclusion . . . . . . . . . . . . . . . . .
Les modles dinterface formels . . . . . . . . .
2.3.1 Les systmes de transition . . . . . . . . .
2.3.2 Les interacteurs formels . . . . . . . . . .
2.3.3 Conclusion . . . . . . . . . . . . . . . . .
Les modles de dispositifs . . . . . . . . . . . . .
2.4.1 Les modles logiques . . . . . . . . . . . .
2.4.2 Les modles physiques . . . . . . . . . . .
2.4.3 Conclusion . . . . . . . . . . . . . . . . .
Les modles dinteraction . . . . . . . . . . . . .
2.5.1 La manipulation directe . . . . . . . . . .
2.5.2 Linteraction instrumentale . . . . . . . . .
2.5.3 Conclusion . . . . . . . . . . . . . . . . .
Les outils de dveloppement . . . . . . . . . . .
2.6.1 Les botes outils WIMP avances . . . .
2.6.2 Les botes outils Post-WIMP spcialises
2.6.3 Conclusion . . . . . . . . . . . . . . . . .
Les diteurs graphiques dinteraction . . . . . .
2.7.1 Les paradigmes de programmation visuelle
2.7.2 Les diteurs de simulations interactives . .
2.7.3 Les diteurs de comportements 3D . . . . .
2.7.4 Conclusion . . . . . . . . . . . . . . . . .
Synthse . . . . . . . . . . . . . . . . . . . . . .
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
40
43
44
44
46
49
50
50
51
54
56
56
57
60
60
61
67
78
79
79
80
85
89
90
CHAPITRE 2. MODLES ET OUTILS POUR LINTERACTION EN ENTRE
2.1 Introduction
Une interface graphique est un systme complexe, difcile apprhender dans son ensemble, et
qui ncessite dtre dcompos. Il existe de multiples stratgies de dcomposition, dont certaines ont
t acceptes comme rfrences, et que nous prsentons dans un premier temps. Contrairement aux
modles de rfrence, les modles de type formel dcrivent les interfaces ou des aspects particuliers
de ces interfaces de manire particulirement dtaille : nous prsentons ceux qui nous semblent pertinents du point de vue de linteraction en entre. Nous dcrivons ensuite deux types de modles qui
traitent deux aspects essentiels de linteraction en entre : les modles de dispositifs, dont lobjectif
est dextraire les caractristiques pertinentes des diffrents types de dispositifs dentre, et les modles dinteraction, qui dcrivent des rgles et des principes gnraux pour la conception dinterfaces
naturelles et efcaces.
Si les modles permettent de mieux comprendre linteraction et sont dune certaine aide dans
la phase de conception, les outils de dveloppement constituent les supports concrets pour limplmentation des applications interactives. Certains de ces outils sinspirent de modles existants et les
autres, largement majoritaires, emploient un modle dinterface spcique. Le dveloppement dapplications interactives repose en grande partie sur les botes outils graphiques traditionnelles, optimises et cbles pour linteraction en entre standard. Dautres botes outils graphiques, moins
connues, prennent en charge des dispositifs dentre ou des techniques dinteraction non conventionnelles. Nous prsentons ces dernires de faon dtaille, et discutons de leurs apports respectifs par
rapports aux botes outils traditionnelles. Pour nir, nous prsentons les diffrents types dditeurs
dinteraction, outils gnralement destins un plus vaste public que les programmeurs, et qui permettent de spcier tout ou partie de linteraction en entre.
Dans cet tat de lart, nous avons choisi de dtailler et dexpliquer les travaux reprsentatifs de
chacune de ces approches plutt que de produire des longues listes de rfrences. Les points-cls de
ce chapitre seront en outre rsums en guise de conclusion.
2.2 Les modles dinterface de rfrence

La recherche en interaction homme-machine a consacr beaucoup dnergie dvelopper des
modles gnriques et abstraits de systmes interactifs. Lobjectif de ces modles de rfrence est
dobtenir une meilleure comprhension des systmes interactifs existants, mettre en place une base
commune de communication sur le domaine, et guider le choix dune architecture logicielle lors du
dveloppement de nouveaux systmes interactifs.
Chaque modle se propose didentier les lments signicatifs qui entrent dans la composition
de la plupart des systmes interactifs, ainsi que les relations qui les lient. Bien que les terminologies
employes diffrent sensiblement, on retrouve souvent dun modle lautre les mmes principes de
base.
Tous les modles partent du principe quun systme interactif comporte une partie interface
et une partie application pure (gure 2.1 page ci-contre). Cette dernire est souvent appele noyau
fonctionnel, et tout ce qui sy rfre appartient au domaine. Le noyau fonctionnel est considr comme
prexistant, et les modles de systmes interactifs dcrivent essentiellement la partie interface, ainsi
que ses relations avec les objets du domaine.
36
2.2. LES MODLES DINTERFACE DE RFRENCE

Systme Interactif
Interface
noyau fonctionnel
U t ilisat e ur
F IG . 2.1 Modle primitif dun systme interactif.
La plupart des modles identient au moins trois types dlments dans la composition des interfaces, et distinguent un cot utilisateur et un ct noyau fonctionnel. Il comprennent presque
toujours des lments en contact direct avec lutilisateur (prsentations), des lments en contact direct avec le noyau fonctionnel ou qui en font partie (interfaces du noyau fonctionnel, abstractions,
modles), et des lments articulatoires (contrleurs, adaptateurs).
Malgr ces points communs, certains modles procdent dapproches trs diffrentes, et on distingue communment deux grands groupes de modles de rfrence. Les modles linguistiques ou
modles couches dcrivent la structure globale dune application interactive sous forme de couches
logiques. Ces modles sont galement appels modles logiques, ou sont qualis dabstraits. Les seconds types de modles sont les modles agents ou interacteurs, ou encore modles orients objet.
Ces modles sinspirent du paradigme de programmation par objets, et proposent une dcomposition
modulaire de linterface en un ensemble dagents communicants.
Nous dcrivons dans la suite ces deux groupes de modles, ainsi que leurs principaux reprsentants.
2.2.1
Les modles linguistiques
Les modles de rfrence linguistiques se basent sur une approche linguistique de linteraction,
inspire des architectures de compilateurs. Lapproche linguistique identie trois aspects dans linteraction :
Aspects lexicaux : ces aspects dsignent tout ce qui peut tre assimil un vocabulaire dentre
(clic, glisser), ou de sortie (ensembles dicnes).
Aspects syntaxiques : ils peuvent dsigner des grammaires dentre reprsentant les squences
dactions valides, ou les aspects spatiaux et temporels de lafchage.
Aspects smantiques : ils correspondent la partie fonctionnelle de lapplication, qui dtermine
en dernier lieu le sens dune action et gnre les erreurs.
dfaut de donner des indications prcises sur la faon dont doit tre structur et implment un
systme interactif, les modles linguistiques identient les couches logiques qui doivent y apparatre.
Dans cette section, nous dcrivons dans leurs grandes lignes et de faon chronologique les principaux modles linguistiques, savoir le modle de Seeheim, le modle Arch, ainsi que son mtamodle
Slinky.
37

Retour
smantique
rapide
Prsentation
Contrleur
Interface du
de dialogue
noyau fonctionnel
N oya u
Fonc t ionne l
U t ilisat e ur
F IG . 2.2 Le modle de Seeheim.
Seeheim
Le premier modle de rfrence largement accept part dune approche linguistique. Celui-ci est
issu dun groupe de travail sur les systmes interactifs ayant eu lieu Seeheim en 1985 [P FAFF 85].
Le modle de Seeheim tait principalement destin au traitement lexical des entres et sorties dans
les interfaces textuelles. Sil est peu utile aujourdhui pour dcrire les systmes interactifs hautement
graphiques, il a servi de base beaucoup dautres modles.
Le modle de Seeheim[P FAFF 85] propose de diviser linterface en trois couches logicielles selon
une approche linguistique (gure 2.2) :
La prsentation est la couche en contact direct avec les entres et sorties. Elle interprte les
actions de lutilisateur (dispositifs physiques) et gnre les sorties (afchage) au niveau lexical.
Le contrleur de dialogue gre le squencement de linteraction en entre et en sortie. Il maintient un tat lui permettant de grer les modes dinteraction et les enchanements dcrans.
Linterface du noyau fonctionnel est la couche adaptative entre le systme interactif et le noyau
fonctionnel. Elle convertit les entres en appels du noyau fonctionnel et les donnes abstraites
de lapplication en des objets prsentables lutilisateur.
Un autre lment a t ajout au modle de Seeheim pour prendre en compte le retour smantique
rapide : par exemple, lors dune opration de glisser-dposer, il peut savrer utile de modier instantanment lapparence de licne-cible pour indiquer si lopration est valide. Dans ce cas, la couche de
prsentation doit court-circuiter le contrleur de dialogue pour accder directement aux informations
smantiques du noyau fonctionnel.
Arch / Slinky
Le modle Arch [UIMS 92] afne le modle de Seeheim en sinspirant davantage des botes
outils graphiques actuelles. Ce modle incorpore la notion de plate-forme de dveloppement, et dcrit
la nature des donnes qui transitent entre les diffrents composants.
Le modle Arch identie cinq composants dans les systmes interactifs (gure 2.3 page ci-contre) :
Le composant dinteraction dsigne lensemble des widgets (objets interactifs) dune bote
outils, ainsi que les communications avec les priphriques physiques. Il dpend dune plateforme donne.
38
Contrleur
Objets de
prsentation
de dialogue
Objets du
domaine
Adaptateur de
Prsentation
domaine
Objets
d'interaction
Objets du
domaine
Interaction
noyau fonctionnel
U t ilisat e ur
F IG . 2.3 Le modle Arch.
Le composant de prsentation joue le rle de mdiateur entre le composant dinteraction et le

contrleur de dialogue. Il maintient une reprsentation logique des widgets qui est indpendante
de la plate-forme.
Le contrleur de dialogue joue le mme rle articulatoire que celui du modle de Seeheim. Il
est notamment responsable du squencement des tches et du maintien de la consistance entre
les vues multiples.
Ladaptateur du domaine est un composant mdiateur entre le contrleur de dialogue et le
noyau fonctionnel. Il est responsable des tches dpendantes du domaine qui ne font pas partie
du noyau fonctionnel mais qui sont ncessaires sa manipulation par lutilisateur. Ces tches
comprennent la rorganisation des donnes du domaine dans des buts de manipulation interactive, ou la dtection des erreurs smantiques.
Le noyau fonctionnel reprsente la partie non interactive de lapplication.
Le composant dinteraction et le noyau fonctionnel constituent les deux pieds de larche. Les
autres composants dcrivent la partie de linterface qui doit tre implmente pour faire le lien entre
la partie purement fonctionnelle dune application et les widgets et les vnements de la bote outils.
Le modle Arch introduit galement trois types dobjets dcrivant la nature des informations qui
transitent entre les composants (gure 2.3) :
Les objets du domaine contiennent des donnes provenant directement ou indirectement du
noyau fonctionnel (par exemple, le rsultat dune requte dans une base de donns).
Les objets de prsentation sont des objets dinteraction virtuels qui dcrivent les vnements
produits par lutilisateur et les donnes qui lui sont prsentes, indpendamment des mthodes
dinteraction et de visualisation.
Les objets dinteraction sont des instances propres une bote outils, et qui implmentent des
techniques dinteraction et de visualisation spciques.
Dans la ralit, le poids relatif des composants Arch et la rpartition de leurs fonctionnalits
peut varier selon les types dapplications interactives et les choix et impratifs xs par leurs dve39
F IG . 2.4 Le jouet Slinky ayant inspir le modle du mme nom.
loppeurs. Un mtamodle baptis Slinky [UIMS 92] a t conu au-dessus du modle Arch an de
suggrer lexistence de ces variantes du modle Arch. Le mtamodle Slinky, inspir du jouet de
mme nom (gure 2.4), met notamment en vidence les notions de choix et de compromis inhrents
au dveloppement des applications interactives.
2.2.2
Les modles agents
En dcomposant les interfaces en objets de mme nature, les modles agents sont proches
des langages programmation objets et des interfaces manipulation directe modernes. Dans cette
section, nous dcrivons les princpaux modles agents, savoir MVC, PAC et le modle hybride
PAC/Amodeus.
MVC
Modle
Vue
Contrleur
U t ilisat e ur
U t ilisat e ur
F IG . 2.5 Le modle MVC.
Le modle MVC (Modle, Vue, Contrleur) [S CHMUCKER 86, K RASNER & P OPE 88] a t introduit
comme architecture de rfrence dans limplmentation des interfaces utilisateur de lenvironnement
Smalltalk [G OLDBERG & ROBSON 81]. Lapproche de MVC inspirera toute une ligne de modles base
dagents, dont les principales motivations sont la modiabilit et la conception itrative, ainsi que la
compatibilit avec les langages objets.
40

MVC dcompose les systmes interactifs en une hirarchie dagents. Un agent MVC consiste en
un modle muni dune ou plusieurs vues, et dun ou plusieurs contrleurs :
Le modle est le noyau fonctionnel de lagent. Il peut reprsenter des donnes brutes (entier,
chane de caractres) ou des objets ayant un comportement complexe. Le modle notie les vues
qui lui sont associes chaque fois que son tat se trouve modi par le noyau de lapplication
ou par ses contrleurs.
La vue maintient une reprsentation du modle perceptible par lutilisateur, quelle met jour
chaque changement dtat du modle. Elle est en gnral constitue dobjets graphiques. La
gure 5 donne plusieurs exemples de vue pour un modle simple.
Le contrleur reoit et interprte les vnements utilisateur, en les rpercutant sur le modle
(modication de son tat) ou sur la vue (retour instantan).
F IG . 2.6 Plusieurs exemples de look & feels pour un modle consistant en une valeur entire et son
domaine.
Chacun des trois composants de la triade MVC est un objet part entire. Au sens de la programmation oriente objet, une classe de Modle peut tre compatible avec plusieurs classes de Vues et de
Contrleurs. Les composants interactifs dune bote outils (widgets) sont la plupart du temps livrs
avec un ensemble de paires Contrleur/Vue, appeles look & feels. Un entier comportant une valeur
minimale et une valeur maximale peut tre ainsi reprsent par une jauge, un curseur, un champ de
saisie, ou une barre de dlement (gure 2.6).
PAC
U t ilisat e ur
Prsentation
Abstraction
Contrle
F IG . 2.7 Le modle PAC.

Par rapport MVC, le modle agents PAC (Prsentation, Abstraction, Contrle) [C OUTAZ 87]
r-introduit la vue et le contrleur dans un objet monolithique mais rend explicite la synchronisation
41

du modle et de la vue/contrleur. Il propose en outre une mthode de description rcursive qui tend
le paradigme agents avec la notion de couche dabstraction.
Comme MVC, le modle PAC dcrit les systmes interactifs comme une hirarchie dagents composs de trois modules. Mais ici, le rle de ces modules diffre (gure 2.7 page prcdente) :
La prsentation dnit le comportement en entre et en sortie de lagent, tel quil est peru par
lutilisateur.
Labstraction encapsule la partie smantique de lagent.
Le contrle maintient la consistance entre la prsentation et labstraction, et communique avec
les autres agents.
Notons quici le composant dabstraction est lquivalent du composant modle de MVC, et que
la prsentation correspond une fusion des composants vue et contrleur. Le composant contrle na
pas dexistence explicite dans le modle MVC.
A
P
C
P
C
P
C
P
C
P
C
P
C
F IG . 2.8 Hirarchie dagents PAC.
Par une approche rcursive, le modle PAC peut tre appliqu de manire consistante plusieurs
niveaux dun systme interactif. Une application interactive peut ainsi tre dcrite comme une hirarchie dagents disposs sur plusieurs couches dabstractions (gure 2.8). Ce type de reprsentation
unie en quelque sorte les modles agents et les approches couches de type Seeheim.
PAC/Amodeus
PAC/Amodeus [N IGAY & C OUTAZ 93] nit de rconcilier les approches linguistiques et agents en
proposant un modle hybride. Il rutilise le modle Arch et dcrit son contrleur de dialogue avec
une hirarchie dagents PAC (gure 2.9 page ci-contre). Ladaptateur de domaine et la prsentation de
lArch communiquent directement avec chaque agent PAC travers son abstraction (pour le premier)
et sa prsentation (pour le second).
Lobjectif de PAC/Amodeus est de combiner les avantages du modle Arch, qui intgre des aspects
de gnie logiciel comme la modiabilit et la portabilit, et du modle PAC, qui permet de structurer
efcacement le contrleur de dialogue jusque-l monolithique. Le modle PAC/Amodeus a t employ pour modliser des plate-formes multimodales [N IGAY & C OUTAZ 95]. Les entres sont dcrites
par des symboles et des grammaires, et des mcanismes de fusion de haut-niveau sont implments
dans le dialogue par des agents PAC.
42

Contrleur de dialogue
Adaptateur de
Prsentation
domaine
Interaction
noyau fonctionnel
U t ilisat e ur
F IG . 2.9 Le modle PAC/Amodeus
2.2.3
Conclusion
Nous avons prsent dans cette section les principaux modles dinterfaces de rfrence, dont
lobjectif est de fournir des stratgies de dcomposition fonctionnelle et structurelle pour les interfaces
utilisateur an de simplier leur conception et constituer un support de raisonnement.
Les modles linguistiques dcomposent les interfaces en un petit nombre de couches, chaque
couche possdant un rle spcique et traduisant un niveau dabstraction. Cette approche est encore
utile pour comprendre le fonctionnement de linteraction, mais elle trop monolithique, abstraite et peu
structurante. En outre, cette approche qui trouve son origine dans les interfaces textuelles est de plus
en plus difcile appliquer telle quelle aux interfaces modernes et encore plus aux interfaces PostWIMP. Cest en particulier le cas de Seeheim. Lapproche Arch est nanmoins plus pragmatique, car
elle sinspire des architectures concrtes des systmes interactives, avec les notions de plate-forme et
de bote outils.
Les modles agents dcrivent un autre style de dcomposition pour les interfaces utilisateur
(dite aussi horizontale par opposition aux modles couches) : ces agents modlisent le systme
de faon homogne. Cette approche est particulirement adapte aux styles de programmation par
objets, et permet de dcrire des aspects tels que la modularit, le paralllisme et la distribution. La
ncessit, cependant, de prendre en compte lhtrognit des systmes interactifs a conduit au modle PAC/Amodeus. PAC/Amodeus emprunte Arch des principes de gnie logiciel essentiels telles
que la modiabilit et la portabilit, incarnes par ses adaptateurs de domaine et son composant de
prsentation.
Malgr leurs apports, les modles de rfrence ne sont pas dune grande aide pour dcrire les
aspects bas-niveau de linteraction, aussi bien du point de vue sorties quentres, ces aspects tant
systmatiquement encapsuls dans des blocs monolithiques. Rien nest dit non plus sur les techniques
dinteraction. Arch et PAC/Amodeus, en particulier, ne dcrivent pas la faon de rpartir les techniques
dinteraction entre le composant de Prsentation, le composant dInteraction, et leur protocole de
communication.
MVC est le seul modle dissocier la gestion des entres de celle des sorties dans chacun de ses
43

agents, ce qui permet conceptuellement de dcrire lapparence ou le comportement en entre dun
objet interactif de faon indpendante. Si cette sparation est trs avantageuse du point de vue de la
modiabilit, elle est souvent difcile mettre en uvre : dans la plupart des composants visuels, la
faon dont les entres sont interprtes est trs lie lafchage. MVC ne dcrivant pas de protocole de
communication entre les deux composants, la plupart des botes outils existantes prfrent fusionner
la vue et le contrleur en une entit unique [F OWLER 99].
2.3 Les modles dinterface formels

Une grande varit de modles, langages et mthodes formelles ont t dvelopps pour spcier,
concevoir, vrier, implmenter et tester divers systmes. Certains dentre eux ont t employs dans
le but de concevoir des interfaces plus ables, cest--dire moins sujettes aux erreurs de conception
humaines. Ces mthodes sont principalement employes dans les applications critiques, par exemple
celles qui mettent en jeu la vie ou la scurit humaine (centrales nuclaires, contrle arien). Elle
sont galement employes dans certaines applications industrielles non critiques car elles donnent
des garanties de abilit tt dans le cycle de conception et permettent de raccourcir la phase de test.
Les modles formels sont galement utiliss comme support pour raisonner sur les proprits et le
comportement des interfaces.
Les mthodes formelles ne constituent pas le sujet de notre thse. Cependant, ce sont galement
des modles dinterfaces, et nous les dcrivons comme tels. Nous prsentons ici deux approches qui
nous semblent essentielles dans le domaine de linteraction homme-machine : les modles base de
systmes de transition et les modles dinteracteurs formels.
2.3.1
Les systmes de transition
Les systmes de transition dsignent un ensemble des notations permettant de dcrire des comportements dits orients contrle . Il en existe un trs grand nombre, presque tous des extensions
des automates tats nis ou des rseaux de Petri respectivement introduits en 1955 et 1962.
Ces deux notations graphiques et leurs variantes sont encore couramment employes aujourdhui
en interaction homme-machine, soit des ns de spcication formelle, soit pour raisonner sur des
systmes interactifs ou expliquer leur fonctionnement. Sils ne permettent de dcrire que des petites
parties dune interface (et ne constituent pas des modles dinterfaces proprement parler), ils entrent
dans la composition de certaines mthodes formelles plus exhaustives. Nous prsentons ici ces deux
notations et quelques-uns de leurs emplois.
Les automates tats nis
Les automates tats nis ou machines tats nis, dont les principales variantes sont les machines de Moore [M OORE 56] et de Mealy [M EALY 55], ont t employs pour spcier le comportement
dynamique de certains systmes, et sont notamment utiliss pour dcrire certaines parties des interfaces utilisateur.
Les automates tats nis sont reprsents graphiquement par des diagrammes de transition
dtats, graphes orients dont les nuds sont des tats et les arcs des transitions (gure 2.10). Un
44
2.3. LES MODLES DINTERFACE FORMELS

tat est un ensemble de valeurs qui caractrise le systme un moment donn dans le temps. Une
transition dtat est une relation entre deux tats indiquant un changement dtat possible, et qui peut
(dans les automates tendus, par exemple) tre annote pour indiquer les conditions et les sources de
dclenchement (vnements) et les oprations qui en rsultent (sorties).
move
drag_feedback
press
release
drag_start
drag_end
F IG . 2.10 Le cliquer-glisser dcrit par un diagramme de transition dtats [T YSON R. et al. 90].
La gure 2.10 est un diagramme de transition dtats simple et classique qui dcrit la gestion du
cliquer-glisser (drag_start, drag_feedback, drag_end) partir dvnements souris de type press, release et move [T YSON R. et al. 90]. Les transitions sont annotes par les vnements qui les dclenchent
(en gras) et les sorties produites (en italique). Cet automate ltre tous les vnements move ayant lieu
avant le press ou aprs le release.
Les automates tats nis menant rapidement une explosion du nombre dtats et de transitions, de nombreuses extensions ont t proposes. Les machines tats hirarchiques et les statecharts [H AREL 87] dcrivent des automates composables, ce qui facilite la description de systmes
complexes et autorise la rutilisabilit. Les automates tats nis peuvent galement tre employs
comme complments des outils de programmation conventionnels [B LANCH 02] ou en association
avec dautres formalismes pour dcrire des parties plus importantes de linterface. Robert Jacob[JACOB et al. 99]
emploie des automates pour spcier les aspects discrets de linteraction en entre et des ots de donnes pour les aspects continus. Il dcrit galement un diteur visuel VRED qui sera voqu dans la
section 2.7.3 page 88.
Les rseaux de Petri
Les rseaux de Petri [P ETRI 62] sont une gnralisation des automates tats. Ils ont t largement
utiliss pour modliser la concurrence et la synchronisation dans les systmes distribus, et sont employs pour dcrire certains comportements dans les interfaces. Nous prsentons cette notation sans
rentrer dans les dtails.
Un rseau de Petri est un graphe biparti altern qui possde deux types de nuds : les places
(cercles) et les transitions (rectangles). Des arcs (ches) relient les places aux tats (voir gure 2.11
page suivante). Ltat du systme, nomm marquage, est dni par la rpartition de jetons (petits
cercles foncs) dans les places. Une transition est franchissable sous certaines conditions, notamment
lorsque sufsamment de jetons sont prsents dans ses places dentre. Le franchissement dune transition se traduit par une modication du marquage consistant la plupart du temps en un dplacement
de jetons.
Le modle des transducteurs formels [ACCOT et al. 97] emploie des rseaux de Petri de haut-niveau [J ENSEN 95]
pour dcrire les transformations successives des vnements dentre. La gure 2.11 page suivante
45
F IG . 2.11 Un comportement bas-niveau du clavier (rptition de touches) dcrit avec une variante labore
de rseau de Petri [ACCOT et al. 97].
dcrit un niveau de transformation pour le clavier. Dans cette notation, les jetons sont typs et comportent une valeur, les arcs sont annots par des variables (<k> sur la gure) et des vnements extrieurs viennent dclencher des transitions (ellipses grises et ches coudes). Quatre touches sont
reprsentes par quatre jetons en haut de la gure, en attente dans la place Idle. En-dessous se trouve
la transition Post, qui est active par des vnements clavier de type Down avec une touche k en
paramtre. Lorsquun vnement < Down, k > arrive, cette transition est franchie si le jeton k est
prsent dans Idle, auquel cas le mme vnement < Down, k > est gnr et le jeton passe dans la
place KeyPressed. Il retourne la place Idle lors du prochain vnement U p. Une partie de ce rseau
de Petri rpte simplement les vnements Down et U p (avec cependant un ltrage grammatical),
et une autre partie (la partie grise) dcrit un mcanisme de rptition automatique de touches avec
gnration dvnments Repeat. Cette dernire emploie des rseaux de Petri stochastiques gnraliss [M ARSAN et al. 95] pour dcrire des transitions temporises.
Les rseaux de Petri ont t intgrs dans plusieurs mthodes et outils formels utiliss pour dcrire la majeure partie des interfaces utilisateur. Le formalisme ICO (Interactive Cooperative Objects) [PALANQUE & BASTIDE 93, PALANQUE & BASTIDE 97] emploie une approche oriente-objet pour modliser les aspects statiques du systme interactif et des rseaux de Petri de haut-niveau pour en dcrire
les aspects dynamiques. Il est livr avec loutil PetShop [BASTIDE et al. 02, S CHYN et al. 03], qui comporte
un diteur interactif permettant de construire des spcications ICO et de les excuter.
2.3.2
Les interacteurs formels
Dans cette section, nous regroupons sous le terme interacteurs formels deux modles formels trs
lis, et qui dcomposent les systmes interactifs en units autonomes appeles interacteurs (objets
dinteraction), qui communiquent entre eux, avec le systme ou avec lutilisateur par le biais de stimuli
(ou vnements).
Les deux principaux modles formels base dinteracteurs ont t dvelopps dans le cadre
du projet Esprit AMODEUS, lun lUniversit dYork (Angleterre), lautre linstitut CNUCE
46

(Pise, Italie). Le modle dYork [D UKE & H ARRISON 93] est une variante modulaire du modle mathmatique PIE [D IX & RUNCIMAN 85]. Son but est de fournir un cadre pour une spcication structure
des systmes interactifs base de notations orientes modle comme Z ou VDM. Lapproche de
CNUCE [PATERN & FACONTI 92], inspire des travaux sur les modles graphiques de rfrence comme
GKS [ISO 85], est plus constructive. Ce modle est utilis conjointement avec LOTOS [ISO 87], un
langage bas sur lalgbre des processus.
Nous donnons ici un aperu conceptuel de ces deux modles, sans rentrer dans les dtails lis aux
notations mathmatiques.
Les interacteurs dYork

Dans le modle dYork [D UKE & H ARRISON 93], un interacteur est dni comme un composant dans
la description dun systme interactif qui encapsule un tat, les vnements qui manipulent cet tat,
et les moyens par lesquels cet tat est rendu perceptible par lutilisateur.
F IG . 2.12 Schma gnral dun interacteur dYork.
Le schma gnral dun interacteur dYork est reprsent sur la gure 2.12. Un interacteur dYork
consiste en un objet comportant un tat et communiquant avec son environnement par des vnements
de type stimulus ou rponse. Un interacteur possde galement une prsentation, qui rete ltat de
lobjet de faon perceptible par lutilisateur. La relation de rendu spcie les prsentations possibles
pour un tat (et ventuellement un historique) donn de lobjet.
Dans une version rafne de ce modle, llment prsentation est explicit par un nouvel objet
appari lobjet principal, et dont ltat interne reprsente les caractristiques dafchage perceptibles
par lutilisateur.
La gure 2.13 page suivante montre comment un comportement simple de systme interactif
peut tre dcrit par des combinaisons dinteracteurs. Dans cet exemple, des icnes (disques, chiers,
rpertoires) peuvent tre manipules par une souris un bouton reprsent par un curseur. Une icne
peut tre slectionne ou dslectionne en cliquant son emplacement, ce qui a pour effet de changer
son apparence. Enn, les icnes slectionnes peuvent tre dplaces en cliquant sur la commande
dplacer dans un menu, puis en bougeant la souris.
47
F IG . 2.13 Un mcanisme simple de slection et de dplacement dicnes dcrit avec les interacteurs
dYork.
Les interacteurs de CNUCE

Le modle de CNUCE [PATERN & FACONTI 92], plus dtaill que le prcdent, dcrit en plus la
structure et le comportement de base dun interacteur, distingue plusieurs types et sources dvnements, et introduit la notion de niveau dabstraction.
Les auteurs de ce modle dnissent un interacteur comme une entit dun systme interactif capable de ragir des stimuli externes, en traduisant des donnes dun haut niveau dabstraction vers
un niveau plus bas dabstraction et vice-versa. Un systme interactif est ainsi dcrit comme un graphe
dinteracteurs communiquant entre eux. Au plus bas niveau, ils communiquent avec lutilisateur et au
plus haut niveau, ils communiquent avec lapplication.
F IG . 2.14 Le schma simpli dun interacteur de CNUCE ( gauche), et sa structure interne (

droite). Le schma de droite reproduit les noms de ux employs dans le formalisme original.
Vu de lextrieur, un interacteur peut (gure 2.14, schma de gauche) :

Recevoir et accumuler des informations du ct application (a)
Recevoir du ct application un signal dclencheur (b) provoquant une mission dinformations
du ct utilisateur (c)
Recevoir et accumuler des informations du ct utilisateur (d) et mettre un retour du ct
utilisateur (c)
Recevoir du ct utilisateur un signal dclencheur (e) provoquant du ct application une mis48

sion des informations accumules (f).
Vu de lintrieur, un interacteur est structur en quatre composants qui communiquent entre eux
(gure 2.14 page prcdente, schma de droite) : la collection maintient les informations relatives au
modle abstrait de linteracteur. Lorsque cet lment est dclench, il transmet ces informations la
prsentation qui met jour les lments visibles par lutilisateur. Dautre part, la mesure reoit et
accumule les informations provenant de lutilisateur. Lorsquelle est dclenche, elle les transmet
labstraction qui les convertit en donnes abstraites manipulables par lapplication. La mesure peut
galement se servir dinformations provenant de la collection.
Notons que llment collection peut tre assimil ltat de linteracteur dYork, et que la prsentation joue peu prs le mme rle dans les deux modles. La mesure et labstraction nont pas
dquivalent dans le modle dYork, et font implicitement partie de ltat.
F IG . 2.15 Vue interne de linteracteur Commandes dans le modle de CNUCE.

Lexemple de la section prcdente peut tre dcrit avec trois interacteurs, de manire trs analogue au modle dYork. La gure 2.15 reproduit uniquement linteracteur Commandes. Les entres
du ct utilisateur (en bas droite) sont connectes linteracteur Souris, et la sortie du ct application (en haut droite) est connecte linteracteur Icnes. Les autres connexions sont laisses
implicites. Lorsquil est dclench par un clic de souris, linteracteur compare la position courante
stocke dans la mesure la structure stocke dans la collection, et selon loption active dans le menu,
gnre lvnement appropri interprtable par les autres interacteurs.
2.3.3
Conclusion
Dans cette section, nous avons donn un bref aperu de deux approches formelles employes pour
dcrire les interfaces utilisateur, savoir les systmes de transition et les interacteurs formels.
Les systmes de transition sont particulirement bien adapts la description des comportements
de type contrle dans les applications interactives. Ils ont t employs pour dcrire le niveau dialogue
de linteraction, le comportement des widgets, ou encore la production dvnements synthtiques. Le
modle des transducteurs formels propose un modle dentre transformationnel, et constitue une tentative intressante de modliser par rtro-conception le comportement trs bas-niveau des dispositifs
physiques. Les systmes de transition ne permettent cependant pas de dcrire des parties importantes
des interfaces, en particulier les ux de donnes et linteraction continue, et cest pourquoi ils sont
frquemment employs en conjonction avec dautres formalismes.
49

Les interacteurs formels sont beaucoup plus structurants pour les interfaces graphiques. Ils dcomposent linteraction en des entits communicantes, la manire des modles de rfrence agent.
Ces interacteurs reoivent des valeurs en entre et produisent des sorties. Les interacteurs dYork
communiquent entre eux par des stimuli et des rponses, et avec lutilisateur en maintenant une prsentation. Mais la partie entre de cette communication nest pas explicite dans le modle. Le modle
de CNUCE, en plus de dcrire une structure et un comportement interne pour les interacteurs, emploie
comme les transducteurs formels un modle dentres de type transformationnel bas sur des couches
dabstractions successives.
2.4 Les modles de dispositifs

Face une prolifration incontrle des dispositifs dentre, il est rapidement devenu ncessaire
de construire des modles pour faire face une telle complexit. Nous distinguons deux grands courants dans les modles de dispositifs dentre : les modles logiques, dont lobjectif est de faciliter
limplmentation dapplications interactives portables, et les modles physiques, dont le but est de
mieux comprendre et exploiter la grande varit des dispositifs existants.
Les modles logiques sont intimement lis lhistoire de la standardisation de linformatique
graphique. Nous les dcrivons dans un premier temps. Les modles physiques, qui consistent principalement en deux taxinomies, seront dcrites par la suite.
2.4.1
Les modles logiques
Les dispositifs logiques de GKS et PHIGS

Il y a trente ans, les applications graphiques interactives taient encore ddies un matriel
spcique et ncessitaient normment de programmation bas-niveau. Sentant quil devenait ncessaire de disposer dun standard pour ces machines, la communaut de linformatique graphique jeta
les premires bases dune API standard avec Core [D UNN & H ERZOG 77], qui aboutit au standard international GKS [E CKERT et al. 79, ISO 85]. Par la suite, deux extensions 3D de GKS furent proposes :
3D-GKS [K ANSY 85] et PHIGS [H EWITT 84] (Programmers Hierarchical Interactive Graphics System),
auquel succda PHIGS+ [VAN DAM 88] (gure 2.16).
F IG . 2.16 Historique des standards graphiques.
Lobjectif des standards graphiques est lindpendance du code vis--vis du matriel. En termes
de sorties, cette indpendance se fait par la dnition dune API graphique gnrique. Pour les entres,
le standard GKS introduit le modle des dispositifs dentre logiques, qui sera repris dans PHIGS et
PHIGS+.
50
2.4. LES MODLES DE DISPOSITIFS

Le modle des dispositifs logiques identie six (ou cinq, selon la spcication) classes dentres.
Ces classes reprsentent des dispositifs physiques gnriques qui diffrent par le type de donnes
quelles peuvent fournir lapplication :
Locator : position de type (x, y).
Stroke : srie de points de type (x, y)n .
Valuator : valeur relle ou entire borne.
Choice : entier reprsentant une slection parmi un ensemble dalternatives.
Pick : identiant dun objet prsent lcran.
String : chane de caractres.
Sur un systme donn, chacun de ces dispositifs logiques est implment par un dispositif physique et une technique dinteraction particulires. Par exemple, une valeur de type Choice peut tre
spcie par un tableau de boutons ou par un menu graphique. Ce paradigme garantit la portabilit
des applications et simplie la tche du programmeur, dans lhypothse o celui-ci ne sintresse pas
la faon dont les donnes utilisateur sont obtenues.
Les tches dinteraction de Foley
Aprs avoir contribu au standard GKS, James Foley a introduit la notion de tches dinteraction
gnriques [F OLEY et al. 84]. Plus ou moins calques sur les dispositifs logiques, ces tches dinteraction
mettent laccent sur les intentions de lutilisateur plutt que sur des types de donnes. Elles sont au
nombre de six :
Select : slection dun objet.
Position : positionner un objet sur 1, 2, 3 dimensions ou plus.
Orient : orienter un objet sur 1, 2, 3 dimensions ou plus.
Ink : dessiner une ligne.
Text : saisir un texte.
Value : spcier une valeur scalaire.
Foley numre alors, pour chaque tche dinteraction, les techniques dinteraction et les dispositifs
physiques permettant de la raliser. La gure 2.17 page suivante illustre les relations possibles entre
trois tches (les racines de larbre) et les dispositifs physiques (les feuilles de larbre). Cet arbre
peut tre lu comme une taxinomie de dispositifs, bien que ceux-ci apparaissent plusieurs fois dans la
reprsentation.
2.4.2
Les modles physiques
La taxinomie de Buxton
Selon William Buxton, les abstractions fournies par les modles logiques sont utiles pour le
programmeur, mais vont lencontre des considrations dutilisabilit [B UXTON 83]. En particulier,
51
F IG . 2.17 La taxinomie de Foley [F OLEY et al. 84].
elles prsupposent que deux dispositifs peuvent tre totalement interchangeables (voir la section 1.2.1
page 7 ce sujet). Or les aspects physiques des interfaces, identis par Buxton comme le niveau
pragmatique de linteraction, ont des effets extrmement importants sur la perception des systmes
par lutilisateur.
Buxton recommande dinclure les caractristiques pragmatiques des dispositifs dentre dans
les spcications de dispositifs gnriques. Il propose un ensemble de caractristiques pertinentes,
avec lequel il construit une taxinomie des dispositifs dentre. Cette taxinomie est reproduite sur la
gure 2.18 page ci-contre.
Les deux principaux axes de la taxinomie sont les suivants :
Nombre de dimensions : Les dispositifs une dimension comprennent les dispositifs de type potentiomtre rotatif ou linaire. Les dispositifs deux dimensions comprennent lensemble des
dispositifs de pointage et des manettes. Les dispositifs trois dimensions incluent les manettes
3D et trackballs 3D.
Proprit capte : Parmi les dispositifs prcdents, certains captent une position (tous les dispositifs isotoniques), dautres un dplacement (souris, dispositifs lastiques), et dautres enn une
pression (dispositifs isomtriques).
Buxton suggre galement de prendre en compte les aspects continu/discret ainsi que lagent de
contrle (main, pied, voix, . . .), seuls les dispositifs manuels et continus tant reprsents dans sa
taxinomie. Une liste trs complte des caractristiques pragmatiques prendre en compte a t plus
tard fournie par Lipscomb et Pique [L IPSCOMB & P IQUE 93].
52
F IG . 2.18 La taxinomie de Buxton [BUXTON 83].
Lespace de conception de Card, Mackinlay et Robertson

En sinspirant de la taxinomie prcdente, Card, Mackinlay et Robertson [C ARD et al. 90, C ARD et al. 91]
ont propos un espace de conception pour les dispositifs dentre, donnant lieu une taxinomie gnrale et dtaille des dispositifs existants qui peut galement servir de support la cration de nouveaux
dispositifs.
Partant du principe quun dispositif dentre traduit des proprits physiques du monde en des paramtres logiques dune application, Card dnit un dispositif dentre par un n-uplet M, In, S, R, Out,W
o :
M est loprateur de manipulation qui dcrit le type de proprit capte : position ou force,
absolu ou relatif, linaire ou angulaire.
In est le domaine dentre, cest--dire les valeurs prises par la grandeur physique capte.
S est ltat courant du dispositif.
R est la fonction de rsolution, qui chaque valeur du domaine dentre associe une valeur du
le domaine de sortie.
Out est le domaine de sortie qui dcrit les valeurs logiques possibles.
W est un ensemble de proprits qui dcrivent des aspects fonctionnels supplmentaires du
dispositif.
Trois oprateurs dcrivent les diffrentes manires de composer ces dispositifs atomiques pour
former des dispositifs plus complexes (gure 2.19 page suivante) :
Lunion (merge) consiste composer deux dispositifs an que le domaine dentre rsultat
soit le produit cartsien des deux domaines dentre sources. Par exemple, une souris peut tre
considre comme lunion de deux potentiomtres linaires orthogonaux.
53
F IG . 2.19 Construction dune souris laide des trois oprateurs de composition [C ARD et al. 91].
Lagencement (layout) consiste composer spatialement deux dispositifs. Un exemple est

lagencement spatial des axes (x, y) et des trois boutons dune souris.
La connexion (connect) consiste composer deux dispositifs an que le domaine de sortie du
premier soit reli au domaine dentre du second. Un exemple est la connexion dune souris
un pointeur (dispositif logiciel).
Lespace de conception de Card, illustr sur la gure 2.20 page ci-contre, met en vidence les principales proprits de chaque dispositif dentre ainsi que sa dcomposition en dispositifs atomiques.
Loprateur de manipulation se retrouve en abscisse (linaire/angulaire et direction de laxe) et en ordonne (position absolue ou relative, force absolue ou relative). Sur ce schma ont t placs un grand
nombre de dispositifs dentre, dont ceux auparavant dcrits par Foley et par Buxton.
2.4.3
Conclusion
Si les normes GKS et PHIGS sont longtemps restes une rfrence dans le domaine de linformatique graphique, leur modle dentre sest trs rapidement rvl dpass par les interfaces modernes
[M YERS 90]. Le modle des dispositifs logiques est adapt linteraction modale avec les applications
graphiques type CAO de lpoque, mais non la manipulation directe moderne. Les tches dinteraction de Foley sont galement ad-hoc.
Trs tt pourtant, les taxinomies de dispositifs de Buxton et de Card ont mis en vidence le caractre ad-hoc des modles logiques. Ces taxinomies, extrmement intressantes du point de vue
thorique et pdagogique, et abondamment rfrences dans la littrature scientique, ne sont malheureusement pas de bons modles dimplmentation et leurs applications logicielles sont pratiquement
inexistantes.
Les standards GKS et PHIGS, focaliss sur laspect graphique, nont pas volu du point de
vue des entres. Aujourdhui, ils ont t remplacs par des standards industriels de facto comme
OpenGL [C ARSON 97], qui sont ddis laspect graphique et ne traitent pas le problme de linteraction en entre.
54
F IG . 2.20 Lespace de conception de Card [C ARD et al. 91].
55
2.5 Les modles dinteraction

Un modle dinteraction est un ensemble de principes, de rgles et de proprits qui guident
la conception dune interface [B EAUDOUIN -L AFON 97]. Un modle dinteraction dtaille tous les aspects dun paradigme dinteraction du point de vue utilisateur et inspire des principes architecturaux
exploitables par le dveloppeur. Dans cette section, nous rappelons les principes gnraux du modle
de la manipulation directe, qui a en partie inspir les interfaces graphiques modernes que nous utilisons actuellement. Puis nous dcrivons une extension et une gnralisation de ce modle, linteraction
instrumentale, qui jette les bases des applications post-WIMP.
2.5.1
La manipulation directe
La transition entre les interfaces ligne de commande du type UNIX et les interfaces graphiques
actuelles a t initie ds les annes 60 avec des applications de dmonstration comme Sketchpad
et Pygmalion, pour nalement se concrtiser vers les annes 80 avec le systme Xerox Star qui intgre toutes les caractristiques de nos interfaces actuelles [M YERS 98 A]. Peu aprs, Ben Shneiderman [S HNEIDERMAN 83] invente le terme de manipulation directe et formule le modle dinteraction
que nous dcrivons ici.
La manipulation directe [S HNEIDERMAN 83, S HNEIDERMAN 98] dcrit des systmes interactifs ayant
les caractristiques suivantes :
1. La visibilit des objets dintrt et des actions possibles,
2. Des actions rapides, rversibles, incrmentales,
3. Le remplacement de la syntaxe complexe des langages de commande par la manipulation directe
de lobjet dintrt.
La manipulation directe repose sur une mtaphore du monde rel, dans lequel nous manipulons
directement les objets. Shneiderman dcrit quelques exemples dinterfaces exploitant la manipulation
directe, dont les traitements de texte WYSIWYG du type Microsoft Word, les tableurs graphiques,
les jeux vido, les logiciels de CAO [S HNEIDERMAN 98]. Les avantages de ce paradigme sont nombreux : apprentissage rapide et productivit accrue, messages derreurs moins ncessaires, rduction
de lanxit due un systme comprhensible et des actions rversibles.
Hutchins et al. [H UTCHINS et al. 86] clarient le concept de manipulation directe du point de vue
cognitif, et voquent un sentiment dengagement dans un monde dobjets plutt que limpression
de communiquer par un intermdiaire . Ils dnissent une notion de directitude mesure par
le foss dexcution et le foss dvaluation. Le premier rfre la distance entre ce que lide que
lutilisateur se fait de la tche et la faon dont elle est reprsente par le systme. Le second voque
la distance entre le comportement du systme et les objectifs de lutilisateur. Lobjectif principal de la
manipulation directe est de combler ces fosss.
Nos interfaces actuelles sinspirent des principes de la manipulation directe. Elles reposent cependant sur un paradigme qui nest quune version appauvrie de la manipulation directe (voir la section 1.1.1 page 3). Les widgets qui composent les interfaces WIMP, en particulier, sont des objets directement manipulables mais qui ne servent que dintermdiaires aux rels objets dintrt (gure 2.21
page ci-contre).
56
2.5. LES MODLES DINTERACTION
F IG . 2.21 gauche : rglage de lheure dans Windows XP avec des techniques WIMP. droite : manipulation directe de lheure dans SpiraClock [D RAGICEVIC & H UOT 02].
2.5.2
Linteraction instrumentale
Le paradigme dinteraction instrumentale [B EAUDOUIN -L AFON 97, B EAUDOUIN -L AFON 00] sinspire de
notre exprience interactive avec le monde physique, qui est gouverne par lutilisation doutils. Des
outils comme un pinceau ou une perceuse, ou mme un interrupteur, sont des objets intermdiaires
(instruments) que nous utilisons pour agir sur dautres objets (objets dintrt).
Dans cette section, nous prsentons le modle de linteraction instrumentale tel quil a t dcrit
par [B EAUDOUIN -L AFON 97].
Instruments dinteraction
Les donnes manipules par une application peuvent tre reprsentes par des entits appeles
objets du domaine, eux-mmes dcrits par un ensemble dattributs : ainsi, une sphre dans un modeleur 3D est dnie par des attributs simples comme sa position et sa taille, et dautres plus complexes
comme sa couleur et sa texture.
Linteraction avec une application a pour nalit la manipulation des objets du domaine. Cette
manipulation peut prendre deux formes : soit lutilisateur agit sur les attributs de ces objets, soit il
manipule ces objets comme un tout, par exemple en les copiant ou en les effaant.
Les manipulations seffectuent par lintermdiaire dinstruments dinteraction, qui sont les mdiateurs entre lutilisateur et les objets du domaine. Une barre de dlement est un exemple dinstrument
qui opre sur un document (lobjet du domaine) en modiant sa partie visible (un attribut).
Les instruments sparent linteraction en deux couches, une du ct utilisateur, et une du ct
application (gure 2.22 page suivante). Les communications du ct utilisateur consistent en actions
physiques de lutilisateur et ractions de linstrument. Les messages du ct application consistent
en commandes envoyes lobjet et rponses de celui-ci, que linstrument peut transformer en retour
vers lutilisateur.
Le comportement typique dun instrument est le suivant :
Lutilisateur agit sur linstrument, qui traduit ses actions en commandes qui altrent les objets
du domaine. Exemple : lutilisateur clique sur un des boutons chs de la barre de dlement,
ce qui a pour effet denvoyer une commande de dlement au document (cette commande est
57
action
commande
rponse
raction
retour
Utilisateur
Instrument
physique logique
Objet du
Domaine
F IG . 2.22 Schma dun instrument.
rmise intervalles tant que le bouton reste appuy).

Linstrument produit des ractions qui permettent lutilisateur de contrler son action sur
linstrument. Exemple : le bouton de la barre de dlement senfonce ds que lutilisateur clique
dessus.
Linstrument produit galement un retour donnant une ide de leffet des commandes sur les
objets du domaine. Exemple : la barre de dlement met jour la position du pouce, indiquant
la nouvelle position dans le document. Un deuxime niveau de retour rafche la partie visible
du document courant.
Activation spatiale et temporelle

Un instrument comporte une partie physique (le dispositif dentre) et une partie logique (sa reprsentation logicielle et visuelle) (voir gure 2.22). Dans la grande majorit des applications interactives, de nombreux instruments logiques se partagent le mme dispositif physique. Les ambiguts
sont alors rsolues par des mcanismes dactivation (galement appels mcanismes de multiplexage
[B UXTON 86 B]. Un instrument est dit activ lorsquil est associ un dispositif physique pour tre
contrl par lutilisateur.
Les mcanismes dactivation sont de deux sortes : lactivation spatiale est lie la prsence dun
pointeur lintrieur dune zone visuelle, alors que lactivation temporelle est lie des changements
de mode demandant des actions explicites (par exemple, le fait de cliquer sur un bouton dans une barre
doutils). Lactivation spatiale est plus directe et plus rapide que lactivation temporelle. Cependant,
lactivation spatiale requiert des instruments visibles en permanence lcran (widgets) qui occupent
de la place.
Dans tous les cas, les cots dactivation sont non ngligeables lorsque le nombre dinstruments
devient important. Ces cots peuvent tre rduits par des associations implicites entre dispositifs et
instruments, comme par exemple lassociation entre la molette de la souris et la barre de dlement.
Lutilisation dassociations implicites passe par la multiplication des dispositifs physiques.
Notons enn que la manipulation dun instrument nimplique pas seulement son association avec
un dispositif physique, mais galement son association avec un objet du domaine. Lentit qui, un
instant donn, fait lobjet dune manipulation instrumentale est appel objet dintrt ; cest lobjet
sur lequel lutilisateur focalise temporairement son attention. Cette notion fondamentale de la manipulation directe est galement mise en avant dans la manipulation instrumentale.
58
2.5. LES MODLES DINTERACTION

Mta-instruments
Dans le monde rel, il est courant que lattention se focalise temporairement sur linstrument luimme : un crayon peut par exemple tre afft par un taille-crayon, qui son tour peut tre resserr
par un tournevis. De faon analogue, un instrument peut tre vu comme un objet du domaine, qui peut
tre contrl par un autre instrument.
Dans les applications interactives, les menus et les barres doutils sont des exemples de mtainstruments qui servent activer dautres instruments. Les mta-instruments peuvent galement savrer utiles pour organiser des instruments dans un espace de travail ou spcialiser des instruments pour
des tches spciques.
La rication
La rication est le processus qui consiste transformer un concept en objet. Lutilisation de
mta-instruments est un exemple de rication dinstruments. Les styles, qui sont des attributs partags entre plusieurs objets, peuvent galement faire lobjet dune rication et tre manipuls par des
instruments. En multipliant le nombre et la nature des objets manipulables dans une application, la
rication ouvre la voie de nouvelles possibilits dinteraction, tout en conservant un style uniforme
et cohrent calqu sur la manipulation instrumentale.
Proprits des instruments

Le degr dindirection, le degr dintgration et le degr de compatibilit sont trois proprits
essentielles des instruments. Ces proprits permettent comparer entre eux plusieurs instruments effectuant des tches similaires. Elles ont galement servi de base une taxinomie des techniques dinteraction WIMP et post-WIMP.
Le degr dindirection traduit le dcalage spatial et temporel entre un instrument et lobjet sur
lequel il agit. Certains instruments comme les poignes de redimensionnement1 sont placs
directement sur lobjet dintrt. Dautres, comme les botes de dialogue, peuvent se trouver
loigns de lobjet quelles manipulent. Le systme de validation des botes de dialogue ajoute
galement au dcalage spatial un dcalage temporel.
Le degr dintgration est le rapport entre le nombre de dimensions physiques et le nombre de
dimensions logiques qui sont manipules lors de lutilisation de linstrument. Pour une barre
de dlement (1D) manipule par une souris (2D), il est de 1/2. Pour un objet 3D manipul
par le mme dispositif, il est de 3/2. Cette proprit est directement lie la notion de tches
intgrales introduite par Robert Jacob [JACOB et al. 94].
Le degr de compatibilit traduit la similarit entre les manipulations effectues sur linstrument
et leurs effets sur lobjet dintrt. titre dexemple, la barre de dlement possde un degr
de compatibilit plus faible que le glisser-dposer, car le dlement du document est invers
par rapport la manipulation.
1 Il sagit habituellement de neuf carrs pleins disposs autour de lobjet qui apparaissent lorsque cet objet est slectionn,
an de permettre de le redimensionner.
59
2.5.3
Conclusion
Le modle de la manipulation directe marque une transition importante entre les interfaces archaques lignes de commande et les interfaces graphiques actuelles, o les objets sont reprsents
lcran et manipuls avec une souris. Ce modle est cependant trop abstrait pour garantir des interfaces o les fosss dexcution et dvaluation ont t rduits leur strict minimum. La preuve en est
de nos interfaces actuelles, o les objets dintrt sont presque toujours manipuls de faon indirecte.
Le modle de linteraction instrumentale afne le modle de la manipulation directe en intgrant
les paradigmes Post-WIMP qui ont t rgulirement proposs pour corriger les faiblesses de nos interfaces modernes. Aussi, la mtaphore prcdente qui dcrit la manipulation dobjets de notre vie
quotidienne a t tendue lutilisation doutils (instruments) comme objets mdiateurs. Tout en
proposant lexploration de nouveaux paradigmes comme les mta-instruments (des instruments qui
agissent sur dautres instruments), ce modle guide la conception dinterfaces rellement directes.
Ainsi, les trois proprits essentielles que sont le degr dindirection, le degr dintgration et le degr de compatibilit expliquent notamment pourquoi les widgets sont des instruments peu efcaces et
montrent lintrt de multiplier les dispositifs physiques et de prserver au maximum les compatibilits entre le dispositif et la tche.
2.6 Les outils de dveloppement

Une application interactive a essentiellement besoin danimer des formes gomtriques lcran et
de lire les donnes en provenance des dispositifs dentre. Le dveloppement dune application complte avec des librairies graphiques et des librairies dentre bas-niveau constitue cependant un travail
titanesque. Cest pourquoi les outils de type Xlib ont rapidement cd la place des librairies de plus
haut niveau comme la X Toolkit [M C C ORMACK & A SENTE 88]. Ces botes outils graphiques ou
botes outils dinteraction proposent des jeux dobjets interactifs rutilisables (widgets) et un mcanisme de gestion des entres base sur la notion dvnements. La plupart du temps, limplmentation
de la partie interactive dune application se rsume alors linstanciation et au positionnement dclaratif de widgets, dont la manipulation est gre automatiquement par des mcanismes daiguillage
vnementiel et des comportements prdnis au sein des widgets. Ces mcanismes seront dcrits plus
en dtail par la suite.
Si les apprciations divergent quant la facilit dutilisation des botes outils graphiques, tous
les dveloppeurs saccordent dire quelles sont difciles tendre (du moins, ceux qui sy sont
essay) [ACCOT et al. 98]. Cette difcult est encore bien plus marque du point de vue de linteraction
en entre. En effet, dles au modle de linteraction standard, les botes outils sont toutes cbles
pour une utilisation exclusive et strotype de la souris et du clavier (voir la section 1.1.1 page 3
pour une dnition de linteraction standard et la section 1.4.1 page 29 pour une discussion sur ses
faiblesses). Les principales difcults proviennent de ce quelles prennent en charge un ensemble
limit et statique de types dvnements (souris et clavier), emploient des mcanismes daiguillage
complexes dont larchitecture est oue, et entremlent les aspects graphiques et comportementaux.
Depuis les premires botes outils, de grands progrs ont t faits du point de vue graphique :
des abstractions simplient grandement la gestion de lafchage et des effets visuels toujours plus
sophistiqus sont pris en compte. Ces avances ont une certaine inuence sur linteraction en entre :
60
2.6. LES OUTILS DE DVELOPPEMENT

le dessin structur2 permet dimplmenter plus facilement des techniques de manipulation directe
[B EAUDOUIN -L AFON et al. 90] et la prise en charge deffets visuels avancs tels que la transparence ou les
dformations encouragent linnovation dans les techniques dinteraction [ROUSSEL 02]. Malgr tout,
les paradigmes dinteraction Post-WIMP avancs ncessitent pour tre dcrits un remaniement non
ngligeable voire complet du modle standard de gestion des entres. Cest encore plus le cas lorsque
lon dsire obtenir une certaine congurabilit de linteraction. Or mme les outils modernes comme
Java Swing [E CKSTEIN & L OY 02] reposent sur un modle vieux de plusieurs dcennies.
Dans cette section, nous donnons un large aperu des botes outils qui remettent en cause de
faon signicative le modle dentre rigide conventionnel. Nous commenons par dcrire les outils qui modlisent les paradigmes dinteraction standard de faon claire et extensible, et que nous
nommons botes outils WIMP avances. Puis, nous dcrivons les outils qui reposent sur des architectures ddies dautres paradigmes dinteraction, et que nous nommons botes outils Post-WIMP
spcialises.
2.6.1
Les botes outils WIMP avances
Lobjectif des botes outils WIMP avances est de fournir de bons modles et de bons outils permettant dune part de faciliter la construction dinterfaces WIMP ou manipulation directe conventionnelles, dautre part de favoriser la description de techniques plus spciques ou moins conventionnelles. Comme preuve dextensibilit, ces botes outils prennent en charge un ensemble minimal
de techniques dinteraction non-standard.
Les deux contributions les plus importantes dans ce domaine sont les botes outils Surbactic [H UDSON & S MITH 96 A] et Garnet/Amulet [M YERS 90, M YERS et al. 97]. Nous les prsentons ici, et dtaillons les mcanismes quelles emploient pour la gestion des entres. Nous analysons ensuite leurs
apports respectifs, ainsi que leurs limites.
Subarctic Toolkit
Subarctic Toolkit [H UDSON & S MITH 96 A] est une bote outils Java qui prend en charge des effets
visuels avancs et les animations [H UDSON & S TASKO 93], et possde un moteur de contraintes3 pour
la gestion de lorganisation spatiale des widgets [H UDSON & S MITH 96 B]. Le modle dentre de cette
bote outils a t introduit dans Artkit [T YSON R. et al. 90], le prdcesseur de Subarctic dvelopp en
C++ . Lobjectif principal de ce modle est de dcrire les mcanismes daiguillage employs par les
botes outils traditionnelles de faon claire et extensible, pour pouvoir y intgrer ensuite de nouveaux
mcanismes. En plus des interactions habituelles, Subarctic prend en charge trois paradigmes dinteraction non conventionnels, savoir linteraction gestuelle [T YSON R. et al. 90], les champs de gravit4
[T YSON R. et al. 90, H UDSON 90], et les lentilles smantiques5 [H UDSON et al. 97].
2 Dans le modle de dessin structur, les appels des routines graphiques sont remplacs par la manipulation dune liste
dafchage dont le rendu est pris en charge par le systme.
3 Les paradigmes de programmation par contraintes et de ot de donnes, auxquels nous ferons parfois rfrence dans
cette partie, seront dcrits plus en dtail dans la partie sur les langages visuels (section 2.7.1 page 79)
4 galement appele snap-dragging, il sagit dune technique de cliquer-glisser dans laquelle lobjet manipul est attir
vers des positions-cls [B IER & S TONE 86]. Elle permet la fois de faciliter la manipulation et de prvenir les erreurs.
5 Les lentilles smantiques sont des formes ottantes qui se comportent comme des ltres, qui effectuent des transformations graphiques sophistiques (loupe, par exemple) ou exposent des reprsentations graphiques alternatives. Les ltres de
61

Dans toute bote outils, laiguillage des entres consiste distribuer les vnements dentre
aux objets appropris dans larbre des widgets. La faon dont Subarctic distribue ces entres est
synthtise sur la gure 2.23. Les rectangles reprsentent des objets (au sens programmation par
objets) qui sont de type Politique dAiguillage ou Agent dAiguillage.
F IG . 2.23 La gestion des entres dans Subarctic [H UDSON & S MITH 96 A].
Les Politiques dAiguillage (Dispatch Policies) : Les politiques daiguillage dcrivent les principales stratgies de distribution des vnements. Ces objets sont disposs horizontalement en
haut de la gure 2.23, et nous les numrons de droite gauche :
lAiguillage Positionnel (Positional) consiste envoyer les vnements positionnels aux
widgets qui se trouvent sous le pointeur, dans lordre inverse de leur afchage.
lAiguillage par Focus (Focus) consiste transmettre certains vnements un widget donn,
indpendamment de la position du pointeur. Les vnements en provenance du clavier sont
envoys au widget qui dtient le focus clavier. Les vnements de type drag sont transmis au
widget sur lequel a t initi le cliquer-glisser.
lAiguillage de Contrle (Monitor Focus) consiste envoyer les vnements bruts aux objets
intresss, des ns de dbogage, par exemple.
Ces trois politiques sont listes sur la gure dans leur ordre de priorit dcroissante. Chaque
vnement passe dune politique lautre jusqu ce quil trouve un destinataire intress, qui
consomme alors lvnement. Dans laiguillage de contrle cependant, les destinataires interprtent mais ne consomment pas les vnements.
Les Agents dAiguillage (Dispatch Agents) : Chaque politique daiguillage est constitue dun ensemble dagents daiguillage agencs verticalement sur la gure. Un agent daiguillage implmente un aspect donn de la stratgie daiguillage, et se charge de convertir les vnements
bas-niveau en vnements plus haut-niveau avant de tenter de les transmettre aux widgets. Lensemble des vnements synthtiques quun agent est susceptible de produire constitue un protocole dentre, et les widgets intresss par ces vnements implmentent ce protocole dentre
(caractris par une interface dans le paradigme de la programmation par objets). Voici quelques
exemples dagents :
Press : Cet agent ltre simplement les vnements souris de type press et release, quil
transmet aux widgets intresss qui se trouvent sous le pointeur.
dbogage [H UDSON et al. 97], qui afchent des informations sur les widgets, en sont un exemple. Nous ninsisterons pas sur
ce paradigme, qui constitue davantage une technique de visualisation que dinteraction.
62

Click et Double-Click : partir des mmes vnements press et release, ces agents produisent et transmettent des vnements synthtiques de type click ou double-click.
Move Drag : Cet agent produit des vnements de type drag_start, drag_feedback et drag_end
partir dvnements souris de type press, move et release. Comme dans la plupart des
agents, la production dvnements synthtiques y est rgie par un automate tats (se rfrer la gure 2.10 page 45 pour celui-ci).
Chaque vnement reu par une politique daiguillage est successivement transmis chacun de
ses agents selon leur ordre de priorit, puis la politique suivante si lvnement na toujours
pas t consomm.
Le gestionnaire dentres de Subarctic peut tre tendu an de prendre en charge dautres techniques dinteraction. De nouveaux agents ou politiques daiguillage peuvent tre implments, ventuellement en drivant un objet existant, puis insrs lendroit voulu dans la liste de priorit. Par
exemple, une bote de dialogue modale peut tre implmente par une politique hybride focus/positionnel
qui transmet les vnements de faon positionnelle aux enfants dun widget qui dtient le focus. Linteraction gestuelle et les champs de gravit ont tous deux t implments par des agents daiguillage
de type focus.
Pour le premier, un agent Segmentation a t driv de lagent Inking Drag, lui-mme driv de
lagent Move Drag auquel il ajoutait un retour graphique de type trace. Cet agent transforme les vnements souris en sries de segments pour les transmettre un moteur de reconnaissance. Des types
particuliers dobjets, les zones sensibles, ont t crs pour servir dintermdiaires entre lagent de segmentation et le widget qui possde le focus gestuel. Il sagit de widgets invisibles qui encapsulent une
zone gestuelle et le vocabulaire gestuel associ. Quant la seconde technique, elle emploie un agent
Snap qui tend lagent Move Drag en ajoutant son protocole dentre les vnements snap_feedback
et unsnap_feedback. Ces vnements notient le widget manipul de son passage proximit dun
site actif smantiquement valide. Les sites actifs sont des points qui agissent comme des champs de
gravit et qui sont dclars par les widgets cibles. Il peut sagir par exemple de cibles de connexion
dans un diteur de diagrammes.
Garnet/Amulet
Lobjectif principal de la bote outils Garnet [M YERS 90] et de son successeur Amulet [M YERS et al. 97]
est de simplier le dveloppement dapplications hautement interactives en sparant du noyau applicatif les principaux aspects de linteraction (principalement, la gestion de la prsentation, des entres
et du annuler/refaire), et en fournissant des outils et des abstractions adapts chacun de ces aspects.
Garnet est implment dans le langage CommonLisp, quil tend avec un modle objet prototypes
et un paradigme de programmation par contraintes ; Amulet repose sur une infrastructure C++ , quil
instrumentalise de la mme manire.
Le principe des interacteurs [M YERS 90] introduit dans Garnet offre un modle de haut-niveau pour
la gestion des entres. Ce modle part de lobservation que dans les botes outils traditionnelles, la
programmation du comportement dun widget, cest--dire sa raction aux vnements souris et clavier, est pnible et rptitive : il est notamment frquent de devoir dcrire plusieurs fois les mmes
mcanismes. Dans Garnet, ces comportements sont dcrits indpendamment des aspects graphiques,
encapsuls dans des objets rutilisables appels interacteurs. Suivant une taxonomie trs semblable
celle de Foley [F OLEY et al. 84], six types dinteracteurs sont fournis pour couvrir la plupart des comportements couramment observs dans les interfaces graphiques :
63

1. Menu : Linteracteur Menu couvre les techniques de slection employes dans les menus ou les
boutons radio. Il dcrit galement les comportements des boutons.
2. Move-Grow : Linteracteur Move-Grow dcrit les manipulations gomtriques employes dans
la manipulation directe, savoir la translation et le redimensionnement. Il dcrit galement le
cliquer-glisser avec des widgets de type barre de dlement.
3. New-Point : Linteracteur New-Point couvre les techniques de cration dobjets gomtriques
dans les diteurs graphiques, consistant spcier des points-cls.
4. Angle : Linteracteur Angle dcrit les rotations dobjets tels que les curseurs de jauges circulaires ou les aiguilles dhorloges analogiques.
5. Text : Linteracteur Text dcrit les principales techniques de saisie employes dans les widgets
textuels.
6. Trace : Linteracteur Trace dcrit des techniques faisant usage de sries dvnements positionnels, tels que le dessin main leve. Rebaptis Gesture dans Amulet, cet interacteur prend
maintenant en charge les techniques dinteraction gestuelle.
Pour rendre un objet graphique sensible aux vnements dentre, le programmeur a simplement
besoin dinstancier linteracteur appropri avant de lassocier lobjet. Linteracteur dcrit la partie
C du modle MVC (voir section 2.2.2 page 40), et vient sintercaler entre les vnements de basniveau de type souris et clavier, quil interprte, et lobjet graphique, quil manipule travers un
protocole. Un seul interacteur peut oprer sur plusieurs objets graphiques, par exemple lensemble des
objets manipulables dans une zone ddition graphique. Certains objets graphiques peuvent galement
comporter plusieurs interacteurs : par exemple, une barre de dlement emploie un interacteur de type
Menu pour ses deux boutons et un interacteur de type Move-Grow pour le pouce.
Un interacteur prend en charge tous les aspects de la technique dinteraction quil dcrit, y compris
les feedbacks transitoires comme la cration et lanimation dun objet fantme dans une technique de
cliquer-glisser. titre dexemple, linteracteur Gesture produit un feedback de type trace et comprend
un classicateur paramtrable qui interprte des sries dvnements souris en donnes textuelles ou
en commandes. En outre, chaque interacteur connat plusieurs variantes dune mme technique dinteraction, et peut tre spcialis par paramtrage. Voici, titre dexemple, les principaux paramtres
partags par tous les interacteurs :
vnements dclencheurs : Ces paramtres dnissent les vnements dentre qui dclenchent,
terminent et annulent linteracteur : par exemple, les transitions dun bouton de la souris ou du
clavier.
Objets dclencheurs : Ces paramtres dterminent au-dessus de quel(s) objet(s) graphique(s)
doit se trouver le pointeur pour que linteracteur dmarre, et sur quel objet ce dernier opre :
par exemple, un clic sur le fond dune barre de dlement dplace le pouce dun cran. Il permet
galement de dnir des cibles illgales.
Discret/continu : Ce paramtre spcie si linteracteur est uniquement activ au dbut et la n
de linteraction, ou doit prendre en compte les dplacements du pointeur entre les deux.
Comportement en sortie : Des paramtres permettent de spcier ce qui se passe lorsque
durant une interaction continue, le pointeur sort dune rgion active. Linteraction peut par
exemple continuer, tre annule (lorsque le pointeur sort dun menu) ou la dernire valeur peut
tre conserve (lorsquil sort dune barre de dlement).
Feedback : Ces paramtres spcient les objets utiliser pour le feedback durant linteraction
ou la n de celle-ci. Par exemple, durant un cliquer-glisser lobjet-lui mme est dplac, ou
64

bien un objet fantme est cr. la n dune interaction de type slection, llment slectionn
dun menu peut tre indiqu par un contour rectangulaire ou un rectangle dinversion vido.
Les paramtres autorisent la plupart du temps des types de valeurs sophistiqus comme des
groupes dvnements : par exemple, la valeur :anykeyboard :except #\control-G affecte au
paramtre :stop-event terminera linteraction lorsquune touche est appuye sauf sil sagit de la
combinaison control+G. Des formules (ou contraintes) peuvent galement tre spcies en tant que
valeur6 . titre dexemple, la technique dinteraction consistant dplacer les objets du bouton gauche
de la souris et les redimensionner du bouton droit pourra tre dcrite ainsi [M YERS 90] :
(Create-instance move-or-grower Move-Grow-Interactor
(:start-event (:leftdown :rightdown)) ; Dmarrer avec le bouton gauche ou droit.
(:start-where (:element-of all-objs-aggregate)) ; Dmarrer sur tout objet du
; conteneur graphique.
(:grow-p (formula (eq :rightdown (gvl :start-char)))) ; Redimensionner si lvnement
; initial est le bouton gauche,
; sinon dplacer.
(:window mywindow))
Les mcanismes daiguillage vnementiel et les modes sont essentiellement grs travers le
paramtre Active, qui associ une formule permet lactivation ou la dsactivation conditionnelle
dun interacteur, et travers le paramtre Priority, qui permet de dnir des niveaux de priorit
lorsque plusieurs interacteurs sont candidats au mme vnement.
Tous les interacteurs sont crits autour du mme automate tats, reproduit sur la gure 2.24
page suivante. Cet automate suppose que toute interaction peut tre dmarre, arrte, termine ou
suspendue. Implmenter un nouvel interacteur revient associer une action chaque transition dans
cet automate tats.
De Lapidary Gamut
Une myriade doutils visuels de construction dinterface ont t dvelopps comme complments
Garnet et Amulet, et la plupart dentre eux offrent une interface graphique aux interacteurs. Dans
Lapidary [M YERS 90, Z ANDEN & M YERS 95], loutil de construction dinterfaces livr avec Garnet, les
interacteurs peuvent tre paramtrs travers des botes de dialogue. Le modle contraintes de
Garnet permet ainsi dassocier la programmation textuelle dclarative la programmation visuelle.
Une partie des comportements, notamment certains types de feedback, peut tre directement dcrite graphiquement dans Lapidary. Par exemple, un feedback de type case cocher sera dessine et
lie par des contraintes un lment de menu prsent lcran, et ces contraintes sont gnralises automatiquement toute cible potentielle de linteraction. Ce type de technique combinant manipulation
graphique et infrence est connue sous le nom de programmation par dmonstration [M YERS 92].
Les techniques de programmation par dmonstration employes dans Lapidary seront reprises et
tendues par la suite, dans Tourmaline [W ERTH & M YERS 93], Marquise [M YERS et al. 93], Pursuit [M ODUGNO 93],
6 Les
formules peuvent galement effectuer des actions par des effets de bord, bien quAmulet fournisse galement des
abstractions permettant dencapsuler des commandes dans des objets.
65
F IG . 2.24 La machine tats dcrivant le comportement gnrique dun interacteur Garnet. Chaque transition
est dclenche par un vnement, qui peut tre dans certains cas spci par paramtrage, et dclenche une
action, qui peut tre dcrite par programmation.
Silk [L ANDAY & M YERS 95], Topaz [M YERS 98 B], Turquoise, et enn Gamut [M C DANIEL & M YERS 98]. Lobjectif de ce dernier est de construire des jeux interactifs complets uniquement par dmonstration,
cest--dire en donnant des exemples des comportements dsirs. Gamut se distingue des autres outils par un moteur dinfrence extrmement sophistiqu, qui repose sur des techniques dintelligence
articielle. Ces techniques sont toutefois trs dpendantes du domaine.
Discussion sur les apports et les limites de Subarctic et Garnet/Amulet

Ces deux botes outils WIMP avances procdent dapproches diffrentes, mais chacune apporte
des lments essentiels dans la modlisation de linteraction en entre. Lapproche de Garnet est intressante car elle se veut la plus dle possible au modle MVC. Dans limplmentation originale de ce
modle en SmallTalk [K RASNER & P OPE 88], la vue et le contrleur taient hautement dpendants lun de
lautre, et le contrleur devait tre rimplment chaque fois que la vue avait chang et vice-versa.
Par la suite, la plupart des botes outils sinspirant de ce modle, comme Andrew [PALAY et al. 88],
Interviews [L INTON et al. 89] ou Swing [F OWLER 99] ont regroup la vue et le contrleur dans un mme
objet nomm Vue, UI ou Look&Feel. Dans Garnet, un protocole de communication assure une certaine indpendance entre la vue et le contrleur, mme si cette indpendance est restreinte par le fait
que chaque type dinteracteur dnit son propre protocole. Le grand mrite du modle de Subarctic
est quant--lui davoir explicit les mcanismes daiguillage standard qui, dans les botes outils traditionnelles comme Swing, taient implments de faon obscure, et par consquent trs difciles
comprendre et tendre.
Si Subarctic na pas pour objectif de rendre linteraction personnalisable, le paramtrage est un
aspect important de Garnet, et garantit une certaine congurabilit de linteraction en entre. Associ
au paradigme de programmation par contraintes, il constitue de plus un outil extrmement puissant. En
66

outre, il se prte relativement bien un paradigme visuel de construction dinterfaces. Les paramtres
des interacteurs de Garnet sont assez nombreux pour couvrir la plupart des techniques existantes.
Cependant, lorsque le nombre de paramtres est excessif, le comportement dun objet peut devenir
difcile comprendre et congurer. Cest un peu le cas de certains interacteurs tout faire
de Garnet, comme le Menu ou le Move-Grow. Cela explique peut-tre que les outils de visuels de
Garnet/Amulet se soient orients vers des techniques de programmation par dmonstration.
Malheureusement, ces outils restent modrment ouverts lensemble des paradigmes Post-WIMP.
Subarctic prend en charge un ensemble trs restreint de techniques post-WIMP et Garnet se limite
linteraction gestuelle simple. Or la faiblesse majeure de lapproche de Garnet, en particulier, est le
caractre trs ad-hoc de son modle dentre. Ses six types dinteracteurs se sont certes rvls sufsants dans les nombreux projets o ils ont t employs, mais ne sont pas adapts de nouveaux types
dentre comme la parole [M YERS et al. 97], et nencouragent pas la description de techniques dinteraction novatrices. Certains outils de base fournis pour le dveloppement de nouveaux interacteurs sont
galement ad-hoc : par exemple, lautomate tats ncessite dtre tendu pour grer des techniques
comme le rollover ou lajustement7 .
Dans Subarctic, lajout de nouvelles techniques dinteraction, bien que facilit, nest pas non plus
gratuit. La plupart des nouveaux paradigmes dinteraction ne sinsrent pas naturellement dans larchitecture existante, et ncessitent chacun une extension importante du modle (Multimodal Subarctic,
dcrit dans la section 2.6.2 page suivante, en est une). Cela reste vrai pour des modications mineures : par exemple, dans Artkit cest la position initiale du geste qui dtermine sa cible, et la prise
en compte dautres zones actives comme le centre du rectangle englobant ncessiterait lajout dun
nouveau type de politique daiguillage [T YSON R. et al. 90]. En outre, des problmes de conit qui interdisent par exemple labonnement simultan au clic et au double-clic ncessitent pour tre rsolus
limplmentation de nouveaux agents de mdiation [T YSON R. et al. 90].
Mais laspect dispositifs dentre reste le facteur le plus limitant pour laccs aux paradigmes
Post-WIMP : ni Subarctic ni Garnet ne grent les dispositifs multiples et leurs modles restent conus
pour les dispositifs standard. Peut-tre par souci de portabilit, Subarctic repose exclusivement sur
les mcanismes dAWT et Swing, auxquels il dlgue une partie de son modle : ainsi, les vnements natifs AWT sont passs en paramtre dans tous les vnements Subarctic, an notamment que
les widgets puissent accder aux touches modicatrices. En outre, le fait que les vnements basniveau traits par Subarctic et Garnet soient en ralit des vnements gnriques standard (produits
par Swing pour le premier et par X pour le second) ne permet pas dexploiter au mieux les capacits
des dispositifs mme standard.
2.6.2
Les botes outils Post-WIMP spcialises
Contrairement aux botes outils WIMP avances, les botes outils Post-WIMP sont conues
ds le dpart pour dcrire des paradigmes dinteraction non-conventionnels. Bien que certaines dentre
elles soient extensibles, elles reposent en gnral sur un paradigme ou un modle dinteraction spcique.
Lapproche de Multimodal Subarctic [M ANKOFF et al. 00], tout en tant relativement gnrale, intgre dans le mcanisme vnementiel la notion dambigut, qui est propre des modalits parti7 Le
rollover consiste produire un effet graphique lorsque le pointeur entre dans le widget. Lajustement, utilis dans
certaines barres de dlement, est un tat o le modle nest pas mis jour pendant linteraction.
67

culires comme la parole ou le geste. Nous dcrivons dans un premier temps cette bote outils qui
constitue une contribution importante dans le domaine.
Les approches que nous dcrivons par la suite sont plus spciques et concernent, dans lordre,
linteraction gestuelle, linteraction multi-pointeurs, les outils semi-transparents, linteraction 3D et
les nouveaux paradigmes comme la sensibilit au contexte et les interfaces tangibles. Pour complter,
nous tudierons la question de laccessibilit.
Linteraction ambigu avec Multimodal Subarctic
Depuis Artkit, les efforts sur la bote outils Subarctic ont essentiellement port sur laspect graphique [H UDSON & S MITH 96 B]. Rcemment cependant, Subarctic a t tendue pour prendre en compte
de nouvelles modalits comme la parole et le geste [M ANKOFF et al. 00]. Il sagit dune version non
encore distribue qui se distingue notablement de la version courante, et que nous baptiserons ici
Multimodal Subarctic. Le modle de gestion des entres y a t entirement remani dans le but de
grer les ambiguts et les techniques de mdiation, aspects essentiels de linteraction multimodale.
Nous exposons brivement ses principes.
F IG . 2.25 Une stratgie de mdiation de type n-best list applique une application de dicte vocale et une
application de prototypage gestuel dinterfaces [M ANKOFF et al. 00].
Avec des modalits telles que la parole ou le geste, des ambiguts peuvent survenir lors de la
conversion dun vnement bas-niveau en un vnement plus haut-niveau. Par exemple, une trace
pourra tre interprtable comme un cercle ou comme un rectangle, avec des indices de conance
comparables. Dans les applications existantes, lambigut est la plupart du temps rsolue automatiquement en optant pour la probabilit la plus forte. Les techniques les plus efcaces consistent cependant faire intervenir lutilisateur, par exemple en lui proposant une liste de choix (gure 2.25), ou en
lui demandant de rpter. Ce sont ces techniques, appeles mdiations, que Multimodal Subarctic se
propose de prendre en charge.
Dans la situation dambigut dcrite prcdemment, lvnement cercle et lvnement rectangle
sont tous deux gnrs par Multimodal Subarctic, puis propags et interprts comme nimporte quel
vnement. Les vnements ambigus tant provisoires, la rversibilit est assure travers un modle
vnements hirarchiques [M YERS & KOSBIE 96], o un graphe orient relie vnements-source et vnements interprts. La rsolution dune ambigut (qui se fait plus tard, voir plus bas) consistera
accepter certains vnements et en rejeter dautres. Lacceptation dun vnement impliquera lacceptation de ses vnements-source, ainsi que le rejet des vnements avec lesquels il est en conit.
Le rejet dun vnement conduira quant--lui au rejet de toutes ses interprtations.
68
F IG . 2.26 vnements hirarchiques rsultant de deux gestes la souris [M ANKOFF et al. 00].
La gure 2.26 reproduit une situation de prototypage gestuel dinterfaces, o une forme mirectangle mi-cercle est trace par lutilisateur, suivie dun geste de type texte (en haut de la gure).
Cette interaction peut signier soit lajout dune case cocher, soit lajout dun bouton radio. Les
vnements hirarchiques crs sont reprsents par un graphe dont les nuds sont des vnements
de bas niveau (ellipses contour noir), des vnements synthtiques non ambigus (ellipses grises)
ou des vnements synthtiques ambigus (ellipses contour discontinu). Ici, lacceptation de lvnement Checkbox induirait lacceptation de lvnement Rect, puis le rejet de lvnement contradictoire
Circle, impliquant son tour le rejet de lvnement Radiobutton.
Cest le systme de mdiation qui se charge initialement daccepter ou rejeter des vnements.
Il reoit les vnements ambigus aprs leur propagation, et les transmet successivement ses mdiateurs, des objets qui savent rsoudre un type particulier dambigut. Un mdiateur intress peut
choisir de rsoudre immdiatement lambigut (en gnral en interagissant avec lutilisateur), ou bloquer cette ambigut pour la rsoudre plus tard. Le systme de mdiation emploie de prfrence des
stratgies paresseuses, o la mdiation est la fois repousse dans les couches dabstraction suprieures et diffre dans le temps, dans le but de :
Donner lambigut loccasion de se rsoudre toute seule : cest le cas par exemple lorsquun
seul vnement ambigu est nalement consomm, les autres ntant pas interprtables par les
widgets.
Ne pas dmarrer la mdiation trop tt : par exemple, ne pas afcher un menu avant que le geste
ne soit termin. Ce dernier comportement est implment par le mdiateur StrokePauser qui
bloque les vnements jusqu rception dun vnement Release.
Privilgier les mdiations de haut-niveau : par exemple, Est-ce une case cocher ou un bouton radio ? est prfrable Est-ce un cercle ou un rectangle ? . De mme, il est souhaitable
de fournir des techniques de mdiation ddies la tche.
Produire un feedback complet sur linterprtation des diffrentes alternatives. Chaque widget
peut ainsi effectuer un retour utilisateur an de montrer ce qui se produirait si lvnement tait
accept. Cela suppose des widgets spcialiss qui sachent traiter des vnements provisoires,
pour ensuite les accepter ou les rejeter.
Enn, donner lutilisateur la possibilit de diffrer son choix. Par exemple, une trace brute
69

possde un sens en tant quannotation, et na pas besoin dtre interprte comme un bouton
radio ou une case cocher tant que lutilisateur na pas dcid dinteragir avec.
Linteraction gestuelle
Le geste, cas particulier dentre ambigu, est une modalit dominante dans les applications dites
gestuelles et dans les systmes stylet. Si Multimodal Subarctic ainsi que Subarctic et Amulet proposent un ensemble minimal de techniques dinteraction gestuelle, certains outils plus conventionnels mais spcialiss offrent une prise en charge plus complte des diverses techniques gestuelles
existantes. Cest le cas du systme dexploitation PenPoint [C ARR 91] et des botes outils Flatland [M YNATT et al. 99] et Satin [H ONG & L ANDAY 00]. Nous prsentons ici Satin, dont larchitecture en
entre est assez reprsentative tout en tant lune des plus abouties aujourdhui.
Satin [H ONG & L ANDAY 00] est une librairie Java qui couvre la plupart des techniques gestuelles
existantes (voir gure 2.27 page ci-contre) et les intgre en partie Swing. Satin emploie son propre
modle graphique (avec prise en charge du dessin structur, des couches, des vues multiples et des
effets de zoom) et dnit une architecture dinteraction gestuelle par-dessus les vnements souris
standard.
Les vnements souris sont convertis en traces qui sont propages dans la hirarchie graphique
de Satin comme des vnements positionnels ( ceci prs quune trace est uniquement transmise
aux objets qui la contiennent entirement) et traites au sein de chaque objet par plusieurs types
dinterprteurs. Les interprteurs gestuels comportent un moteur de reconnaissance qui partir dune
trace produisent une liste de commandes reconnues, ordonne par probabilit dcroissante. Les interprteurs dencre comportent des algorithmes de traitement permettant de couper, joindre, simplier
des traces ou les transformer en segments.
Satin distingue galement les interprteurs discrets des interprteurs progressifs qui peuvent effectuer des actions durant un geste, et introduit la notion de multi-interprteurs, des interprteurs
composites munis dune stratgie de choix. Cette dernire consiste en gnral transmettre une trace
aux interprteurs-ls jusqu ce quelle soit consomme, mais peut galement grer des modes : le
multi-interprteur zoom smantique, par exemple, active ou dsactive des interprteurs en fonction du
niveau de zoom actuel.
Enn, Satin ajoute Swing un widget gestuel de type Marking Menu, et modie dans son Pen
Look & Feel certains widgets Swing dans le but de faciliter la manipulation au stylet (suppression
du double-clic et largissement de certains lments).
Linteraction multi-pointeurs
Un petit nombre de prototypes botes outils ont t proposes dans le but de dcrire des techniques de travail collaboratif o plusieurs utilisateurs interagissent avec la mme application sur le
mme poste de travail, ou pour dcrire des techniques dinteraction bimanuelle. Il sagit principalement de MMM [B IER & F REEMAN 91], Bimanual Whizz [C HATTY 94], et MID [H OURCADE & B EDERSON 99].
Ces trois outils ont en commun la prise en charge de dispositifs de pointage multiples.
MMM (Multi-Device Multi-User Multi-Editor). MMM [B IER & F REEMAN 91] est un prototype
dapplication interactive pouvant tre contrle la souris par plusieurs utilisateurs. Cette application
70
F IG . 2.27 Denim, une application de prototypage de sites web base sur les paradigmes dinteraction gestuelle et dinterface zoomable, dveloppe avec la bote outils Satin [H ONG & L ANDAY 00].
consiste principalement en des menus et des hirarchies dditeurs, qui sont des zones rectangulaires
contenant des objets gomtriques manipulables, des zones de textes ou encore dautres diteurs. Bien
quil ne sagisse pas proprement parler dune bote outils, MMM a t dvelopp dans le but de
valider la fois un modle dinteraction et une architecture logicielle adapts linteraction multiutilisateurs.
Le modle dinteraction de MMM distingue tout dabord utilisateurs et dispositifs : aprs stre
saisi dune souris, chaque utilisateur senregistre en cliquant sur sa zone personnelle, un petit rectangle
portant son nom (voir gure 2.28 page suivante). En outre, les modes dinteraction sont dupliqus
pour chaque utilisateur : chaque utilisateur possde sa propre slection (qui reprsente aussi le focus
clavier et le focus commande pour les menus), ses attributs par dfaut (police de texte, couleur),
une position de caret (curseur textuel), et bien videmment une position de pointeur. Chacun de ces
modes comporte un feedback ; certains comme les attributs par dfaut sont visualiss dans la zone
personnelle de lutilisateur (gure 2.28 page suivante), dautres comme les pointeurs et les slections
sont afchs dans la couleur personnelle de lutilisateur pour pouvoir tre distingus. Ces derniers
sont superposables graphiquement, y compris les slections graphiques et textuelles. Les menus sont
des objets partags qui peuvent nanmoins tre dupliqus par les utilisateurs pour tre placs dans
leur zone de travail. Enn, MMM autorise linteraction concurrente avec une granularit assez ne.
Par exemple, un utilisateur peut dplacer un diteur pendant que lautre modie lun de ses objets.
Pour prendre en charge ces techniques, MMM repose sur un modle de gestion des entres spcique. Les vnements souris traditionnels ont t repris et tendus avec un champ identiant le
dispositif, un champ identiant lutilisateur, et un champ contenant ltat des autres dispositifs. Ces
vnements sont gnrs puis transmis travers la hirarchie des diteurs jusqu tre consomms,
selon le mcanisme daiguillage classique. La diffrence est que chaque diteur possde sa propre
71
F IG . 2.28 La zone personnelle dun utilisateur dans MMM, travers laquelle il peut senregistrer et y visualiser une partie de ses modes dinteraction. gauche, un rectangle illustre la couleur de remplissage par dfaut.
droite, la zone personnelle indique la police courante. [B IER & F REEMAN 91]
le dvnements quil interprte dans son propre l dexcution. cette concurrence sajoutent des
mcanismes de synchronisation qui permettent dviter les modications incohrentes. Dabord, la
conversion en coordonnes locales dun vnement positionnel lors de sa transmission un diteur
nest pas effectue tant que la position de cet diteur risque dtre en cours de modication, cest-dire tant que le processus de son parent est actif (les vnements clavier par contre, sont transmis sans
attendre). Ensuite, lvnement est interprt en deux temps par lditeur : lorsquune modication de
la slection ou du focus positionnel est ncessaire, lditeur envoie une requte de mise jour un
processus extrieur avant de replacer lvnement dans sa le pour une seconde phase de traitement.
Enn, le rafchage est galement effectu de manire asynchrone, selon un mcanisme analogue
celui de Java Swing [E CKSTEIN & L OY 02].
Bimanual Whizz. Bimanual Whizz [C HATTY 94] est le nom que nous donnons lextension bimanuelle de Whizz [E STEBAN 97]. Whizz est une bote outils qui dcrit linteraction par un modle ot de
donnes, et est dote dun outil de programmation visuelle (voir la section 2.7.2 page 83 sur lditeur
graphique WhizzEd). Whizz repose essentiellement la bote outils XTV [B EAUDOUIN -L AFON et al. 90],
crite pour le dveloppement dapplications manipulations directe avec X. XTV constitue une bonne
infrastructure pour la gestion de dispositifs multiples car ses vnements possdent la notion de
dispositifs-source.
Bimanual Whizz implmente un modle dinteraction bimanuelle qui distingue trois paradigmes
[C HATTY 94] : linteraction indpendante (les deux mains sont employes en srie, par exemple pour s-
lectionner un outil avant de lutiliser), linteraction parallle (les deux mains effectuent simultanment
des tches distinctes) et linteraction combine (les deux mains collaborent sur la mme tche). Son
modle dinteraction prend galement en compte laspect asymtrique de linteraction bimanuelle, en
remplaant pour la main non-dominante le point actif du pointeur par une zone circulaire.
Bimanual Whizz modie peu le modle vnements standard de XTV , dabord pour prserver
la compatibilit avec le modle original, et ensuite parce que ce modle possde dj une notion de
dispositifs qui permet de distinguer des vnements souris de sources diffrentes. Ds lors, il est possible de rsoudre certains problmes de concurrence, et de dcrire par exemple des boutons sensibles
nimporte quel vnement Press mais ltrant ensuite tout vnement autre que le Release du dispositif lorigine du Press. Les interactions parallles continues de type cliquer-glisser posent dautres
problmes de concurrence qui sont rsolus dans Bimanual Whizz en instanciant chaque interaction
72

un objet analogue un interacteur de Garnet, qui prend en charge de faon autonome les transitions
dtats, la manipulation et le feedback.
F IG . 2.29 Utilisation de ltres dans Bimanual Whizz pour dcrire des techniques dinteraction bimanuelle
combine. Sur le schma de gauche, le pointeur droit est utilis pour dplacer un segment ; lorsque le pointeur
gauche clique sur une extrmit de ce segment, le ot est redirig par le ltre Switch et le segment est dform. Le schma de droite dcrit une technique de fusion temporelle, o un ltre spcialis ferme lapplication
lorsquil reoit deux vnements dans un intervalle de temps spci. [C HATTY 94]
Pour les interactions combines, Bimanual Whizz distingue deux types de fusion. Dans une combinaison de type mode+vnement, le premier dispositif spcie un mode dinteraction pour le second :
par exemple, la manipulation de lextrmit dun segment est interprte comme une translation sauf
si lautre extrmit est maintenue par un autre pointeur. Le modle de Whizz permet dintroduire aisment ce type de mode par lajout dun module dans le ot de donnes (voir gure 2.29, image de
gauche). Dans une combinaison de type vnement+vnement, deux vnements simultans sont interprts en un vnement de plus haut niveau : par exemple, cliquer simultanment sur deux boutons
peut fermer lapplication. Ce type de fusion temporelle ncessite simplement dans Whizz la dnition dvnements synthtiques supplmentaires et lajout dun ltre dans le ot de donnes (voir
gure 2.29, image de droite).
MID (Multiple Input Devices). MID [H OURCADE & B EDERSON 99] est une librairie qui tend le modle AWT de Java pour grer des dispositifs de pointage multiples. Elle ne dnit pas de nouveaux
types dvnements, mais tend la dnition dun vnement souris en y introduisant la notion de
dispositif-source, selon une approche trs similaire Bimanual Whizz. Les applications Java existantes ncessitent peu de modications pour tre rendues compatibles avec MID, et seules les oprations consistant, pour les widgets, senregistrer comme observateurs dvnements souris ncessitent
dtre traduites. Lapplication peut ensuite tre modie an dexploiter les identiants de dispositifs.
MID a servi implmenter une application de dessin multi-utilisateurs nomme KidPad.
MID introduit dans lAWT la notion de dispositifs de pointages multiples dune manire relativement sduisante, sans modier les principes fondamentaux de cette bote outils. Cependant,
lapproche de MID est essentiellement pragmatique et de bas-niveau. En particulier, il naborde pas
les problmes de la gestion concurrente des vnements positionnels que nous avons prcdemment
voqus.
73

Les outils semi-transparents
Les botes outils que nous dcrivons ici constituent en quelque sorte des volutions des botes
outils multi-pointeurs : elles grent linteraction bimanuelle, mais y ajoutent de nouvelles techniques dinteraction bases sur la semi-transparence (voir section 1.3.3 page 19). Elles sont cependant peu reprsentes. En introduisant le premier modle dinteraction bas sur ce paradigme, Bier
et al [B IER et al. 93] dcrivent par la mme occasion une extension de la bote outils MMM utilise pour implmenter ces techniques. Nous la dcrivons dans un premier temps. Par la suite, Kurtenbach et al. [K URTENBACH et al. 97] ont tendu de faon intressante ce modle dinteraction bimanuelle avec leur application T3 (Tablets, Two-hands, Transparency), notamment en augmentant le
nombre de degrs de contrle (deux dispositifs positionnels sensibles la rotation sont employs).
Cependant, ils ne proposent pas de nouvelle bote outils. Enn, une autre application-prototype,
CPN2000 [B EAUDOUIN -L AFON & L ASSEN 00], a t dveloppe sur un modle dinteraction similaire, et
a permis dintroduire une nouvelle architecture de bote outils Post-WIMP. Nous dcrivons galement cette architecture.
MMM remani. Le modle dinteraction bimanuelle bas sur les outils semi-transparents a t
dcrit par Bier et al [B IER et al. 93] dans le but de montrer comment lemploi combin de palettes ottantes semi-transparentes composes doutils divers et de lentilles magiques peut faciliter des tches
de cration, ddition, ou de slection dobjets graphiques. Ces interactions ont t implmentes avec
la bote outils MMM (voir section 2.6.2 page 70), aprs des remaniements importants de son modle
dafchage et de son modle dentre.
Cette bote outils a t tout dabord modie pour interprter de faon spcique les vnements
en provenance dun dispositif trackball, an quil puisse tre employ par la main non-dominante
pour dplacer et redimensionner les objets ottants et naviguer dans la fentre graphique. En outre,
lintroduction doutils ottants dstructure le modle hirachique des objets graphiques pour lequel
le mcanisme daiguillage tait conu (voir gure 2.30). Les vnements positionnels doivent ainsi
remonter vers lapplication aprs avoir t transmis aux objets graphiques et ventuellement modis
par ceux-ci. Les deux types de modication sont lannotation et le changement de position.
Lannotation a pour but de sassurer quun objet ne recevra pas deux fois le mme vnement,
et permet de transmettre des commandes. Une palette ottante, par exemple, ajoute une commande
lvnement et le retourne lapplication, qui se charge ensuite de passer cet vnement aux objets
qui se trouvent en-dessous et ainsi de suite. Les commandes sont concatnes pour permettre lusage
combin de plusieurs palettes. Quant aux lentilles magiques, dont la plupart sont dformantes, elles
modient la position de chaque vnement an quil soit correctement dirig vers lobjet qui apparat
sous sa position.
F IG . 2.30 Les outils ottants ajoutent la notion de hirarchie celle de couche graphique : les trois outils
reprsents ici sont au mme niveau dans la hirarchie des widgets, bien quils soient superposs et afchs
dans un ordre dtermin (de droite gauche dans larbre) [B IER et al. 93].
74

Larchitecture CPN2000. CPN2000 [B EAUDOUIN -L AFON & L ASSEN 00] est une application complte ddition de rseaux de Ptri colors, employant un modle dinteraction instrumentale (voir section 2.5.2 page 57) mlant efcacement manipulation directe et bimanuelle, palettes doutils conventionnelles ou semi-transparentes, Marking Menus (voir section 1.3.2 page 18), guides magntiques de
type Snap-Dragging, et un modle de documents bas sur une mtaphore de classeurs. Ce modle
privilgie la redondance (il existe de multiples manires deffectuer une tche) et autorise par des
quasi-modes laccs simultan plusieurs outils.
Larchitecture de CPN2000 est de type MVC, avec une structure de document (M), une structure
dafchage (V) et une structure dentre (C) clairement spars et faiblement coupls. La structure
dentre est compose dinstruments dinteraction, qui grent des entrs physiques et possdent une
prsentation. Les instruments consultent la structure graphique pour le picking mais oprent directement sur les lments (nuds) du document structur avec un protocole simple base de commandes.
Plusieurs instruments spciques une classe particulire de nud peuvent tre combins en un
instrument gnrique. En outre, un instrument est lui-mme un document, ce qui lui permet dtre
manipul par dautres instruments (par exemple, les outils dune palette peuvent tre dplacs avec un
instrument Move). Pour nir, lactivation et la dsactivation de chaque instrument est gr par deux
machines tats, un par dispositif.
Linteraction 3D
Par opposition aux scnes 3D statiques, les scnes animes en temps rel comportent des lments
(camras, sources lumineuses, objets) dont les attributs (position, forme, couleur) sont variables au
cours du temps. Dans le domaine de la 3D, linteraction est considre comme un cas particulier
danimation, o les attributs nvoluent plus de faon autonome mais en fonction de valeurs en provenance des dispositifs dentre ou de dispositifs virtuels (la plupart du temps, des widgets 2D).
Ces dispositifs sont vus comme des groupes de canaux produisant des valeurs de faon continue.
Ainsi, la majorit des nombreuses botes outils 3D modernes dcrivent linteraction par des
contraintes ou des ots de donnes liant des canaux des attributs : citons par exemple UGA [Z ELEZNIK et al. 91],
Inventor [S TRAUSS & C AREY 92], TBAG [E LLIOTT et al. 94], WorldToolkit [S ENSE 8 03], Virtools [V IRTOOLS 01]
ou des approches plus rcentes comme OpenTracker [R EITMAYR & S CHMALSTIEG 01] et 3dml/inTml [F IGUEROA et al. 02].
Un petit nombre doprateurs mathmatiques simples (par exemple, des oprateurs permettant dagir
sur la vitesse ou lacclration dun objet plutt que sur sa position) suft dcrire la plupart des
techniques de contrle continu et statique tels quon les trouve dans les outils de navigation 3D ou les
jeux. Lessentiel du comportement de ce type dapplication est pris en charge par des outils de simulation mcanique, et les actions discrtes sont traites comme de simples commandes (par exemple,
lappui dun bouton lance lanimation dun tir de missile).
En revanche, les applications de conception et ddition o des objets sont manipuls ont des
besoins plus proches de ceux des interfaces 2D, et les modes y jouent notamment un rle important.
Les modes et en particulier le multiplexage temporel et spatial sont habituellement traits dans les
botes outils 3D comme des remaniements explicites du graphe de contraintes ou des reconnexions
dynamiques dans le ot de donnes. Les stratgies de picking employes pour les dispositifs 2D
sont similaires celles des botes outils conventionnelles, alors que la slection 3D ncessite des
techniques plus avances comme le Go-Go8 , techniques qui sont rarement prises en charge.
8 Le
Go-Go est une technique de slection 3D o le bras virtuel est tendu jusqu atteindre lobjet [P OUPYREV et al. 96].
75

Dautres paradigmes en cours dexploration
De nouvelles botes outils continuent tre proposes pour prendre en charge, du moins en
partie, de nouveaux paradigmes dinteraction encore en cours dexploration. Nous dcrivons brivement le Context Toolkit utilis pour construire des applications sensibles au contexte et les Phidgets,
employs pour construire des interfaces tangibles.
Context Toolkit. Les applications sensibles au contexte (voir section 1.3.5 page 24) sont difciles
construire, tant donn leur nature distribue et lemploi de dispositifs non-standard (capteurs) de
nature trs htrogne. Le Context Toolkit [S ALBER et al. 99] propose une architecture base sur la notion
de widgets de contexte, qui communiquent entre eux par TCP/IP et XML.
Les widgets de contexte maintiennent un tat en fonction de donnes en provenance de gnrateurs, qui sont des abstractions des senseurs physiques. Ils se chargent galement de notier lapplication de tout changement dans cet tat. Par exemple, le widget Prsence notie de lidentit de
chaque arrivant et son heure darrive dans un lieu donn partir de systmes badge ou danalyse
biomtrique, et le widget Activit informe de tout changement dans le niveau dactivit en fonction de
donnes en provenance de microphones ou de camras vido.
Les widgets de contexte sont composables : par exemple, un widget Runion peut dtecter le
dbut ou la n dune runion en fonction du nombre de personnes dans la salle et du niveau dactivit. Les Serveurs sont des conteneurs plus importants de widgets, qui peuvent par exemple notier
lapplication de chaque dbut et n de runion dans lensemble dun immeuble.
Les Phidgets. Dans les interfaces tangibles (voir section 1.3.5 page 23), une mme mtaphore
peut tre mise en uvre par des techniques trs diverses. Les interfaces bases sur la capture vido
ncessitent avant tout des librairies qui prennent en charge lacquisition, lanalyse et linterprtation
dimages en provenance de camras ou web-cams. Dautres interfaces font usage de dispositifs spcialiss comme les capteurs 3D, dautres encore reposent sur des dispositifs maison . Si les dispositifs
exotiques du commerce sont souvent ardus programmer, il est encore plus difcile de construire
soi-mme des dispositifs mme simples.
Lobjectif des Phidgets [G REENBERG & F ITCHETT 01] est de fournir des composants physiques agenables prts lemploi et aisment accessibles travers une API unie. La partie physique des phidgets communique travers le protocole USB, et la partie logicielle repose sur les standards COM et
ActiveX de Microsoft. Le composant logiciel principal, le gestionnaire de phidgets, notie lapplication des connexions et dconnexions de phidgets et instancie un objet daccs chaque connexion.
Ce dernier comporte une interface gnrique permettant notamment didentier le dispositif de faon
unique, et une interface spcique permettant de lire et/ou modier son tat, et tre noti de ses
changements.
Un phidget peut galement tre reli et synchronis un widget : Par exemple, un slider peut tre
utilis pour contrler un potentiomtre motoris, visualiser sa position, ou simuler son comportement
lorsquil est absent. La librairie WidgetTap [G REENBERG & B OYLE 02] offre maintenant des outils dinspection permettant dattacher des phidgets des widgets dapplications Windows conventionnelles
(voir galement la section 1.3.5 page 23 ce sujet).
76

Laccessibilit
Sil nexiste pas notre connaissance de bote outils prenant spciquement en charge des
techniques dinteraction adaptes des entres appauvries, certaines botes outils proposent des
solutions simples pour amliorer laccessibilit. La plupart dentre elles offrent ainsi aux utilisateurs
experts et ceux ne pouvant employer une souris des moyens dinteragir avec les widgets par lintermdiaire du clavier.
LAPI daccessibilit de Swing [S UN 02] va plus loin en dnissant un contrat entre linterface et
les technologies daccessibilit extrieures, qui consiste principalement attribuer chaque widget
un nom, une description et des moyens de naviguer dans sa hirarchie. Lobjectif de cette API est
de fournir une vue textuelle des applications pour quelles puissent tre perues et contrles
indpendamment de leur prsentation graphique.
Aucune de ces techniques ntant en mesure de garantir laccessibilit effective dune application,
les guides daccessibilit publis lusage des dveloppeurs en constituent un complment indispensable [D UNN 00, S CHWERDTFEGER 00]. Ces derniers conseillent par exemple de sassurer que tout widget
peut tre travers par le mcanisme de focus, et que des raccourcis sont dnis pour tout lment de
menu et fonction importante de lapplication.
Discussion sur les apports et les limites des botes outils spcialises
Malgr leur spcialisation, les botes outils Post-WIMP contribuent de faon importante la
comprhension de linteraction en entre. Lapport de Multimodal Subarctic, par exemple, est davoir
rationalis les techniques de mdiation qui taient dj employes par certaines applications mais mal
comprises. Cette bote outils introduit une architecture claire et propose des outils efcaces pour
la gestion des entres ambigus, et est par consquent bien adapte au paradigme de linteraction
multimodale. Un autre apport de ce modle est davoir explicit un aspect notre avis important
de linteraction en entre, savoir lexistence de niveaux dabstraction dnis par des chanes de
traitements successifs. Cette notion napparaissait que de faon implicite dans Subarctic o chaque
agent recevait les mmes vnements bas-niveau. Ces chanes de traitement deviennent rellement
explicites dans le modle ot de donnes de la bote outils Whizz et son extension linteraction
bimanuelle. Larchitecture de CPN2000 offre quant--elle une base solide aux techniques de type
instrumental et dcrit une implmentation efcace du modle MVC.
Les botes outils spcialises sont plus ouvertes aux entres que les botes outils WIMP, mais
chacune dentre elles comporte ses limites. Bien que Multimodal Subarctic ait ajout des modalits
(parole, geste et contexte) Subarctic, sa prise en charge des dispositifs non-standard reste limite,
et le clavier et la souris continuent y jouer un rle prpondrant. Comme dans Satin, linteraction
gestuelle repose exclusivement sur les vnements souris conventionnels. Les botes outils multipointeurs et de semi-transparence exploitent efcacement des entres positionnelles multiples, mais
de faon ad-hoc et avec des dispositifs de type spcique : MMM dcrit des techniques adaptes
linteraction multi-utilisateurs avec la souris et sa version bimanuelle gre un trackball et une souris
de manire cble. Bimanual Whizz ne reconnat que les souris, bien quil les gre de faon trs
extensible.
Les botes outils 3D sont celles qui savent le mieux exploiter les entres enrichies. Leurs modles
canaux permettent dobtenir, avec peu dabstractions, une certaine indpendance par rapport aux
77

entres, que certains outils comme WorldToolkit exploitent au maximum en prenant en charge un
grand nombre de dispositifs. Ces modles autorisent en outre une grande exibilit dans la description
dinteractions et se prtent bien la programmation visuelle (voir plus loin, section 2.7 page ci-contre).
Cependant, leur pouvoir dexpression se limite au contrle dattributs dobjets 3D, et ces outils ne
sont pas adapts la complexit de linteraction 2D. Bien quil prenne en charge moins de dispositifs
non-standard, Bimanual Whizz tire avantage du mme type de modle ot de donnes pour dcrire
certaines techniques dinteraction 2D Post-WIMP.
Aucun de ces outils, y compris les plus ouverts en entre, na t prvu pour laccessibilit. Les
recherches actives dans ce domaine se posent gnralement pour objectif de dnir des architectures
applicatives o lon puisse greffer des modalits de sortie et dentre alternatives, ce qui suppose tout
dabord de rendre le modle de lapplication (ou la structure du document, pour les navigateurs Web)
explicite. Si les implmentations incompltes du modle MVC comme celui de Swing autorisent dans
une certaine mesure la substitution des prsentations (utiliser une modalit sonore au lieu de visuelle,
par exemple), elles nexternalisent pas sufsament le contrle pour tre exploitables du point de vue
des entres.
Lintroduction de lAPI daccessibilit a nanmoins fait de Swing une bote outils considre
comme lune des plus avances dans le domaine, car lon considre actuellement quune application
est accessible ds lors quelle est compatible avec les technologies daccessibilit existantes comme
les lecteurs dcran . Malgr tout, une relle accessibilit exige des applications quelles proposent
des techniques dinteraction adaptes la fois au handicap et la tche. Or laccessibilit des applications repose toujours sur des outils extrieurs, et nous ne connaissons ce jour aucune bote outils
capable daider le dveloppeur construire des applications directement accessibles.
2.6.3
Conclusion
Alors que chaque bote outils tente de proposer un modle graphique le plus gnrique possible,
chacune dentre elles emploie un modle dentre ad-hoc, qui convient ce que lon veut faire .
Certaines botes outils tentent certes de proposer des mcanismes gnraux, mais sans rellement y
parvenir. Ainsi, si les techniques gestuelles simples se dcrivent bien dans les botes outils WIMP
avances, la plupart des autres paradigmes ncessitent des changements incrmentaux importants. Le
fait que nombreuses de ces extensions fassent lobjet de publications compltes est assez rvlateur.
Cette grande htrognit dans les botes outils est naturelle. Tout dabord, les paradigmes
Post-WIMP sont trs varis et leur unication pose un problme vident de complexit. Mme si
des applications comme CPN2000 parviennent composer des techniques multiples, certaines publications font tat de la complexit de combiner deux paradigmes comme linteraction gestuelle et
cooprative [H ONG & L ANDAY 00]. En outre, un dveloppeur doutils se xe en gnral pour objectif
soit de prendre en charge les techniques propres un paradigme dinteraction dans lequel il est expert
(interfaces conventionnelles pour Garnet, interfaces gestuelles pour Satin), soit de prendre en charge
un nouveau modle dinteraction des ns de dmonstration (MMM remani).
Les botes outils Post-WIMP nen permettent pas moins de construire des applications bien
plus contrlables dans le sens o elle prennent en charge des techniques dinteraction avances. Cette
contrlabilit est nanmoins limite par le fait que ces techniques sappuient soit sur des dispositifs conventionnels (botes outils gestuelles), soit sur un ensemble xe de dispositifs quelles exploitent de faon efcace mais rigide (botes outils multi-pointeurs). La version tendue de MMM,
78
2.7. LES DITEURS GRAPHIQUES DINTERACTION

par exemple, gre de faon trs spcique le trackball dune part, et les pointeurs conventionnels
dautre part.
Seules les botes outils 3D parviennent obtenir une certaine indpendance par rapport aux
entres en permettant de connecter librement des dimensions physiques multiples des attributs dobjets 3D. Et bien quelles soient loin de balayer lespace des dispositifs non conventionnels existants,
certaines dentre elles prennent en charge des dispositifs 3D nombreux et divers. Elles exploitent cependant un paradigme Post-WIMP spcique (le contrle parallle et direct) en ignorant presque tout
des techniques avances du domaine de la 2D (outils transparents, gestes, reconnaissance vocale, etc).
Aucune bote outils WIMP avance ou Post-WIMP ne prend en charge laccessibilit, cest-dire linteraction avec des entres appauvries, autre que par des moyens standard (raccourcis clavier).
La plupart offrent une certaine congurabilit oriente-programmeur dans la mesure o elles sont
un peu plus extensibles et mieux construites que les botes outils traditionnelles. Cependant, la
grande majorit ne permet pas de congurer linteraction sans programmation. Les exceptions sont
Garnet/Amulet, qui permet de paramtrer les interacteurs, et les outils 3D qui offrent parfois un diteur
interactif, approche dont sinspire galement WhizzEd dans la 2D. Les diteurs visuels dinteraction
connus seront dcrits de faon plus gnrale et dtaille dans la section suivante.
2.7 Les diteurs graphiques dinteraction

Les diteurs graphiques dinteraction permettent de construire ou de modier des applications
interactives ou des parties dapplications interactives par manipulation, assemblage, et connexion de
blocs lmentaires.
Les outils de construction dinterfaces de type Visual Basic [F RANTZ 00] ou Visual C++ [C HAPMAN 03]
ne permettent de dcrire que la partie prsentation des interfaces graphiques, et ne seront pas voqus
ici. Parmi les outils permettant de spcier le comportement des interfaces, nous distinguons deux
catgories : les diteurs de simulations interactives 2D qui permettent de spcier simultanment la
prsentation et le comportement dapplications interactives 2D, et les diteurs de comportement 3D
qui sont destins la description de comportements dapplications 3D.
Chaque diteur possde un style de programmation visuelle qui lui est propre, selon quil met
laccent sur laspect ot de donnes, ot de contrle ou encore la programmation par contraintes.
Certaines de ces approches sont communes aux diteurs 2D et 3D. Nous les dcrivons dans un premier
temps. Puis, nous prsentons les deux catgories dditeurs, en dcrivant les principaux outils existants
puis en analysant leurs avantages et leurs inconvnients.
2.7.1
Les paradigmes de programmation visuelle
Les diteurs graphiques de comportements emploient des objets graphiques interconnects assimilables des graphes. La smantique de ces graphes diffre selon lapproche de programmation
visuelle utilise :
Flot de donnes. Dans lapproche ot de donnes, les sommets reprsentent des oprations atomiques et les arcs reprsentent des transferts de donnes entre ces oprations. Les sommets
produisent de faon rptitive des valeurs en sortie en fonction des valeurs reues en entre.
79

Des rgles de dclenchement spcient quel moment un sommet est activ. Le paradigme
de ot de donnes permet de mettre en vidence les ux dinformations dans un processus, et
dcrit de faon explicite la dpendance entre les donnes. Il se focalise sur la transformation.
Programmation fonctionnelle. Lapproche fonctionnelle est trs proche de lapproche ots de donnes, dans le sens o elle dcrit galement des transformations. Cependant, dans les graphes
fonctionnels, les donnes sont tires au lieu dtre pousses : une opration nest active que lorsque ses rsultats sont ncessaires une opration ultrieure. Ce mcanisme est
galement appel valuation paresseuse.
Flot de contrle. Dans lapproche ot de contrle de type organigramme, les sommets dcrivent
galement des oprations. Cependant, laccent est mis sur le squencement de ces oprations,
et les ux de donnes disparaissent. Les arcs spcient des relations dordre du type "sexcute
avant" et les donnes consommes et produites par les oprations sont relgues dans des variables globales. Dans la version automate des graphes ot de contrle, les sommets dcrivent
des tats et les arcs des transitions entre tats pendant lesquelles sont effectues les oprations
(voir section 2.3.1 page 44). Ces oprations manipulent galement des variables globales. Les
deux types de graphes imposent un ordre total sur les oprations : un seul sommet est activ
la fois. Ce paradigme met en vidence le squencement des oprations dans un processus. Il se
focalise sur laspect procdural.
Programmation par contraintes. Les contraintes sont des relations portant sur une ou plusieurs
variables, qui sont spcies indpendamment de toute notion algorithmique. Un solveur se
charge de les rsoudre (i.e. trouver une instanciation correcte des variables), ou de les maintenir
(i.e. instancier en continu un sous-ensemble des variables en fonction dautres variables qui
voluent au cours du temps). Dans les langages graphiques inspirs de la PPC, les sommets
sont des variables et les arcs des contraintes qui devront tre maintenues entre ces variables.
Ces graphes nimposent pas de relation dordre du type "sexcute avant". La programmation
par contraintes met en avant une description dclarative des problmes, en termes de relations
entre les composants.
2.7.2
Les diteurs de simulations interactives
Les diteurs de simulations interactives emploient des langages visuels o certaines primitives
graphiques sont manipulables lexcution, ce qui permet de dcrire simultanment la prsentation
et le comportement dinterfaces graphiques. Ils peuvent tre employs pour dcrire le comportement
de widgets mais galement la faon dont ils sont contrls par des vnements de bas-niveau.
La plupart de ces diteurs emploient des paradigmes de programmation par contraintes, dautres
ont une approche ot de donnes, dautres encore ont une approche mixte. Dans cette section, nous
dcrivons ces trois types dditeurs.
Les contraintes de ThingLab

Thinglab [B ORNING 79] est lun des premiers systmes employer des techniques de programmation visuelle pour dcrire des comportements interactifs. Implment dans le langage SmallTalk,
Thinglab repose sur la PPC tout en restant volontairement trs proche des concepts de la programmation oriente objet : classes, objets, mthodes, hirarchie dhritage et hirarchie compositionnelle.
80

Les objets prdnis de ThingLab, pour la plupart des objets gomtriques simples, consistent en des
structures dobjets lis par des contraintes, et possdant une reprsentation graphique manipulable.
De nouvelles classes dobjets peuvent tre construites par composition, en assemblant graphiquement
plusieurs objets existants et en spciant des contraintes supplmentaires.
F IG . 2.31 Une fentre de lditeur de simulation Thinglab. [B ORNING 79]
Une fentre de ThingLab est reprsente sur la gure 2.31. La partie suprieure de la fentre
contient lexplorateur dobjets. Les classes de ThingLab sont listes dans le premier panneau,
gauche. Le second panneau permet dafcher lobjet courant sous diffrentes formes (graphique,
structurelle ou valeurs), le troisime permet dappeler ses mthodes, et le dernier contient les arguments de ces mthodes. Une partie importante de linteraction (instanciation et composition dobjets,
dnition des contraintes) seffectue par appel de ces mthodes. La partie infrieure de la fentre
contient la reprsentation graphique manipulable de lobjet courant.
gauche de la zone infrieure, un oprateur daddition a t construit par composition dobjets lmentaires. Ces objets lmentaires sont le point numrique (point gomtrique possdant une
valeur numrique interne) et la piste numrique (association dun point numrique et dun segment),
ainsi quun cadre permettant dafcher un symbole. Loprateur est construit en composant trois pistes
numriques et un cadre, et en spciant les contraintes gomtriques et numriques qui les lient. Une
piste numrique peut tre afche et rendue ditable en lui associant un champ de saisie. droite, un
convertisseur de tempratures a t construit par assemblage de ces objets. Les zones de saisie, xes
par des ancres, sont considres comme des constantes par le solveur.
La gure 2.32 page suivante illustre deux autres exemples construits avec ThingLab. Lexemple de
gauche est un document comportant quatre nombres visualiss sous deux formes : une forme textuelle
et une forme graphique. Ces deux vues sont manipulables et synchronises. Lexemple de droite est
une fentre dcoupe en zones redimensionnables, construit en composant puis en contraignant des
rectangles.
Thinglab a eu un grand impact en tant que systme de simulation interactive vise pdagogique.
Dautres outils ont suivi ses traces avec succs, comme les applications denseignement de la gomtrie Cabri Gomtre [C APPONI & L ABORDE 91] ou Chamois [B OURIT 00]. Avec Thinglab II, laccent est
81
F IG . 2.32 Deux interfaces construites avec Thinglab. [B ORNING 79]
davantage mis sur les applications interactives relles [M ALONEY et al. 89]. Mais bien que des optimisations algorithmiques aient t introduites, aucun exemple rellement nouveau na t dcrit.
Lapproche mixte de Fabrik
F IG . 2.33 Un convertisseur de temprature construit avec Fabrik. [I NGALLS et al. 88]

Fabrik [I NGALLS et al. 88] est un systme similaire Thinglab, qui a t davantage conu pour la
description dinterfaces graphiques. Fabrik est bas sur un modle de type data-ow compositionnel,
mais qui autorise les connexions bidirectionnelles de type PPC. Certains de ses objets effectuent des
calculs, dautres sont interactifs et permettent de saisir des donnes (zone de texte, bouton) ou de les
afcher (prsentation de listes, images).
La gure 2.33 montre, gauche, un convertisseur dunits de temprature construit avec Fabrik.
Celui-ci comporte deux blocs interactifs de type barre de dlement relis par un bloc de calcul,
dni laide doprateurs atomiques dans la partie droite de la gure.
Les graphmes constituent une autre particularit intressante de Fabrik. Ce sont des blocs qui
transforment des valeurs en objets gomtriques lmentaires (lignes, rectangles) et qui permettent
de dcrire la prsentation dune interface. La gure 2.34 page suivante montre lintrieur des blocs
slider utiliss dans le convertisseur de la gure 2.33. Ce graphe comporte deux graphmes de rectangles prenant les valeurs topleft et bottomright en entre. Ils correspondent aux deux rectangles
internes du slider, reprsent droite. La position du premier est xe, et celle du second est calcule
partir des mouvements de la souris.
82
F IG . 2.34 Un composant interactif construit avec les graphmes de Fabrik. [I NGALLS et al. 88]
Les ots de donnes dInterCONS et de WhizzEd

Les langages visuels ots de donnes ont t employs avec succs dans des domaines tels que le
traitement dimages ou le traitement du son. LabView [S ANTORI 90], logiciel de traitement de donnes
provenant dappareils de mesure, en est un exemple. Des diteurs de ce type existent pour dcrire des
comportements dinterfaces graphiques.
F IG . 2.35 Un systme de barres de dlement et une calculatrice construits avec InterCONS. [S MITH 88]
InterCONS [S MITH 88] est lun de ces systmes. Il emploie primitives graphiques appeles outils,
qui possdent des connecteurs en entre et en sortie de type entier. Ces blocs sont des lments
interactifs ou des oprateurs simples.
La gure 2.35 montre, gauche, une technique de dlement construite avec InterCONS. Une
barre de dlement simple et deux boutons ont t connects une vue pour contrler son dlement
horizontal. InterCONS permet de masquer les objets comportementaux an de ne laisser apparatre
que les lments interactifs, puis de rorganiser visuellement ces derniers : au centre de la gure 2.35,
la construction a t complte avec un contrle vertical avant dtre visuellement remanie. droite
de la gure est reprsente une autre application, une calculatrice, construite avec InterCONS.
83
F IG . 2.36 Une horloge analogique avec alarme rglable, dcrite avec WhizzEd. [E STEBAN 97].
WhizzEd [E STEBAN et al. 95, E STEBAN 97] est un langage visuel ddi la construction dinterfaces
manipulation directe, qui emploie un paradigme de data-ow compositionnel. Contrairement aux
diteurs vus prcdemment, la prsentation de linterface graphique est dissocie du langage visuel.
WhizzEd comporte nanmoins des briques qui afchent des primitives graphiques, similaires aux
graphmes de Fabrik. Parmi les autres types de briques disponibles, les tempos mettent rgulirement
des valeurs de type boolen dans le but deffectuer des animations, et les ractions mettent des
vnements utilisateur.
La gure 2.36 illustre une horloge construite avec WhizzEd : Lhorloge, reprsente droite de la
gure, possde une aiguille dalarme, rglable par manipulation directe, qui sonne lorsquelle concide
avec lheure courante. Cette fonction, ainsi que lapparence de lhorloge et sa mise jour sont dcrites
par le programme visuel reproduit sur la gure.
La gestion des vnements dans WhizzEd se fait par un mcanisme dabonnement : une primitive
graphique est rendue sensible un type dvnement lorsquelle est relie un bloc de raction. Ce
lien est reprsent sur la gure 2.36 par des pointills. Les ractions tant dissocies des primitives
graphiques, ce mcanisme permet de rendre explicite linterprtation des vnements. De plus, de
nouveaux types dvnements synthtiques peuvent tre ajouts avant dtre associs aux primitives
graphiques.
Discussion sur les apports et les limites de ces dmarches
La plupart des diteurs de simulations interactives prsentent lavantage de pouvoir spcier simultanment lapparence et du comportement dune interface graphique. Cependant, le comportement
dune interface peut difcilement tre spci indpendamment de sa prsentation : lorsque celui-ci
change, la prsentation de linterface change galement. InterCONS rsout en partie ce problme en
permettant de masquer certains composants graphiques.
84

ThingLab et ses successeurs ont montr que la PPC tait bien adapte la description de certains
mcanismes dinteraction : les comportements gomtriques des interfaces (positionnement, proportions, alignements de widgets), et le maintien des consistances entre les objets de lapplication et
les objets de linterface graphique ou entre des vues multiples. Il semble toutefois que ce paradigme
soit beaucoup moins employ pour dcrire linteraction en entre en tant que telle. De plus, ces outils restent ddis aux simulations interactives utilises dans des buts pdagogiques, plutt qu la
construction dinterfaces utilisateur relles. Premirement, ce paradigme ne permet de dcrire que des
relations mathmatiques simples entre des objets. Ensuite, un ensemble important de contraintes est
difcile rsoudre et spcier (systme sous-contraint ou sur-contraint).
Le paradigme ot de donnes semble plus prometteur pour dcrire les comportements complexes des applications interactives, en particulier les techniques dinteraction. En effet, ces comportements gagnent tre dcrits de manire concrte, en termes de liens de causalit entre objets
[E STEBAN et al. 95]. Parmi les outils existants, WhizzEd est actuellement lun des plus aboutis du point
de vue comportement et gestion des entres. Bien quil ait t principalement conu pour construire
des animations, il a servi dcrire une application iconique complte de type Macintosh [E STEBAN 97].
Les outils que nous avons pass en revue mettent globalement laccent sur la construction de comportements autonomes , qui mettent en uvre des animations ou des calculs complexes. Certains
exemples comme la calculatrice montrent quil est possible de crer des applications compltes, et
non seulement leur partie interface. Ces applications-jouets montrent quil est possible de construire
avec une ne granularit des composants interactifs relativement complexes.
Malheureusement, laccent sur les comportements semble se faire au dtriment de linteraction :
dans tous les exemples mis en uvre, linteractivit et la contrlabilit des applications est relativement pauvre. Si les modles de type data-ow sont naturellement adapts linteraction concurrente,
les outils actuels, de par leur vision des entres, ne permettent pas une interaction riche avec des dispositifs multiples : les entres se limitent aux vnements standards. En outre, une grande partie de la
gestion des entres est implicite et non congurable.
WhizzEd, ddi aux applications hautement interactives, semble le plus avanc dans ce domaine.
Sil est adapt la description des interfaces manipulation directe, sa vision de linteraction en
entre reste cependant relativement limite. Seuls les vnements souris classiques sont pris en compte
dans la version originale de Whizz, bien que son extension linteraction bimanuelle soit galement
capable dexploiter les pointeurs multiples de faon trs efcace (voir la section 2.6.2 page 70 sur cette
extension). Mais le mcanisme dabonnement de Whizz ne permet pas, sans programmation, de grer
de nouveaux types dvnements provenant de dispositifs concrets. En outre, certains mcanismes de
gestion des entres restent implicites, tels que le picking.
2.7.3
Les diteurs de comportements 3D
Introduction
Certains outils comme Maya RTA [A LIAS 01], Blender [ROOSENDAAL & WARTMANN 03] et Virtools
Dev [V IRTOOLS 01] permettent de crer des applications 3D hautement interactives en construisant des
comportements par manipulation directe. Lobjectif de ces diteurs est de permettre aux artistes de
rendre leurs crations vivantes et interactives sans ncessit de programmation.
Les diteurs de comportements 3D sont essentiellement bass sur les paradigmes dassociation
85

dactions (mapping) ou de ot de donnes. Certaines approches plus exprimentales dcrivent galement des diteurs visuels hybrides donnes/contrle. Nous dcrivons ces trois types dditeurs.
Les senseurs et actions de Maya RTA et Blender
F IG . 2.37 une fentre de Maya RTA avec son diteur dinteraction en bas gauche. [A LIAS 01]
Maya RTA (Maya Real-Time Author) [A LIAS 01] permet de construire des applications 3D interactives dans le format Shockwave 3D, en connectant des senseurs et des actions (gure 2.37). Les
senseurs ragissent de faon binaire des proprits de la scne (collision, distance entre objets) ou
des dispositifs dentre (touche du clavier, bouton de la souris). Connectes aux senseurs, les actions
dclenchent des commandes de haut niveau (dmarrer une animation, jouer un son, changer de camra). Un senseur peut galement dclencher plusieurs actions en parallle ou en squence. Lditeur
de Maya emploie un modle vnementiel binaire trs simple, qui ne permet de dcrire que des relations directes (mappings) entre des contrleurs deux tats et des actions.
La fentre interactive de Blender [ROOSENDAAL & WARTMANN 03] emploie un modle lgrement
plus sophistiqu base de briques logiques. Les briques logiques comprennent les senseurs et les
actuateurs (lquivalent des actions de Maya RTA), ainsi quun troisime type de brique, les contrleurs. Ces derniers comprennent les oprateurs logiques et les scripts Python. Ils sinsrent entre les
senseurs et les actuateurs, et permettent de dcrire des conditions plus complexes pour les dclenchements dactions. Tout comme lditeur de Maya, les briques logiques de Blender sont essentiellement
bases sur des associations dactions o les vnements sont binaires. Laccs des donnes comme
les coordonnes de la souris est possible, mais ncessite lcriture de scripts.
Les ots de donnes de Virtools Dev
Un grand nombre doutils de construction dapplications interactives 3D reposent sur des modles
ot de donnes (voir section 2.6.2 page 75). Ce paradigme se prtant bien une programmation
visuelle, certains dentre eux proposent en complment un diteur interactif. Cest le cas par exemple
de WorldUp [S ENSE 8 03], Cult3D Designer [C YCORE 03] ou Virtools Dev [V IRTOOLS 01].
Le modle base de ots de donnes de lditeur de Virtools Dev [V IRTOOLS 01] est parmi les
86
F IG . 2.38 Un jeu daction programm avec lditeur de comportements de Virtools Dev.
87

plus sophistiqus sur le march. Virtools comporte un grand nombre de scripts comportementaux
prdnis, graphiquement reprsents par des blocs de construction. Associ un objet 3D, un script
comportemental permet par exemple danimer ou de contraindre ses mouvements. Tout comme les
briques logiques, chaque bloc comprend des entres et des sorties dactivation (contrle), mais peut
galement traiter des donnes types travers des paramtres dentre et paramtres de sortie. Les
blocs peuvent tre librement interconnects travers leurs entres/sorties et leurs paramtres pour
dcrire des comportements complexes. Les blocs contrleur (souris, clavier, joystick) permettent
dajouter de linteraction. Les blocs sont composables, et de nouveaux blocs atomiques peuvent tre
dnis sous forme de scripts en C++ ou de DLLs.
La gure 2.38 page prcdente montre un jeu daction programm avec Virtools. La fentre de jeu
est visible dans la partie suprieure gauche de la fentre, la structure de la scne apparat dans la partie
suprieure droite, et une partie du script dcrivant le contrle du vaisseau est visualise en bas. Ce
script emploie quatre blocs Key Event (gauche, droite, bas, haut) dont deux sont visibles ici. Chacun
de ces blocs est connect un bloc Variate Value qui, partir des paramtres de dplacement du
vaisseau (vitesse, acclration, direction), met des messages vers la partie infrieure du script qui se
charge de calculer puis dappliquer les transformations gomtriques sur lobjet.
Flots de donnes et machines tats de VRED
F IG . 2.39 Le dplacement dun objet 3D dcrit avec VRED [JACOB et al. 99].
VRED [JACOB et al. 99] est un diteur dinteraction exprimental qui sappuie sur un modle mixte
ot de donnes et ot de contrle pour dcrire les aspects la fois continus et discrets de linteraction. Son objectif est dincorporer les deux aspects dans le mme langage visuel dans le but de
dcrire facilement des techniques Non-WIMP . Il a t principalement employ pour spcier des
techniques dinteraction simples de ralit virtuelle.
88

VRED se compose dun diteur de ot de donnes pour dcrire des relations entre des grandeurs
continues, et dun diteur de diagrammes de transition dtats (voir section 2.3.1 page 44) pour dcrire
des modes. Chaque mode active des liens et en dsactive dautres dans le ot de donnes.
La gure 2.39 page ci-contre illustre une technique simple de manipulation dobjets dans une
application de ralit virtuelle, o une main dont la position est capte par un Polhemus dplace
des objets lorsquun bouton est maintenu enfonc (le picking nest pas reprsent). Dans le ot de
donnes (en haut), les ellipses reprsentent des valeurs continues (avec en-dessous leur type) et les
rectangles des transformations (avec en-dessous leurs conditions dactivation). La position fournie par
le Polhemus est lie celle dun curseur, elle-mme lie celle de lobjet. Le premier lien est statique
et le le second est uniquement actif dans le mode DRAGGING. La prise en charge des vnements
discrets de type bouton est dcrite par un diagramme de transition dtats (en bas), qui active le mode
DRAGGING tant que le bouton est enfonc.
Discussion sur les apports et les limites des diteurs 3D
Les modles base de senseurs et de canaux des diteurs 3D offrent une vision dtaille des
entres, qui permet dexploiter au mieux les dispositifs tendus. Ils sont par consquent beaucoup
plus ouverts aux dispositifs non-standards que les outils ddition 2D, et permettent de dcrire des
interactions qui emploient des entres extrmement riches. Les modles de connexion nafs comme
ceux de Maya RTA et de Blender offrent par contre un pouvoir dexpression assez faible, qui ne permet
pas de dcrire des comportements complexes.
Les diteurs de type VirTools Dev ont combl ce manque en exploitant le paradigme de dataow. VirTools Dev, de par son grand pouvoir dexpression, a pu servir dvelopper des jeux vido
commerciaux tels que Syberia [M ICRODS 02]. Dautres outils 3D emploient des diteurs de comportements similaires [S ENSE 8 03, C YCORE 03]. Le principal inconvnient de ces outils est leur complexit
dutilisation qui requiert des comptences qui sont proches de celles du programmeur.
Les diteurs 3D du commerce sont uniquement adapts la description dinterfaces 3D, o les attributs gomtriques des objets dune scne sont contrls plus ou moins directement par lutilisateur.
Si ce type dinterface est trs strotyp, les diteurs 3D sont peu adapts au contrle dapplications
2D, o les objets du domaine et les techniques dinteraction sont plus varis et souvent plus complexes.
VRED est une approche exprimentale qui constitue lune des rares tentatives visant rconcilier
les aspects ot de donnes et les rassembler dans le mme langage visuel. Cependant, il emploie deux
notations bien diffrentes et oblige pour chaque aspect de linteraction opter pour un modle continu
ou vnements. Les difcults lies linterprtation dun ot de donnes dynamique ont en outre
t voques par lauteur lui-mme, qui propose dencapsuler un ot de donnes dans chaque tat du
diagramme de transition et dtendre lditeur avec un paradigme dinterfaces zoomables. Outre les
difcults de lecture que cette nouvelle approche peut poser, cet diteur na pas encore vu le jour.
2.7.4
Conclusion
Les diteurs graphiques dinteraction constituent un pas en avant non ngligeable vers des interfaces graphiques congurables en entre. Malheureusement, il existe encore une trop grande sparation entre les diteurs 2D qui sont puissants mais possdent une vision vnementielle strotype
des entres, et les diteurs 3D qui ont une vision gnrique et bas-niveau des dispositifs dentre mais
89

ne permettent pas de dcrire des techniques dinteraction complexes. En outre, les premiers (except
WhizzEd) reposent en gnral sur des modles base de contraintes, ce qui les rend plus adapts la
description de comportements gomtriques qu des ux dentre.
Nous remarquons galement que les diteurs sont soit "orients-dition", soit "orients-modle".
La premire approche consiste, comme Maya RTA, construire un diteur interactif destin lutilisateur nal employant des mtaphores simples, mais reposant sur un modle simpliste de linteraction,
avec un faible pouvoir dexpression. La seconde approche consiste, comme VRED, btir un diteur
visuel par-dessus un modle existant, en gnral puissant, mais sans se focaliser sur lutilisabilit et
sans prendre le temps dimplmenter les techniques dinteraction et de visualisation appropries.
Pour nir, les outils ddition 2D comme 3D semblent tout ignorer des techniques dinteraction
avances telles que linteraction gestuelle, les outils transparents ou la reconnaissance vocale. Un
outil de conguration de linteraction en entre gagnerait sinspirer des approches employes dans
les deux domaines, tout en fournissant un support pour ces techniques dinteraction non standards.
2.8 Synthse
Vu la grande complexit des applications interactives, des modles ont t rapidement proposs
an de sparer les diffrents aspects fonctionnels et structurels des interfaces, et de guider leur conception et leur implmentation. Les premires approches de type vertical comme Seeheim ou Arch dcomposent linterface en plusieurs couches dabstraction, de lutilisateur jusquau noyau fonctionnel.
Malgr leurs apports thoriques, ces modles sont peu dtaills et encapsulent linteraction en entre
et en sortie bas-niveau dans une seule entit monolithique. An de rendre mieux compte des caractristiques des interfaces modernes et du paradigme de programmation oriente-objet, les approches
horizontales agents comme MVC, PAC et les interacteurs formels dcomposent les interfaces en
rseaux dentits de mme nature. Les entres, disperses parmi les agents, restent cependant connes dans des objets monolithiques et ne sont toujours pas dcrites. Elles restent en outre confondues
avec les sorties, hormis dans le modle MVC qui spare les entres des aspects graphiques mais sans
expliquer comment mettre en uvre cette sparation. Le modle des interacteurs de CNUCE suggre nanmoins des ux dentre qui transitent dun agent lautre pour tre converties en donnes
abstraites interprtables par lapplication.
Deux types de modles se sont spciquement attachs dcrire linteraction en entre bas-niveau.
Les modles logiques de dispositifs comme GKS et PHIGS, dont lobjectif est lindpendance vis-vis du matriel, divisent les dispositifs dentre en six classes. Les tches dinteraction de Foley
sparent de faon similaire les tches applicatives en six classes gnriques. Malgr leurs apports
pratiques, et en dehors du fait quelles ont t construites pour des besoins dinteraction qui ne sont
plus les mmes aujourdhui, ces classications sont excessivement simplicatrices au vu de la grande
varit des dispositifs (pour les premires) et des tches existantes (pour les secondes). Les modles
physiques de Buxton et Card mettent au contraire laccent sur la spcicit de chaque dispositif. Le
premier propose une taxonomie base sur des caractristiques pragmatiques (nombre de dimensions,
proprits physiques captes) et le second dcrit un dispositif dentre comme une composition de dispositifs lmentaires qui convertissent des grandeurs physiques en valeurs numriques. Ces modles
sont utiles pour comparer diffrents dispositifs ou en concevoir de nouveaux, mais nont eu que peu
dimpact sur les applications et les outils de dveloppement, o lon recherche surtout la gnricit et
la portabilit. Seules les librairies daccs bas-niveau aux dispositifs emploient des reprsentations de
90
2.8. SYNTHSE
nature physique, o chaque dispositif concret est habituellement expos comme une combinaison de
dimensions continues et discrtes.
Aujourdhui, le dveloppement des applications interactives repose exclusivement sur les botes
outils graphiques, qui grent la majeure partie de linteraction en entre de faon interne. Les botes
outils conventionnelles, cbles pour une utilisation exclusive et strotype de la souris et du clavier,
sont les principales responsables de la rigidit des applications en termes dentres. Des botes outils
WIMP avances comme Subarctic et Garnet/Amulet ont t proposes an de dcrire la gestion des
entres et linteraction standard de manire claire et extensible, mais lintgration de nouvelles techniques dinteraction ncessite en pratique des remaniements importants, et les dispositifs non-standard
sont ignors. Un certain nombre de botes outils plus spcialises prennent en charge des paradigmes
dinteraction Post-WIMP spciques, telles les botes outils gestuelles (Satin), parfois en exploitant
des entres non-standard comme lextension multimodale de Subarctic (entres de nature ambigu)
ou les botes outils multi-pointeurs (MMM, Bimanual Whizz et MID). Le modle dinteraction
base doutils transparents a galement donn lieu un remaniement de la bote outils MMM et au
dveloppement de larchitecture CPN2000. Ces botes outils emploient toutes cependant un modle
vnements conventionnel adapt des dispositifs de type spcique, et exploitent ces dispositifs de
manire efcace mais ge.
Les botes outils spcialises dans linteraction tangible (Phidgets) et la sensibilit au contexte
(Context Toolkit), peu nombreuses vu la jeunesse de ces paradigmes, offrent une prise en charge souple
mais de bas-niveau de senseurs et dispositifs simples de nature htrogne. Le domaine de linteraction
3D, plus mr, offre depuis un certain temps des botes outils permettant de connecter librement des
canaux individuels de dispositifs dentre sophistiqus des structures abstraites, habituellement
travers des ots de donnes (UGA, Inventor, TBAG, WorldToolkit). Ces structures sont cependant
toujours des attributs dobjets 3D, les dispositifs pris en charge sont tous des priphriques 3D, et les
techniques dinteraction quil est possible de dcrire sont bien moins varies que celles de la 2D. Le
modle ot de donnes sur lequel elles reposent offre nanmoins une grande libert dexpression
et se prtent bien des outils ddition visuelle (Maya RTA, Blender, Virtools Dev) qui rendent la
spcication de linteraction en entre en partie accessible des non-programmeurs.
Le domaine de linteraction 2D a galement produit des diteurs de comportements, mais qui
reposent pour la plus grande part sur des modles contraintes peu adapts la description de linteraction en entre bas-niveau (Thinglab, Fabrik). Seul lditeur WhizzEd a su exploiter la grande
souplesse offerte par les ots de donnes, initialement pour construire des interfaces animes, puis
pour dcrire certains mcanismes propres linteraction bimanuelle. Notons que des systmes transitions (automates tats nis, rseaux de Petri) ont t galement employs pour dcrire linteraction
de manire visuelle ou non : Petshop, par exemple, permet de construire interactivement des spcications ICO base de rseaux de Petri. Cependant, les systmes orients-contrle que ces formalismes
se proposent de dcrire caractrisent mieux les techniques WIMP que les interactions Post-WIMP,
essentiellement amodales et fortement concurrentes.
Pour rsumer simplement, aucun modle et aucun outil ce jour ne prend en compte ladaptabilit
en entre sous ses trois angles. Deux types dapproche ont t proposes pour amliorer la contrlabilit : celle des botes outils Post-WIMP, qui consiste implmenter un modle dinteraction efcace
pour un certain type dentres, et celle des botes outils 3D, qui consiste proter de manire simple
de la richesse des dispositifs dimensions multiples. La voie vers la congurabilit a t ouverte par
les diteurs dinteraction 2D et surtout 3D. Aucun de ces diteurs, cependant, ne permet dexploiter
des techniques dinteraction Post-WIMP sophistiques, ni de tirer parti de dispositifs multiples de
91

nature htrogne (par exemple, geste, parole et dispositifs 3D). Enn, ni les outils de programmation
ni les diteurs interactifs noffrent de solution adapte linteraction avec des entres appauvries.
Le problme de ladaptabilit en entre peut nanmoins tre rsolu en approfondissant les approches existantes et en tirant parti de leurs avantages respectifs. Dans le chapitre suivant, nous introduisons une mtaphore pour dcrire des interfaces intgralement congurables en entre, et nous
verrons comment cette mtaphore mne tout naturellement un modle ot de donnes, similaire
ceux des outils 3D ou de WhizzEd. Nous montrerons galement en quoi les particularits de notre
modle et de nos outils en font une solution particulirement efcace au problme de ladaptabilit en
entre.
92
Chapitre 3
Introduction au modle des

congurations dentre
Sommaire
3.1
3.2
3.3
3.4
3.5
Introduction . . . . . . . . . . . . . . . . . . .
Le paradigme des dispositifs en cascade . . . .
3.2.1 La mtaphore de la connexion logicielle .
3.2.2 Points dentre . . . . . . . . . . . . . .
3.2.3 Adaptateurs . . . . . . . . . . . . . . . .
3.2.4 Dispositifs gnraliss . . . . . . . . . .
3.2.5 Cascades . . . . . . . . . . . . . . . . .
Les systmes ractifs . . . . . . . . . . . . . . .
3.3.1 Systmes ractifs et conversationnels . .
3.3.2 Pour une gestion ractive de linteraction
3.3.3 Le modle du synchronisme parfait . . .
Les congurations dentre . . . . . . . . . . .
3.4.1 Les briques de base . . . . . . . . . . . .
3.4.2 Les notions essentielles . . . . . . . . . .
3.4.3 Aperu du modle dexcution . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . .
93
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
94
94
94
95
96
97
98
99
99
100
100
101
101
104
106
107
CHAPITRE 3. INTRODUCTION AU MODLE DES CONFIGURATIONS DENTRE
3.1 Introduction
Ladaptabilit en entre requiert une grande indpendance entre les dispositifs physiques et les
applications. Notre objectif premier est par consquent de dcoupler les dispositifs dentre de lapplication, an que le dveloppeur ou lutilisateur puisse employer nimporte quel dispositif dentre
la place des dispositifs standards, ou en plus de ceux-ci. Sur un systme entirement adaptable en
entre, celui-ci devrait idalement disposer dun outil lui permettant de connecter (et dconnecter)
librement ses dispositifs dentre lapplication.
Nous avons choisi de baser notre approche sur ce principe de connexion, car il constitue une
mtaphore simple et naturelle aussi bien pour lutilisateur que pour le dveloppeur.
Dans un premier temps, nous motivons et dveloppons cette mtaphore pour aboutir un paradigme de dispositifs en cascade, qui constituera la base de notre approche. Dans un deuxime temps,
nous prsentons brivement le paradigme des systmes ractifs qui a inspir notre modle dexcution. Enn, nous prsentons notre modle des congurations dentres, qui concrtise et combine ces
deux approches.
3.2 Le paradigme des dispositifs en cascade

Dans cette section, nous introduisons le paradigme des dispositifs en cascade, en dveloppant le
principe de la connexion logicielle de dispositifs. Ce paradigme suppose dabord deux types dentits :
les dispositifs dentre physiques et lapplication. Nous serons par la suite amens introduire quatre
autres notions essentielles : les points dentre, les adaptateurs, les dispositifs gnraliss, et enn les
cascades.
3.2.1
La mtaphore de la connexion logicielle
F IG . 3.1 La mtaphore de la connexion : les dispositifs dentre sont connects une application pour tre
utiliss.
94
3.2. LE PARADIGME DES DISPOSITIFS EN CASCADE

Le paradigme de connexion logicielle de dispositifs (gure 3.1 page prcdente) drive de la
notion plus familire de connexion physique : lorsque nous voulons utiliser un dispositif, nous le
connectons. Dans le monde quotidien, la plupart des dispositifs lectriques ou lectroniques ncessitent dtre branchs sur le secteur (fer repasser, chargeur de tlphone portable), ou sur un autre
dispositif (casque audio sur une chane hi-, guitare lectrique sur un amplicateur) pour tre utiliss.
Dans le deuxime cas, la connexion sert tablir un change dinformations entre un dispositif mobile
usage humain, et un dispositif xe qui lui est li.
Il est intressant de noter que lorsque lchange dinformations se fait du dispositif humain vers le
dispositif xe, il est possible dtablir un parallle avec linteraction instrumentale dans le monde
rel [B EAUDOUIN -L AFON 97]. Dans ce cas particulier de manipulation instrumentale, lopration de
connexion initie lutilisation dun instrument (le dispositif mobile) tout en dsignant lobjet du monde
sur lequel il va agir (le dispositif xe). Cest le cas lorsque lon branche une guitare sur un amplicateur, ou un dispositif de commande sur certains appareils industriels ou domotiques. Mais cela peut
galement sappliquer lorsque lon branche un dispositif dentre sur un ordinateur (dautant plus
que les progrs technologiques autorisent dornavant des connexions chaud de dispositifs dentre
[USB/HID 01]).
F IG . 3.2 Faade dun amplicateur de guitare lectrique (1959SLP de chez Marshall) comportant quatre
entres distinctes. Chaque entre contrle un type de son particulier en termes de gain et de brillance.
En outre, diffrents branchements possibles sur un dispositif xe peuvent multiplier le nombre

dobjets manipulables. Les diffrentes entres de certains amplicateurs de guitare permettent ainsi
de manipuler plusieurs sons (gure 3.2). Mais malheureusement, les systmes informatiques actuels
ne permettent quune utilisation unique et globale dun dispositif (voire zro, sil nest pas reconnu
par les applications). Le paradigme de connexion logicielle permet daller plus loin dans ce domaine,
en passant virtuellement dun objet manipulable unique (lordinateur) des objets multiples de granularit plus ne (les applications et leurs diffrentes fonctionnalits). La connexion logicielle tend
la connexion physique des dispositifs dentre, tout en se basant sur le mme paradigme.
3.2.2
Points dentre
Tout logiciel interactif possde un certain nombre de besoins en termes dentre, ou points dentre : ce sont des donnes qui sont fournies par lutilisateur. Il existe plusieurs manires de dcrire ces
points dentre indpendamment des dispositifs. Lune de celles-ci, que nous utiliserons temporairement pour les besoins de cette introduction, consiste les identier comme autant de tches dinteraction au sens de Foley [F OLEY et al. 84]. Pour rappel, ces tches dinteraction sont essentiellement des
types de donnes.
Ainsi, un logiciel de traitement de texte pourra avoir besoin de donnes de type Position pour
spcier lemplacement du point dinsertion, et de donnes de type Text pour insrer du nouveau
texte. Il comportera ainsi deux points dentre. Si le logiciel gre les annotations, il pourra galement
95
Position
(x,y)
Point
dinsertion
Text
(string)
Stroke
n
(x,y)
Annotations
F IG . 3.3 Les trois points dentre de lapplication de traitement de texte, dcrits comme des tches
dinteraction de Foley.
dclarer un point dentre supplmentaire de type Stroke (gure 3.3).

Chaque point dentre dnit une destination de connexion possible pour un dispositif dentre.
Mme si dans les applications classiques les points dentre de type Text et Position sont invariablement connects un clavier et une souris, les tches dinteraction sont thoriquement indpendantes
des dispositifs dentre. Dans la section suivante, nous verrons quelques exemples de connexions
standards et alternatives.
3.2.3
Adaptateurs
Position
(x,y)
Contrle du
mouvement
Point
dinsertion
Scannage
Text
(string)
Reconnaissance
vocale
Stroke
n
(x,y)
Annotations
F IG . 3.4 Diffrentes manires de connecter des dispositifs dentre une application de traitement
de texte.
La gure 3.4 illustre, laide de connexions, diverses mthodes de saisie possibles pour notre logiciel de traitement de texte. Du ct gauche sont reprsents un certain nombre de dispositifs dentre
96
3.2. LE PARADIGME DES DISPOSITIFS EN CASCADE

potentiellement utilisables (souris, manette, bouton deux tats, clavier, microphone, tablette) et du
ct droit les trois points dentre (tches dinteraction de Foley) vers lapplication. Seules quelquesunes parmi toute les possibilits de connexion sont reprsentes sur la gure.
Certaines connexions font intervenir des utilisations non triviales des dispositifs dentre (par
exemple, mettre des positions avec un clavier). Les donnes mises par le dispositif et celles reues
par le point dentre tant incompatibles, ces couplages ncessitent lutilisation de botes adaptatrices,
ou adaptateurs. Chaque adaptateur traite les donnes en provenance dun dispositif pour les rendre
compatibles avec un point dentre donn. Ils peuvent ventuellement possder un tat et produire des
retours (graphique, sonore, etc...) qui ne sont pas reprsents sur la gure.
Il est intressant de remarquer que chacun de ces adaptateurs dcrit une technique dinteraction.
Ainsi, lutilisation dune manette ou dun clavier comme dispositifs positionnels implique lutilisation dune technique de contrle du mouvement ou contrle du second ordre (lutilisateur contrle la
vitesse et non la position du pointeur). Des techniques danimation (dites de scannage) sont utilises
pour spcier des positions avec des dispositifs daccessibilit deux tats, tels que les boutons. De
mme, pour pouvoir fournir du texte, le signal dun microphone ncessite dtre interprt travers
un module de reconnaissance vocale.
Sur la gure, par souci de simplicit, les connexions standards ne comportent pas dadaptateurs.
En pratique, certaines dentre elles peuvent ncessiter des traitements de base (telles que des remises
lchelle pour les dispositifs de pointage) ou un retour graphique simple (pointeur, par exemple).
Les donnes brutes du clavier ncessitent galement dtre traites (le cas du clavier sera dvelopp
un peu plus loin).
3.2.4
Dispositifs gnraliss
Nous avons introduit trois types dobjets pour dcrire des exemples pratiques de connexion de
dispositifs : les dispositifs dentre, les adaptateurs, et les points dentre vers lapplication. Nous
allons unier ces trois entits.
Remarquons dabord quil est possible de connecter deux types dobjets un point dentre : un
dispositif ou un adaptateur. Or du point de vue de lapplication, un adaptateur se comporte exactement
comme un dispositif dentre. Par exemple, ladaptateur "contrle du mouvement" fournit des donnes
comparables celles dune souris.
Notons galement quun point dentre peut galement se comporter comme un dispositif dentre. Ainsi, des positions peuvent gnrer du texte travers un clavier graphique. Des tracs peuvent
galement produire du texte travers un module de reconnaissance de lcriture (gure 3.5 page suivante).
Chaque dispositif dentre, adaptateur et point dentre peut jouer le rle de dispositif. Nous regroupons par consquent ces objets sous le terme gnrique de dispositifs gnraliss, ou plus simplement dispositifs. Les dispositifs systme tels que le clavier ou la souris, sont des cas particuliers de
dispositifs. Les points dentre vers une application seront galement appels dispositifs dapplication.
97
Position
(x,y)
Point
dinsertion
Clavier
graphique
Text
(string)
Reconnaissance
de lcriture
Stroke
n
(x,y)
Annotations
F IG . 3.5 Exemples de points dentre jouant le rle de dispositifs
3.2.5
Cascades
Nous avons vu jusquici deux types de connexions : les connexions directes et les connexions avec
adaptateur unique. Dans les systmes interactifs cependant, linterprtation des actions de lutilisateur
se fait en gnral travers une srie de traitements successifs. Cette srialisation rpond souvent au
besoin daccder un dispositif sur plusieurs niveaux dabstraction. Elle apporte en outre lavantage
dune modularit accrue et dune meilleure structuration. Le mcanisme de gestion du clavier, que
nous tudierons dans cette section, fournit un exemple de traitement en cascade.
Lexemple du clavier
A chaque fois quune touche dun clavier est appuye, on peut considrer quelle passe dun tat
faux un tat vrai. Ces changements dtats sont traduits par le clavier en codes touches, qui leur
tour sont convertis en symboles dont la combinaison est interprte comme une chane de caractres
dans lditeur de texte.
Clavier
Gnrateur
de codes touches
Gnrateur
de symboles
Gnrateur
de caractres
Texte
F IG . 3.6 Cascade de dispositifs entre le clavier et lditeur de texte
Cette srie de traitements peut tre reprsente par une chane de dispositifs allant du dispositif
concret au dispositif de lapplication (gure 3.6) [F EKETE & D RAGICEVIC 00]. Chaque adaptateur convertit les donnes quil reoit dans son format propre. Le gnrateur de codes touches associe chaque
touche du clavier un code positionnel. Le gnrateur de symboles traduit les codes touches en symboles, selon la langue du clavier. Enn, le gnrateur de caractres traduit les symboles en chanes
de caractres, selon une mthode dentre spcique. Il permet par exemple de composer des lettres
98
3.3. LES SYSTMES RACTIFS

accentues telles que , ou de produire nimporte quel caractre spcial en utilisant la touche Alt et
les touches du pav numrique.
Le feedback en cascade
F IG . 3.7 Cascade de dispositifs et de feedback dans une technique de dlement de document.
La gure 3.7 illustre un exemple de traitement en cascade dans une technique de dlement de
document : les donnes en provenance dun dispositif souris concret sont converties en coordonnes
cran pour contrler un dispositif curseur, puis encore traites pour dplacer une barre de dlement.
Ici, lajout de deux dispositifs virtuels , lutilisateur et le document permet de mettre en vidence
un ux dinformations implicite : lutilisateur contrle la souris, le curseur met des informations visuelles en destination de lutilisateur, et la barre de dlement (ici, le point dentre vers lapplication)
manipule un document (cach dans lapplication) qui met son tour des informations visuelles vers
lutilisateur.
Le ux dinformations implicite mis ici en vidence expose diffrents niveaux de feedback vers
lutilisateur. Il montre comment une cascade explicite de dispositifs peut correspondre une cascade
implicite de feedback oriente en sens inverse.
3.3 Les systmes ractifs

Le paradigme des systmes ractifs nous vient des langages comme Esterel [B ERRY et al. 87, B ERRY 99]
ou Lustre [H ALBWACHS et al. 91], dans lesquels la propagation de linformation est conceptuellement
instantane. Dans cette section, nous dcrivons brivement ce paradigme et motivons nos choix quant
ce modle dexcution.
3.3.1
Systmes ractifs et conversationnels
Les systmes informatiques qui interagissent avec lenvironnement peuvent tre distingus en
deux classes [B ERRY 89] :
Les systmes conversationnels 1 : Dans ces systmes, le client met des requtes vers lordinateur. Celui-ci choisit sil doit ou non y rpondre, ainsi que le moment o il doit fournir la
rponse. Dans ces systmes, lordinateur est matre de linteraction, et le client attend dtre
servi. Dautre part, les choix internes de lordinateur font que ces systmes sont le plus souvent
1 Dans
la publication originale, Berry qualie ces systmes dinteractifs. Pour viter toute confusion avec notre notion
plus gnrale de systmes interactifs, nous avons choisi dutiliser la place le terme conversationnel.
99

non dterministes. Les exemples incluent les systmes dexploitation, les bases de donnes, les
systmes rseau.
Les systmes ractifs ou systmes rexes : Dans ces systmes, cest lenvironnement qui est
matre de linteraction : le rle de lordinateur est de ragir de faon continue aux stimuli externes en produisant des rponses instantanes. On trouve ces systmes dans les domaines o le
client ne peut pas attendre (systmes temps rel), comme le contrle de processus industriels,
les systmes embarqus, les pilotes de dispositifs, ou le traitement de signal. Le dterminisme
est une proprit souvent dsirable pour ces types de systmes : les rsultats mis doivent dpendre uniquement des informations reues et de leur enchanement temporel.
Les systmes ractifs sont des programmes qui ragissent lenvironnement la vitesse de lenvironnement, alors que les autres systmes ragissent leur vitesse propre. Les systmes conversationnels sont asynchrones et souvent non-dterministes, et les systmes ractifs sont parfaitement
synchrones et souvent dterministes [B ERRY 00].
3.3.2
Pour une gestion ractive de linteraction
La plupart des systmes comportent la fois des lments conversationnels et ractifs. Par exemple,
le pilotage dun avion est ractif, alors que la communication avec le sol est conversationnel. Cest le
cas galement des systmes interactifs.
Certains services du systme dexploitation et du systme de fentrage, comme la gestion du curseur de la souris ou le dplacement des fentres, sont minemment ractifs. Au niveau de lapplication,
il existe galement des lments plus ractifs que dautres. Dans une application de dessin vectoriel,
par exemple, le rafchage dun dessin complexe peut prendre du temps, et seffectue selon un mode
conversationnel. Il est par contre souhaitable que le retour graphique associ aux dplacements dobjets soit ractif.
Le modle vnements classique, bien quessentiellement conversationnel, est souvent utilis
pour dcrire lintgralit du comportement dune application interactive. Nous pensons cependant
que les parties intrinsquement ractives dune application interactive, en particulier celles relatives
la gestion des entres, gagnent reposer sur un modle ractif. La le vnements ny est pas
ncessaire, elle est peu adapte la description de comportements ractifs, et ne donne aucune garantie
en termes de temps rel.
3.3.3
Le modle du synchronisme parfait
Les langages ractifs sont bass sur le modle du synchronisme parfait, dans lequel les processus
sont capables, au niveau conceptuel, de sexcuter et dchanger de linformation en un temps nul
[B ERRY 00]. Ce modle est quivalent au modle zro-dlai des circuits lectroniques (gure 3.8
page ci-contre). Bien que ce paradigme soit peu naturel pour des programmeurs classiques, cest un
standard pour les thoriciens du contrle, les concepteurs de circuits lectroniques, ou les utilisateurs
de contrleurs programmables.
Dans le paradigme ractif, un vnement est un signal. Du point de vue logiciel, un programme
ractif sexcute en une squence ininterrompue ditrations appeles ticks, qui sont des ractions aux
signaux dentre. Lhypothse du synchronisme parfait est vrie en pratique si les ractions sont
assez rapides pour quaucun signal provenant de lenvironnement ne soit perdu.
100
3.4. LES CONFIGURATIONS DENTRE
F IG . 3.8 Exemple de circuit synchrone, o linformation est propage de faon instantane [B ERRY 00].
Nous naborderons pas les dtails concernant les diffrents langages ractifs existants (pour plus
de dtails, le lecteur est invit lire [B ERRY 00]). Prcisons simplement quil en existe deux styles : les
langages impratifs et les langages ots de donnes. Notre modle dexcution sinspire du dernier.
3.4 Les congurations dentre

Le modle des congurations dentre est une concrtisation du paradigme des dispositifs en cascades et des systmes ractifs dcrits prcdemment. La bote outils ICON et son langage visuel,
dcrits dans le prochain chapitre, constituent une implmentation de ce modle. Nous prsenterons
ici le modle des congurations dentre, ses diffrentes briques de base et ses caractristiques principales.
Le modle des congurations dentre repose sur une infrastructure et des mcanismes concrets,
qui consistent principalement en un systme ots de donnes et un moteur ractif. Cette infrastructure et ces mcanismes sont dcrits par le modle ICOM (Input Conguration Model), indpendamment des aspects graphiques et architecturaux du modle que nous dcrivons ici. ICOM, dtaill en
annexe, dnit les aspects statiques (la structure) et dynamiques (le comportement en dition et en
excution) dune conguration dentre. Nous ne donnerons ici quun aperu gnral de son fonctionnement.
3.4.1
Les briques de base
Les quatres entits principales de notre modle sont les congurations dentre, les dispositifs, les
slots et les connexions.
Une conguration dentre (gure 3.9 page suivante) est un ensemble de dispositifs systme et de
dispositifs dapplication relis par des dispositifs utilitaires. Les premiers sont des objets fournis par
le systme, qui sont partags et qui reprsentent pour la plupart des dispositifs dentre concrets. Les
seconds sont des objets spciques fournis par lapplication. Les derniers sont des objets autonomes
fournis par une bibliothque et qui sont instanciables a volont.
Un dispositif (gure 3.10 page suivante) est une bote noire qui interagit avec son environnement
par lintermdiaire de canaux typs, appels slots. Sa fonction principale est de produire des valeurs
101
Configuration dentre
Dispositifs
Systme
Dispositifs
dapplication
Dispositifs
utilitaires
F IG . 3.9 Une conguration dentre dcrit une manire de relier des dispositifs systme des dispositifs
dapplication.
Slots de
sortie
Slots
dentre
Entres
implicites
Sorties
implicites
F IG . 3.10 Un dispositif, avec ses slots dentres ( gauche, en blanc) et ses slots de sortie ( droite, en noir).
102

en sortie en fonction des valeurs quil reoit en entre. Il peut galement dclarer un ensemble de
paramtres permettant de spcialiser son comportement.
any
double
int
boolean
string
object
null
entre
sortie
F IG . 3.11 gauche, un ou logique comportant deux boolens en entre et un boolen en sortie, et un

dispositif darrondi qui transforme un rel (double) en un entier. droite, les diffrents types de slots.
F IG . 3.12 Un dispositif possdant des slots nomms name, color.r, color.g, et color.b. Le slot color est
un slot composite. gauche, le dispositif dans sa reprsentation condense, droite dans sa version tendue.
Un slot est un tat du dispositif qui est accessible aux autres dispositifs. Ces derniers ont la possibilit dcrire sur le slot sil sagit dun slot dentre, ou de lire sa valeur sil sagit dun slot de
sortie (gure 3.10 page prcdente). Les slots possdent des types de donnes simples visibles dans
leur reprsentation graphique (gure 3.11). Par exemple, les slots boolens sont circulaires, les slots
entiers ont une forme triangulaire et les types indnis sont reprsents par un carr. Les slots peuvent
tre organiss de faon hirarchique par un mcanisme de nommage analogue aux chemins chiers
ou packages Java (voir gure 3.12).
F IG . 3.13 Exemples de connexions : le slot de sortie s comporte trois connexions et le slot dentre e comporte
une connexion. Les slots dentre ne peuvent comporter plus dune connexion.
Une connexion est un arc orient reliant un slot de sortie dun dispositif un slot dentre dun
autre dispositif (gure 3.13). Deux slots relis par une connexion partagent la mme valeur. Les
103

connexions multiples sont autorises sur les slots de sortie mais pas sur les slots dentre. En outre,
les connexions induisant des dpendances cycliques sont interdites.
3.4.2
Les notions essentielles
Nous prsentons ici quatre caractristiques importantes dICOM :

1. Le principe des entres/sorties implicites, qui permet dvoquer lasynchronisme, le non-dterminisme
et le feedback.
2. La composition, qui autorise des congurations plusieurs niveaux de granularit.
3. Les mcanismes de mutation, qui permettent de dcrire des dispositifs gnriques qui se spcialisent en fonction des connexions et des paramtres.
4. Les processeurs, permettant aux dispositifs de dcrire plusieurs comportements en excution
possibles.
Les entres/sorties implicites
Un dispositif opre sur ses slots dentre et de sortie mais peut galement communiquer avec
lenvironnement extrieur la conguration par des entres ou des sorties implicites. La prsence
dentres (resp. de sorties) implicites est graphiquement indique par la prsence dune encoche dans
le coin infrieur gauche (resp. droit) du dispositif (voir la gure 3.10 page 102).
Les entres implicites traduisent la rception de ux dinformations autres que ceux dcrits par
les connexions (par exemple, provenant de dispositifs concrets).
Les sorties implicites traduisent lmission dinformations vers dautres entits que les slots de
la conguration dentre (par exemple, lapplication interactive ou lcran).
Composition
Notre modle ne fait pas de distinction entre dispositifs dentre, de sortie ou de traitement. Cette
unication du concept de dispositifs permet notamment de rendre ces derniers composables : par
exemple, un dispositif dentre associ un dispositif de sortie est un dispositif comportant la fois
des entres et des sorties implicites. Deux entits entrent en jeu dans la composition : les slots externes
et les dispositifs composites.
F IG . 3.14 Une conguration dentre comportant trois slots externes.
104

Une conguration dentre peut comporter des slots externes (gure 3.14 page ci-contre), qui
sont des slots isols nappartenant aucun dispositif. Ces slots dnissent en quelque sorte une vue
extrieure pour la conguration.
F IG . 3.15 Un dispositif composite dni par sa conguration lle.
Un dispositif composite est un type particulier de dispositif uniquement dni par une congurationlle (gure 3.15). Chacun de ses slots correspond un slot externe de sa conguration-lle.
Lopration consistant regrouper un ensemble de dispositifs dans un dispositif composite (composition) et lopration inverse (dcomposition) sont dcrits en annexe, section A.4 page 204. La
dcomposition totale, laquelle nous faisons rfrence plus loin, consiste appliquer des dcompositions successives jusqu obtenir une conguration plate.
Dispositifs mutables
F IG . 3.16 Deux dispositifs mutables relis en srie. Le premier opre sur des rels ou sur des entiers en
fonction de ses connexions en entre. Le second adapte son type la fois en entre et en sortie.
Certains dispositifs gnriques sont capables de se spcialiser en fonction des valeurs prises par
leurs paramtres et des types des slots qui leur sont connects. Cette opration repose sur un mcanisme trs gnral nomm mutation, dcrit en annexe, section B.3 page 215. Une mutation consiste
en une modication du type dun ou plusieurs slots mutables du dispositif. Un slot mutable possde
un type concret et un super-type dcrivant les types concrets quil est susceptible davoir. Dans la reprsentation graphique dun slot mutable, le super-type entoure le type concret (gure 3.16). Certains
slots sont en outre dynamiques, cest--dire que leur prsence dpend du paramtrage du dispositif.
105

Les processeurs
Un processeur est un objet qui encapsule le comportement en excution dun dispositif. Plusieurs
types de processeurs peuvent tre associs un seul dispositif : un additionneur peut par exemple
dnir un processeur pour laddition dentiers, un pour laddition de rels et un autre pour la concatnation de chanes de caractres. Le processeur effectivement employ par ladditionneur au moment
de lexcution dpendra du type concret de son slot de sortie.
Lunique responsabilit dun processeur est de mettre jour la demande (cest--dire chaque
fois quil est dclench) les valeurs de ses slots de sortie en fonction des valeurs de ses slots dentre
(comme voqu prcdemment, un processeur peut galement communiquer avec lenvironnement).
3.4.3
Aperu du modle dexcution
Lancement
La phase de lancement est destine prparer la conguration lexcution. Elle comporte plusieurs tapes. Pour commencer, lexcution travaille aprs dcomposition totale de la conguration
dentre. Ensuite, tous les dispositifs de la conguration sont ouverts pour leur permettre de sinitialiser. Chaque dispositif retourne lorsquil est ouvert un processeur en fonction de sa paramtrisation
(valeur de ses paramtres et types concrets de ses slots mutables), ou le processeur nul lors dun chec
douverture.
Aprs avoir rcupr les processeurs, le systme cre un objet Valeur pour chaque slot de sortie
de la conguration, objet qui encapsule une valeur concrte (entier, boolen,...) et la partage avec
les slots dentre connects. Ces partages de rfrence autorisent en quelque sorte une propagation
instantane des valeurs travers les connexions. Pour nir, les processeurs sont tris topologiquement
en fonction du graphe de dpendances.
Lalgorithme du tick
Lalgorithme dexcution se dcompose en pas atomiques ou ticks. Durant un tick, les processeurs
sont parcourus dans lordre topologique et chacun dentre eux est dclench sil est de type actif
(cest--dire quil correspond un dispositif entres implicites), ou si au moins une de ses Valeurs
en entre comporte un signal. Le signal est un drapeau boolen dans lobjet Valeur qui est toujours
faux au dbut du tick. Lorsquun processeur dclench met explicitement jour une Valeur (la
nouvelle valeur concrte peut tre la mme), ce drapeau passe vrai pour que les processeurs qui en
dpendent puissent tre dclenchs.
Un tick consiste donc globalement dclencher les processeurs actifs (pour la plupart des dispositifs dentre) puis transmettre les mises jour au reste de la conguration. Lalgorithme dexcution
ractif (dcrit en annexe, section C.3 page 227) assure que tout changement est correctement propag
et que chaque processeur est activ seulement lorsque cest ncessaire, au plus une fois dans le tick.
Les processeurs tant tris topologiquement, la mise jour de la conguration est effectue en une
seule passe. Cet algorithme est simple et extrmement efcace.
106
3.5. CONCLUSION
3.5 Conclusion
Nous avons dcrit et motiv dans ce chapitre les principes gnraux dun modle dentre bas
sur le paradigme cascades de dispositifs. Ce modle emploie des mtaphores simples comme les
connexions et les adaptateurs, et il est facile apprhender aussi bien pour le concepteur que pour
lutilisateur.
Nous avons ensuite concrtis ce paradigme avec le modle des congurations dentres. Une
conguration dentre est un ensemble de dispositifs systme (modules qui dcrivent pour la plupart
des dispositifs dentre physiques) et de dispositifs dapplication (modules qui dcrivent les entits contrlables de lapplication) relis par des dispositifs utilitaires (modules qui peuvent tre vus
comme des adaptateurs ou des techniques dinteraction). Notre modle repose sur une architecture
ot de donnes claire et fonctionnelle (qui permet notamment de dcrire des modules composables
et capables de se spcialiser dynamiquement), et sur un modle dexcution ractif qui garantit une
raction immdiate aux actions de lutilisateur.
Dans les chapitres suivants, nous montrerons par des exemples comment ce modle permet de
dcrire la majeure partie des mcanismes en jeu dans la gestion des dispositifs dentre dans les
systmes interactifs existants, tout en amliorant la visibilit et la modularit de ces mcanismes.
Nous montrerons galement comment il peut servir dcrire de nouvelles techniques dinteraction.
Le prochain chapitre dcrit la bote outils en entre ICON (Input Congurator), dveloppe partir
des principes que nous avons voqus.
107
108
Chapitre 4
La bote outils dentres ICON

Sommaire
4.1
4.2
4.3
4.4
4.5
4.6
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les dispositifs dICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Les dispositifs systme . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Les dispositifs utilitaires . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Les dispositifs de bote outils graphique . . . . . . . . . . . . . . .
4.2.4 Les dispositifs dapplication . . . . . . . . . . . . . . . . . . . . . .
Programmation avec ICON . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Implmentation de nouveaux dispositifs . . . . . . . . . . . . . . . .
4.3.2 Initialisation dune conguration . . . . . . . . . . . . . . . . . . . .
4.3.3 Srialisation et descripteurs . . . . . . . . . . . . . . . . . . . . . .
Construction et dition de congurations dentre . . . . . . . . . . . . .
4.4.1 Lditeur de congurations . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Des congurations standard aux congurations hautement interactives
4.4.3 Congurations dentre pour laccessibilit . . . . . . . . . . . . . .
4.4.4 Les techniques dinteraction avances et novatrices . . . . . . . . . .
Distribution, contributeurs, et projets utilisant ICON . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
109
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
110
110
111
112
114
117
118
118
121
124
127
127
131
135
136
141
142
CHAPITRE 4. LA BOTE OUTILS DENTRES IC ON
4.1 Introduction
Nous avons dvelopp partir du modle des congurations dentre dcrit dans le chapitre prcdent une bote outils dentre , dans le but de valider et dafner ce modle dans un contexte
de dveloppement rel, qui comprend un langage de programmation et un systme interactif concret
(systme dexploitation et bote outils graphique).
Nous prsentons dans ce chapitre la bote outils dentre ICON (Input Congurator), dont lobjectif est de :
Proposer une implmentation concrte du modle des congurations dentre et du moteur
ractif ncessaire leur excution,
Offrir une bibliothque extensible de dispositifs systme et utilitaires prts lemploi permettant de construire et tester des exemples de congurations dentre,
Fournir des interfaces et des librairies permettant de dvelopper rapidement des dispositifs dapplication et de nouveaux dispositifs systme et utilitaires dans un paradigme de programmation
oriente objet, ainsi que des services comme la srialisation (persistance) des congurations
dentre,
Procurer aux dveloppeurs et aux utilisateurs moins experts un diteur interactif qui exploite
le modle visuel des congurations dentre et linstrumente par des techniques dinteraction
appropries.
Nous avons choisi dimplmenter cette bote outils avec le langage Java, principalement pour
sa portabilit et la notorit dont il bncie auprs des programmeurs dapplications. Nous avons
galement choisi de rendre Swing contrlable par des dispositifs dapplication gnriques que nous
nommerons dispositifs de bote outils graphique.
Nous dcrivons pour commencer des exemples de dispositifs systme, utilitaires, de bote outils
graphiques et dapplication, et afnons cette taxonomie dans le contexte dICON. Nous dcrivons dans
un deuxime temps trois notions propres limplmentation ICON, savoir linterface et les classes
abstraites de dispositifs, le mcanisme dinitialisation dune conguration avec passage du contexte,
et le principe des descripteurs employ pour la srialisation. Nous prsentons ensuite lditeur interactif de congurations dentre, et voquons par des exemples les diffrents types de techniques
dinteraction que nous avons pu dcrire. Enn, nous donnons avant de conclure des informations sur
la distribution, les contributeurs, et les projets utilisant ICON.
4.2 Les dispositifs dICON

Comme le modle des congurations dentre, ICON sappuie sur une classication des dispositifs
en dispositifs systme, dispositifs utilitaires et dispositifs dapplication, laquelle il ajoute un type
particulier de dispositif dapplication, les dispositifs de bote outils graphiques. La bibliothque de
dispositifs dICON comprend tous les types de dispositifs hormis les dispositifs dapplication, qui sont
sont dcrits par chaque application interactive.
110
4.2. LES DISPOSITIFS DIC ON
4.2.1
Les dispositifs systme
Un dispositif systme reprsente une ressource globale, en gnral un dispositif dentre physique.
Il est :
Partag : Plusieurs copies dun dispositif systme, si elles sont paramtres de la mme manire,
mettront les mmes donnes.
Volatile : un instant donn, un dispositif systme peut tre prsent ou non dans la bibliothque
dICON, selon la conguration matrielle et logicielle du systme hte. Lorsquune conguration dans
laquelle il est utilis est en cours dexcution, sa dure de vie est au moins celle de la conguration. Il
peut cependant disparatre entre deux excutions.
Laccs bas-niveau aux dispositifs

ICON repose sur un ensemble dAPIs dentre existantes an daccder aux dispositifs dentre.
Chacune de ces APIs dentre fournit une interface unie pour laccs aux informations et aux donnes produites par une classe spcique de dispositifs, dans un systme dexploitation donn.
ICON produit son tour une vision unie de ces classes de dispositifs. Chaque API dentre gre
par ICON gnre un ensemble de dispositifs systme dans la bibliothque de dispositifs. Lensemble
des dispositifs systme est variable, et est fonction de la conguration logicielle (pilotes installs) et
physique (dispositifs connects) du poste de travail.
La plupart des APIs dentre fournissent plusieurs niveaux daccs aux dispositifs, travers des
mcanismes spciques de traitement de donnes et dabstraction. Dans notre optique, le courtcircuitage de ces services par lutilisation exclusive des services bas-niveau est ncessaire une utilisation optimale des capacits inhrentes chaque dispositif dentre.
Bien quICON constitue une sur-couche aux APIs dentre, il reste lcart de toute abstraction
simplicatrice en prsentant une vision essentiellement bas niveau des dispositifs dentre. Le modle
de dispositifs base de canaux dICON autorise et mme encourage cette vision.
Les dispositifs systme existants
F IG . 4.1 Exemples de dispositifs systme (souris, clavier, tablette graphique et commande vocale).
111

Actuellement, ICON fournit sous les systmes Microsoft Windows laccs la souris (bas-niveau)
et au clavier (niveau bote outils), aux tablettes graphiques travers lAPI Wintab [P OYNER 96], aux
dispositifs de jeu et aux contrleurs isomtriques 3D travers lAPI DirectInput [M ICROSOFT 03 A], et
la reconnaissance vocale travers lAPI JavaSpeech [S UN 98] (la reconnaissance gestuelle galement
prise en charge, mais sous forme de dispositif utilitaire). Sous X Windows sont accessibles tous les
dispositifs implments par la XInput Extension [PATRICK & S ACHS 94]. Un dispositif systme particulier
nomm VirtualUser permet de rejouer des signaux pralablement entregistrs en sortie de dispositifs
systme. ICON comprend galement des dispositifs systme de sortie, permettant ainsi de jouer de la
musique sur des cartes son, ou faire de la synthse vocale. La bibliothque dICON est extensible, et
des dispositifs systme reposant sur dautres APIs dentre peuvent y tre ajoutes.
La gure 4.1 page prcdente montre des exemples de dispositifs systme tels quils apparaissent
dans ICON. Le premier dispositif, gauche, est une souris bas niveau, qui met des valeurs positionnelles relatives dx et dy. Contrairement aux coordonnes cran traditionnellement utilises dans les
systmes vnements, ces valeurs traduisent directement les actions effectues sur le dispositif physique. Elles peuvent ainsi tre interprtes indpendamment de toute notion de pointeur (et ne sont
pas, en particulier, contraintes aux bords de lcran).
Le second dispositif est un clavier qui met les changements dtat de chaque touche individuelle,
mais qui est galement capable dmettre des codes touche . La tablette graphique met des informations spciques chaque pointeur physique (stylet, gomme, souris,...) prsent sur tablette, ainsi
que des valeurs synthtiques de position, de pression et dorientation. Enn, le dispositif de commande
vocale met les chanes de caractres reconnues ou leur indice, conformment au vocabulaire spci
dans les paramtres du dispositif.
4.2.2
Les dispositifs utilitaires
Les dispositifs utilitaires sont les dispositifs de la bibliothque dICON qui ne sont pas des dispositifs systme. Ces dispositifs sont autonomes (chaque copie dun dispositif se comporte indpendamment des autres) et persistants (un dispositif utilitaire est toujours prsent dans la bibliothque
dICON, indpendamment de la conguration logicielle et matrielle du systme). Nous dcrivons
dans cette section les diffrents types de dispositifs utilitaires.
Les dispositifs de traitement
Un dispositif de traitement effectue essentiellement des transformations de donnes. Ils nont pour
la plupart pas dentres/sorties implicites et sont par consquent dterministes. Dautres se basent sur
un temps absolu, ce qui les rend non-dterministes (le temps nest pas explicite dans ICON et il nest
accessible que sous forme dentre implicite).
La bibliothque dICON comporte une trentaine de dispositifs de traitement qui comprennent les
oprateurs mathmatiques, les oprateurs logiques, les dispositifs de traitement de signal, les adaptateurs de type et de domaine, et les dispositifs pour le contrle conditionnel et le routage.
La gure 4.2 page suivante illustre quelques-uns de ces dispositifs. gauche, un dispositif daddition acceptant diffrents types (mutable) et un dispositif de transformation linaire paramtrable.
Ensuite sont reprsents deux oprateurs boolens, un dispositif passe-bas paramtrable, un adaptateur de types (cast) automatique et un chantillonneur temporel, et enn un passeur conditionnel
112
F IG . 4.2 Exemples de dispositifs de traitement dans ICON, avec les fentres de proprits des dispositifs
paramtrables.
et un intgrateur qui permet de transformer des valeurs relatives en valeurs absolues.

La plupart des dispositifs de traitement sont mutables, cest--dire quils se spcialisent suivant
les types de slots qui leurs sont connects ou en fonction de leur paramtrage. Cest le cas par exemple
du dispositif plus de la gure 4.2, qui est capable deffectuer des additions sur plusieurs types, ou du
dispositif typeAdapter, qui se spcialise selon les types qui lui sont connects en entre et en sortie.
Les dispositifs retour graphique
Les dispositifs retour graphique sont des dispositifs utilitaires qui produisent un afchage graphique an dmettre des informations vers lutilisateur (feedback). Ces dispositifs comportent des
sorties implicites, mais contrairement aux dispositifs systme, ils sont persistants car indpendants de
toute conguration logicielle. Concernant la conguration matrielle, nous supposons que dans les
systmes ICON un cran est toujours disponible. Dans le cas contraire (prise en compte de systmes
embarqus, par exemple), ces dispositifs appartiendraient la catgorie systme.
Les dispositifs retour graphique actuellement prsents dans ICON sont reprsents sur la gure 4.3 page suivante. gauche apparaissent les dispositifs dafchage de donnes brutes, essentiellement utiliss pour le dbogage de congurations. Le premier afche lhistorique des donnes
quil reoit sur la sortie standard. Le second afche ses dernires valeurs reues dans une fentre de
dialogue.
Les dispositifs suivants animent des objets graphiques en incrustation (overlay) par-dessus les
autres lments de lcran. Le dispositif curseur permet danimer un pointeur en fonction des positions en coordonnes cran quil reoit, et comporte galement des slots boolens destins recevoir
et transmettre des tats de boutons. Ce dernier aspect lui confre un rle de dispositif virtuel. La fentre de proprits de ce dispositif, reprsente sur la gure, offre le choix entre plusieurs pointeurs
prdnis. Chaque copie dun dispositif curseur est autonome (hormis les recouvrements visuels), ce
qui autorise les curseurs multiples.
Les deux derniers dispositifs offrent des retours graphiques similaires au curseur, bien que plus
113
F IG . 4.3 Dispositifs retour graphique dans ICON.
avancs : le dispositif toolglass permet danimer une barre doutils semi-transparente [B IER et al. 93],
et le dispositif quikwrite permet de contrler un diteur de texte avec uniquement un pointeur. Ces
dispositifs, qui dcrivent galement des techniques dinteraction, sont dcrits plus en dtail par la
suite, dans la section 4.4.4 page 139.
Les afchages en incrustation sont actuellement implments au niveau de la bote outils Swing,
la plupart des systmes dexploitation (dont Microsoft Windows) noffrant pas ce type de service. Les
mcanismes employs actuellement permettent dafcher et danimer par-dessus nimporte quelle
fentre Swing un ou plusieurs composants graphiques semi-transparents, sans modier le code de
lapplication. Ces afchages restent cependant limits aux fentres Swing, et les dispositifs qui les
emploient appartiennent par consquent la catgorie des dispositifs de bote outils graphique (voir
section suivante), bien quen ralit ils ne communiquent pas avec les composants interactifs. Mais il
nest pas exclu qu terme, les plate-formes actuelles fournissent des services dincrustation et que les
dispositifs de retour graphique sophistiqus soient fournis comme des services de base dans ICON.
Dautres dispositifs retour graphique, bass ou non sur les mcanismes dincrustation, peuvent
tre implments et ajouts la bibliothque dICON.
4.2.3
Les dispositifs de bote outils graphique
Les dispositifs de bote outils graphique, situs mi-chemin entre la catgorie des dispositifs
utilitaires et celle de dispositifs dapplications, permettent un contrle gnrique de ces dernires.
travers des entres ou des sorties implicites, ces dispositifs communiquent avec les composants
interactifs (widgets) des fentres dveloppes avec la bote outils. Les rfrences vers les fentres
contrles sont passes en paramtre travers le contexte dexcution ( section 4.3.2 page 121).
ICON comporte des dispositifs de bote outils lis Swing. Nous les dcrivons ici.
Slecteurs et manipulateurs
Il existe deux types de dispositifs de bote outils graphique :
Les slecteurs. Les slecteurs sont des dispositifs qui mettent en sortie des rfrences vers des
114

composants interactifs. Chaque slecteur dcrit une stratgie de slection pour ces composants. Les
slecteurs standards des botes outils sont la slection positionnelle (picking) et le focus. Dautres
stratgies peuvent tre dveloppes, comme les rfrences statiques ou les slections multiples.
Les manipulateurs. Les manipulateurs sont des dispositifs qui prennent en entre des rfrences
vers des composants interactifs. Chaque manipulateur possde des fonctionnalits de contrle propres
une classe donne de composants, et emploie les rfrences reues en entre pour dterminer sur
quelles instances oprer. Parmi ces dispositifs, un manipulateur de surface offre un contrle gnrique des composants interactifs. Celui-ci expose toutes les oprations possibles sur ces composants,
telles que lmission dvnements positionnels. Ensuite, chaque manipulateur de modle dcrit les
oprations supplmentaires quil est possible deffectuer sur une classe particulire de composants :
modication de la valeur dune barre de dlement ou insertion de texte dans une zone de texte, par
exemple.
Les dispositifs Swing

ICON inclut un ensemble de dispositifs Swing, dont le rle est de permettre dinteragir, de faon
standard ou non, avec toute application reposant sur cette bote outils. An de permettre de repenser
lintgralit de linteraction avec Swing et dviter les interfrences avec ses techniques dinteraction
standard, ICON dsactive par dfaut toute gestion vnementielle des entres lors de lexcution dune
conguration :
Dsactivation du clavier. Lorsque le dispositif clavier est utilis dans une conguration en cours
dexcution, ICON dsactive linterprtation des vnements clavier dans Swing en consommant ces
vnements dans la le dvnements Java. ICON dtourne galement la combinaison Alt+C, utilise
pour stopper la conguration.
Dsactivation de la souris. Lorsque le dispositif souris est utilis dans une conguration en cours
dexcution, ICON dsactive linterprtation des vnements souris, ainsi que le curseur systme. Ce
dernier est rendu invisible et maintenu dans une fentre Swing.
F IG . 4.4 Les dispositifs de la bote outils Swing.
115

Les dispositifs Swing sont reprsents sur la gure 4.4 page prcdente. Ceux-ci incluent deux
slecteurs standards : le picking et le focus. Le premier met une rfrence vers le composant qui
se trouve sous la dernire position reue en entre, lorsque son slot pick est vrai. Le dispositif de
focus communique avec le systme de focus de Swing : il notie des changements de focus, et permet
galement de contrler ce focus en passant au composant suivant ou prcdent.
Le dispositif suivant est un manipulateur de surface qui dclare toutes les actions quil est possible deffectuer sur un objet de type JComponent. Un certain nombre de slots dentre permettent de
simuler les manipulations positionnelles standard avec une granularit assez ne. Ces slots incluent
une position, trois boutons, et des modicateurs (touches de contrle, double-clic). partir de ces
informations, le dispositif construit des vnements souris synthtiques (de type MouseClicked, MouseMoved, MouseDragged, etc.), qui sont mis vers le composant en cours. Dautres slots permettent
de modier ltat interne du composant, comme sa visibilit ou son focus.
Les dispositif JScrollbar offre diffrentes manires de contrler la valeur courante des barres
de dlement et des curseurs (sliders). Le dispositif JText permet quant lui de contrler sur les
composants textuels le placement du caret et dy insrer du texte. Il expose en outre toutes les actions
abstraites dclares par le composant Swing, telles que la suppression de texte ou le copier-coller.
Ces 5 dispositifs constituent une bibliothque minimale pour exprimenter le contrle des applications Swing avec ICON (un projet extrieur cette thse tant en cours pour dvelopper un bibliothque complte de dispositifs reposant sur la bote outils Jazz/Piccolo). Notre bibliothque exprimentale offre cependant dj une grande richesse quant aux possibilits de construction de techniques
dinteraction non standards, et nous a permis de valider les principes de base des dispositifs de botes
outils, savoir les notions de slecteurs et de manipulateurs.
Notons enn que les dispositifs Swing maintiennent une rfrence vers une fentre unique et
oprent sur un seul composant de cette fentre la fois, mais quil est tout fait envisageable dtendre
ces dispositifs pour grer des listes de rfrences, aussi bien pour les fentres que pour les composants.
Les systmes de coordonnes dans ICON

ICON laisse les dtails de gestion des systmes de coordonnes aux botes outils graphiques et
aux applications. Il emploie un systme de coordonnes unique, savoir des coordonnes cran en
double prcision. Il sagit dune convention que les dispositifs dentre positionnels, les dispositifs de
botes outils graphiques et les applications partagent.
Lusage de la rsolution de lcran comme systme de rfrence vite les conversions multiples et
permet dattribuer une smantique prcise aux slots positionnels prsents en entre ou en sortie sur des
dispositifs comme le Pick. Lemploi de valeurs relles plutt quentires possde quant lui plusieurs
avantages. Tout dabord, il rduit de faon importante les pertes de prcision dans les conversions de
coordonnes locales en coordonnes cran. Ensuite, certains dispositifs positionnels absolus comme
la tablette graphique possdent une rsolution bien plus importante que celle de lcran1 , et cette
rsolution peut ainsi tre exploite par les applications (par exemple les applications de dessin) et par
certaines techniques dinteraction comme la reconnaissance gestuelle. Par ailleurs, certaines botes
1 Le dispositif tablette produit par dfaut des positions dans le systme de coordonnes cran de rfrence, mais est
galement capable de fournir au besoin des positions entires dans son propre systme de coordonnes. Il est plus gnralement souhaitable, pour rester au plus prs du dispositif physique, que lattribution dune smantique positionnelle certains
canaux de dispositifs dentre ne soit pas systmatique.
116

outils possdent un mode dafchage graphique suprieur la rsolution de lcran (nomm antialiasing dans Swing), qui peut tre avantageusement exploit par les dispositifs de feedback ou les
applications.
4.2.4
Les dispositifs dapplication
Bien quune application interactive puisse tre contrle de manire gnrique par les dispositifs
de bote outils graphique, les dveloppeurs peuvent tendre la contrlabilit de leur application en
implmentant et en dclarant des dispositifs spciques : ce sont les dispositifs dapplication.
Les dispositifs dapplication sont les dispositifs qui nappartiennent pas la bibliothque dICON
et qui sont fournis par les applications.
Lapplication ICONDraw
F IG . 4.5 Les dispositifs de lapplication de dessin ICONDraw.
La gure 4.5 montre une application de dessin en Java, ICONDraw ( droite), qui a t crite pour
tre entirement recongurable par ICON. Cette application est totalement isole des vnements Java
standards, hormis les composants interactifs Swing situs autour de la zone de dessin. Elle dcrit
simplement la faon dont elle sattend tre contrle en exposant ses outils de dessin sous forme de
dispositifs dapplication (gure 4.5, image de gauche).
Les outils de dessin sont au nombre de quatre : dessin main leve, trac de lignes et de rectangles,
et gomme. Ces outils sont contrls par lmission, travers les slots p0 et p, dune ou deux sries de
positions (les lignes et les rectangles sont dnies par leurs deux extrmits). Un outil peut galement
tre activ ou dsactiv (slot activate) et recevoir des attributs graphiques tels que la taille de la brosse
et les composantes couleur RGBA (slot brush).
Les outils de dessin grent galement un retour graphique, ainsi que deux modes dutilisation,
le mode courant tant spci par le slot use. Dans le mode non utilis , un retour graphique est
effectu sur la position et les attributs de la brosse courante. En mode utilis , le retour graphique
est effectu sur la forme gomtrique en cours de cration. Cette forme est valide et ajoute au dessin
lors du passage suivant au mode non utilis .
117

Types de dispositifs dapplication
Nous dgageons trois grands types de dispositifs dapplication, adapts un contexte de programmation oriente-objet comme java :
Les dispositifs de classe. Un dispositif de classe est un dispositif dapplication qui reprsente
une classe dobjets. Les slots dcrivent les oprations qui peuvent tre effectues par lutilisateur sur
les objets de cette classe. Les dispositifs de classe comportent en entre un slot de type objet, qui
spcie la ou les instances cibles. Les JComponent et leurs drivs, dcrits prcdemment dans la
section 4.2.3 page 114, en sont des exemples. Les dispositifs de classe sont en gnral utiles pour
contrler des objets crs et supprims dynamiquement pendant lexcution dune conguration.
Les dispositifs dinstance statiques. Les dispositifs dinstance statiques reprsentent des instances particulires de classes. Seules les instances cres puis convenablement dclares avant linitialisation dune conguration dentre seront visibles et contrlables. Par exemple, aprs la cration
et linitialisation dune fentre, un dispositif dinstance statique pourra tre cr pour chaque composant interactif prsent dans la fentre. Les dispositifs dinstance statiques sont utiles pour le contrle
ddi.
Les dispositifs dinstance dynamiques. Les dispositifs dinstance dynamiques reprsentent des
instances de classes qui sont cres la demande dICON. Lors du lancement dune conguration
dentre, chaque dispositif dinstance dynamique prsent dans la conguration est ouvert par un appel
sa mthode open. Dans cette mthode, un gestionnaire dinstances de lapplication cre linstance
et linstalle, cest--dire la lie au reste de lapplication. Dautres objets peuvent tre crs durant
cette procdure dinstallation. Les dispositifs de dessin dICONDraw sont des dispositifs dinstance
dynamiques : un outil de dessin est instanci pour chaque dispositif prsent dans la conguration.
Plusieurs instances du mme outil de dessin peuvent coexister, et il nexiste pas de limite quant au
nombre doutils prsents dans la fentre de dessin. Les dispositifs dinstance dynamiques, trs puissants, sont utiles pour dcrire des outils, cest--dire des objets de manipulation qui ne font pas partie
intgrante du modle interne de lapplication.
4.3 Programmation avec ICON

Pour programmer avec la bote outils ICON, il nest pas ncessaire de connatre la structure et
les mcanismes de base (typage et excution) des congurations dentre, dcrits indpendamment
par le modle ICOM.
Cependant, lextension de la bibliothque dICON, le dveloppement dapplications interactives
congurables et la distribution de congurations dentres rutilisables ncessitent la connaissance de
quelques mcanismes essentiels propres la bote outils ICON. Nous les dcrivons dans cette partie.
4.3.1
Implmentation de nouveaux dispositifs
Dispositifs programmables
ICON fournit un dispositif utilitaire Script qui permet de dcrire des comportements simples en
JavaScript, directement dans lditeur de congurations et sans ncessit de recompilation. La liste des
118
4.3. PROGRAMMATION AVEC IC ON
F IG . 4.6 Fentre de proprits du dispositif Script.
slots du dispositif ainsi que le code de traitement sont saisis dans la fentre de proprits du dispositif,
illustre gure 4.6. Cet exemple dcrit une fonction de transfert utilise dans le contrle dun zoom
par un dispositif isomtrique.
Linterface Device
Comme nous le verrons dans cette section, limplmentation en Java dun dispositif simple est
relativement lmentaire. Les fonctionnalits dun dispositif dentre sont dcrites par linterface Device dans lAPI ICON. Cette interface est reproduite, avec les commentaires, sur la gure 4.7 page
suivante. La partie excution des dispositifs dentre est dcrite par linterface Processor, reproduite
sur la mme gure.
En pratique, un dispositif drive toujours de la classe AbstractDevice. Cette classe implmente un
certain nombre de comportements par dfaut communs une grande majorit des dispositifs, savoir,
la gestion des slots dentre et de sortie travers les mthodes addIn et addOut, lauto-duplication
(consistant en une r-instanciation de la classe et la copie des valeurs des paramtres), et la gestion
dun processeur unique.
Exemple : le dispositif DColorConv
La gure 4.8 page 121 montre un exemple de dispositif utilitaire qui a t ajout la bibliothque
dICON pour permettre un contrle vocal des attributs de la brosse dans ICONDraw. Ce dispositif
DColorConv convertit des noms de couleur en leurs composantes RGB.
crire un dispositif utilitaire consiste essentiellement dclarer ses slots dentre et de sortie, et
remplir le corps de sa mthode de mise jour update, pour assigner les valeurs des slots de sortie
en fonction de celles des slots dentre (la gestion des tables de couleurs nest pas montre dans
le code). chaque fois quune des valeurs en entre changera, cette mthode de mise jour sera
automatiquement appele par la machine ractive dICON.
La classe AbstractDevice gre un processeur unique : elle implmente linterface Processor, et sa
mthode open() retourne this par dfaut. La gestion de processeurs multiples, utile pour faire de la
spcialisation de code, seffectue par drivation de la mthode open() et lutilisation dinner classes.
119
public interface Device {
/**
* Spcifie ci ce dispositif peut
* actuellement tre ouvert (i.e.
* sil est correctement paramtr).
*/
public boolean isOpenable();
public static String[] AUTO_PROPERTIES =

new String[] {"Auto"};
/**
* Retourne le nom du dispositif.
*/
public String getName();
/**
* Ouvre le dispositif pour le prparer
* lexcution. Toute allocation de
* ressources doit seffectuer ici.
* Le contexte dexcution permet, le cas
* chant, de passer au dispositif les
* rfrences ncessaires son excution
* (fentres, etc.)
* Retourne un Processor si louverture a
* russi, null dans le cas contraire (voir
* linterface Processor, plus bas).
*/
public Processor open(OpenContext context);
/**
* Retourne des informations sur le
* dispositif destination de
* lutilisateur, ou null.
*/
public DeviceInfo getInfo();
/**
* Retourne les slots dentre du dispositif.
*/
public In[] getIns();
/**
* Cette mthode est appele lorsque le
* dispositif nest plus utilis. Les
* ressources doivent tre dsalloues ici.
*/
public void close();
/**
* Retourne les slots de sortie du
* dispositif.
*/
public Out[] getOuts();
/**
* Retourne un court message derreur
* explicatif, si isOpenable() retourne faux
* ou aprs un chec douverture.
*/
public String getError();
/**
* Spcifie si ce dispositif comporte des
* entres implicites.
*/
public boolean hasExternalInput();
/**
* Spcifie si ce dispositif comporte des
* sorties implicites.
*/
public boolean hasExternalOutput();
/**
* Active ou dsactive le dispositif.
*/
public void setEnabled(boolean enabled);
}
/**
* Retourne les paramtres du dispositif.
* Pour chaque paramtre X, la classe doit
* dclarer deux accesseurs setX et getX.
* En retournant AUTO_PROPERTIES, les
* paramtres sont automatiquement dduits
* des accesseurs de la classe.
*/
public String[] getProperties();
public interface Processor {

/**
* Cette mthode est appele lors du premier
* tick dexcution.
*/
void init();
/**
* Spcifie si ce dispositif est duplicable
*/
public boolean isCopiable();
/**
* Retourne un dispositif avec les mmes
* fonctionnalits, ou null si le dispositif
* nest pas duplicable (instance statique).
*/
public Device copy();
/**
* Cette mthode est appele lorsquun signal
* est prsent dans lun des slots dentre.
*/
void update();
}
F IG . 4.7 Les interfaces Device et Processor.
120
public class DColorConv extends AbstractDevice {

// dclaration des slots
public
public
public
public
final
final
final
final
In name
Out r =
Out g =
Out b =
= addIn("name", SlotType.STRING);
addOut("color.r", SlotType.DOUBLE);
addOut("color.g", SlotType.DOUBLE);
addOut("color.b", SlotType.DOUBLE);
( )
// mise jour des slots de sortie
public void update() {
if (name.hasSignal()) {
String s = name.getStringValue();
boolean found = false;
for (int i=0; i<COLOR_NAMES.length && !found; i++)
found = (COLOR_NAMES[i].equals(s));
if (found) {
r.setDoubleValue(COLOR_R[i-1]);
g.setDoubleValue(COLOR_G[i-1]);
b.setDoubleValue(COLOR_B[i-1]);
}
}
}
}
F IG . 4.8 Code java du dispositif DColorConv.
Le dispositif peut tre rendu paramtrable (par exemple, une liste de couleurs personnalisable),
simplement en ajoutant des mthodes de type accesseurs la classe. ICON dduit automatiquement les
noms de paramtres par introspection et gnre la fentre de proprits correspondante dans lditeur.
Limplmentation dun dispositif dapplication est similaire celle dun dispositif utilitaire comme
DColorConv, ceci prs que les assignations de slots de sortie sont remplaces par des appels de mthodes dans lapplication elle-mme.
4.3.2
Initialisation dune conguration
Principe gnral
Pour tre congurable par ICON, une application doit crer une conguration dentre et faire
le lien entre cette conguration et ses propres objets. Lensemble des mcanismes de communication entre lapplication et sa conguration dentre est rsum sur la gure 4.9. La cration dune
conguration dentre ncessite la dclaration dun dossier de dispositifs et le passage dun contexte
dexcution.
Le dossier de dispositifs contient lensemble des dispositifs qui pourront tre utiliss dans la conguration, et qui seront visibles dans la partie gauche de lditeur de congurations (voir section 4.4.1
page 127). En gnral, il sagit de la bibliothque standard dICON comportant tous les dispositifs
systme et utilitaires organiss en sous-dossiers, laquelle est ajout un dossier spcique lapplication. Comme tout dossier, ce dernier est un conteneur de dispositifs-prototypes, instances de dispositifs qui sont dupliques pour tre ajoutes la conguration. Un ou plusieurs prototypes peuvent
121
F IG . 4.9 Initialisation dune conguration dentre dans une application interactive.
tre dclars par classe de dispositif, ce qui permet notamment de fournir des ensembles de dispositifs
pr-paramtrs, ou de dcrire des dispositifs dinstance statiques.
Le contexte dexcution est une table de hachage qui contient toutes les informations ncessaires
lexcution de lensemble des dispositifs du dossier. Les dispositifs de bote outils graphique, que
nous avons voqus prcdemment, ncessitent une rfrence vers la ou les fentres quils contrlent.
En outre, lapplication possde ses propres dispositifs qui requirent des rfrences vers des objets
de celle-ci, rfrences qui sont ajoutes au contexte sur des cls spciques. Lors du lancement de la
conguration dentre, chaque dispositif reoit dans sa mthode open le contexte dexcution do il
va extraire les informations pertinentes, et le cas chant produire un chec douverture si celles-ci
sont indisponibles.
Implmentation dune application congurable

Le code type dune application congurable par ICON est donn sur la gure 4.10 page ci-contre.
Ce code prsente trois parties principales :
A. Initialisation de la conguration dentre. Ce code est ajout la n de la mthode constructeur de lapplication. Le dossier de dispositifs est cre en passant le dossier de lapplication (MyDevices) au constructeur de la bibliothque standard dICON (FRoot). La conguration dentre (ainsi
que sa fentre ddition) est ensuite cre, puis excute.
B. Gestion de la conguration. Une gestion minimale de la conguration consiste en lajout
dun lment interactif (lment de menu, par exemple) qui dclenche le passage en mode dition
(mthode editInput()), et en la gestion propre de la dsallocation des dispositifs lors de la fermeture
122
public class MyApp extends JFrame {

static final File default_ic = new File("IC files/default.ic");
final Configuration ic;
final JInputEditor editor;
(...)
public MyApp() {
(...)
// 1. Cration de la bibliothque de dispositifs

DeviceFolder devices = new FRoot(new MyDevices());
// 2. Cration du contexte dexcution
OpenContext context = new OpenContext();
context.setValue(OpenContext.KEY_JFRAME, this);
context.setValue("MY_APP", this);
// 3. Cration de la configuration dentre
ic = new Configuration(context, devices);
// 4. Chargement de la configuration par dfaut
ic.load(default_ic);
// 5. Cration dune fentre ICon
editor = new JInputEditor(ic);
// 6. Ouverture et dmarrage de la configuration
ic.open();
ic.start();
}
(...)
// Appel par un bouton ou un lment de menu

public void editInput() {
// Arrt et dition de la configuration
ic.stop();
editor.setVisible(true);
}
// Appel par un bouton ou un lment de menu
public void quit() {
// Arrt et fermeture de la configuration
ic.stop();
ic.close();
System.exit(0);
}
// Liste des dispositifs de cette application

class MyDevices extends AbstractFolder {
public MyDevices() {
super("MyApp");
// Cration et ajout des prototypes de dispositifs
add(new AppDevice1());
}
}
F IG . 4.10 Code type dune application congurable en entre. Les dispositifs dapplication ne sont pas
reprsents.
123

de lapplication (mthode quit()).
C. Dossier de dispositifs. Les dispositifs-prototypes de lapplication sont dclars par drivation
dune classe abstraite (AbstractFolder).
4.3.3
Srialisation et descripteurs
Pour pouvoir tre sauvegardes et charges, les congurations dentre doivent tre srialisables.
La srialisation consiste convertir un objet en une srie doctets (que nous nommerons signature)
pour pouvoir, lors dune excution ultrieure, recrer le mme objet par le processus inverse. Dans
cette section, nous voquerons essentiellement la srialisation de dispositifs.
Les difcults de la srialisation de dispositifs

tablir la signature dun dispositif systme nest pas trivial. En voici quelques raisons :
1. Un dispositif systme nest pas entirement dcrit par sa classe. Par exemple, deux dispositifs
physiques de mme type peuvent tre prsents, et produire dans ICON deux dispositifs qui
drivent de la mme classe.
2. Toutes les APIs dentre ne garantissent pas un mcanisme dterministe de dtection et didentication de dispositifs. Lordre dans lequel les dispositifs sont lists peut galement changer.
3. Entre deux excutions, un dispositif dentre physique peut avoir t dbranch et rebranch sur
un autre connecteur : il devra tout de mme tre retrouv, puisquil sagit du mme dispositif.
4. Deux dispositifs dentre physiques identiques (mme marque, mme modle) peuvent tre
utiliss conjointement dans une conguration et y jouer un rle diffrent. Il va de soi que ces
dispositifs sont physiquement placs diffremment sur lespace de travail (main droite et main
gauche, par exemple). Dune excution lautre, leurs rles respectifs ne devra donc pas tre
interverti.
tablir des signatures les plus prcises possibles, notamment en sappuyant sur des identiants
uniques ( condition quils soient fournis par lAPI dentre), peut rsoudre en partie ces problmes.
Des interrogations subsistent cependant : faut-il prendre en compte lidentiant matriel du dispositif
ou celui du connecteur sur lequel il est branch ? Si seul lidentiant matriel est utilis, la situation
4. voque prcdemment ne sera pas rsolue. Dans le cas contraire, cest la situation 3. qui posera
problme.
Dautres arguments vont lencontre de lemploi didentiants uniques. Le remplacement dune
souris par une autre, par exemple, ne devrait pas rendre une conguration standard inutilisable. De
mme, certaines congurations dentre devraient pouvoir tre rutilisables dun poste lautre et
dun utilisateur lautre. Il est clair que la rutilisabilit des congurations dentre et lidentication prcise des dispositifs physiques pour la persistance sont deux exigences incompatibles, et cest
pourquoi il est essentiel demployer des stratgies de signature adaptes chaque contexte.
Notons enn que ces problmes sont gnralisables tous les dispositifs comportant des entres
ou sorties implicites (les dispositifs dapplication en particulier), car, dune excution lautre, il faut
tre capable de reconstruire ou de retrouver les objets extrieurs avec lesquels ils communiquaient.
124

La gestion de la srialisation dans ICON est dune grande souplesse, grce au principe de descripteurs sur lequel il repose. La signature dun dispositif est obtenue par la signature dun de ses
descripteurs. Des descripteurs plus ou moins slectifs peuvent tre construits, chaque dossier de dispositifs ayant la charge de fournir des descripteurs stricts (uniques) pour ses dispositifs ls.
Les descripteurs : dnition

Un descripteur est un ensemble non ncessairement dnombrable de dispositifs. En outre, chaque
descripteur est li une reprsentation textuelle, tel quil existe une bijection entre lensemble des
descripteurs et lensemble de leurs reprsentations textuelles.
Dans ICON, linterface DeviceDescriptor est dnie par les mthodes suivantes :
public boolean contains(Device d)
public String getString()
Une classe de descripteurs est une classe :
1. Qui implmente linterface DeviceDescriptor
2. Dont le nom est prx par DD
3. Qui comporte un constructeur du type public DDFoo(String s)
4. Qui vrie pour toute instance desc :
desc new DDFoo(desc.getString())
(quivalence de leurs fonctions contains et getString).
Un descripteur est une instance dune classe de descripteurs. La signature dun descripteur est
obtenue par concatnation de son nom de classe sans le prxe DD, du signe =, et de sa reprsentation
textuelle.
Exemple : pour une instance de DDFoo dont getString()=4, la signature est foo=4.
Les classes de descripteurs dICON

Il existe plusieurs classes de descripteurs prdnies dans ICON. Il est ainsi possible de dcrire
des ensembles de dispositifs possdant un nom donn, drivant dune classe donne, possdant un
ensemble minimal de slots (noms et/ou types), ou provenant dun dossier donn. Ces descripteurs
sont extrmement puissants et la plupart permettent dutiliser des caractres gnriques (* et ?). De
nouvelles classes de descripteurs peuvent cres et employes.
Les descripteurs sont composables : les meta-descripteurs sont des descripteurs qui comportent un
ou plusieurs descripteurs-ls. La plupart permettent deffectuer des oprations ensemblistes. Le descripteur DDAnd, par exemple, effectue des intersections de descripteurs. titre dexemple, la phrase
tous les dispositifs dont le nom commence par "mouse" et qui drivent dune classe "DMouse"
sera construite ainsi :
DeviceDescriptor mydesc =
new DDAnd(new DDName("mouse*"), new DDClass("*.DMouse")) ;
125

ou pourra tre spcie par la signature suivante :
DeviceDescriptor desc = DescriptorUtilities.createDD("
and {
name=mouse* ;
class=*.DMouse ;
}
") ;
Lalgorithme de chargement
Lors du chargement dun chier de conguration, et pour chaque descripteur de ce chier, le dossier de dispositifs est parcouru jusqu ce quun dispositif-prototype convienne (contains(d)==true).
Celui-ci est alors copi, ajout la conguration et nest plus pris en compte dans les recherches ultrieures.
Le descripteur DDProperties, qui dcrit des paramtrages pour les dispositifs, joue un rle particulier dans lalgorithme de dsrialisation. Lorsquun dispositif-prototype correct a t trouv, puis
copi, lalgorithme lui applique le paramtrage spci par le descripteur lorsquil existe. Si ce paramtrage provoque une erreur (paramtre inexistant ou valeur incorrecte), lalgorithme reprend la
recherche.
Lors dune dsrialisation, plusieurs dispositifs-prototypes peuvent rpondre un descripteur.
Cest le premier rencontr qui est choisi, puis limin des choix ultrieurs. Lalgorithme effectue
cependant des retours arrire lorsquil aboutit une impasse (dispositif introuvable).
Les descripteurs stricts
Lors dune sauvegarde, ICON utilise par dfaut des descripteurs stricts, garantissant lunicit.
Chaque dossier de dispositifs est charg de fournir des descripteurs stricts pour ses dispositifs, par
la mthode getDescriptor(Device d). Dans la classe AbstractFolder, cette mthode retourne
simplement un descripteur sur la classe du dispositif pass en paramtre. Ce comportement par dfaut
convient aux dispositifs utilitaires et la plupart des dispositifs dapplication. Le plus souvent, limplmentation dune application congurable par ICON ne ncessite donc aucune connaissance sur les
descripteurs.
Pour un dossier comportant plusieurs prototypes de mme classe, il devient cependant ncessaire
de retourner un descripteur plus prcis, portant par exemple sur le nom du dispositif. Les dossiers de
dispositifs systme, quant eux, devront retourner une liste complte des caractristiques physiques
du dispositif pour sassurer que deux dispositifs ne possdent jamais le mme descripteur. Des classes
spciques de descripteurs pourront galement tre cres et employes.
Le langage ICSCRIPT
Les chiers de congurations sont gnrs dans un langage de script ddi nomm ICSCRIPT.
Un exemple de chier de conguration est donn gure 4.11 page 128. Celui-ci est partag en trois
sections (en gras italique) : la dclaration des dispositifs compose de descripteurs, les connections,
126
4.4. CONSTRUCTION ET DITION DE CONFIGURATIONS DENTRE

et la partie prsentation, optionnelle et propre lditeur de congurations. Chaque descripteur est
nomm (en gras) dans la premire section an de pouvoir tre rfrenc dans les sections suivantes.
Une syntaxe similaire permet galement le nommage des descripteurs de slots, lorsque des connexions
doivent tre spcies entre des slots dont le nom concret nest pas connu (attribut name absent du
descripteur ou comportant des caractres gnriques, par exemple).
Lauteur dune conguration peut diter ce chier et modier les descripteurs qui sy trouvent
avant de le distribuer dautres utilisateurs. Par exemple, les slots non utiliss dun dispositif peuvent
tre supprims de sa dclaration, ou plusieurs dispositifs interchangeables peuvent tre spcis en
reliant simplement leurs descripteurs par un or. Les oprations ensemblistes and, or et not peuvent
tre imbriques et appliques sur nimporte quel sous-ensemble de descripteurs.
Le langage ICSCRIPT est un premier pas vers la rutilisabilit des congurations dentre.
terme, des stratgies de rutilisabilit intgres pourront tre mises en uvre sur la base des descripteurs, telles que la visualisation et ldition graphique des descripteurs, ou lutilisation dun moteur de
rsolution de contraintes dans lalgorithme de chargement des congurations.
4.4 Construction et dition de congurations dentre

Lditeur de congurations dICON permet de visualiser, modier, sauver et charger des congurations dentre. La construction et ldition des congurations dentre se font essentiellement par
manipulation directe. Bien que les congurations dentre soient indpendantes de lditeur et peuvent
tre implmentes directement en Java, cet outil constitue llment central de la bote outils ICON,
et lui confre toute sa souplesse. Le dveloppeur dapplications peut, travers cet outil, construire et
tester un grand nombre de congurations dentre potentielles qui rpondent des situations spciques en termes de dispositifs dentre. Lutilisateur avanc peut ensuite personnaliser linteraction
pour la plier ses besoins spciques.
Dans cette section, nous prsenterons brivement lditeur de congurations dICON. Puis, nous
donnerons aperu des diffrents types de conguration dentre quil est possible de construire avec
cet diteur. Nous avons construit et test de nombreuses mthodes dentre avec ICON, et nous nen
fournirons que les exemples les plus reprsentatifs.
4.4.1
Lditeur de congurations
Lefcacit dun outil de programmation visuelle repose en grande partie sur le choix des techniques dinteraction, choix qui dtermine sa facilit dapprentissage ainsi que les performances effectives dans les diffrentes tches de programmation. Les techniques employes dans notre diteur,
simples et standards pour la plupart et plus spciques pour dautres, rpondent aux tches courantes
de construction et ddition de congurations dentre. Nous les voquons dans ce court descriptif.
Des clips vido montrant des constructions ou des modications de congurations sont galement
disponibles en tlchargement [D RAGICEVIC 02].
La fentre ddition. Une capture dcran de la fentre ddition de congurations dentre est
donne gure 4.12 page 129. Celle-ci est divise en trois parties : En haut gauche, larborescence
des dossiers de dispositifs-prototypes, qui comprend les dispositifs dentre disponibles, les dispositifs
utilitaires dICON, et le cas chant, le dossier de lapplication en cours ddition. En bas gauche,
127
Devices {
mouse: and {
folder=all.extended.directInput;
and {
name=mouse;
class=DDirectMouse;
externalInput;
outs {
and {
name=but.left;
type=boolean;
}
and {
name=but.middle;
type=boolean;
}
and {
name=but.right;
type=boolean;
}
and {
name=p.dx;
type=int;
}
and {
name=p.dy;
type=int;
}
and {
name=wheel;
type=int;
}
}
}
properties disableSystem=yes;
}
sum: and {
folder=all.standard.control;
class=DSum;
properties defaultValue=0.0;
}
sum2: and {
folder=all.standard.control;
class=DSum;
properties defaultValue=0.0;
}
freehand: and {
and {
name=freehand;
class=fr.emn.examples.icondraw.DFreehand;
}
properties {
screenCoordinates=yes;
activated=yes;
}
}
}
Connections {
mouse.but.left=freehand.use;
mouse.p.dx=sum.in;
mouse.p.dy=sum2.in;
sum.out=freehand.p.x;
sum2.out=freehand.p.y;
}
Layout {
sum2: {
x=81.50220396714089;
caption=sum;
expand=yes;
scale=0.7142857142857143;
y=107.5312562612703;
}
sum: {
x=80.19785614105392;
caption=sum;
expand=yes;
scale=0.7142857142857143;
y=94.05299539170508;
}
freehand: {
x=147.29663394109403;
caption=freehand;
expandSlots=[p];
scale=1.0;
y=79.66643291257597;
}
mouse: {
x=1.8408134642356373;
caption=mouse;
expandSlots=[but, p];
scale=1.0;
y=79.9273024777934;
}
}
F IG . 4.11 Fichier ICSCRIPT gnr partir de la conguration de la gure 4.21.
128
F IG . 4.12 La fentre ddition dICON. Une conguration qui permet de jouer de la musique avec les touche
de fonction du clavier est en cours ddition.
la liste des dispositifs-prototypes pour le dossier actif. droite, lespace de travail zoomable o est
visualise la conguration dentre.
F IG . 4.13 Instanciation ( gauche) et inspection (au centre et droite) dun dispositif.

Instanciation et inspection de dispositifs. Pour tre utilis dans une conguration, un dispositif
est instanci partir de son prototype par cliquer-glisser sur lespace de travail (gure 4.13, image de
gauche). Une technique de type sheye peut tre active par un quasi-mode an de pousser les
dispositifs voisins si la place manque. Des info-bulles (tooltips) permettent dobtenir des informations
sur le dispositif : courte description du dispositif et de ses slots, nom complet et type de chaque
slot, fentre daide dtaille sur le dispositif (gure 4.13 au centre). La hirarchie des slots peut tre
inspecte la manire des rpertoires dans les explorateurs de chiers (gure 4.13, image de droite).
Techniques de connexion. Les slots sont connects par cliquer-glisser Les compatibilits de types
et les cycles sont explicits par des retours graphiques et magntiques. Le rendu des connexions
est automatique et emploie un algorithme simple et original, optimis pour les graphes acycliques2 .
Des techniques dinteraction ddies permettent de faciliter certaines tches de connexion courantes.
Lauto-expand est une technique gestuelle qui ouvre et ferme automatiquement les slots composites
2 Lors
de dplacements de dispositifs, cet algorithme offre une animation uide et sans discontinuit des connexions et
ne gnre pas de nouveau croisement.
129
F IG . 4.14 La technique auto-expand. Ici, un dispositif est connect un slot initialement invisible, en un seul
geste.
pendant une interaction de connexion (gure 4.14)3 . Une technique de reconnexion permet galement de dplacer lune des deux extrmits dune connexion, et des connexions groupes peuvent tre
cres automatiquement entre des slots composites.
F IG . 4.15 Cration par manipulation directe dune copie de dispositif ( gauche) et dun lien ( droite).
Copie et lien. La copie dun dispositif (gure 4.15, image de gauche) et la cration dun lien (gure 4.15, image de droite) se font par manipulation directe. Lopration de copie cre une nouvelle
instance du dispositif et en reproduit le paramtrage. Les liens, explicits par des lignes verticales
paisses (gure 4.15, image de droite), permettent dafcher le mme dispositif en diffrents endroits
de la conguration, an de rduire sa complexit visuelle. Comme nous le verrons dans certaines
congurations-exemples, les liens peuvent tre dploys dans la dimension verticale, perpendiculairement au ux de connexions qui est essentiellement horizontal.
F IG . 4.16 Conguration dentre avec dispositifs dploys (en haut) et rduits (en bas).
Niveau de dtail. Les dispositifs peuvent tre rduits pour ne montrer que les slots utiliss, et
diminuer ainsi la complexit visuelle dune conguration. Le passage dun mode lautre se fait
3 La fermeture automatique des slots composites est temporairement dsactive lors dune inspection de haut en bas, an
dviter que le slot sous le pointeur se dcale brutalement vers le haut.
130

par un simple clic sur le dispositif, ou automatiquement par la technique de lauto-expand dcrite
prcdemment. Lespace de travail est zoomable, ainsi que les dispositifs individuels (pas de zoom
smantique pour linstant, en dehors dune prise en charge minimale des niveaux de dtail).
F IG . 4.17 Cycle ddition-excution pour une conguration dentre.

Cycle ddition-excution. Une fois construite, une conguration dentre peut tre immdiatement teste en lanant son excution (gure 4.17, gauche). Par la suite, la conguration peut
nouveau tre dite par lemploi du raccourci Alt+C ou par une option de menu si lapplication
interactive le prvoit (gure 4.17, droite). Ldition dynamique permet dafner une conguration
dentre par des cycles ddition-excution, ce qui est particulirement utile pour tester des techniques
dinteraction, ou rgler des paramtres arbitraires comme des niveaux de sensibilit.
4.4.2
Des congurations standard aux congurations hautement interactives
Dans cette partie, nous donnons un aperu des techniques dinteraction qui peuvent tre construites
avec lditeur de congurations. Nous voquerons des exemples de mthodes dentre adaptes des
congurations matrielles standard, enrichies ou appauvries, puis des congurations exploitant des
techniques dinteraction novatrices et avances. Tous les exemples sont issus de captures dcran de
lditeur dICON, ou de lapplication contrle.
Description de mthodes dentre standards
F IG . 4.18 Contrle positionnel standard des composants Swing.

Des mthodes dinteraction standards souris/clavier peuvent tre construites et livres avec les
applications sous forme de congurations dentre par dfaut. La gure 4.19 page suivante illustre
une conguration qui reproduit le contrle positionnel standard des composants de Swing la souris.
Les positions relatives de la souris bas-niveau sont transformes en valeurs absolues qui dplacent un
curseur, puis slectionnent le composant cible et contrlent ce composant en gnrant des vnements
souris.
Cette conguration peut tre tendue pour une description plus ne du comportement standard de
Swing. La gure 4.18 met en vidence tous les slots disponibles sur les dispositifs de la gure 4.19. Par
131
F IG . 4.19 Contrle positionnel standard des composants Swing. Sur cette gure, tous les slots disponibles
sont mis en vidence.
F IG . 4.20 Contrle au clavier du focus et des composants Swing.
des connexions supplmentaires, il est possible de prendre en compte les autres boutons de la souris
et leurs modicateurs. Le slot but1 du curseur peut tre connect au slot state.focus de JComponent
pour dcrire le changement de focus la souris. La conguration peut galement tre complte pour
prendre en compte les mcanismes relatifs au clavier : la gure 4.20 montre un exemple de contrle
du focus avec les touches Tab et Shift+Tab, ainsi que la simulation du clic avec la touche espace.
F IG . 4.21 Contrle la souris du dessin main leve.
Des mthodes dinteraction standard, bases sur la souris et le clavier peuvent galement tre
construites pour des applications spciques. Sur la gure 4.21, loutil de dessin main leve est
contrl la souris de manire triviale. Pour tre complte, cette conguration minimale peut tre
tendue en insrant un feedback supplmentaire sur le pointeur, et en dcrivant le contrle des attributs
de brosse, ainsi que le contrle modal doutils multiples.
132
F IG . 4.22 Interaction multi-pointeurs avec Swing.
Pointeurs multiples et interaction bimanuelle

Parce que chaque curseur gre son propre retour graphique, lutilisation de curseurs multiples
est lmentaire avec ICON. Comme illustr sur la gure 4.22, la duplication de la conguration de
la gure 4.18 page 131 et le remplacement de la souris par un autre dispositif suft permettre un
contrle bimanuel ou multi-utilisateurs des applications Swing. Deux composants interactifs (ou plus,
selon le nombre de pointeurs) peuvent tre contrls en mme temps. Cependant les interactions
concurrentes ne sont pas permises au sein dun mme composant. En outre, certains mcanismes de
Swing, conus sur la base dun pointeur unique, peuvent se rvler gnants : par exemple, le fait de
cliquer avec un pointeur peut fermer un menu qui vient dtre ouvert par un autre pointeur. Nous
discuterons de ce problme dans la section 5.6.2 page 170
F IG . 4.23 Trac de lignes standard et bimanuel avec ICONDraw.
Contrairement aux dispositifs Swing, les dispositifs dapplications peuvent tre conus pour grer
la concurrence, et des techniques dinteraction bimanuelle peuvent tre dcrites avec une granularit
bien plus ne. La gure 4.23 montre comment, avec un dispositif supplmentaire, une technique dinteraction standard peut tre remplace par une technique dinteraction bimanuelle. Le cadre suprieur
gauche illustre le contrle par dfaut de loutil de trac de lignes dICONDraw, construit avec des dispositifs de routage conditionnel. Cette technique consiste placer successivement une extrmit de la
ligne puis lautre. Dans le cadre infrieur, la conguration a t modie an que le curseur (contrl
par la souris) soit directement reli une extrmit de la ligne, et quune tablette graphique soit relie
la deuxime.
133

Utilisation de dispositifs tendus et riches
F IG . 4.24 Dessin main leve sensible la pression.
Dans ICON, les dimensions supplmentaires fournies par les dispositifs tendus peuvent tre facilement exploites. La gure 4.24 montre comment, dans une conguration ICONDraw, le canal de
pression dune tablette graphique peut tre assign la dimension de la brosse.
F IG . 4.25 Contrle dune interface zoomable avec un dispositif six degrs de libert, par la technique PZR.
Les dispositifs dentre riches, comme les dispositifs multiples degrs de libert, peuvent galement tre exploits leur maximum. La gure 4.25 illustre une conguration o une application
zoomable, dcrite par le dispositif ZCanvas, est contrle par un dispositif isomtrique six degrs de
libert de type Magellan. La technique employe (que nous nommons PZR pour Pan/Zoom/Rotate )
permet de contrler simultanment la position, le zoom et lorientation du document.
Dans cette conguration-exemple, les dimensions x et z du dispositif, parallles aux axes de la souris, dplacent la zone de travail. Sur chaque axe, trois dispositifs de traitement enchans convertissent
des valeurs relatives relles en valeurs absolues entires. La dimension y du dispositif, qui traduit
la pression ou la traction verticale sur le dispositif, envoie des commandes de zoom au document
travers un dispositif scriptable, dont le code a t donn en exemple dans la section 4.3.1 page 118.
Enn, la dimension u envoie des commandes de rotation au document, travers une simple remise
lchelle.
134
4.4.3
Congurations dentre pour laccessibilit
mulation de dispositifs
F IG . 4.26 Adapteurs de contrle clavier.
Deux dispositifs compatibles (par exemple, deux dispositifs positionnels) peuvent tre facilement
intervertis dans ICON. Si les dispositifs sont de nature diffrente, la puissance dexpression dICON
peut tre exploite pour construire des techniques dinteraction capables dmuler un dispositif. La
bibliothque dICON fournit en outre des adaptateurs prdnis pour ce type de tche. La gure 4.26
montre comment un tel adaptateur peut tre insr entre un clavier et un curseur : ladaptateur KeyControl est un dispositif composite construit avec ICON, qui permet un contrle uide de dimensions
continues partir de dispositifs deux tats. Des techniques plus spciques de contrle adaptes
des entres appauvries peuvent galement tre construites. Des touches clavier peuvent par exemple
tre directement assignes des boutons ou des commandes dans une application graphique.
Utilisation de commandes vocales
F IG . 4.27 Contrle vocal des barres de dlement dans Swing.
Bien quil ne gre pas les grammaires, le dispositif de commande vocale peut tre employ pour un
contrle vocal simple dapplications interactives. La gure 4.27 illustre une conguration permettant
de manipuler les barres de dlement de Swing partir de commandes telles que plus, un peu moins,
ou minimum. Sur cette gure sont reprsents la fentre de proprits dans laquelle le vocabulaire est
spci, ainsi que le dispositif de contrle conditionnel Switch permettant dactiver une commande en
fonction de lindex de la chane reconnue.
135
F IG . 4.28 Les attributs de dessin contrls la voix dans ICONDraw.
La gure 4.28 montre comment, dans ICONDraw, des attributs de brosse peuvent tre contrls
la voix, avec des commandes comme bleu, rouge, plus gros, ou moins gros. La taille de la brosse est
contrle par un dispositif de commande vocale suivi dun dispositif Switch, puis dun dispositif Cycle
qui permet un contrle incrmental paramtrable dune valeur entire. Le contrle de la couleur emploie un second dispositif de commande vocale paramtr avec un vocabulaire de couleurs. La chane
de caractres reconnue est convertie en composantes RGB par un dispositif qui a t implment pour
loccasion (voir section 4.3.1 page 118).
Parmi dautres mcanismes de contrle vocal que nous avons expriments, une technique de
curseur contrl la voix, dcrite dans la section 4.4.4, a t implmente pour permettre un contrle
vocal gnrique des applications interactives.
4.4.4
Les techniques dinteraction avances et novatrices
Concevoir de nouvelles techniques dinteraction : le pointage augment

Les dispositifs de traitement de donnes et de retour graphique dICON peuvent servir construire
des techniques dinteraction part entire. Ces techniques dinteraction peuvent tre spciques
une application, ou rutilisables si elles sont dcrites un niveau assez bas dans la conguration.
Ces dernires peuvent tre transformes en dispositifs composites et tre rutilises dans dautres
congurations.
Nous prsentons en guise dexemple un nouveau paradigme dinteraction conu et test avec
ICON, le pointage augment. Le pointage augment dcrit un ensemble de techniques dinteraction
positionnelles qui emploient un double pointeur, compos dun pointeur tmoin (ou de bas niveau) et
dun pointeur augment (ou de haut niveau) (gure 4.29 page suivante). Le premier pointeur produit
un retour graphique direct sur le dispositif positionnel sans agir sur linterface. Le second pointeur,
qui agit sur linterface, est li au premier mais possde un comportement supplmentaire destin
136
F IG . 4.29 Le double pointeur, compos du pointeur tmoin (en noir et blanc) et du pointeur augment (en
gris fonc, lintrieur du prcdent).
faciliter certaines tches de pointage.
F IG . 4.30 Une technique de pointage liss , permettant notamment la correction du dessin main leve.
Pour des utilisateurs prsentant des difcults motrices ou dans certaines tches positionnelles
telles que le dessin main leve, il peut tre utile de lisser les dplacements du pointeur. La gure 4.30
prsente la partie dune conguration dentre dcrivant cette technique applique au pointage augment : le premier dispositif Cursor constitue le pointeur tmoin. Le second, renomm smoothCursor,
plac la suite de ltres passe-bas, constitue le pointeur augment. Ce dernier fait ofce de dispositif
virtuel et contrle dautres parties de la conguration. Cette conguration a rapidement t obtenue
en modiant une conguration de contrle positionnel standard. Sur la partie droite de la gure, la
technique est utilise pour le dessin main leve dans ICONDraw : au dpart et la n du trac, les
deux curseurs sont confondus. Pendant le trac, le curseur effectif (en gris fonc) subit un retard et se
dsolidarise du premier pour tracer une ligne uide.
Ici comme dans les exemples qui vont suivre, le pointeur tmoin est utile pour la comprhension et la visualisation du comportement du pointeur augment par rapport aux mouvements rels du
dispositif, tout en conservant une sensation de contrle sur ce dernier.
F IG . 4.31 Le pointage de second ordre, appliqu une barre de dlement : lutilisateur agit uniquement sur
la vitesse de dlement du document.
La gure 4.31 dcrit une autre technique de pointage augment, le pointage de second ordre. Les
ltres passe-bas sont remplacs par des dispositifs drivateurs, qui calculent la vitesse dvolution de
valeurs numriques (ces derniers ont t dcrits avec ICON puis transforms en dispositifs compo137

sites). Ici, le pointage augment est activ par le bouton droit de la souris, le bouton gauche effectuant
un cliquer-glisser standard.
Le pointage de second ordre permet dagir sur la vitesse du pointeur au lieu de sa position. Il
est utile lors de tches de pointage qui requirent un dplacement uniforme et prolong de celui-ci :
recherche dans un long document, ou recherche dans une liste avec slection successive des lments.
Il permet galement des cliquer-glisser non limits aux bords de lcran, utiles pour la navigation (pan)
dans un large espace de travail. Sur la partie droite de la gure 4.31 page prcdente, lutilisateur met
contribution la technique sur une barre de dlement Swing4
Dautres techniques de pointage augment ont t mises en uvre, comme le pointage contraint
(une aide au trac de lignes horizontales ou verticales ncessite uniquement un blocage conditionnel des valeurs en x ou y dans la conguration), ou la grille magntique de bas-niveau. Toutes ces
techniques gomtriques permettent dajouter des fonctionnalits des applications interactives sans
modier le code de celles-ci.
Pour nir, nous dcrirons une technique assimilable un pointage augment, le curseur vocal.
Un pointeur est contrl laide de commandes vocales agissant sur sa direction et sa vitesse, et deux
autres commandes permettent de simuler lappui et le relchement du bouton de la souris. Le temps
de reconnaissance, de lordre de la seconde pour la plupart des moteurs, pose dimportants problmes
pour le contrle positionnel. Notre technique du curseur vocal permet de prendre en compte le contexte
dune commande, cest--dire le moment o cette commande a commenc tre prononce.
F IG . 4.32 Exemple dutilisation du curseur vocal. Les mots gris sont les mots prononcs, et les mots en noir
sont les mots reconnus. Les images ont t retouches pour rendre compte des mouvements du pointeur.
Le curseur vocal est compos dun curseur effectif et dun curseur contextuel (gure 4.32). En
temps normal, ils se dplacent de faon solidaire. Lorsque lutilisateur commence parler (augmentation brutale du niveau dentre), le curseur contextuel sarrte et le curseur effectif continue se
dplacer. Si un bruit ou une commande non-contextuelle (contrle de la vitesse) est nalement reconnue, le curseur contextuel rejoint le curseur effectif. Si une commande contextuelle (changement
de direction ou appui/relchement) est reconnue, le curseur effectif rejoint le curseur contextuel et la
commande est valide.
La conguration dentre de la gure 4.33 page ci-contre dcrit le gros du mcanisme du curseur vocal. Un dispositif SpeechCursor effectue les principaux calculs en dterminant les positions
successives des deux curseurs en fonction des commandes reues. Le dispositif de commande vocale
est congur conformment aux commandes supportes par SpeechCursor, et est reli au dispositif de synthse vocale an davoir un retour sur les commandes reconnues. Dans cette variante de
4 Nous avons galement tendu le dispositif DJScrollbar pour quil puisse tre manipul avec une prcision suprieure
celle du pixel. Le dlement dun document peut ainsi tre contrl nement par un pointage de second ordre mais aussi
par tout dispositif de type tablette. Lafchage du curseur a galement t modi pour utiliser une interpolation linaire.
138
F IG . 4.33 Une conguration dcrivant la technique de pointage vocal.
pointage augment, les deux curseurs sont situs au mme niveau dans la conguration. En effet, le
dplacement de chacun des deux curseurs est fonction de lautre.
Le dispositif SpeechCursor, principal dispositif de cette conguration, est un dispositif composite
construit avec des dispositifs utilitaires de base. Celui-ci est relativement complexe : il comporte 17
dispositifs et emploie un dispositif composite lui-mme constitu de 21 dispositifs de base. Nous y
reviendrons dans la section 5.4 page 157 lorsque nous dvelopperons le problme de la complexit.
Les techniques dinteraction avances cls en main
Avec la technique du curseur vocal vue prcdemment, nous ne sommes plus trs loin des limites
pratiques de la construction de comportements complexes partir de briques de base. Pour dcrire
des techniques dinteraction complexes, lemploi de dispositifs scriptables ou limplmentation de
dispositifs monolithiques sont des solutions privilgier.
Les techniques dinteraction implmentes sous forme de dispositif, prtes lemploi , rendent
possible la description rapide dinterfaces volues. La bibliothque dICON comporte actuellement
trois de ces techniques dinteraction, toutes trois bases sur la semi-transparence : la Toolglass, le
Floating Quikwriting, et le dispositif de Commande Gestuelle.
Le dispositif Toolglass permet danimer une barre doutils semi-transparente, manipulable en interaction bimanuelle. Ce dispositif implmente la technique dinteraction de mme nom (voir section 1.3.3 page 19), avec de plus une transparence contrlable. La prsentation visuelle de cette barre
doutils (liste et disposition des icnes afcher) est spcie dans la fentre de proprits du dispositif (gure 4.34 page suivante).
Les slots x et y de la toolglass ont fonction de picking : lorsque son slot use est vrai, le dispositif
met vrai sur lun des slots de tool selon loutil qui se trouve la position donne. Cette position est
galement retransmise en sortie sur les slots xthru et ythru. Dans la conguration de la gure 4.34
page suivante, chaque slot boolen de tool est connect au slot activate dun curseur ddi (seul le
contrle de loutil Freehand est reprsent ici, les autres tant similaires). Lorsquaucune icne na
t slectionne, le curseur actif est le curseur par dfaut (en haut sur la gure). Dans le cas contraire,
un autre curseur est activ (en bas sur la gure), et travers lui, loutil correspondant. Pour nir, la
toolglass peut tre dplace travers ses slots xmove et ymove, et sa transparence peut galement tre
139
F IG . 4.34 Branchement de la technique dinteraction Toolglass dans ICONDraw.
contrle. Ici, lemplacement et la transparence de la barre doutils sont simultanment contrles au

stylet et les outils sont contrls la souris.
F IG . 4.35 Scnario dutilisation de la technique dinteraction Floating Quikwriting dans Swing. Ici, lutilisateur supprime une espace et insre un saut de ligne en un geste rapide.
Le dispositif QuikWrite implmente une version semi-transparente de la technique dinteraction

gestuelle de mme nom (voir section 1.3.2 page 16), appele Floating QuikWriting. Au lieu dtre xe,
la zone de saisie gestuelle est ottante et est solidaire dun pointeur en forme de caret (gure 4.35).
Dans le mode pointage, la position de lensemble est contrle par un dispositif positionnel. Lors du
passage au mode gestuel (bouton enfonc), le curseur textuel est dplac la position du pointeur, et
lobjet ottant simmobilise pour passer la main son curseur gestuel interne.
Cette technique est efcace pour la rvision de documents, car des ditions simples comme la
suppression ou linsertion dun caractre dans le texte se font en un geste rapide, et parce quelle ne
requiert pas de changement de dispositif entre la navigation et la saisie.
Le dispositif QuikWrite reoit simplement des vnements positionnels et les transcrit en com140
4.5. DISTRIBUTION, CONTRIBUTEURS, ET PROJETS UTILISANT IC ON
F IG . 4.36 Conguration dentre pour lutilisation du Floating Quikwriting dans Swing.
mandes boolennes, en plus de produire un retour graphique. La conguration de la gure 4.36 illustre
son utilisation avec les composants texte de Swing.
Implment rcemment, le dispositif GestureCmd offre une prise en charge de linteraction gestuelle conventionnelle. Il repose sur le moteur de classication de Satin [H ONG & L ANDAY 00] dont il
emploie galement les vocabulaires prdnis et linterface dentranement. La fentre de proprits du dispositif permet de lancer celle-ci, et de paramtrer laspect de la trace afche en incrustation. Le dispositif de commandes gestuelles met, en plus des commandes et des classes de commandes reconnues, des proprits gomtriques telles que le rectangle englobant, le point de dpart
et le point darrive du geste. Nous avons employ ce dispositif pour dessiner des formes gomtriques dans ICONDraw et pour saisir du texte dans les applications Swing avec lalphabet Grafti [M AC K ENZIE & Z HANG 97].
4.5 Distribution, contributeurs, et projets utilisant ICON

La version actuelle de la bote outils ICON comporte approximativement 400 classes (dont la
moiti est employe pour dcrire les dispositifs de la bibliothque et leurs processeurs spcialiss)
et approximativement 20 000 lignes de code (dont un tiers est consacr lditeur interactif). Elle a
t dveloppe par lauteur, exceptes certaines parties, en particulier lapplication ICONDraw dveloppe par Jean-Daniel Fekete, les dispositifs GestureCmd et VirtualUser implments par Stphane
Huot, et les dispositifs de la X Input Extension implments par Stphane Conversy. ICON repose en
outre sur un bon nombre dAPIs dentre pour la prise en charge des dispositifs physiques (voir la
section 4.2.1 page 111 pour plus de dtails).
Une distribution en version alpha dICON est en libre tlchargement ladresse suivante : http://www.emn.fr/x-inf
En dehors des applications-jouet voques dans ce chapitre, ICON est actuellement utilis pour
la conception de deux applications interactives dans le cadre du projet GINA (Gomtrie Interactive
et Naturelle) [CMI 02]. Ce projet a pour objectif de fournir des outils de reconstruction 3D partir de
vues 2D en perspective et de contraintes spcies de manire multimodale. Les applications sont les
141

suivantes :
Marina II [CMI 02] est une application de reconstruction de scnes 3D partir de photographies
bas sur le solveur de contraintes GINA. Dveloppe avec Swing, cette application comporte
dj un premier niveau de congurabilit travers les dispositifs Swing dICON. Elle externalise
en outre des dispositifs simples de type commande an de permettre la conguration des
actions. Par exemple, les changements de vue peuvent tre contrls avec le bouton droit de la
souris ou par des commandes vocales.
Svalabard [CMI 02] est un projet dinterface Post-WIMP de modlisation 3D par croquis, employant une approche centre utilisateur et se basant notamment sur des tudes portant sur les
techniques de dessin darchitectes [H UOT et al. 03]. Cette application emploie actuellement une
tablette graphique et des ltres pour construire et traiter les traces, et dtecter le contexte du
dessin (gure 4.37). Ces ltres sont des dispositifs ICON, ce qui permet de dcrire et tester
aisment des mcanismes de ltrage et les afner dynamiquement.
F IG . 4.37 Filtres de dessin dans Svalabard [H UOT et al. 03].

ICON est galement employ dans un projet du LRI visant valuer lefcacit des techniques
dinteraction Post-WIMP pour diffrents types de tches [A PPERT et al. 03]. Il a servi dans ce projet
monter une exprimentation contrle o plusieurs techniques de slection doutils (toolglass, palette
doutils classique et palette doutils bimanuelle) sont compares dans des tches simples.
Il existe pour nir deux projets de botes outils graphiques reposant sur ICON :
PiccoloIcon : Nous avons dj expriment quelques techniques dinteraction avec la bote
outils zoomable Jazz [B EDERSON et al. 00], dont une que nous avons voqu dans ce chapitre. Des
travaux sont actuellement en cours pour intgrer ICON de manire complte et raisonne la
bote outils Piccolo [B EDERSON 03], le successeur de Jazz.
MagLite [H UOT 03] est une bote outils graphique Post-WIMP en cours de dveloppement
par lauteur de Svalabard, reposant intgralement sur ICON pour la gestion des entres. Elle
permet de construire aisment des objets interactifs de forme quelconque et manipulables en
translation, taille et rotation avec ICON. Elle permet galement de dcrire et dassocier des
outils ces composants. Bien que cette bote outils ne soit quen cours de ralisation, la
palette des techniques dinteraction Post-WIMP connues ou indites pouvant tre dcrites est
dj trs vaste.
4.6 Conclusion
Nous avons dcrit ICON, une bote outils dentre dont lobjectif est de rsoudre les principaux
problmes lis ladaptabilit en entre actuellement non abords par les botes outils graphiques.
142
4.6. CONCLUSION
Nous avons principalement montr travers des exemples quICON permettait de construire aisment
une grande varit de techniques dinteraction Post-WIMP et daccessibilit, existantes ou indites, et
que ces techniques une fois construites taient extrmement congurables.
La bote outils en entre ICON est un projet vaste, qui a mis longtemps atteindre la maturit
ncessaire pour commencer tre utilis dans des applications grandeur nature. Les utilisateurs ayant
employ ou employant ICON sont pour lheure trs satisfaits de cet outil, car il leur ouvre des possibilits que nul autre nest actuellement en mesure de fournir. Ces utilisateurs ont galement, par leurs
remarques, grandement contribu son amlioration. En distribuant librement ICON, nous esprons
la fois populariser notre approche dans le monde du dveloppement et de la recherche, la valider par
un nombre plus important dapplications, et obtenir des retours constructifs an damliorer ICON.
ICON fournit des solutions indites la plupart des problmes lis linteraction en entre, mais
ne prtend pas les rsoudre tous. Il ne prtend pas non plus luniversalit. Dans le chapitre suivant,
nous analyserons les forces et les faiblesses de notre approche en gnral et dICON en particulier, et
tenterons galement de rpondre aux nombreuses questions quelles ouvrent.
143
144
Chapitre 5
Discussion
Sommaire
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les apports dICON du point de vue architectural . . . . . . . . .
5.2.1 Architecture concrte des systmes interactifs . . . . . . . . .
5.2.2 Les niveaux daccs et de contrle dICON . . . . . . . . . .
5.2.3 Une gestion des entres entirement explicite . . . . . . . . .
Pertinence du modle pour les interactions Post-WIMP . . . . . .
5.3.1 Limitations du langage et pouvoir dexpression . . . . . . . .
5.3.2 Prise en compte des dispositifs non conventionnels . . . . . .
5.3.3 Description de techniques dinteraction non conventionnelles .
Complexit et lisibilit . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Le rle de la structuration spatiale . . . . . . . . . . . . . . .
5.4.2 Les limites du tout-visuel . . . . . . . . . . . . . . . . . . . .
5.4.3 Complexit et nature de linteraction . . . . . . . . . . . . . .
Caractrisation des diffrents types de dispositifs . . . . . . . . . .
5.5.1 Les dispositifs systme dentre . . . . . . . . . . . . . . . .
5.5.2 Les dispositifs dapplication et de bote outils . . . . . . . .
5.5.3 Les dispositifs utilitaires . . . . . . . . . . . . . . . . . . . .
Dvelopper avec ICON . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Matriser un nouveau paradigme de programmation . . . . . .
5.6.2 Connexion avec les outils et applications existantes . . . . . .
5.6.3 La rutilisabilit des congurations . . . . . . . . . . . . . .
5.6.4 La prise en charge effective des dispositifs dans ICON . . . .
5.6.5 Les performances . . . . . . . . . . . . . . . . . . . . . . . .
Les utilisateurs dICON . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1 Un continuum dutilisateurs . . . . . . . . . . . . . . . . . .
5.7.2 Les utilisateurs avancs . . . . . . . . . . . . . . . . . . . . .
5.7.3 Utilisateurs scientiques et informaticiens . . . . . . . . . . .
5.7.4 Dveloppeurs . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.5 Le cycle de vie dune conguration . . . . . . . . . . . . . .
Positionnement de notre approche et perspectives . . . . . . . . .
5.8.1 ICON et les autres approches . . . . . . . . . . . . . . . . . .
5.8.2 Quelques perspectives . . . . . . . . . . . . . . . . . . . . .
145
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
147
147
147
148
150
151
152
154
155
157
157
159
160
161
162
163
166
166
166
169
171
172
173
174
174
174
176
176
177
177
177
180
CHAPITRE 5. DISCUSSION
146
5.1. INTRODUCTION
5.1 Introduction
Dans ce chapitre, nous identions les apports essentiels dICON, ainsi que ses limites, la fois
celles qui sont inhrentes notre modle et celles pour lesquelles nous pensons pouvoir proposer des
solutions. Nous gnraliserons galement quelques aspects de notre approche.
Dans un premier temps, nous expliquons comment ICON tend larchitecture des systmes interactifs actuels pour rendre la gestion des entres explicite. Puis, nous tentons de dterminer dans quelle
mesure ICON et son modle sous-jacent sont pertinents pour dcrire les paradigmes dinteraction non
conventionnels voqus dans le premier chapitre, et poursuivons avec les problmes de complexit et
de lisibilit relatives au langage visuel.
Nous gnralisons et dtaillons galement le rle des diffrents types de dispositifs, et en particulier les services que doivent fournir ICON les dispositifs de bote outils et dapplication.
Nous analysons ensuite la pertinence dICON du point de vue du programmeur, en abordant diffrentes considrations dordre pratique. Puis, nous voquons les diffrents utilisateurs auxquels ICON
sadresse.
Pour nir, nous comparons ICON avec les approches existantes et proposons quelques perspectives, avant daborder la conclusion gnrale de cette thse.
5.2 Les apports dICON du point de vue architectural

ICON repose sur des systmes interactifs conventionnels (systme dexploitation + bote outils),
systmes dont nous avons dj dcrit les limites dans le chapitre 1 (section 1.4.3 page 30). Mais
linverse de ces systmes il permet de dcrire la manire dont les entres sont gres dans un modle
clair et consistant. Dans cette section, nous identions les diffrents niveaux de gestion des entres
dans les systmes interactifs rels, puis nous montrons la faon dont ICON parvient tendre ce type
de systme, et ce que cette extension apporte.
5.2.1
Architecture concrte des systmes interactifs
Dans les systmes interactifs actuels, les applications sappuient essentiellement sur des services
partags fournissant une gestion standard des entres. Dans ces systmes, les techniques dinteraction
standard sont implmentes sur plusieurs niveaux (gure 5.1 page suivante) :
Niveau matriel : Les entres peuvent tre gres en partie au niveau matriel, par llectronique du dispositif. Cest le cas par exemple des boutons de tir automatique sur certaines
manettes de jeux, similaires la fonction de rptition de touches du clavier. Ces mcanismes
peuvent tre vus comme des techniques dinteraction.
Niveau systme : Au niveau du systme dexploitation, les pilotes de dispositifs fournissent au
programmeur des abstractions de bas niveau pour lire les donnes en provenance des dispositifs.
Les pilotes ont galement pour charge de transformer les donnes spciques en informations
interprtables par le gestionnaire dentres standard du systme dexploitation. Certains pilotes
de dispositifs non standard permettent ainsi un contrle par compatibilit en imitant le comportement dun clavier ou dune souris. Le gestionnaire dentres standard du systme dexploitation fournit des services relatifs aux dispositifs standards, tels que lafchage dun pointeur
147
TECHNIQUES D'INTERACTION
Matriel
Dispositifs
Systme
Pilotes
B. Outils
Gestionnaire
d'entres
Routeur
Entres
standard
Application
Widgets
UI
Application
Evnements
standard
Autres
entres
Donnes spcifiques
aux dispositifs
F IG . 5.1 Architecture concrte dun systme classique, mettant en vidence les diffrents niveaux dimplmentation des techniques dinteraction standard.
ou la gestion de la langue du clavier, et produit les vnements propres ces dispositifs. Un

premier routage de ces vnements est effectu par le gestionnaire de fentres, qui les transmet
la fentre concerne.
Niveau bote outils : La bote outils graphique sur laquelle repose lapplication interactive
se charge, pour chaque fentre, de router les vnements vers les widgets appropris. Il existe
deux stratgies standard de routage : le multiplexage spatial pour les vnements positionnels, et
le multiplexage temporel bas sur les techniques de focus. Ces stratgies de routage constituent
des techniques dinteraction. Chaque widget de la bote outils gre son tour une technique
dinteraction gnrique. Dans les botes outils qui suivent une approche MVC, le modle dun
widget est distinct de sa vue et de son contrleur (regroups dans un objet UI dans le langage
Java). Dans cette approche, les objets modle peuvent tre considrs comme des briques de
base de lapplication.
Niveau applicatif : Si les modles conceptuels dinteraction recommandent une sparation
franche entre linteraction et le noyau applicatif, cette sparation est difcile mettre en uvre
en pratique. En outre, les limitations inhrentes aux botes outils obligent souvent limplmentation de techniques dinteraction spciques au niveau de lapplication.
5.2.2
Les niveaux daccs et de contrle dICON
La gure 5.2 page ci-contre montre comment ICON sinsre dans un systme interactif concret.
ICON est une bote outils dentres qui sinterpose entre le systme dexploitation et lapplication.
Lorsquil est intgr une bote outils graphique comme Swing, il sinsre entre ses mcanismes de
routage vnementiel et ses widgets. ICON peut servir tendre la gestion standard des entres, mais
est galement capable de grer la quasi-totalit de linteraction des dispositifs dentre lapplication.
Le rle jou par ICON dans la gestion des entres dpend essentiellement de la manire dont il accde
aux entres et de la faon dont il contrle lapplication.
ICON accde aux entres deux niveaux :
Accs aux vnements standard : ICON peut tre contrl par des vnements standard,
148
5.2. LES APPORTS DIC ON DU POINT DE VUE ARCHITECTURAL
Matriel
Systme
BO
Dispositifs Pilotes Gest. Routeur

d'entres
ICon
BO
Application
Configurations d'entre Widgets
Application
Contrle par dfaut
Entres
Standard
Evts
standard
Autres
Entres
UI
Contrle
gnrique
de surface
Contrle
gnrique
de modle
Contrle
ddi
Accs
bas-niveau
Dispositifs
d'appli.
F IG . 5.2 Un systme interactif concret intgrant ICON.
travers des dispositifs qui lisent dans la le dvnements du systme dexploitation ou de la

bote outils. Ces derniers possdent lavantage dtre portables dune plate-forme une autre.
Le dispositif clavier de Swing (voir section 4.2.1 page 111) en est un exemple.
Accs bas niveau aux dispositifs : ICON accde principalement aux dispositifs dentre au
niveau bas, ce qui permet de tirer parti des spcicits des dispositifs non conventionnels,
mais galement de celles des dispositifs standard. Ainsi, un dispositif de souris bas-niveau peut
mettre des donnes positionnelles non contraintes aux bords de lcran (voir section 4.2.1
page 111).
ICON peut contrler une application interactive de quatre manires diffrentes. Les niveaux de
contrle dune application, du plus superciel au plus profond, sont les suivants :
Le contrle par dfaut : Ce niveau dsigne le contrle dune application hors ICON . ICON
permet de conserver la gestion des entres effectue implicitement au niveau systme et bote
outils, et de ltendre ou non avec des interactions dcrites explicitement. Par exemple, une
application de modlisation 3D conventionnelle peut tre tendue pour prendre en compte la
manipulation 3D avec des dispositifs ddis. Les diffrents mcanismes standard de gestion
des entres peuvent galement tre dsactivs (voir section 4.2.3 page 114) pour tre rednis
de faon explicite ou tre remplacs par des techniques dinteraction alternatives.
Le contrle gnrique de surface : Ce niveau dsigne les stratgies de contrle positionnel
gnrique des widgets de la bote outils, travers des dispositifs manipulateurs de surface
(section 4.2.3 page 114). Cest ce niveau que peuvent tre explicitement rednies des techniques dinteraction standard telles que le picking. Certaines congurations dcrites dans notre
chapitre sur la bote outils ICON constituent des exemples de contrle gnrique de surface :
le contrle positionnel standard des composants Swing (gure 4.18 page 131), le contrle au
clavier du focus et du clic (gure 4.20 page 132), et linteraction Swing avec des pointeurs
multiples (gure 4.22 page 133).
Le contrle gnrique de modle : Ce niveau comprend les stratgies de contrle spciques
un type de widget, dcrites travers des dispositifs manipulateurs de modle (section 4.2.3
page 114). Avec le niveau prcdent, il permet de spcier des stratgies daccessibilit gn149
riques compatibles avec les applications existantes. Le contrle de modle est gnrique en ce
sens quil nest pas ddi une application particulire, mais il est cependant plus spcique
que le prcdent, car il dcrit des interactions avec une classe de widget donne. La conguration de la gure 4.27 page 135, qui dcrit le contrle des barres de dlement la voix,
en est un exemple. Le contrle dune interface zoomable (gure 4.25 page 134) est un exemple
dutilisation de manipulateurs de modle dans une bote outils graphique non conventionnelle.
Le contrle ddi : Ce niveau dcrit le contrle dune application interactive travers des
dispositifs dapplication. Cest le niveau de contrle le plus puissant, car il permet de dcrire
des techniques dinteraction ddies la tche. Il ne concerne cependant que les applications qui
ont t dveloppes pour tre compatibles avec ICON, ou des applications qui ont t modies
dans ce sens. Les dispositifs dapplication sont en principe spciques une application donne,
mais il est galement possible dimaginer des librairies de dispositifs rutilisables adapts un
type particulier dapplication. ICONDraw est un exemple dapplication qui supporte le contrle
ddi comme le dessin la tablette graphique (gure 4.24 page 134).
5.2.3
Une gestion des entres entirement explicite
Nous avons vu quICON permettait de court-circuiter une bonne partie des services du systme
dexploitation et de la bote outils an de grer la quasi-totalit de linteraction en entre. Cette
dernire option est la plus avantageuse car elle remplace lensemble des botes noires standard par
une bote blanche hautement congurable.
Matriel
Clavier
Gnrateur
de codes touches
Systme
Gnrateur
de symboles
B. Outils
Gnrateur
de caractres
Application
JText
F IG . 5.3 La cascade de traitements dans un systme interactif classique, vue de lapplication. Le dispositif
concret na pas dexistence, et les traitements bas-niveau sont cachs.
La gure 5.3 reprend lexemple de la gestion standard du clavier initialement introduit dans la
section 3.2.5 page 98 [F EKETE & D RAGICEVIC 00]. Certaines fonctionnalits comme la rptition des
touches, la mmoire tampon, et la gestion des voyants nont pas t mis en vidence dans cette
exemple, mais celui-ci reproduit nanmoins les principaux mcanismes de gestion du clavier prsents
dans tous les systmes interactifs existants. Comme voqu prcdemment, la gestion des entres est
rpartie entre diffrents acteurs, de llectronique du dispositif jusqu lapplication.
Si une grande partie de la gestion des dispositifs dentre dans les systmes interactifs actuels
peut tre dcrite par de telles cascades de dispositifs, cette structuration est toujours implicite : les
adaptateurs ne sont pas toujours bien distincts, les tches de traitement sont dissmines travers
diffrentes couches tanches, et il nexiste nalement pas de mcanisme fournissant une vision globale
de la chane complte de ces traitements. Bien que les systmes dexploitation produisent parfois des
donnes plusieurs niveaux dabstraction pour rpondre aux besoins des applications et des botes
150
5.3. PERTINENCE DU MODLE POUR LES INTERACTIONS POST-WIMP

outils (par exemple, symbole ou code touche en plus du caractre), la partie bas-niveau des traitements
relatifs un dispositif concret est entirement cache, ce qui restreint considrablement le champ
daction du dveloppeur (gure 5.3 page ci-contre).
ICon
Matriel Sys.
Clavier
Gnrateur
de codes touches
Gnrateur
de symboles
Application
Gnrateur
de caractres
F IG . 5.4 Les diffrents niveaux dabstraction du clavier, explicits par la cascade de dispositifs.
linverse, ICON est capable dexposer de faon explicite le dispositif physique1 et tous les traitements effectus en amont. Chez le dveloppeur, la vision synthtique et vnementielle dun dispositif
dentre est alors remplace par une vision niveaux multiples. Le niveau le plus bas est le dispositif
concret : le clavier concret est une bote boutons, chacun de ces boutons comportant deux tats.
Cette vision mcanique du clavier est celle quexprimente lutilisateur. Ensuite, chaque adaptateur
supplmentaire joue le rle dun oprateur logique qui transforme successivement un clavier concret
en clavier spatial, puis symbolique, et enn textuel (gure 5.4). Selon ses besoins, lapplication peut
se greffer chacun de ces niveaux : un clavier textuel est pertinent pour une application de traitement
de texte, mais un clavier plus bas niveau est mieux adapt des actions telles que le dplacement dun
curseur (gure 5.4). Il est en outre vident quune telle modularit procure une congurabilit bien
plus importante.
5.3 Pertinence du modle pour les interactions Post-WIMP

Nous avons montr dans le premier chapitre lintrt des dispositifs dentre non standard et des
paradigmes dinteraction post-WIMP. Il est par consquent utile de dterminer dans quelle mesure
les outils fournis par ICON et le modle des dispositifs en cascade sur lequel il repose permettent de
dcrire ces nouveaux dispositifs et paradigmes dinteraction.
Nous commencerons par voquer les limitations inhrentes au langage dICON et leurs consquences sur la description de techniques dinteraction en gnral. Puis, nous nous demanderons si
notre modle permet de prendre en compte lensemble des dispositifs non-standard existants et ve1 Si le plus bas niveau visible est en pratique celui fourni par le pilote de dispositif, des niveaux plus bas peuvent tre
reconstruits par rtro-conception , comme nous lavons fait pour les canaux boolens de notre dispositif clavier. Cependant, nous savons dj que de linformation est perdue au l des traitements et des abstractions. [ACCOT et al. 97] donne un
bon aperu de ce type de problme.
151
nir. Enn, nous tenterons de dterminer en quoi notre approche est adapte ou non la description des
diffrents paradigmes dinteraction non-standard voqus dans le premier chapitre.
5.3.1
Limitations du langage et pouvoir dexpression
Le langage ot de donnes dICON comporte certaines limitations inhrentes. Nous les justions
ici, et dcrivons en quoi elles ne nuisent pas rellement son pouvoir dexpression.
Unicit des connexions en entre
ICON nautorise pas les connexions multiples sur un seul slot dentre, ce type de connexion
ntant pas souhaitable dans un paradigme ractif. En effet, plusieurs signaux peuvent converger pendant un tick l o lon suppose quun seul signal (et une seule valeur) peut tre stock. La mthode
consistant conserver le dernier signal induit un comportement non-dterministe car lordre dans
lequel arrivent les signaux nest pas connu.
Dans ICON, les signaux ncessitent dtre fusionns explicitement par des dispositifs de type
oprateur mathmatique ou logique. Cette mthode prsente lavantage dtre dterministe, et permet
lutilisateur de choisir librement la faon dont il veut combiner plusieurs sources de donnes sur un
seul slot dentre.
Staticit
Les congurations dentre sont statiques : elles ne peuvent pas tre modies pendant lexcution. Cest en particulier le cas des connexions. Or les techniques dinteraction comportent la fois
des connexions statiques (la souris bouge toujours le mme curseur) et des connexions dynamiques
(le curseur contrle diffrents objets). En effet, sil est envisageable daffecter un dispositif un objet
de faon permanente (par exemple, le contrle du volume), le nombre de dimensions contrlables
dune application est souvent suprieur aux dimensions disponibles en entre, do la ncessit dun
multiplexage spatial ou temporel.
Le multiplexage peut cependant tre dcrit avec ICON, de deux manires diffrentes. La premire
repose sur des techniques dactivation slective : les sorties dun dispositif sont connectes de faon
permanente aux entres de plusieurs dispositifs comportant chacun un slot boolen dactivation, et un
mcanisme de slection sassure quun seul dentre eux est actif la fois. La conguration montrant
un usage de la Toolglass dans ICONDraw constitue un exemple dactivation slective (voir gure 4.34
page 140).
La deuxime technique de multiplexage emploie des passages de rfrence : un dispositif agit sur
lobjet qui lui a t transmis en entre par un autre dispositif, et est capable changer dobjet dintrt
tout moment. Les slecteurs et les manipulateurs dcrits dans la section 4.2.3 page 114 emploient
cette technique, et sont notamment utiliss dans la conguration dcrivant le contrle des composants
Swing (voir gure 4.18 page 131).
Autoriser des reconnexions dynamiques dans les congurations dentre compliquerait signicativement le modle dexcution, et serait source de confusions importantes si le problme de la
reprsentation visuelle adquate nest pas tudi srieusement. Cependant, si notre approche dacti152

vation slective rend explicite lensemble des ux de donnes possibles, elle ne dcrit pas clairement
pourquoi et quand les donnes empruntent un chemin plutt quun autre. Nous reviendrons sur ce
problme dans la section 5.8.1 page 179 lorsque nous voquerons les systmes transitions.
Acyclisme
Nous distinguons deux types de cycles : les cycles explicites, qui sont internes la conguration,
et les cycles implicites, qui transitent par lenvironnement. Nous les dcrivons sparment.
Les cycles explicites. En tant que langage ractif, ICON nautorise pas les dpendances cycliques
directes : lalgorithme de sa machine ractive repose sur lexistence dun ordre partiel entre les dispositifs, qui garantit lexcution de chaque tick en un temps ni. La plupart des langages ractifs
rsolvent ce problme en autorisant les cycles avec un oprateur de retard, qui transmet le signal au
tick suivant.
Un oprateur de retard peut galement tre implment dans ICON pour permettre de dcrire des
cycles explicites, cest--dire des cycles internes la conguration. Cependant nous navons jamais eu
besoin de tels cycles, sauf une seule reprise, lorsque nous dcrivions un comportement un niveau
de granularit trs n2 . Les cycles de ce type traduisent des mcanismes internes qui se situent, selon
nous, un niveau trop bas pour tre pertinent du point de vue de la personnalisation de linteraction.
Notre exprience a montr qu un certain niveau de granularit, les comportements peuvent tre tous
dcrits sans faire appel des cycles.
Nous pensons plus gnralement que les ux unidirectionnels de donnes, o contrleurs et
contrls sont clairement spars, constituent un bon modle structurant pour linteraction en entre 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 lavons vu dans la section 3.2.5 page 98), linterprtation des actions
de lutilisateur ne dpend pas de ltat du systme en aval.
Les cycles implicites. Linformation peut transiter dans nimporte quel sens dans une conguration ICON en passant par les entres/sorties implicites. Nous qualions ce type de cycle dimplicite,
car il transite par lenvironnement. Le comportement dun dispositif pick, par exemple, dpend de
lagencement spatial des objets quil sert en partie manipuler. Les cycles implicites sont utiles car
ils permettent une conguration dentre deffectuer, travers des points de retour comme le pick,
des requtes dans lapplication ou la bote outils tout en la contrlant.
Les seuls cycles qui nous semblent essentiels dans linteraction sont par consquent ceux qui
rsultent de la communication double sens entre le contrle et la vue dune part (pour le pick, par
exemple), et entre le contrle et le modle dautre part (pour le retour smantique). Ces cycles sont
tous implicites et peuvent tre dcrits par des points de retour. Ils remettent en cause notre modle
unidirectionnel, mais seulement un niveau de la cascade o la communication bidirectionnelle avec
la vue et le modle devient ncessaire.
2 Chacun des deux pointeurs dcrit par notre technique de curseur vocal (gure 4.33 page 139) peut tout moment
prendre la position de lautre. Ce mcanisme a t dcrit dans ICON dans un dispositif composite (gure 5.8 page 159) en
maintenant jour lcart entre les deux positions, comportement qui aurait pu tre dcrit plus simplement par lusage dun
cycle.
153
5.3.2
Prise en compte des dispositifs non conventionnels
Les dispositifs dentre non standard sont extrmement nombreux et varis, et de nouveaux dispositifs apparaissent rgulirement sur le march ou dans le monde de la recherche. Il est par consquent
indispensable de disposer dun modle assez gnral pour prendre en compte les dispositifs existants
et ceux venir.
Le modle base de canaux structurs sur lequel repose ICON est la fois trs simple et trs
gnral. Les canaux ont t largement employs dans les modles de dispositifs dentre, et sont
aujourdhui adopts par les principaux standards [USB/HID 01]. En effet, tout dispositif dentre peut
tre dcompos en un ensemble de canaux atomiques. La faiblesse des modles existants provient
non pas de cette dcomposition en canaux mais dune classication ge des dispositifs, qui les rend
peu volutifs et ne permet pas dexploiter les capacits propres chaque dispositif. ICON rsout le
problme en vacuant toute notion de classe ad-hoc. Nanmoins, dans certains cas particuliers que
nous dtaillons ici, notre modle peut montrer certaines faiblesses.
Les dispositifs grand nombre de dimensions
F IG . 5.5 Deux dispositifs grand nombre de dimensions : le cube dformable [M URAKAMI et al. 95] et la table
Smartskin [R EKIMOTO 02].
La dcomposition en canaux rencontre des difcults dans les cas de dispositifs dentre possdant un trs grand nombre de dimensions. Le cube dformable de Murakami et al [M URAKAMI et al. 95],
reprsent sur la gure 5.5 est une structure recouverte de mousse qui comporte 90 degrs de libert interdpendants. Le dispositif Smartskin de Rekimoto [R EKIMOTO 02], dj prsent au premier chapitre
et illustr sur la gure 5.5, image de droite, est une matrice de 72 (ou 768 selon le modle) capteurs
capacitifs. Les nombreux canaux de ces dispositifs seraient pnibles connecter individuellement. En
outre, la reprsentation en liste de slots dans ICON nest pas adapte des canaux disposs en matrice. Mme si ICON permet dorganiser ces canaux multiples en un unique slot composite, ceux-ci se
comporteraient du point de vue de la machine ractive comme des canaux individuels dont la gestion
resterait lourde.
Une solution consiste modliser ces dispositifs un plus haut niveau (par exemple, remplacer la
matrice de Smartskin par une liste de pointeurs), avec cependant pour inconvnient de faire disparatre
le dispositif concret et de rendre implicite une partie importante de la chane de traitements. Pour le
154

dispositif clavier dICON, une solution intermdiaire a t implmente, o chaque touche (boolen)
est accessible individuellement, en mme temps que le code (entier) de la dernire touche appuye ou
relche. Cette redondance est ncessaire, car les deux structures sont pertinentes, selon lutilisation
que lon dsire faire du clavier dans la conguration dentre.
Les dispositifs trs haut dbit dinformations
Certaines entres comme les signaux audio ou vido mettent des ux de donnes extrmement
denses. Ces entres provoquent une premire difcult dordre technique, car le langage Java nest
actuellement pas capable de traiter un tel dbit en temps rel, traitement qui est habituellement implment au niveau matriel ou dans un langage trs bas niveau. Mais surtout, il est difcile de faire
cohabiter dans une mme machine ractive des algorithmes de traitement de nature totalement diffrente, car son temps de raction total est au moins gal celui du dispositif le plus lent. Or la
ractivit nest quune question dordre de grandeur : pour la plupart des congurations dentre, un
temps de rponse comparable au taux de rafrachissement de lcran (de lordre de 100 Hz) est plus
quacceptable du point de vue de linteraction ; pour les applications de reconnaissance gestuelle, la
frquence acceptable est de lordre de 1000 Hz, comparable celle dune tablette graphique ; pour les
applications de traitement de signal audio, la frquence est de lordre de 10000 Hz.
Dans ICON, il est possible de faire communiquer par des entres/sorties implicites plusieurs congurations dentre qui sexcutent des vitesses diffrentes. Cependant, tout comme pour le problme
prcdent, les dispositifs trs haut dbit gagneraient tre modliss plus haut niveau, quitte violer notre principe selon lequel les dispositifs doivent tre dcrits un niveau trs bas. En effet, dans un
systme interactif un chantillon audio isol na pas plus de sens quun pixel provenant dune camra,
et il est plus judicieux de transmettre travers les canaux de ces dispositifs des paquets audio et vido. Le dispositif de commande vocale actuellement implment dans ICON est un dispositif dentre
pur, le ux dinformations entre le microphone et le moteur de reconnaissance vocale tant implicite. Les traitements en amont sont par consquent congurs par paramtrage du dispositif (mots
reconnatre) au lieu dtre reprsents explicitement dans ICON.
5.3.3
Description de techniques dinteraction non conventionnelles
partir dun nombre limit de dispositifs fournissant les services de base, les possibilits offertes
par ICON pour dcrire des techniques dinteraction existantes ou indites sont extrmement nombreuses. Nous avons construit et test approximativement une centaine de congurations dentre, et
nous ne pouvons malheureusement pas toutes les voquer. Dans le chapitre prcdent, nous avons
essay den fournir un chantillon reprsentatif.
Les techniques dinteraction non conventionnelles proposes dans la littrature scientique sont
nanmoins extrmement nombreuses, et nous navons pas pu toutes les dcrire ce jour. Dans cette
section, nous exploitons toutefois les rsultats obtenus avec les techniques dj implmentes et tentons de dterminer les capacits potentielles dICON pour les autres, dans le but didentier les caractristiques des paradigmes non conventionnels par rapport auxquelles ICON est pertinent et celles pour
lesquelles il lest moins. Nous avons identi un certain nombre de ces caractristiques qui ncessitent
une prise en charge spcique :
1. Le paralllisme : Le paralllisme est un caractre essentiel des interfaces post-WIMP, en par155
ticulier dans celles bases sur linteraction bimanuelle et multimodale. Parce quICON sappuie
sur un paradigme ot de donnes, il est naturellement adapt la description de la concurrence. Dune part, des comportements concurrents peuvent tre ajouts un comportement existant sans manipuler la conguration dentre initiale. Dautre part, le langage graphique se prte
bien la reprsentation de comportements massivement parallles, car bien que les connexions
soient nombreuses le paralllisme ninduit pas de croisements entre celles-ci. Dans le chapitre
sur la bote outils ICON, nous dcrivons un exemple o un simple copier-coller transforme
une interaction Swing standard en une interaction multi-pointeurs (gure 4.22 page 133).
2. La transparence : Lafchage dobjets transparents en incrustation est une technique prsente
dans la plupart des paradigmes post-WIMP, comme les outils semi-transparents ou linteraction
gestuelle. Les dispositifs de feedback se prtent bien la description de telles techniques, et
ceux que nous avons implment dans ICON nous ont permis de dcrire des interactions base
de pointeurs multiples, de barres doutils et de saisie gestuelle ottantes. Nous pensons plus
gnralement que ce type de retour graphique permet de dcrire un grand nombre de techniques dinteraction indpendamment de lapplication, et quICON gagnerait tre tendu pour
inclure explicitement un modle de feedback graphique multicouche tel que celui dcrit dans
[F EKETE & B EAUDOUIN -L AFON 96, F EKETE 96 B].
3. Les modalits naturelles : Certaines interfaces post-WIMP reposent sur lexploitation de modalits naturelles telles que la parole et le geste pour communiquer avec lordinateur. Ce type
dentres, dont linterprtation est complexe, soppose aux entres explicites telles que le pointage. Pour pouvoir tre interprts par lapplication, les signaux bruts provenant de ces entres
doivent tre convertis en symboles par des techniques de classication. Les algorithmes de classication sont lents et se prtent mal un paradigme ractif3 . Le principe des entres/sorties
implicites (voir section C.5.1 page 232) dICON permet toutefois de dcrire des dispositifs
asynchrones et temporellement non-dterministes, qui effectuent leurs calculs dans un autre
l dexcution an de ne pas bloquer la machine ractive. Le classicateur est alors vu comme
un dispositif dentre qui met des sorties son rythme propre. Le dispositif de commande
vocale (voir section 4.2.1 page 111) en est un exemple. Certains aspects plus haut-niveau de
linteraction multimodale tels que la gestion de lambigut et la fusion des modalits ne sont
cependant pas pris en charge par ICON.
4. Les capteurs passifs : Linteraction implicite base de capteurs et la sensibilit au contexte sont
des caractristiques prdominantes dans certains paradigmes tels que linformatique diffuse ou
linformatique vestimentaire. Les capteurs passifs se distinguent des dispositifs dentre en ceci
quils ne sont pas directement contrls par lutilisateur. Dans ICON, les capteurs peuvent tre
tout--fait assimils des dispositifs dentre et tre connects des applications de la mme
manire. Nous pourrions par exemple construire une conguration o le niveau acoustique de
lenvironnement (information dj disponible travers le dispositif de commande vocale) agit
sur le volume sonore dune application. Limplmentation dune grande varit de capteurs ainsi
que des dispositifs de traitement adapts tels que des classicateurs sufrait dcrire la plupart
des techniques dinteraction implicite employes dans ces interfaces post-WIMP.
3 Les interactions base de classication sont quelque peu en contradiction avec la nature suppose concise et directe de
linteraction post-WIMP (voir section 1.3.1 page 15). Mais il existe proprement parler plusieurs approches de linteraction
Post-WIMP, dont certaines sattachent plus laspect communicationnel qu laspect instrumental. Quoi quil en soit, les
interactions base de classication restent indispensables dans certains contextes comme laccessibilit.
156
5.4. COMPLEXIT ET LISIBILIT
5.4 Complexit et lisibilit

Un diteur graphique de congurations possde de nombreux avantages par rapport des langages
de script ou de programmation. Par exemple, dans lhypothse o toute notion de classe a t vacue,
les moyens daccder un nouveau dispositif dentre ne peuvent pas tre rendus explicites dans un
langage textuel : il est ncessaire de consulter une documentation ou de faire des requtes pralables
sur le dispositif pour connatre le nom de ses diffrents canaux. Dans lditeur dICON, les interfaces
des dispositifs sont explicites, et il suft de connecter les canaux du dispositif dentre pour pouvoir
lutiliser.
Cependant, les langages visuels possdent galement de nombreux inconvnients. En particulier,
ils supportent mal la complexit, et un programme peut rapidement devenir illisible et difcile
maintenir. ICON nchappe pas cette rgle (voir par exemple les congurations des gures 5.6 et 4.33
page 139). Dans cette section, nous tudions plus en dtail le problme de la complexit visuelle dans
ICON.
5.4.1
Le rle de la structuration spatiale
F IG . 5.6 La conguration par dfaut dICONDraw, o les dispositifs standard contrlent diffrents outils de
dessin ainsi que les composants Swing. Cette reprsentation nemploie pas de liens.
Sur la gure 5.6 est reprsente la conguration dentre par dfaut dICONDraw. Cest une conguration minimale mais complte permettant de contrler, avec les dispositifs standard, les trois outils
de dessin, les attributs de la brosse, ainsi que les widgets standard de Swing. Bien que lon puisse y
deviner une technique de multiplexage, cette conguration est illisible. Non seulement les nombreux
croisements entre les connexions (impossible viter ici) nuisent sa lecture, mais il est galement
difcile de dterminer les rles respectifs des diffrents dispositifs.
La gure 5.7 page suivante montre une autre reprsentation de la mme conguration. Cer157
tains dispositifs ont t dupliqus plusieurs endroits de lespace de travail en employant des liens
(voir 4.4.1 page 127). Les dispositifs ont ensuite t regroups an de mettre en vidence les diffrentes parties fonctionnelles de la conguration : la partie A dcrit le contrle standard des composants
Swing. La partie B dcrit la slection de loutil au bouton droit de la souris, selon une technique de
multiplexage temporel. La partie C dcrit le contrle des attributs de la brosse au clavier, selon une
technique simple dincrmentation/dcrmentation (la brosse est un dispositif virtuel fourni par
ICONDraw, qui se contente de dcrire une structure et transmettre en sortie les donnes reues en
entre). Enn, les parties de D1 D3 dcrivent le contrle des trois outils de dessin.
F IG . 5.7 Sur cette reprsentation de la conguration par dfaut dICONDraw, des liens ont t employs pour
viter les croisements de connexions et les dispositifs ont t regroups de faon mettre jour les diffrentes
parties fonctionnelles. Nous avons ajout les rectangles englobants et les lettres de A D pour les besoins de
notre discours.
Cet exemple montre que la lisibilit dune conguration dentre repose en grande partie sur une
158
5.4. COMPLEXIT ET LISIBILIT

bonne structuration spatiale. Nous pensons que mme des congurations dentre extrmement complexes peuvent tre structures en sous-congurations qui peuvent tre comprises et modies de
faon indpendante. Cette structuration est facilite dans ICON par les techniques de manipulation directe et par le principe des liens, qui sont reprsents dans la dimension verticale perpendiculairement
aux ots de donnes. En outre, le redimensionnement relatif des dispositifs et lencapsulation de souscongurations dans des dispositifs composites permettent de mettre en vidence certaines parties de
la conguration ou de dnir des niveaux de dtail. Toutes les techniques nont pas t explores : par
exemple, lannotation des congurations des ns de documentation, ou lutilisation du zoom smantique pour naviguer dans la hirarchie des dispositifs composites sont deux techniques qui semblent
prometteuses.
5.4.2
Les limites du tout-visuel
Dans le chapitre prcdent, nous avons dcrit une technique de pointage vocal employant deux
pointeurs interdpendants, le premier tant sensible au niveau sonore et le second la commande
reconnue (conguration de la gure 4.33 page 139). Cette technique dinteraction sophistique est
principalement implmente par le dispositif SpeechCursor, un adaptateur qui renseigne la position
des deux pointeurs en fonction des commandes quil reoit.
F IG . 5.8 Dcomposition du dispositif composite SpeechCursor ( gauche) en sa conguration-lle (au milieu). Cette dernire emploie galement quatre instances dun dispositif composite cr pour loccasion et dont
la conguration-lle est reprsente droite.
Le comportement du dispositif SpeechCursor a t entirement dcrit avec des oprateurs lmentaires dICON an de tester la puissance dexpression du langage (gure 5.8). Nous ne nous attarderons
par dcrire ces congurations, notre but tant simplement de montrer que malgr les deux niveaux
de composition, chaque conguration-lle est relativement complexe et difcile lire.
Cet exemple montre les limites du tout-visuel ou du tout-modulaire consistant dcrire
nimporte quel comportement, mme trs complexe, par composition doprateurs simples. Bien que
159
nous ayons plusieurs reprises insist sur les avantages apports par un modle modulaire en termes
de congurabilit, nous avons galement montr lintrt demployer des dispositifs monolithiques
(implments en Java) pour dcrire des comportements complexes, et en particulier des techniques
dinteraction connues. Nous pensons en effet qu partir dun certain niveau de granularit, il devient
inutile de dcomposer les comportements car la complexit lemporte sur la souplesse. En effet, un
dispositif monolithique mais paramtrable est toujours plus congurable (dans le sens que nous avons
dni dans la section 1.4.2 page 29) quune conguration dentre dont on narrive pas comprendre
le fonctionnement. Il nous semble cependant difcile dtablir prcisment cette granularit-limite.
5.4.3
Complexit et nature de linteraction
F IG . 5.9 Trac de lignes standard et bimanuel avec ICONDraw.
La gure 5.9 illustre deux techniques de trac de lignes que nous avons dj voques dans le
chapitre prcdent, et quil nous semble utile de reproduire ici. La conguration du haut dcrit la
technique de cliquer-glisser standard couramment employe pour spcier deux points avec un seul
pointeur. Celle-ci a t ensuite modie (conguration du bas) pour prendre en compte un deuxime
dispositif de pointage. La conguration obtenue est bien plus simple que la conguration originale,
dabord parce que le multiplexage nest plus ncessaire : deux dispositifs contrlent deux dimensions.
Ensuite, parce que la tablette graphique fournit des donnes directement compatibles avec celles du
dispositif dapplication (la souris ncessite la conversion de positions relatives en positions continues).
Cet exemple montre que la complexit dune conguration dentre dpend dune certaine manire du type dinteraction quelle dcrit. Les techniques dinteraction standard, parce quelles utilisent des entres relativement pauvres et gnriques, emploient des techniques dinteraction essentiellement bases sur le multiplexage, ncessitant lusage de modes et de structures conditionnelles.
Ces comportements peuvent tre lorigine de congurations dentre relativement complexes. linverse, les congurations dentre les plus simples, o la transformation des donnes est majoritaire
par rapport leur contrle, dcrivent des techniques de contrle direct avec des dispositifs multiples.
La technique dinteraction bimanuelle dcrite ci-dessus en est un exemple, tout comme le contrle
dune interface zoomable avec un dispositif six degrs de libert (gure 4.25 page 134).
Il est intressant de constater que dans lexemple dcrit prcdemment, la technique dinteraction
considre comme la plus naturelle se dcrit aussi le plus aisment. Une technique dinteraction simple
dutilisation ne se dcrit pas ncessairement de faon simple dans ICON (par exemple, un dispositif
160
5.5. CARACTRISATION DES DIFFRENTS TYPES DE DISPOSITIFS

dentre et un objet de lapplication peuvent tre compatibles du point de vue cognitif mais tre
modliss diffremment). En outre, la simplicit dune conguration dentre ne garantit rien, bien
sr, quant lutilisabilit de la technique quelle dcrit (la suppression alatoire dune connexion
simplie la conguration mais pas linteraction). Malgr tout, nous pensons quil existe un rapport
entre la simplicit dune conguration dentre et certaines bonnes proprits de linteraction, en
particulier celles qui caractrisent les paradigmes post-WIMP (voir section 1.3.1 page 15).
En effet, nous pensons tout dabord quun critre dutilisabilit essentiel pour une technique dinteraction de type instrumental4 est sa facult dtre facilement comprhensible par lutilisateur : celuici doit pouvoir lassimiler facilement mais surtout ensuite pouvoir prdire son comportement, et pour
ce faire, stre construit un modle mental prcis de son fonctionnement. En consquence, les mcanismes de cette interaction doivent pouvoir se dcrire facilement dans le formalisme qui convient.
Nous pensons par ailleurs que les langages ots de donnes, et ICON en particulier, sont bien adapts
la description de la plupart des interactions de type Post-WIMP, car ils encouragent la description
de techniques dinteraction directes, amodales et parallles.
5.5 Caractrisation des diffrents types de dispositifs

ICON permet de spcier des techniques dinteraction en termes de congurations dentre, mais
ne dcrit pas prcisment comment ces congurations doivent tre dcomposes en dispositifs, ni la
faon dont ces dispositifs doivent tre dcomposs en slots. Nous avons en partie rpondu cette
question dans le chapitre prcdent par de nombreux exemples de dispositifs et de congurations.
Dans ICON, la plupart des choix de conception restent cependant la charge du dveloppeur.
Le dispositif est la brique de base dans ICON, et il est essentiel de se demander ce qui le caractrise
et ce quil reprsente. Du point de vue des entres, la plupart des dispositifs physiques sont des objets
autonomes dont les parties constituantes sont indissociables : faire correspondre un dispositif physique un dispositif dans ICON est par consquent une bonne approximation. La dcomposition dune
application en dispositifs dapplication est cependant moins triviale, et les choix relatifs cette dcomposition incombent au programmeur dapplication. La dcomposition dune conguration dentre en
techniques dinteraction pose galement la question du bon niveau de granularit.
Dans cette section, nous dnissons plus prcisment les rles et les fonctions des dispositifs
systme dentre, des dispositifs de bote outils et dapplication, et des dispositifs utilitaires. Nous
dcrivons notamment les services que ces dispositifs, et en particulier les dispositifs dapplication et de
bote outils, sont senss fournir. Nous numrons galement les difcults que le programmeur peut
rencontrer pour dcrire correctement ces dispositifs, et proposons des directives dimplmentation
permettant de guider le dveloppement de nouveaux dispositifs.
4 Cest--dire
que linterface est manipule comme un instrument ou un outil plutt quemploye comme un mdium de
communication.
161
5.5.1
Les dispositifs systme dentre
Rle et fonction des dispositifs systme dentre

Un dispositif dentre ICON est un dispositif systme qui dcrit un priphrique utilisateur physique. En pratique, le rle des dispositifs dentre dans ICON est de fournir une vue unie et basniveau des dispositifs dcrits par les diverses APIs dentre.
Limplmentation de dispositifs systme dentre peut poser un certain nombre de difcults, que
nous dcrivons par la suite.
Lhtrognit des APIs dentre
Le modle de chaque dispositif systme (structure et nom des slots, en particulier) sera intimement li lAPI sur lequel il repose, et sur les choix qui y auront t faits. Les APIs existantes tant
assez htrognes, deux dispositifs systme reprsentant le mme dispositif physique mais provenant
dAPIs diffrentes pourront ainsi avoir une structure toute diffrente. En particulier, il nexiste pas de
convention de nommage pour les slots.
Lhtrognit des APIs nest cependant pas limitative dans le sens o ICON ne ncessite ni abstraction ni smantique dans son modle de congurations. Un utilisateur dICON a simplement besoin
de voir apparatre les dispositifs concrets dont il dispose, et dtre capable didentier ces dispositifs
et la smantique de leurs canaux. Cette identication repose uniquement sur le choix (en gnral judicieux) des noms (nom du dispositif, nom de ses canaux) faits par les fabricants des dispositifs et de
pilotes.
Le problme de la rutilisabilit des congurations dentre dun systme lautre sera abord
plus loin dans cette discussion (section 5.6.3 page 171). Enn, notons que le problme de lhtrognit pourrait tre en partie rsolu par lemploi exclusif dune API universelle telle que le USB
Human Interface Device [USB/HID 01].
Le choix du bon niveau dabstraction
Il existe proprement parler au moins trois niveaux bas : le bas-niveau logique (donnes numriques en provenance du pilote de dispositif), le bas-niveau lectronique (les signaux lectroniques)
et le bas-niveau physique (ou mcanique). Ce dernier est le plus pertinent, car il est en contact direct
avec lutilisateur, et contribue le plus limage mentale que celui-ci se fait du dispositif et de ses actions sur celui-ci. Or les APIs dentre se situent au mieux au niveau logique, cest--dire au plus bas
niveau logiciel. Et il nexiste pas ncessairement de correspondance directe entre ce niveau logique et
le modle physique du dispositif.
Non seulement une modlisation trs bas-niveau nest pas toujours ralisable, mais elle nest pas
non plus adapte tous les contextes dutilisation. titre dexemple, un clavier devra apparatre
comme un ensemble de slots boolens (un slot par touche) pour tre dle son modle physique.
Cette structure est pertinente lorsque lon doit sintresser un ensemble restreint de touches (touches
ches, par exemple). Mais elle devient trop lourde lorsque lon doit appliquer un ltre lensemble
du clavier, car elle ncessite de connecter chaque touche parmi les centaines existantes. Lutilisation
de donnes srialises base de codes touches peut savrer ncessaire.
162

Ces considrations nous amnent dnir trois proprits souhaitables pour les dispositifs dentre, proprits qui doivent guider les programmeurs :
Abstraction physique : Les slots qui dcrivent le dispositif doivent tre choisis et structurs en
fonction des caractristiques physiques de ce dispositif. Les donnes qui proviennent de ces canaux
doivent tre brutes, ou subir des transformations sans perte si elles ne concident pas avec le modle
physique du dispositif.
Redondance : Si le besoin sen fait sentir, il peut tre ncessaire de fournir des manires alternatives daccder aux donnes du dispositif, par des slots supplmentaires de plus haut niveau (valeurs
absolues en plus de relatives, informations synthtiques sur plusieurs canaux, etc.).
Paramtrisation : Si le besoin sen fait sentir, il peut galement tre ncessaire de dnir des
comportements alternatifs pour un mme dispositif. Les traitements de donnes qui implmentent ces
comportements seront bien identis et choisis par lutilisateur dans les paramtres du dispositif.
5.5.2
Les dispositifs dapplication et de bote outils
Rles et fonctions de ces dispositifs

Le rle principal des dispositifs dapplication et de bote outils est de fournir des points dentre : pour les premiers, il sagira dexposer une interface de contrle pour une application donne
et de prendre en charge ce contrle. Pour les seconds, il sagira dexposer une interface de contrle
gnrique pour lensemble des applications qui reposent sur la mme bote outils graphique.
Une autre fonction de ces dispositifs est de fournir des points de retour. Ces derniers sont concrtiss par des dispositifs comportant des entres implicites et produisant des sorties, et qui peuvent tre
employs pour effectuer des requtes vers lapplication ou la bote outils. Les slecteurs de Swing
comme le pick, dcrits dans le chapitre prcdent, sont des exemples de tels dispositifs.
Dans la suite, nous dcrivons un ensemble minimal de services utiles que pourraient fournir
ICON les applications et les botes outils, sous forme de points dentre et de retour.
Services communs aux applications
Jean-Daniel Fekete [F EKETE 96 A] a identi trois services du noyau smantique indispensables
linteraction : la notication, la prvention des erreurs, et lannulation. Ces trois services, sils sont
pris en charge par lapplication, peuvent tre externaliss sous forme de points dentre ou de points
de retour :
La notication est principalement employe pour mettre jour la vue, mais pourrait galement
se rvler utile comme point de retour dans une conguration dentre. Un tel dispositif de
retour peut par exemple comporter en sortie un boolen mis vrai chaque changement, ou un
slot produisant des listes dobjets ayant chang.
Le retour smantique est souvent employ dans linteraction en entre pour prvenir les erreurs. Le retour smantique peut tre dcrit par des points de retour qui dterminent si une
opration est valide ou non. Chaque dispositif peut reprsenter une commande, ou recevoir la
commande dynamiquement en entre. Les arguments de la commande sont des objets transmis
sur les slots dentre. En sortie des dispositifs, un boolen indique si la commande est valide, et
163
une chane peut ventuellement transmettre un message derreur. Un ltre produisant une liste
darguments valides serait galement utile pour dcrire des techniques comme le snap smantique [H UDSON 90] ou le drag-and-pop [BAUDISCH et al. 03].
Lannulation est un point dentre qui peut tre prsent sur chaque dispositif sous forme dun
slot annuler et dun slot refaire. Lannulation peut galement tre dcrite dans un unique dispositif global.
Services communs aux botes outils
La notication et lannulation sont deux services qui peuvent galement tre fournis travers les
botes outils graphiques. Voici les autres services de botes outils graphiques susceptibles dtre
employs dans les congurations :
Points dentre :
Les manipulations gnriques : Il sagit de points dentre qui dcrivent lensemble de
manipulations quil est possible deffectuer sur tout type de widget. Le manipulateur de surface DJComponent, qui interprte des manipulations positionnelles simples, en constitue un
exemple. Des manipulations gomtriques plus sophistiques peuvent tre prises en charge,
comme les changements dchelle et les rotations de Jazz. Un protocole dmission de commandes similaire ceux des botes outils semi-transparents (section 2.6.2 page 74) peut
galement tre dni. Enn, les botes outils peuvent ventuellement donner les moyens de
modier lemplacement et la hirarchie de leurs widgets.
Les manipulations spciques : Il sagit de points dentre qui dcrivent le contrle de
widgets de types spciques. Les manipulateurs de modle DJScrollbar et DJText sont des
exemples de points dentre qui permettent de dcrire des techniques dinteraction adaptes
aux modles internes des widgets.
Le feedback : Certains feedbacks tels que la mise en vidence graphique peuvent tre pris
en charge au sein des widgets. Ce service nest cependant pas indispensable et peut avantageusement tre remplac par la cration de fantmes (voir plus bas).
Points de retour :
Le pick : Il sagit dun service indispensable, dont la version minimale consiste retourner
lobjet le plus profond dans la hirarchie qui se trouve sous une position donne. Des services
plus avancs peuvent consister prendre en compte des critres de slection et/ou retourner
une liste dobjets candidats. Le pick avec des formes quelconques permettrait galement de
dcrire des techniques positionnelles volues comme le pointeur pour main non-dominante
de Bimanual Whizz (section 2.6.2 page 70) ou la manipulation groupe dobjets.
Le focus : Si la bote outils gre le focus, elle peut indiquer le focus courant par un point
de retour et/ou le rendre contrlable par un point dentre. Ce service nest pas indispensable
et pourrait dcrit dans ICON partir des deux services suivants.
Les fantmes : Ces points de retour produisent des instantans des objets de la bote outils,
qui peuvent tre anims en incrustation avec ICON. La cration dobjets fantmes multiplie les possibilits pour dcrire le feedback dans ICON, en particulier si cette fonctionnalit est paramtrable (choix entre contours seuls / forme pleine / image, et choix de la couleur et de la transparence). Les contours dun objet peuvent galement tre employs dans
des calculs de collision pour des techniques de manipulation base de formes (alignements
[R AISAMO & R IH 96] et manipulation groupe [R EKIMOTO 02], par exemple).
Informations non graphiques : Des informations non graphiques (analogues lAPI dac164

cessibilit de Swing) peuvent tre fournies telles que : le nom unique de chaque widget, sa
description, lordre de parcours des widgets, et leur structure hirarchique. Ces points de retour autorisent la navigation non-positionnelle dans linterface (gestion des cycles de focus,
contrle vocal).
Identier et dcrire les points dentre dune application

Des dispositifs dapplication peuvent tre dvelopps pour tout type dapplication interactive. Il
nexiste pas de modle gnrique pour ces dispositifs, chaque dveloppeur devant dterminer quel
modle est pertinent pour son application spcique. Bien que des modles gnriques adapts des
types particuliers dapplication (dessin, traitement de texte, modlisation 3D) puissent tre susceptibles de guider les dveloppeurs dans limplmentation des dispositifs dapplication, il est bon de
rester lcart des modles simplicateurs et garder laccent sur laspect hautement spcique des
tches propres chaque application interactive.
Les objets dapplication ne sont pas toujours aussi bien dlimits que les dispositifs physiques. En
particulier, les dveloppeurs peuvent hsiter devant le niveau de granularit adopter. Ainsi, chaque
commande dune application (les commandes de menus, par exemple) peut tre individuellement
expose sous forme de dispositif, ou toutes ces commandes peuvent tre regroupes dans un dispositif plus grand. En outre, les programmeurs peuvent choisir ou non dexposer certains objets ou
mcanismes, selon le degr de congurabilit quils dsirent atteindre, et leffort quils comptent y
consacrer.
Nous avons dj dcrit dans le chapitre prcdent une taxonomie oriente-objet des dispositifs
dapplication, utile pour guider les choix : les dispositifs de classe, les dispositifs dinstance statiques
et les dispositifs dinstance dynamiques (voir section 4.2.4 page 118). Des exemples de dispositifs
dinstance dynamiques sont les outils de dessin dICONDraw : chaque dispositif employ dans la
conguration cre une instance dans lapplication. Les manipulateurs de Swing, en revanche, sont
des dispositifs de classe, qui oprent sur des instances variables de la mme classe.
Une fois les points dentre identis, il convient de les dcrire correctement. Cette opration
comporte des difcults similaires celles que nous avons dj voqu pour les dispositifs dentre.
Nous avons par exemple constat, chez les dbutants en dveloppement ICON, des difcults apprhender la notion d indpendance par rapport aux entres , difcults qui ont t la source
derreurs de conception. Pour cette raison, il nest pas inutile de guider les dveloppeurs en leur fournissant, comme nous lavons fait avec pour dispositifs dentre, des directives dimplmentation une
fois que les objets exposer ont t clairement identis :
Abstraction applicative : Les slots qui dcrivent le dispositif doivent tre choisis et structurs en
fonction des caractristiques de lobjet applicatif et uniquement celui-ci. Lobjectif quil faut garder
lesprit est lindpendance par rapport aux entres : le dispositif doit tre construit sans prjug sur la
faon dont il sera contrl.
Redondance et paramtrisation : En fonction des utilisations envisages, et tout comme avec les
dispositifs systme, il peut savrer ncessaire de fournir plusieurs manires de contrler un dispositif
dapplication ou de le rendre paramtrable. Une valeur numrique pourra par exemple tre contrle
soit par affectation, soit par incrmentation/dcrmentation.
165
5.5.3
Les dispositifs utilitaires
Rle des dispositifs utilitaires

Le rle des dispositifs utilitaires est de permettre de connecter travers des transformations de
donnes et du feedback un ensemble de dispositifs dentre un ensemble de dispositifs dapplication.
Ces dispositifs sont la fois des adaptateurs et des techniques dinteraction, et peuvent tre composs
pour former des adaptateurs et des techniques dinteraction plus complexes.
Le choix du bon niveau de granularit

Cest au niveau des dispositifs utilitaires que le problme de la dcomposition est le moins trivial.
Mme si les dispositifs dICON sont composables, et quil est donc possible de dcrire des comportements sur plusieurs niveaux dabstraction, il convient de choisir jusquo sarrte cette dcomposition.
Autrement dit, quelle doit tre la granularit des dispositifs atomiques ?
Bien que sduisante, la dmarche consistant fournir un ensemble de dispositifs de fonctionnalit
minimale qui soit sufsant pour dcrire nimporte quelle technique dinteraction est critiquable du
point de vue pratique : dabord, il nest pas vident de dterminer priori cet ensemble minimal.
Ensuite, la description graphique de comportements complexes peut se rvler rapidement pnible,
comme nous lavons vu dans notre discussion sur la complexit visuelle.
Aussi, nous pensons quil est essentiel de pouvoir disposer dune bibliothque de dispositifs mathmatiques et logiques simples, mais galement dune bibliothque volutive dadaptateurs monolithiques de complexit variable. Lutilisateur a ainsi la possibilit de manipuler et dimplmenter
des techniques dinteraction part entire, de composer des adaptateurs de complexit moyenne, et
dutiliser des dispositifs minimaux l o les outils existants font dfaut. Nous avons dj donn des
exemples de ces diffrentes approches dans la section 4.4.4 page 136.
5.6 Dvelopper avec ICON

Dans cette section, nous analysons sous un angle pragmatique la pertinence de notre approche
du point de vue du dveloppeur dapplications. Nous en avons dj abord un aspect en faisant tat
des difcults relatives aux choix de conception. Ici, nous commenons par dterminer en quoi ICON
induit une nouvelle faon de programmer linteraction, et numrons les concepts auxquels doivent
shabituer les programmeurs ayant jusque-l employ des outils conventionnels. Puis, nous dcrivons
dans quelle mesure et avec quelle facilit ICON peut tre employ avec des botes outils graphiques
et des applications existantes. Dautres considrations pratiques sont ensuite abordes, savoir la
rutilisabilit des congurations, la prise en charge effective des dispositifs dentre physiques, et
enn les questions de performance.
5.6.1
Matriser un nouveau paradigme de programmation
Limplmentation de dispositifs ICON est relativement simple en soi, car comme nous lavons vu
dans la section 4.3.1 page 118, elle consiste essentiellement dclarer des slots puis spcier les
166
5.6. DVELOPPER AVEC IC ON

actions effectuer lorsque la valeur dun slot dentre a chang (ou plus exactement, lorsque celui-ci
a reu a signal). Il peut exister nanmoins des difcults qui dcoulent dun style de programmation
diffrent des outils habituels. Nous numrons ici les principaux paradigmes et concepts pouvant
poser problme, en voquant notamment les erreurs-type dduites de lobservation et du suivi de deux
programmeurs ayant employ ICON pour dvelopper une application (voir section 4.5 page 141). Nous
commenons par un concept essentiel dans ICON, savoir lindpendance par rapport aux entres.
Puis, nous voquons trois notions exotiques dcoulant de notre modle dexcution, savoir la
ractivit, la simultanit et le dterminisme. Enn, nous dcrivons les problmes lis lutilisation
dobjets dans les congurations dentre.
Lindpendance par rapport aux entres : Nous avons dj constat dans une discussion prcdente que les dveloppeurs habitus aux botes outils conventionnelles avaient quelques difcults
matriser la philosophie d indpendance par rapport aux entres . Dans ICON, cette philosophie impose que les dispositifs soient construits sans prjug sur la faon dont ils seront contrls. Or, il est
courant de constater des erreurs consistant dclarer des dispositifs dapplication qui comportent,
titre dexemple, des slots dentre nomms shift ou mouseClick. Une autre erreur typique consiste
implmenter dans lapplication, ou dans le dispositif dapplication, des mcanismes qui sont en
ralit des techniques dinteraction, et quil est nettement prfrable de dcrire dans la conguration
dentre. Par exemple, un dispositif dapplication est dclar avec un slot slectionner, qui slectionne un dossier lorsque sa valeur passe de faux vrai ou alors ouvre celui-ci lorsquil passe deux
fois de faux vrai dans un intervalle de temps assez court. Il sagit dun comportement modal de
type double-clic, qui constitue une technique dinteraction et doit tre dcrit lextrieur du dispositif
dapplication. Si ce type derreur est facile comprendre, la limite entre ce qui doit tre dcrit dans
ICON et ce qui doit tre dcrit dans lapplication nest pas toujours triviale.
La ractivit : La programmation ractive est un paradigme peu connu des programmeurs utilisant des langages impratifs, et certains de ses concepts comme le temps de propagation nul peuvent
leur paratre difciles apprhender. Cependant, ni lutilisateur de lditeur interactif ni le programmeur nont se soucier de ces concepts, car ICON gre intgralement et de faon transparente la
propagation de linformation entre les dispositifs. Le modle ractif impose cependant des contraintes
sur le temps dexcution de chaque dispositif (mthode update()). Des erreurs courantes consistent
effectuer, dans cette mthode, des initialisations lourdes au lieu de les placer dans la mthode open(),
effectuer des oprations qui rclament du temps (gros calculs ou routines graphiques) au lieu de les
lancer dans un l dexcution spar, ou crer des objets chaque tick l o ce nest pas indispensable. Dans ce dernier cas, et bien que la distinction puisse tre subtile, il convient de diffrentier les
crations discontinues dobjets (par exemple, crer un objet chaque clic) des crations continues (par
exemple, crer un objet chaque mouvement de la souris) qui alourdissent lexcution et occupent
rapidement la mmoire.
La simultanit et la gestion des tats : Une autre caractristique dICON dcoulant de son
modle ractif est la notion de simultanit. La simultanit est absente de la programmation vnementielle classique, o les vnements sont traits squentiellement en fonction de leur ordre darrive
dans la le. Dans le modle ractif dICON, il est frquent que plusieurs signaux arrivent au mme
moment dans diffrents slots dun dispositif dentre (ils peuvent galement arriver dans le dsordre).
Lordre dans lequel ces signaux sont traits a alors son importance. Par exemple, le dispositif de dessin main lev dICONDraw (voir section 4.2.4 page 117) 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 contrle par les slots x et y, et le changement de mode est dtermin par le slot use. Pour
167
ce dispositif, il convient de vrier si le slot use a reu un signal avant de traiter les valeurs x et y.
La simultanit complique gnralement 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 reu simultanment sur des slots on et off). En outre, les choix qui sont
faits napparaissent pas lextrieur du dispositif, si ce nest travers sa documentation. Cest pourquoi nous pensons que la programmation de certains dispositifs dans ICON gagnerait reposer sur des
outils adapts, ide qui sera dveloppe dans la section 5.8.1 page 179.
Dterminisme et non-dterminisme : ICON fait la distinction entre dterminisme et non-dterminisme,
autres concepts auxquels un dveloppeur nest pas ncessairement habitu. Les dispositifs non-dterministes
sont simplement des dispositifs qui emploient des informations en provenance de lenvironnement,
systme qui englobe tout ce qui ne fait pas partie de la conguration dentre. Nous disons dans
ICON quils comportent des entres implicites (voir section 3.4 page 101). Par ailleurs, nous disons
dun dispositif qui modie lenvironnement quil comporte des sorties implicites. ICON ne dduit pas
automatiquement la prsence dentres/sorties implicites, et le dveloppeur du dispositif doit explicitement les dclarer en drivant les deux accesseurs boolens correspondants. Cette opration, bien
que simple, peut tre facilement omise par le programmeur. Elle est pourtant indispensable car premirement, un dispositif non-dterministe est trait diffremment par la machine ractive : celui-ci est
activ chaque tick an quil puisse, mme en labsence de signaux dentre, surveiller lvolution
de lenvironnement et ventuellement transmettre des valeurs en sortie. Ensuite, la prsence dentres
et de sorties implicites est une information qui contribue une bonne comprhension dune conguration dentre, car elle permet de voir clairement quels endroits cette dernire communique avec
lextrieur (utilisateur et application notamment).
Manipuler des objets dans les congurations dentre : Une conguration dentre opre sur
des types primitifs, structurs ou non, tels que des entiers ou des boolens. La manipulation dobjets
y est galement possible grce aux slots de type object, mais celle-ci requiert toutefois certaines prcautions. Il existe trois principales manires demployer des objets dans les congurations dentre :
la transmission de rfrences, la cration dobjets et la manipulation dobjets. La transmission de rfrences consiste transmettre dun dispositif lautre des rfrences des objets qui proviennent
initialement de lenvironnement. Les dispositifs slecteurs/manipulateurs, illustrs notamment par la
technique du pick, constituent un exemple de cette utilisation (voir section 4.2.3 page 114). Cet emploi ne pose aucun problme. La cration dobjets consiste crer des objets au sein dun dispositif
avant de les passer par rfrence. La cration dobjets ne pose pas de problme tant quelle ne nuit pas
lhypothse ractive (voir la discussion prcdente). Plus problmatique est la manipulation dobjets qui consiste, au sein des dispositifs, lire ou crire dans les objets transmis. Ces oprations
peuvent en effet engendrer des dpendances caches entre les dispositifs et rendre une conguration
dentre implicitement non-dterministe. Cest le cas par exemple de la conguration de la gure 5.10
page ci-contre. Lorsque cest possible, il est toujours prfrable de composer des slots primitifs plutt
que demployer des objets, car les ux dinformation et la structure des donnes manipules y sont
explicites. Dans le cas contraire, tout objet lu ou modi doit tre considr comme faisant partie
de lenvironnement, et les dispositifs concerns dclars comme ayant des entres et/ou des sorties
implicites.
168
F IG . 5.10 Conguration dentre manipulant des objets de type Liste : le dispositif addItem concatne
les objets mis par B la dernire liste mise par A, que printAfter afche aprs chaque modication.
printBefore afche quant lui les listes mises par A. Prcisons que seules des rfrences sont transmises
dans les connexions. Supposons que A mette une rfrence vers une liste L = {a1 , a2 } et quau mme moment,
B mette une rfrence vers un objet a3 . Le dispositif printBefore afchera {a1 , a2 } ou {a1 , a2 , a3 } selon
quil sexcute avant ou aprs addItem. Or, comme il nexiste aucune dpendance explicite entre ces deux dispositifs, il ny a aucun moyen de savoir lequel sera excut avant lautre. Le comportement de printBefore,
non-dterministe, dpend de la manire dont le tri topologique est effectu.
5.6.2
Connexion avec les outils et applications existantes
Indpendance dICON par rapport aux botes outils graphiques

Les botes outils graphiques grent les entres sans les sparer clairement de laspect graphique.
linverse, ICON ne soccupe que du premier aspect, et laisse le second aux botes outils graphiques. Il peut par consquent fonctionner avec plusieurs dentre elles. Pour lheure, ICON fournit
les dispositifs minimaux pour linteraction avec les applications Swing, ainsi quune prise en charge
exprimentale des applications Jazz. lavenir, la bibliothque de dispositifs pourra tre enrichie
dautres dispositifs de bote outils. Rappelons cependant quune application peut tre contrle indpendamment de la bote outils graphique sur laquelle elle repose, avec des dispositifs dapplication
dcrits par le programmeur.
Des applications non-java peuvent galement tre contrles avec ICON. Plusieurs stratgies sont
possibles : une interface de communication externe peut tre dnie dans lapplication (un protocole
rseau, par exemple), et des dispositifs ICON qui implmentent cette interface peuvent tre ajouts
la bibliothque. Une application interactive existante peut galement tre contrle sans modication
de son code, lorsque celle-ci implmente dj un protocole bien dni. Nous avons ainsi pu contrler
lapplication Microsoft Word (zoom du document, commandes telles que le copier/coller) en implmentant un dispositif qui sappuie sur le protocole COM (Component Object Model).
Ce type de contrle a cependant pour inconvnient la perte du feedback graphique et du courtcircuitage de la gestion vnementielle standard, car dans la version actuelle dICON ces fonctionnalits sont implmentes par des dispositifs de la bote outils Swing. Nanmoins, ces deux aspects
sont conceptuellement indpendants de la bote outils. Un feedback graphique peut tre implment
au niveau systme, condition que celui-ci fournisse les services graphiques ncessaires comme lincrustation et la transparence. De mme, dans la mesure o le systme dexploitation le permet, les
vnements standard peuvent tre intercepts leur source.
169
Gestion de la concurrence dans les botes outils et les applications
Le problme principal pos par la connexion dICON avec des botes outils graphiques ou des
applications existantes est quelle requiert une coopration minimale de ces dernires : leur contrlabilit repose fortement sur les services quelles sont capables de fournir (les services utiles ont t
dcrits dans la section 5.5.2 page 163), mais galement sur une gestion ne et correcte des modications concurrentes. Swing, par exemple, est capable dexposer ses widgets deux niveaux : un niveau
modle spcique au widget, et un niveau vnementiel gnrique. Les modles sont exposs avec
le niveau de dtail qui convient, et grent parfaitement la concurrence. Le niveau vnementiel, sur
lequel reposent les techniques de contrle de surface comme le contrle multi-pointeurs, comporte
cependant quelques faiblesses.
Premirement, chaque widget Swing gre ses propres vnements positionnels et peut donc tre
contrl indpendamment, mais certains liens implicites entre ces widgets induisent des comportements inappropris lors dun contrle 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
incomplte et cble de linteraction concurrente.
Deuximement, il nest pas surprenant de constater quun widget Swing est incapable de grer
deux ux dvnements positionnels (par exemple, deux drags simultans) : la granularit du contrle
de surface se limite donc celle du widget, ce qui est principalement gnant pour de gros widgets.
Une liste, par exemple, est gre comme un seul widget et non comme un ensemble dlments. Une
barre de dlement constitue galement un widget monolithique.
Plusieurs stratgies peuvent tre envisages pour rsoudre ce problme. Nous avons dj propos
une faon de modier les botes outils existantes en substituant larchitecture M[V+C] [F OWLER 99]
une architecture MVZMC [D RAGICEVIC & F EKETE 99, F EKETE & D RAGICEVIC 00]. Cette dernire permet de
rendre les widgets nouveau modulaires en liminant la gestion des entres dans [V+C] et en la
remplaant par un protocole gnrique permettant de manipuler individuellement chacune des zones
manipulables du widget (gure 5.11, image de gauche). Lobjet [V+C] est ainsi remplac par lobjet
VZM (Vue/Zones/Manipulateurs), qui au lieu de recevoir les vnements dentre est manipul par un
ou plusieurs contrleurs de vue. Le modle est, quant lui, directement manipul par des contrleurs
de modle (gure 5.11, image de droite).
F IG . 5.11 gauche : les zones manipulables dune barre de dlement. droite : le modle architectural
MVZM C.
Lavantage de larchitecture MVZMC est quelle permet de conserver la structure en classes de

widgets dune bote outils existante. Nous avons tendu plusieurs widgets Swing avec cette architecture et montr comment ils pouvaient tre efcacement contrls avec des pointeurs multiples
[D RAGICEVIC & F EKETE 99]. Cependant ces extensions ncessitent de modier la machine virtuelle Java,
170

et en particulier de remanier les sources de Swing, qui ne sont pas un modle de clart ni de maintenabilit. Nous tudions actuellement une autre approche consistant exploiter des botes outils
graphiques Java employant un modle graphique structur comme Jazz [B EDERSON et al. 00] ou Piccolo [B EDERSON 03] an de contrler les applications lchelle de la forme gomtrique (voir galement les projets lis ICON dans la section 4.5 page 141).
5.6.3
La rutilisabilit des congurations
Il est essentiel pour le programmeur dapplications que les congurations quil dcrit soient rutilisables. Tout dabord, elles doivent pouvoir tre charges et excutes sur dautres systmes que le
sien. Ensuite, le fait de pouvoir rutiliser des congurations ou des parties de congurations dune
application lautre faciliterait la tche du programmeur, mais garantirait galement lutilisateur
une certaine cohrence de linteraction entre les diverses applications compatibles ICON.
Rutilisabilit dun systme lautre

Les systmes interactifs traditionnels garantissent la compatibilit matrielle par des mcanismes
dabstraction : les pilotes de dispositifs se chargent de fournir une abstraction connue du matriel spcique connect lordinateur. Notre approche place le problme de la rutilisabilit au second plan
au prot doutils permettant chaque utilisateur de congurer au mieux linteraction avec son propre
matriel. De ce fait, an dexploiter au mieux les spcicits de chaque dispositif, ICON nemploie
pas dabstractions ad-hoc comme les classes prdnies de dispositifs. Dans ICON, chaque dispositif
(marque, modle) tant distinct des autres, il ny a pas notion de dispositifs compatibles .
Pour pouvoir partager les congurations, nous avons cependant intgr dans ICON un mcanisme
de srialisation et dsrialisation de dispositifs extrmement souple bas sur les descripteurs (section 4.3.3 page 124). Ce mcanisme permet en fonction des besoins de dnir des classes de dispositifs interchangeables laide dun langage nomm ICSCRIPT, an de permettre ICON, lors du
chargement de la conguration, de rechercher le dispositif qui convient le mieux parmi ceux prsents.
Simple mais puissant, ce langage autorise notamment les descriptions incompltes et leur composition logique. En outre, il permet de dnir des descripteurs plus ou moins stricts, ce qui est, comme
nous lavons vu dans la section 4.3.3 page 124, dimportance capitale car si une conguration destine la distribution se doit dtre tolrante sur la dnition dun dispositif dentre, sur un systme
multi-dispositifs donn il est important de retrouver les mmes dispositifs dune session lautre.
Le mcanisme de descripteurs dICON comporte toutefois encore certaines limites : par exemple,
il permet de dcrire des quivalences smantiques entre slots de noms diffrents (par exemple, le
slot stylus sur une tablette Wintab correspond au slot button1 sur une souris DirectInput ) mais ne
permet pas dapparier des types de donnes incompatibles (par exemple, les slots dx et dy de la souris
plus une conversion en coordonnes absolues peuvent tre substitus aux slots x et y de la tablette ).
Actuellement, il est ncessaire de traiter les diffrents cas dans des congurations spares. Une autre
faiblesse de ces mcanismes est quils reposent sur une description logique des dispositifs dentre
qui ignore la plupart des proprits intrinsques des dispositifs dont Buxton a sufsamment soulign
limportance (voir la section 1.2.1 page 7). Intgrer au niveau logiciel un modle pragmatique des
entres comme celui de Buxton est un problme qui na ce jour pas t rsolu.
171
Rutilisabilit dune application lautre
Dans les systmes interactifs traditionnels, les techniques dinteraction standard (pointage, menus,
widgets, etc.) sont rutilisables dune application lautre et surtout, offrent une cohrence globale
dans linterface utilisateur. Dans ICON, le dveloppeur de chaque application est libre de dcrire les
techniques dinteraction quil souhaite. Lavantage est bien sr de pouvoir employer des interactions
ddies la tche, mais la rutilisabilit inter-applications reste un critre essentiel pour le programmeur et les utilisateurs.
ICON autorise travers son modle modulaire une certaine cohrence dans les techniques dinteraction. Plusieurs congurations dentre peuvent ainsi reposer sur les mmes mcanismes de base
dj dcrits par les dispositifs utilitaires. En outre, les techniques dinteraction cl en main peuvent
tre facilement remployes dune application lautre. La faon dont ces techniques sont composes
et exploites dans une application peut varier cependant, et des techniques totalement indites peuvent
facilement tre dcrites. ICON ne propose pas de modle haut-niveau pour structurer linteraction, et
est en outre indiffrent quant aux conventions employes (par exemple, la smantique du bouton droit
de la souris). La cohrence de linteraction dune application lautre reste donc un problme, et si
les dveloppeurs dapplications peuvent sinspirer des conventions usuelles de la plupart des congurations reposant sur des dispositifs standard, les conventions relatives linteraction post-WIMP sont
encore inexistantes.
Enn, est-il possible de fournir des congurations dentre qui fonctionnent dans toutes les applications ? La rutilisabilit stricte des congurations dentre suppose une abstraction partage par
toutes les applications interactives. Les dispositifs de bote outils graphique fournissent un tel niveau de rutilisabilit, car ils permettent de contrler lensemble des applications reposant sur la mme
bote outils. Bien que ce contrle se fasse par compatibilit, des interactions non standard peuvent
nanmoins tre dcrites, et il est possible par exemple de proposer des congurations daccessibilit
gnriques5 . En outre, des botes outils graphiques volues comme Jazz permettent de dcrire des
techniques dinteraction gnriques encore plus sophistiques.
Malgr tout, le principe de conguration gnrique est incompatible avec celui de linteraction ddie la tche, et seuls des modles dapplication spciques permettront de dcrire des interactions
la fois puissantes et rutilisables. Nous avons dj voqu la possibilit de fournir une bibliothque
de dispositifs abstraits ddis au domaine, dispositifs pouvant tre partags par un petit nombre dapplications de mme nature (par exemple, applications de dessin ou applications 3D). Cette solution
semble constituer un compromis tout fait acceptable, qui reste encore explorer.
5.6.4
La prise en charge effective des dispositifs dans ICON
ICON sappuie sur un petit nombre dAPIs dentre existantes pour la prise en charge des dispositifs non standard (voir la section 4.2.1 page 111 pour les dtails). Les dispositifs dentre connects
au poste de travail et qui sont compatibles avec lune de ces APIs apparaissent dans ICON et peuvent
tre employs dans les congurations dentre. Les APIs actuellement prises en charge ne couvrent
cependant pas lensemble des dispositifs dentre existants, et les autres dispositifs ncessitent dtre
implments dans ICON avant de pouvoir tre utiliss. Cette opration peut se rvler fastidieuse, mais
elle reste avantageuse pour le programmeur car elle permet de tirer parti du nouveau dispositif dans
5 Voir
par exemple la conguration de la gure 4.27 page 135, qui dcrit le contrle vocal dune barre de dlement.
172

nimporte quelle application interactive Java.
Notons pour nir que la multiplicit des APIs dentre tend nettement disparatre au prot du
standard USB [USB/HID 01], et que la prise en charge de ce standard dans Java fait actuellement lobjet
dun projet dIBM ofciellement accept comme extension candidate au langage [M AXIMILIEN et al. 01]
ainsi que dun projet open-source indpendant [J USB 03]. Les deux projets proposent dj une implmentation Linux quasi-complte. 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
dinteraction non conventionnelles. Par ailleurs, les possibilits potentielles offertes par laccs aux
dispositifs USB dans un langage multi-plateformes rendra encore plus indispensable lexistence dun
outil appropri pour les exploiter au mieux dans les applications.
5.6.5
Les performances
ICON repose sur un modle dexcution ractif, bien diffrent du modle classique o les vnements dentre sont accumuls dans une le pour tre traits. Le modle vnementiel est de type
conversationnel : lordinateur est matre de linteraction et le client attend dtre servi. Dans un modle ractif, cest lenvironnement (donc lutilisateur) qui est matre de linteraction, et toute action de
sa part est traite sans dlai.
La machine ractive offre par consquent des garanties en termes de temps rel. En revanche,
le modle ractif nest valable que tant que lhypothse ractive est vrie, cest--dire lorsque les
vnements sont traits plus rapidement que la vitesse o ils arrivent. La transgression de lhypothse
ractive a des consquences importantes sur la abilit du systme et sur linteraction elle-mme, car
des vnements peuvent tre perdus.
La souplesse actuelle des pilotes de dispositifs (qui grent notamment des mmoires tampon) fait
quen pratique, la ractivit minimale acceptable dpend de critres pragmatiques plutt que techniques. Ainsi, pour la plupart des techniques dinteraction, un temps de raction de lordre de 1/50
de seconde permet de conserver linformation pertinente, et correspond une ractivit et un taux de
rafrachissement considrs comme largement acceptables du point de vue de lutilisabilit. Ce temps
doit tre sensiblement diminu pour certaines techniques comme la reconnaissance gestuelle, o le
dbit dinformations traiter (du moins au niveau bas) est plus important.
Le temps dexcution dune itration (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 ngligeable par rapport au dernier. Lalgorithme de propagation employ dans ICON et dcrit en
annexe C est minimaliste et performant, mme implment en Java. Pour donner un ordre de grandeur
du temps de propagation, une conguration comportant 1000 dispositifs simples (se contentant de
transmettre une valeur) connects en srie sexcute en environ 0.5 ms (taux de rafrachissement de
1800 Hz) sur une station Silicon Graphics 540 avec un processeur cadenc 550 MHz.
Le temps de traitement volue linairement par rapport au nombre de dispositifs prsents dans
la conguration, et est au moins gal celui du dispositif le plus lent. Ce temps doit tre maintenu
le plus bas possible, ce qui ncessite un style de programmation particulier pour les dispositifs (voir
section 5.6.1 page 166). Dans lhypothse o linstanciation dobjets est minimale et o les traitements
coteux sont lancs dans des ls dexcution spars, ICON sexcute en temps-rel .
Les performances dpendent galement des ressources processeur disponibles. Le l dexcution
173
dICON est prioritaire par rapport celui qui gre le rendu graphique. Cependant, an de permettre au
rafrachissement graphique de se faire, ICON permet de spcier une frquence dexcution an de
laisser entre les ticks linitiative aux autres processus. Le temps dexcution de chaque tick est mesur
an de savoir si un moment lhypothse ractive est viole. Il est galement possible danalyser les
performances dune conguration dentre, et de dterminer la contribution de chaque dispositif au
temps dexcution.
5.7 Les utilisateurs dICON

Le modle des dispositifs en cascade constitue, nous en sommes certains, une bonne infrastructure pour un outil de conguration la fois puissant et naturel dutilisation. Il exploite le concept de
connexion logicielle, mtaphore qui tend naturellement le paradigme de la connexion physique (section 3.2.1 page 94). Les deux entits essentielles pour une application congurable y sont exposes,
savoir les dispositifs physiques et les points dentre vers lapplication, puis compltes par la notion
dadaptateurs.
Lobjectif de lditeur interactif dICON est dinstrumenter ces concepts par les outils et les techniques dinteraction et de visualisation ncessaires an doffrir une congurabilit maximale un
nombre maximum dutilisateurs. Nous ne nous attendons pas ce que lutilisateur moyen soit capable demployer tous les fonctionnalits dICON. En revanche, ICON peut sadapter divers degrs
dexpertise, et vise non seulement les programmeurs mais un plus large public compos dutilisateurs
avancs. Nous dcrivons ce continuum dutilisateurs dans cette section.
5.7.1
Un continuum dutilisateurs
La table 5.7.1 page ci-contre numre les diffrentes tches de conguration qui peuvent tre effectues avec ICON, dans lordre croissant de difcult. Chaque tche ncessite des pr-requis qui sont
spcis en deuxime colonne, et qui doivent tre cumuls avec les pr-requis des tches prcdentes.
Nous donnons galement une ide des types dutilisateurs que nous pensons capables deffectuer
chaque tche.
La tche la plus simple (tche 1.) consiste choisir parmi plusieurs congurations dentre existantes dans une application interactive, par exemple remplacer une conguration standard par une
conguration conue pour des utilisateurs handicaps. Cette tche peut tre effectue par nimporte
quel utilisateur de lapplication, pourvu que les congurations disponibles y soient correctement listes et documentes.
Les tches suivantes, destines des catgories particulires dutilisateurs, sont dcrites par la
suite.
5.7.2
Les utilisateurs avancs
Comme nous lavons vu dans le chapitre 4, il est possible dinterrompre temporairement une
application pour ouvrir sa conguration dentre dans lditeur interactif. Cette option est destine aux
utilisateurs avancs, cest--dire la catgorie des utilisateurs qui sont prts consacrer du temps pour
personnaliser les outils quils emploient (voir la discussion ce sujet dans la section 1.4.1 page 28).
174
5.7. LES UTILISATEURS DIC ON
1.
2.
3.
4.
5.
6.
7.
8.
Tche
Slection parmi plusieurs congurations dentre disponibles.
Paramtrisation dun dispositif.
Permuter des dispositifs ou des
slots compatibles.
Connexion directe dun dispositif
dentre des dimensions compatibles de lapplication.
Insertion de dispositifs de traitement supplmentaires.
Connexion dun dispositif dentre

des dimensions incompatibles de
lapplication.
Cration ou adaptation dune conguration dentre complte.
Extension de la bibliothque
dICON par ajout de nouveaux dispositifs dentre ou de traitement.
Pr-requis
Aucun.
Localisation du dispositif dans la
conguration.
Comprhension du modle de slots
et des compatibilits de types.
Connaissance minimale des dispositifs dentre disponibles et des
dispositifs de lapplication.
Comprhension minimale du paradigme de ot de donnes et
connaissance des principaux dispositifs de traitement disponibles.
Matrise du paradigme de ots de
donnes et bonne connaissance des
dispositifs de la bibliothque.
Connaissance tendue des dispositifs de la bibliothque et notions de
programmation JavaScript.
Connaissance du langage Java et de
linterface Device.
Utilisateurs viss
Tout utilisateur.
Utilisateurs avancs.
Scientiques /
Informaticiens.
Dveloppeurs.
TAB . 5.1 Tches de conguration qui peuvent tre effectues avec ICON, de la plus facile la plus
difcile.
Selon son degr dexpertise, nous pensons quun utilisateur avanc peut accomplir une ou plusieurs
des tches qui suivent.
La tche 2. consiste personnaliser un dispositif en ajustant ses paramtres. Un exemple consiste
changer le vocabulaire dun dispositif de commande vocale (voir la conguration-exemple de la
gure 4.27 page 135). Cela suppose, une fois la conguration dentre ouverte dans lditeur interactif,
que lutilisateur soit capable de localiser le dispositif paramtrer dans cette conguration. Cette
tche est facilite par la labelisation et la documentation des dispositifs, ainsi que par lutilisation
dinfobulles.
La tche suivante (tche 3.) consiste intervertir des dispositifs ou des slots compatibles. Il peut
sagir de remplacer une souris par une tablette graphique pour contrler le curseur, remplacer une
technique dinteraction prdnie par une autre, ou encore rednir des raccourcis clavier. Les changements de connexion sont aiss effectuer grce aux techniques de manipulation directe employes
dans lditeur interactif.
La tche 4. consiste employer un dispositif dentre dans une conguration existante en le
connectant directement des dimensions de lapplication. Il peut sagir dassigner des boutons dune
souris tendue des commandes, de contrler le zoom dun document avec la molette de la souris, ou
de connecter la pression dune tablette la taille de la brosse dans un logiciel de dessin (conguration de la gure 4.24 page 134). Les connexions sont directes, et la seule difcult ici rside dans les
ventuelles incompatibilits de domaines, qui ncessitent lemploi du dispositif de remise lchelle
LinearFunc.
175
La tche 5. consiste tendre une conguration dentre en ajoutant des traitements de donnes
simples, comme par exemple insrer un ltre passe-bas pour lisser les dplacements du curseur (conguration de la gure 4.30 page 137). Ce type de tche ncessite la connaissance pralable de quelques
dispositifs de traitement prdnis, et la comprhension du fonctionnement gnral du ot de donnes
pour tre capable dinsrer le dispositif au bon endroit.
5.7.3
Utilisateurs scientiques et informaticiens
Par rapport aux tches vues prcdemment, la tche 6. est plus complexe. Pour connecter des
dispositifs de nature diffrente, des dispositifs intermdiaires de traitement et de contrle doivent tre
employs, ce qui ajoute la complexit. Par exemple, connecter une dimension continue comme la
pression dun stylet un canal boolen comme le clic ncessite lemploi et la paramtrisation dun
seuil. De mme, spcier des valeurs continues avec seulement deux boutons ncessite lutilisation de
techniques dincrmentation/dcrmentation.
Notons que les dispositifs utilitaires de haut niveau fournis par la bibliothque dICON permettent
de ramener la difcult de la plupart des situations courantes celle dune tche de type 4. ou 5. :
les dispositifs adaptateurs permettent de relier entre eux des slots ou des dispositifs dun type particulier, par des techniques gnriques simples comme lincrmentation/dcrmentation prcdemment
voque, des techniques plus avances comme le pointage au clavier (conguration de la gure 4.26
page 135), ou encore de vritables techniques dinteraction comme le dispositif QuikWriting (conguration de la gure 4.26 page 135).
Nanmoins, les adaptateurs prdnis ne rpondent pas toutes les situations, et spcier de tels
mcanismes avec des oprateurs simples peut se rvler extrmement difcile pour des personnes
nayant jamais travaill sur des systmes ot de donnes. La construction dune conguration dentre complte ou la modication de parties importantes dune conguration existante lest encore plus
(tche 7). Cest pourquoi ces deux types de tches sont rservs des informaticiens sachant programmer ou des scientiques ayant une exprience des systmes ots de donnes. Dans certains
cas, lutilisation de dispositifs programmables (voir section 4.3.1 page 118) peut remplacer avantageusement la composition graphique.
5.7.4
Dveloppeurs
Enn, il peut se rvler ncessaire lors de la construction dune conguration dentre dimplmenter des dispositifs initialement non prsents dans la bibliothque (tche 8.). Ce dernier type de
tche est bien videmment rserv aux dveloppeurs, qui dsirent enrichir la bibliothque de nouveaux adaptateurs et techniques dinteraction ou prendre en charge de nouveaux dispositifs dentre.
Lensemble des tches que nous avons dcrites jusquici sont des tches de conguration. Cette
liste doit tre complte par deux autres tches : dabord celle qui consiste implmenter une application compatible avec ICON (tche 9.), et qui ncessite une connaissance minimale de la librairie
de programmation dICON et de ses principaux concepts (une section complte lui sera consacre).
Ensuite, celle qui consiste simplement utiliser cette application interactive (tche 0.), et qui ne ncessite absolument aucune connaissance dICON. Pour cette dernire tche, une documentation utilisateur prcisant comment utiliser lapplication toutefois peut savrer ncessaire, en particulier pour
des congurations dentre qui dcrivent des techniques non standard.
176
5.8. POSITIONNEMENT DE NOTRE APPROCHE ET PERSPECTIVES
5.7.5
Le cycle de vie dune conguration
Nous avons vu dans cette section comment ICON sadresse tout un continuum dutilisateurs, du
dveloppeur dapplications lutilisateur nal. Nous rsumons ici le rle respectif de chacun.
Le dveloppeur dapplications produit lapplication interactive et les dispositifs propres cette
application, et fournit une conguration par dfaut, ainsi quun ensemble prdni de congurations
dentre destins assurer une contrlabilit et une accessibilit minimales.
Lutilisateur nal peut utiliser lapplication de manire standard, ou remplacer la conguration
par dfaut par celle qui lui convient. Il peut galement, selon son degr dexpertise, personnaliser de
manire plus ou moins pousse des congurations existantes ou en construire de nouvelles, pour ventuellement les partager avec dautres utilisateurs. Les utilisateurs avancs peuvent galement assister
des utilisateurs dans la personnalisation de linteraction.
Enn, certains dveloppeurs peuvent galement de faon indpendante contribuer enrichir la
bibliothque dICON de nouveaux dispositifs, an de prendre en charge de nouvelles techniques dinteraction ou des dispositifs dentre non conventionnels.
5.8 Positionnement de notre approche et perspectives

Dans cette section, nous positionnons ICON par rapport aux principales autres approches, dans
le but de dgager les points communs et les complmentarits, et dvaluer loriginalit dICON par
rapport aux travaux existants. Nous proposons ensuite diffrentes pistes de recherche pour des travaux
futurs.
5.8.1
ICON et les autres approches
ICON et le modle MVC

La plupart des modles de rfrence (voir section 2.2 page 36) dcrivent un composant prsentation ou interaction qui gre la fois les entres et lafchage. Le modle MVC, tout comme celui
dICON, spare linteraction en entre (gre par le contrleur) de linteraction en sortie (gre par la
vue). Lobjectif dICON est de dcrire la partie contrleur de la triade, sans soccuper de la structure
des deux autres composants.
La gure 5.12 page suivante illustre larchitecture dICON dans le paradigme MVC. La conguration dentre constitue le contrleur, hormis ses dispositifs dapplication qui dcrivent chacun
une partie du modle et/ou de la vue de lapplication interactive. Les dispositifs dapplication sont en
quelque sorte linterface entre le contrleur et le reste de lapplication. Une conguration dentre
peut galement, avec des dispositifs de feedback, dcrire des vues indpendantes. Les dispositifs de
bote outils ne sont pas explicitement reprsents dans ce schma ; nous les considrons ici comme
des dispositifs dapplication qui se distinguent uniquement par leur caractre gnrique.
Lobjet M+V de la gure dcrit lapplication interactive de faon monolithique, sans distinguer
son noyau fonctionnel de sa reprsentation. En pratique bien sr, le modle M et la vue V peuvent tre
explicitement spars, de mme quils peuvent tre structurs en objets M+V plus petits. Les dispositifs dapplication crent dj une certaine structuration en encapsulant des objets M+V individuels,
177
Application
Configuration d'entre
M+V
V ... V
F IG . 5.12 ICON dans le paradigme MVC. Les dispositifs de la partie M+V sont les dispositifs dapplication de
la conguration dentre. Les vues multiples, gauche, matrialisent les sorties implicites des autres dispositifs.
qui peuvent reter ou non une structure pr-existante dans lapplication. Les widgets constituent un
exemple de structure pr-existante exploite par les dispositifs de bote outils.
Notons pour nir que les dispositifs dapplication ne sont pas tous destins tre utiliss en bout
de conguration . Certains dentre eux, les points de retour, peuvent comporter des slots de sortie et
tre employs nimporte quel niveau de la conguration (notre schma nen comporte pas pour des
raisons de lisibilit). Des dispositifs comme le Pick peuvent ainsi tre employs pour rinjecter dans
la conguration de linformation en provenance de lapplication.
ICON et les modles vnements
Les outils commerciaux de dveloppement dinterfaces et la majorit des botes outils PostWIMP proposes par la recherche (voir 2.6 page 60) reposent sur des modles vnements pour la
gestion des entres. ICON emploie un modle ot de donnes ractif o la notion dvnement est
absente, et o le paradigme de dveloppement est par consquent tout autre. Les mcanismes comme
laiguillage, labonnement et les callbacks, en particulier, sont remplacs par des connexions directes
entre modules.
Les deux approches ne sont cependant pas incompatibles, et dans certains cas elles peuvent se
rvler complmentaires6 . Le modle dICON, nous lavons vu, est particulirement adapt la description de techniques dinteraction ractives et de bas-niveau. Certains modles dinteraction, en
particulier linteraction multimodale, ncessitent des notions de plus haut-niveau, comme celles des
vnements ambigus et des stratgies de mdiation employes par Multimodal Subarctic (voir section 2.6.2 page 68). Nanmoins, toute interface, y compris les interfaces multimodales, comporte une
partie ractive de bas-niveau. Une interface gestuelle, par exemple, a besoin daccder aux dispositifs
dentre physiques, de produire en temps rel des traces et de les afcher.
Nous pensons que tout paradigme dinteraction 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 entres. Pour reprendre lexemple de linteraction gestuelle, dautres dispositifs que la souris ou la tablette (par exemple, un dispositif de suivi oculaire) sont susceptibles de
produire une trace. Mme des dispositifs de nature non positionnelle peuvent tre exploits avec des
algorithmes et des mcanismes de reconnaissance gestuelle : une succession de touches au clavier est
6 Par
exemple, ICON permet facilement de dcrire des dispositifs gnrateurs dvnements qui, partir dattributs
simples transmis en entre, et chaque signal sur un slot send, instancient des vnements pour les placer dans une le.
178

interprtable comme un geste, par exemple. Le modle dICON, et sa notion dadaptateurs en particulier, facilite et mme encourage les utilisations multiples des dispositifs dentre. Au contraire,
lapproche vnementielle, quelle soit ou non ouverte aux entres non conventionnelles, requiert une
classication des dispositifs et lattribution dun rle g chacun dentre eux.
Ds lors, il ressort une question essentielle, savoir jusqu quel niveau linteraction doit tre
dcrite avec IC ON ? Nous navons pas tudi les manires de combiner notre modle avec des architectures Post-WIMP de plus haut-niveau. Cependant, nous avons montr comment ICON pouvait
permettre de dcrire des techniques dinteraction de type instrumental dans un certain niveau de
granularit. Cette exprience nous a notamment permis de raliser quil serait par trop simplicateur de dcomposer la gestion de linteraction en couches ges. En effet, certains lments contrlables dune application interactive (ou points dentre, dans notre terminologie) sont de bas-niveau
et peuvent tre manipuls avec des techniques de contrle direct. Par exemple, la plupart des widgets
sont des dispositifs virtuels qui peuvent, la manire des Phidgets, tre directement associs des
dispositifs rels. Cest galement vrai pour certaines structures propres lapplication. Des parties
de linteraction peuvent par consquent tre intgralement dcrites avec des ots de donnes ractifs,
des dispositifs physiques jusqu lapplication. Une architecture interactive employant un modle du
type ICON comme couche basse devrait par consquent autoriser ce type de court-circuitage , sous
peine dignorer les techniques de contrle direct ou de les dcrire avec des mauvaises abstractions.
ICON et les systmes de transition

Les rseaux de Ptri et les automates tats sont des approches orientes contrle, orthogonales
la notre. Elles dcrivent particulirement bien les mcanismes de multiplexage temporel et les modes
employs dans les interfaces conventionnelles. linverse, les interfaces Post-WIMP de type instrumental comportent relativement peu de contrle et sont plutt caractrises par des ots de donnes.
Cependant, moins de disposer dun dispositif physique pour chaque objet dintrt, toute interface
comporte ncessairement une partie contrle. En outre, pour des raisons daccessibilit, nous nous
devons de prendre en charge les situations dentres appauvries. Ce que nous faisons actuellement,
mais en encapsulant les techniques daccessibilit dans des adaptateurs.
Sil est difcile dintgrer le contrle et les donnes dans le mme paradigme, deux types dapproches hybrides sont envisageables : au niveau macroscopique lextrieur dICON et au niveau
microscopique lintrieur des dispositifs. La premire approche consisterait rendre les congurations dentre dynamiques et contrler les reconnexions dans des automates ou des rseaux de Ptri,
la manire de VRED (voir section 2.7.3 page 88). Bien que nous ayons dj motiv une approche
essentiellement statique et que nous estimons que le problme de lhybridation na pas encore t
rsolu de faon convaincante au niveau du langage visuel, ce type dapproche mrite dtre tudi.
Lapproche consistant dcrire une partie des comportements des dispositifs avec des machines
tats nous parat une piste prioritaire. Un langage impratif comme Java permet dimplmenter facilement des dispositifs, mais ne dispose pas des outils adapts pour dcrire des machines tats
complexes. Une extension syntaxique comme celle propose par [B LANCH 02] permettrait demployer
les approches ot de donnes et ot de contrle de manire orthogonale et rellement complmentaire. Lagencement visuel de blocs reposerait ainsi sur un paradigme ot de donnes, et les
mcanismes internes ces blocs seraient dcrits avec un langage programmation conventionnel mais
sachant prendre en charge les transitions dtats.
179
Les approches analogues
ICON se situe la frontire de plusieurs approches. Tout dabord, le principe de ots de donnes
sur lequel il repose a t exploit dans de nombreuses applications, principalement dans les domaines
de traitement et danalyse dimages et de composition musicale. Ensuite, ICON emploie un langage
visuel pour dcrire linteraction, comme le font beaucoup de logiciels commerciaux et doutils produits par le monde de la recherche. Cependant, les nombreuses approches du type Visual C++ de
Microsoft, et y compris celle de Garnet/Amulet (voir section 2.6.1 page 63) se concentrent principalement sinon exclusivement sur lagencement de composants visuels. Les diteurs de comportement
comme Thinglab ou Fabrik (voir section 2.7.2 page 80) peuvent permettre de dcrire certains aspects
touchant linteraction en entre, mais sont plus adapts la partie modle (synchronisation entre
plusieurs modles et entre modles et vues) et graphique (maintien de contraintes gomtriques) de
lapplication.
Lapproche consistant utiliser un langage visuel bas sur un modle ot de donnes pour dcrire linteraction en entre a t trs peu explore dans le domaine de linteraction 2D. Lun des rares
exemples est la bote outils Whizz et lditeur WhizzEd (section 2.7.2 page 83). Si ce langage visuel
a t principalement cr pour dcrire des interfaces animes et des interactions simples, son extension
linteraction bimanuelle (section 2.6.2 page 70) donne des exemples de conguration dentre assez
proches de ce que lon pourrait construire avec ICON. Whizzed donnait dj une bonne ide de la
puissance du modle ot de donnes pour dcrire le contrle dapplications hautement interactives.
ICON approfondit et tend cette approche, tout dabord en posant les principes dun modle dentre
bas sur des dispositifs gnraliss regroupant dispositifs physiques, points dentre et adaptateurs,
ensuite en proposant un modle dexcution bas sur les langages ractifs. Enn, ICON explore plus
loin ce paradigme, en exploitant des dispositifs dentre multiples et bien dautres techniques dinteraction non-standard.
Si notre approche est novatrice dans le monde de linteraction 2D, elle peut nanmoins sembler
familire aux dveloppeurs dapplications 3D. Nous avons vu que la plupart des botes outils 3D
reposaient sur un modle dentre ot de donnes, et que quelques unes proposaient des diteurs
visuels comparables au notre. Cest notamment le cas de Virtools Dev (voir section 2.7.3 page 86). Ces
outils sont bien adapts la description dinteractions 3D, et plus particulirement la manipulation
directe dobjets 3D avec des dispositifs sophistiqus. ICON applique linteraction 2D les techniques
qui font le succs des applications 3D, savoir lusage de dimensions physiques multiples dans des
techniques contrle direct. En outre, ICON prend en charge des dispositifs plus divers et intgre des
techniques 2D que les outils 3D taient incapables de dcrire, notamment parce que ces techniques
sont beaucoup plus varies et complexes, comportent des modes et des feedbacks, et oprent sur des
objets de nature bien plus diverse que les attributs dobjets 3D.
5.8.2
Quelques perspectives
ICON, en tant que travail exploratoire, ouvre de nombreuses voies. Nous en avons soulign quelqueunes sur la gure 5.13 page ci-contre. Nos contributions y sont voques en gris, savoir le paradigme
de cascades de dispositifs (en bas) et ses applications successives : le modle ICOM, la bote outils
et lditeur dICON, les congurations dentre que nous avons construites et enn leurs applications.
Ces contributions sont agences selon laxe application, qui constitue une premire direction dexploration possible pour les perspectives. Les deux autres axes sont la validation de notre approche (cet
180
Application
Applis.
Validation
Exps
Configurations
B.A.O. ICon
Evaluation
Formalisation
Dispositifs
Evaluation
diteur ICon
ICom
IConLite
Types tendus
Casc. implicites
Intgration
Cascades de dispositifs
Extension
F IG . 5.13 Perspectives.
axe dpend en partie des applications dveloppes, do son orientation diagonale) et lextension de
celle-ci.
Le modle ICOM dcrit les mcanismes de linfrastructure data-ow dICON. Plusieurs orientations sont possibles pour celui-ci : dabord, une formalisation permettrait dune part de valider la
abilit de notre modle, dautre part de vrier des proprits sur les congurations. Nous avons
dj voqu la possibilit dexploiter des outils de vrication de langages ractifs comme Esterel
[F EKETE et al. 98, F EKETE & D RAGICEVIC 00]. Diverses voies sont possibles quant lextension du modle
ICOM : lintgration avec des modles existants, en particulier des formalismes orients-contrle et
des modles dinteraction plus haut-niveau (voir 5.8.1 page 179) ; la prise en charge de types tendus
pour faciliter la construction de congurations dentre et de cascades implicites ditables pour exposer efcacement les modles physiques des dispositifs. Ces deux dernires ides seront dveloppes
plus loin.
En dehors de son infrastructure ICOM, ICON peut tre divise en deux parties : la partie bote
outils qui dcrit la librairie extensible de dispositifs, et lditeur interactif de congurations. Chaque
de ces deux parties peut tre valide par une valuation : la premire pour prouver la pertinence de
loutil vis--vis du programmeur, et la seconde pour dterminer lutilisabilit du congurateur interactif. Nous avons dj constat que les deux dveloppeurs que nous avons suivis taient capables, aprs
un temps dassimilation, de produire rapidement des dispositifs dapplication chaque fois que cela
savrait ncessaire, et de matriser toutes les potentialits de lditeur interactif. Nous ne nous attendons cependant pas ce quun utilisateur moyen emploie lditeur de la mme manire. Au lieu de
cela, nous avons montr en quoi lutilisateur, selon ses comptences, pouvait tirer parti de ce langage
visuel pour des tches simples. Une valuation permettrait de dterminer plus prcisment en quoi
consistent ces tches. Nous nous doutons cependant que la mise en place de telles exprimentations
serait loin dtre triviale, en particulier sil sagit dvaluer la pertinence dICON par rapport dautres
outils. Ainsi, si les botes outils conventionnelles permettent de dvelopper facilement des interfaces
WIMP, elles ne prennent pas en charge la majeure partie des techniques dinteraction quICON permet
181
de dcrire. La comparaison est difcile, faute de cibles de comparaison.
La bibliothque dICON, bien que dj trs complte, gagnerait cependant tre tendue avec
de nouveaux dispositifs. Les principaux dispositifs systme que nous projetons dimplmenter, dans
le but de couvrir une plus vaste palette dentres non standard, sont les priphriques MIDI, USB,
et lanalyse vido. Nous avons depuis peu notre disposition un certain nombre de botes potentiomtres MIDI dont lexploitation dans ICON nous semble trs prometteuse. Linterface HID des
priphriques utilisateur USB, en plus dtre gnrale, est trs dtaille et intgre bon nombre dinformations pragmatiques sur le dispositif physique (mme si malheureusement, les constructeurs nimplmentent pas toujours cette interface entirement). Linteraction multidigitale [R EKIMOTO 02], maintenant ralisable avec des dispositifs tactiles matriciels du commerce [TACTEX 03, F INGERW ORKS 03],
nous parat galement avoir un fort potentiel. Nous projetons galement dajouter dautres dispositifs
utilitaires ICON, dont divers adaptateurs daccessibilit (techniques simple bouton, notamment),
dautres techniques dinteraction prtes lemploi, et des dispositifs ddis au feedback reposant sur
un modle graphique multicouche similaire [F EKETE 96 B]. Enn, nous avons dj voqu un projet
en cours dont le but est de dcrire de nouveaux dispositifs de bote outils pour contrler les applications zoomables dveloppes avec Piccolo [B EDERSON 03]. Lobjectif de ces dispositifs est lintgration
complte dICON une bote outils graphique avance.
Nous avons dj propos dans ce mmoire quelques amliorations pour le congurateur interactif
dICON : par exemple, lannotation des congurations des ns de documentation et une technique
de zoom smantique pour naviguer dans les dispositifs composites. Les utilisateurs non-experts pourraient galement bncier dune version allge du congurateur interactif qui leur serait spcialement destine : nous dvelopperons les ides la base dICONLITE par la suite.
un niveau au-dessus se situent les congurations dentre construites avec ICON. Bien quelles
soient dj nombreuses, bien dautres techniques peuvent tre dcrites avec les dispositifs existants. En
particulier, nous pensons que le potentiel des techniques dinteraction de bas-niveau type pointage
augment mrite dtre davantage explor. En outre, au fur et mesure quICON se verra enrichir
par de nouveaux dispositifs, dautres congurations exploitant ces dispositifs viendront sajouter
celles existantes.
Lobjectif des congurations dentre est de dcrire linteraction avec des applications. ce jour,
toutes les applications reposant sur Swing peuvent tre contrles avec ICON (nous avons galement
dcrit le contrle partiel de Microsoft Word et de Jazz, mais uniquement titre exprimental). En
dehors des applications-jouets comme ICONDraw, deux projets dapplications employant ICON ont
t voqus (voir section 4.5 page 141). Nous projetons de dcrire le contrle dapplications de natures plus varies et en particulier des applications gourmandes en entres tels que les jeux vido
et les applications danimation 3D. Les visages anims comme ceux des agents Haptek [H APTEK 03]
notamment, comportent un grand nombre de dimensions qui peuvent tre contrles simultanment.
Nous esprons galement que notre distribution dICON sera employe dans des projets de dveloppement extrieurs. Enn, comme nous lavons vu dans la section 4.5 page 141, ICON a galement servi
monter une exprimentation visant comparer plusieurs techniques dinteraction. Nous pensons
quICON pourra tre dune aide non ngligeable dans ce type de tche, car il offre un accs ais aux
dispositifs non-standard et permet de prototyper rapidement des techniques dinteraction, de les afner et den tudier plusieurs variantes. En outre, ICON rend explicite toute la chane de traitements, et
la reprsentation visuelle quil donne de cette chane est un outil de comprhension qui peut tre mis
prot pour illustrer des tudes comparatives.
182

Nous terminons cette section par trois perspectives dextension que nous venons dvoquer et
qui mritent dtre un peu plus dveloppes : les types tendus, les cascades implicites ditables, et
ICONLITE.
Types tendus
Il existe de nombreuses raisons dtendre notre systme de typage avec des types plus restrictifs. Tout dabord, les remises lchelle sont frquentes dans ICON, et il est difcile demployer
loprateur de transformation linaire sans connatre les domaines de dpart et darrive7 . Il nous
semblerait par consquent utile dinclure les domaines dans les types de slot, information qui pourrait
par exemple tre exploite par des adaptateurs de domaine automatiques, ou comme pr-conditions
dans des dispositifs dapplication.
F IG . 5.14 Utilisation de la valeur au repos pour justier une technique de contrle du second ordre. La
dimension x de la manette ( droite) contrle la dimension x dun pointeur ( gauche) aprs une opration
de recentrage, une intgration, et un seuil. Une connexion directe serait permise avec un typage simple, mais
enfreindrait ici les pr-conditions du pointeur (domaine et non-volatilit) [D RAGICEVIC 98].
Les pr-conditions et post-conditions pourraient tre gnralises bien dautres proprits, notamment dans le but de prendre en compte certaines caractristiques pragmatiques des dispositifs
[B UXTON 83]. Ces proprits doivent pouvoir tre aisment propages travers les dispositifs. Cest le
cas des valeurs particulires, qui peuvent dans certains cas tre transformes par la fonction dexcution8 . Dans [D RAGICEVIC 98], nous dcrivons des proprits pragmatiques qui rentrent dans ce cadre.
Un slot, par exemple, peut conserver sa valeur lorsque lutilisateur nexerce plus daction sur les dispositifs physiques, ou bien revenir une valeur au repos. Cette valeur au repos permet de spcier
des pr-conditions extrmement intressantes dans les dispositifs dapplication (gure 5.14). Dautres
proprits comme la prcision et la latence peuvent tre galement prises en compte, et propages de
faon spcique.
Les types tendus avec des pr-conditions et des post-conditions permettraient la fois de proposer des adaptateurs volus facilitant signicativement la construction de congurations, et de vrier certaines proprits dans la conguration dentre. Par exemple, une prcision minimale pourrait
tre requise en entre dun pointeur ou dun dispositif gestuel. Malgr les nombreuses applications,
cette approche demande un vaste travail et pose plusieurs problmes : tout dabord lutilisation de
types tendus complique limplmentation des dispositifs qui doivent calculer explicitement certaines
7 Nous
avons en partie rsolu ce problme en standardisant les domaines lorsque ctait possible : les coordonnes cran
sont employes pour les valeurs positionnelles (la tablette produit des position cran en valeur ottante), et la plupart des
autres valeurs bornes, comme la pression du stylet, sont normalises dans le domaine [0, 1].
8 Les valeurs particulires peuvent tre propages automatiquement travers des dispositifs dterministes du premier
ordre (sans mmoire). Les bornes min et max du domaine sont des valeurs particulires, mais qui ncessitent un traitement
spcique lorsque le dispositif dcrit une fonction non strictement monotone.
183
post-conditions9 . En outre, les post-conditions ne peuvent pas toujours tre dduites prcisment, et
deviennent rapidement vagues au fur et mesure des traitements. Enn, les informations concernant
les dispositifs dentre physiques (par exemple, la valeur au repos) ne sont pas toujours disponibles.
Cascades implicites ditables
Pilotes
Dispositif concret
y
2.3cm
3.2cm
x z
-0.2cm
4
3
2
1
0
x
true
y
down
1
2
0A
0B true
0C
true
0 1 2 3
cascade simule
key
down
OB
true
string
"5"
0D
...
Cascade relle
F IG . 5.15 Exemple de cascade implicite pour une bote boutons : le pilote de dispositif produit des vnements down/up avec des codes touche (troisime dispositif en partant de la gauche), et chaque vnement down
est converti en caractre. Il est possible dimaginer une srie de traitements implicites menant la production
des vnements down/up : par exemple, lorsque lutilisateur presse un bouton, la nouvelle position (x, y, z) de
ce bouton (qui est aussi celle du doigt) est mise, puis discrtise, et enn convertie en code touche.
Lorsquun dispositif dentre ICON fournit une vue logique assez loigne du modle concret du
dispositif, il serait intressant des ns dexplication de rendre le dispositif concret visible dans la
conguration, et de reproduire la cascade implicite (ou une cascade possible) de traitements en aval
de ce dispositif (gure 5.15). Le dispositif de reconnaissance vocale, par exemple, pourrait apparatre
comme un dispositif de traitement connect un microphone physique.
La cascade implicite peut mme tre rendue modiable si les dispositifs qui la composent sont
rels et non plus simuls, et quils sont inversibles. Un dispositif de fonction de transfert f est inversible sil existe un dispositif de fonction de transfert f 1 telle que f f 1 = Id (voir galement
[ACCOT et al. 97]). Or supposons que f = g h dsigne une cascade implicite divise en une partie noninversible g et une partie inversible h. Si la partie h est modie en h2 , il sufrait pour prendre en
compte cette modication dappliquer la fonction de transfert h1 h2 en sortie du dispositif logique.
Ainsi, dans lditeur graphique, les dispositifs de g seraient non modiables mais la cascade h pourrait
tre modie comme tout lment de la conguration. Le traitement rel h1 h2 resterait cependant
invisible lutilisateur.
Les applications potentielles des cascades implicites ditables sont nombreuses. Sur la conguration de la gure 5.15 par exemple, il serait possible de se servir de la vue matricielle de la bote
boutons pour calculer la moyenne des (x,y) enfoncs et contrler grossirement un pointeur. Le dispositif concret pourrait fournir des informations spatiales galement utiles. Un modle de manette
intgrant les diffrentes grandeurs physiques (dplacement rel, force exerce sur le manche), par
9 Le
calcul des post-conditions pourrait cependant tre pris en charge par un ensemble restreint de dispositifs atomiques
prdnis.
184

exemple, permettrait de donner un sens aux valeurs numriques produites par le pilote de dispositif
[D RAGICEVIC 98]. La cascade implicite pourrait galement remonter jusqu un modle dutilisateur
comportant des post-conditions qui dcrivent ses capacits motrices (par exemple, la force maximale
quil est capable dexercer).
Le calcul de linverse devrait tre la charge de chaque dispositif, qui implmenterait une fonction du type Device createInverse(). Linconvnient, l encore, rside dans la difcult pour le
dveloppeur de programmer de tels dispositifs, en particulier si les inversions sont employes en combinaison avec des types tendus10 .
ICONLITE
Notre exprience avec ICON nous a conduit penser quil est possible, en poussant plus loin
lexploitation de la mtaphore de la connexion logicielle (voir section 3.2.1 page 94), de construire
un diteur de congurations lusage de lutilisateur moyen, qui soit la fois simple dutilisation et
puissant. Ceci condition de concevoir les techniques de visualisation et dinteraction appropries.
Lditeur WhizzEd (voir section 2.7.2 page 83) emploie des reprsentations iconiques des dispositifs, ce qui facilite leur identication. Les Phidgets (voir section 1.3.5 page 23) exploitent une
technique de conguration extrmement naturelle, consistant brancher un dispositif USB puis
lassocier un widget prsent lcran par un simple clic. Si la contrlabilit et la congurabilit
offerte par les Phidgets est bien en de dICON, le paradigme de connexion dynamique peut tre
tendu et exploit dans une version allge dICON.
F IG . 5.16 gauche : le dock de Mac OS X (en bas de la fentre). droite : Interface Builder dApple, qui
permet de connecter graphiquement des widgets leur modle, et de visualiser ces connexions tout moment.
Les dispositifs dentre connects peuvent tre reprsents graphiquement dans une barre de dispositifs inspire du dock de Mac OS X [A PPLE 02] (gure 5.16, image de gauche). Lorsquun nouveau dispositif est branch, cette barre apparat pour permettre dtablir une connexion avec les
lments prsents lcran. Les connexions sont afches en incrustation la manire dInterface
10 Dans
le cas de la bote boutons, par exemple, une cascade inverse produirait partir de chaque symbole un domaine
bidimensionnel.
185
Builder [A PPLE 03] (gure 5.16 page prcdente, image de droite) dans le mode de construction, et
disparaissent dans le mode dinteraction. Le mode de construction peut tre ractiv tout moment
pour modier les connexions.
Une palette dadaptateurs permettrait dinsrer des traitements supplmentaires dans les connexions
(par exemple, une rptition automatique pour un bouton). Ceux-ci doivent tre simples dutilisation
et contrairement la version actuelle de notre diteur, avoir une reprsentation graphique iconique
explicite. Des mcanismes de connexion intelligents doivent pouvoir permettre linsertion automatique dadaptateurs (adaptateurs de domaine, notamment), ainsi que les connexions groupes de
slots entre objets compatibles.
En outre, des objets dapplication non visuels (par exemple, le pan ou le zoom) doivent pouvoir
tre ris et afchs, par exemple dans une palette propre lapplication. Il en est de mme pour des
objets systme comme les pointeurs.
Deux objets compatibles (par exemple, une souris et un curseur) peuvent tre directement relis,
ce qui ne ncessite pas la prsence explicite de slots. En revanche, il est indispensable que les objets
puissent tre afchs avec plusieurs niveaux de dtail. Par exemple, un clavier peut tre reli un
diteur de texte, mais des connexions de touches individuelles doivent galement tre possibles.
Pour nir, il serait intressant dexplorer les diffrents moyens dtendre matriellement nos systmes an de dplacer une partie de la tche de conguration vers le niveau physique. Par exemple,
lorganisation de la barre de dispositifs peut reproduire lagencement spatial des prises USB, ces
dernires pouvant notamment tre places sous lcran. Chaque prise USB pourrait se voir assigner
un rle diffrent, et des adaptateurs matriels pourraient galement tre employs (des adaptateurs
USB portant un identiant reconnu par ICONLITE sufraient). Certains utilisateurs disposeraient par
exemple dadaptateurs daccessibilit personnels. Enn, tant donn quun dispositif de pointage est
toujours ncessaire pour connecter des dispositifs des objets graphiques, un cran tactile pourrait
tre employ et ddi cet effet.
186
Conclusion et perspectives
Rappel de la problmatique
Nous avons introduit dans cette thse le terme dadaptabilit en entre comme une combinaison
de trois proprits : la contrlabilit, qui caractrise la capacit dun systme interactif exploiter
efcacement des entres enrichies, laccessibilit, qui dnit sa capacit exploiter des entres appauvries, et la congurabilit, qui dcrit sa capacit pouvoir tre nement personnalise du point
de vue des entres. Ces trois proprits sont fortement lies et constituent trois facettes dune proprit plus gnrale, qui caractrise des systmes interactifs entirement ouverts en entre . Aprs
avoir montr en quoi il tait essentiel de tendre vers ce type de systme, nous avons mis en vidence
le retard considrable accumul par les systmes interactifs grand public actuels, retard largement
d des outils de dveloppement gs, exclusivement bass sur le modle de linteraction standard
(souris, clavier et techniques dinteraction WIMP). Les rares applications faisant usage dentres non
conventionnelles, comme les jeux vido ou certaines applications semi-professionnelles, ncessitent
une programmation artisanale extrmement coteuse en temps et en nergie.
Si la complexit et limportance des problmes lis linteraction en entre sont aujourdhui
universellement reconnues par la communaut de linteraction homme-machine, ce domaine a encore
fait lobjet de peu de travaux. Nous avons prsent dans notre tat de lart les principaux modles et
outils pertinents du point de vue de linteraction en entre, et avons montr en quoi certaines approches
constituaient une avance dans le domaine de linteraction en entre, bien quaucun modle ou outil
ce jour ne rponde aux exigences de ladaptabilit en entre sous tous ses aspects.
La spcicit de notre dmarche

Les contributions de la recherche les plus pertinentes du point de vue de notre problmatique sont
les botes outils graphiques avances, qui se sont donnes pour objectif de corriger les principales faiblesses des outils de dveloppement existants. Les contributions comme Subarctic et Garnet/Amulet
montrent quun modle dinteraction en entre standard assez gnral peut tre en partie tendu pour
dcrire des techniques plus volues. Les botes outils Post-WIMP ont, de leur ct, introduit de
nombreux modles nouveaux dinteraction, spciquement adapts des paradigmes comme linteraction gestuelle, lusage de modalits ambigus, linteraction multi-utilisateurs ou encore linteraction bimanuelle avec des outils semi-transparents. Malgr leurs apports indniables, les botes outils
avances sappuient sur des modles vnementiels conventionnels, o seuls les dispositifs standard
ou un nombre xe de dispositifs tendus peuvent tre pris en compte. Par ailleurs, ces outils exploitent
ces dispositifs de manire efcace mais ge, ou au mieux difcile tendre.
187
CONCLUSION ET PERSPECTIVES
Depuis lintroduction des standards comme GKS, bien des modles et des outils continuent demployer des abstractions dans lesquelles les dispositifs dentre sont regroups en classes dquivalence
strotypes. Les tches dinteraction ont subi des simplications analogues, notamment par lintroduction des widgets gnriques. Essentiellement motive par des problmes de portabilit et de rutilisabilit, ce type dapproche empche cependant de tirer parti des capacits intrinsques de chaque
dispositif et des caractristiques de la tche. Notre dmarche se distingue des approches existantes
dans le sens o elle nglige (dans un premier temps) les problmes de portabilit pour tenter de rpondre la question suivante : sur un systme concret, qui comprend un ensemble donn de dispositifs
physiques, lutilisateur peut-il efcacement tirer parti de ces dispositifs pour contrler une application
donne ?
Il nous a paru ncessaire pour rpondre cette question de substituer aux dispositifs logiques des
dispositifs concrets, qui apparaissent au plus bas niveau possible, cest--dire comme des ensembles
de canaux bruts ; de mme, les objets du domaine doivent pouvoir tre exposs sans a priori sur la
faon dont ils seront contrls, et nous devons enn disposer dun moyen exible de relier les canaux
dentre lapplication interactive pour pouvoir la contrler. Notre dmarche sinspire dapproches
couramment employes dans les outils de dveloppement dapplications 3D. Comme certains de ces
outils, nous proposons un paradigme de programmation visuelle pour lassignation des canaux : cette
ide est pertinente dans la mesure o les canaux ne comportent pas de smantique, et laccs tout
nouveau dispositif physique dans un langage textuel ncessiterait des requtes pralables lAPI de
bas niveau pour connatre linterface du dispositif. linverse, un nouveau dispositif peut apparatre
explicitement dans un langage visuel, auquel cas ses canaux ne ncessitent quune interprtation smantique de la part de lutilisateur pour pouvoir tre exploits.
ICON et son modle dinteraction en entre

Le modle dinteraction en entre que nous avons propos dans cette thse est bas sur le principe
de congurations dentre, dont les dispositifs gnraliss constituent les briques de base. Les dispositifs gnraliss sont des modules (agents) qui comportent des canaux en entre et en sortie et peuvent
traiter de linformation. Ils regroupent les dispositifs systme, qui dcrivent principalement des dispositifs dentre physiques, les dispositifs utilitaires, modules de traitement de donnes et de feedback,
et les dispositifs dapplication, qui exposent indpendamment des entres les dimensions directement
contrlables de lapplication. Une conguration dentre dcrit la faon dont des dispositifs systme
sont connects aux dispositifs dapplication travers des dispositifs utilitaires. Dans ce paradigme,
les dispositifs utilitaires peuvent tre vus aussi bien comme des adaptateurs que comme des morceaux de techniques dinteraction. Les congurations dentre sappuient sur un modle ot de
donnes qui permet de dcrire des canaux structurs et des dispositifs composables et spcialisables.
Elles emploient en outre un modle dexcution qui sinspire des langages ractifs.
Le systme ICON (Input Congurator) a permis la fois de valider et dafner notre modle, et de
montrer la faisabilit dun outil de prototypage et de dveloppement pour des interfaces adaptables en
entre. ICON est une bote outils dentres, qui ne traite que les aspects entres indpendamment
des aspects sorties , contrairement aux botes outils existantes o ces deux notions sont habituellement imbriques. Dvelopp dans le langage Java, ICON comprend un ensemble riche et aisment
extensible de dispositifs systme et utilitaires, les dispositifs dapplication tant dclars par chaque
application travers un mcanisme simple. Les applications Java/Swing existantes peuvent galement
tre contrles de manire gnrique travers des dispositifs de bote outils graphique . ICON
188
peut accder aux entres et contrler les applications plusieurs niveaux, et peut tre employ pour
rednir tout ou partie de linteraction en entre. Il est par exemple possible dajouter une prise en
charge des dispositifs spcialiss une application 3D existante tout en conservant sa gestion standard
des entres.
ICON offre en outre des outils pour assurer une portabilit minimale des congurations dentre
dun systme lautre, par des mcanismes qui permettent de dcrire des quivalences entre dispositifs concrets sans notion de classe a priori. Les mcanismes des descripteurs de dispositifs sont
uniques dans la mesure o ils permettent de jouer sur la nesse des descriptions pour rendre des congurations standard plus tolrantes aux diffrences de plate-formes avant distribution, ou au contraire
leur permettre de dissocier sur une plate-forme donne deux dispositifs trs proches mais employs
diffremment (souris main gauche et souris main droite, par exemple).
Dcrire linteraction avec des ots de donnes

Notre approche ot de donnes est innovante dans le domaine des applications interactives
2D, o les rares diteurs visuels de comportement emploient comme Thinglab des systmes base de
contraintes, principalement pour dcrire des relations gomtriques entre les widgets dans les applications WIMP. Seul loutil 2D Whizzed a servi dcrire quelques techniques dinteraction bimanuelle
par des ots de donnes, mais lapproche navait pas encore t gnralise dautres dispositifs et
dautres techniques Post-WIMP ou daccessibilit. Les ots de donnes ont, nous lavons vu, connu
plus de succs dans le domaine de la 3D, mais les interactions que ces outils permettent actuellement
de dcrire sont encore limites. ICON permet de contrler des objets plus varis que des attributs de
formes 3D, dexploiter des dispositifs dentre de nature bien plus htrogne, et permet demployer
ou construire des techniques dinteraction plus volus que le simple contrle direct.
Notre approche ot de donnes se situe par ailleurs loppos des dmarches de modlisation
orientes contrle comme les rseaux de Ptri ou les automates tats, adapts la description du
multiplexage temporel et des modes, mais non la reprsentation et au traitement de linformation. La
description du contrle dans ICON est possible mais se fait gnralement au dtriment de la lisibilit.
Son diteur interactif fournit malgr tout des outils (raccourcis de dispositifs, zoom, encapsulation par
composition) qui se sont rvls efcaces pour grer ce type de complexit.
Nous pensons cependant que le tout-visuel a ses limites, et prnons une approche mlant lemploi doprateurs simples et de techniques dinteraction monolithiques dveloppes dans un langage
conventionnel. Notre exprience a en effet montr qu un certain niveau de granularit, linteraction en entre pouvait en grande partie tre dcrite comme des ux unidirectionnels de donnes et
qu ce niveau, la congurabilit lemportait avantageusement sur la complexit. Idalement, lemploi dICON devrait se limiter linsertion et la paramtrisation dadaptateurs prdnis comme le
dispositif gestuel (qui traduit des sries de positions en commandes boolennes et produit du feedback) ou le dispositif contrle clavier (qui convertit quatre canaux boolens en positions). Le
rle des dispositifs de traitement plus simples (oprateurs mathmatiques ou boolens, traitement de
signal, branchements conditionnels, animation) reste toutefois essentiel, car ils permettent dafner
les techniques dinteraction prdnies et de construire des techniques rpondant des situations trs
spciques.
189
Les apports essentiels de notre approche

Le premier avantage de notre modle dinteraction en entre est quil permet de dcrire toute la
chane de gestion des entres de manire explicite, du dispositif physique jusqu lapplication. Dans
les systmes interactifs conventionnels, les techniques dinteraction sont concrtement implmentes
sur plusieurs niveaux dabstraction, la plupart de ces niveaux tant inaccessibles au programmeur
dapplications ; celui-ci dispose en particulier dune visibilit trs limite quant aux traitements effectus aux niveaux bas. linverse, notre modle expose tous les aspects de la gestion des entres de
manire homogne et modulaire, dune manire qui permet de saisir des aspects habituellement obscurs de linteraction en entre : dans notre paradigme, les techniques dinteraction sont simplement
des adaptateurs ou des compositions dadaptateurs dont la disposition en srie traduit des cascades de
traitement de donnes et de feedback.
Une spcicit de notre approche est quelle repose sur un modle dexcution ractif. Les langages ractifs, dans lesquels la propagation de linformation est conceptuellement instantane, sont
particulirement adapts la description de systmes qui ragissent immdiatement lenvironnement. Aujourdhui, seuls les aspects trs bas-niveau de linteraction sont grs de faon ractive (pilotes de dispositifs, animation du pointeur), le reste tant pris en charge par des modles vnements
qui sont de type conversationnel (lutilisateur attend que les vnements soient traits). Nous pensons cependant que la majeure partie de linteraction en entre gagne tre dcrite de faon ractive.
Les aspects asynchrones et non-dterministes de linteraction, lis par exemple des techniques de
reconnaissance vocale ou gestuelle, sintgrent en outre dans notre modle de faon trs naturelle.
La mtaphore de la connexion logicielle et le principe dadaptateurs qui caractrisent notre modle constituent des paradigmes naturellement appropris la description dapplications entirement
congurables en entre. Lditeur interactif dICON instrumente ces paradigmes avec des techniques
dinteraction tudies pour faciliter la construction de congurations dentre et offrir une congurabilit un public plus large que les seuls dveloppeurs. Les utilisateurs avancs peuvent ainsi, selon
leur degr dexpertise, personnaliser des congurations dentre prdnies pour les adapter leurs
besoins ou ceux dautres utilisateurs. Lditeur interactif dICON est galement un outil de prototypage qui permet aux dveloppeurs de construire et tester pour leur application un grand nombre de
techniques de contrle en fonction des dispositifs physiques potentiellement disponibles.
Les possibilits offertes par ICON et son diteur interactif sont extrmement nombreuses, et nous
nen navons explor quun sous-ensemble. Nous avons dcrit dans cette thse plusieurs exemples de
congurations fonctionnant avec des applications Swing dj existantes ou avec une application de
dessin conue pour tre exclusivement contrle avec ICON. Ces exemples illustrent diverses faons
dexploiter des dispositifs standard (clavier, souris) ou volus (tablettes graphiques, reconnaissance
vocale, dispositifs 3D) avec des adaptateurs prdnis (contrle positionnel au clavier, interaction gestuelle, outils semi-transparents,. . .) ou par combinaison doprateurs simples (interaction bimanuelle,
commandes vocales, techniques de bas niveau indites), pour contrler des applications interactives
de faon gnrique ou ddie.
Un avantage dcisif de lapproche ot de donnes est quelle est particulirement adapte la
description dinteractions Post-WIMP fortement concurrentes, directes et amodales. ICON encourage
en outre lemploi de dispositifs physiques multiples et la description de techniques dinteraction novatrices et ddies la tche. De plus, ICON fournit les outils ncessaires pour dcrire la majorit des
paradigmes dinteraction non conventionnels que nous avons voqus dans le premier chapitre. Les
styles dinteraction pour lesquels ICON est moins adapt sont de deux types : dabord, nous lavons
190
vu, les comportements essentiellement orients contrle. Ensuite, les paradigmes Post-WIMP qui font
un usage volu de modalits naturelles : interprtations smantiques avances, fusion de modalits
htrognes et prise en charge de lambigut. Nous qualions ces dernires techniques de communicationnelles (linterface est un interlocuteur intelligent) par opposition aux techniques instrumentales
(linterface est un ensemble doutils) pour lesquelles ICON est le mieux adapt. Mme des modles
vnements sophistiqus du type Multimodal Subarctic gagneraient cependant reposer sur une
infrastructure ICON pour dcrire les niveaux bas de linteraction en entre.
Pour nir, ICON constitue une solution originale et efcace aux problmes lis ladaptabilit en
entre. Il permet de dcrire des applications hautement contrlables grce une prise en charge de
dispositifs dentre multiples, lemploi dabstractions de bas niveau pour dcrire la fois ces dispositifs et les besoins spciques de chaque application en termes dentres, la facilit de spcication
dinteractions fortement concurrentes, et la prsence dune librairie extensible de techniques dinteraction Post-WIMP prtes lemploi. Une accessibilit minimale est assure par la prsence dun
ensemble aisment extensible de techniques daccessibilit gnriques reposant sur le principe des
adaptateurs, et peut tre amliore par la construction de techniques daccessibilit ddies la tche.
Lditeur interactif dICON permet en effet au dveloppeur dapplications de rpondre efcacement
un grand nombre de situations en termes dentres, quelles soient enrichies ou appauvries. Une fois
construites, les congurations dentre sont hautement congurables, et peuvent tre personnalises
diffrents niveaux selon le degr dexpertise de lutilisateur.
Exploitation dICON et perspectives

La bote outils en entres ICON est distribue sur Internet et est actuellement employe dans
le cadre du projet GINA (Gomtrie Interactive et NAturelle). Elle a dabord t exprimente sur
une application de reconstruction interactive de scnes 3D partir de photographies, et est actuellement utilise dans le dveloppement dune application Post-WIMP de modlisation 3D exploitant
les techniques de dessin darchitectes. ICON a galement servi monter une exprimentation visant
comparer lutilisabilit de plusieurs techniques dinteraction. En outre, deux projets sont actuellement
en cours pour une intgration totale dICON avec des botes outils graphiques Post-WIMP.
Si ICON semble avoir aujourdhui atteint la maturit ncessaire pour pouvoir tre employ dans
des projets de dveloppement, notre travail demeure essentiellement exploratoire, et demande tre
afn, complt et gnralis. Une validation exhaustive de notre approche ncessiterait notamment
des tudes dutilisabilit portant sur lditeur interactif et la librairie de programmation ICON, la mise
en uvre dapplications plus nombreuses et plus complexes, et une formalisation de son modle ots
de donnes ractif. Notre approche ouvre par ailleurs de nombreuses perspectives damlioration et
dextension. Nous avons par exemple voqu des stratgies dintgration avec des approches complmentaires (formalismes orients-contrle, modles dinteraction communicationnels de haut niveau,
modles multicouches pour le feedback graphique), ainsi que des extensions possibles de notre modle visant notamment incorporer les caractristiques pragmatiques des dispositifs physiques mis en
vidence par Buxton.
Une perspective peut-tre lointaine mais des plus intressantes serait une gnralisation de notre
paradigme de connexion logicielle aux niveaux matriel et systme dexploitation, dans le but de
tendre vers une nouvelle gnration de plate-formes intgralement ouvertes en entre. Selon nous,
lavnement du standard USB a rendu ce type dvolution possible, notamment en fournissant un accs uni et de niveau bas un grand nombre de dispositifs dentre, et en autorisant les connexions et
191
les dconnexions chaud. Nos postes de travail devraient non seulement autoriser les connexions dynamiques de dispositifs physiques divers et varis, mais devraient galement permettre aux utilisateurs
de spcier leur emploi de faon simple et naturelle. Notre exprience avec ICON nous a convaincu
de la faisabilit dun tel systme, et nous avons dj voqu un certain nombre de caractristiques qui
nous semblaient pertinentes pour une version grand public et allge de notre congurateur, combinant dans des proportions raisonnables simplicit dutilisation et pouvoir dexpression.
192
Remerciements
Merci Jean-Daniel Fekete, pour ses qualits dencadrant, la fois scientiques et humaines, pour
la patience dont il a su faire preuve pendant ces nombreuses annes o jai souvent dout, et pour avoir
ni par me transmettre le virus de lIHM. Il sest beaucoup investi dans ces travaux, a t lorigine
de nombreuses ides, et ce sont vritablement les fruits dun travail commun qui sont prsents dans
ce mmoire. Je remercie aussi Grard Hgron, pour sa patience galement, et son soutien.
Merci Stphane Huot, pour mavoir continuellement stimul par son enthousiasme sans bornes
et sa passion du travail en quipe, ainsi quaux autres thsards de lquipe CMI : Frdric Jourdan,
Didier Boucard et Mohammad Ghoniem, avec lesquels je me suis senti trs proche. Nul doute que je
naurais pu venir bout de ma thse sans les encouragements et le soutien (et aussi la bonne humeur)
de Stphane, Frdric et des autres. Jai eu galement grand plaisir ctoyer les membres et exmembres du dpartement informatique de lEMN, je pense en particulier Geoffrey Subileau, Mathias
Braux, Mohammed Tounsi, Abdallah, Philippe, Narendra, Rmi, Christine, Cdric et Christian, sans
oublier Vanessa et les autres membres du CRITE. Merci aussi Pierre Cointe pour mavoir accord
sa conance et offert son appui lors dune priode difcile.
Merci ceux qui en montrant de lintrt pour mes travaux mont beaucoup encourag, cest-dire aux membres de mon jury de thse, Caroline Appert, et aux autres. Merci galement ceux de
mes nouveaux collgues Toulousains du LIIHS, du CENA, et dIntuilab, qui mont accompagn la
n de mon calvaire et mont aid lors de mes rptitions de soutenance.
Merci mes proches pour avoir longtemps support mon irritabilit lorsquil fallait aborder le
dlicat sujet de lavancement de ma thse : mes parents et mon frre Christian, ainsi que Pascal, Nadir
et Fatima, Paul et Lucie, Jrmy, Thomas, Stphane et Florence. Merci aussi au personnel du Groupe
Scolaire de la Maison dArrt avec qui jai eu plaisir travailler pendant la dure de mon service
national : Jean-Marc Allain et tous les instituteurs spcialiss, les emplois-jeunes, Raphal, ainsi que
les dtenus.
Merci tout particulirement Batrice, ainsi qu sa proche famille : Jean, Jeanine, Philippe,
Bernadette, Xavier, Thrse, Laurent et Anita.
193
REMERCIEMENTS
194
Annexe A
Structure dune conguration dentre

Sommaire
A.1 Vue densemble . . . . . . . . . . . . . . . . .
A.2 Les quatre briques de base et leurs attributs .
A.2.1 Dispositifs . . . . . . . . . . . . . . . .
A.2.2 Slots . . . . . . . . . . . . . . . . . . .
A.2.3 Connexions . . . . . . . . . . . . . . . .
A.2.4 Conguration dentre . . . . . . . . . .
A.3 Les connexions . . . . . . . . . . . . . . . . . .
A.3.1 Contraintes sur les connexions . . . . . .
A.3.2 Types et sous-typage . . . . . . . . . . .
A.3.3 Attributs de connexions drivs des slots
A.3.4 Attributs de slots drivs des connexions
A.3.5 Graphe de dpendances . . . . . . . . . .
A.4 Composition de dispositifs . . . . . . . . . . .
A.4.1 Slots externes . . . . . . . . . . . . . . .
A.4.2 Connexions externes . . . . . . . . . . .
A.4.3 Dispositifs composites . . . . . . . . . .
A.4.4 Composition et dcomposition . . . . . .
A.4.5 Slots i-connects . . . . . . . . . . . . .
195
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
196
197
197
199
200
200
201
201
201
202
203
204
204
204
206
206
207
209
ANNEXE A. STRUCTURE DUNE CONFIGURATION DENTRE

Notre but dans ces trois annexes nest pas dintroduire un nouveau formalisme data-ow, mais de
dcrire la structure et les mcanismes spciques aux congurations dentre de faon sufsamment
univoque pour quils puissent tre compris et implments dans un langage impratif. Cette structure
et ces mcanismes constituent le modle ICOM (Input Conguration Model). Dans la mesure du
possible, nous essaierons de dcrire ce modle indpendamment de toute implmentation : les choix
lis au style de programmation (hirarchie des classes par exemple) sont laisss libres. Par ailleurs,
nous emploierons le plus souvent des schmas graphiques gnriques pour dcrire les structures de
donnes, indpendamment du langage visuel dcrit dans le chapitre 3. Enn, dans certains passages
ncessitant des explications plus dtailles et chaque fois que le langage naturel se rvlera peu
adapt la description dun mcanisme, des notations mathmatiques simples seront employes.
Dans cette partie, nous introduisons les lments de base du modle ICOM, en dcrivant leur
structure et leurs relations. Cette partie concerne les aspects statiques des congurations dentre.
A.1 Vue densemble
F IG . A.1 Structure globale dune conguration dentre, avec les briques de bases et leurs relations.
La gure A.1 fournit une vue globale de lorganisation structurelle dune conguration dentre.
Chaque entit est dcrite par un ensemble dattributs typs, cest--dire une liste de noms ( gauche, en
gras) et de types ( droite). Les ches pleines dcrivent les relations dagrgation (X comporte un ou
plusieurs Y ) et les ches en pointills des relations de rfrence (X rfrence Y ). Les ches grises
traduisent des relations dagrgation uniquement employes pour la composition et seront abordes
plus tard.
La structure de base est la suivante : une conguration comporte un ensemble de dispositifs et
196
A.2. LES QUATRE BRIQUES DE BASE ET LEURS ATTRIBUTS

de connexions, ainsi que des dossiers de dispositifs-prototypes. Chaque dispositif comporte un ensemble de slots et de paramtres, et chaque connexion fait rfrence deux slots. Un dispositif de
type composite peut comporter une conguration dite lle, elle-mme pouvant comporter des slots
dits externes.
Dans la suite, nous dcrivons les attributs des entits lmentaires de notre modle dans lordre
de la gure, de gauche droite : le dispositif, les paramtres, le dossier de prototypes, le slot, la
connexion, et la conguration.
A.2 Les quatre briques de base et leurs attributs

A.2.1
Dispositifs
La structure dun dispositif est dnie par un ensemble dattributs et deux fonctions, qui sont
numrs dans le tableau A.2.1 puis dcrits par la suite.
Dispositif
nom
parent
slots
paramtres
configurationFille
prototype
composite
mutable
entresImplicites
sortiesImplicites
chane de caractres
Conguration
Slot [ ]
Paramtre [ ]
Conguration
vrai/faux
vrai/faux
vrai/faux
vrai/faux
vrai/faux
fonction
fonction
TAB . A.1 Structure dun dispositif. La colonne de gauche liste le nom des attributs, celle de droite
prcise leur type.
nom : Cet attribut contribue identier la fonction du dispositif, par exemple le type de traitement
de donnes quil effectue. Il peut galement reter le rle spcique du dispositif au sein de la
conguration.
parent : Une rfrence la conguration laquelle appartient le dispositif, ou ou null sil sagit
dun dispositif-prototype.
slots : Les slots dun dispositif lui permettent de communiquer avec les autres dispositifs lors de
la phase dexcution ( section A.2.2 page 199).
paramtres : Un dispositif possde un ensemble ventuellement vide de paramtres. Les valeurs
de ces paramtres dterminent certains aspects du comportement du dispositif pendant la phase
de construction et dexcution. Un dispositif ne peut pas comporter deux paramtres portant le
mme nom ( section A.2.1 page suivante).
configurationFille : La conguration-lle du dispositif, lorsquil sagit dun dispositif composite ; null sinon.
197

prototype : Spcie si le dispositif est un dispositif-prototype ( section A.2.1).
composite : Spcie si le dispositif est de type composite ( section A.4 page 204).
mutable : Un dispositif est dit mutable sil est susceptible de se spcialiser en fonction de la valeur
prise par certains de ses attributs ( annexe B).
entresImplicites : Indique si le dispositif reoit des informations de lenvironnement, cest-dire des donnes autres que celles en provenance de ses slots dentre) ( section C.5.1
page 232).
sortiesImplicites : Indique si le dispositif met des informations vers lenvironnement, cest-dire ailleurs que sur ses slots de sortie ( section C.5.1 page 232).
: est la fonction de mutation du dispositif, qui dtermine le comportement de celui-ci pendant la
phase de construction ( annexe B).
: est la fonction dexcution du dispositif, qui dtermine le comportement de celui-ci pendant la
phase dexcution ( annexe C).
Paramtres
La structure dun paramtre, dcrite dans le tableau A.2.1, est simplement celle dun attribut. Les
paramtres peuvent tre ainsi vus comme des attributs de dispositif supplmentaires.
Paramtre
nom
chane de caractres
type
(selon limplmentation)
valeur type
TAB . A.2 Structure dun paramtre.
Dossiers de prototypes
Un dispositif-prototype est en tous points semblable un dispositif, ceci prs quil ne fait pas
partie dune conguration, ne mute pas (il est obligatoirement dans un tat consistant ( section B.2.4
page 214)) et nest jamais excut. Uniquement destin tre dupliqu, celui-ci possde un tat statique qui dnit un paramtrage initial (valeur par dfaut des paramtres) et un comportement (fonctions de mutation et dexcution).
Les dispositifs-prototypes sont regroups dans un dossier de prototypes dont la structure est la
suivante :
Dossier
nom
prototypes
chane de caractres
Dispositif [ ]
TAB . A.3 Structure dun dossier de prototypes.
198
A.2. LES QUATRE BRIQUES DE BASE ET LEURS ATTRIBUTS
A.2.2
Slots
Un slot est un tat du dispositif qui est accessible aux autres dispositifs. Ces derniers ont la possibilit dcrire sur le slot sil sagit dun slot dentre, ou de lire sa valeur sil sagit dun slot de
sortie (gure 3.11 page 103). Ces changes se font par lintermdiaire des connexions ( section A.3
page 201).
Les attributs dun slot sont numrs dans le tableau ci-dessous, et dtaills par la suite.
Slot
nom
parent
sens
type
supertype
externe
dclencheur
t-mutable
s-mutable
absent
chane de caractres
Dispositif ou Conguration
entre/sortie
vrai/faux
vrai/faux
vrai/faux
vrai/faux
vrai/faux
TAB . A.4 Structure dun slot.

nom : Cet attribut identie le slot au sein du dispositif. Le nom de chaque slot dentre dun dispositif est unique, de mme pour ses slots de sortie. Les noms comportant des points .
dnissent des slots structurs (structure cependant non explicite dans ICOM).
parent : Une rfrence au dispositif ou la conguration laquelle appartient le slot, selon quil
sagisse dun slot de dispositif ou dun slot externe.
sens : Cet attribut vaut entre ou sortie, selon quil sagisse dun slot dentre ou dun slot
de sortie. Ce critre restreint lensemble des connexions possibles entre slots ( section A.3
page 201).
type : Le type dun slot dcrit le type de donnes qui y transitera lors de la phase dexcution. Dans
la phase de construction, celui-ci dtermine simplement la compatibilit des connexions (
section A.3.2 page 201).
supertype : Le supertype dun slot dcrit lensemble des types que peut possder un slot t-mutable.
( annexe B)
externe : Un slot externe est un slot isol nappartenant aucun dispositif. Il sert communiquer
avec la conguration parente dans les dispositifs composites. Un slot non externe est galement
appel slot de dispositif. ( section A.4.1 page 204)
dclencheur : Un slot est dit dclencheur sil est susceptible de provoquer une mutation de son
dispositif parent. Cet attribut vaut faux pour les slots absents. ( annexe B)
t-mutable : Un slot est dit t-mutable sil est susceptible de changer de type. ( annexe B)
s-mutable : Un slot est dit s-mutable sil est susceptible dtre ajout ou supprim du dispositif.
Un slot ne peut pas tre simultanment s-mutable et t-mutable. En outre, un slot dclencheur ne
peut pas tre s-mutable. ( annexe B)
absent : Spcie si le slot est un slot absent ou un slot prsent. Les slots prsents sont crs par le
dispositif, et les slots absents sont crs par les mcanismes de mutation. ( annexe B)
199
A.2.3
Connexions
Une connexion est une relation liant deux slots, indiquant que ces deux slots partageront la mme
valeur lors de la phase dexcution. La structure dune connexion est dcrite dans le tableau A.2.3.
Connexion
parent Conguration
sortie Slot
entre Slot
TAB . A.5 Structure dune connexion.

parent : Une rfrence la conguration parente de la connexion.
sortie : Une rfrence un slot de sortie appartenant parent ou lun de ses dispositifs-ls.
entre : Une rfrence un slot dentre appartenant parent ou lun de ses dispositifs-ls.
Les connexions sont orientes de la sortie vers lentre, et seront parfois notes s e, s tant le
slot de sortie et e le slot dentre.
A.2.4
Conguration dentre
Une conguration dentre est principalement constitue dun ensemble de dispositifs et de connexions.
Elle peut ventuellement tre encapsule dans un dispositif composite, auquel cas elle possde un dispositif parent. La structure dune conguration dentre est dcrite ci-dessous :
Conguration
nom
parent
bibliothque
dispositifs
connexions
slotsExternes
chane de caractres
Dispositif
Dossier [ ]
Dispositif [ ]
Connexion [ ]
Slot [ ]
TAB . A.6 Structure dune conguration dentre.

nom : Ce nom contribue identier la fonction et le rle de la conguration dentre.
parent : Une rfrence au dispositif parent de la conguration, lorsque celle-ci est encapsule dans
un dispositif composite, null sinon.
bibliothque : La bibliothque de dispositifs de la conguration, compose dun ensemble de
dossiers de prototypes.
dispositifs : Lensemble des dispositifs de la conguration dentre.
connexions : Lensemble des connexions qui relient les dispositifs entre eux. Les connexions seront abordes en dtail dans la section suivante.
slotsExternes : Une conguration peut comporter des slots isols dits externes, qui lui permettent
de communiquer avec lextrieur. Ces objets sont dcrits dans la section A.4 page 204.
200
A.3. LES CONNEXIONS
A.3 Les connexions

A.3.1
Contraintes sur les connexions
Tout ensemble de connexions doit obir aux trois contraintes suivantes :

Couplage : Une connexion appartenant une conguration C peut relier soit :
1. Un slot de sortie appartenant un dispositif de C un slot dentre appartenant un
dispositif de C ;
2. Un slot de sortie appartenant un dispositif de C un slot dentre externe appartenant
C;
3. Un slot de sortie externe appartenant C un slot dentre appartenant un dispositif de
C;
En rsum, une connexion doit relier deux slots de sens opposs et tre oriente du slot de sortie
vers le slot dentre, et ne peut relier deux slots externes.
Unicit en entre : Il existe au plus une connexion comportant un lment entre donn. Ceci implique notamment que les connexions multiples sur un slot dentre sont interdits, ainsi que les
connexions redondantes.
Acyclisme : Un ensemble de connexions ne doit pas gnrer de dpendances cycliques : pour toute
conguration C, le graphe de dpendances ( section A.3.5 page 204) de la dcomposition
totale ( section A.4 page 204) de C doit tre acyclique.
A.3.2
Types et sous-typage
Hormis les contraintes numrs prcdemment, toute connexion est autorise indpendamment
des types des slots. Cependant, notre modle de connexion est typ et diffrencie les connexions
compatibles des connexions incompatibles.
any
double
boolean
string
object
int
null
F IG . A.2 Exemple de graphe de types pour les slots.
La gure A.2 reprsente le graphe de types que nous utilisons dans notre implmentation en Java,
avec les relations de sous-typage. Les diffrents types de slots sont les int (nombres entiers), boolean
(boolens), double (nombres ottants), string (chanes de caractres), et object (objets). cela
sajoutent les types spciaux any (qui reprsente tous les types possibles) et null (qui ne reprsente
201

aucun type). Ce graphe, comportant notamment le type object, est adapt un langage objets tel
que Java.
Notre modle ne ncessite pas la dnition explicite dun graphe de types. Au lieu de cela, il
suppose quil existe un graphe de types avec son sommet le type any, et sa base le type null, et
dnit sur ce graphe les relations et oprations suivantes :
Nous dirons que ts est un sous-type de t (relation note ts t) ssi ts est successeur inclusif de
t dans le graphe, cest--dire ssi ts = t ou ts est successeur direct ou indirect de t. De mme, nous
nommerons union de plusieurs types leur premier prdcesseur inclusif commun dans le graphe, et
intersection de plusieurs types leur premier successeur inclusif commun dans ce mme graphe. Les
oprations dunion et dintersection seront respectivement notes (t1 , . . . ,tn ) et (t1 , . . . ,tn ).
A.3.3
Attributs de connexions drivs des slots
Nous nommons attribut driv un attribut dun objet dont la valeur est fonction de celle des autres
attributs de cet objet ou de ses objets accessibles (objets-ls ou objets rfrencs). Ils seront prcds
dun triangle . Ces attributs napportent pas dinformation supplmentaire mais peuvent nanmoins
servir introduire des dnitions utiles. Nous verrons galement que lorsque la valeur de certains
attributs est xe dans un objet, dautres attributs initialement libres peuvent devenir des attributs
drivs.
Les connexions comportent des caractristiques de compatibilit, ainsi que dautres attributs drivs dont les valeurs sont fonction de leurs slots dentre et de sortie. Nous dcrivons ces attributs,
rsums dans le tableau A.3.3, en introduisant de nouveaux termes ainsi que leurs dnitions.
Connexion
externe
compatibilit
compatibilitStatique
vrai/faux
compatible/incompatible
compatible/incompatible/mutable
TAB . A.7 Attributs drivs dans une connexion

externe : Une connexion externe est une connexion reliant un slot de dispositif (slot pour lequel
externe=faux) un slot externe (slot pour lequel externe=vrai). Une connexion non externe,
ou connexion de dispositifs est une connexion reliant deux slots de dispositifs. Une connexion
ne peut relier deux slots externes.
compatibilit : Une connexion est dite compatible ssi le type de son slot de sortie est un sous-
type de celui de son slot dentre. Dans le cas contraire, elle est incompatible.
compatibilitStatique : Une connexion est dite statiquement compatible ssi le supertype de
son slot de sortie est un sous-type de celui de son slot dentre, et que son slot dentre est
ni s-mutable ni t-mutable. Une connexion est dite statiquement incompatible ssi le supertype
de son slot de sortie nest pas un sous-type de celui de son slot dentre, et que son slot de
sortie est ni s-mutable ni t-mutable. Dans tous les autres cas, la connexion est dite mutable. Une
connexion mutable est soit compatible soit incompatible, mais sa compatibilit peut changer
suite une mutation ( annexe B). linverse, une connexion statiquement compatible est
toujours compatible, et une connexion statiquement incompatible est toujours incompatible.
202
A.3. LES CONNEXIONS

La compatibilit de types nentre pas en ligne de compte dans les contraintes de connexion vues
prcdemment car, comme nous le verrons dans lannexe B, une connexion compatible peut trs bien
devenir incompatible au cours de ldition et vice-versa. La compatibilit statique dcrit cependant
les volutions possibles de cette compatibilit, et il est tout fait possible (bien que nous ne le faisions
pas) de refuser les connexions statiquement incompatibles.
A.3.4
Attributs de slots drivs des connexions
De mme que les slots induisent un certain nombre de proprits sur les connexions, certaines
proprits caractrisent les slots en fonction des connexions existantes. Nous dcrirons ces attributs
drivs tout en introduisant de nouveaux termes qui nous seront utiles dans les deux prochaines annexes. Ces attributs sont rsumes dans le tableau A.3.4.
Slot
connexions
slotsConnects
connect
typeConnect
Connexion [ ]
Slot [ ]
vrai/faux
TAB . A.8 Attributs drivs dans un slot

connexions : Les connexions dun slot S sont les connexions comportant S en entre ou en sortie.
Pour un slot dentre, cet attribut comporte au plus un lment.

slotsConnects : Les slots connects S sont les slots relis S par des connexions. Pour un slot
dentre, cet attribut comporte au plus un lment.

connect : Un slot est dit connect ssi il comporte au moins une connexion.
typeConnect : Le type connect dun slot de sortie est lintersection des types de ses slots connec-
ts, ou any sil nest pas connect. Le type connect dun slot dentre est le type de son slot
connect, ou null sil nest pas connect.
Slots connects s
Connexions de s
Slot connect e
Connexion de e
c1
e1
c2
e2
c3
s1
c'1
s2
c'2
e3
F IG . A.3 Exemples de connexions : le slot de sortie s comporte trois connexions c1, c2 et c3 qui le relient
aux slots dentre e1, e2 et e3. Le slot dentre e comporte une connexion c1 qui le relie au slot de sortie s1. e
ne peut comporter dautre connexion.
203
A.3.5
Graphe de dpendances
F IG . A.4 Graphe de dpendances dun ensemble de connexions.
Les connexions de dispositifs sont des arcs orients reliant deux slots qui ont chacun un dispositif
pour parent. Il est donc possible, partir dun ensemble de connexions de dispositifs, de construire un
graphe orient exprimant des dpendances entre les dispositifs (gure A.4). Ce graphe nous permet
dintroduire les deux relations suivantes sur les dispositifs :
Un dispositif D1 est successeur direct dun dispositif D0 ssi il existe un arc D0 D1 dans le
graphe de dpendances.
Un dispositif D1 est successeur indirect dun dispositif D0 ssi il existe un chemin qui va de D0
D1 dans le graphe de dpendances. Cette relation est note D0 D1 .
Dans les congurations ne comportant pas de dispositif composite, en particulier dans les congurations rsultant dune dcomposition totale ( section A.4), le graphe de dpendances est toujours
un graphe orient acyclique, ou DAG.
A.4 Composition de dispositifs

Les dispositifs sont composables : un ensemble de dispositifs interconnects peut tre dcrit de
faon quivalente par un dispositif unique appel dispositif composite.
Un dispositif composite est essentiellement dcrit par une conguration dentre, sa conguration
lle. De faon gnrale, toute conguration dentre peut tre encapsule dans un dispositif composite, appel dispositif parent. Ces deux relations de composition induisent galement des relations
hirarchiques entre congurations et dispositifs : une conguration peut tre lle ou parente dune
autre conguration du point de vue de la composition, de mme que les dispositifs (gure A.5 page
ci-contre). La communication dun niveau lautre se fait par lintermdiaire des slots externes.
A.4.1
Slots externes
Un slot externe est un type particulier de slot qui nappartient pas un dispositif mais une
conguration. Du point de vue de cette conguration, ce sont des points dentre et de sortie lui
permettant dchanger de linformation avec lextrieur. Au niveau de la conguration parente, ils
reprsentent les slots dun dispositif composite : chaque slot externe est associ un slot de sens
oppos sur le dispositif composite (voir gure A.6 page suivante).
Un slot externe est uniquement dni par un sens, un nom et un index. Ses autres attributs sont
204
A.4. COMPOSITION DE DISPOSITIFS
C
configuration parente
configurations filles
d1
d2
C1
C2
dispositif parent
configuration fille
d11
d12
d21
dispositif parent
dispositifs fils
d22
F IG . A.5 Exemple de hirarchies compositionnelles entre congurations et dispositifs : une conguration

C comprend deux dispositifs composites d1 et d2 respectivement dcrits par les congurations C1 et C2. Ces
dernires comprennent chacun deux dispositifs.
d*
e*
s1*
s2*
dispositif parent
C*
d1
sx
d2
e1x
e2x
slots externes
F IG . A.6 La conguration C comprend trois slots externes sx , e1x et e2x qui dcrivent les slots de son
dispositif parent d. chaque slot dentre (resp. de sortie) externe est associ un slot de sortie (resp. dentre)
sur le dispositif composite.
205

directement fonction des attributs de ses slots connects (voir section suivante sur les connexions
externes). Dans la liste qui suit, ces attributs drivs sont prcds dune che :
nom : Cet attribut spcie le nom du slot externe au sein de la conguration, ainsi que le nom du slot
correspondant sur le dispositif composite. Dans une conguration dentre, les slots externes
dentre ont des noms distincts, de mme que les slots externes de sortie.
parent : La conguration parente du slot composite.
sens : Cet attribut vaut entre ou sortie. Il spcie si le slot externe est un slot externe dentre
ou de sortie.
type : Cet attribut a pour valeur le type connect du slot externe (voir section suivante).
supertype : Cet attribut a pour valeur any.
externe : Cet attribut vaut vrai.
dclencheur : Vaut vrai ssi il existe un slot connect au slot externe pour lequel declencheur=vrai.
s-mutable : Vaut vrai ssi il existe un slot connect au slot externe pour lequel s-mutable=vrai.
t-mutable : Vaut vrai ssi s-mutable=faux et il existe un slot connect au slot externe pour
lequel t-mutable=vrai..
A.4.2
Connexions externes
Comme nous lavons vu prcdemment, les connexions comportant un slot externe sont nommes
connexions externes. Il existe deux types de connexions externes : les connexions externes dentre
qui relient un slot dentre de dispositif un slot externe de sortie, et les connexions externes de sortie
qui relient un slot de sortie de dispositif un slot externe dentre.
Les rgles de connexion ainsi que les attributs et les relations dnies dans la section A.3 page 201
sont les mmes pour les connexions externes. Les contraintes dunicit relatives aux connexions sur
les slots dentre (section A.3 page 201) sappliquent aux slots externes de sortie. Notons quune
connexion externe est toujours compatible, car elle relie deux slots de mme type.
A.4.3
Dispositifs composites
Un dispositif composite est entirement dni par sa conguration lle. Hormis lattribut parent,
lensemble de ses attributs (prcds dune che dans la liste ci-dessous) est fonction des attributs de
cette conguration lle :
parent : La conguration laquelle appartient le dispositif, ou null.
configurationFille : La conguration dentre qui dcrit le dispositif composite.
nom : Le nom dun dispositif composite est le nom de sa conguration lle.
slots : Les slots dun dispositif composite correspondent aux slots externes utiliss dans la con-
guration lle, dans lordre indiqu par leur attribut index. Chaque slot du dispositif composite
hrite des attributs du slot externe qui lui est associ.
paramtres : Un dispositif composite ne comporte pas de paramtre.
composite : Cet attribut vaut vrai.
206

prototype : Cet attribut vaut faux.
mutable, entresImplicites, sortiesImplicites : Chacun de ces attributs vaut vrai ssi il
est vrai pour au moins un dispositif dans la conguration lle.
A.4.4
Composition et dcomposition
e*
Slot de dispositif composite
s*
sx
Slot externe
ex
F IG . A.7 Deux types de connexions inter-niveaux quivalentes la connexion s e. gauche, la connexion

inter-niveaux descendante (s e , sx e). droite, la connexion inter-niveaux ascendante (s ex , s e).
Les slots intermdiaires permettent la connexion s e de remonter ou de redescendre dun niveau dans larbre
des congurations.
Nous appellerons connexion inter-niveaux toute paire de connexions reliant deux slots par lintermdiaire dun slot externe et de son slot de dispositif composite associ. Si cette connexion passe
par le slot du dispositif composite puis par le slot externe, nous sommes dans le cas dune connexion
inter-niveaux descendante ; dans le cas contraire, il sagit dune connexion inter-niveaux ascendante
(gure A.7). Dans les deux cas, la connexion inter-niveaux est quivalente du point de vue de lexcution une connexion directe entre le deux slots.
Des oprations de composition et de dcomposition permettent de construire des structurations
alternatives de larbre des congurations. La gure A.8 page suivante montre un exemple de composition ajoutant un niveau de conguration. Les dispositifs d2, d3 et d4 sont regroups au sein dun
dispositif composite, qui peut ensuite tre aplati pour redonner la conguration initiale.
La composition dun ensemble de dispositifs dans une conguration C sobtient par lalgorithme A.1 page 209. Lopration inverse, consistant dcomposer un dispositif composite d dans C
sobtient par lalgorithme A.1 page 209. Ces algorithmes emploient la factorisation des connexions
multiples sur un slot de sortie (gure A.9 page suivante).
Enn, la dcomposition totale dune conguration C, utilise pour le calcul des dpendances cycliques, sobtient en appliquant rcursivement lalgorithme A.1 page 209 sur lensemble des dispositifs de la conguration C.
207
d1
d2
s11 s12 e2
d3
s2
e3
d4
d5
s3 e41 e42 s4
Composition
s5
Dcomposition
d1
d*
s11 s12
d5
e1* e2*
s*
s5
C*
sx1
sx2
d2
e2
s2
d3
e3
ex
d4
s3 e41 e42 s4
F IG . A.8 Exemple de composition et de dcomposition dune conguration dentre. Les dispositifs d1, d2
et d3 sont dplacs dans la conguration-lle C et remplacs par le dispositif composite d . Les connexions
scindes telles que s11 e3 sont remplaces par des connexions inter-niveaux, tandis que les connexions
internes telles que (s2 e41) sont prserves (voir lalgorithme A.1). Lopration de dcomposition supprime
le dispositif composite et la conguration-lle, aprs avoir replac les dispositifs-ls dans la conguration
initiale et remplac les connexions inter-niveaux par des connexions simples (voir lalgorithme A.2).
e1 e2
e1
e*
Slot de dispositif composite
s*
sx
Slot externe
e2
e1 e2
ex
s
e1 e2
F IG . A.9 Formes factorises de connexions inter-niveaux multiples sur un slot de sortie.
208

1. Crer une conguration vide C contenant la mme bibliothque que C.
2. Crer un dispositif composite d de conguration-lle C et lajouter C ;
3. Dplacer les dispositifs vers C ;
4. Soit lensemble des slots appartenant aux dispositifs . Dplacer de C vers C toutes les connexions
s e de C vriant s et e ;
5. Pour toute connexion s e de C vriant s et e :
/
(a) sil nexiste pas dans C de connexion s e avec e appartenant d :
ajouter un slot externe de sortie sx dans C , qui sera associ un nouveau slot dentre e dans
d ;
ajouter la connexion s e dans C ;
ajouter la connexion sx e dans C .
(b) sil existe dans C une connexion s e avec e appartenant d :
ajouter la connexion sx e dans C , sx tant le slot externe associ e .
6. Pour toute connexion s e de C vriant s et e :
/
(a) sil nexiste pas dans C de connexion s ex avec ex slot externe :
ajouter un slot externe dentre ex dans C , qui sera associ un nouveau slot de sortie s dans
D ;
ajouter la connexion s e dans C ;
ajouter la connexion s ex dans C .
(b) sil existe dans C une connexion s ex avec ex slot externe :
ajouter la connexion s e dans C, s tant le slot de d associ ex .
Algorithme A.1: Composition des dispositifs dans C.
A.4.5
Slots i-connects
Il est utile dintroduire une dnition alternative de la connexion, la i-connexion, qui ne prend en
compte que les connexions effectives (ventuellement inter-niveaux) entre slots de dispositifs. Nous
dirons ainsi quun slot de dispositif S est i-connect un slot de dispositif S si S est reli S soit par
une connexion, soit par une ou plusieurs connexions inter-niveaux successives.
Soit un slot S appartenant un dispositif dans une conguration C. Soit C0 la racine de larbre de
congurations dont fait partie C.
Le slot S est i-connect S ssi S est connect S dans la dcomposition totale de C0 .
Lensemble des slots i-connects S est lensemble des slots connects S dans la dcomposition
totale de C0 .
209
1. Dplacer les dispositifs de C vers C ;

2. Dplacer toutes les connexions de dispositifs s e de C vers C ;
3. Pour tout slot externe de sortie sx de C et e son slot associ sur d :
(a) sil nexiste pas de connexion s e dans C :
supprimer toutes les connexions sx e de C .
supprimer sx dans C .
(b) sil existe une connexion s e dans C :
supprimer s e dans C ;
pour toute connexion sx e de C :
supprimer sx e dans C ;
ajouter la connexion s e C ;
supprimer sx dans C .
4. Pour tout slot externe dentre ex de C et s son slot associ sur d :
(a) sil nexiste pas de connexion s ex dans C :
supprimer toutes les connexions s e de C.
supprimer ex dans C .
(b) sil existe une connexion s ex dans C :
supprimer s ex dans C ;
pour toute connexion s e de C :
supprimer s e de C ;
ajouter la connexion s e C.
supprimer ex dans C .
5. Supprimer le dispositif composite d et sa conguration-lle C .
Algorithme A.2: Dcomposition du dispositif d dans C.
210
Annexe B
Aspects dynamiques dune conguration

dentre
Sommaire
B.1 Vue densemble . . . . . . . . . . . . . . . . . . . .
B.2 Dnitions prliminaires . . . . . . . . . . . . . . .
B.2.1 Types de slots . . . . . . . . . . . . . . . . . .
B.2.2 Identiants et valuations . . . . . . . . . . . .
B.2.3 Paramtrages et m-paramtrages de dispositifs
B.2.4 Fonction de mutation et consistance . . . . . .
B.3 Algorithmes . . . . . . . . . . . . . . . . . . . . . .
B.3.1 Mutation dun dispositif . . . . . . . . . . . .
B.3.2 Propagation des mutations . . . . . . . . . . .
B.3.3 Propagation borne . . . . . . . . . . . . . . .
B.3.4 Exemples de fonctions de mutation . . . . . .
B.4 Oprations sur les congurations . . . . . . . . . . .
B.4.1 Oprations lmentaires . . . . . . . . . . . .
B.4.2 Oprations consistantes . . . . . . . . . . . . .
211
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
212
213
213
213
213
214
215
215
216
218
218
220
220
222
ANNEXE B. ASPECTS DYNAMIQUES DUNE CONFIGURATION DENTRE

Dans cette partie, nous dcrivons les principaux aspects dynamiques du modle ICOM, qui traduisent le comportement dune conguration dentre durant la phase de construction et ddition. La
plupart des notions abordes ici sappuient sur les structures dcrites dans lannexe A.
B.1 Vue densemble

Lessentiel du comportement en dition dune conguration dentre repose sur les mcanismes
de mutation. Les dispositifs mutables sont des dispositifs capables de se spcialiser ou se restructurer
en modiant la valeur de certains de leurs attributs en fonction de la valeur dautres attributs, selon
un mcanisme appel mutation. Lors dune mutation, le type de certains slots peut changer : ces
slots sont nomms t-mutables. Une mutation peut galement restructurer un dispositif en crant ou en
supprimant des slots dynamiques, nomms s-mutables.
Lensemble des attributs qui provoquent ces spcialisations et lensemble des attributs spcialisables constituent respectivement le paramtrage et le m-paramtrage du dispositif (gure B.1) :
d
slots
paramtres
p1
p2
dclencheur
dclencheur
S1
S2
S3
S4
dclencheur
t-mutable
dclencheur
t-mutable
s-mutable
type
valeur
valeur
connect
type
connect
type
connect
type
connect
F IG . B.1 Fonction de mutation dun dispositif d comportant les paramtres p1, p2 et les slots S1, S2, S3
et S4. , la source de , est compos des valeurs prises par ses paramtres et des attributs de connexion de ses
slots dclencheurs. m , la cible de , dcrit les types des slots t-mutables de d, ainsi que de lensemble des slots
s-mutables que possde le dispositif aprs mutation.
1. Le paramtrage dun dispositif dcrit les valeurs prises par ses paramtres, et spcie si ses
slots dclencheurs sont connects, ainsi que leurs types connects.
2. Le m-paramtrage m dun dispositif dcrit lensemble de ses slots s-mutables, ainsi que lensemble des types pris par ses slots t-mutables.
3. Chaque dispositif comporte une fonction de mutation : m qui un paramtrage associe
un m-paramtrage.
Aprs une introduction prliminaire sur les notions de signature et de valuation, nous dnirons
plus prcisment , m et la fonction , puis nous dcrirons les mcanismes de base qui permettent
dappliquer et de propager les fonctions de mutation.
212
B.2. DFINITIONS PRLIMINAIRES
B.2 Dnitions prliminaires

B.2.1
Types de slots
Un slot structurellement mutable ou s-mutable est un slot pour lequel lattribut s-mutable =
vrai. Un slot t-mutable est un slot pour lequel t-mutable = vrai, et un slot absent est un slot pour
lequel absent = vrai.
Les slots s-mutables sont uniquement dnis par leur parent, leur nom, leur sens et leur type.
Les slots absents sont uniquement dnis par leur parent, leur nom, et leur sens.
Un slot ne peut pas tre simultanment s-mutable et t-mutable. En outre, un slot dclencheur ne
peut pas tre s-mutable.
B.2.2
Identiants et valuations
Les dnitions qui suivent sappliquent tout dispositif, quil soit mutable ou non.
Lidentiant V (S) dun slot S de dispositif est un couple form de la valeur de ses attributs nom
et sens, permettant de caractriser de faon unique ce slot sur son dispositif parent :
V (S) = S.nom, S.sens
Tout couple de la forme nom, sens dont les lments constitutifs ont pour types respectifs ceux
des attributs de slots nom et sens est un identiant de slot. Un identiant de slot nom, sens dsigne
le slot S ssi V (S) = nom, sens .
Soient a1, . . . , an des attributs de slots distincts, et diffrents des attributs nom et sens.
La valuation Va1 ,...,an (S) dun slot de dispositif S est un n-uplet comportant lidentiant de S et
les valeurs de ses attributs a1 , . . . , an :
Va1 ,...,an (S) = S.nom, S.sens, S.a1 , . . . , S.an
Tout n-uplet de la forme nom, sens, a1 , . . . , an , dont les lments constitutifs ont pour types respectifs ceux des attributs de slots nom, sens, a1 , . . ., an , est une valuation de slot, note Va1 ,...,an . Le
couple nom, sens en constitue lidentiant. Nous dirons quune valuation de slot dsigne le slot S ssi
son identiant dsigne le slot S.
De faon analogue, pour les paramtres :
Lidentiant V (P) dun paramtre P est la valeur de son attribut nom, et la valuation Vvaleur (P)
de ce paramtre est le couple form par la valeur de ses attributs nom et valeur.
B.2.3
Paramtrages et m-paramtrages de dispositifs
Le paramtrage dun dispositif d est le couple :
(d) = VPd ,VSd
213

o VPd est lensemble des valuations Vvaleur des paramtres de d :
VPd = { P1 .nom, P1 .valeur , . . . , Pn .nom, Pn .valeur }Pi d.parametres
et VSd est lensemble des valuations Vconnecte,typeConnecte des slots dclencheurs de d :
VSd = { S1 .nom, S1 .sens, S1 .connecte, S1 .typeConnecte , . . . ,
Sn .nom, Sn .sens, Sn .connecte, Sn .typeConnecte }Si d.slots et Si .declencheur=vrai
Le m-paramtrage dun dispositif d est le couple :
m (d) = VSs ,VSt
o VSs est lensemble de valuations Vtype des slots s-mutables de d :
VSs = { S1 .nom, S1 .sens, S1 .type , . . . ,
Sn .nom, Sn .sens, Sn .type }Si d.slots et Si .smutable=vrai
et VSt est lensemble de valuations Vtype des slots t-mutables de d :
VSs = { S1 .nom, S1 .sens, S1 .type , . . . ,
Sn .nom, Sn .sens, Sn .type }Si d.slots et Si .tmutable=vrai
Un m-paramtrage valide pour un dispositif d est un couple de la forme :
m = VSs ,VSt
o VSs est un ensemble de valuations Vtype :
VSs = { nom1 , sens1 ,type1 , . . . , nomn , sensn ,typenn }
dont les identiants sont distincts et ne dsignent pas de slot prsent non s-mutable de d (slots
pour lesquels absent = f aux et s-mutable= f aux).
et VSt est un ensemble de valuations Vtype :
VSt = { nom1 , sens1 ,type1 , . . . , nomn , sensn ,typenn }
dont les identiants sont distincts et dsignent tous des slots t-mutables de d. En outre, chaque
lment nom, sens,type de VSt identiant S vrie type S.supertype.
Notons quun slot s-mutable tant entirement dni par ses attributs parent, nom, sens et type,
un ensemble de valuations Vtype suft bien dcrire lensemble des slots s-mutables dun dispositif.
B.2.4
Fonction de mutation et consistance
Soit d un dispositif, P lensemble de ses paramtrages possibles, et P m lensemble de ses mparamtrages valides.
Le dispositif d comporte une fonction de mutation , qui chaque paramtrage de P associe
un m-paramtrage m de P m :
214
B.3. ALGORITHMES
P Pm
Un dispositif est dans un tat consistant ssi il est non mutable, ou sil satisfait sa fonction de
mutation :
m (d) = ((d))
B.3 Algorithmes
B.3.1
Mutation dun dispositif
La mutation dun dispositif consiste en la rvaluation des valeurs de ses attributs la suite dune
modication de son paramtrage, dans le but dassurer sa consistance. Cette rvaluation nest ncessaire que dans la mesure o ce dispositif est mutable. Le mcanisme de mutation dun dispositif est
dcrit par lalgorithme B.1.
Soit m = VSs ,VSt limage de (d) par .

Soit = lensemble des slots s-mutables de d dsigns par une des valuations de VSs .
Soit lensemble des slots s-mutables non connects de d, non dsigns dans VSs .
Soit + lensemble des slots s-mutables connects de d, non dsigns dans VSs .
a
Soit lensemble des slots absents de d, dsigns dans VSs .
a
Soit V + lensemble des valuations de VSs ne dsignant aucun slot de d.
Soit t lensemble des slots t-mutables de d dsigns dans VSt .
Soit un ensemble de slots initialement vide.
1. Pour chaque slot S de = :
mettre jour lattribut type de S avec la valeur x de la valuation S.nom, S.sens, x de VSs ;
si la nouvelle valeur de S.type est diffrente de lancienne, ajouter S .
2. Pour chaque slot S de :
supprimer le slot S du dispositif d.
3. Pour chaque slot S de + :
a
mettre jour les attributs de S :
S.s mutable = f aux, S.absent = vrai, S.type = null si S.sens = entre et S.type = any si sens =
sortie ;
4. Pour chaque slot S de :
a
mettre jour les attributs de S :
S.s mutable = vrai, S.absent = f aux, S.type = x avec S.nom, S.sens, x valuation de VSs ;
5. Pour chaque valuation x, y, z de V + :
crer un nouveau slot s-mutable S[parent=d,nom=x,sens=y,type=z] et lajouter d.
6. Pour chaque slot S de t :
mettre jour lattribut type de S avec la valeur x de la valuation S.nom, S.sens, x de VSt ;
Algorithme B.1: Mutation dun dispositif d de fonction de mutation , et construction de lensemble des
slots qui ont chang de type.
215

Lalgorithme de mutation met jour les slots du dispositif en fonction du m-paramtrage, en
supprimant, en ajoutant, ou en mettant jour le type des slots. Lemploi de slots absents vite la
suppression de connexions la suite dune mutation. En particulier, un slot supprim puis cr
nouveau conservera ses connexions.
Lalgorithme distingue six cas possibles pour chaque slot : Les slots s-mutables de d qui sont
absents du m-paramtrage sont supprims sils ne sont pas connects (slots ) et transforms en slots
absents sils sont connects (slots + ). Les nouveaux slots s-mutables dcrits par le m-paramtrage
a
sont ajouts sils nexistent pas en tant que slots absents (valuations V + ), et drivs des slots absents
dans le cas contraire (slots ). Enn, lalgorithme met jour les types des slots t-mutables (slots
a
t ) et des slots s-mutables qui sont prsents la fois sur le dispositif et dans le m-paramtrage (slots
= ). la n de lalgorithme, comprend lensemble des slots ayant chang de type, qui servira la
propagation des mutations.
B.3.2
Propagation des mutations
La mutation dun dispositif d est provoque par une ou plusieurs des causes lmentaires suivantes :
1. la modication du type connect dun des slots dclencheurs de d ;
2. une connexion ou une dconnexion sur lun des slots dclencheurs de d ;
3. la modication de la valeur dun des paramtres de d.
En outre, la mutation de d a pour rsultat une ou plusieurs consquences lmentaires qui peuvent
tre classes en quatre catgories :
1. la modication du type dun slot t-mutable ou s-mutable de d ;
2. la suppression dun slot s-mutable connect de d ;
3. la suppression dun slot s-mutable non connect de d ;
4. lajout dun slot s-mutable d.
d'
S
t-mutable
S'
dclencheur
type
type
connect
F IG . B.2 Propagation dune mutation : Le slot S, t-mutable, et le slot S , dclencheur, sont relis par une
connexion c de sens quelconque. la suite dune mutation du dispositif d, le type de S est modi, ce qui a
pour effet de modier galement le type connect du slot S et provoquer une mutation de d .
216
B.3. ALGORITHMES
Par lintermdiaire des connexions, les consquences de type 1 et 2 peuvent provoquer sur dautres
dispositifs des causes de type 1 et y dclencher des mutations : la mutation est alors propage (gure B.2 page ci-contre). La mutation dun dispositif est susceptible dtre propage tous les dispositifs directement connects, indpendamment du sens des connexions. Ce mcanisme de propagation
est dcrit par lalgorithme B.2.
Rpter les tapes suivantes jusqu ce que soit vide :

1. Copier dans et effacer le contenu de .
2. Pour tout dispositif d de :
(a) Appliquer lalgorithme B.1 page 215 d.
Soit lensemble des slots de d ayant chang de type.
(b) Si d , retirer d de .
(c) Pour tout slot s appartenant , pour tout slot s i-connect s :
Soit d le dispositif parent de s . Si s est un slot dclencheur et si d , ajouter d .
/
Algorithme B.2: Mutation avec propagation des dispositifs dans une conguration C.
Lalgorithme B.2 consiste appliquer lalgorithme de mutation sur un ensemble de dispositifs,

en se servant de la valeur de retour pour dterminer lensemble des dispositifs vers lesquels les
mutations doivent tre propages. Lalgorithme est nouveau appliqu sur ce dernier ensemble, et
ainsi de suite jusqu ce quil ny ait plus de dispositifs candidats. Notons que la propagation des
mutations peut monter ou descendre dans larbre des congurations, travers les slots i-connects
(voir section A.4.5 page 209).
Il est galement important de noter que cet algorithme rcursif opre en largeur dabord plutt
quen profondeur dabord : les dispositifs cibles de la propagation sont stocks au lieu dtre muts
immdiatement. Au niveau du slot, cest lalgorithme de mutation (algorithme B.1 page 215) qui se
charge du stockage des propagations. La propagation en largeur dabord a pour avantage dviter des
dclenchements inutiles de mutations (gure B.3).
d
S2
d'
S1
d1
S'1 S'2
d2
d3
d4
1
2
F IG . B.3 Exemples de mutations inutiles. gauche, une propagation en profondeur dabord au niveau du
slot : le dispositif d modie son slot S1 puis son slot S2. La propagation instantane des mutations dclenche
deux mutations successives sur le dispositif d . droite, une propagation en profondeur dabord au niveau du
dispositif : le dispositif d1 dclenche une mutation sur d2 puis sur d3. L aussi, la propagation instantane
dclenche deux mutations successives de d4.
217
B.3.3
Propagation borne
Bien que les connexions dune conguration dentre ne gnrent pas de dpendance cyclique,
ce nest pas le cas des mutations, qui se propagent indpendamment de lorientation des connexions.
Lorsque les mutations comportent des dpendances cycliques, lalgorithme B.2 page prcdente peut
ne pas se terminer, mais peut galement converger.
Lalgorithme B.3 est une variante de lalgorithme B.2 page prcdente, qui se termine toujours.
Le nombre de mutations sur chaque dispositif est limit imax . Lorsquun dispositif a mut imax fois,
celui-ci est considr comme non stabilis. terme, lalgorithme fournit dans NS lensemble des
dispositifs non stabiliss. Si cet ensemble est non vide, la propagation est considre comme non
stabilise dans son ensemble.
De par sa proprit de terminaison, lalgorithme B.3 est de loin prfrable lalgorithme B.2
page prcdente. Deux stratgies sont possibles pour lexploiter : soit interdire les connexions qui
induisent une propagation non stabilise, soit autoriser provisoirement (hors excution) les dispositifs
non stabiliss dans une conguration. Un diteur interactif pourrait par exemple mettre en vidence les
erreurs dans lespoir que lutilisateur les corrige. Une manire de stabiliser la partie problmatique
de la conguration consiste insrer des dispositifs typeurs , dont les types en entre et en sortie
sont xs par paramtrage : cela quivaut ajouter des contraintes un problme sous-contraint.
Soit i : une fonction qui associe un entier des dispositifs, et dont lensemble de dpart est initialement vide et NS un ensemble de dispositifs initialement vide galement.
Rpter les tapes suivantes jusqu ce que soit vide :
1. Copier dans et effacer le contenu de .
2. Pour tout dispositif d de :
(a) Si d ne fait pas partie de lensemble de dpart de i, ajouter d imax i.
(b) Si i(d) = 0, ajouter d NS . Sinon :
i. Appliquer lalgorithme B.1 page 215 d.
Soit lensemble des slots de d ayant chang de type.
ii. Dcrmenter i(d) dans i.
iii. Si d , retirer d de .
iv. Pour tout slot s appartenant , pour tout slot s i-connect s :
Soit d le dispositif parent de s . Si s est un slot dclencheur et si d , ajouter d .
/
Algorithme B.3: Mutation avec propagation borne imax itrations des dispositifs dans une conguration
C. Cet algorithme construit galement lensemble NS des dispositifs non stabiliss.
B.3.4
Exemples de fonctions de mutation
Le systme de mutations, trs gnral, peut se dcliner en un certain nombre de mcanismes

de spcialisation concrets. Parmi ceux-ci, nous donnerons un exemple de typage, de spcialisation
structurelle par paramtrage, et dadaptation bi-directionnelle. Dautres exemples peuvent tre donns,
tels que la spcialisation structurelle par connexion, ou le typage par paramtrage.
218
B.3. ALGORITHMES
Exemple de typage
Voici un exemple de dispositif dont les slots prennent le type int lorsque les slots dentre sont
connects des entiers et le type double dans les autres cas :
Soit un dispositif mutable add ayant deux slots dentre nomms in1 et in2, un slot de sortie
nomm out, et ne comportant pas de paramtre. in1, in2 et out sont t-mutables et possdent comme
supertype double. Les slots dclencheurs sont in1 et in2. La fonction de mutation add de ce dispositif
est la suivante :
P Pm
add :
in1, entree, c1 , x1 , in2, entree, c2 , x2
in1, entree, y , in2, entree, y , out, sortie, y
avec :
y = int si x1 = int et x2 = int
y = double sinon.
Exemple de spcialisation structurelle

Voici un exemple de dispositif dont le nombre de slots de sortie et dentre est paramtrable :
Soit un dispositif mutable multipass comportant deux paramtres respectivement nomms inCount
et outCount. Le dispositif ne comporte pas dautre slot que les slots s-mutables gnrs par la fonction
de mutation. La fonction de mutation multipass de ce dispositif est la suivante :
multipass :
P Pm
inCount, x1 , outCount, x2
2
1
, VSs VSs ,
avec :
1
VSs = si x1 0,
1 =
in1, entree, int , . . . , inx1 , entree, int
VSs
2
VSs = si x2 0,
2
VSs = out1, sortie, int , . . . , outx2 , sortie, int
sinon.
sinon.
Exemple dadaptation bi-directionnelle

Enn, voici un exemple de dispositif de type adaptateur , dont les types sadaptent en entre et
en sortie :
Soit un dispositif mutable autocast comportant un slot dentre et un slot de sortie respectivement
nomms in et out, et ne comportant pas de paramtre. in et out sont dclencheurs et t-mutables, et
possdent comme supertype any. La fonction de mutation autocast de ce dispositif est la suivante :
P Pm
autocast :
in, entree, c1 , x1 , out, sortie, c2 , x2
in, entree, x1 , out, sortie, x2
219
B.4 Oprations sur les congurations

La structure dune conguration dentre est susceptible dvoluer dans le temps : elle peut tre
dite. Cette volution est rgle par un ensemble dtermin doprations, qui dcrivent les volutions
possibles dune conguration tout en imposant des contraintes sur celles-ci.
B.4.1
Oprations lmentaires
Une opration lmentaire sur une conguration est une fonction qui une conguration C et
un ensemble de dispositifs associe une nouvelle conguration C et un nouvel ensemble .
comprend les dispositifs de plus les dispositifs susceptibles dtre non consistants dans C , cest-dire les dispositifs pouvant ncessiter une mutation.
Quatre oprations lmentaires sont numrs par la suite, et dcrits chacun par un algorithme
simple montrant comment C et sobtiennent partir de C et .
Clonage de dispositifs
Le clonage dun dispositif non composite d dans une conguration consiste crer puis ajouter dans cette conguration un nouveau dispositif possdant les mmes valeurs dattributs, mais ne
comportant pas de connexion.
Opcloner(d) : (C, ) (C , )
avec d C.dispositi f s.
1. Cration dun dispositif d vide ;
2. Copie dans d des valeurs des attributs atomiques et des fonctions de d ;
3. Copie dans d des paramtres et des slots non s-mutables et non absents de d ;
4. Ajout de d C.dispositi f s ;
5. Ajout de d .
Ajout dun dispositif

Lajout dun nouveau dispositif dans une conguration consiste en la copie dun des dispositifs
prototypes prsents dans un des dossiers de prototypes de la conguration. Lopration dajout est la
mme que celle de clonage (mme algorithme), ceci prs que le dispositif clon appartient lun
des dossiers de prototypes de la conguration.
Opa jouter(p) : (C, ) (C , )
avec p D.prototypes et D C.bibliotheque.
1. Appliquer Opcloner(p) (C, ) ;
2. p.parent = C ;
220
B.4. OPRATIONS SUR LES CONFIGURATIONS

Connexion
Une opration de connexion consiste relier un slot de sortie un slot dentre par une nouvelle
connexion. Elle est dnie ainsi pour deux slots non externes :
Opconnecter(s,e) : (C, ) (C , )
avec :
s.parent C.dispositi f s
e.parent C.dispositi f s
s e obit aux rgles de couplage, dunicit et dacyclisme ( section A.3 page 201).
1. Cration dune nouvelle connexion x = s e ;
2. Ajout de x C.connexions ;
3. Ajout de {d1 , d2 } .
Dconnexion
Une opration de dconnexion entre deux slots consiste supprimer la connexion correspondante
dans la conguration.
Opdeconnecter(s,e) : (C, ) (C , )
avec :
s.parent C.dispositi f s
e.parent C.dispositi f s
s e C.connexions.
1. Suppression de la connexion s e de C.connexions ;
2. Ajout de {d1 , d2 } .
Suppression dun dispositif

La suppression dun dispositif dans une conguration implique la suppression de toutes les connexions
qui lui sont lies.
Opsupprimer(d) : (C, ) (C , )
avec d C.dispositi f s
1. Pour toute connexion s e de C telle que s d.slots ou e d.slots, appliquer Opdeconnecter(s,e)
(C, ) ;
2. Suppression de d dans C.dispositi f s.
221
B.4.2
Oprations consistantes
Une opration consistante sur une conguration est une fonction qui une conguration C associe
une nouvelle conguration C dont les dispositifs sont consistants. Une opration consistante peut tre
dnie partir dune suite doprations lmentaires, de la manire suivante :
Op(Op1 ,...,Opn ) : C C
1. Soit = ;
2. Appliquer dans lordre les Opi sur (C, ) ;
3. Appliquer lalgorithme de mutation avec propagation sur .
222
Annexe C
Excution dune conguration dentre

Sommaire
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 Dnitions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.1 Signaux valus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.2 Historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.3 Signaux valus multiples . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.4 Processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.5 Fonction dexcution dun dispositif . . . . . . . . . . . . . . . . . . . . .
C.3 Lancement et excution dune conguration . . . . . . . . . . . . . . . . . . .
C.3.1 Codage des signaux dentre et des processeurs . . . . . . . . . . . . . . .
C.3.2 Cration des valeurs et ouverture des dispositifs . . . . . . . . . . . . . . .
C.3.3 Construction de la machine ractive . . . . . . . . . . . . . . . . . . . . .
C.4 Algorithme dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.4.1 Mise jour dun processeur . . . . . . . . . . . . . . . . . . . . . . . . .
C.4.2 La boucle dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.5 Lenvironnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.5.1 Communication avec lenvironnement : non-dterminisme et effets de bord
C.5.2 Ouverture non-dterministe des dispositifs . . . . . . . . . . . . . . . . .
C.5.3 Lhypothse ractive dans ICoM . . . . . . . . . . . . . . . . . . . . . . .
223
224
224
224
225
225
226
226
227
228
229
229
230
230
231
232
232
233
233
ANNEXE C. EXCUTION DUNE CONFIGURATION DENTRE
C.1 Introduction
Nous dcrivons ici la partie excution du modle ICOM, cest--dire le comportement des congurations dentre lors de la phase de lancement et dexcution. Notre algorithme dexcution est de
type ractif ce qui signie que chaque modication des entres est rpercute et propage dans la
conguration en un temps conceptuellement nul (voir 3.3 page 99). La plupart des notions abordes
ici sappuient sur les structures dcrites dans lannexe A.
C.2 Dnitions pralables

E
d
e1
e2
s1
s2
F IG . C.1 Schma dun processeur.
Le comportement en excution dune conguration dentre est essentiellement dcrit par des
processeurs. Un processeur est une fonction qui aux valeurs prises par les slots dentre associe des
valeurs aux slots de sortie (gure C.1). Lorsquune conguration est lance, des structures sont alloues pour stocker la valeur de chaque slot, et chaque dispositif cre un processeur en fonction de
son paramtrage, selon sa fonction dexcution .
Les valeurs manipules par les processeurs sont des valeurs de variables classiques associes un
boolen appel signal : il sagit de signaux valus. Un signal valu est propag aux autres processeurs
seulement si le signal est prsent (boolen vrai). Des modications de la valeur dune variable sont
ncessairement propages, mais une valeur non modie peut galement tre propage. Un signal
valu peut par consquent reprsenter aussi bien un tat quun vnement.
Dans cette section, nous introduisons les dnitions relatives aux signaux valus, aux processeurs,
et aux fonctions dexcution.
C.2.1
Signaux valus
Une variable est dnie par ensemble appel type et un lment de cet ensemble appel valeur :
V = X, x , x X
Un signal valu est la combinaison dune variable et dun boolen appel signal :
S = V, s =
X, x , s , x X, s {vrai, f aux}
La valeur dun signal valu est un couple form par la valeur x de sa variable V (appele valeur
de variable de S) et la valeur de son signal :
v = x, s
224
C.2. DFINITIONS PRALABLES

Lensemble des valeurs possibles de S, not V (S), est V (S) = {v}vX{vrai, f aux} .
C.2.2
Historiques
x
s
t
1
V
1
F
2
V
2
V
2
F
F IG . C.2 volution possible dun signal valu au cours du temps.
La valeur dun signal valu volue au cours du temps, que nous supposons discret et reprsent par
un entier strictement positif. Nous noterons vt = xt , st la valeur dun signal valu linstant t .
Un signal valu volue en accord avec la condition suivante :

t
, xt+1 = xt st+1 = vrai
Autrement dit, le changement de la valeur de variable est une condition sufsante (mais non
ncessaire) pour que le signal soit vrai. En outre, un signal valu est considr comme nayant pas
de valeur de variable tant que son signal na pas reu la valeur vrai au moins une fois. La gure C.2
illustre une volution possible dun signal valu au cours du temps, obissant ces deux conditions.
Un historique dun signal valu S linstant t, not ht (S), dcrit une volution de sa valeur depuis
t = 1 jusqu t strictement positif :
ht (S) = v1 , . . . , vt
La condition de changement de valeur de variable nonce plus haut est traduite par la dnition
de lensemble des historiques possibles H (S). La condition dabsence de valeur de variable est pour
sa part traduite par la dnition de la relation dquivalence entre deux historiques de H (S).
Lensemble des historiques possibles H (S) dun signal valu S est :
H (S) =
v1 , . . . , vt
,vi Xi {vrai, f aux},xi+1 =xi si+1 =vrai
La relation dquivalence entre deux historiques de H (S) est dnie comme suit :
Soient h et h H (S).
h h ssi
h = h ou si h et h sont de la forme :
h = x, f aux , . . . , x, f aux , vk , . . . , vt
h = x , f aux , . . . , x , f aux , vk , . . . , vt
C.2.3
Signaux valus multiples
Par commodit pour la suite, nous tendrons les dnitions prcdentes aux signaux valus multiples du type S = S1 , . . . , Sn :
225

Les valeurs de S sont de la forme v = v1 , . . . , vn . Lensemble des valeurs possibles de S est
v1 , . . . , vn vi Xi {vrai, f aux}
V (S) =
Les historiques ht (S) de S sont de la forme :

ht (S) = ht (v1 ), . . . , ht (vn ) =
v1 , . . . , vt1 , . . . , v1 , . . . , vtn
n
1
Lensemble des historiques possibles H (S) de S est :
H (S) =
v1 , . . . , vn , . . . , v1 , . . . , vtn
n
1
1
,vij Xi {vrai, f aux},xij+1 =xij sij+1 =vrai
La relation dquivalence entre deux historiques de H (S) est dnie comme suit :
Soient h et h H (S), avec h = h1 , . . . , hn et h = h , . . . , h .
n
1
h h ssi i [1, n], hi h
i
C.2.4
Processeurs
Un processeur est une fonction qui chaque historique dun ensemble de signaux valus nomms
signaux dentre associe des valeurs dautres signaux valus, nomms signaux de sortie.
Soit PE,S un processeur dni sur les signaux dentre E = e1 , . . . , em et les signaux de sortie
S = s1 , . . . , sn . La fonction PE,S est dnie comme suit :
PE,S :
H (E) V (S)
ht (E) v(S)
Cette fonction vrie en outre la condition dabsence de valeur nonce prcdemment, cest-dire quelle ne peut pas lire les variables qui nont pas encore reu de signal. Cette condition
snonce ainsi :
h et h H (E), h h PE,S (h) = PE,S (h )
Un processeur PE,S est dit passif si en plus, il ne peut pas gnrer de signal (et fortiori de valeur)
sans en recevoir, ce qui se traduit par la condition suivante :
h H (E)
tel que h = v1 , . . . , vt1 , xt1 , f aux , . . . , v1 , . . . , vt1 , xtn , f aux
n
n
1
1
limage de h est de la forme PE,S (h) =
y1 , f aux , . . . , ym , f aux
Dans le cas contraire, le processeur est dit actif.
C.2.5
Fonction dexcution dun dispositif
Comme nous lavons vu en guise dintroduction, le comportement en excution dun dispositif est
dcrit par un processeur qui opre sur les signaux dentre et de sortie associs ses slots dentre et
de sortie (ces signaux valus sont crs lors du lancement de la conguration, nous le verrons dans la
section suivante).
Le comportement en excution dpend uniquement des valeurs prises par les paramtres du dispositif, ainsi que de ses types connects sil est mutable. chaque paramtrage ( section B.2.3
226
C.3. LANCEMENT ET EXCUTION DUNE CONFIGURATION

page 213) dun dispositif correspond par consquent un processeur. La correspondance paramtrage/processeur
est dcrite par la fonction dexcution du dispositif, qui chacun de ses paramtrages possibles associe un processeur P :
: (d) P
C.3 Lancement et excution dune conguration

1
open
P0
open
open
P2
V0
P1
V1
tri topologique
machine ractive
F IG . C.3 Les quatre phases du processus de lancement dune conguration.
Le lancement dune conguration dentre consiste en un ensemble doprations destines prparer cette conguration dentre lexcution. Ces mcanismes aboutissent la cration dune machine ractive, qui sera la version excutable de la conguration dentre. Les diffrentes tapes de ce
processus, illustres sur la gure C.3 pour une conguration-exemple, sont les suivantes :
1. Aplatissement de larbre des congurations
2. Cration des valeurs et ouverture des dispositifs
3. Tri topologique
4. Cration de la machine ractive
La premire phase consiste aplatir larbre des congurations an de placer tous les dispositifs au
mme niveau. Lalgorithme, appel dcomposition totale, a dj t dcrit en annexe A (algorithme
A.1). La seconde phase consiste crer les structures de base qui serviront lexcution : les Valeurs
(signaux valus) et les Processeurs. Un tri topologique est ensuite effectu sur les processeurs, partir
du graphe de dpendances entre dispositifs ( section A.3.5 page 204). La dernire phase consiste
construire la machine ractive et remplir sa structure.
Nous ne dcrirons pas le mcanisme daplatissement (dj dcrit en Annexe A) et le tri topologique (dj connu [L ACOMME et al. 03]). En revanche nous dtaillerons la phase consistant crer les
227

structures de base , aprs avoir dcrit ces structures. Puis nous dcrirons les machines ractives et la
faon dont elles sont cres.
C.3.1
Codage des signaux dentre et des processeurs
Dans la section prcdente, nous avons introduit et dcrit les processeurs laide doutils mathmatiques simples. Dans cette partie, nous emploierons des reprsentations alternatives sous forme de
structures de donnes.
Un signal valu est cod par une structure nomme Valeur, qui encapsule une valeur de variable
et un temps. Le temps est un entier prcisant quel moment le signal valu a reu un signal pour la
dernire fois. Cette reprsentation est quivalente celle des signaux valus vus prcdemment : un
signal est prsent (s = vrai) si et seulement si le temps de la Valeur est gal au temps courant de la
machine ractive (i.e. au temps global).
La structure Valeur est dcrite ci-dessous :
Valeur
parent
valIndex
valeur
temps
signal
Machine
entier
variable
entier
vrai/faux
TAB . C.1 Structure dun signal valu.

parent : La machine ractive laquelle appartient cette Valeur.
valIndex : Spcie lindice de cette Valeur dans la machine ractive.
valeur : La valeur de variable du signal valu, stocke dans une variable au sens langage de programmation. La reprsentation concrte de cette variable dpend du type du slot associ, ainsi
que du langage de programmation choisi pour limplmentation. Nous ne nous en proccupons
pas ici.
temps : Le temps associ la Valeur, spciant quel moment elle a reu un signal pour la dernire
fois.
signal : Attribut boolen driv spciant si un signal est prsent. Cet attribut vaut vrai ssi le
temps de la valeur est gal au temps de la machine ractive parente.

Un processeur est cod par une structure Processeur. Cette structure comporte des rfrences
des Valeurs dentre et de sortie, ainsi quune dcomposition de PE,S en deux sries de fonctions
nommes calculValeur et calculSignal. Ces fonctions sont des projections de la fonction PE,S sur les
valeurs et les signaux de son ensemble darrive :
Soit PE,S : ht (E) v(S) =
calculValeur[i] : ht (E) xi
calculSignal[i] : ht (E) si
x1 , s1 , . . . , xn , sn .
entres : Cette table contient les Valeurs reprsentant les signaux dentre du processeur.
sorties : Cette table contient les Valeurs reprsentant les signaux de sortie du processeur.
228
C.3. LANCEMENT ET EXCUTION DUNE CONFIGURATION

Processeur
entres
sorties
calculValeur
calculSignal
Valeur [ ]
Valeur [ ]
fonction [ ]
fonction [ ]
TAB . C.2 Structure dun processeur.

calculValeur : Les projections de la fonction P sur les valeurs de variable de chaque signal de sortie.
Cette table comporte autant de fonctions que dlments dans la table valeursSortie.
calculSignal : Les projections de la fonction P sur les signaux de chaque signal de sortie. Cette
table comporte autant de fonctions que dlments dans la table valeursSortie.
C.3.2
Cration des valeurs et ouverture des dispositifs
La seconde tape phase du lancement dune conguration dentre consiste crer les structures
contenant les valeurs des slots.
Une structure Valeur est cre pour tout slot de sortie de la conguration dentre. Les slots
dentre ne comportent pas de Valeur (voir la gure C.3 page 227), mais rfrencent celle de leur slot
connect. Il ny aura donc pas proprement parler de propagation de valeur entre deux slots, puisque
ceux-ci partageront la mme valeur.
Une fois les valeurs cres, les dispositifs sont ouverts : lorsquun dispositif est ouvert, celui-ci
retourne une structure Processeur cre partir de sa fonction dexcution.
C.3.3
Construction de la machine ractive
ProcInfo
P2
Valeur
V0
V1
depFirst
depLast
DepInfo
procIndex
V1
P1
ValInfo
P1
P0
V
dclench
P2
actif
V0
Processeur
P0
variable
temps
temps
F IG . C.4 Exemple de machine ractive cre partir dune conguration exemple.
229

La machine ractive gre tous les aspects de lexcution des congurations dentre, et en particulier le dclenchement des processeurs et la propagation des valeurs. Un exemple de structure de
machine ractive est illustr sur la gure C.4 page prcdente, qui reprend la conguration-exemple
de la gure C.3 page 227. Cette structure est la suivante :
Machine
ProcInfo
ValInfo
DepInfo
temps
(Processeur, vrai/faux, vrai/faux) [ ]

(Valeur, entier, entier) [ ]
vrai/faux [ ]
entier
TAB . C.3 Structure dune machine ractive.

ProcInfo : Cette table contient une liste topologiquement ordonne des processeurs avec leurs
conditions de dclenchement. Le boolen actif spcie si le processeur doit tre continuellement dclench. La valeur de cet attribut dpend de la nature de la fonction PE,S du processeur
( section C.2.4 page 226). Le second boolen, dclench est interne lalgorithme dexcution. Initialement gal actif, il servira spcier pour litration courante si les valeurs du
processeur doivent tre mises jour.
ValInfo : Cette table contient la liste des Valeurs ainsi que leurs dpendances (illustres sur la
gure C.4 page prcdente par des ches pleines). Les dpendances dune Valeur sont dnies
par les attributs depFirst et depLast, qui rfrencent par leur index un ensemble dlments
contigus dans la table DepInfo.
DepInfo : Cette table contient la liste des dpendances rfrences par OutInfo, et est remplie en
mme temps quelle. Lorsquun slot de sortie est trait par lajout dune Valeur dans OutInfo,
une dpendance est cr pour chaque slot dentre qui lui est directement connect. Une dpendance est uniquement dcrite par lattribut ProcIndex, qui rfrence le processeur du dispositif
parent du slot dentre, en pointant vers son index dans la table ProcInfo.
temps : Cet attribut est interne lalgorithme dexcution au mme titre que lattribut dclench
de la premire table. Initialement zro, ce compteur entier spciera le temps courant de la
machine ractive.
C.4 Algorithme dexcution

Lexcution est partage entre les Processeurs qui mettent jour leurs Valeurs de sortie, les Valeurs
qui notient la machine ractive, et enn la machine ractive qui synchronise lensemble.
C.4.1
Mise jour dun processeur
La mise jour dun Processeur consiste modier ses valeurs de sortie, et notier la machine
ractive parente an que cette mise jour soit propage. Lensemble de ce mcanisme est dcrit par
lalgorithme C.1 page suivante : la procdure miseAJour dnie dans la structure Processeur applique les fonctions calculValeur et calculSignal ses Valeurs de sortie. Elle dlgue les assignations
nales et les notications la procdure miseAJour dnie dans la structure Valeur. Lorsquun signal est prsent, cette dernire appelle la procdure envoiSignal de la machine ractive, dcrite dans
la section suivante.
230
C.4. ALGORITHME DEXCUTION

proc Processeur.miseAJour()
for i=0 to sorties.length do
sorties[i].miseAJour(calculValeur[i](entres), calculSignal[i](entres))
end for
end proc
proc Valeur.miseAJour(nouvelleValeur, signal)
valeur nouvelleValeur
if signal = vrai then
machine.envoiSignal(valIndex)
end if
end proc
Algorithme C.1: Mise jour dun processeur.
C.4.2
La boucle dexcution
Lexcution dune machine ractive consiste en une srie ditrations appeles ticks. Pendant un
tick, tous les signaux sont propags dans la machine ractive. La procdure tick (algorithme C.2) dcrit
une itration : la structure ProcInfo est parcourue dans lordre, et chaque processeur est mis jour
sil est dclench. La mise jour dun dispositif peut amener le dclenchement dautres processeurs
situs aprs lui dans la table.
proc Machine.tick()
temps++
for i=0 to ProcInfo.length do
pinfo ProcInfo[i]
if pinfo.dclench then
pinfo.Processeur.miseAJour()
end if
if not pinfo.actif then
pinfo.dclench faux
end if
end for
end proc
proc Machine.envoiSignal(int valIndex)
dinfo DepInfo[valIndex]
dinfo.Valeur.temps temps
for i=dinfo.depFirst to dinfo.depLast do
ProcInfo[DepInfo[i].procIndex].dclench vrai
end for
end proc
Algorithme C.2: Itration dune machine ractive.
Cet algorithme de propagation assure qu la n dun tick, tous les changements ont correctement
t propags, et que la mise jour dun dispositif nest jamais effectue plus dune fois : dans la
conguration-exemple de la gure C.4 page 229, quand B reoit une valeur du dispositif actif A, il
attendra la mise jour de C avant de se mettre jour.
231

Lexcution dune conguration dentre consiste en des appels successifs de la procdure tick.
Notre modle ne dcrit pas comment ces appels sont effectus, en particulier sils une pause les spare
(pour laisser la main dautres processus ou garder une frquence constante), ou encore sils sont
appels uniquement lorsque des valeurs sont prsentes en entre (interruptions matrielles).
C.5 Lenvironnement
Le modle dexcution que nous avons dcrit est particulirement bien adapt la description de
traitements de donnes dterministes. Cependant, un systme interactif comporte souvent une part de
non-dterminisme, en particulier du non-dterminisme temporel rsultant de processus asynchrones,
qui prennent du temps . En outre, il est vident que notre systme ncessite dtre aliment en informations, en particulier celles provenant des dispositifs dentre, et doit galement agir lextrieur
du systme, soit sur lapplication contrle, soit pour gnrer un retour utilisateur (feedback). Tous ces
mcanismes ne peuvent tre pris en compte sans inclure dans le modle la notion denvironnement,
systme externe la machine ractive.
Nous voquerons dans cette partie comment nous pouvons, dans notre modle et dans une ventuelle implmentation, prendre en compte cette communication, puis nous aborderons un autre problme li lenvironnement, celui de lhypothse ractive.
C.5.1
Communication avec lenvironnement : non-dterminisme et effets de bord
Lorsquun dispositif ne possde pas dentres ou de sorties implicites, son comportement lors de
lexcution est entirement dtermin par un processeur oprant uniquement sur les signaux dentre et de sortie lis aux slots du dispositif. Dans le cas contraire, le dispositif communique avec
lenvironnement, et ce processeur ne peut dcrire intgralement son comportement.
Environnement
eext
sext
P
d
e1
e2
s1
s2
Configuration
d'entre
F IG . C.5 Communication entre un processeur et un systme extrieur la conguration, appel environnement.
Nous pouvons cependant gnraliser notre modle dterministe en supposant que lenvironnement
232
C.5. LENVIRONNEMENT
est accessible travers deux signaux valus (dont les types peuvent bien sr tre complexes) : le signal
valu eext et le signal valu sext . Le dispositif interagit alors avec lenvironnement en lisant eext (sil
comporte des entres implicites) et en crivant dans sext (sil comporte des sorties implicites). Le
comportement dun tel dispositif peut alors tre dcrit avec un processeur PE,S dni sur les signaux
valus relatifs aux slots auxquels on ajoute les signaux valus de lenvironnement (gure C.5 page
ci-contre) :
E = Eslots {eext }
S = Sslots {sext }
Notre modle dexcution dcrit le comportement des congurations dentre, mais non le comportement de lenvironnement (qui, par dnition, ne fait pas partie de notre systme), ni les mcanismes de communication avec cet environnement. En particulier, les variables associes eext et sext
ne sont pas explicites et ni leur type ni leur valeur ne sont connues : elles permettent uniquement
dvoquer, dans notre modle, la prsence de non-dterminisme (pour le premier) et deffets de bord
(pour le second).
Dans une implmentation concrte, la communication avec lenvironnement (librairies et parties
du code externes la machine ractive) sera implmente librement dans la fonction de mise jour,
mais devront cependant tre explicitement dclars par la prsence dentres et de sorties implicites.
La prsence dentres implicites implique souvent un dispositif actif, qui a besoin de lire lenvironnement mme en labsence de signaux en entre : il y a donc un sens ce quun dispositif entres
implicites soit actif par dfaut. La prsence de sorties implicites na quant lui pas dinuence sur
les mcanismes dexcution, mais peut apporter (tout comme les entres implicites) une information
utile sur la smantique du dispositif dans une ventuelle reprsentation graphique.
C.5.2
Ouverture non-dterministe des dispositifs
Nous avons dcrit la phase douverture des dispositifs comme un mcanisme permettant de crer
des processeurs de manire dterministe. Cependant, les dispositifs comportant des entres ou des
sorties implicites ont souvent besoin dallouer au sein de lenvironnement des ressources pour prparer leur excution. Ces mcanismes dinitialisation peuvent, de manire non-dterministe, russir ou
chouer (dans le cas des dispositifs sans entres ou sorties implicites, nous supposerons quelle russit
toujours).
Lorsque louverture dun dispositif d a russi, celui-ci retourne, comme dcrit prcdemment, un
Processeur construit partir de sa fonction dexcution P = ((d)). Dans le cas contraire, il retourne
le Processeur nul dcrit par la fonction P :
P : ht (E)
C.5.3
Lhypothse ractive dans ICoM
Dans une implmentation concrte, il est vident que le traitement de linformation (effectu par
lensemble des processeurs) prend un certain temps, ainsi que la communication entre ces processeurs
(pris en charge par la machine ractive). En pratique, cette dernire est souvent ngligeable par rapport
aux traitements de donnes. La dure dun tick dans une machine ractive est par consquent au
moins gale la somme des dures des traitements effectus par les processeurs. En outre, le temps
233

de rponse dune machine ractive augmente linairement avec la taille dune conguration dentre.
Un modle ractif ne reste valide que tant que lhypothse du synchronisme parfait est vrie,
cest--dire si la machine ractive ragit plus vite que lenvironnement. Dans notre modle, le signal
valu eext est synchronis sur lhorloge de la machine ractive. En supposant que eext lit des signaux
que lenvironnement lui envoie selon son horloge propre, lhypothse ractive est vrie si durant
chaque tick, au plus un signal est mis par lenvironnement.
eext dcrit en gnral linformation provenant dun dispositif dentre concret. En supposant, pour
simplier, que ce dispositif concret met des informations frquence constante, la machine ractive
doit ragir au moins la mme frquence1 . Pour une conguration dentre comportant plusieurs de
ces dispositifs, la frquence de raction de la machine ractive doit tre au moins gale celle du
dispositif mettant la plus haute frquence.
1 Il
nest cependant pas ncessaire quune machine ractive ragisse frquence constante.
234
Bibliographie
[ACCOT et al. 98] Johnny ACCOT, Stphane C HATTY, Yannick J ESTIN, et Stphane S IRE. Conception des
interfaces : et si nous analysions enn la tche du programmeur ? . Dans Prise de position pour les diximes
journes francophones sur lInteraction Homme Machine (IHM98), septembre 24 1998.
[ACCOT et al. 97] Johnny ACCOT, Stphane C HATTY, Sbastien M AURY, et Philippe PALANQUE. Formal
transducers : Models of devices and building bricks for the design of highly interactive systems . Dans
M. D. H ARRISON et J. C. T ORRES, diteurs, Design, Specication and Verication of Interactive Systems
97, Eurographics, pages 143159, Wien, 1997. Springer-Verlag. Proceedings of the Eurographics Workshop
in Granada, Spain, June 4 6, 1997.
[A LIAS 01] Maya real-time author (RTA) . Alias Systems (Alias|Wavefront), dcembre 2001. http:
//www.alias.com.
[A PPERT et al. 03] Caroline A PPERT, Michel B EAUDOUIN -L AFON, et Wendy M ACKAY. Context matters :
Evaluating interaction techniques with the CIS model . Rapport Technique 1372, Laboratoire de Recherche
en Informatique (LRI), Universit de Paris-Sud, 2003.
[A PPLE 02] Introduction to the aqua human interface . Apple Computer, Inc., 2002. http://developer.
apple.com.
[A PPLE 03] Interface builder . Apple Computer, Inc., 2003. http://developer.apple.com/tools/
interfacebuilder/.
[BALAKRISHNAN et al. 99] Ravin BALAKRISHNAN, George F ITZMAURICE, Gordon K URTENBACH, et
William B UXTON. Digital tape drawing . Dans Proceedings of the 12th Annual ACM Symposium on
User Interface Software and Technology, pages 161170, N.Y., novembre 710 1999. ACM Press.
[BARLOW et al. 90] Horace BARLOW, Colin B LAKEMORE, et Miranda W ESTON -S MITH. Images and Understanding : Thoughts about images : Ideas about understanding. Cambridge University Press, 1990.
ISBN 0-521-36944-4.
[BASTIDE et al. 02] Rmi BASTIDE, David NAVARRE, et Philippe PALANQUE. A model-based tool for
interactive prototyping of highly interactive applications . Dans CHI 02 extended abstracts on Human
factors in computer systems, pages 516517. ACM Press, 2002.
[BAUDEL 95] Thomas BAUDEL. Morphologie de lInteraction Humain-Ordinateur : tude de Modles dInteraction Gestuelle. Thse de doctorat, Universit de Paris-Sud, U.F.R. scientique dOrsay, dec 1995.
[BAUDISCH et al. 03] P. BAUDISCH, E. C UTRELL, D. ROBBINS, M. C ZERWINSKI, P. TANDLER, B. B EDER SON , et A. Z IERLINGER. Drag-and-pop and drag-and-pick : Techniques for accessing remote screen
content on touch- and pen-operated systems . Dans Proceedings of the 9th IFIP TC13 International Conference on Human-Computer Interaction (INTERACT03), pages 5764, septembre 2003.
235
BIBLIOGRAPHIE
[B EAUDOUIN -L AFON 97] Michel B EAUDOUIN -L AFON. Interaction instrumentale : de la manipulation directe la ralit augmente . Dans Actes des Neuvimes Journes sur lInteraction Homme-Machine,
IHM97, sep 1997.
[B EAUDOUIN -L AFON 00] Michel B EAUDOUIN -L AFON. Instrumental interaction : an interaction model
for designing post-WIMP user interfaces . Dans Thea T URNER, Gerd S ZWILLUS, Mary C ZERWINSKI,
et Patern FABIO, diteurs, Proceedings of the 2000 Conference on Human Factors in Computing Systems
(CHI-00), pages 446453, N. Y., avril 16 2000. ACM Press.
[B EAUDOUIN -L AFON et al. 90] Michel B EAUDOUIN -L AFON, Yves B ERTEAUD, et Stphane C HATTY.
Creating direct manipulation applications with xtv . Dans Proc. European X Window System Conference,
novembre 1990.
[B EAUDOUIN -L AFON & L ASSEN 00] Michel B EAUDOUIN -L AFON et Henry Michael L ASSEN. The architecture and implementation of CPN2000, a post-WIMP graphical application . Dans Proceedings of the
13th Annual Symposium on User Interface Software and Technology (UIST-00), pages 181190, N.Y., novembre 58 2000. ACM Press.
[B EDERSON 03] Ben B EDERSON. The piccolo 1.0 toolkit . Human Computer Interaction Lab (HCIL),
University of Maryland, avril 2003. http://www.cs.umd.edu/hcil/piccolo/.
[B EDERSON et al. 00] Benjamin B. B EDERSON, Jon M EYER, et Lance G OOD. Jazz : an extensible zoomable
user interface graphics toolkit in java . Dans Proceedings of the 13th Annual Symposium on User Interface
Software and Technology (UIST-00), pages 171180, N.Y., novembre 58 2000. ACM Press.
[B ERRY 89] Grard B ERRY. Real time programming : special purpose or general purpose languages .
Rapport interne RR-1065, Inria, Institut National de Recherche en Informatique et en Automatique, 1989.
[B ERRY 99] Grard B ERRY. The Esterel v5 language primer . Rapport Technique, avril 1999. http:
//www-sop.inria.fr/meije/esterel/doc/main-papers.html.
[B ERRY 00] Grard B ERRY. The Foundations of Esterel. MIT Press, 2000.
[B ERRY et al. 87] Grard B ERRY, P. C OURONN, et G. G ONTHIER. Programmation synchrone des systmes
ractifs : le langage ESTEREL . Technique et Science Informatique, 6(4), 1987.
[B IER et al. 93] E. B IER, M. S TONE, K. P IER, W. B UXTON, et T. D E ROSE. Toolglass and magic lenses :
The see-through interface . Proceedings of SIGGRAPH93, pages 7380, 1993.
[B IER & F REEMAN 91] E. A. B IER et S. F REEMAN. MMM : A user interface architecture for shared editors
on a single screen . Dans Proceedings of the Fourth Annual Symposium on User Interface Software and
Technology (UIST 91), pages 7986, South Carolina, USA, novembre 11-13 1991. ACM Press.
[B IER & S TONE 86] E. A. B IER et M. C. S TONE. Snap-dragging . Computer Graphics (Proc. ACM SIGGRAPH 86), 20(4) :233240, 1986.
[B LANCH 02] Renaud B LANCH. Programmer linteraction avec des machines tats hirarchiques . Dans
Proceedings of the 14th French-speaking conference on Human-computer interaction (Confrence Francophone sur lInteraction Homme-Machine), pages 129136. ACM Press, 2002.
[B OLT 80] Richard A. B OLT. put-that-there : Voice and gesture at the graphics interface . Computer
Graphics, 14(3) :262270, juillet 1980.
[B ORNING 79] Alan Hamilton B ORNING. Thinglab - A Constraint-Oriented Simulation Laboratory. PhD
thesis, Stanford University, juillet 1979. galement disponible comme rapports de recherche STAN-CS-79746 (Stanford Computer Science Department) et SSL-79-3 (XEROX Palo Alto Research Center).
236
BIBLIOGRAPHIE
[B OURIT 00] Cyril B OURIT. Chamois : un logiciel de constructions gomtriques . aot 2000. http:
//membres.lycos.fr/bourit/.
[B UXTON 83] William B UXTON. Lexical and pragmatic considerations of input structures . Computer
Graphics, 17(1) :3137, janvier 1983.
[B UXTON 86 A ] William B UXTON. Chunking and phrasing and the design of human-computer dialogues .
Dans H. J. K UGLER, diteur, Information Processing 86, Proceedings of the IFIP 10th Worm Computer
Congress, pages 475480. North Holland Publishers, 1986.
[B UXTON 86 B ] William B UXTON. There is more to interaction than meets the eye : Some issues in manual
input . Dans D. A. N ORMAN et S. W. D RAPER, diteurs, User Centred System Design : New Perspectives
on Human-computer Interaction, pages 319337. Lawrence Erlbaum Associates, Hillsdale, NJ., 1986.
[B UXTON & M YERS 86] William B UXTON et Brad A. M YERS. A study in two-handed input . Human
Factors in Computing Systems, pages 321326, 1986.
[C ADOZ 94] Claude C ADOZ. Le geste, canal de communication homme/machine : la communication instrumentale . Technique et Science de lInformation, 13(1) :3161, 1994.
[C APPONI & L ABORDE 91] B. C APPONI et C. L ABORDE. Cabri-gomtre, un environnement pour lapprentissage de la gomtrie lmentaire . Dans Actes de la VIme cole dt de didactique des mathmatiques,
pages 22022, 1991.
[C ARD et al. 90] Stuart K. C ARD, Jock D. M ACKINLAY, et George G. ROBERTSON. The design space of
input devices . Dans Proceedings of ACM CHI90 Conference on Human Factors in Computing Systems,
Multi-Media, pages 117124, 1990.
[C ARD et al. 91] Stuart K. C ARD, Jock D. M ACKINLAY, et George G. ROBERTSON. A morphological
analysis of the design space of input devices . ACM Trans. on Inf. Sys., 9(2) :99, 1991.
[C ARR 91] R. M. C ARR. The point of the pen (PenPoint operating system) . Byte Magazine, 16(2) :211
214, 216, 219221, fvrier 1991.
[C ARSON 97] George S. C ARSON. Standards pipeline :the Open GL specication . Computer Graphics,
31(2) :1718, mai 1997.
[C HAPMAN 03] Davis C HAPMAN.
ISBN 2744015571.
Visual C++ 6.
Le Programmeur. CampusPress, mars 2003.
[C HATTY 94] Stephane C HATTY. Extending a graphical toolkit for two-handed interaction . Dans Proceedings of the ACM Symposium on User Interface Software and Technology, Two Hands and Three Dimensions, pages 195204, 1994.
[CMI 02] Le projet GINA (Gomtrie Interactive et NAturelle) . cole des Mines de Nantes, quipe CMI,
2002. http://www.emn.fr/x-info/gina/.
[C OHEN et al. 89] P. R. C OHEN, M. DALRYMPLE, D. B. M ORAN, F. C. P EREIRA, et J. W. S ULLIVAN. Synergistic use of direct manipulation and natural language . Dans Proceedings of the SIGCHI conference on
Human factors in computing systems, pages 227233. ACM Press, 1989.
[C OUTAZ 87] Joelle C OUTAZ. PAC, an object-oriented model for dialog design . Dans Proceedings of IFIP
INTERACT87 : Human-Computer Interaction, 2. Design and Evaluation Methods : 2.5 Dialogue Design and
Evaluation, pages 431436, 1987.
[C YCORE 03] Cult3D Designer . Cycore, 2003. http://www.cult3d.com/Cult3D/.
237
BIBLIOGRAPHIE
[D IX & RUNCIMAN 85] Alan D IX et Colin RUNCIMAN. Abstract models of interactive systems . Dans
Proceedings of the HCI85 Conference on People and Computers : Designing the Interface, The Design
Process : Models and Notation for Interaction, pages 1322, 1985.
[D OHERTY et al. 01] Eamon D OHERTY, Gilbert C OCKTON, Chris B LOOR, et Dennis B ENIGNO. Improving
the performance of the cyberlink mental interface with "yes / no program" . Dans Proceedings of ACM CHI
2001 Conference on Human Factors in Computing Systems, Motion and Emotion, pages 6976, 2001.
[D RAGICEVIC 98] Pierre D RAGICEVIC. Concrtiser les dispositifs dentre dans les outils de dveloppement , Prise de position. Dans Actes des diximes journes francophones sur lInteraction Homme Machine
(IHM98), pages 133139, septembre 24 1998.
[D RAGICEVIC 01] Pierre D RAGICEVIC. Une architecture en cascade pour des systmes interactifs multidispositifs , Rencontres Doctorales, papier court. Dans A. B LANDFORD, J. VANDERDONKT, et P. G RAY,
diteurs, People and Computers XV Interaction without Frontiers : Joint proceedings of IHM 2001 and HCI
2001, volume 2, pages 191192. Springer Verlag, 2001.
[D RAGICEVIC 02] Pierre D RAGICEVIC. Page Web du projet ICON . cole des Mines de Nantes, quipe
CMI, 2002. http://www.emn.fr/x-info/icon/.
[D RAGICEVIC & F EKETE 99] Pierre D RAGICEVIC et Jean-Daniel F EKETE. tude dune bote outils multidispositifs . Dans Actes de la 11ime confrence francophone dInteraction Homme-Machine (IHM99),
pages 5562. Cepadues, novembre 1999.
[D RAGICEVIC & F EKETE 00] Pierre D RAGICEVIC et Jean-Daniel F EKETE. Input device selection and interaction conguration with ICON . Rapport Technique 00/5/INFO, cole des Mines de Nantes, dpartement
Informatique, novembre 2000.
[D RAGICEVIC & F EKETE 01] Pierre D RAGICEVIC et Jean-Daniel F EKETE. Input device selection and interaction conguration with ICON . Dans A. B LANDFORD, J. VANDERDONKT, et P. G RAY, diteurs, People
and Computers XV Interaction without Frontiers : Joint proceedings of IHM 2001 and HCI 2001, pages
543558. Springer Verlag, 2001.
[D RAGICEVIC & F EKETE 02] Pierre D RAGICEVIC et Jean-Daniel F EKETE. ICON : Input device selection
and interaction conguration , Dmonstration, papier court. Dans UIST 02 Companion. The 15th Annual
ACM Symposium on User Interface Software and Technology, octobre 2730 2002.
[D RAGICEVIC & F EKETE 03] Pierre D RAGICEVIC et Jean-Daniel F EKETE. ICON : Towards high input
adaptability of interactive applications . Rapport Technique (en cours de publication), cole des Mines de
Nantes, dpartement Informatique, dcembre 2003.
[D RAGICEVIC & F EKETE 04] Pierre D RAGICEVIC et Jean-Daniel F EKETE. The input congurator toolkit :
Towards high input adaptability in interactive applications . Dans S OUMIS AVI2004 Advanced Visual
Interfaces. ACM Press, mai 2528 2004.
[D RAGICEVIC & H UOT 02] Pierre D RAGICEVIC et Stphane H UOT. SpiraClock : a continuous and nonintrusive display for upcoming events . Dans CHI 02 extended abstracts on Human factors in computer
systems, pages 604605. ACM Press, 2002.
[D UKE & H ARRISON 93] D. J. D UKE et M. D. H ARRISON. Abstract interaction objects . Dans R. J. H UB BOLD et R. J UAN , diteurs, Eurographics 93, pages 2536, Oxford, UK, 1993. Eurographics, Blackwell
Publishers.
[D UNN 00] Jeff D UNN. Developing accessible JFC applications . Sun Microsystems Accessibility Team,
juin 2000. http://www.sun.com/access/developers/developing-accessible-apps/.
238
BIBLIOGRAPHIE
[D UNN & H ERZOG 77] Robert M. D UNN et Bertram H ERZOG. Status report of the Graphics Standards
Planning Committee of ACM/SIGGRAPH . Computer Graphics, 11(3) :I19 + II117, Fall 1977.
[E CKERT et al. 79] R. E CKERT, G. E NDERLE, K. K ANSY, et F.J. P RESTER. GKS79 - proposal of a standard
for a graphical kernel system . Dans Proceedings of Eurographics79, 1979.
[E CKSTEIN & L OY 02] Robert E CKSTEIN et Marc L OY. Java Swing. OReilly & Associates, Inc., 981 Chestnut Street, Newton, MA 02164, USA, 2e dition, 2002. ISBN 0-596-00408-7.
[E LLIOTT et al. 94] Conal E LLIOTT, Greg S CHECHTER, Ricky Y EUNG, et Salim A BI -E ZZI. TBAG : A high
level framework for interactive, animated 3D graphics applications . Dans Andrew G LASSNER, diteur,
Proceedings of SIGGRAPH 94 (Orlando, Florida, July 2429, 1994), Computer Graphics Proceedings,
Annual Conference Series, pages 421434. ACM SIGGRAPH, ACM Press, juillet 1994. ISBN 0-89791667-0.
[E LO 02] Keys to a successful kiosk application . Elo TouchSystems, Inc., 2002. http://www.elotouch.
com.
[E STEBAN 97] Olivier E STEBAN. Programmation visuelle pour la construction dinterfaces homme-machine
hautement interactives. Thse de doctorat, Laboratoire Interface Homme Systmes (LIHS), avril 1997.
[E STEBAN et al. 95] O. E STEBAN, S. C HATTY, et P. PALANQUE. Whizzed : a visual environment for building highly interactive software . Dans Proceedings of IFIP INTERACT95 : Human-Computer Interaction,
pages 121126, 1995.
[F EKETE & B EAUDOUIN -L AFON 96] Jean-Daniel F EKETE et Michel B EAUDOUIN -L AFON. Using the
multi-layer model for building interactive graphical applications . Dans Proceedings of the ACM Symposium on User Interface Software and Technology, Papers : Tools, pages 109118, 1996.
[F EKETE & D RAGICEVIC 00] Jean-Daniel F EKETE et Pierre D RAGICEVIC. Une architecture multidispositifs . Dans Actes du Colloque sur les Interfaces Multimodales, mai 910 2000.
[F EKETE et al. 98] Jean-Daniel F EKETE, Martin R ICHARD, et Pierre D RAGICEVIC. Specication and verication of interactors : A tour of esterel . Dans Chris R. ROAST, diteur, Formal Aspects of Human
Computer Interaction FAHCI98, pages 103118. British Computer Society, septembre 1998.
[F EKETE 96 A ] Jean-Daniel F EKETE. Les trois services du noyau smantique indispensables lIHM .
Dans Actes Huitimes Journes sur lIngnierie des Interfaces Homme-Machine, IHM96, pages 4550,
septembre 1996.
[F EKETE 96 B ] Jean-Daniel F EKETE. Un modle multicouche pour la construction dapplications graphiques
interactives. Thse de doctorat, Universit de Paris-Sud, Orsay (France), janvier 1996.
[F IGUEROA et al. 02] Pablo F IGUEROA, Mark G REEN, et H. James H OOVER. InTml : a description language
for VR applications . Dans Proceeding of the seventh international conference on 3D Web technology, pages
5358. ACM Press, 2002.
[F INGERW ORKS 03] iGesture multitouch Pad . FingerWorks, 2003. Brevet US. 6323846. http://www.
fingerworks.com/.
[F ITZMAURICE & B UXTON 97] George F ITZMAURICE et William B UXTON. An empirical evaluation of
graspable user interfaces : Towards specialized, space-multiplexed input . Dans Proceedings of ACM CHI
97 Conference on Human Factors in Computing Systems, volume 1 de PAPERS : Handy User Interfaces,
pages 4350, 1997.
239
BIBLIOGRAPHIE
[F ITZMAURICE et al. 95] George W. F ITZMAURICE, Hiroshi I SHII, et William B UXTON. Bricks : Laying the
foundations for graspable user interfaces . Dans Irvin R. K ATZ, Robert M ACK, Linn M ARKS, Mary Beth
ROSSON, et Jakob N IELSEN, diteurs, Proceedings of the Conference on Human Factors in Computing
Systems (CHI95), pages 442449, New York, NY, USA, mai 1995. ACM Press.
[F OLEY et al. 90] J. F OLEY, A. VAN DAM, S. F EINER, et J. H UGHES. Computer graphics Principles and
Practice. Addison-Wesley, 2e dition, 1990.
[F OLEY et al. 84] James D. F OLEY, Victor L. WALLACE, et Peggy C HAN. The human factors of computer
graphics interaction techniques . IEEE Computer Graphics and Applications, 4(11) :1348, novembre
1984.
[F OWLER 99] A. F OWLER. A Swing architecture overview : The inside story on JFC component design .
Sun Microsystems, 1999. http://java.sun.com/products/jfc/tsc/articles/architecture/.
[F RANTZ 00] Grard F RANTZ. Visual Basic 6 : Le guide du programmeur. La rfrence. Osman Eyrolles
Multimdia, novembre 2000. ISBN 2746402343.
[G ILL 02] Lisa G ILL. The secret of logitechs success . oct 2002. E-Commerce Times. http://www.
ecommercetimes.com/perl/story/19664.html.
[G OLDBERG & ROBSON 81] A. G OLDBERG et D. ROBSON. The Smalltalk-80 system . Byte Magazine,
6(8) :3648, aot 1981.
[G REENBERG & B OYLE 02] Saul G REENBERG et Michael B OYLE. Customizable physical interfaces for
interacting with conventional applications . Dans Proceedings of the 15th annual ACM symposium on User
interface software and technology (UIST-02), pages 3140, New York, octobre 2730 2002. ACM Press.
[G REENBERG & F ITCHETT 01] Saul G REENBERG et Chester F ITCHETT. Phidgets : Easy development of
physical interfaces through physical widgets . Dans Proceedings of the 14th Annual Symposium on User
Interface Software and Technology (UIST-01), pages 209218, New York, novembre 1114 2001. ACM
Press.
[GSA 91] GSA. Managing end user computing for users with disabilities. General Services Administration,
1991. Washington, DC.
[G UIARD 87] Yves G UIARD. Asymmetric division of labor in human skilled bimanual action : The kinematic chain as a model. . The Journal of Motor Behavior, 19(4) :486517, 1987.
[H ALBWACHS et al. 91] N. H ALBWACHS, P. C ASPI, P. R AYMOND, et D. P ILAUD. The synchronous data
ow programming language LUSTRE . Dans Proceedings of the IEEE, volume 79, septembre 1991.
[H APTEK 03] PeoplePutty : dynamic 3-D character building tool . Haptek, Inc., 2003. http://www.
haptek.com/.
[H AREL 87] David H AREL. Statecharts : A visual formalism for complex systems . Science of Computer
Programming, 8(3) :231274, juin 1987.
[H EWITT 84] W. T. H EWITT. PHIGS Programmers Hierarchical Interactive Graphics System . Computer Graphics Forum, 3(4) :299300, dcembre 1984.
[H INCKLEY et al. 98] Ken H INCKLEY, Mary C ZERWINSKI, et Mike S INCLAIR. Interaction and modeling
techniques for desktop two-handed input . Dans Proceedings of the 11th Annual Symposium on User
Interface Software and Technologie (UIST-98), pages 4958, New York, novembre 14 1998. ACM Press.
[H INCKLEY et al. 03] Ken H INCKLEY, R.J.K. JACOB, et C. WARE. Computer Science and Engineering
Handbook Second Edition (in press), Chapitre Input/Output Devices and Interaction Techniques. CRC Press,
2e dition, 2003.
240
BIBLIOGRAPHIE
[H INCKLEY et al. 94 A ] Ken H INCKLEY, R. PAUSCH, J. C. G OBLE, et N. F. K ASSELL. Passive real-world
interface props for neurosurgical visualization . Proceedings of CHI 94, pages 452458, 1994.
[H INCKLEY et al. 94 B ] Ken H INCKLEY, Randy PAUSCH, John C. G OBLE, et Neal F. K ASSELL. A survey
of design issues in spatial input . Dans ACM UIST94 Symp. on User Interface Software & Technology,
pages 213222. 1994.
[H ONEYWELL 99] Steve H ONEYWELL. Quake III Arena : Primas Ofcial Strategy Guide. Prima Lifestyles,
dec 1999. ISBN 0761525882.
[H ONG & L ANDAY 00] Jason I. H ONG et James A. L ANDAY. SATIN : a toolkit for informal ink-based
applications . Dans Proceedings of the 13th Annual Symposium on User Interface Software and Technology
(UIST-00), pages 6372, N.Y., novembre 58 2000. ACM Press.
[H OURCADE & B EDERSON 99] Juan Pablo H OURCADE et Benjamin B. B EDERSON. Architecture and implementation of a java package for multiple input devices (MID) . Rapport interne CS-TR-4018, University
of Maryland, College Park, mai 1999.
[H OURIZI & J OHNSON 01] R. H OURIZI et P. J OHNSON. Beyond mode error : Supporting strategic knowledge structures to enhance cockpit safety . Dans A. B LANDFORD, J. VANDERDONKT, et P. G RAY, diteurs,
People and Computers XV Interaction without Frontiers : Joint proceedings of IHM 2001 and HCI 2001,
2001.
[H UDSON 90] Scott E. H UDSON. Adaptive semantic snapping - a technique for semantic feedback at the
lexical level . Dans Proceedings of the SIGCHI conference on Human factors in computing systems, pages
6570. ACM Press, 1990.
[H UDSON et al. 97] Scott E. H UDSON, Roy RODENSTEIN, et Ian S MITH. Debugging lenses : A new class of
transparent tools for user interface debugging . Dans Proceedings of the ACM Symposium on User Interface
Software and Technology, Making Things Visible, pages 179187, 1997.
[H UDSON & S MITH 96 A ] Scott E. H UDSON et Ian S MITH. SubArctic UI Toolkit users manual st. Paul
release (beta version 0.8e) . septembre 1996. http://www.cc.gatech.edu/gvu/ui/sub_arctic/. GA
30332-0280.
[H UDSON & S MITH 96 B ] Scott E. H UDSON et Ian S MITH. Ultra-lightweight constraints . Dans Proceedings of the 9th annual ACM symposium on User interface software and technology, pages 147155. ACM
Press, 1996.
[H UDSON & S TASKO 93] Scott E. H UDSON et John T. S TASKO. Animation support in a user interface
toolkit : exible, robust, and reusable abstractions . Dans Proceedings of the 6th annual ACM symposium
on User interface software and technology, pages 5767. ACM Press, 1993.
[H UOT 03] Stphane H UOT. Page Web du projet MagLite . cole des Mines de Nantes, quipe CMI, 2003.
http://www.emn.fr/x-info/gina/maglite.
[H UOT et al. 03] Stphane H UOT, Cdric D UMAS, et Grard H GRON. Toward creative 3D modeling : an
architects sketches study . Dans Proceedings of the 9th IFIP TC13 International Conference on HumanComputer Interaction (INTERACT03), septembre 2003.
[H UTCHINS et al. 86] E. L. H UTCHINS, J. D. H OLLAN, et D. A. N ORMAN. Direct manipulation interfaces .
Dans N ORMAN , D.A. et S. W. D RAPER, diteurs, User Centered System Design : New Perspectives on
Human-Computer Interaction, pages 87124. Lawrence Erlbaum Associates, Hillsdale, NJ and London,
1986.
241
BIBLIOGRAPHIE
[I NGALLS et al. 88] Dan I NGALLS, Scott WALLACE, Yu-Ying C HOW, Frank L UDOLPH, et Ken D OYLE. Fabrik : A visual programming environment . Dans Norman M EYROWITZ, diteur, OOPSLA88 : ObjectOriented Programming Systems, Languages and Applications : Conference Proceedings, pages 176190,
1988.
[I SHII & U LLMER 97] Hiroshi I SHII et Brygg U LLMER. Tangible bits : Towards seamless interfaces between
people, bits and atoms . Dans Proceedings of ACM CHI 97 Conference on Human Factors in Computing
Systems, volume 1 de PAPERS : Beyond the Desktop, pages 234241, 1997.
[ISO 85] The Graphical Kernel System (GKS) : ISO 7942. International Organization for Standardization,
Geneva, Switzerland, 1985.
[ISO 87] LOTOS - language of temporal ordering specication . Rapport Technique ISO DP 8807, 1987.
[JACOB 96] Robert J. K. JACOB. Human-computer interaction : Input devices . ACM Computing Surveys,
28(1) :177179, mars 1996.
[JACOB et al. 99] Robert J. K. JACOB, Leonidas D ELIGIANNIDIS, et Stephen M ORRISON. A software model and specication language for non-WIMP user interfaces . ACM Transactions on Computer-Human
Interaction, 6(1) :146, mars 1999.
[JACOB et al. 94] Robert J. K. JACOB, Linda E. S IBERT, Daniel C. M C FARLANE, et M. Preston M ULLEN
J R .. Integrality and separability of input devices . ACM Transactions on Computer-Human Interaction,
1(1) :326, mars 1994.
[J ENSEN 95] Kurt J ENSEN. Coloured Petri Nets : Basic Concepts, Analysis Methods and Practical Use, vol.
2. EATCS Monographs on Theoretical Computer Science. Springer Verlag, 1995. ISBN 3-540-58276-2.
[J USB 03] jusb : Java USB . Projet open source, 2003. http://jusb.sourceforge.net/.
[K ANSY 85] K. K ANSY. 3D extension to GKS . Computers and Graphics, 9(3) :267273, 1985.
[K NEP et al. 95] Brian K NEP, Craig H AYES, Rick S AYRE, et Tom W ILLIAMS. Dinosaur input device .
Dans Irvin R. K ATZ, Robert M ACK, Linn M ARKS, Mary Beth ROSSON, et Jakob N IELSEN, diteurs, Proceedings of the Conference on Human Factors in Computing Systems (CHI95), pages 304309, New York,
NY, USA, mai 1995. ACM Press.
[K RASNER & P OPE 88] G. E. K RASNER et S. T. P OPE. A cookbook for using the model-view-controller user
interface paradigm in Smalltalk-80 . Journal of Object Oriented Programming, 1(3) :2649, aot/septembre
1988.
[K URTENBACH & B UXTON 94] Gordon K URTENBACH et William B UXTON. User learning and performance with marking menus . Dans Beth A DELSON, Susan D UMAIS, et Judith O LSON, diteurs, Proceedings of the Conference on Human Factors in Computing Systems, pages 258264, New York, NY, USA,
avril 1994. ACM Press.
[K URTENBACH et al. 97] Gordon K URTENBACH, George F ITZMAURICE, Thomas BAUDEL, et Bill B UXTON.
The design of a GUI paradigm based on tablets, two-hands, and transparency . Dans Proceedings of ACM
CHI 97 Conference on Human Factors in Computing Systems, volume 1 de PAPERS : Handy User Interfaces,
pages 3542, 1997.
[L ACOMME et al. 03] Philippe L ACOMME, Christian P RINS, et Marc S EVAUX. Algorithmes de graphes. Eyrolles, 2e dition, octobre 2003. ISBN 2212113854.
[L ANDAY & M YERS 95] James A. L ANDAY et Brad A. M YERS. Interactive sketching for the early stages
of user interface design . Dans Irvin R. K ATZ, Robert M ACK, Linn M ARKS, Mary Beth ROSSON, et Jakob
242
BIBLIOGRAPHIE
N IELSEN, diteurs, Proceedings of the Conference on Human Factors in Computing Systems (CHI95),
pages 4350, New York, NY, USA, mai 1995. ACM Press.
[L INTON et al. 89] Mark A. L INTON, John M. V LISSIDES, et Paul R. C ALDER. Composing user interfaces
with InterViews . IEEE Computer, 22(2), Febuary 1989.
[L IPSCOMB & P IQUE 93] James S. L IPSCOMB et Michael E. P IQUE. Analog input device physical characteristics . ACM SIGCHI Bulletin, 25(3) :4045, 1993.
[M ACKAY 96] Wendy E. M ACKAY. Ralit augmente : le meilleur des deux mondes . La Recherche,
numro spcial Lordinateur au doigt et lil, 284, mars 1996.
[M ACKAY et al. 98] Wendy E. M ACKAY, Anne-Laure FAYARD, Laurent F ROBERT, et Lionel M EDINI.
Reinventing the familiar : Exploring an augmented reality design space for air trafc control . Dans
Proceedings of ACM CHI 98 Conference on Human Factors in Computing Systems, volume 1 de Computer
Augmented Environments, pages 558565, 1998.
[M AC K ENZIE & Z HANG 97] I. Scott M AC K ENZIE et Shawn Z HANG. The immediate usability of Grafti .
Dans Graphics Interface 97, pages 129137, mai 1997.
[M ALONEY et al. 89] John H. M ALONEY, Alan B ORNING, et Bjorn N. F REEMAN -B ENSON. Constraint
technology for user-interface construction in ThingLab II . Dans Norman M EYROWITZ, diteur, OOPSLA89 Conference Proceedings : Object-Oriented Programming : Systems, Languages, and Applications,
pages 381388. ACM Press, 1989.
[M ANKOFF et al. 00] Jennifer M ANKOFF, Scott E. H UDSON, et Gregory D. A BOWD. Providing integrated
toolkit-level support for ambiguity in recognition-based interfaces . Dans Thea T URNER, Gerd S ZWILLUS,
Mary C ZERWINSKI, et Patern FABIO, diteurs, Proceedings of the 2000 Conference on Human Factors in
Computing Systems (CHI-00), pages 368375, N. Y., avril 16 2000. ACM Press.
[M ANN 96] Steve M ANN. smart clothing : Wearable multimedia computing and personal imaging to
restore the technological balance between people and their environments . Dans Proceedings of the Fourth
ACM Multimedia Conference (MULTIMEDIA96), pages 163174, New York, NY, USA, novembre 1996.
ACM Press.
[M ARSAN et al. 95] M. Ajmone M ARSAN, G. BALBO, G. C ONTE, S. D ONATELLI, et G. F RANCESCHINIS.
Modelling with Generalized Stochastic Petri Nets. Wiley Series in Parallel Computing. John Wiley and Sons,
1995. ISBN 471 93059 8.
[M AXIMILIEN et al. 01] Michael M AXIMILIEN, Boyd D IMMOCK, Dan S TREETMAN, Brian W EISCHEDEL,
Paul K LISSNER, Sunil D USANKAR, Ron K LEINMAN, Harry M C K INLAY, W INCOR -N IXDORF, Peter
D UELLINGS, Roger L INDSJ, Steve T URNER, Paul G AY, et Boris DAINSON. Java API for USB (javax.usb), JSR-80 specication v0.9.0 . avril 2001. http://javax-usb.org/.
[M C C ORMACK & A SENTE 88] Joel M C C ORMACK et Paul A SENTE. Using the X toolkit or how to write
a widget . Dans Proceedings of the USENIX Summer Conference, pages 114, Berkeley, CA, USA, juin
1988. USENIX Association.
[M C DANIEL & M YERS 98] Richard G. M C DANIEL et Brad A. M YERS. Building applications using only
demonstration . Dans Proceedings of the 3rd international conference on Intelligent user interfaces, pages
109116, 1998.
[M EALY 55] George H. M EALY. A method for synthesizing sequential circuits . Bell System Technical
Journal, 34(5) :10451079, 1955.
243
BIBLIOGRAPHIE
[M ERTZ et al. 00] C. M ERTZ, J.L. V INOT, et D. E TIENNE. Entre interaction directe et reconnaissance
dcriture : les gestes cologiques . Dans ERGO-IHM 2000, pages 170177, Biarritz, France, octobre
2000. CRT ILS & ESTIA.
[M ICRODS 02] Syberia . Microds, 2002. http://www.microids.com,http://www.syberia.info/.
[M ICROSOFT 03 A ] DirectInput C/C++ reference .
microsoft.com/.
Microsoft Corporation, 2003.
http://msdn.
[M ICROSOFT 03 B ] Transcriber .
Microsoft Corporation, 2003.
http://www.microsoft.com/
windowsmobile/resources/downloads/pocketpc/transcriber.mspx.
[M ILGRAM & K ISHINO 94] P. M ILGRAM et F. K ISHINO. A taxonomy of mixed reality visual displays .
IEICE Transactions on Information Systems, E77-D(12), dec 1994.
[M ODUGNO 93] Francesmary M ODUGNO. PURSUIT : Programming in the user interface . Dans Proceedings of ACM INTERCHI93 Conference on Human Factors in Computing Systems Adjunct Proceedings,
Doctoral Consortium, page 217, 1993.
[M OORE 56] E. F. M OORE. Gedanken-experiments on sequential machines . Rapport Technique, 1956.
[M OZILLA 03] The optimoz project . The Mozilla Organization, 2003. http://optimoz.mozdev.org/.
[M URAKAMI et al. 95] Tamostsu M URAKAMI, Kazuhiko H AYASHI, Kazuhiro O IKAWA, et Naomasa NAKA JIMA . DO-IT : Deformable objects as input tools . Dans Proceedings of ACM CHI95 Conference on
Human Factors in Computing Systems, volume 2 de Interactive Experience, pages 8788, 1995.
[M YERS 90] Brad A. M YERS. A new model for handling input . ACM Transactions on Information
Systems, 8(3) :289320, juillet 1990.
[M YERS 92] Brad A. M YERS. Demonstrational interfaces : A step beyond direct manipulation . Computer,
25(8) :6173, aot 1992.
[M YERS 93] Brad A. M YERS. Why are human-computer interfaces difcult to design and Implement ? .
Rapport Technique CMU-CS-93-183, Carnegie Mellon University, School of Computer Science, juillet
1993. ftp://reports.adm.cs.cmu.edu/usr/anon/1993/CMU-CS-93-183.ps.
[M YERS 96] Brad A. M YERS. The Amulet v2.0 reference manual . Carnegie Mellon University Computer
Science Department, fvrier 1996. http://www.cs.cmu.edu/~amulet.
[M YERS 98 A ] Brad A. M YERS. A brief history of human-computer interaction technology . interactions,
5(2) :4454, 1998.
[M YERS 98 B ] Brad A. M YERS. Scripting graphical applications by demonstration . Dans Proceedings
of ACM CHI 98 Conference on Human Factors in Computing Systems, volume 1 de Software Behind the
Scenes, pages 534541, 1998.
[M YERS & KOSBIE 96] Brad A. M YERS et David S. KOSBIE. Reusable hierarchical command objects .
Dans Michael J. TAUBER, Victoria B ELLOTTI, Robin J EFFRIES, Jock D. M ACKINLAY, et Jakob N IELSEN,
diteurs, Proceedings of the Conference on Human Factors in Computing Systems : Commun Ground, pages
260267, New York, avril 1318 1996. ACM Press.
[M YERS et al. 93] Brad A. M YERS, Richard G. M C DANIEL, et David S. KOSBIE. Marquise : Creating
complete user interfaces by demonstration . Dans Proceedings of ACM INTERCHI93 Conference on
Human Factors in Computing Systems, Demonstration Based Systems, pages 293300, 1993.
244
BIBLIOGRAPHIE
[M YERS et al. 97] Brad A. M YERS, Richard G. M C DANIEL, Robert C. M ILLER, Alan S. F ERRENCY, Andrew
FAULRING, Bruce D. K YLE, Andrew M ICKISH, Alex K LIMOVITSKI, et Patrick D OANE. The Amulet
environment : New models for effective user interface software development . IEEE Transactions on
Software Engineering, 23(6) :347365, juin 1997.
[M YNATT et al. 99] Elizabeth D. M YNATT, W. Keith E DWARDS, Anthony L A M ARCA, et Takeo I GARASHI.
Flatland : New dimensions in ofce whiteboards . Dans Marian G. W ILLIAMS, Mark W. A LTOM, Kate
E HRLICH, et William N EWMAN, diteurs, Proceedings of the Conference on Human Factors in Computing
Systems (CHI-99), pages 346353, New York, mai 1520 1999. ACM Press.
[N G et al. 98] Elizabeth N G, Tim B ELL, et Andy C OCKBURN. Improvements to a pen-based musical input
system . Dans OzCHI98 : The Australian Conference on Computer-Human Interaction, pages 239252.
IEEE Press, nov 1998.
[N IGAY & C OUTAZ 93] Laurence N IGAY et Joelle C OUTAZ. A design space for multimodal systems :
Concurrent processing and data fusion . Dans Proceedings of ACM INTERCHI93 Conference on Human
Factors in Computing Systems, Voices and Faces, pages 172178, 1993.
[N IGAY & C OUTAZ 95] Laurence N IGAY et Joelle C OUTAZ. A generic platform for addressing the multimodal challenge . Dans Proceedings of ACM CHI95 Conference on Human Factors in Computing Systems,
volume 1 de Papers : Multimodal Interfaces, pages 98105, 1995.
[N ORMAN 81] D. A. N ORMAN. Categorization of action slips . Psychological Review, 1(88) :115, 1981.
[N ORMAN 02] Donald A. N ORMAN.
ISBN 0465067107.
The Design of Everyday Things.
Basic Books, sep 2002.
[N ORMAN & D RAPER 86] D. A. N ORMAN et St.W. D RAPER. User Centered System design. Lawrence Earlbaum Assoc., Hillsdale, 1986. ISBN 0-89859-781.
[O PERA 03] Mouse gestures in opera . Opera Software ASA, 2003. http://www.opera.com/features/
mouse/.
[O RR & A BOWD 00] Robert J. O RR et Gregory D. A BOWD. The smart oor : a mechanism for natural user
identication and tracking . Dans CHI 00 extended abstracts on Human factors in computer systems, pages
275276. ACM Press, 2000.
[PALANQUE & BASTIDE 93] Philippe PALANQUE et Rmi BASTIDE. Interactive Cooperative Objects : an
Object-Oriented Formalism Based on Petri Nets for User Interface Design . Dans IEEE / System Man and
Cybernetics 93, pages 274285. Elsevier Science Publisher, octobre 1993.
[PALANQUE & BASTIDE 97] Philippe PALANQUE et Rmi BASTIDE. Synergistic modelling of tasks, users
and systems using formal specication techniques . Interacting with Computers, 9(2) :129153, 1997.
[PALAY et al. 88] Andrew J. PALAY, Wilfred J. H ANSEN, Mark S HERMAN, Maria G. WADLOW, Thomas P.
N EUENDORFFER, Zalman S TERN, Miles BADER, et Thom P ETERS. The Andrew Toolkit an overview . Dans USENIX A SSOCIATION, diteur, EUUG Conference Proceedings, Spring, 1988. London,
England, pages 311 ? ?, Buntingford, Herts, UK, Spring 1988. EUUG.
[PARADIGM 03] Vega prime . Multigen-Paradigm, Inc., 2003. http://www.paradigmsim.com.
[PARAGON 03] Penreader . Paragon Software, 2003. http://www.penreader.com.
[PARTRIDGE et al. 02] Kurt PARTRIDGE, Saurav C HATTERJEE, Vibha S AZAWAL, Gaetano B ORRIELLO, et
Roy WANT. TiltType : accelerometer-supported text entry for very small devices . Dans Proceedings
of the 15th annual ACM symposium on User interface software and technology (UIST-02), pages 201204,
New York, octobre 2730 2002. ACM Press.
245
BIBLIOGRAPHIE
[PATERN & FACONTI 92] F. PATERN et G. FACONTI. On the use of LOTOS to describe graphical interaction . Dans Proceedings of the HCI92 Conference on People and Computers VII, Graphics Design and
Techniques, pages 155173, 1992.
[PATRICK & S ACHS 94] Mark PATRICK et George S ACHS. X11 input extension library specication . X
Consortium Standard, X11R6, avril 1994.
[P EARSON & W EISER 86] Glenn P EARSON et Mark W EISER. Of moles and men : The design of foot
controls for workstations . Dans Proceedings of ACM CHI86 Conference on Human Factors in Computing
Systems, Haptic Techniques, pages 333339, 1986.
[P ERLIN 98] Ken P ERLIN. Quikwriting : Continuous stylus-based text entry . Dans Proceedings of the
ACM Symposium on User Interface Software and Technology, Fast Pen Input, pages 215216, 1998.
[P ETRI 62] C. A. P ETRI. Fundamentals of a theory of asynchronous information ow . Proc. IFIP
Congress, N-H, 1962.
[P FAFF 85] G. E. P FAFF, diteur. User Interface Management Systems : Proceedings of the Seeheim Workshop,
Berlin, 1985. Springer-Verlag. proceedings of the Workshop on User Interface Management Systems, held
in Seeheim, FRG, November 1-3, 1983.
[P IEPER & KOBSA 99] Michael P IEPER et Alfred KOBSA. Talking to the ceiling : an interface for bed-ridden
manually impaired users . Dans CHI 99 extended abstracts on Human factors in computer systems, pages
910. ACM Press, 1999.
[P IPER et al. 02] Ben P IPER, Carlo R ATTI, et Hiroshi I SHII. Illuminating clay : a 3-D tangible interface
for landscape analysis . Dans Loren T ERVEEN, Dennis W IXON, Elizabeth C OMSTOCK, et Angela S ASSE,
diteurs, Proceedings of the CHI 2002 Conference on Human Factors in Computing Systems (CHI-02), pages
[P OLLER & G ARTER 84] M.F. P OLLER et S. K. G ARTER. The effects of modes on text editing by experienced editor users . Human Factors, 26(4) :449462, 1984.
[P OUPYREV et al. 96] Ivan P OUPYREV, Mark B ILLINGHURST, Suzanne W EGHORST, et Tadao I CHIKAWA.
The go-go interaction technique : Non-linear mapping for direct manipulation in VR . Dans Proceedings
of the ACM Symposium on User Interface Software and Technology, Papers : Virtual Reality (TechNote),
pages 7980, 1996.
[P OYNER 96] Rick P OYNER. Wintab interface specication 1.1 : 16- and 32-bit API reference .
LCS/Telegraphics, mai 1996. http://www.pointing.com.
[P REECE et al. 94] Jenny P REECE, Yvonne ROGERS, Helen S HARP, David B ENYON, Simon H OLLAND, et
Tom C AREY. Human-Computer Interaction. Addison-Wesley Publishing, Reading, Mass., 1994. ISBN 0201-62769-8. OCLC 35598754.
[R AISAMO & R IH 96] Roope R AISAMO et Kari-Jouko R IH. A new direct manipulation technique for
aligning objects in drawing programs . Dans Proceedings of the Ninth Annual Symposium on User Interface
Software and Technogy, pages 157164, New York, novembre 68 1996. ACM Press.
[R EITMAYR & S CHMALSTIEG 01] Gerhard R EITMAYR et Dieter S CHMALSTIEG. An open software architecture for virtual reality interaction . Dans Chris S HAW et Wenping WANG, diteurs, Proceedings of the
ACM Symposium on Virtual Reality Software and Technology (VRST-01), pages 4754, New York, novembre
1517 2001. ACM Press.
[R EKIMOTO 96] Jun R EKIMOTO. Tilting operations for small screen interfaces . Dans Proceedings of the
Ninth Annual Symposium on User Interface Software and Technogy, pages 167168, New York, novembre 6
8 1996. ACM Press.
246
BIBLIOGRAPHIE
[R EKIMOTO 02] Jun R EKIMOTO. SmartSkin : an infrastructure for freehand manipulation on interactive
surfaces . Dans Loren T ERVEEN, Dennis W IXON, Elizabeth C OMSTOCK, et Angela S ASSE, diteurs,
Proceedings of the CHI 2002 Conference on Human Factors in Computing Systems (CHI-02), pages 113
[ROOSENDAAL & WARTMANN 03] Ton ROOSENDAAL et Carsten WARTMANN. The Ofcial Blender Gamekit : Interactive 3-D for Artists. No Starch Press, mars 2003. ISBN 1593270046.
[ROUSSEL 02] Nicolas ROUSSEL. Videoworkspace : une bote outils pour lexploration de nouvelles
techniques de gestion de fentres . Dans Proceedings of the 14th French-speaking conference on Humancomputer interaction (Confrence Francophone sur lInteraction Homme-Machine), pages 271274. ACM
Press, 2002.
[S ALBER et al. 99] Daniel S ALBER, Anind K. D EY, et Gregory D. A BOWD. The context toolkit : Aiding
the development of context-enabled applications . Dans Marian G. W ILLIAMS, Mark W. A LTOM, Kate
E HRLICH, et William N EWMAN, diteurs, Proceedings of the Conference on Human Factors in Computing
Systems (CHI-99), pages 434441, New York, mai 1520 1999. ACM Press.
[S ALEM & Z HAI 97] Chris S ALEM et Shumin Z HAI. An isometric tongue pointing device . Dans Proceedings of ACM CHI 97 Conference on Human Factors in Computing Systems, volume 1 de TECHNICAL
NOTES : Input & Output in the Future, pages 538539, 1997.
[S ANTORI 90] Michael S ANTORI. An instrument that isnt really . IEEE Spectrum, 27(8) :3639, aot
1990.
[S CHMUCKER 86] K. S CHMUCKER. MacApp : an application framework . Byte Magazine, 11(8) :189193,
aot 1986.
[S CHWERDTFEGER 00] Richard S. S CHWERDTFEGER. IBM guidelines for writing accessible applications using 100% pure Java . IBM Accessibility Center, aot 2000. http://www-3.ibm.com/able/
guidelines/java/snsjavag.html.
[S CHYN et al. 03] Amlie S CHYN, David NAVARRE, et Philippe PALANQUE. Description formelle dune
technique dinteraction multimodale dans une application de ralit virtuelle immersive . Dans Actes de la
15me confrence francophone dInteraction Homme-Machine (IHM2003), novembre 2528 2003.
[S ENSE 8 03] WorldUp and WorldToolkit : Virtual reality support software . Sense8 Corp, 2003. http:
//www.sense8.com.
[S HNEIDERMAN 83] Ben S HNEIDERMAN. Direct manipulation : A step beyond programming languages .
IEEE Computer, 16(8) :5769, aot 1983.
[S HNEIDERMAN 98] Ben S HNEIDERMAN. Designing the User Interface. Addison Wesley Longman, 3e
dition, 1998.
[S MITH 88] David N. S MITH. Building interfaces interactively . Dans Proceedings of the ACM SIGGRAPH
Symposium on User Interface Software, pages 144151, 1988.
[S ONY 03] Eye toy . Sony Computer Entertainment, Inc., 2003. http://www.eyetoy.com.
[S TARNER & P ENTLAND 95] Thad S TARNER et Alex P ENTLAND. Visual recognition of american sign
language using hidden markov models . Dans International Workshop on Automatic Face and Gesture
Recognition, 1995.
[S TERIADIS & C ONSTANTINOU 03] Constantine E. S TERIADIS et Philip C ONSTANTINOU. Designing
human-computer interfaces for quadriplegic people . ACM Transactions on Computer-Human Interaction,
10(2) :87118, 2003.
247
BIBLIOGRAPHIE
[S TORK & H ENNECKE 96] D.G. S TORK et M.E. H ENNECKE. Speechreading : An overview of image processing, feature extraction, sensory integration and pattern recognition techniques . Dans Proceedings of
the 2nd International Conference on Automatic Face and Gesture Recognition (FG 96), pages xvixxvi.
IEEE, oct 1996.
[S TRAUSS & C AREY 92] Paul S. S TRAUSS et Rikk C AREY. An object-oriented 3D graphics toolkit . volume 26, pages 341349, juillet 1992.
[S UN 98] Java speech API specication v1.0 . Sun Microsystems, Inc., 1998. http://java.sun.com/
products/java-media/speech/.
[S UN 02] The java accessibility API . Sun Microsystems, Inc., 2002. http://www.sun.com/access/.
[TACTEX 03] MWK-02 : True multi-touch pressure sensing pad . Tactex Controls, Inc., 2003. Brevet CA.
2273113. http://www.tactex.com/.
[T YSON R. et al. 90] Henry T YSON R., Hudson S COTT E., et Newell G ARY L.. Integrating gesture and
snapping into a user interface toolkit . Dans Proceedings of the 3rd annual ACM SIGGRAPH symposium
on User interface software and technology, pages 112122. ACM Press, 1990.
[UIMS 92] A metamodel for the runtime architecture of an interactive system . ACM SIGCHI Bulletin,
24(1) :3237, 1992.
[USB/HID 01] Universal Serial Bus (USB) device class denition for Human Interface Devices (HID).
Firmware specication version 1.11 . Rapport Technique, juin 2001. http://www.usb.org/developers/
hidpage/.
[VAN DAM 88] Andries VAN DAM.
22(3) :125220, juillet 1988.
PHIGS+ functional description revision .
Computer Graphics,
[VAN K AMPEN 00] Kurtis J. VAN K AMPEN. The interface between humans and interactive kiosks . Input
Technologies, LLC, 2000. http://www.visi.com/~keefner/pdfs/focus1.pdf.
[V IRTOOLS 01] Virtools dev . Virtools SA, 2001. http://www.virtools.com/.
[WACOM 03] Wacom pentools 3.1 .
pentools/.
Wacom Technology Co, dec 2003.
http://www.wacom.com/
[W EIMER & G ANAPATHY 89] D. W EIMER et S. K. G ANAPATHY. A synthetic visual environment with hand
gesturing and voice input . Dans Proceedings of the SIGCHI conference on Human factors in computing
systems, pages 235240. ACM Press, 1989.
[W EISER 91] Mark W EISER. The computer for the 21st century . Scientic American, pages 95104,
septembre 1991.
[W ERTH & M YERS 93] Andrew J. W ERTH et Brad A. M YERS. Tourmaline : Macrostyles by example .
Dans Stacey A SHLUND, Ken M ULLET, Austin H ENDERSON, Erik H OLLNAGEL, et Ted W HITE, diteurs,
Proceedings of the Conference on Human Factors in computing systems, pages 532532, New York, avril 24
29 1993. ACM Press.
[W ORDS P LUS 03] EZ Keys user manual . Words+, Inc., 2003. http://www.words-plus.com.
[YANG et al. 98] Jie YANG, Rainer S TIEFELHAGEN, Uwe M EIER, et Alex WAIBEL. Visual tracking for
multimodal human computer interaction . Dans Proceedings of the Conference on Human Factors in
Computing Systems (CHI-98) : Making the Impossible Possible, pages 140147, New York, avril 1823
1998. ACM Press.
248
BIBLIOGRAPHIE
[Z ANDEN & M YERS 95] Brad T. Vander Z ANDEN et Brad A. M YERS. Demonstrational and constraintbased techniques for pictorially specifying application objects and boundaries . ACM Transactions on
Computer-Human Interaction, 2(4) :308365, dcembre 1995.
[Z ELEZNIK et al. 91] Robert C. Z ELEZNIK, D. Brookshire C ONNER, Matthias M. W LOKA, Daniel G.
A LIAGA, Nathan T. H UANG, Philip M. H UBBARD, Brian K NEP, Henry K AUFMAN, John F. H UGHES, et
Andries van DAM. An object-oriented framework for the integration of interactive animation techniques .
Computer Graphics, 25(4) :105112, juillet 1991.
[Z HAI 98] Shumin Z HAI. User performance in relation to 3D input device design . Computer Graphics,
32(4) :5054, novembre 1998.
249
U N MODLE D INTERACTION EN ENTRE POUR DES SYSTMES

INTERACTIFS MULTI - DISPOSITIFS HAUTEMENT CONFIGURABLES
Pierre D RAGICEVIC
Doctorat de lUniversit de NANTES
Rsum
Aujourdhui, les applications comme les outils de dveloppement demeurent cbls pour une utilisation exclusive et strotype du clavier et de la souris, et ignorent tout autre paradigme dinteraction.
Bien quavrs, les problmes lis ladaptabilit en entre ont encore fait lobjet de trs peu dtudes.
Dans cette thse, nous proposons un modle bas sur des congurations dentre, o des dispositifs
dentre sont librement connects aux applications travers des adaptateurs, et o la traditionnelle
le dvnements est remplace par un paradigme ot de donnes ractif. Ce modle a donn lieu
la bote outils en entres ICON (Input Congurator), qui permet de construire des applications
interactives entirement congurables en entre, capables dexploiter des dispositifs et des techniques
dinteraction non-standard. Son diteur visuel permet au dveloppeur de crer rapidement des congurations pour des entres appauvries ou enrichies, que les utilisateurs avancs peuvent ensuite adapter
leurs besoins.
Mots-cls : Interaction Homme-Machine, Priphriques dentre, Techniques dinteraction, Adaptabilit, Accessibilit, Interfaces Post-WIMP.
Abstract
Todays applications and tools exclusively rely on mice and keyboards and use them a stereotyped
way, and are still ignoring any other interaction paradigm. Though importance of input adaptability has
been widely recognized, its issues have been very little studied. We propose a new input model based
on input congurations. In this model, input devices are freely connected to applications through
adapters, and traditional event mechanisms have been replaced by a reactive data-ow paradigm.
Using this model, we developed the ICON (Input Congurator) input toolkit, which allows to build
interactive applications that are fully congurable and that can make use of alternative input device and
techniques. With its visual editor, developers can rapidly create by direct manipulation congurations
for impoverished or enriched input. Power users can then customize those congurations to suit their
specic needs.
Keywords : Human-Computer Interaction, Input devices, Interaction techniques, Adaptability,
Accessibility, Post-WIMP interfaces.

Memoire Final

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Memoire Final

Загружено:

Авторское право:

Доступные форматы

U NIVERSIT DE N ANTES

Thse de Doctorat de lUniversit de Nantes

Prsente et soutenue publiquement par

Un modle dinteraction en entre

Professeur, Universit de Nantes

Table des matires

1 Linteraction en entre non standard

Les dispositifs dentre non standard . . . . . . . . . . . . . . . . . . . . . . . . . .

Des dispositifs adapts la tche . . . . . . . . . . . . . . . . . . . . . . . .

Des dispositifs adapts lutilisateur . . . . . . . . . . . . . . . . . . . . . .

Des dispositifs adapts lenvironnement . . . . . . . . . . . . . . . . . . .

Lvolution de lquipement grand public . . . . . . . . . . . . . . . . . . .

Nouveaux paradigmes dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . .

Objectifs et enjeux des interfaces post-WIMP . . . . . . . . . . . . . . . . .

Les outils semi-transparents . . . . . . . . . . . . . . . . . . . . . . . . . .

Linteraction non-standard dans linformatique grand public . . . . . . . . . . . . .

Ncessit dune interaction adaptable . . . . . . . . . . . . . . . . . . . . .

Dnition de ladaptabilit en entre . . . . . . . . . . . . . . . . . . . . . .

Linteraction en entre et son vocabulaire . . . . . . . . . . . . . . . . . . .

Adaptabilit des systmes interactifs actuels . . . . . . . . . . . . . . . . . .

2 Modles et outils pour linteraction en entre

Les modles dinterface de rfrence . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

Les modles dinterface formels . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les systmes de transition . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les interacteurs formels . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles de dispositifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les outils de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les botes outils WIMP avances . . . . . . . . . . . . . . . . . . . . . .

Les botes outils Post-WIMP spcialises . . . . . . . . . . . . . . . . . .

Les diteurs graphiques dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . .

Les paradigmes de programmation visuelle . . . . . . . . . . . . . . . . . .

Les diteurs de simulations interactives . . . . . . . . . . . . . . . . . . . .

Les diteurs de comportements 3D . . . . . . . . . . . . . . . . . . . . . . .

Les modles agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles linguistiques . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Introduction au modle des congurations dentre

Le paradigme des dispositifs en cascade . . . . . . . . . . . . . . . . . . . . . . . .

La mtaphore de la connexion logicielle . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

Les systmes ractifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Systmes ractifs et conversationnels . . . . . . . . . . . . . . . . . . . . .

Pour une gestion ractive de linteraction . . . . . . . . . . . . . . . . . . . 100

Le modle du synchronisme parfait . . . . . . . . . . . . . . . . . . . . . . 100

Les congurations dentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Les notions essentielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Les briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Aperu du modle dexcution . . . . . . . . . . . . . . . . . . . . . . . . . 106

4 La bote outils dentres ICON

Les dispositifs dICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Les dispositifs utilitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Les dispositifs de bote outils graphique . . . . . . . . . . . . . . . . . . . 114

Les dispositifs systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Les dispositifs dapplication . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Programmation avec ICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Initialisation dune conguration . . . . . . . . . . . . . . . . . . . . . . . . 121

Implmentation de nouveaux dispositifs . . . . . . . . . . . . . . . . . . . . 118

Srialisation et descripteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Construction et dition de congurations dentre . . . . . . . . . . . . . . . . . . . 127

Lditeur de congurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Des congurations standard aux congurations hautement interactives . . . . 131