interfaces multimodales : concepts, modèles et architectures...development of multimodal...

THESE

présentée par

Yacine BELLIK

pour l'obtention du titre de DOCTEUR de l'Université de Paris-XISpécialité : INFORMATIQUE

Interfaces multimodales :concepts, modèles et architectures

Date de soutenance : 30 Mai 1995

Composition du jury :

Président :

M. M. Beaudouin-Lafon (LRI, Université Paris-XI)

Rapporteurs :

M. J. Caelen (ICP-INPG, Grenoble)Mme. C. Faure (ENST, Paris)

Examinateurs :

M. D. G. Bouwhuis (IPO, Eindhoven, Pays-Bas)M. Y. Burnod (INSERM-CREARE, Paris)M. J. S. Liénard (LIMSI)M. D. Teil (LIMSI)

Thèse préparée au sein du Laboratoire d'Informatique pour la Mécanique et les Sciences de l'Ingénieur

LIMSI-CNRS

A mes parentsA ma famille

A mes amis...

Je tiens à remercier :

Daniel Teil, responsable du groupe Communication Non Verbale au LIMSI, qui m'aencadré durant ma thèse, qui m'a conseillé, qui a su être à mon écoute et qui a beaucoupoeuvré pour que ce travail aboutisse.

Françoise Néel, responsable du groupe Communication Parlée au LIMSI, pour sesencouragements, son soutien, pour les nombreuses discussions et les multiples échangesfructueux, que ce soit au cours du contrat DRET ou en d'autres occasions, et pour avoirminutieusement relu ce document.

Jean-Sylvain Liénard, Directeur de recherche CNRS au LIMSI, pour son intérêt, sesremarques et qui m'a toujours accordé sa confiance.

Joseph Mariani, Directeur du LIMSI, pour m'avoir accueilli dans son laboratoire etm'avoir offert des conditions idéales pour mener à bien mes recherches.

Jean Caelen, Directeur de recherche CNRS à l'ICP, et Claudie Faure, responsable del'équipe Formes et Interfaces à l'ENST, pour l'enthousiasme qu'ils ont manifesté à l'égard demon travail et pour avoir bien voulu être rapporteurs de cette thèse.

Michel Beaudouin-Lafon, Professeur à l'Université de Paris XI, qui m'a fait découvrir etaimer le domaine de l'interaction Homme-Machine, et pour avoir accepté de présider le jury.

Don Bouwhuis, Professeur, responsable du groupe Cognition et Communication à l'IPO,et Yves Burnod, Directeur de recherche à l'INSERM, pour leur intérêt et pour avoir accepterd'être membres du jury.

Dominique Burger de l'INSERM-CREARE et son équipe avec qui j'ai apprécié detravailler et qui m'a fait découvrir un domaine de recherche et d'application très intéressant ettrès motivant.

Michel Barès de la DRET, Eric Pierre de Sextant-Avionique et son équipe avec qui j'aieu plaisir à collaborer dans le cadre d'un contrat de recherche.

Tous les membres du LIMSI et en particulier Angel, Annelies, David, Driss, Jacques,Guy, Marie-Françoise, Michèle, Mike, Patrick, Pierre, Rachid, Samir, Sophie-Anne, Stéphane,Sylvie, et Thierry, qui ont su créer et entretenir une ambiance de travail très sympathique.

RésuméCette thèse s'inscrit dans le domaine de la communication Homme-Machine et plus spécifiquement dans

celui de la conception et de la réalisation des interfaces multimodales. Les travaux de recherche présentésdécrivent les nouveaux problèmes posés par ce type d'interfaces et proposent des solutions qui sont testées àtravers des réalisations abouties. Le travail est divisé en trois étapes. La première, à caractère exploratoire, décritla conception et la réalisation d'une interface multimodale pour une application de dessin graphique (LIMSI-Draw). Cette première expérimentation permet de révéler des problèmes importants liés aux contraintestechnologiques actuelles, de souligner l'importance du facteur temporel souvent négligé dans les interfacesclassiques et de proposer une méthode efficace pour la fusion des informations. Le modèle d'architecture adoptéest articulé autour d'interpréteurs indépendants et d'un contrôleur de dialogue central utilisant des règles dedécision qui permettent d'assurer une fusion robuste. Cette partie de l'étude se termine par une évaluation avecdes sujets humains d'où sont dégagés des enseignements intéressants sur l'utilisation des modalités. La secondeétape a pour but la conception d'un outil pour la spécification des interactions multimodales. Cet outil, baptiséSPECIMEN, est fondé sur un modèle combinant une spécification par des réseaux de transitions augmentés à unespécification par messages à l'aide d'opérateurs de composition permettant de décrire des actions séquentielleset/ou parallèles. Par ailleurs, l'élaboration d'une méthode de détection de messages répartie à travers des agentsspécialisés permet la définition de mécanismes de fusion généraux. Dans la dernière étape, SPECIMEN estappliqué pour la construction d'une interface multimodale pour non-voyants (MEDITOR). L'objectif visé estdouble : d'une part valider cet outil à travers une réalisation concrète, d'autre part étudier l'apport de lamultimodalité au problème de l'accès aux systèmes informatiques par des utilisateurs non-voyants. Des résultatspréliminaires encourageants sont obtenus et des perspectives prometteuses pour une communication Homme-Machine "intelligente" combinant des modèles d'interaction anthropomorphiques et physiques sont discutées enconclusion.

Mots-clefsCommunication Homme-Machine, Interaction Homme-Machine, Interfaces Multimodales , Interaction

Multimodale, Architectures Logicielles, Outils d'Interfaces, Interfaces Non-Visuelles, Interfaces pour Non-Voyants.

AbstractThis thesis deals with Man-Machine Communication; specifically, it deals with the design and

development of multimodal interfaces. The present work describes the new problems that were induced by theseinterfaces, and proposes solutions which have been tested on, and validated through, concrete applications. Thepresent work is divided into three main phases: an exploratory phase, a specification tool design phase, and a testand validation phase. The first phase, the exploratory phase, describes the design and development of amultimodal interface for a drawing application (LIMSI-Draw). This phase reveals several important problemsrelative to the present technological constraints. In addition, the experimentation highlights the informationfusion problem, and the importance of the temporal factor which is often neglected in classical interfaces. Anefficient method, that resolves the problem of information fusion, is proposed. The adopted architecture model isbuilt around independent interpreters and around a central dialogue controller which uses decision rules to ensurea robust fusion. The multimodal interface is then evaluated by potential users. Some interesting results, regardingthe use of modalities, are subsequently presented. The second step consists in designing a specification tool formultimodal interactions. This tool, SPECIMEN, is based on a model which combines a specification byaugmented transition network with a specification by messages using composition operators. These compositionoperators allow the description of sequential and / or parallel actions. Furthermore, elaborating a messagedetection method, spread through specialised agents, allows the definition of general information fusionmechanisms. In the last phase, SPECIMEN is used to develop a multimodal interface, MEDITOR, for blindusers. MEDITOR's objective is not only to test SPECIMEN, through a concrete application, but also to studyhow multimodality can help resolve the problem of computer access by the blind. Encouraging preliminaryresults have been observed. Finally, promising perspectives for an "intelligent" Man-Machine Communication,combining both anthropomorphical and physical interaction models, are discussed in the conclusion.

Key-wordsMan-Machine Communication, Man-Machine Interaction, Multimodal Interfaces, Multimodal Interaction,

Software Architectures, User Interfaces Tools, Non Visual Interfaces, Blind User Interfaces

Table des matières

Introduction générale ................................................................................................... 1

Chapitre 1. Interfaces Homme-Machine multimodales :état de l'art

1.1. Introduction............................................................................................... 61.2. Définition .................................................................................................. 71.3. Les différents acteurs intervenant autour des interfaces homme-

machine...................................................................................................................... 71.4. Cycle de construction d'une interface........................................................ 8

1.4.2. La phase d'implémentation......................................................... 81.4.3. La phase d'évaluation ................................................................. 81.4.4. La méthode itérative................................................................... 9

1.5. Les modèles d'architecture ........................................................................ 91.5.1. Le modèle de Seeheim ............................................................... 101.5.2. Le modèle MVC......................................................................... 111.5.3. Le modèle PAC .......................................................................... 121.5.4. Le modèle ARCH....................................................................... 14

1.6. Les modèles d'interaction :........................................................................ 17du modèle conversationnel à la réalité virtuelle............................................... 17

1.6.1. La manipulation directe.............................................................. 181.6.2. Les nouveaux modèles d'interaction .......................................... 18

1.7. Interfaces multimodales : Concepts et ...................................................... 19définitions ........................................................................................................ 19

1.7.1. Média.......................................................................................... 191.7.2. Mode .......................................................................................... 201.7.3. Modalité ..................................................................................... 231.7.4. Taxinomie des modalités............................................................ 241.7.5. Multimédia ou Multimodal ? ..................................................... 27

1.8. Les types de multimodalités...................................................................... 291.8.1. Représentation............................................................................ 301.8.2. Relation entre les différents types .............................................. 341.8.3. Utilité de cette classification ...................................................... 35

1.9. Types de coopération entre modalités....................................................... 361.9.1. L'équivalence.............................................................................. 361.9.2. La redondance ............................................................................ 371.9.3. La complémentarité.................................................................... 371.9.4. La spécialisation......................................................................... 371.9.5. Discussion .................................................................................. 39

1.10. Analyse de quelques modalités et des médias......................................... 41associés............................................................................................................. 41

1.10.1. La parole en entrée ................................................................... 411.10.2. La parole en sortie .................................................................... 431.10.3. Le geste manuel........................................................................ 441.10.4. Le regard................................................................................... 46

1.11. La fusion dans les interfaces multimodales ............................................ 471.12. Grammaire multimodale ......................................................................... 491.13. La multimodalité en sortie ...................................................................... 491.14. Le temps dans les interfaces multimodales............................................. 51

1.14.1. Exemples illustratifs................................................................. 511.14.2. La proximité temporelle ........................................................... 531.14.3. Temps de réponse des médias d'interaction ............................. 571.14.4. Coréférences actives et coréférences passives ......................... 59

1.15. Les systèmes existants............................................................................. 611.15.1. ARCHIE................................................................................... 621.15.2. WIP........................................................................................... 631.15.3. TAPAGE .................................................................................. 641.15.4. MATIS ..................................................................................... 661.15.5. L'agenda électronique............................................................... 671.15.6. Autres systèmes........................................................................ 68

1.16. Conclusion .............................................................................................. 71

Chapitre 2. LIMSI-Draw : une première expérience

2.1. Introduction............................................................................................... 742.2. Description de LIMSI-Draw ..................................................................... 74

2.2.1. L'écran de présentation............................................................... 752.2.2. Fonctionnalités générales ........................................................... 772.2.3. Exemples d'interactions multimodales supportées par

LIMSI-Draw .................................................................................................. 782.3. Structure de LIMSI-Draw ......................................................................... 79

2.3.1. Représentation des informations ................................................ 792.3.2. Architecture interne.................................................................... 812.3.3. Fonctionnement du contrôleur de dialogue................................ 852.3.4. Traitement d'un exemple : "mets ça ici"..................................... 92

2.4. Analyse de LIMSI-Draw ........................................................................... 952.4.1. Le type de multimodalité supporté............................................. 952.4.2. Inexistence d'une modalité dominante ....................................... 952.4.3. Stratégie de fusion...................................................................... 962.4.4. Critères de fusion ....................................................................... 962.4.5. Stratégie d'interprétation ............................................................ 972.4.6. Stratégies d'interaction ............................................................... 972.4.7. Utilité des références aux arguments.......................................... 1002.4.8. Traitement des arguments optionnels......................................... 1012.4.9. Traitement des anaphores et des ellipses.................................... 1032.4.10. Exemple comparatif ................................................................. 103

2.5. Evaluation ................................................................................................. 1032.5.1. Description de l'expérience ........................................................ 1042.5.2. Quelques paramètres étudiés ...................................................... 1052.5.3. Conclusion sur l'évaluation ........................................................ 109

2.6. Conclusion ................................................................................................ 110

Chapitre 3. SPECIMEN: un outil pour la spécification desinteractions multimodales

3.1. Introduction............................................................................................... 1123.2. Pourquoi des outils d'interfaces ?.............................................................. 113

3.2.1. Quelques statistiques .................................................................. 1133.2.2. Buts ............................................................................................ 113

3.3. Les différents types d'outils....................................................................... 1163.3.1. Les boîtes à outils ....................................................................... 1163.3.2. Les boîtes à outils génériques..................................................... 1163.3.3. Les squelettes d'application........................................................ 1183.3.4. Les éditeurs de ressources .......................................................... 1183.3.5. Les générateurs d'interfaces........................................................ 1193.3.6. Les UIMS ................................................................................... 120

3.4. Les réseaux de transitions ......................................................................... 1213.4.1. Les grammaires formelles .......................................................... 1223.4.2. Les machines abstraites .............................................................. 1233.4.3. Les réseaux de transitions .......................................................... 123

3.5. choix du modèle........................................................................................ 1273.6. Architecture de SPECIMEN ..................................................................... 128

3.6.1. Les interfaces objet des médias .................................................. 1293.6.2. La file commune des messages d'entrée..................................... 1303.6.3. Les agents de fusion séquentielle (AFS) .................................... 1303.6.4. Les agents de fusion parallèle (AFP).......................................... 1303.6.5. La table d'aiguillage (TA)........................................................... 1313.6.6. Le générateur des messages d'entrée (GME).............................. 1313.6.7. Le contrôleur de dialogue (CD).................................................. 1323.6.8. Le générateur des messages de sortie (GMS)............................. 1323.6.9. Les réseaux de transitions .......................................................... 133

3.7. Structure des réseaux ................................................................................ 1333.7.1. Les arcs de transitions ................................................................ 1333.7.2. Les noeuds.................................................................................. 1343.7.3. Utilité de l'attribut d'état ............................................................. 134

3.8. Les catégories de messages ....................................................................... 1353.8.1. Les messages élémentaires ......................................................... 1353.8.2. Les messages composés ............................................................. 1353.8.3. Le message nul ........................................................................... 1443.8.4. Commutativité et associativité des opérateurs de

composition ................................................................................................... 1453.9. La fusion dans SPECIMEN ...................................................................... 146

3.9.1. Comportement des AFS ............................................................. 1483.9.2. Comportement des AFP ............................................................. 149

3.10. Représentation des messages .................................................................. 1503.11. Représentation des médias ...................................................................... 1533.12. Spécification de l'interaction................................................................... 156

3.12.1. Spécification des arcs ............................................................... 1563.12.2. Spécification des noeuds .......................................................... 1573.12.3. Définition des messages ........................................................... 1583.12.4. Exemple.................................................................................... 1583.12.5. Spécification interactive de l'interaction .................................. 160

3.13. Conclusion .............................................................................................. 161

Chapitre 4. Application aux interfaces non visuelles

4.1. Introduction............................................................................................... 1634.2. Position du problème ................................................................................ 164

4.2.1. Les méthodes classiques d'accès aux interfaces visuelles .......... 1654.2.2. Problèmes posés par les interfaces graphiques........................... 167

4.3. Exemples de systèmes existants................................................................ 1704.3.1. OUTSPOKEN ............................................................................ 1704.3.2. SCREEN-READER ................................................................... 1714.3.3. GUIB .......................................................................................... 1724.3.4. MATHS...................................................................................... 1744.3.5. Discussion .................................................................................. 176

4.4. Description de MEDITOR ........................................................................ 1794.4.1. Introduction ................................................................................ 1794.4.2. Configuration matérielle ............................................................ 1814.4.3. La simulation visuelle ................................................................ 1834.4.4. Structure des documents utilisés dans MEDITOR..................... 1844.4.5. Description de quelques fonctionnalités .................................... 1854.4.6. Exemple comparatif ................................................................... 1914.4.7. Utilisation des modalités ............................................................ 1924.4.8. Problème des attributs ................................................................ 193

4.5. Première évaluation................................................................................... 1934.5.1. Description de l'expérimentation................................................ 1934.5.2. Résultats de l'expérimentation.................................................... 194

4.6. Conclusion ................................................................................................ 196

Conclusion et perspectives........................................................................................... 197Références bibliographiques........................................................................................ 202Annexes ....................................................................................................................... 222

Introduction générale

1


"W. Buxton se plaît à imaginer comment un extraterrestre reconstituerait l'aspectphysique d'un être humain s'il était en présence d'une de nos stations de travail comme seulobjet relatant l'espèce humaine. Il imaginerait probablement un individu doté de deuxmembres, le droit pourvu d'un unique doigt, pour actionner la souris, et le gauche muni d'unecentaine de doigts en cinq rangées pour utiliser le clavier. Son sens tactile seraitpratiquement nul (les claviers ne sont pas sensibles à la pression). L'individu seraitprobablement un cyclope et son sens auditif juste suffisant pour reconnaître un "bip" entre400 et 800 Hz...".

Ce paragraphe extrait de [Beaudouin-Lafon 91] vise à montrer à quel point les interfacesHomme-Machine actuelles sous-exploitent les capacités sensori-motrices de l'être humain.Depuis quelques années déjà, on a donc commencé à se rendre compte que l'être humain,pourtant doté de plusieurs organes d'émission et de réception d'informations, n'exploite pas aumaximum ses potentialités pour communiquer avec la machine. Le dialogue humain est paressence multimodal : l'être humain peut tout aussi bien parler et faire des gestessimultanément, qu'écouter, voir, et sentir au même moment. Notre cerveau est capable aussibien de synchroniser nos gestes et nos paroles, que de fusionner et d'interpréter lesinformations visuelles, auditives, tactiles, olfactives et gustatives que nous percevons de notreenvironnement. L'exploitation de ces capacités dans la communication Homme-Machinedevrait permettre d'apporter plus de rapidité, d'efficacité, et de confort.

Les nouveaux dispositifs de communication Homme-Machine qui ont fait leurapparition ces dernières années (système de reconnaissance et de synthèse de parole, écrans ettablettes tactiles, gants numériques, oculomètres, etc.) ont contribué au lancement desrecherches sur l'interaction multimodale à travers le monde. Cependant, disposer desressources matérielles nécessaires au développement de telles interfaces n'est pas suffisant. Denombreux problèmes se posent non seulement au niveau de la technologie elle-même et desnombreuses contraintes qu'elle induit, mais également au niveau conceptuel et logiciel. Aprèsune première phase de recherche visant surtout à produire des prototypes multimodauxexpérimentaux, une deuxième phase a été entamée. Celle-ci vise à mieux comprendre,classifier et organiser les concepts et les problèmes posés par l'interaction multimodale.


2

Le chapitre 1 de cette thèse sera consacré à un état de l'art sur les interfacesmultimodales. Quelques notions générales relatives aux interfaces Homme-Machine serontrappelées et les principaux modèles d'architecture et d'interaction seront analysés. Puisl'attention sera portée plus particulièrement sur l'interaction multimodale. Après avoir exposénotre contribution à la définition des concepts fondamentaux de la multimodalité, lesprincipaux nouveaux aspects introduits par l'interaction multimodale et les problèmes qu'ellesoulève seront présentés. Ce premier chapitre se terminera par une analyse des principauxsystèmes multimodaux existants.

Dans le second chapitre nous décrirons notre première expérience dans le domaine del'interaction multimodale : LIMSI-Draw. Cet éditeur graphique a été développé dans uneoptique exploratoire. Sa réalisation a coïncidé avec le lancement des recherches en Francedans ce domaine. La stratégie adoptée par le PRC-CHM (Programme de RechercheConcertée-Communication Homme-Machine) était, dans une première phase, de mettre aupoint des démonstrateurs et des prototypes afin de révéler, de manière concrète, les problèmesposés par l'interaction multimodale. Notre plan de travail était en adéquation avec cette ligne.Nous avons choisi comme domaine d'application la manipulation d'objets graphiques, car ilpermet de bien mettre en évidence l'intérêt de la multimodalité.

LIMSI-Draw a été une expérience très enrichissante. Elle a, par exemple, permis demontrer que le temps revêt une grande importance dans ce type d'interfaces car il devient lui-même porteur d'information et influe sur l'interprétation des énoncés. Ainsi, l'exploitation dela dimension temporelle permet d'augmenter la puissance d'expression d'un langage. Cetteapplication a par ailleurs servi de maquette expérimentale pour l'étude des stratégiescognitives mises en oeuvre par des sujets dans l'utilisation d'une station de travailmultimodale. Quelques résultats d'ordre ergonomique ont pu être tirés suite à cetteexpérimentation et sont présentés à la fin de ce second chapitre.

LIMSI-Draw est une application multimodale dans laquelle la fusion des informationsest réalisée à un niveau sémantique, une fois que les événements ont été interprétés eninformations d'un niveau d'abstraction plus élevé. Cette fusion nécessite une interprétation quiest dépendante du domaine de l'application. Chaque changement de domaine d'applicationconduit à la réécriture d'interpréteurs spécifiques capables d'exploiter des connaissancespropres à ce nouveau domaine et ainsi d'effectuer correctement la tâche d'interprétation quileur incombe.


3

Cette contrainte rend difficile la conception d'outils génériques d'aide à la constructiondes interfaces multimodales. Or, les besoins en termes d'outils sont très importants dans ledomaine des interfaces Homme-Machine. D'une part, la méthode de conception itérative quiest suivie pour la construction de ces interfaces et, d'autre part, le désir de rendre cetteconstruction accessible à des utilisateurs non-informaticiens, justifie en grande partie cesbesoins. Si de nombreux outils existent aujourd'hui pour la construction des interfacesgraphiques à manipulation directe, il en est tout autrement pour les interfaces multimodales.

Nous présenterons au chapitre 3 un outil pour la spécification des interactionsmultimodales (SPECIMEN). Dans cet outil, la fusion est réalisée au niveau des événements(plus précisément des messages). La méthode de fusion distribuée que nous avons conçue àcet effet montre qu'il est possible de disposer d'un processus de fusion efficace même sansexploitation de critères sémantiques.

Par ailleurs, les interactions multimodales en exploitant aussi bien des modalitéslangagières (langage parlé, écrit, langue des signes, etc.) que des modalités actionnelles (gesteergotique, désignation optique, etc.), intègrent au sein d'une même interface aussi bien unmodèle d'interaction anthropomorphique qu'un modèle physique. Il devient par conséquentnécessaire de disposer d'outils permettant de construire des interfaces supportantsimultanément ces deux modèles; c'est pourquoi nous avons fondé notre outil sur un modèlehybride pour la représentation des interactions multimodales. Ce modèle combine le modèledes réseaux de transitions augmentés à un modèle de spécification par messages. Il présentel'avantage d'allier l'adéquation des ATNs (Augmented Transitions Networks) pour lareprésentation des structures langagières à la souplesse d'un modèle à événements étendu auxbesoins spécifiques des interactions multimodales.

Le domaine d'application choisie pour valider notre outil est celui des interfaces non-visuelles et dans ce contexte nous avons réalisé l'application MEDITOR, présentée auchapitre 4. Cette application consiste en un éditeur de textes multimodal pour non-voyants. Laréalisation de cette application avait un double objectif. D'une part, il s'agissait de tester lavalidité de SPECIMEN en tant qu'outil d'aide au développement des interfaces multimodales àtravers la réalisation d'une application précise et concrète. D'autre part, il était intéressantd'étudier l'apport de la multimodalité au problème de l'accès aux technologies informatiquespar des utilisateurs non-voyants.


4

MEDITOR a permis de montrer que la multimodalité est une composante importantequi doit être intégrée dans les méthodes d'adaptation des interfaces visuelles aux utilisateursnon-voyants. La définition de nouveaux scénarios d'interaction non visuels multimodaux peutavoir un apport très important pour l'augmentation de l'efficacité, de la convivialité et de lafacilité d'apprentissage et d'utilisation de l'interface non visuelle. Une première évaluation aété réalisée l'année passée et a été très positive. Une évaluation plus importante estactuellement en cours. Le prototype est installé pour l'année scolaire à l'Institut National desJeunes Aveugles (INJA) où il est utilisé par des élèves non-voyants. Une équipe de l'INSERMse charge du suivi de son évaluation. Ce prototype a reçu le second prix du concoursinternational à l'innovation SETAA à Paris, en Novembre 1994.

Cette thèse se terminera par une conclusion sur les champs et les perspectives ouvertspar l'apport de ce travail dans le domaine de l'interaction multimodale.

Chapitre1

Chapitre 1. Interfaces Homme-Machine multimodales : état de l'art

6

Chapitre 1.

Interfaces Homme-Machine multimodales :état de l'art

1.1. INTRODUCTIONDepuis quelques années, les chercheurs ont commencé à se rendre compte que l'être

humain, qui est pourtant doté de plusieurs organes de production et de réceptiond'informations, n'exploitait pas de manière optimale ses potentialités pour communiquer avecune machine. En effet, les moyens de communication humains possèdent une caractéristiqueimportante : il est possible de faire coopérer, c'est à dire d'utiliser simultanément et de manièrecomplémentaire plusieurs modes de communication aussi bien en perception qu'enproduction. L'exploitation de cette possibilité devrait permettre d'apporter plus de rapidité,d'efficacité, et de confort à l'interaction Homme-Machine.

La multimodalité permet de disposer d'interactions intuitives dans la mesure où lacommunication entre humains est elle-même multimodale. Ainsi, dans un sens nous pouvonsparler et faire des gestes simultanément, et dans l'autre nous pouvons écouter, voir, toucher etsentir au même moment. Notre cerveau est capable aussi bien de coordonner nos gestes et nosparoles, que de fusionner les informations provenant de nos différents organes sensoriels. Ilpeut également modifier et adapter en permanence la production de nos gestes et de nosparoles en fonction de notre perception de l'univers extérieur.

L'apparition sur le marché de nouveaux dispositifs d'interaction Homme-Machine(systèmes de reconnaissance et de synthèse de parole, gants numériques, oculomètres, écranstactiles, etc.) a permis de lancer des recherches et de réaliser des expérimentations dans ledomaine de l'interaction multimodale. Cependant, disposer des capacités matériellesnécessaires pour développer des interfaces multimodales n'est pas suffisant. De nombreuxproblèmes restent à résoudre aussi bien au niveau conceptuel, logiciel que matériel.


7

Dans ce chapitre, nous présentons un état de l'art sur les interfaces multimodales. Nouscommencerons par rappeler quelques notions générales relatives aux interfaces Homme-Machine. Nous analyserons les principaux modèles d'architecture et modèles d'interactionexistants, puis nous nous intéresserons à l'interaction multimodale proprement dite. Aprèsavoir défini les concepts de base, nous évoquerons les principaux nouveaux aspects introduitspar la multimodalité et nous clôturerons ce chapitre par une analyse de quelques systèmesmultimodaux existants.

1.2. DEFINITIONOn désigne par le terme Interface Homme-Machine, la partie d'un programme

informatique qui assure la communication d'informations à l'utilisateur et la réceptiond'informations provenant de lui.

1.3. LES DIFFERENTS ACTEURS INTERVENANT AUTOUR DESINTERFACES HOMME-MACHINE

On peut classer les différents acteurs intervenant autour des interfaces Homme-Machineen cinq catégories :

• l'utilisateur final : c'est la personne qui utilise le programme final,• le concepteur: c'est la personne qui conçoit et crée l'interface• le développeur : c'est la personne qui implémente l'interface selon les désirs du

concepteur,• l'évaluateur : en général, il s'agit d'un ergonome qui se charge de l'évaluation de l'interface,• le créateur d'outils : c'est la personne qui crée des outils pour faciliter la construction

(conception, implémentation et évaluation) de l'interface.

Ces catégories ne sont pas exclusives. Il faut plutôt les considérer comme des rôles dontcertains (par exemple conception et développement) peuvent parfois être assumés par uneseule et même personne. Dans d'autres cas de figure, une même catégorie pourra faireintervenir plusieurs personnes.


8

1.4. CYCLE DE CONSTRUCTION D'UNE INTERFACELe cycle de construction d'une interface comprend trois phases (fig. 1) :

EvaluationImplémentation

Conception

Figure 1. Cycle de construction d'une interface

1.4.1. La phase de conceptionLa phase de conception repose en général sur l'analyse des tâches effectuées par

l'utilisateur (ou qu'il aura à effectuer), sur l'identification de ses besoins et sur une bonneconnaissance des contraintes éventuelles humaines, matérielles ou autres (environnement detravail par exemple). Elle consiste à "rationaliser et à organiser les résultats ainsi obtenus pourdécrire la façon dont un utilisateur du système final pourrait se représenter sonfonctionnement" [Beaudouin-Lafon 91]. Une bonne conception repose d'une part sur unebonne conduite des analyses précédentes (ce qui nécessite obligatoirement l'implication del'utilisateur dans ces analyses) et d'autre part sur un bon modèle d'interaction qui doitcomporter des principes d'interaction simples et peu nombreux et qui doit être cohérent.

1.4.2. La phase d'implémentationElle consiste à mettre en oeuvre sur machine les idées dégagées de la phase précédente.

L'utilisation d'outils d'interfaces est recommandée et même nécessaire, car ceux-ci allègent latâche de programmation, réduisent le nombre de "bugs", assurent une certaine cohérence àl'interface en imposant de respecter des guides de style et facilitent la maintenance.

1.4.3. La phase d'évaluationElle consiste à demander à des sujets représentatifs des futurs utilisateurs, d'effectuer un

certain nombre de tâches en utilisant le système interactif développé. Il s'agira ensuited'enregistrer, de classer et d'analyser toutes les données ainsi recueillies afin de tirer desconclusions quant aux imperfections et défauts du système et les améliorations qui devront yêtre apportées. Il est également primordial de prendre en considération les remarques et lessuggestions formulées par les sujets. Cette méthode d'évaluation est en général très coûteuse.Actuellement, avec la croissance exponentielle des réseaux informatiques une nouvelle


9

méthode d'évaluation moins rigoureuse mais avantageuse est apparue. Elle consistesimplement à mettre à la disposition des utilisateurs du monde entier (sur le réseau internet) lelogiciel développé et à demander aux personnes qui vont le tester d'utiliser le courrierélectronique pour signaler aux auteurs les problèmes rencontrés et leur envoyer leursremarques et leurs suggestions. La méthode est simple, rapide et quasiment gratuite.

1.4.4. La méthode itérativeLe cycle de construction de l'interface consiste à effectuer une première phase de

conception puis à implémenter l'interface. Celle-ci sera alors testée auprès des utilisateurs puisdes corrections et des améliorations seront apportées aussi bien au niveau de l'implémentationque des choix de conception. L'interface est alors soumise de nouveau aux tests desutilisateurs et le cycle reprend jusqu'à obtenir une version finale stable, mais qui dans laplupart des cas continuera à évoluer mais de manière beaucoup plus lente. C'est la méthodeitérative de construction des interfaces à laquelle il est difficile de se soustraire en l'absenced'une théorie fondamentale sur l'interaction Homme-Machine.

1.5. LES MODELES D'ARCHITECTURELes modèles d'architecture définissent l'organisation logicielle d'un système interactif.

Le principe de base de tous ces modèles est la séparation entre le noyau fonctionnel quiimplémente les concepts propres à un domaine d'application particulier et l'interface quiprésente ces concepts à l'utilisateur et qui lui permet de les manipuler. Ce principe trèsséduisant, puisque qu'il doit permettre en théorie de modifier l'interface sans affecter le noyaufonctionnel et inversement, est en réalité difficile à concrétiser pour la totalité de l'interface.En pratique et dans la majorité des cas, seule une partie de l'interface est réellement séparée dunoyau fonctionnel.

Un modèle d'architecture permet de structurer un système interactif et ainsi de disposerd'une meilleure modularité. Cette modularité est primordiale, étant donnée la méthodeitérative de construction des interfaces. Elle facilite la réutilisation logicielle des composantsdu système interactif, sa maintenance et son évolution.

Nous présentons ci-dessous les principaux modèles d'architecture logicielle desinterfaces Homme-Machine. Nous décrirons brièvement les modèles de Seeheim, MVC, etPAC, et nous décrirons avec un peu plus de détails le modèle ARCH qui chronologiquementest le dernier modèle apparu.


10

1.5.1. Le modèle de SeeheimEn novembre 1983 eût lieu à Seeheim, en Allemagne, le second workshop [Seeheim 83]

consacré aux UIMS (cf. Chapitre 3). Le modèle d'architecture issu de ce workshop (fig. 2) aété le premier à établir clairement la séparation entre l'interface et le noyau fonctionnel.

NoyauFonctionnel

Contrôleur de Dialogue

Composant de Présentation

Utilisateur

Interface Homme-Machine

Interface dunoyau fonctionnel

Figure 2. Le modèle de Seeheim

L'interface elle-même est constituée de trois composants :

1.5.1.1. Le composant de présentationLe composant de présentation est le composant qui est en contact direct avec les médias1

d'entrée et de sortie. Il se charge d'une part de la production effective des sorties (affichage,production de sons...) à partir des informations qu'il reçoit du contrôleur de dialogue, et d'autrepart, de la réception et du traitement (d'un premier niveau) des événements d'entrée induits parles actions de l'utilisateur pour ensuite transmettre les informations résultantes au contrôleurde dialogue.

1.5.1.2. Le contrôleur de dialogueC'est au sein de ce composant qu'est déterminée la structure du dialogue entre

l'utilisateur et l'application. Le contrôleur de dialogue est responsable du séquencement desopérations au niveau des actions de l'utilisateur et des appels aux fonctions du domaine, etréalise un pont entre les objets concrets de l'interface (composant de présentation) et lesconcepts du domaine (noyau fonctionnel).

1On entend ici par média, dispositif physique ou périphérique. Ce terme sera défini plus en détail plus loin

dans ce chapitre.


11

1.5.1.3. L'interface du noyau fonctionnelCe composant sert de passerelle entre le noyau fonctionnel et le contrôleur de dialogue.

Il ajuste les différences entre les formalismes utilisés par ces deux composants. Il contient engénéral une description des entités du domaine qui sont directement liées à l'interface ainsiqu'une description des procédures du noyau fonctionnel qui peuvent être invoquées par lecontrôleur de dialogue.

Dans la fig. 2, la relation qui lie le composant de présentation à l'interface du noyaufonctionnel montre en fait que la séparation totale entre l'interface et le noyau fonctionnel estdifficile à atteindre. En théorie, toutes les informations en provenance du noyau fonctionnel etdevant être présentées à l'utilisateur doivent être d'abord traitées par le contrôleur de dialogueavant d'être transmises au composant de présentation. En pratique, il s'avère que certainesinformations ne font que transiter par le contrôleur de dialogue sans subir aucun traitement dela part de celui-ci. On constate alors une communication directe entre le composant deprésentation et l'interface du noyau fonctionnel (voir même le noyau fonctionnel lui-même).Ceci est particulièrement vrai pour des opérations d'affichage complexe et/ou exigeant untemps de réponse minimal. Le contrôleur de dialogue se trouve alors court-circuité dans unsouci d'efficacité.

1.5.2. Le modèle MVCLe modèle MVC (Modèle, Vue, Contrôleur) [Krasner 88] [Pinson 88] est un modèle

multi-agents qui est apparu dans le cadre du langage de programmation SmallTalk. Il structureun système interactif en un ensemble d'agents, chaque agent comportant trois facettes(fig. 3) :

le modèle : il définit les fonctionnalités propres au domaine. Il peut consister en unsimple entier (modèle d'un compteur) ou être un objet, instance d'une classe Smalltalk-80beaucoup plus complexe.

la vue : elle correspond à la perception qu'a l'utilisateur du modèle. C'est la partie qui esten contact direct avec les médias de sortie.

le contrôleur : il traite les entrées de l'utilisateur. Il peut envoyer des messages aumodèle pour l'avertir d'une action de l'utilisateur ou directement à la vue pour lui demander demettre à jour une sortie suite à un événement d'entrée.

Le modèle, la vue et le contrôleur communiquent par échange de messages.


12

Vue

Modèle

Contrôleur

Utilisateur

Médiasd'entrée

Médiasde sortie

Figure 3. Le modèle MVC

1.5.3. Le modèle PACLe modèle PAC (Présentation, Abstraction, Contrôle) a été introduit par J. Coutaz

[Coutaz 87] [Coutaz 88]. Il structure l'application interactive de manière récursive sous formed'une hiérarchie d'agents comprenant chacun trois facettes (fig. 4) :

A PC

A PC

A PC

A PC

A PC

Figure 4. Le modèle PAC

Présentation : c'est la partie qui est contact direct avec l'utilisateur. Elle gère aussi bienles sorties que les entrées.

Abstraction : elle définit les compétences sémantiques. Elle implémente les fonctionspropres au domaine de l'application.


13

Contrôle : maintient la consistance entre les entités de la facette abstraction et de lafacette présentation, et gère la communication avec les autres agents.

Le modèle PAC peut donner lieu à différentes interprétations. La hiérarchie entre agentspeut-être considérée, par exemple, comme une échelle d'abstraction. Dans un tel schéma onretrouve à travers l'agent de plus haut niveau, le modèle de Seeheim. La facette contrôle de cetagent représente alors une encapsulation de l'ensemble du contrôle de dialogue dans lesystème interactif, de même que la facette présentation de cet agent définit la présentation detout le système. Une autre interprétation consisterait à considérer les liens entre agentsuniquement comme des relations d'échanges de messages. Dans ce cas la facette présentationde l'agent de plus haut niveau est simplement la facette qui définit la présentation de cet agent.Dans [Coutaz 91a] on trouve une proposition de modèle combinant Seeheim et PAC (modèlePAC-SEEHEIM). Ici PAC est utilisé uniquement pour modéliser le composant contrôleur dedialogue du modèle Seeheim. De la même manière, PAC est utilisé dans le modèle PAC-Amodeus [Nigay 91b] [Nigay 94] pour modéliser le contrôleur de dialogue du modèle ARCH(cf. §. 1.5.4).

La principale différence qui existe entre le modèle PAC et le modèle MVC est que cedernier sépare les entrées (contrôleur) des sorties (vue), alors que PAC les rassemble au seind'un même composant (présentation). MVC a l'avantage d'assurer une plus grandeindépendance des entrées par rapport aux sorties. Il est alors possible de modifier les sortiesd'une interface sans affecter ses entrées et inversement. Cependant, certains types d'interactionde bas niveau peuvent requérir une relation directe et immédiate entre les entrées et les sortieset il peut être alors préférable dans ce cas que les entrées et les sorties soient gérées au sein dumême composant.

Comme tous les modèles multi-agents, PAC se caractérise par une organisationmodulaire, supporte le parallélisme et permet donc de modéliser des dialogues à plusieurs filsd'activité2. Il peut constituer un bon candidat pour la modélisation de systèmes interactifsnécessitant une architecture distribuée (collecticiel). De même que pour MVC, son adéquationpar rapport à l'approche orientée objet facilite son implémentation.

Toutefois, on peut reprocher au modèle PAC son caractère trop général. En l'absenced'une méthode précise de décomposition, l'identification des agents et des rôles qui doiventleur être assignés reste un problème important.

2 En anglais, multithread dialogue.


14

1.5.4. Le modèle ARCHLe modèle ARCH [Arch 92] est issu de réflexions menées lors d'un atelier de travail

consacré aux UIMS (CHI'91 UIMS Tool Developer's). Il a été conçu dans le but de minimiserles effets des évolutions des outils d'interaction sur les systèmes interactifs, et dans un soucide refléter le plus fidèlement possible, les architectures des systèmes interactifs existants.C'est donc un modèle qui se veut proche de la réalité. Cependant, les objectifs visés derrière laconception d'un système interactif étant multiples et parfois contradictoires (optimisation ducode, optimisation de la vitesse, indépendance par rapport aux médias, indépendance parrapport aux outils d'interaction, etc.), il en résulte des modèles d'architectures souventdifférents. D'où l'idée d'un métamodel, à partir duquel différentes instances d'un modèle debase pourront être dérivées. C'est pourquoi le modèle ARCH est accompagné d'unmétamodèle (SLINKY) qui une fois appliqué au modèle ARCH produit une instance concrètereflétant l'architecture d'un système interactif particulier.

1.5.4.1. Les composants du modèle ARCHLe modèle ARCH comprend cinq composants (fig. 5). Le noyau fonctionnel et le

composant d'interaction (généralement une boîte à outils) forment les pieds de l'arche, cardans la plupart des cas ces deux composants existent avant le développement même del'interface et forment ainsi la base de départ.

Objets d'InteractionObjets du Domaine

Objets du Domaine Objets de Présentation

Contrôleur de Dialogue

Adaptateur de Domaine

Composant d'InteractionNoyau Fonctionnel


Figure 5. Les Composants du modèle ARCH


15

Le composant d'interaction : c'est dans ce composant que sont mises en oeuvre lesinteractions physiques avec l'utilisateur, à travers les objets d'interaction d'une boite à outils.C'est le composant qui est en contact direct avec les médias.

Le composant de présentation : c'est un composant intermédiaire entre le composantd'interaction et le contrôleur de dialogue qui permet à ce dernier de manipuler des objetsd'interaction virtuels plutôt que les objets d'interaction d'une boite à outils réelle (composantd'interaction). Ceci facilite le portage des applications d'un système graphique (ayant sa proprebibliothèque d'objets d'interaction) à un autre (par exemple du Macintosh à Windows, deWindows à X-Window etc.).

Le contrôleur de dialogue : il joue le même rôle que dans le modèle de Seeheim.

L'adaptateur du domaine : comme pour le modèle de Seeheim, l'adaptateur du domaineajuste les différences entre les formalismes utilisés par le contrôleur de dialogue et le noyaufonctionnel pour la représentation des objets conceptuels. Par exemple, lorsqu'une erreursémantique intervient au sein du noyau fonctionnel, il se charge de la communiquer aucontrôleur de dialogue dans le formalisme adéquat.

Le noyau fonctionnel : comme pour le modèle de Seeheim, il définit les conceptspropres au domaine de l'application.

1.5.4.2. Les types d'objets circulant entre les différents composants

Les objets du domaine : les objets du domaine sont utilisés par le noyau fonctionnel etpar l'adaptateur de domaine. On peut distinguer deux types d'objets du domaine : ceux quin'ont aucun lien direct avec l'interface, et ceux qui sont reliés à l'interface. Le premier typed'objets est utilisé par le noyau fonctionnel pour mettre en oeuvre les concepts propres audomaine. Quant au second, il est utilisé par l'adaptateur de domaine pour mettre en relationces concepts avec l'interface.

Les objets de présentation : les objets de présentation sont des objets virtuelsd'interaction. Ils véhiculent un concept interactif sans en décrire les détails de mise en oeuvre.Par exemple pour représenter le champ Sexe d'une base de données, on utilisera un objet deprésentation qui permet de réaliser un choix exclusif parmi un ensemble de deux valeurs.


16

Les objets d'interaction : les objets d'interaction constituent la mise en oeuvre dans tousleurs détails des concepts interactifs. En général, il s'agira des objets d'interaction fournis parune boîte à outils particulière. Ils possèdent un style de présentation propre (look and feel) etsont liés de manière concrète à un ou plusieurs médias. Par exemple, à l'objet de présentationprécédent correspondra un ensemble de deux boutons radios, manipulables par une souris. Engénéral, à un objet de présentation pourra correspondre un ou plusieurs objets interactifs.

1.5.4.3. Le métamodel SLINKYLe terme SLINKYTM provient d'un jouet flexible (fig. 6) qui une fois mis en

mouvement voit son centre de gravité se déplacer suite à un changement dans la répartition desa masse.

Figure 6. Le métamodel SLINKY

Cette métaphore est utilisée dans le modèle ARCH pour représenter la modification dela répartition des fonctionnalités à travers les différents composants du modèle, d'une instanceà l'autre (fig. 7). En effet selon les objectifs visés lors de la conception et du développementdu système interactif, on peut constater une migration des fonctionnalités d'un composant versun autre. Par exemple, une fonctionnalité réalisée au sein du contrôleur de dialogue dans unsystème interactif particulier peut dans un autre système être réalisé au sein de l'adaptateur dedomaine. L'importance, en terme de fonctionnalités, des différents composants du modèleARCH varie donc d'une instance à l'autre. Dans des cas limites, on peut même constater ladisparition d'un composant. SLINKY constitue donc une belle métaphore, pour représentercette migration des fonctionnalités entre les différents composants.


17

Contrôleur de dialogue

Adaptateurde domaine

Noyaufonctionnel

Composant de présentation

Composantd'interaction



Noyaufonctionnel





Noyaufonctionnel





Noyaufonctionnel



Figure 7. Différentes instances du modèle ARCH

Le modèle ARCH a repris le modèle de Seeheim et l'a affiné en éclatant le composantde présentation en deux composants : un composant de présentation qui définit des conceptsd'interaction assez abstraits et un composant d'interaction qui implémente ces concepts demanière concrète. Cet éclatement dénote un souci d'instaurer une plus grande portabilité d'unenvironnement graphique particulier à un autre. Par ailleurs, l'utilisation de la métaphore dumétamodèle SLINKY correspond à une tentative de mieux représenter la réalité des systèmesinteractifs actuels. En ce sens, on peut déplorer que le modèle ARCH soit plus un modèle quitente d'expliquer les architectures des systèmes interactifs actuels plutôt qu'un modèleréellement générateur de nouvelles architectures.

1.6. LES MODELES D'INTERACTION :DU MODELE CONVERSATIONNEL A LA REALITE VIRTUELLEUn modèle d'interaction3 définit les principes fondamentaux qui décrivent la manière

dont l'utilisateur interagit avec sa machine. Un des plus anciens modèles utilisés dansl'interaction Homme-Machine restant encore largement répandu de nos jours (bien que lesstations graphiques aient remplacé la majorité des terminaux alphanumériques) est le modèleconversationnel. Dans ce modèle, le système est en perpétuelle attente d'une commande del'utilisateur. Celui-ci la formule en la tapant au clavier. Après une vérification syntaxique, lesystème l'exécute et revient dans un état d'attente pour une nouvelle commande.Eventuellement le système peut indiquer à l'utilisateur une erreur dans la formulation ou lui

3Egalement appelé parfois style d'interaction.


18

demander de fournir des informations supplémentaires. Dans tous les cas, les commandespossèdent une syntaxe rigide que l'utilisateur doit respecter. Les shells d'UNIX (interpréteursde commandes) sont des exemples de programmes utilisant le modèle conversationnel.

1.6.1. La manipulation directeEn 1983, Shneiderman introduisit pour la première fois le terme de manipulation directe

[Shneiderman 83] qui allait produire une révolution dans les interfaces Homme-Machine.Cependant le concept de manipulation directe remontait à quelques années auparavant. En1980, Nelson [Nelson 80] faisait déjà référence au concept de virtualité en la définissantcomme une représentation du monde réel pouvant être manipulée par l'utilisateur. En 1981,Hatfield [Hatfield 81] introduisit le célèbre terme WYSIWYG (What You See Is What YouGet) indiquant que l'état visuel d'un document à l'écran reflétait exactement son état àl'impression. En 1982, Thimbleby [Thimbleby 82] généralisa cette notion à l'état du systèmepar l'intermédiaire du terme WYSIWYHG (What You See Is What You Have Got). C'est en1986, que Hutchins et al. [Hutchins 86], explicitèrent la différence entre ce qu'on peut appeleraujourd'hui le modèle anthropomorphique (ou langagier ou logico-linguistique) et le modèlephysique (ou analogique ou actionnel) [IHM 93]. Dans les interfaces à manipulation directe,l'utilisateur à l'impression d'agir directement sur un monde qui s'apparente à un mondephysique. Plutôt que de communiquer avec un interlocuteur auquel il demande desinformations, ou ordonne d'exécuter des actions, l'utilisateur à l'impression que c'est lui mêmequi agit sur des objets dotés de réactions spécifiques.

La manipulation directe a permis aux interfaces graphiques de connaître un large succèsauprès des utilisateurs. Toutefois, si ses avantages sont certains, il ne faut cependant pasconsidérer la manipulation directe comme étant le modèle idéal de l'interaction Homme-Machine. Un de ses principaux inconvénients est sans doute son incapacité à supporter desréférences descriptives [Buxton 93]. En général, il n'est pas possible (ou difficile) de désignerun objet en décrivant certains de ses attributs de manière à le distinguer des autres objets (parexemple "le rectangle rouge situé au dessus du triangle vert").

1.6.2. Les nouveaux modèles d'interactionDe nouveaux modèles d'interaction sont apparus ces dernières années. La réalité

virtuelle est certainement celui qui a été le plus médiatisé. Elle vise à créer un monde artificiel(en 3D) dans lequel l'utilisateur est immergé grâce à l'utilisation d'un casque de vision 3D,d'écouteurs, d'un dispositif de naviguation et éventuellement d'un dispositif manuel de retourd'effort. Il peut alors explorer cet univers virtuel et agir sur certains de ses objets. Si lesadeptes et les détracteurs de la réalité virtuelle sont déjà nombreux, il est encore difficile de se


19

prononcer sur l'avenir de ce modèle d'interaction considéré par certains comme le modèleultime de l'interaction Homme-Machine. Sans doute, la réalité virtuelle peut-elle apporterbeaucoup dans certains domaines et n'être d'aucune utilité dans d'autres. La réalité augmentée[Mackay 92] est un modèle d'interaction plus récent. Comme son nom l'indique, elle vise àenrichir les objets de l'environnement réel de propriétés supplémentaires et de nouvellescapacités de réaction. Le concept de See-Through tools [Bier 94] (qu'on pourrait traduire paroutils transparents) repose quant à lui sur une interaction exploitant les deux mains del'utilisateur pour une plus grande rapidité dans la réalisation des tâches. Dans les interfacesgraphiques, l'utilisateur dispose souvent d'une palette d'outils. Si les outils sont des opérationsqui s'appliquent sur des opérandes, alors l'idée est de contrôler d'une main les mouvements dela palette à l'aide d'un dispositif de localisation (typiquement une track-ball), afin d'amenerl'outil désiré (opération) sur l'objet (opérande) et d'appliquer alors l'opération sur l'opérandepar l'intermédiaire d'un autre dispositif de pointage (souris) de l'autre main. Ainsi, en un seulclic, l'utilisateur peut sélectionner aussi bien l'opération que l'opérande. L'interaction gestuelleet l'interaction multimodale font aussi partie des nouveaux modèles d'interaction Homme-Machine. Le lecteur trouvera dans le paragraphe §. 1.10.3 plus de détails sur l'interactiongestuelle. La suite de cette thèse sera consacrée à l'interaction multimodale.

Un modèle d'interaction peut-être adapté à une classe d'application particulière et ne pasl'être pour d'autres. Des modèles hybrides capables d'intégrer en leur sein, de manièrecohérente, différents modèles d'interaction nous semblent prometteurs. Nous discuterons plusen détail ce point en conclusion et perspectives.

1.7. INTERFACES MULTIMODALES : CONCEPTS ETDEFINITIONSDans ce paragraphe nous exposons les concepts de base de la multimodalité et passons

en revue quelques définitions importantes. A l'heure actuelle, bien que les concepts soientbien identifiés par la communauté scientifique, il faut cependant souligner l'inexistence d'unconsensus général sur les termes servant à les désigner4.

1.7.1. MédiaSelon le sens commun, un média désigne un procédé technique permettant la

distribution, la diffusion ou la communication des oeuvres de l'esprit, écrites, sonores ouvisuelles. En informatique, il peut être utilisé pour désigner un support d'information

4 Par exemple, le média chez Bernsen [Bernsen 94] correspond au canal chez Frohlich [Frohlich 91], alors

que le média chez Frohlich correspond à la modalité chez Bernsen.


20

(disquette, CD-ROM, etc.) mais également pour identifier le dispositif physique permettant àla machine d'acquérir de l'information (capteur, périphérique d'entrée) ou de la diffuser(effecteur, périphérique de sortie). Pour notre part, c'est dans ce second sens que nousl'utiliserons dans la suite bien que certains auteurs lui donnent un sens très général. Parexemple, pour Blattner [Blattner 90] tout véhicule d'information (physique ou logique5) est unmédia. D'autres auteurs considèrent que tout système permettant de représenter del'information est un média [Frohlich 91]. Dans sa théorie des modalités [Bernsen 94], Bernsenassocie le terme média à des qualités perceptuelles de l'être humain (le visuel ou le graphiquepour la vision, le son pour l'audition et le toucher pour la fonction tactile).

1.7.2. ModeDans le sens commun un mode détermine la manière générale dont un phénomène se

présente ou dont une action se fait. En linguistique il correspond à la manière dont le verbeexprime l'état ou l'action (impératif, subjonctif, etc.). Dans le domaine des interfaces Homme-Machine, le mode correspond à l'état dans lequel se trouve le système interactif à un instantdonné. Cette définition est relative au fait qu'une même action (ou séquence d'actions) peutproduire des résultats différents selon le mode dans lequel se trouve le système[Thimbleby 90]. Il correspond donc au contexte qui détermine l'interprétation6. Dans certainssystèmes graphiques, on peut trouver la notion de boîte de dialogue modale et boîte dedialogue amodale. Une boîte de dialogue modale empêche l'utilisateur d'accéder à toute autrefenêtre tant qu'il n'a pas quitté cette boîte (soit par annulation ou par validation, etc.). Al'inverse, une boîte de dialogue amodale autorise l'utilisateur à basculer vers d'autres fenêtres.Ici, la notion de mode correspond aussi à une notion d'état dans lequel se trouve le système.Cet état est souvent caractérisé par une forte restriction des actions que peut accomplirl'utilisateur. C'est ainsi que Foley et al. définissent le mode : "un mode est un état ou unecollection d'états dans lesquels seul un sous-ensemble de toutes les tâches interactivespossibles sont disponibles" [Foley 90].

Frohlich adopte une définition quelque peu opposée mais qui se rapproche plus de notrepoint de vue. Pour lui, les modes de l'interface sont définis par des états à travers lesquelsdifférentes actions de l'utilisateur peuvent produire les mêmes effets [Frohlich 91]. Parexemple, une même commande peut être réalisée soit à travers une formulation vocalelangagière (prononciation d'une phrase) soit à travers une action physique (clic sur une icône).

5Par exemple, un mail (message électronique) est un média.6L'éditeur de textes VI offre un bon exemple d'utilisation des modes. Pour écrire du texte, il faut être dans

un certain mode et pour naviguer dans le texte il faut être dans un autre mode. On bascule d'un mode vers unautre en utilisant une touche particulière.


21

Ceci correspond pour lui à deux modes différents. La définition de Frohlich correspond en faità une vue utilisateur alors que la définition généralement répandue dans le domaine desinterfaces Homme-Machine correspond à une vue système.

Pour notre part, nous préférons nous positionner du point de vue de l'utilisateur, etdéfinir le concept de mode par rapport à l'être humain. Ceci garantit une plus grande stabilitédans la définition du concept. Nous exposons dans ce qui suit notre définition du terme mode.

Dans une communication entre deux entités (humains, animaux, machines...), le modede communication mis en jeu se rapporte, pour chacune de ces entités, à l'organe (ou ausystème d'organes) utilisé pour percevoir ou produire des informations. Cela nous amène parconséquent à distinguer tout d'abord et pour chaque communiquant, le mode d'entrée du modede sortie.

Pour l'être humain les modes d'entrée et de sortie sont limités en nombre, en fonctiondes organes humains utilisés pour l'émission et la réception d'information. En entrée, il existeplusieurs modes correspondant aux différents organes des organes sensoriels (récepteurs) :

Organes Modes correspondantsyeux visuel

oreille auditifnez olfactif

langue gustatifenveloppe corporelle, couches

musculaires, récepteurs articulatoireset vestibulaires

tactilo-proprio-kinesthésique (TPK)

Le mode tactilo-proprio-kinesthésique (TPK) correspond aux organes qui permettent depercevoir la température, la pression, la surface des objets, leur consistance, leur forme, maiségalement leur poids, leurs structures articulatoires et leur mouvement [Cadoz 94].

En sortie, on peut identifier deux modes :

Organes Modes correspondantssystème vocal oral

système musculaire actionnel ou gestuel

Le mode oral correspond aux différents organes (poumons, cordes vocales, langue,lèvres...) qui interviennent dans la production de sons (parole, bruits, sifflements etc.).


22

Le mode actionnel ou gestuel correspond aux différents organes qui permettent, parmise en action de tout ou de certaines parties du corps (mains, bras, tête, visage...) detransmettre des informations.

Remarque : le mode sonore désigne les modes oral et/ou auditif.

Pour un sujet non humain (végétal, animal ou machine), il est difficile (voireimpossible) d'établir une liste exhaustive des modes de communication possibles. Enparticulier, pour la machine la liste n'est pas figée et évolue avec l'apparition de nouveauxmédias.

C'est pourquoi, lors d'un échange d'informations entre un homme et une machine, nousferons par convention référence aux modes de communication relatifs à l'être humain et non àceux qui pourraient être dévolus à la machine. Par exemple, lorsque l'utilisateur fait un gestepour transmettre une information à la machine, le mode utilisé sera dit gestuel, quel que soit lemédia utilisé par la machine pour capter l'information (caméra ou gant numérique).

Etant donnés deux sujets humains, lorsqu'un des sujets produit une information à traversun mode X, quels sont les différents modes possibles à travers lesquels le deuxième sujet peutpercevoir cette information ? Le tableau suivant fournit la réponse à cette question.

Visuel Auditif Olfactif Gustatif TPKOral Non Oui Non Non Non

Gestuel Oui Non Non Non Oui

La dernière case (Gestuel, TPK) peut paraître étrange. Elle correspond en fait à des caslimites de personnes sourdes et aveugles, et qui pour pouvoir communiquer avec l'extérieur,palpent avec leurs mains, celles de leur interlocuteur pour percevoir les gestes qu'il accomplit.

Les deux tableaux suivants présentent une analyse similaire mais cette fois-ci pour unecommunication entre l'homme et la machine. Le premier tableau correspond à unecommunication de l'homme vers la machine, le second de la machine vers l'homme. Pour lamachine, nous indiquons différents médias actuellement disponibles sur le marché.


23

Homme vers machine

clavier, souris, track-ball,joystick, stylo, écran tactile,

gant numérique, caméra,oculomètre

Système dereconnaissance vocale

Oral Non OuiGestuel Oui Non

On peut remarquer pour le mode gestuel, que la caméra permet en théorie d'exploiter lesgestes de toutes les parties du corps. L'oculomètre permet de capter les "gestes" de l'oeil. Tousles autres médias se basent sur les gestes de la main.

Machine vers homme

Visuel Auditif Olfactif Gustatif TPKEcrans 2D et 3D Oui Non Non Non NonAfficheur Braille Oui Non Non Non Oui

Systèmes de synthèseet/ou de restitution de

sons (parole, bruit,musique...)

Non Oui Non Non Non

Systèmes avec retourtactile et/ou retour

d'effortNon Non Non Non Oui

La case (Afficheur Braille, Visuel) correspond aux cas de certaines personnes qui lisentle braille de manière visuelle (dans certaines écoles pour non-voyants, des enseignants voyantscorrigent les copies en braille de leurs élèves en les lisant de manière visuelle plutôt quetactile).

1.7.3. ModalitéDans le sens commun, la modalité désigne une condition, une particularité qui

accompagne un fait (modalités de paiement par exemple). En linguistique elle est plus globaleque le mode. Elle exprime les diverses manières dont un contenu est envisagé (modegrammatical, intonation, etc.). En psychologie, elle est liée aux catégories sensorielles de l'êtrehumain. Dans le modèle du processeur humain [Card 83] [Barnard 87], la modalité désigne unprocessus spécialisé. Bernsen, quant à lui, la définit comme étant un système représentationneld'information [Bernsen 94].


24

Pour notre part, et en nous positionnant toujours du coté de l'être humain, nousconsidérerons que la modalité de communication est définie par la structure des informationséchangées, telle qu'elle est perçue par l'être humain.

Lorsque l'échange d'information se fait de la machine vers l'homme, la modalité utiliséeest déterminée par la structure que perçoit l'être humain et non pas la structure utilisée par lamachine pour représenter l'information. En effet, l'information peut être structurée à l'intérieurde la machine de différentes manières alors que la structure perçue par l'être humain peut êtrela même. Par exemple, un texte affiché à l'écran sera toujours perçu par l'utilisateur commeune structure textuelle, quelle que soit la structure utilisée par la machine pour produire cetteinformation (structure de caractères ASCII ou image, c'est à dire structure de pixels).

Lorsque l'échange à lieu de l'homme vers la machine, la modalité utilisée est déterminéepar la structure des informations telle qu'elle serait perçue par un deuxième être humain(imaginaire) observant l'échange. Ici également, l'information produite par l'utilisateur peutêtre structurée à l'intérieur de la machine de différentes manières, bien que la structure perçuepar le sujet observateur soit la même.

1.7.4. Taxinomie des modalitésLa modalité étant définie par la structure des informations, il devient alors possible

d'établir une taxinomie des modalités, en fonction des types de structures d'information et descaractéristiques qui en découlent.

Tout le problème réside dans l'identification de critères pertinents qui permettent dedéfinir une typologie des structures d'information intervenant dans la communication Homme-Machine. Il est intéressant de souligner ici les travaux de Bernsen [Bernsen 93] [Bernsen 94]dans ce domaine. Celui-ci propose de classifier les modalités de sortie (par rapport à lamachine) en les rattachant à des modalités de base appelées modalités pures. Une modalitéparticulière hérite alors des caractéristiques de la modalité pure à laquelle elle est rattachée etpeut de plus posséder des caractéristiques plus spécialisées qui la différencient des autresmodalités de la même famille. Les modalités pures sont classées en fonction de 5 critères. Lesquatre premiers définissent le profil de la modalité, constitué de ses caractéristiques de base.Le dernier correspond au média d'expression (ce qui se rapproche en fait du mode dans notredéfinition).


25

Langagière / Non LangagièreIndique si la modalité utilisée repose ou non sur la préexistence d'un lexique plus ou

moins important, d'une syntaxe plus ou moins complexe et sur des représentationssémantiques et pragmatiques.

Analogique / Non AnalogiqueUne modalité analogique véhicule des informations qui tire leurs représentations de

l'entité signifiée (représentation iconique ou isomorphique). Une modalité analogique véhiculedes informations plus riches et donc plus précises par rapport à une modalité non analogique(par exemple il existe plus de détails dans une photographie que dans le discours linguistiquequi pourrait la décrire). Cependant, cette richesse implique une absence de focus, c'est à dired'un point d'intérêt particulier dans l'information.

Arbitraire / Non ArbitraireUne modalité non arbitraire repose sur la préexistence d'un système de représentations

sémantiques connu par les utilisateurs. Une modalité arbitraire nécessite en générall'apprentissage des conventions de représentation utilisées pour un contexte donné.

Statique / DynamiqueCe critère indique si le temps intervient explicitement dans la structure des informations

ou pas.

Média d'expressionBernsen cite trois médias d'expression : graphique, sonore et tactile

On peut tout d'abord remarquer une incompatibilité entre notre définition du termemédia et ce qu'entend Bernsen par ce terme. Le sens qu'il lui affecte se rapproche plus de notredéfinition du mode que du média, bien que le qualificatif graphique s'applique plus auxstructures d'informations (et donc aux modalités) qu'aux modes. En effet, une structuregraphique peut tout aussi bien être perçue à travers le mode visuel que le mode tactile (il suffitde l'imprimer avec une imprimante et un papier spécial pour obtenir une structure en relief).

Deuxièmement, on peut constater que le dernier critère ne se situe pas au même niveauque les quatre premiers. Ceci a d'ailleurs pour conséquence l'élimination d'un grand nombre decombinaisons. Par exemple, la structure des informations exprimées à travers le mode sonoreest toujours dynamique. C'est pourquoi, au lieu d'obtenir 48 (2x2x2x2x3) modalités pures, iln'en obtient que 28 possibles.


26

Troisièmement on peut noter que certains critères sont incompatibles. Par exemple, unemodalité analogique n'est jamais arbitraire, puisqu'elle tire sa représentation de l'entitéreprésentée.

Enfin, on peut reprocher à certains critères d'avoir uniquement deux valeurs discrètes.Par exemple certaines modalités telles que la musique sont difficilement positionnables parrapport au critère langagière/non langagière et il est clair que le morse ou les langages decommandes simplifiés ne se situent pas au même niveau, par rapport à ce critère, que lelangage naturel. Le critère Langagière/Non Langagière doit, par conséquent, être considérécomme un critère à valeurs continues plutôt que comme un paramètre binaire, vu la grandediversité des valeurs qu'il peut prendre (code Morse, langage de programmation non évolué,langage de programmation évolué, langage de commande, langage MATIF7, langue dessignes, langue naturelle parlée, langue naturelle écrite...).

C'est pourquoi, nous préférons classer les modalités dans un espace multidimensionnel,dans lequel chaque dimension représente un critère donné. Certaines dimensions pouvant êtrecontinues et d'autres discrètes. De plus, chaque espace multidimensionnel est relatif à unmode de communication particulier (modes d'entrée compris) car certains critères peuvent êtrepertinents par rapport à un mode donné et n'avoir aucun sens pour un autre mode. Cecin'empêche pas l'existence de critères similaires par rapport à différents modes. Ceci signifieraen fait, que certaines structures et donc certaines modalités peuvent être associées à différentsmodes. Par exemple, une structure telle que le braille peut être perçue aussi bien à travers lemode TPK qu'à travers le mode visuel. De même une structure textuelle peut être perçue àtravers les modes visuels, auditifs et TPK. Chaque axe de l'espace représente un critère donnéet peut donc être continu ou à valeurs discrètes.

Critèretemporel

Critèrespatial

CritèreLangagier

Critèred'analogie

Critère deprosodie

Mode visuel x x x xMode auditif x x x x

Mode oral x xMode gestuel x x xMode TPK x x x

7MATIF est le langage gestuel utilisé dans les établissements boursiers.


27

Le critère temporel indique pour les modes visuel et TPK8, l'existence d'opérationsd'animation telles que le clignotement, les changements de couleur, les déplacements, lesrotations, les déformations etc. Pour le mode gestuel, il sert à différencier les gestes statiquesdes gestes dynamiques. Dans une structure statique, seule la configuration finale d'unecertaine partie du corps est pertinente. Dans une structure dynamique toutes les configurationsintermédiaires (déplacement compris) sont prises en comptes et influent sur l'interprétationsémantique de l'information.

Le critère spatial indique pour le mode visuel si la visualisation se fait en 2D , enprojection 3D ou en 3D virtuel. Pour le mode auditif, il indique si le son perçu est en mono,stéréo, ou en 3D. Enfin, pour le mode gestuel, il indique s'il s'agit de gestes 1D (appui destouches du clavier par exemple), 2D (déplacement de souris, ou dessin au stylo) ou 3D.

Le critère langagier est défini pour tous les modes. C'est un critère à valeurs continues.Le critère d'analogie indique pour le mode visuel, le degré de ressemblance de la

représentation par rapport à ce qui est représenté. Il permet de faire la distinction entre unephoto, une peinture, une image de synthèse, un graphique etc. Pour le mode auditif, il permetpar exemple, de distinguer les sons enregistrés et restitués des sons synthétisés.

Le critère de prosodie concerne les modes auditif et oral uniquement. Il indiquel'importance des attributs prosodiques sur la structure utilisée. Il permet par exemple dedistinguer le chant de la parole, différents styles de voix (voix criée, chuchotée, etc.)...

1.7.5. Multimédia ou Multimodal ?La distinction entre multimédia et multimodal a été explicitée par J. Coutaz

[Coutaz 91b] [Coutaz 92]. Un système multimédia est un système capable d'acquérir, destocker et de restituer des informations de nature différente (texte, images, sons, séquencesvidéo...). Il dispose pour cela de dispositifs physiques adaptés (carte sonore, carte d'acquisitionvidéo,...). Il faut cependant faire remarquer qu'actuellement, un système ne disposant pas delecteur de CD-ROM n'est pas considéré comme un système multimédia à part entière. Eneffet, même s'il dispose des capacités lui permettant d'effectuer les opérations d'acquisition etde restitution, il ne dispose pas des capacités lui permettant réellement d'exploiter desapplications multimédias. Etant donné la nature des informations manipulées, ces applicationsrequièrent de grandes capacités de stockage que seul le CD-ROM peut offrir à l'heure actuelle.La caractéristique principale d'un système multimédia par rapport à un système multimodalréside dans le fait que les informations manipulées dans un système multimédia ne subissent

8Pour le mode TPK, les opérations d'animation sont naturellement moins riches (souvent réduites au

clignotement) que pour le mode visuel.


28

aucun traitement d'analyse, de reconnaissance ou d'interprétation. L'information manipuléeconstitue donc l'objet même de la tâche.

Un système multimodal doit également posséder des capacités lui permettant d'acquérir,de stocker et de restituer des informations de nature différente, cependant cette exigence peutêtre ici moins forte en comparaison avec un véritable système multimédia. Par, exemple descapacités de synthèse musicale (synthèse MIDI9) ne sont pas du tout nécessaires dans unsystème multimodal (alors qu'il n'existe pas de système multimédia ne possédant pas de tellescapacités). De même, un lecteur de CD-ROM n'est pas non plus indispensable. Toutefois cecin'est pas la différence majeure entre les deux types de systèmes. Celle-ci réside en fait dans letraitement que subissent les informations échangées entre l'utilisateur et le système, et le rôlequ'elles remplissent.

En se rapportant à l'espace MSM (Multi-Sensori-Moteur) [Nigay 93a] [Coutaz 93c][Nigay 94] Nigay donne une définition vague des termes multimédia et multimodal : unsystème est multimodal en entrée (respectivement en sortie) s'il dispose d'au moins deuxcanaux d'entrée (respectivement de sortie) dont la fonction d'interprétation possède un fortpouvoir d'abstraction. La question qui se pose ici est évidemment de savoir à partir de quelpoint doit-on ou peut-on considérer qu'une fonction d'interprétation possède un fort pouvoird'abstraction.

Dans un système multimodal, les informations émises par l'utilisateur (entrée) sontd'abord acquises par le système, puis analysées, reconnues et interprétées. Ici le système nestocke pas l'information brute (par exemple le signal acoustique correspondant à la phraseprononcée par l'utilisateur). Seule l'interprétation résultante10 est mémorisée. Ce qui expliquela non-nécessité de disposer de capacités de stockage importantes. Cette capacitéd'interprétation et de compréhension des informations constitue donc une différence majeureentre les systèmes multimédia et multimodal. En sortie, un système multimodal doit aussiposséder des capacités multimédia et notamment des capacités de synchronisation temporelleentre différentes informations de nature différente et pouvant être produites simultanément(son et images par exemple). Mais de plus, et c'est là un aspect que nous développerons unpeu plus loin dans ce chapitre, il doit être doté de capacités intelligentes11 qui vont luipermettre de déterminer de manière dynamique, la forme de présentation la plus adéquatepour communiquer une information donnée à l'utilisateur à un instant donné. Cette forme de

9MIDI est l'abréviation de Musical Instrument Digital Interface.10Complétée de certaines informations temporelles, origine de l'information, etc.11Certains auteurs anglo-saxons [Neal 90] désignent le multimodal par multimédia intelligent.


29

présentation adéquate va bien sûr dépendre de nombreux paramètres déterminant le contexteglobal, qui sont liés à l'environnement, à l'utilisateur, à la tâche etc.

Finalement, si l'information dans un système multimédia est l'objet de la tâche, elle sertau contraire à contrôler la tâche dans un système multimodal [Azémard 95].

1.8. LES TYPES DE MULTIMODALITESLes types de multimodalité désignent la manière dont l'utilisateur (entrée) ou la machine

(sortie) peut "s'exprimer", et ce d'un point de vue "système". La première classification a étéintroduite par J. Caelen lors des troisièmes journées sur l'ingénierie des interfaces Homme-Machine [IHM 91]. Cette classification repose sur deux critères : l'usage des médias et l'usagedes modes (fig. 8).

Alterné

Exclusif

Synergique

Concurrent

Usage des médias

Usage des modes(interprétation/génération)

Séquentiel Parallèle

Indépendant

Combiné

Figure 8. Les différents types de multimodalité

Cette classification nous a paru quelque peu imprécise. Par exemple, ici la notion demode n'est pas très claire. Et l'on ne voit pas très bien la distinction entre parallélisme dansl'utilisation des médias et parallélisme dans l'expression des énoncés. En effet, il peut y avoirparallélisme dans l'expression des énoncés sans qu'il y ait pour autant parallélisme dansl'usage des médias. C'est pourquoi nous avons affiné et complété cette classification enprécisant ces critères et en distinguant trois paramètres :

Production des énoncés : indique si les énoncés (en entrée ou en sortie) doivent êtreproduits séquentiellement, ou s'il est possible que plusieurs énoncés indépendants soientproduits en parallèle.


30

L'usage des médias : indique si l'usage des médias doit être exclusif, c'est à dire qu'à uninstant donné un seul média peut être utilisé, ou si au contraire, il est possible d'en utiliserplusieurs simultanément.

Le nombre de média par énoncé : indique si lors de la production d'un énoncé, il faututiliser un seul média, ou s'il est possible d'en utiliser plusieurs. Dans ce dernier cas, en entrée,il est nécessaire de procéder à la fusion des différentes informations provenant des différentsmédias.

1.8.1. ReprésentationCes trois paramètres devraient nous définir huit types de multimodalités. Cependant, il

existe une combinaison qui ne peut être produite. En effet, on ne peut avoir d'usage simultanédes médias, si la production des énoncés doit être séquentielle avec utilisation d'un seul médiapar énoncé. Nous pouvons représenter ces types par les sommets d'un cube dans un espace 3D(fig. 9).

Nous pouvons remarquer que les quatre sommets qui définissent la face supérieurenécessitent la fusion. De même, les quatre sommets qui définissent la face latérale droitecorrespondent aux différents types de multimodalités parallèles. En fait, les deux sommetspostérieurs de cette face correspondent à des cas de dialogue à plusieurs fils (multithreaddialogue [Tanner 86]) et les deux sommets antérieurs à des cas de dialogue concurrents(concurrent dialogue [Hartson 89]).


31

Y

Exclusif

Parallèle

Un

Plusieurs

des énoncésProduction

Nombre de médias par énoncé

X

Z

Simultané

Séquentielle

Usage des médias

SYNERGIQUE

ALTERNEE SYNERGIQUE PARALLELE

ALTERNEE PARALLELE

EXCLUSIVEPARALLELE

PARALLELESIMULTANEEEXCLUSIVE

IMPOSSIBLE

Figure 9. Les différents types de multimodalité

1.8.1.1. La multimodalité exclusivePour ce type de multimodalité, la production des énoncés doit être séquentielle, et un

énoncé doit être exprimé entièrement à travers un seul média. Un exemple est fourni dans lafig. 10.

Médias

TEMPS

S.R.Parole

Souris

Click menu (EFFACE)

Click(OBJET)

"efface le cercle rouge"

Enoncé 1 Enoncé 2

Figure 10. Exemple de multimodalité exclusive


32

1.8.1.2. La multimodalité alternéePour ce type de multimodalité, la production des énoncés doit être séquentielle, avec la

possibilité d'utiliser plusieurs médias alternativement dans un énoncé. La fig. 11 illustre cetype de multimodalité.

Médias

TEMPS

S.R.Parole

Souris

Click(OBJET)

"ici""mets ça" Click(POSITION)

Figure 11. Exemple de multimodalité alternée

1.8.1.3. La multimodalité synergiqueComme pour le type précédent, il est possible d'utiliser plusieurs médias dans un

énoncé, mais cette fois ils peuvent être utilisés simultanément (fig. 12). C'est le type demultimodalité le plus répandu dans les systèmes existants.

Médias

TEMPS

S.R.Parole

Souris Click(OBJET)

"ici""mets ça"

Click(POSITION)

Figure 12. Exemple de multimodalité synergique

Nous abordons maintenant les différents types de multimodalité parallèle. Il y amultimodalité parallèle lorsque deux ou plusieurs énoncés peuvent être produits en parallèle.


33

1.8.1.4. La multimodalité parallèle exclusivePlusieurs énoncés indépendants peuvent être produits en parallèle. Cependant, un

énoncé doit être exprimé entièrement à travers un même média, et à un instant donné, un seulmédia peut être actif (fig. 13).

Médias

TEMPS

S.R.Parole

Souris

"tout""efface"

Click Menu(SAUVEGARDER)

Figure 13. Exemple de multimodalité parallèle exclusive

1.8.1.5. La multimodalité parallèle simultanéeLa différence avec le type précédent réside dans l'usage simultané des médias (fig. 14).

Médias

TEMPS

S.R.Parole

Souris

"efface la ligne rouge"

Click Menu(TRACER LIGNE)

Click (1er POINT)

Click (2eme POINT)

Figure 14. Exemple de multimodalité parallèle simultanée

1.8.1.6. La multimodalité parallèle alternéePour ce type, il est possible d'utiliser plusieurs médias dans un même énoncé.

Cependant, à un instant donné, un seul média peut être utilisé (fig. 15).


34

Médias

TEMPS

S.R.Parole

Souris

Pointage Menu (EFFACER)

Ecr tactile

Click(OBJET) "ici""mets ça"

Click(POSITION)

Pointage(OBJET)

Figure 15. Exemple de multimodalité parallèle alternée

1.8.1.7. La multimodalité parallèle synergiqueC'est le type de multimodalité le plus complexe. Plusieurs énoncés peuvent être produits

en parallèle et plusieurs médias peuvent être utilisés dans un même énoncé simultanément(fig. 16).

Médias

TEMPS

S.R.Parole

Souris

Pointage Menu (EFFACER)

Ecr tactile

Click(OBJET)

"ici""mets ça"

Click(POSITION)

Pointage(OBJET)

Figure 16. Exemple de multimodalité parallèle synergique

1.8.2. Relation entre les différents typesIl existe une relation d'inclusion entre les différents types de multimodalité qui peut être

exprimée de la façon suivante:Soient t1 et t2 deux types de multimodalités et P(e,t) un prédicat tel que :

- e est une production d'énoncés, t un type de multimodalité,- P(e,t) est vrai si et seulement si e est supportée par t.


35

Nous pouvons alors définir la relation d'inclusion entre t1 et t2 par :

t1 C t2 <==> ∀ e / e est une production d'énoncés, P(e,t1) ==> P(e,t2)

Autrement dit, t1 est inclus dans t2 si et seulement si toute production d'énoncéssupportée par t1 est également supportée par t2.

La fig. 17 représente cette relation d'inclusion entre les sept types de multimodalité. Onpeut voir que la multimodalité exclusive est la plus simple, alors que la multimodalitéparallèle synergique est la plus complexe.

TYPES DE MULTIMODALITES

1-Exclusive

2-Alternée

3-Synergique

4-Parallèle exclusive

5-Parallèle simultanée

6-Parallèle alternée

7-Parallèle synergique

Figure 17. Relation d'inclusion des différents types de multimodalités

1.8.3. Utilité de cette classificationUne telle classification permet de juger de la complexité des traitements réalisés dans

une interface multimodale à travers le type de multimodalité qu'elle supporte. La relationd'inclusion décrite ci-dessus permet d'apprécier la complexité relative de chaque type demultimodalité. Cette classification détaille, par rapport à la précédente, les différents types demultimodalités parallèles qui étaient tous englobés sans distinction aucune sous la


36

dénomination de multimodalité concurrente. Il nous semble par exemple, important dedistinguer la multimodalité parallèle exclusive de la multimodalité parallèle synergique car leniveau de complexité des traitements devant être mis en jeu dans l'un et l'autre type ne sontpas du tout du même ordre. Cependant il faut reconnaître que les types de multimodalitésparallèles ne sont pas courants à l'heure actuelle dans les interfaces multimodales. En fait, ilspeuvent se rencontrer surtout dans les cas d'utilisateurs experts, très bien entraînés et habituésà réaliser certaines manipulations en parallèle (pilotage d'avion de chasse par exemple).Néanmoins, ces cas de multimodalités parallèles peuvent aisément se produire dans dessystèmes incluant le collecticiel et le multimodal. En effet, dans ce cas ce sont plusieursutilisateurs qui agissent en même temps dans le cadre d'une tâche collective (coopérative ouconcurrente) chacun d'entre eux pouvant interagir avec le système de manière multimodale.Bien que de tels systèmes n'existent pas encore, il est clair que les types de multimodalitésparallèles seront dans ces cas là très fréquents. On peut par ailleurs remarquer qu'un certainnombre de problèmes posés par la multimodalité parallèle se retrouvent dans le collecticiel.L'exemple suivant tiré d'ICP-Draw [Caelen 91a] [Caelen 91b] [Caelen 91c] illustre bien notrepropos : l'utilisateur prononce la phrase "dessine un carré au dessous du cercle" etsimultanément il déplace avec la souris le cercle servant de repère. Un tel cas peutévidemment facilement se produire dans le cadre du collecticiel.

1.9. TYPES DE COOPERATION ENTRE MODALITESLes types de coopération entre modalités ont été introduits par J. C. Martin [Martin 93]

[Martin 94] durant les cinquièmes journées sur l'ingénierie des interfaces Homme-Machine(IHM'93). Elles ont été par la suite présentées de manière plus formelle dans [Coutaz 94] sousle nom de propriétés CARE (Complémentarité, Assignation, Redondance, Equivalence) dansle cadre du modèle pipe-line [Nigay 94]. Le groupe de travail GT10 du GDR-PRC CHM surla multimodalité leur a donné, quant à lui, le nom de formes de multimodalités. Pour ne pasalimenter ce flot de termes, nous allons utiliser dans la suite le premier terme (types decoopération) introduit par Martin qui a été le premier à mettre en évidence ces notions.Contrairement aux types de multimodalité qui analysent l'interaction multimodale d'un pointde vue système, les types de coopération entre modalités analysent la multimodalité d'un pointde vue plus général et plus proche de l'utilisateur. Elles recouvrent quatre notions :

1.9.1. L'équivalenceLa notion d'équivalence fait référence au fait que l'utilisateur ou la machine peut avoir le

choix entre plusieurs modalités pour formuler un énoncé particulier. Par exemple, en entrée,l'utilisateur peut avoir le choix entre prononcer le nom de la commande qu'il désire exécuterou la désigner sur une barre d'outils en utilisant la souris. En sortie, la machine peut par


37

exemple, avertir l'utilisateur de l'arrivée d'un nouveau mail, soit en émettant un messagesonore, soit en affichant un message visuel.

1.9.2. La redondanceElle consiste à transmettre un même énoncé sur différentes modalités. En principe,

l'analyse d'un énoncé transmis à travers une des modalités est suffisante pour dégager toutesles informations sémantiques véhiculées par cet énoncé sans avoir besoin d'analyser les autresénoncés transmis sur les autres modalités. Cependant, en pratique ceci n'est pas toujours vrai.Par exemple, en sortie, la redondance peut être utilisée pour signaler l'importance ou l'urgenced'un message. Dans ce cas, la redondance fournit donc une information supplémentaire. Enentrée, en reconnaissance de parole par exemple, elle peut être utilisée pour améliorer lesrésultats de la reconnaissance. Le projet AMIBE exploite les informations visuellesconcernant les mouvements labiaux (en plus du signal acoustique) pour améliorer lesperformances du système de reconnaissance [Amibe 94]. La même méthode est utilisée dans[Vo 95].

1.9.3. La complémentaritéLa complémentarité consiste à transmettre différents messages représentant les

constituants d'un même énoncé sur plusieurs modalités. La compréhension de l'énoncénécessite ici une fusion entre les différents messages transmis à travers les différentesmodalités. Par exemple, en entrée, l'utilisateur peut prononcer la phrase "efface ce fichier" touten cliquant avec la souris sur l'icône du fichier en question. L'interprétation de la phrase"efface ce fichier" indique la commande à exécuter mais ne permet pas de connaître l'objet surlequel elle doit s'appliquer. De même, la désignation par la souris permet de connaître l'objetcible mais pas la commande qui doit être appliquée dessus. La compréhension complète del'énoncé nécessite donc la fusion des deux messages. En sortie, la machine peut par exemple(si l'utilisateur désire savoir ce qu'il doit faire pour visualiser un objet en fil de fer), synthétiserun message "cliquez sur ce bouton pour visualiser l'objet en fil de fer" et faire clignotersimultanément le bouton en question. Dans ce cas également, le message sonore seul permetde savoir qu'il existe un bouton qui permet de visualiser l'objet en fil de fer mais ne donneaucune indication sur ce bouton. Le clignotement permet d'attirer l'attention sur un boutonparticulier mais ne précise pas son rôle. La compréhension complète du message nécessite làaussi de la part de l'être humain une fusion des deux messages.

1.9.4. La spécialisationElle consiste à utiliser toujours la même modalité pour un type d'énoncé particulier et à

ne pas l'utiliser pour d'autres types d'énoncés (spécialisation exclusive). Par exemple, en


38

entrée et dans une application graphique de dessin, on peut affecter la parole à l'entrée desnoms des commandes et la souris à l'entrée des paramètres des commandes. En sortie, parexemple dans une application d'édition de textes pour handicapés visuels (cf. Chapitre 4), onpeut décider d'utiliser l'affichage braille uniquement pour la présentation du texte, lesmessages d'erreurs et autres "feed-back" étant communiqués à travers la synthèse de parole.La spécialisation est considérée comme un type de coopération car elle peut faciliter larésolution des problèmes de fusion. Ainsi, un message transmis à travers une modalitéspécialisée ne sera pas candidat à une éventuelle fusion.

Ces définitions révèlent des notions intéressantes, bien qu'on puisse leur reprocher uncertain manque de précision ou de formalisme. Coutaz et Nigay ont affiné ces notions et ontdonné aux définitions une teinte plus formelle. De plus, ces notions sont maintenant définiespar rapport à trois éléments : le dispositif physique, le langage d'interaction et la tâche. Ledispositif physique (artificiel ou biologique) est l'outil d'acquisition ou de production de lasubstance (réalité physique observable) d'une expression [Arnold 94] alors que le langaged'interaction en détermine la structure. Ceci est en concordance avec la terminologie deHejmslev [Hejmslev 47]. La fig. 18 illustre les relations existant entre les dispositifs, leslangages et les tâches.

Plusieurs dispositifs sont:-équivalents-redondants-complémentaires pour

Un dispositif est :-assigné à

une tâche

D

Plusieurs langages sont:-équivalents-redondants-complémentaires pour

un langage

Un langage est :-assigné à

L

Dispositifs Langages Tâches

Figure 18. Les relations CARE entre dispositifs, langages d'interaction et tâches([Coutaz 94])


39

Equivalence de dispositifs : D-Equivalence (D,s,exp,l)Etant donnée un état s du système et une expression exp du langage l, les dispositifs de

D seront dits équivalents pour construire l'expression exp si celle-ci peut être formulée enutilisant n'importe quel dispositif de D.

Assignation de dispositif : D-Assignation (d,s,exp,l)Le dispositif d sera dit assigné à l'expression exp du langage l relativement à l'état s, si

exp ne peut être formulée qu'en utilisant le dispositif d.Complémentarité de dispositif : D-Complémentarité (D,s,exp,l)Les dispositifs d1, d2,..., dn de D seront dits complémentaires dans l'état s pour la

formulation de l'expression exp de l, si exp peut être décomposé en n sous-expressionsexp1,..,expi,..,expn telles que expi est formulée exclusivement au moyen du dispositif di.

Redondance de dispositifs : D-Redondance (D,s,exp,L)Les dispositifs de D seront dits redondants dans l'état s s'ils sont équivalents dans cet

état pour la formulation de exp et s'il peuvent être utilisés simultanément.

Les mêmes notions sont définies pour les langages:

Equivalence de langages : L-Equivalence (L,s,t)Etant donnée un état s du système et une tâche t, les langages de L seront dits

équivalents pour s et t si la tâche t peut être réalisée12 en utilisant n'importe quel langage de L.Assignation de langage : L-Assignation (l,s,t)Le langage l sera dit assigné à t dans l'état s, si t ne peut être réalisée qu'en utilisant le

langage l.Complémentarité de langages : L-Complémentarité (L,s,t)Les langages l1, l2,..., ln de L seront dits complémentaires dans l'état s et pour la tâche t

si l'énoncé exprimé pour réaliser la tâche t peut être décomposé en n sous-expressions exp1,...,expi, ...,expn telles que expi est formulée exclusivement dans le langage li.

Redondance de langages : L-Redondance (L,s,t)Les langages de L seront dits redondants dans l'état s et pour la tâche t s'ils sont

équivalents pour s et t et s'il peuvent être utilisés simultanément13.

1.9.5. DiscussionCoutaz et Nigay ne définissent pas les notions d'équivalence, de redondance, de

complémentarité et d'assignation (ou spécialisation) par rapport aux modalités mais plutôt par

12Dans le texte original, on peut lire "t peut être exprimée" au lieu de "t peut être réalisée". Il est plus juste

de dire "réalisée" car on exprime un énoncé dans le but de réaliser une tâche.13La simultanéïté est ici bien sûr approximative (déterminée par un seuil temporel).


40

rapport, aux dispositifs d'une part, et aux langages d'autre part. De plus, ces notions sontclairement relativisées par rapport à l'état du système, à la tâche au sens de [Balbo 93], (pourles langages) et aux expressions (pour les dispositifs). Ces notions seront dites permanentes sielles sont vérifiées quel que soit l'état du système, et temporaires dans le cas contraire. Ellesseront dites totales si elles sont vérifiées pour toutes les tâches (en ce qui concerne leslangages) ou pour toutes les expressions (dans le cas des dispositifs) et partielle sinon. Cetterelativité est tout à fait pertinente. Par exemple, les modalités, les langages ou les dispositifsne peuvent être considérés comme équivalents de manière globale. L'utilisateur ou la machinepeut effectivement avoir le choix entre plusieurs modalités, langages ou dispositifs pourformuler un énoncé, mais ceci se produit de manière locale c'est à dire à un instant particulier,en fonction d'un contexte particulier et pour un type d'énoncé particulier.

Toutefois on peut regretter que Coutaz et Nigay n'aient pas indiqué de manière plusprécise ce que l'état du système peut englober. L'état du système est effectivement importantmais ces notions doivent également être relativisées par rapport à d'autres paramètres tels quel'état de l'environnement et l'état de l'utilisateur. Par exemple, un bruit ambiant trop importantpeut inhiber une équivalence que l'état courant du système, le type d'expression, et la tâcheauraient pu autoriser.

Par ailleurs la notion d'équivalence peut être considérée à partir de différents points devue. Les définitions données ci-dessus la considèrent uniquement d'un point de vue substitutif.C'est pourquoi le terme substitution a maintenant tendance à remplacer le terme équivalence.L'équivalence telle qu'elle a été définie signifie en fait qu'un élément (modalité, langage oudispositif) peut être substitué à son équivalent, mais l'équivalence peut également êtreconsidérée du point de vue de l'effort physique14 ou cognitif15 que doit produire l'utilisateur,du point de vue du temps de réponse de la machine ou du point de vue du temps nécessaire àla diffusion de l'information16, du point de vue de la fiabilité de la modalité17, etc.

On peut également noter que les notions présentées ci-dessus ne s'appliquent pasforcément à des modalités, des langages ou des dispositifs de manière isolée. Elle peuvent

14Bien qu'une désignation à l'aide de la souris ou à l'aide de l'écran tactile puisse déclencher la même

commande, il est cependant clair que l'effort physique nécessaire à la désignation tactile est plus important quecelui requis par une désignation à travers la souris (étant donné la position verticale de l'écran tactile).

15Le soulignement d'un mot par utilisation d'un raccourci clavier (par exemple SHIFT-CTRL-S) peutnécessiter un effort cognitif plus important que l'utilisation de la parole (prononciation du mot souligné parexemple).

16La description verbale d'une image nécessite plus de temps que son affichage.17Un système de reconnaissance de parole est moins fiable qu'une souris.


41

également concerner des combinaisons de modalités. Ainsi, une modalité peut être substituéepar une combinaison de modalité. Par exemple, dans MEDITOR (cf. Chapitre 4) laprésentation du texte qui dans les logiciels classiques se fait uniquement à travers le modetactile, est faite ici à travers la combinaison des modes tactile et sonore18.

Enfin, Martin a tenté de proposer une méthode de spécification des interfacesmultimodales à partir de ces notions mais cette spécification est cependant assez superficielleet ne montre pas de manière assez précise comment la conception et/ou l'implémentationd'une interface multimodale peuvent se faire en utilisant ces types de coopérations. Coutaz etNigay proposent quant à elles d'utiliser ces notions pour comparer, classer et évaluer lesinterfaces multimodales, mais sans indiquer de méthode précise.

1.10. ANALYSE DE QUELQUES MODALITES ET DES MEDIASASSOCIESNous présentons ci-dessous une analyse de quelques modalités intervenant dans la

communication Homme-Machine multimodale. Les caractéristiques de chaque modalité, sesavantages, ses inconvénients et les contraintes technologiques sous-jacentes à son intégrationdans un système de communication Homme-Machine constitue un des facteurs qui doiventêtre pris en considération dans le processus de conception de l'interface si l'on désire aboutir àdes interfaces multimodales qui soient réellement efficaces et conviviales.

1.10.1. La parole en entréeLa parole est la modalité la plus utilisée dans la communication entre êtres humains.

Elle possède de nombreux avantages. Elle autorise un débit d'informations important (180 à200 mots/minute), plus grand que la frappe au clavier. Elle permet de référencer et d'accéder àdes objets non visibles : contrairement au geste de désignation, il n'est pas nécessaire, enparole, de voir un objet pour pouvoir le désigner. La parole permet de le référencer de manièredescriptive en indiquant des attributs ou des propriétés particulières de l'objet qui permettentde l'identifier. Par exemple, un objet graphique peut être référencer par ses attributs de couleurde forme, de position, etc. Dans les interfaces à manipulation directe, pour accéder à unecommande particulière, il peut être parfois nécessaire de traverser toute une arborescence demenus avant d'y aboutir. Grâce à la parole, il devient possible d'y accéder directement en lanommant. De plus, le remplacement des raccourcis claviers par des mots facilite la

18Lorsque la présentation du texte se fait uniquement à travers le mode tactile, l'utilisateur non voyant est

amené à basculer entre deux modes : un mode dans lequel il peut perçevoir les caractères du texte et un autremode où il peut percevoir les attributs. Dans MEDITOR, les caractères du texte sont présentés à travers le modetactile et les attributs à travers le mode sonore.


42

mémorisation des commandes, car les mots contrairement aux raccourcis claviers possèdentun contenu sémantique. Parler n'occupe ni les mains, ni les yeux. Par conséquent, il estpossible grâce à la parole de communiquer et d'agir en même temps (au sens action sur desobjets réels ou virtuels de l'environnement).

En présence d'autres utilisateurs, ces avantages sont tempérés par les inconvénientssuivants : l'utilisation de la parole pour communiquer avec la machine, ne permet pas d'assurerla confidentialité des informations [Caelen 91d]. De plus, l'utilisation de ce canal peutoccasionner une gêne pour les utilisateurs voisins. Par ailleurs, la parole étant aussi un moyende communication entre humains, et en l'absence de capteurs "intelligents" adéquatspermettant de savoir si l'utilisateur est en train de s'adresser à la machine ou à un interlocuteurvoisin, il faut prévoir un moyen sûr et efficace de basculement d'interlocuteur (interrupteurmicro, fonction clavier, mot particulier, etc.). La machine ne doit pas recevoir ni interpréterdes propos qui ne lui sont pas adressés. Une telle erreur, si elle se produisait, risquerait d'avoirdes conséquences désastreuses. Enfin, il ne faut pas oublier que parler représente une dépensephysique pour l'utilisateur, particulièrement en cas de répétition fréquente des mêmescommandes orales. Il convient donc de varier autant que possible le vocabulaire tout en tenantcompte des contraintes liées au choix et à la taille de celui-ci.

Parler à une machine n'est pas aussi simple que de parler à un être humain. A l'heureactuelle, un certain nombre de contraintes technologiques entrent en jeu. Par exemple, la tailledu vocabulaire est souvent limitée à quelques centaines de mots. Il faut, en outre, accorder uneattention particulière au choix de ce vocabulaire. Des mots trop courts (chiffres, lettresépelées), ou trop proches acoustiquement (rouge, bouge) risquent d'être confondus. Uneséance d'apprentissage reste nécessaire pour les systèmes monolocuteurs. Pour les grandsvocabulaires, elle est longue et fastidieuse (de l'ordre d'une heure, mais elle peut être réduitedans le cas de systèmes adaptatifs). Les conditions dans lesquelles l'apprentissage a été fait(type de micro, distance de la bouche au micro, gain d'entrée, bruit ambiant, etc.) influenténormément sur les performances du système. Il est donc important de conserver les mêmesconditions à l'apprentissage et lors de l'utilisation. La sensibilité des systèmes dereconnaissance au bruit (particulièrement les bruits non stationnaires) peut être une contraintegênante pour une utilisation en milieu non isolé. Contrairement au clavier, à la souris, ou àl'écran tactile, qui ne présentent aucun risque d'erreur (ceci ne voulant pas dire que l'utilisateurne puisse pas se tromper), les systèmes de reconnaissance vocale ne sont pas déterministes etconstituent de ce fait une nouvelle source d'erreurs (outre l'utilisateur). En effet, le taux dereconnaissance n'atteint jamais 100%, même si les conditions idéales sont réunies.


43

L'utilisation d'une syntaxe ou la modélisation adaptée du dialogue permettent cependantd'augmenter sensiblement le taux de reconnaissance.

1.10.2. La parole en sortieL'utilisation de la parole en sortie permet, dans la plupart des cas, d'attirer l'attention de

l'utilisateur de façon plus efficace qu'un affichage visuel. C'est donc le canal le plus adéquatpour transmettre des messages urgents ou importants. Le message sonore possède deuxcaractéristiques importantes : la séquentialité et la non-persistance. La séquentialité impliquel'utilisation de messages courts, et dans le mesure du possible, le remplacement de cesmessages par des bruits significatifs brefs (icônes auditives19). La non-persistance, quant àelle, implique un effort d'attention de la part de l'utilisateur et impose la répétition du messageen cas de mauvaise compréhension de sa part. De même que pour la parole en entrée,l'utilisation de la parole en sortie peut gêner les utilisateurs voisins éventuels, et les conditionsde confidentialité ne peuvent être réunies. L'utilisation d'un casque d'écoute peut constituerune solution acceptable à ces deux problèmes, mais il faut cependant tenir compte du fait quececi risque d'isoler l'utilisateur de son environnement.

L'utilisation de la parole en sortie peut se faire de deux manières différentes: soit parrestitution de parole préenregistrée, soit par synthèse à partir du texte. Dans le cas de larestitution de parole enregistrée, les messages sonores émis sont d'excellente qualité puisqu'ilsproviennent de parole réelle. Cependant, le vocabulaire disponible est limité à celui qui a étéenregistré. De ce fait, il n'est pas possible d'utiliser cette méthode dans les cas ou les messagessonores à émettre ne sont pas connus à l'avance (consultation de journaux, dictionnaires,encyclopédies etc.). De plus la modification ou l'extension du vocabulaire n'est pas simple, caril convient en général de faire appel à la même personne qui a prononcé les premiersmessages.

La synthèse à partir du texte, présente comme principal avantage, celui d'autoriser unvocabulaire illimité. Cependant les systèmes de synthèse sont toujours dépendant de la langue,car chaque langue possède son propre système phonétique et ses propres règles deprononciation. Le manque de naturel (intonation systématique) est flagrant et des problèmesd'intelligibilité peuvent se poser en début d'utilisation, mais disparaissent avec l'habitude. Eneffet, les paramètres prosodiques sont difficilement contrôlables de manière automatique, etne garantissent pas la variabilité présente dans la voix humaine. Ceci peut entraîner unecertaine lassitude chez l'utilisateur au bout de quelques heures d'utilisation.

19Les icônes auditives sont des sons naturels échantillonnés [Gaver 89].


44


45

1.10.3. Le geste manuelLe geste manuel possède trois fonctions principales: une fonction ergotique, une

fonction épistémique, et une fonction sémiotique [Cadoz 93] [Cadoz 94a]. La fonctionergotique correspond à l'utilisation de la main en tant qu'organe d'action sur l'environnement.Ce type de geste, nécessite en général une coordination permanente avec la vision; un retourtactile et un retour d'effort [Brooks 90] sont vivement recommandés. La fonction épistémiquedu geste consiste à utiliser la main en tant qu'organe de perception à travers le toucher. Letoucher, contrairement à la vue ou à l'ouïe, nécessite en général, une activité motrice car lesmécanorécepteurs de la main sont plus sensibles aux variations des stimulations plutôt qu'auxstimulations elles-mêmes. La perception par le toucher est caractérisée par une certaineséquentialité, bien que nous disposions de deux mains (ce qui correspond en fait audéroulement en parallèle de deux processus séquentiels). La fonction sémiotique enfin,correspond à l'utilisation de la main en tant qu'organe d'expression. C'est par ce type de gestesqu'est constituée la langue des signes utilisée par les sourds. Il faut noter que ces troisfonctions ne sont pas exclusives [Cadoz 94b].

L'indépendance vis-à-vis de l'environnement sonore qui caractérise la communicationgestuelle fait qu'on la retrouve souvent dans des situations où le milieu environnant ne se prêtepas à l'utilisation de la parole soit en raison de bruits importants (piste d'aéroport,établissement boursier, etc.) ou en raison de l'éloignement (grutiers), soit tout simplement enraison d'absence d'air (plongée sous-marine).

De même que pour la parole, le geste est souvent utilisé dans la communication entrehumains pour illustrer un concept ou pour compléter une désignation (geste co-verbal)[Calbris 85] [Briffault 93]. De plus, l'être humain peut produire des gestes en dehors de toutecommunication (en manipulant des objets). En l'absence, ici aussi, de capteurs "intelligents"permettant de savoir si les gestes accomplis par l'utilisateur s'adressent bien à la machine, ilconvient de prévoir un moyen sûr et efficace de basculement d'interlocuteur. La machine nedoit pas recevoir ni interpréter des gestes qui ne lui sont pas adressés. Une telle erreur, si ellese produisait, risquerait également d'avoir des conséquences graves. Par ailleurs, il convient deprendre en considération le fait que la communication gestuelle requiert un certain espacephysique afin de pouvoir effectuer des gestes dynamiques, ce qui peut être une contraintesérieuse dans des applications du domaine avionique en raison de la taille réduite descockpits. Enfin la communication gestuelle nécessite une activité musculaire qui peutengendrer au bout d'un certain temps des tremblements de la main et qui contribuent àaugmenter l'imprécision des désignations gestuelles.


46

Les gants numériques [Zimmerman 87] [Sturman 94] ont été à l'origine des recherchessur la reconnaissance gestuelle. Ces médias se présentent sous forme de gants à enfiler etutilisent soient des fibres optiques (Dataglove) soient des dispositifs mécaniques(exosquelette) soient encore des jauges de contraintes (Cyberglove). Ils sont couplés à undispositif de détection de position qui permet de connaître la position et l'orientation d'unepartie mobile (ici la main) dans l'espace. Un exemple de tels dispositifs est le polhemus deVPL. Il consiste en un système électromagnétique qui se compose d'un émetteur fixe dansl'espace et d'un récepteur attaché à la partie mobile. Le gant numérique lui-même fournit desinformations sur la forme de la main (angles de flexion des deux articulations principales dechaque doigt) et permet la reconnaissance de postures en utilisant des algorithmes deprogrammation dynamique [Sagawa 92], ou des réseaux de neurones [Murakami 91] [Fels 93]ou encore la vision par caméra [Tamura 88] [Ishibuchi 93] même si ces dernières recherchessont encore à un stade primaire.

Il est nécessaire avant de pouvoir utiliser le gant, d'effectuer une phase d'apprentissagequi permettra au système de mémoriser les différents gestes qui pourront être utilisés au coursdu dialogue. La taille et le choix du vocabulaire gestuel sont soumis à des restrictions encoreplus sévères que celles des systèmes de reconnaissance vocale. Les gestes utilisés doiventavoir des configurations suffisamment distinctes pour ne pas être confondues lors de lareconnaissance. Les postures doivent être choisies, de préférence, avec des angles de flexionaux valeurs limites (0°, 45°, 90°). Les gants numériques actuels utilisent tous des filsconducteurs pour transmettre les données provenant du gant numérique à la machine. Ces filsencombrent l'utilisateur et diminuent sensiblement sa liberté d'action. Les gants numériquesutilisant la technologie des fibres optiques sont confrontés au problème de l'imprécision et del'usure de celles-ci. Ces fibres supportent difficilement les contorsions qu'elles subissent.Quant aux gants utilisant des systèmes mécaniques, ils sont très encombrants et possèdent unpoids non négligeable qui induit une fatigue musculaire rapide. Une autre contraintetechnologique concerne la portée de l'émetteur utilisé pour la détection de position. Celle-cireste assez réduite (2 à 2,5 m en laboratoire, 1m dans des conditions réelles à cause deschamps magnétiques). La précision des mesures dépend de la distance entre le capteur etl'émetteur. Pour une distance de 2 mètres, la précision en position est de 6,4 mm et enorientation de 0,85 degrés. L'imprécision des désignations avec un gant numérique est dueessentiellement aux tremblements de la main. C'est pourquoi, dans les applications 2D il peutêtre préférable d'utiliser un écran tactile pour les désignations, lorsque l'utilisateur n'est pastrop éloigné de son écran. Par ailleurs, on peut déplorer le fait que les informations renvoyéespar les gants numériques soient quelquefois incomplètes. Par exemple, certains gants nefournissent aucune information sur l'écartement des doigts ou les mouvements de rotation du


47

pouce. C'est ainsi que les deux gestes de la fig. 19 ne pourront pas être distingués. De plus, ilfaut remarquer que la communication gestuelle et notamment la langue des sourds faitintervenir non seulement les configurations de la main mais également les mimiques duvisages, les mouvements des bras, des avant-bras, des épaules etc.

Figure 19. Configurations indiscernables avec le gant de base de VPL

1.10.4. Le regardLe regard pourrait être le moyen de désignation le plus rapide20 qui existe chez l'être

humain. Il ne nécessite pratiquement pas d'effort et ne génère donc pas de fatigue physique.Combiné avec d'autres modalités, notamment la parole, il permet, dans l'idéal, de disposerd'interactions très puissantes. Cependant désigner un objet du regard, nécessite de focaliser lavue sur cet objet. Ce type de désignation occupe donc la vision et dans des situations oùl'utilisateur doit constamment surveiller des paramètres de son environnement de manièrevisuelle, il convient d'être prudent. Par ailleurs, utiliser le regard comme moyen de désignationimplique que l'objet désigné soit visible et de préférence immobile ou en mouvement lent. Cequi n'est pas toujours forcément le cas.

L'oculomètre est un système qui permet de connaître à tout instant la direction du regardde l'utilisateur. Il en existe différents types. Les plus courants se composent d'un casqueéquipé de miroirs et d'une micro-caméra analysant le reflet cornéen d'une diode infrarougeéclairant l'oeil droit [Metrovision 93]. Le champ de vision de l'oculomètre étant limité à 60degrés en horizontale et à 45 degrés en verticale, il convient de tenir compte (en plus desmouvements de la pupille) de la position et de l'orientation de la tête dans l'espace. Cettecontrainte impose de coupler l'oculomètre à un dispositif de détection de position fixé sur latête et qui permet de connaître la position et l'orientation de la tête dans l'espace. On retrouve

20Après la pensée.


48

naturellement ici les problèmes liés à la portée de l'émetteur utilisé pour la détection de laposition. Une phase de calibration est nécessaire avant chaque utilisation. Les mesures doiventêtre très précises (environ 1 degré), car il est difficile voire impossible pour un utilisateur decompenser des écarts de mesure avec son oeil. Pour une utilisation en avionique, il convientde prendre en considération le fait que l'oculomètre est capable de supporter une accélérationde 3G et que les miroirs, sous l'effet des vibrations peuvent être soumis à de légerspivotements engendrant par la suite des erreurs de mesure. Il est important de fournir un retourà l'utilisateur. Un curseur indiquant la position du point désigné par le regard doit donc êtreaffiché à l'écran.

La désignation oculaire est cependant plus délicate que la désignation manuelle. Desétudes comparatives entre le couple de combinaison de modalités (parole, regard) et (parole,geste manuel) ont été menées chez Sextant-Avionique [Perbet 92] [Fleury 94]. Ces études ontmontré qu'un des principaux problèmes de la désignation oculaire est justement relatif auretour visuel. Si le retour visuel est parfait, c'est à dire si le curseur est affiché exactement à laposition regardée par l'utilisateur, cela cache naturellement l'information située en dessous ducurseur. Par contre, si la position du curseur est légèrement décalée par rapport à la directiondu regard (ce qui est le cas avec la technologie actuelle), l'utilisateur doit alors modifier ladirection de son regard de telle sorte que le curseur soit bien positionné sur le point qu'ildésire désigner. De plus, l'utilisateur ne doit pas essayer de suivre le curseur de son regard,sans quoi il risquerait de le voir lui échapper en permanence (mouvement de fuite).

La désignation oculaire nécessite donc une certaine phase d'apprentissage car l'oeil jouehabituellement le rôle de récepteur d'information, alors qu'ici on lui fait jouer le rôled'émetteur d'information.

1.11. LA FUSION DANS LES INTERFACES MULTIMODALESEn entrée, la fusion des informations provenant des différentes modalités constitue un

des principaux problèmes de l'interaction multimodale. Il s'agit d'intégrer au sein d'une mêmeentité plusieurs informations sémantiquement liées et produites par l'utilisateur à travers desmodalités distinctes. Plusieurs questions se posent :

• Sur quels critères doit-on se baser pour décider de la fusion des informations ?Différents critères tels que la proximité temporelle, la complémentarité logique des

informations, la complétude des structures de fusion, la compatibilité des types desinformations à fusionner etc., ont déjà été utilisés [IHM 92]. Bien que ces critères aientmontré leur efficacité dans des interfaces multimodales où les composantes langagières ne


49

sont pas prédominantes, ils ne sont cependant pas suffisants dans des situations de dialogueplus élaborées et incluant un important traitement du langage naturel. D'autres critèresnécessitant notamment une prise en compte du contexte du dialogue et de son historique sontindispensables [Wilson 93]. Cependant la plupart des systèmes multimodaux offrant undialogue élaboré avec l'utilisateur considèrent le langage naturel (écrit ou oral) comme étant lamodalité dominante. L'analyse, la fusion et l'interprétation sont alors guidées par cettemodalité. Par exemple, ce n'est que lorsqu'un déictique a été détecté sur la modalité langagièreque le système va consulter une autre modalité (en général gestuelle) pour y rechercherl'information complémentaire nécessaire à la compréhension complète de l'énoncé. De ce fait,de tels systèmes perdent en généricité car ils sont en général dépendants de la modalitédominante. Ceci peut poser des problèmes par rapport à leur extension à d'autres modalitésd'une part, et à l'impossibilité d'utiliser le système si la modalité dominante devient(momentanément) inutilisable d'autre part.

• A quel niveau d'abstraction doit être réalisée cette fusion ?La fusion des informations peut selon les systèmes être réalisée à différents niveaux, en

particulier à un niveau lexical (niveau des événements) ou à un niveau sémantique. La fusionà un niveau lexical repose en général sur des critères temporels et ne permet pas de prendre encompte la sémantique des informations. Cependant, cette indépendance par rapport au niveausémantique, permet de réaliser des outils génériques pour la conception des interfacesmultimodales, exploitables dans différents domaines d'application. La fusion à un niveausémantique nécessite d'interpréter les informations avant de les fusionner. Cette fusion estplus robuste, car elle exploite davantage de critères. Cependant, elle est en général dépendantedu domaine d'application étant donné que l'interprétation elle-même l'est également. Parailleurs, l'interprétation d'une information peut donner lieu à des ambiguïtés car elle peutnécessiter des informations en provenance d'autres modalités. Il peut être alors envisagé derecourir à une fusion progressive d'un niveau à un autre. Nous verrons au chapitre 2 unexemple de système où la fusion des informations est réalisée à un niveau sémantique (aprèsinterprétation des événements) et au chapitre 3 un outil générique d'aide au développementd'interfaces multimodales dans lequel la fusion est réalisée au niveau des événements.

• Comment gérer d'éventuels conflits entre fusions de niveaux distincts et/ou modalitésdistinctes ?Il est possible que le processus de fusion à un niveau sémantique contredise le processus

de fusion réalisé au niveau lexical. Par exemple l'utilisateur dis "ce triangle" tout en désignantun rectangle. A un niveau lexical ces deux informations auraient été fusionnées (car elles ontété produites dans un voisinage temporel proche). Cependant au niveau sémantique, cette


50

fusion aurait fait apparaître un conflit. On peut alors envisager différentes solutions. Parexemple, il est possible d'affecter des priorités aux différents niveaux (on privilégie la non-fusion sémantique par rapport à la fusion lexicale, ou la fusion sémantique par rapport à lanon fusion lexicale). On peut également tenir compte des caractéristiques des modalités àtravers lesquelles les informations ont été produites pour prendre une décision. Par exemple, ilest probable que le système de reconnaissance ait commis une erreur en reconnaissant"triangle" au lieu de "rectangle", ce qui amènera a privilégier dans ce cas la fusion lexicale.Enfin si le conflit ne peut être résolu, il est possible d'engager un dialogue d'explication avecl'utilisateur.

1.12. GRAMMAIRE MULTIMODALEComme nous l'avons vu dans le §. 1.10, il est important, dans une interface multimodale

de tenir compte des caractéristiques propres à chaque modalité et aux contraintestechnologiques actuelles. Par exemple, il ne faut pas donner la possibilité à l'utilisateurd'effectuer des opérations exigeant une certaine sécurité en utilisant la parole, vu le risqued'erreur de reconnaissance qui n'est jamais nul. Selon les domaines d'application, il peut alorsêtre nécessaire de disposer d'une grammaire multimodale qui décrit les différents scénariosd'interaction possibles. Une telle approche a été appliquée par exemple dans [Shimazu 94] àtravers l'utilisation d'une grammaire multimodale à clauses définies. Au chapitre 2, nousverrons un exemple d'interface multimodale n'utilisant pas de grammaire. L'utilisateur à lapossibilité d'utiliser n'importe quelle modalité ou combinaison de modalité et dans n'importequel ordre pour exprimer ses énoncés. Au chapitre 3 nous décrirons un outil permettant dedévelopper des interfaces multimodales intégrant une grammaire à travers l'utilisation desréseaux de transitions augmentés.

Dans l'idéal, une telle grammaire doit également tenir compte de paramètresdynamiques tels que l'état de l'utilisateur (il faut éviter par exemple, de demander uneconfirmation manuelle à l'utilisateur, s'il n'a pas les mains libres) ou l'état de l'environnement(par exemple un niveau de bruit trop élevé interdira l'utilisation de la modalité "parole").

1.13. LA MULTIMODALITE EN SORTIEEn sortie, la multimodalité a rajouté une nouvelle dimension à la problématique de la

communication Homme-Machine. Dans les interfaces actuelles toutes les sorties de lamachine vers l'utilisateur sont prédéterminées dans leurs modalités. Par exemple un messaged'erreur sera toujours communiqué à l'utilisateur à travers une modalité visuelle si leconcepteur de l'interface l'a prévu de cette manière. Le problème que l'on se pose aujourd'huiest de doter la machine de capacités "intelligentes" qui lui permettront de choisir de manière


51

dynamique, non seulement le contenu d'une information à communiquer à l'utilisateur, maiségalement la meilleure modalité ou la meilleure combinaison de modalités à utiliser et ce enfonction du contexte courant. Ce problème implique plusieurs questions : que signifieconcrètement le terme "meilleure" (rapidité, fiabilité, concision, etc.) ? Quels sont leséléments qui constituent le contexte (caractéristiques statiques et dynamiques du système, del'utilisateur, de l'environnement, du dialogue, de la tâche, etc.) ? Comment représenter ceséléments et comment les exploiter ?

Tout ceci implique tout d'abord qu'une distinction claire soit établie entre le contenud'une information et sa forme de présentation (un contenu peut être présenté sous différentesformes et une forme peut s'appliquer à différents contenus). Il convient donc d'établir unetypologie des informations en fonction de ces deux critères et d'identifier des relations decorrespondance entre eux. Les travaux de Bernsen sur la théorie des modalités [Bernsen 93][Bernsen 94] constitue un point de départ intéressant dans ce sens. Ensuite, il sera nécessairede définir concrètement de nouveaux modèles (relatifs à l'utilisateur, à la tâche, àl'environnement, etc.) aptes à intégrer les différentes connaissances indispensables àl'établissement d'une telle communication. Nous reviendrons plus en détail sur ces points dansles perspectives futures. Nous pouvons d'ailleurs constater dans le §. 1.15 que la plupart destravaux sur la multimodalité qui ont donné lieu à des prototypes ou à des démonstrateurs,n'ont abordé que le problème des entrées multimodales.

A un niveau plus bas, il est nécessaire que les médias offrent des fonctionnalités que l'onretrouve en partie dans les systèmes multimédia et qui permettent de synchroniser plusieursmessages émis à travers différentes modalités. Considérons l'exemple suivant : l'utilisateurdemande à la machine quelle procédure il doit suivre pour réaliser une commande donnée. Lamachine émet alors un énoncé multimodal composé d'un énoncé vocal "pour exécuter cettecommande appuyez sur ce bouton" et d'un message visuel qui consiste à faire clignoter(pendant quelques secondes) le bouton en question et ce à partir du moment où le mot "ce"commence à être synthétisé.

Cet exemple montre que des mécanismes de spécification temporelle précise doiventêtre prévus, et que les médias doivent posséder les fonctionnalités nécessaires pour pouvoirgérer la synchronisation. Par exemple un système de synthèse de parole doit permettre, entreautres, de connaître à tout moment l'état précis de la synthèse (par exemple, la position, dansle texte transmis, du mot qui est en train d'être synthétisé). Cette fonctionnalité possède uneutilité qui apparaît aussi dans les cas d'urgence. En effet, lorsqu'un message urgent doit êtretransmis à l'utilisateur, il est nécessaire de pouvoir, arrêter ou suspendre la production du


52

message courant (synthèse vocale d'un texte par exemple), et éventuellement la reprendre àpartir de la position où il a été interrompu .

1.14. LE TEMPS DANS LES INTERFACES MULTIMODALESLe temps revêt une grande importance dans les interfaces multimodales, car il devient

lui-même porteur d'information, et influe sur l'interprétation des énoncés. Les fig. 20 et 21montrent qu'à une même séquence d'actions de l'utilisateur, peuvent correspondre deuxinterprétations différentes, selon la distribution temporelle précise des événementscorrespondants et en particulier la proximité temporelle de ceux-ci.

1.14.1. Exemples illustratifsExemple 1

Exemple 2

"pression" "plus deux" Désignationicône température

"pression" "plus deux" Désignationicône température

Temps

Temps

Figure 20. Importance du temps dans les interfaces multimodales

Considérons le contexte d'application d'une usine chimique. Dans l'exemple 1 de lafig. 20, l'utilisateur demande au système de lui communiquer la valeur de la pression, enprononçant le mot "pression". La valeur de la pression est alors communiquée à travers lesynthétiseur de parole. Puis l'utilisateur décide d'augmenter la température. Disposant sur sonécran tactile, d'une icône température (sous forme d'un thermomètre par exemple), il désignecette icône tout en prononçant les mots "plus deux". Le système augmente alors la valeur de latempérature de 2 unités.

Dans l'exemple 2, l'utilisateur prononce d'abord les mots "pression plus deux", ce qui apour effet d'augmenter la pression de 2 unités, puis il désigne l'icône de température. Lesystème lui communique alors la valeur de la température par l'intermédiaire de la synthèse deparole.


53

Un autre cas illustrant l'importance du facteur temporel et que nous avons rencontrédans MEDITOR (cf. Chapitre 4) est donné dans la fig. 21. Dans le premier exemplel'utilisateur désigne un premier caractère en prononçant la phrase "début sélection". Puis ildésigne un second caractère en prononçant la phrase "fin sélection". Le texte compris entre lesdeux caractères est alors sélectionné. Il prononce ensuite le mot "gras" ce qui a pour effetd'affecter l'attribut gras à la sélection courante. Il désigne ensuite un autre caractère etprononce le mot "efface". Seul le caractère désigné est alors effacé.

Dans le second exemple, la troisième désignation est effectuée juste après laprononciation du mot gras. Cette proximité temporelle permet à l'utilisateur d'indiquer ausystème que l'attribut gras doit être affecté au caractère qu'il vient juste de désigner et non à lasélection courante (qui reste toujours valide). Le mot "efface" n'étant accompagné d'aucunedésignation, il est par conséquent appliqué à la sélection courante.

Finalement dans l'exemple 1 la sélection est passée en gras et le caractère a été effacé,alors que dans l'exemple 2 c'est l'inverse qui se produit bien que la séquence des événementssoit exactement la même dans les deux cas.

Exemple 1

"début sélection" "fin sélection" "gras"

Désignation caractère



Exemple 2

"début sélection" "fin sélection" "gras"




"efface"

"efface"

Figure 21. Importance du temps dans les interfaces multimodales


54

On voit à travers ces exemples que la séquence seule ne suffit pas à interprétercorrectement les énoncés multimodaux. Il est nécessaire de connaître la distributiontemporelle précise des informations afin de pouvoir détecter les proximités temporelles entreles événements. Il est par conséquent, indispensable que ces événements soient caractériséspar leurs dates de début et de fin de production. Ceci permet de les classer selon leur ordrechronologique réel et de mesurer les distances temporelles entre eux. Ce type de distanceconstitue un critère de base pour la fusion des informations. Malheureusement, les systèmesd'exploitation actuels ne permettent pas en général d'obtenir une datation correcte desévénements. Il est par conséquent, souvent nécessaire de les contourner, et d'effectuer soi-même une datation approximative à un niveau assez bas de programmation.

1.14.2. La proximité temporelleLa proximité temporelle de deux informations peut indiquer l'existence d'une grande

probabilité que ces informations soient coréférentes et donc qu'elles doivent être fusionnées.Elle augmente la richesse d'expression d'un langage en introduisant un degré de libertésupplémentaire dans l'espace d'expression. Cette notion est utilisée depuis longtemps dans lesinterfaces à manipulation directe à travers le double clic. Celui-ci n'a de signification que siles deux clics qui le composent sont temporellement proches. Dès lors que ces deux clics sonttemporellement proches, ils ne vont plus être interprétés en tant que clics mais vont êtrefusionnés (même si cette fusion est réalisée de manière ad-hoc) pour donner naissance à unnouveau type d'événement (le double-clic) qui donnera lieu à une autre interprétation. Lapuissance d'expression se trouve ainsi dédoublée. Si une telle utilisation de la proximitétemporelle peut être en général difficilement exploitable à travers une seule modalité, il est parcontre très aisé d'en tirer profit lorsqu'on dispose de plusieurs modalités pouvant être utiliséesen parallèle.

Pour définir concrètement la notion de proximité temporelle, il faut étudier les différentscas de succession de deux messages dans le temps. Allen [Allen 83] en a proposé 13(fig. 22).


55

Simultanéïté parfaite

Précédence / Succession

Précédence / Succession, immédiate

Recouvrement total

Recouvrement total à la fin

Recouvrement total au début

Recouvrement partiel

Figure 22. Les treize relations temporelles d'Allen

Ces relations nous semblent importantes dans le cas de la multimodalité en sortie oudans les applications multimédia [Guimarães 92]. En effet, elles permettent de spécifierprécisément la manière dont les différentes informations de sortie doivent être synchroniséesdans le temps. Cependant, en entrée, nous pensons qu'il n'est pas nécessaire d'en distinguerautant. Les cas que nous avons distingués dans nos réalisations et qui sont présentés dans lafig. 23 nous ont été suffisants.


56

MEDIAS

M1

M2

M1

M1

M1

M1 M1

M2

M2 M2

M2

M21

2

3

DD

MEDIAS

MEDIAS

MEDIAS

MEDIAS

MEDIAS

TEMPS

TEMPS

TEMPS TEMPS

TEMPS

TEMPS

Figure 23. Succession temporelle de deux messages

Dans les cas 2 (recouvrement partiel) et 3 (recouvrement total), il est logique de dire queles deux messages sont temporellement proches. Dans le cas 1 (pas d'intersection), la distancetemporelle séparant la date de fin de production du premier message et la date de début deproduction du second est mesurée puis comparée à un seuil déterminé expérimentalement, oufixé selon les préférences de l'utilisateur.

Outre cette méthode par étude de cas, il est possible d'envisager d'autres méthodes pourla mesure de la proximité temporelle. Etant donné deux messages M et M' ayant pour dates dedébut et de fin respectivement td et tf , t'd et t'f, la distance moyenne définie par :

Dist M M ABSt t t td f d f( , ' )

' '

=+

− +ΦΗΓ

ΙΚϑ2 2

revient à représenter chaque intervalle temporel par son milieu et à mesurer les distancesentre ces milieux. On peut également utiliser la distance euclidienne définie par :


57

Dist M M t t t td f d f( , ' ) ( ) ( )' '= − + −2 2

Ceci revient à représenter les messages par des points dans un espace 2D enpositionnant par exemple les dates de début sur l'axe des abscisses et les dates de fin sur l'axedes ordonnées. Il suffit ensuite de mesurer les distances entre les points pour essayer dedégager des nuages de points (fig. 24).

Temps de fin

Temps de début

M1

M2

M3

M4 M5

Figure 24. Mesure de la proximité temporelle à l'aide de la distance euclidienne

Le choix de la meilleure distance à utiliser peut dépendre des modalités utilisées. Parexemple, l'utilisation de la distance moyenne ou de la distance euclidienne dans le cas de lacombinaison de deux modalités, dont l'une produit des messages ayant une longueurtemporelle importante et l'autre produit des messages brefs, est déconseillée. En effet, cesdeux distances tiennent compte de la durée des messages. De ce fait, la différence importanteentre les durées des messages propres à chaque modalité peut conduire à des décisionserronées. Deux messages tels que le premier possède une grande durée par rapport à celle dusecond pourraient être considérés indépendants même s'ils se chevauchent temporellement. Enrevanche, dans le cas de fusion de plus de deux messages, il peut être préférable d'utiliser ladistance euclidienne. Pour notre part, la mesure de la proximité temporelle par étude de casest la méthode qui nous a donné le plus de satisfaction dans nos réalisations.


58

1.14.3. Temps de réponse des médias d'interactionPour pouvoir interpréter correctement les énoncés émanant de l'utilisateur, il est

nécessaire de traiter les informations produites par ce dernier selon leur ordre chronologiqueréel21. Or la différence entre les temps de réponse des différents médias peut être trèsimportante. Ceci implique que le système reçoit en général un flot d'informations dans unordre qui ne correspond pas au véritable ordre produit par l'utilisateur (fig. 25) et peut de cefait conduire à une mauvaise interprétation des énoncés.

"ferme"

Temps

Acquisition

Reconnaissance

Pointageutilisateur

Réception par le systèmede l'événement pointage

Réception par le systèmede l'événement "ferme"

Figure 25. Problème du temps de réponse des médias

Un message peut donner lieu à différentes interprétations selon qu'il ait été produit demanière isolée (dans le temps) ou au contraire, en simultanéïté (ou pseudo-simultanéïté) avecun ou plusieurs autres messages. Par exemple, la désignation d'une fenêtre sur un écran tactile,peut signifier, lorsqu'elle n'est accompagnée d'aucun ordre vocal, "mettre en avant-plan lafenêtre désignée". Par contre, si cette désignation est accompagnée de l'ordre vocal "ferme",l'interprétation sera différente. Or, si l'utilisateur prononce le mot "ferme" et pointe tout desuite après une fenêtre sur son écran tactile, on peut alors constater que l'événementcorrespondant au pointage est produit avant l'événement correspondant au mot prononcé, carle système de reconnaissance de parole met beaucoup plus de temps à reconnaître un mot quel'écran tactile à détecter les coordonnées de pointage, étant donné la différence qui existe entreles traitements respectifs mis en jeu.

21Même pour les être humains, il peut être difficile de comprendre le sens d'une phrase dont l'ordre des

mots a été modifié.


59

La solution à ce problème consiste tout d'abord à dater les messages (date de début etdate de fin). Ainsi, l'ordre chronologique pourra être reconstitué. Ensuite, il convient de netraiter un message, qu'après avoir interrogé tous les médias d'interaction pour s'assurerqu'aucun autre message n'est en cours de production. De cette façon on peut être sûr que leprochain message qui sera produit aura une date de début de production postérieure à celle dumessage en cours de traitement.

Soit t le temps où l'on interroge les médias. A cet instant, le message en cours detraitement ayant déjà été produit, on est sûr que son temps de début de production t1 estinférieur à t. Or si à cet instant t aucun autre message n'est en cours de production, on peut êtresûr que le prochain message qui sera produit aura un temps de début de production t2supérieur à t.

Finalement de t2>t et t>t1 on déduit t2>t1.

Ceci assure que les informations seront traitées selon leur ordre chronologique réel.

Concernant les systèmes de reconnaissance vocale, tester si un message est en cours deproduction, signifie tester si l'utilisateur est en train de parler ou si la reconnaissance d'un motest en cours. Malheureusement cette possibilité n'est pas toujours offerte par les systèmes dereconnaissance. On peut être alors contraint dans un tel cas, avant de traiter une information,d'attendre un certain intervalle de temps qui correspond au temps maximal nécessaire à laproduction d'un message (quel que soit le média d'où il provient). Par exemple, s'il s'agit deparole continue, cela pourra être le temps que met la plus grande phrase du langage pour êtrereconnue à partir du moment où elle a commencé à être prononcée. Naturellement ceciimplique des temps de réponses plus élevés. Dans des applications intégrant unereconnaissance gestuelle il pourra s'agir du temps maximal mis pour qu'un geste soit reconnu.Il est par conséquent important que les systèmes de reconnaissance de parole ou dereconnaissance de gestes soient capables de fournir des informations aussi bien sur l'état del'utilisateur que sur l'état du système de reconnaissance lui-même. Ceci n'est pas toujoursfacile. Par exemple dans [Braffort 92] [Baudel 93] le processus de reconnaissance n'estdéclenché que lorsque la main de l'utilisateur entre dans une région déterminée de l'espace.Nous retrouvons ici le problème de basculement d'interlocuteur propre à la parole et au geste.


60

1.14.4. Coréférences actives et coréférences passivesNos travaux nous ont amenés à distinguer deux types de coréférence dans les interfaces

multimodales :

1. les coréférences actives : correspondent à la production de deux informations àtravers deux médias, telles que l'interprétation et la compréhension complète et sans ambiguïtéd'une des informations ne peuvent se faire sans l'autre. Par exemple, l'utilisateur prononce lemot "ferme" et clique en même temps sur la barre de titre d'une fenêtre.

2. les coréférences passives : correspondent à la production d'une information à traversun média, telle que l'interprétation et la compréhension complète et sans ambiguïté de cetteinformation ne peuvent se faire sans connaissance de l'état d'un autre média. Par exemple,l'utilisateur prononce le mot "ferme". La fenêtre pointée du regard (état de l'oculomètre) estalors fermée.

Le problème posé par les coréférences passives concerne la sauvegarde des états desmédias. En effet un certain temps est nécessaire avant que l'information produite par lepremier média ne soit acquise, reconnue et partiellement interprétée par le système. Pour quele système puisse interpréter complètement cette information, il a besoin de connaître l'état dusecond média. Or il est très probable qu'à ce moment là cet état ait changé (particulièrementpour des médias tels que l'oculomètre ou la souris qui peuvent changer d'état très rapidement).Le système doit alors être capable de retrouver l'état du second média au moment oùl'information provenant du premier a été produite.

Pour illustrer ce problème considérons l'exemple suivant dans lequel l'utilisateurdispose, entre autres, d'un oculomètre, d'un système de reconnaissance vocale et d'un écran.Sur l'écran sont disposées différentes fenêtres. Pour fermer une fenêtre particulière, ilprononce le mot "ferme" et simultanément il pointe du regard la fenêtre désirée (fig. 26).


61

"ferme"

Temps

Acquisition

Reconnaissance

Interprétation

Direction du regard

multimodaldialogue

multimodaldialogue

multimodaldialogue

multimodaldialogue

Figure 26. Problème des coréférences passives

L'analyse de cette manipulation du point de vue du système, indique que le système dereconnaissance vocale met un certain temps à acquérir et à reconnaître le mot prononcé, et lesystème multimodal un certain temps à l'interpréter. Aussi courts que soient ces temps, il esttrès probable, une fois la commande interprétée, que la direction du regard ait changé. Il fautdonc retrouver la direction du regard à un instant passé, compris entre l'instant de début deprononciation du mot "ferme" et l'instant de fin de prononciation. L'état de oculomètre à cetinstant passé permettra de retrouver la direction du regard. Il faut donc que chaque média àchangement d'état fréquent dispose d'une mémoire tampon pour le stockage des états récents.Cette mémoire qui peut être représentée sous forme d'un tableau aura une taille qui dépendranaturellement de l'intervalle de temps maximal qui peut exister entre le début d'acquisitiond'une information et la fin de son interprétation et ce quel que soit son média d'origine. Deuxstructures peuvent être envisagées pour les éléments du tableau. La première contient deuxinformations : l'état du média et la date à partir de laquelle le média est passé dans cet état. Laseconde contient une seule information (l'état du média) mais on dispose en plus de deuxinformations globales : une date initiale et un intervalle temporel. Dans la première structureon ne mémorise l'état du média qu'au moment où celui-ci change. On est alors obligé demémoriser également l'instant où il a changé. Dans la seconde structure, l'état du média estmémorisé de manière régulière. On n'a alors plus besoin que de connaître la date initiale àpartir de laquelle on a commencé la mémorisation et l'intervalle de temps séparant deuxlectures d'état. Le choix de la structure la plus optimale à utiliser dépend de la fréquence des


62

changements d'états du média. Si cette fréquence est assez élevée on préférera la secondestructure, sinon la première est plus optimale.

1.15. LES SYSTEMES EXISTANTSLa première interface multimodale fut développée en 1980 aux Etats-Unis, au sein du

MIT (Massachusetts Institut of Technology), par R. Bolt [Bolt 80] dans laquelle il introduisitle célébre "Put That There" pour la manipulation d'objets graphiques. Depuis, les recherchessur les interfaces multimodales ont été peu nombreuses. En 1985, la compagnie BOEING deSeattle étudia l'intégration des systèmes de reconnaissance de parole et des écrans tactiles dansles opérations de navigation aérienne [Anderson 85]. En 1990, des chercheurs de la mêmecompagnie ont développé une interface multimodale intégrant un système de reconnaissancevocale et une "track-ball" sur une station de travail simulant les cockpits des avions radarAWACS [Salisbury 90].

Ce n'est que depuis 1990 que les recherches sur les interfaces multimodales se sontvéritablement développées. Différents projets européens ont été créés pour explorer cettenouvelle tendance dans la communication Homme-Machine, tels que le projet MMI2

[Binot 92] [Wilson 93] et le projet ARCHIE [Smart 93]. De grandes entreprises s'intéressentégalement à la multimodalité. Sextant-Avionique étudie l'intégration des interfacesmultimodales dans les futurs cockpits d'avions [Perbet 90]. La compagnie japonaise HITACHIs'intéresse quant à elle, à la multimodalité pour des applications de conception etd'aménagement d'intérieur. Des chercheurs de NEC ont développé un système multimodalbasé sur les grammaires à clauses définies. L'entreprise française THOMSON a développé unsystème de dialogue multimodal dénommé MELODIA [Bisson 92] [Pouteau 93] appliqué àdes systèmes de contrôle et de surveillance [Nogier 93]. Le Calspan-UB Research Center(CUBRC) possède un projet dénommé IMMI (Intelligent Multi-Media Interfaces) dont le butest d'appliquer les méthodes utilisées en Intelligence Artificielle pour le développementd'interfaces graphiques intelligentes intégrant la parole, en entrée et en sortie, le langagenaturel et des gestes de désignation. Le projet CUBRICON (CUBRC IntelligentCONversationalist) est une partie du projet IMMI, et concerne plus particulièrement l'aspectmultimodal [Neal 90]. De nombreux laboratoires de recherche et universités en Francepossèdent des projets de recherches sur la communication multimodale. On trouvera dans[IHM 92] une synthèse de ces différents travaux.

Nous présentons ci-dessous quelques systèmes que nous avons choisis pour êtreillustratifs des divers aspects de la multimodalité qui font l'objet des recherches actuellement


63

dans le monde. Parmi eux, nous présentons quelques systèmes français suffisamment avancéspour avoir fait l'objet de démonstrateurs :

On trouvera dans le §. 1.15.6, une description brève d'autres systèmes développés ou encours de développement ainsi que les références correspondantes.

1.15.1. ARCHIEARCHIE (A Reliable Computer-Human Interface Environment) [Smart 94] est un

système qui permet de rajouter à une application déjà existante de nouveaux médias d'entréeet ce de manière transparente, c'est à dire sans avoir à modifier (ou de manière minime) lecode de l'application. Il est cependant nécessaire de rajouter certaines déclarations spécifiées àtravers un langage spécifique : le langage MIDL (Multimodal Interaction DefinitionLanguage).

ARCHIE intègre un noyau logiciel qui tourne sous X-Window dont le principe de baseconsiste à traduire les nouveaux événements générés par les nouveaux médias d'entréerajoutés à la station de travail en événements X (principalement des événements souris ouclavier). Par exemple un événement parole tel que la prononciation du mot "ok" pourra êtretraduit en événement clic souris sur un bouton OK de l'interface. La manière selon laquelledoit se faire cette traduction est spécifiée par le développeur en utilisant le langage MIDL.

L'architecture d'ARCHIE repose essentiellement sur deux modules : le générateur desymboles et le générateur d'effets. Le générateur de symboles a pour rôle de scruter la filed'attente des événements produits par les nouveaux médias et de générer les symboles(structures d'informations particulières) spécifiés par le développeur. Ces symboles sont alorsrajoutés à la file d'attente des symboles. Le générateur d'effets scrute la file d'attente dessymboles et génère les événements X correspondants à la spécification du développeur. Ilrajoute alors ceci à la file d'attente standard des événements X.

Un symbole permet en fait de déclarer ce que nous avons appelé événement multimodal[Bellik 92b]. Il permet ainsi de désigner un ensemble d'événements temporellement proches.Un effet permet, quant à lui, de préciser quel événement X doit être générer lorsqu'un symboleparticulier (ou une séquence de symboles) a été produit.

ARCHIE permet donc de rendre une application, déjà existante, multimodale en entrée,sans avoir à la modifier. Il permet de ce fait d'exploiter des applications existantes. Ceci peutêtre en particulier très utile pour les handicapés. Cependant ceci ne permet pas d'exploiter de


64

manière optimale la puissance des interactions multimodales. Une interface multimodale issuede l'adaptation d'une interface, qui initialement a été produite à partir d'un processus deconception monomodal, ne peut être aussi efficace et conviviale qu'une interface produitedirectement à partir d'un processus de conception multimodal. De plus certaines interactionspeuvent ne pas être adaptables. Certains événements générés à partir d'une interaction avecl'utilisateur ne peuvent pas forcément être générés de manière simulée par programme, cartout ce que l'utilisateur peut percevoir sur son écran et qui conditionne ses entrées, notammentses clics souris, n'est pas forcément percevable de manière automatique par programme.

1.15.2. WIPWIP [André 93] est un système de synthèse automatique de présentations incluant du

texte et des graphiques. Ce système intègre deux modalités en sortie (texte et schémasgraphiques) et un seul mode (visuel). Il est bien adapté pour la génération d'instructionsexplicatives du fonctionnement d'appareils ou de dispositifs techniques dont les manuelsincluent souvent du texte et des illustrations graphiques avec des références croisées de l'un àl'autre. Il a été appliqué pour produire des explications en anglais et en allemand concernantl'utilisation d'une machine à café, l'assemblage d'une tondeuse à gazon et l'installation d'unmodem.

L'architecture de WIP est articulée autour de quatre modules : le planificateur deprésentations, le générateur de graphiques, le générateur de textes et l'organisateur spatial22.

Le planificateur de présentations se charge aussi bien de la détermination du contenu desinformations à présenter que de la sélection des modalités appropriées à leur présentation.L'approche qui a été adoptée est fondée sur l'utilisation de plans. Le planificateur deprésentations produit un plan structuré de manière hiérarchique du document à générer. Leniveau le plus élevé du plan représente le but de la présentation (par exemple expliquercomment procéder pour faire du café). Les niveaux plus bas spécifient les tâches deprésentation élémentaires.

Le générateur de graphiques comprend quant à lui deux composants : le composant deconception graphique et le composant de réalisation graphique. Le composant de conceptiongraphique se charge de traduire les tâches de présentation qu'il reçoit de la part duplanificateur de présentation en une séquence d'opérateurs graphiques de création et detraitement d'objets 2D et 3D. Ces opérateurs sont alors exécutés par le composant de

22Layout manager en Anglais.


65

réalisation graphique. Ce dernier peut en fait être considéré comme un éditeur graphiqueorienté objet étendu.

De même que pour le générateur de graphiques, le générateur de textes comprend luiaussi deux composants : le composant de conception des textes et le composant de réalisationdes textes. Le composant de conception des textes reçoit de la part du planificateur deprésentation les éléments qui doivent être présentés sous forme de texte. L'élaboration desmessages textuels se fait en plusieurs étapes (découpage d'un paragraphe en phrases, choix desstructures syntaxiques, conjugaison des verbes, utilisation d'anaphores, choix des lexèmesetc.). Principalement, le composant de conception de textes se charge de spécifier aucomposant de réalisation de textes "ce qu'il faut dire". Le composant de réalisation se chargealors de "comment le dire". Cependant les frontières entre ces deux modules ne sont pas trèsclaires. On peut constater que les choix lexicaux sont effectués au niveau du composant deconception des textes. Ces choix engendrent alors des contraintes syntaxiques qui sont prisesen considération au niveau du module de réalisation de textes.

Enfin, l'organisateur spatial se charge du calcul de la taille et des coordonnées desdifférents objets à présenter. Il comprend un composant de positionnement d'objets, untypographe "intelligent", un composant chargé de soigner le rendu des documents et ungestionnaire d'interaction.

WIP est donc un des premiers systèmes multimodaux en sortie. Il permet de percevoir lacomplexité des traitements nécessaires pour une génération dynamique des sorties. De plus ilne gère que deux modalités de sortie et il fait abstraction de nombreux facteurs qui devraientpouvoir influer sur les présentations générées. Par ailleurs, WIP permet de bien distinguer ladifférence entre un système multimédia et un système multimodal en sortie. Dans le premiercas la machine se contente de présenter des informations sous différentes formes mais cesformes ont été prédéterminées et choisies par le concepteur de l'interface. Un systèmemultimodal en sortie est capable de choisir lui même de manière dynamique le contenu et lesformes de présentation des informations.

1.15.3. TAPAGETAPAGE (édition de TAbleau par la PArole et le GEste) [Faure 92] [Poirier 93]

[Faure 93] [Faure 94] est un système qui permet à un utilisateur de créer et de manipuler destableaux de données en utilisant la parole et le geste (à travers un ordinateur à stylo).TAPAGE comporte deux aspects. Le premier concerne l'affinement du tracé des tableaux. Al'aide du stylo, l'utilisateur dessine, sur l'écran de l'ordinateur, un tableau en traçant des lignes


66

et des colonnes. Le système est alors capable (à la demande de l'utilisateur) d'idéaliser letableau, c'est à dire d'en améliorer l'aspect en remplaçant les lignes tracées par l'utilisateur pardes lignes parfaitement verticales et horizontales (fig. 27).

Figure 27. Idéalisation des tableaux dans TAPAGE

Le second aspect concerne l'interaction multimodale en entrée dans le système.TAPAGE permet à l'utilisateur de s'exprimer à travers deux modes : le mode oral et le modegestuel. Pour le mode oral une seule modalité est utilisée. Il s'agit d'un langage de commandesimple à base de mots clés bien déterminés (35 mots). Le mode gestuel quant à lui comportequatre modalités :

le geste de dessin : permet de tracer les lignes et les colonnes des tableaux,le geste de pointage23 : permet de sélectionner des cases dans un tableau (de manière

individuelle), des lettres du clavier virtuel24 et de pointer des commandes dans un menu,le geste de commande : permet de déclencher l'exécution de certaines commandes en

effectuant des gestes particuliers. Par exemple, l'effacement d'une ligne peut être obtenu eneffectuant un geste de zigzag sur cette ligne. Un tel geste à l'avantage de référencer aussi bienla commande que l'utilisateur désire exécuter que l'argument ou les arguments sur lesquels elleporte. Nous classons également dans cette catégorie les gestes qui permettent de réaliser dessélections multiples (par exemple, entourage de l'ensemble des objets de la sélection ou dessind'un trait coupant tous les objets de la sélection),

23Nous distinguons le geste de commande du geste de pointage car le premier comporte une

caractéristique dynamique que ne possède pas le second.24Dans le cas où la reconnaissance de l'écriture manuscrite ne donne pas des résultats satisfaisants,

l'utilisateur a la possiblité de faire apparaître sur son écran un clavier et d'entrer des caractères en pointant lestouches de ce clavier.


67

le geste d'écriture : permet d'entrer des informations à travers l'écriture manuscrite. Lemodule de reconnaissance d'écriture manuscrite n'a pas été développé dans le cadre du projetTAPAGE. Il est fourni avec l'ordinateur à stylo.

L'architecture logicielle de TAPAGE est proche de celle de LIMSI-DRAW [Bellik 91][Teil 91a] (cf. Chapitre 2). On retrouve ici des modules associés à chaque modalité eteffectuant une première interprétation individuelle, et un module intégrateur qui se charge dela fusion des différentes informations en vue de l'interprétation globale de la commande.

Un problème intéressant soulevé par TAPAGE concerne la résolution des ambiguïtéspour l'interprétation des informations. Par exemple, un tracé horizontal peut avoir deuxsignifications [Poirier 93] : dans la modalité "geste de dessin", il signifie que l'utilisateur estentrain de rajouter une ligne horizontale au tableau qu'il est en train de créer. Dans la modalité"geste de commande" il signifie que l'utilisateur désire sélectionner les objets coupés par cetrait. L'ambiguïté est ici levée grâce au contexte. Si le système se trouve dans le contextedessin le geste sera interprété comme un rajout de ligne au tableau. Dans le contextecorrection il sera interprété comme une sélection. On retrouve donc ici l'utilisation des modesau sens de [Thimbleby 90]. Il est dommage que TAPAGE n'exploite pas mieux lamultimodalité pour résoudre les ambiguïtés. L'utilisateur se trouve obligé de basculer entre lesdeux modes selon la commande qu'il désire exécuter bien que l'action qu'il effectue soit lamême. L'exploitation de la multimodalité aurait permis d'éviter cette contrainte. Ainsil'utilisateur pourrait dire "sélection" en même temps qu'il trace la ligne pour indiquer ausystème qu'il désire effectuer une sélection ou bien dire "Ajouter ligne" s'il désire rajouter uneligne à son tableau. L'information véhiculée à travers la parole aurait alors servi à leverl'ambiguïté sur le geste effectué.

1.15.4. MATISMATIS (Multimodal Airline Travel Information System) [IHM 92] [Nigay 93b]

[Nigay 94] est un système d'information sur les transports aériens. Il fournit desrenseignements sur les vols (horaires de départ et d'arrivée, déjeuner à bord ou pas, etc.) entredeux villes suite à des requêtes de l'utilisateur. Les requêtes peuvent être exprimées à l'aide dela souris (manipulation directe), à l'aide du clavier, de manière orale ou par combinaisons destrois moyens comme dans l'exemple suivant : "Quels sont les vols à destination de <clic sourissur une ville> et décollant avant <frappe au clavier d'un horaire>". Les sorties sontuniquement visuelles (graphiques et textuelles).


68

La caractéristique originale de MATIS est qu'il autorise le dialogue à plusieurs filsd'activité. Ainsi il est possible pour l'utilisateur d'exprimer une nouvelle requête avant d'avoirachever l'expression de la requête courante. Un changement de focus explicite (parl'intermédiaire de la souris) est utilisé pour basculer d'une requête à une autre.

Le modèle d'architecture utilisé dans MATIS est PAC-Amodeus. Comme nous l'avonsvu dans le paragraphe §.1.5, ce modèle reprend le modèle ARCH et structure le contrôleur dedialogue sous forme d'une hiérarchie d'agents PAC. La structure utilisée pour la fusion est lecreuset. Cette structure peut être vue comme un ensemble de cases initialement vides et quisont remplies au fur et à mesure du traitement des informations.

Dans MATIS trois types de fusion sont mises en oeuvre selon le critère sur lequel ellesse basent. La micro-fusion combine des événements ayant des intervalles temporels entrelacés(ce qui correspond aux cas 2 et 3 de notre classification des différents cas de successiontemporelle de deux messages). La macro-fusion combine deux événements non entrelacésmais temporellement proches (ce qui correspond au cas 1). La fusion contextuelle utilise lecontexte courant de l'interaction.

Contrairement à l'approche que nous avons adoptée dans nos travaux et qui consiste àreconstituer l'ordre chronologique réel des informations avant de procéder à d'éventuellesfusions, dans MATIS la méthode qui a été appliquée consiste à traiter les informationsdirectement dans l'ordre où elles se présentent (ordre qui ne correspond évidemment pas àl'ordre chronologique réel des informations) et à effectuer les fusions éventuelles quitte àdevoir les défaire plus tard s'il s'avère que ces fusions n'étaient pas pertinentes. L'inconvénientde cette approche est qu'elle suppose qu'aucun retour n'est produit consécutivement à uneopération de fusion et avant que l'énoncé ne soit complètement traité. En effet, s'il est possibled'annuler les effets internes (non perceptibles par l'utilisateur) produits par une opération defusion non pertinente, il est par contre délicat d'annuler un effet externe (feed-back) quel'utilisateur aurait déjà perçu.

1.15.5. L'agenda électroniqueL'agenda électronique de [Vo 95] est un système qui présente différentes facettes de la

multimodalité. L'interface est multimodale en entrée de type synergique. L'utilisateur disposede différentes modalités : la parole, l'écriture manuscrite, le geste de désignation et le gestegraphique (tracé). Par exemple, l'utilisateur peut prononcer la phrase "prévois une réunionlundi" tout en traçant avec le stylo un trait indiquant le créneau horaire de la réunion. Il peutégalement dire "reporte cette réunion à Mardi" tout en pointant la réunion en question. Mais


69

d'autres aspects de la multimodalité sont exploités dans ce système, notamment pourpermettre une meilleure reconnaissance vocale.

1.15.5.1. Exploitation de la redondance pour l'amélioration de la reconnaissanceUne caméra filme les mouvements des lèvres de l'utilisateur. Les données ainsi

recueillies sont combinées aux données acoustiques pour améliorer la reconnaissance deparole. La reconnaissance acoustico-labiale s'avère intéressante surtout en milieu bruité.L'amélioration des résultats est cependant quelque peu inférieure à celle obtenue dans le projetAMIBE [Amibe 94].

1.15.5.2. Détection de la position de l'utilisateurUne caméra peut suivre les mouvements de l'utilisateur dans la pièce de travail. La

position spatiale ainsi récupérée est utilisée pour améliorer la reconnaissance vocale selon unetechnique dite de beamforming, qui permet d'améliorer la qualité d'un signal sonore si laposition spatiale de sa source est connue. Les résultats obtenus sont particulièrementintéressants en milieu fortement bruité.

1.15.5.3. Détection de la direction du regardLa direction du regard est ici détectée grâce à la vision par caméra. Ceci permet de

décharger l'utilisateur du matériel encombrant qu'il aurait à porter sur la tête s'il devait utiliserun oculomètre. Cependant cette détection par caméra n'est évidemment pas aussi précise qu'unoculomètre car en fait seule la direction de la tête (et non des yeux) est détectée. Parconséquent cette technique n'est pas utilisée pour des pointages sur l'écran par le regard.Cependant, elle est suffisante pour capturer des informations sur l'état de l'utilisateur et savoirpar exemple, s'il est en train de regarder son écran ou pas. Ceci conditionnera bien sûr laforme de présentation des informations (visuelles ou sonores). Mais cet aspect n'est pas encoretraité dans ce système.

1.15.6. Autres systèmesLe tableau suivant présente brièvement d'autres systèmes multimodaux existants et

fournit les références correspondantes :


70

Systèmes Références

"Put-That-There" : première interface multimodale enentrée, synergique, pour la manipulation de formesgéométriques simples.

[Bolt 80] [Bolt 85] [Bolt 87a][Bolt 87b]

CUBRICON : système de développement d'interfacesmultimodales. Application au contrôle aérien et à laplanification de missions militaires. Langage naturel etgestes de désignation en entrée. Langage naturel etaffichage graphique en sortie.

[Neal 88] [Neal 89] [Neal 90]

Xspeak : rajoute une interface vocale pour la gestion desfenêtres sous X-Windows. L'interface globale ainsiobtenue peut être considérée comme une interfacemultimodale (en entrée) exclusive. Ce type d'extension estmaintenant assez courant sur les Macintosh (VoiceNavigator) ou sur les PC.

[Schmandt 90]

Talk and Draw : système de surveillance radar dans desavions AWACS incluant des commandes vocalescomplétées par des désignations effectuées à l'aide d'unesouris.

[Salisbury 90]

ICP-Draw : application graphique pour la manipulation deformes géométriques simples en utilisant un dialoguemultimodale à forte composante orale.

[Wreto 90] [Caelen 91a][Caelen 91b] [Caelen 91c][Caelen 93]

Le jeu multimode : jeu de mots croisés multimodal.Positionnement des lettres dans une grille de mots croisésen utilisant un dialogue multimodal à forte composanteorale.

[Bourguet 91]

NoteBook : bloc-notes électronique permettant lacréation, et la manipulation de notes à travers uneinterface multimodale en entrée combinant le langagenaturel à des désignations souris. La multimodalitésupportée est du type alternée. Certaines interactionspeuvent paraître synergiques mais NoteBook n'exploitantpas le temps, elles peuvent conduire à des erreursd'interprétation.

[Nigay 91a] [Nigay 94]


71

Interface multimodale pour futurs cockpits d'avionsincluant une combinaison de la parole avec desdésignations oculaires ou manuelles (gant numérique).

[Perbet 91a] [Perbet 91b]

MMI2 (Multi-Modal Interface for Man-MachineInteraction) : système multimodal adoptant une approchemulti-expert. Il supporte le langage naturel anglais,français, et espagnol, en entrée et en sortie, lamanipulation directe, et quelques sorties audio nonverbales. Il a été utilisé pour des applications deconception, gestion et surveillance de réseaux. Iln'exploite pas la proximité temporelle pour la fusion desinformations et il est en ce sens plus proche de lamultimodalité alternée que synergique. Il inclue unimportant traitement des ellipses et des anaphores.

[Ben Amara 91] [Wilson 91][Kuijpers 92] [Binot 92][Wilson 93]

ICP-Plan : application de dessin offrant des outils pour laréalisation de plans architecturaux. L'interface estmultimodale en entrée et de type synergique à fortecomposante orale.

[Bourguet 92a] [Bourguet 92b][IHM 92]

La particularité du système développé par Bolt est qu'ilsupporte des gestes effectués avec les deux mains. Ilintègre deux gants numériques, un oculomètre et unsystème de reconnaissance de parole. L'applicationchoisie concerne la manipulation d'objets 3D(déplacement, rotations ,etc.).

[Bolt 92]

VIPX (Voice Interactive Processing System) : éditeur detextes multimodal à forte composante langagière, avec desdésignations sur un écran tactile.

[Biermann 92]

MELODIA (Multimodal Environment for a naturaL andtask-Oriented DIAlogue) est un système dedéveloppement d'applications multimodales intégrant undialogue orienté par la tâche.

[Bisson 92] [Nogier 92][Nogier 93a] [Pouteau 93a][Pouteau 93b]


72

DEMMONS (Declarative Multimodal MOdelliNgSystem) : application multimodale synergique pour lamodélisation d'objets 3D. Utilisation de la parole seule oucombinée au geste 2D ou 3D pour décrire les propriétésdes objets. A mis en évidence la notion de commandeprogressive. L'utilisateur a la possibilité d'intervenir à toutmoment au cours de l'exécution de la commande diteprogressive pour en changer les paramètres. Par exemple,modification de la vitesse de rotation d'un objet qui est entrain de tourner sur lui-même.

[Vigouroux 92] [Caubet 92][IHM 92] [Gaildrat 93][Rubio 94]

EDWARD : système multimodal visant à intégrer au seind'une même interface plusieurs styles d'interactiondifférents. Il inclut notamment un important traitement dulangage naturel.

[Bos 93] [Bos 94]

MILORD : station de travail multimodale en entrée et ensortie pour des applications dans le domaine médical etnotamment en radiologie.

[Bernabei 94]

1.16. CONCLUSIONDans ce chapitre, nous avons présenté un état de l'art des interfaces multimodales. La

jeunesse des travaux dans ce domaine fait que les chercheurs sont souvent confrontés à unproblème de terminologie. Toutefois les concepts commencent à être bien identifiés, même sile consensus sur les "étiquettes" qui doivent leur être assignées n'est pas encore acquis.

Les principaux nouveaux aspects et problèmes introduits par l'interaction multimodaleont été évoqués et quelques systèmes existants ont été analysés. Ces systèmes peuvent êtreclassés globalement en deux catégories.

Les premiers intègrent un important traitement du langage et/ou du dialogue, le langagenaturel étant alors la modalité directrice. Les traitements sont principalement guidés par cettemodalité dominante. Les autres modalités (en général une modalité gestuelle) ne font quecompléter, si nécessaire, cette modalité dominante. Ces systèmes présentent l'avantage d'offrirune communication Homme-Machine plus proche de la communication humaine. Toutefois,ils sont en général dépendents de cette modalité dominante.


73

Les seconds traitent toutes les modalités à un même niveau et n'accordent pasd'importance particulière à une modalité plus qu'à une autre. La parole est en général utiliséedans ces systèmes à travers un vocabulaire et une syntaxe limités. Ceci est suffisant pour ungrand nombre d'applications et parfois même plus efficace dans la réalisation de certainestâches. Nos travaux, présentés dans les chapitres suivants, se situent dans cette secondecatégorie.

Par ailleurs, la majorité des systèmes existants traitent principalement de lamultimodalité en entrée. Les recherches sur la multimodalité en sortie ne font que commencer.Nos travaux ont été également plus axés sur la multimodalité en entrée, bien que l'outilprésenté au chapitre 3 propose une couche de base pour le traitement des sorties. Dans lecadre d'un contrat DRET, nous avons mené une première réflexion sur la générationdynamique des sorties qui constitue l'aspect novateur de la multimodalité en sortie. Le lecteurpourra trouver plus de détails sur cette réflexion dans [Bellik 94e]. Nous reviendrons sur cetaspect en conclusion et perspectives.

Chapitre2

Chapitre 2. LIMSI-Draw: une première expérience

75

Chapitre 2

LIMSI-Draw : une première expérience

2.1. INTRODUCTIONDans ce chapitre nous présenterons LIMSI-Draw, notre première expérience dans le

domaine de l'interaction multimodale. Cet éditeur graphique a été développé dans une optiqueexploratoire. Sa réalisation a coïncidé avec le lancement des recherches en France dans cedomaine. La stratégie adoptée par le PRC-CHM était dans une première phase, de commencerpar mettre au point des démonstrateurs et des prototypes afin de mettre en évidence demanière concrète les problèmes posés par l'interaction multimodale. Notre plan de travail étaiten adéquation avec cette ligne. Nous avons choisi comme domaine d'application lamanipulation d'objets graphiques, car ce type d'application permet de bien mettre en évidencel'intérêt de la multimodalité.

LIMSI-DRAW a permis de révéler des problèmes importants relatifs aux interfacesmultimodales, ce qui nous a servi par la suite pour la conception de SPECIMEN, un outild'aide au développement des interfaces multimodales, présenté au chapitre suivant.

Ce chapitre sera structuré en quatre parties : la première décrit LIMSI-Draw d'un pointde vue externe en présentant la configuration matérielle, l'interface de présentation, lafonctionnalité générale du système et les types d'interactions supportées. La seconde partiedécrit la structure interne du système : son architecture, les rôles des différents modules, lareprésentation des informations dans le système et les règles utilisées pour la compréhensiondes énoncés de l'utilisateur. La troisième partie analyse les caractéristiques de LIMSI-Draw etla dernière partie enfin présente les résultats d'une première évaluation.

2.2. DESCRIPTION DE LIMSI-DRAWLIMSI-Draw est un éditeur graphique multimodal en entrée qui permet à un utilisateur

de créer et de manipuler des formes géométriques simples (rectangles, cercles, etc.) (fig. 28).


76

Figure 28. LIMSI-Draw

Il intègre trois médias en entrée :• un système de reconnaissance vocale DatavoxTM25 [Vecsys 89a] [Vecsys 89b],• un écran tactile haute définition [Elographics 89a] [Elographics 89b],• une souris

Le système Datavox effectue une reconnaissance de parole de type mots enchaînés etpermet la définition d'une syntaxe. C'est un système monolocuteur qui de ce fait nécessite unephase d'apprentissage avant utilisation. Il permet de calculer les dates de prononciation desdifférents mots composant la phrase reconnue, ainsi que leurs durées.

2.2.1. L'écran de présentationL'écran de présentation de LIMSI-Draw (fig. 73) est divisé en cinq zones :

25Datavox est une marque déposée par Vecsys (France).


77

Menu des commandes Palette des couleurs

Palettedes motifs

Zone de travail

Zone de visualisation desrésultats de la reconnaissance

Figure 29. Ecran de LIMSI-Draw

2.2.1.1. Le menu des commandesCette zone contient la liste des commandes disponibles. La commande courante est

encadrée d'un rectangle. Pour sélectionner une commande, l'utilisateur peut soit la désignerdirectement avec son doigt sur l'écran tactile, soit cliquer dessus avec la souris, soit enfinprononcer son nom. La commande sélectionnée reste active jusqu'à la sélection d'une autrecommande, ce qui évite à l'utilisateur de devoir resélectionner la même commande à chaquefois.

2.2.1.2. La palette des couleursElle contient six couleurs. De même que pour la sélection d'une commande, l'utilisateur

peut choisir une couleur en utilisant l'écran tactile, la souris ou la parole (en prononçant lenom de la couleur désirée). La couleur choisie reste également active jusqu'au choix d'uneautre.


78

2.2.1.3. La palette des motifs de remplissageCette zone contient les quatre motifs de remplissage disponibles : motif plein, vide,

hachuré, croisé. Les remarques faites précédemment pour la palette des couleurs sontégalement valables pour celle des motifs de remplissage.

2.2.1.4. La zone de visualisation des résultats de la reconnaissanceDans cette zone, sont affichés les mots reconnus par le système de reconnaissance

vocale. L'utilisateur peut ainsi vérifier le bon déroulement de la reconnaissance. Dans le casoù le système de reconnaissance vocale reconnaît un mot avec un score de reconnaissanceinférieur à un seuil prédéfini (75 %), un message vocal invitant l'utilisateur à répéter ce qu'ilvient de dire est envoyé à l'utilisateur.

2.2.1.5. La zone de travailC'est dans cette zone que l'utilisateur crée et manipule les objets. La désignation des

objets et d'autres arguments tels que le centre d'un cercle ou le sommet d'un triangle se font àl'aide de l'écran tactile ou de la souris.

2.2.2. Fonctionnalités généralesVoici une description brève des principales commandes offertes par LIMSI-Draw.2.2.2.1. Tracé d'un objetLes commandes de tracé d'objets possèdent en général deux types d'arguments : les

arguments obligatoires définissent la forme, la taille et la position de l'objet. Les argumentsoptionnels indiquent la couleur et le motif de remplissage de l'objet. En cas de non indicationde ces arguments les valeurs courantes des attributs de couleur et de motif de remplissage sontutilisés.

2.2.2.2. Déplacement ou copie d'un objetCes commandes possèdent deux arguments tous deux obligatoires : l'objet à déplacer ou

à copier et la nouvelle position.2.2.2.3. Modification de la couleur ou du motif de remplissage d'un objetL'objet dont on veut modifier la couleur ou le motif de remplissage est un argument

obligatoire. La nouvelle couleur ou le nouveau motif sont optionnels (utilisation des valeurscourantes).

2.2.2.4. Effacement d'un objetCette commande possède un seul argument obligatoire : l'objet à effacer.2.2.2.5. Effacement de tous les objetsCette commande ne requiert aucun argument. Une confirmation est cependant demandée

à l'utilisateur avant l'exécution.


79

2.2.3. Exemples d'interactions multimodales supportées parLIMSI-DrawLIMSI-Draw offre à l'utilisateur une grande souplesse quant à l'expression des

commandes. En effet, chaque commande peut être réalisée de six manières différentes, parrapport aux médias utilisés :

1. En utilisant uniquement la souris.2. En utilisant uniquement l'écran tactile.3. En combinant la souris et l'écran tactile.4. En combinant la parole et la souris.5. En combinant la parole et l'écran tactile.6. En combinant la parole, la souris et l'écran tactile.

Pour chacune de ces manières, la syntaxe de la commande peut être aussi très souple. Cequi offre à l'utilisateur encore plus de possibilités pour exprimer sa commande. Par exemple,pour le déplacement d'un objet, il peut disposer des différents scénarios d'interaction suivants :

• "met" + désignation d'un objet + désignation d'une position.• "met" + ("ça" . désignation d'un objet) + désignation d'une position.• "met" + désignation d'un objet + ("ici" . désignation d'une position).• "met" + ("ici" . désignation d'une position) + désignation d'un objet.• "met" + ("ça" . désignation d'un objet) + ("ici" . désignation d'une position).• "met" + ("ici" . désignation d'une position) + ("ça" . désignation d'un objet).• "met" + "le" + désignation d'une position.• "met" + "le" + ("ici" . désignation d'une position).• "met" + ("ici" . désignation d'une position) + "le".

REMARQUES1. '+' représente la séquentialité, '.' représente la simultanéité (avec un certain seuil de

tolérance).2. Si la commande de déplacement avait déjà été sélectionnée, l'utilisateur dispose

encore des mêmes scénarios mais sans avoir besoin cette fois de prononcer le mot "met" audébut.

3. Toutes les désignations peuvent se faire indifféremment à l'aide de l'écran tactile oude la souris.

4. La désignation d'une position peut, bien sûr, se faire sur un objet (superpositiond'objets).


80

Le tableau suivant présente d'autres exemples d'interactions multimodales supportéespar LIMSI-Draw :

Commande InteractionTracé d'un rectangle avec la

couleur et le motif courant(omission des argumentsoptionnels)

L'utilisateur prononce le mot "rectangle" tout endésignant à l'aide de l'écran tactile et/ou de la souris deuxpoints sur l'écran.

Tracé d'un triangle bleu avecun motif de remplissage hachuré.

Il prononce la phrase "triangle bleu hachuré" touten désignant à l'aide de l'écran tactile et/ou de la souris,les trois sommets du triangle.

Tracé d'un cercle aveccontrôle continu sur le rayon

Il prononce la phrase "cercle centre bordure" touten désignant avec l'écran tactile ou la souris, le centre ducercle, puis un point sur sa périphérie, et sans lever ledoigt de l'écran tactile (ou sans relâcher le bouton de lasouris) il fait glisser celui-ci. Le cercle s'agrandit alors,ou se rétrécit en suivant le mouvement du doigt.

Tracé d'un cercle aveccontrôle continu sur le centre

Il reprend la même manipulation précédente saufque cette fois au lieu de dire "cercle centre bordure", ildit "cercle bordure centre".

Duplication du dernier objetmanipulé

Il prononce la phrase "copie le ici" tout endésignant la position où doit être dupliquer l'objet référé.

2.3. STRUCTURE DE LIMSI-DRAWToute l'architecture interne de LIMSI-Draw a été fondée autour de la représentation des

informations. Avant de présenter cette architecture, il nous faut donc préciser la manière dontelles sont représentées.

2.3.1. Représentation des informationsSi on considère que le noyau fonctionnel consiste en un ensemble de commandes

(fonctions) activées de manière indirecte (à travers l'interface) par l'utilisateur, on peut alorsdécomposer toute action de l'utilisateur en une suite d'opérations de baseO1, O2, ..., Oi, ... ,On où Oi représente l'une des trois opérations suivantes :


81

2.3.1.1. Faire référence à une commandeConsiste à indiquer au système quelle commande doit être exécutée. Cette référence

peut être complexe (lorsqu'elle est exprimée, par exemple, en langage naturel) ou simple(choix dans un menu, ou clic sur une icône).

2.3.1.2. Faire référence à un argumentConsiste à indiquer au système à quel argument de la commande courante doit être

affectée la donnée qui vient ou qui va être fournie.

2.3.1.3. Entrer une donnéeConsiste à fournir au système une donnée (position spatiale, objet graphique, nom de

fichier, enregistrement d'une base de données,...) qu'il devra affecter à un argument particulierde la commande à exécuter.

De cette classification, découle notre formalisme de représentation. Les informationstraitées par le contrôleur de dialogue sont donc de trois types :

1. Commande.2. Argument.3. Donnée.

Chaque information est décrite par :

• son type global (commande, argument, donnée),• son type local: indique le type de la commande, de l'argument ou de la donnée, par

rapport au domaine de l'application,• son origine (écran tactile, système de reconnaissance vocale, souris),• la date de début de production de l'événement associé,• la date de fin de production de l'événement associé,• un code permettant d'identifier la commande ou l'argument. S'il s'agit d'une donnée, un

pointeur permettant d'y accéder est disponible dans la structure,• un état décrivant les différents traitements subis par l'information.

Les états sont gérés et utilisés par le contrôleur de dialogue. Ils sont affectés auxinformations au fur et à mesure de leur traitement. Ils décrivent les différents traitements subispar ces informations.


82

Le formalisme utilisé pour la représentation des informations est donc unique (paropposition à un formalisme de représentation multiple).

ExempleSoit la commande DUPLIQUER servant à dupliquer un objet affiché à l'écran. Cette

commande possède deux arguments :

1. OBJET : l'objet à dupliquer.2. POSITION : sa nouvelle position.

Considérons alors, l'interaction suivante:

1- L'utilisateur prononce le mot "copie",2- Il désigne une position sur l'écran tactile tout en prononçant le mot "ici",3- Il désigne à l'aide de la souris un objet tout en prononçant le mot "ça".

Dans cette interaction, on peut dire que :

1- Le mot "copie" fait référence à la commande DUPLIQUER.2- La désignation par l'écran tactile est une entrée de donnée.3- Le mot "ici" fait référence à l'argument POSITION. Il permet de savoir que la donnée

entrée doit être affectée à l'argument POSITION.4- La désignation par la souris est une entrée de donnée.5- Le mot "ça" fait référence à l'argument OBJET. De même, il permet de savoir que la

valeur entrée doit être affectée à l'argument OBJET.

2.3.2. Architecture interneL'architecture interne de LIMSI-Draw décrite dans la fig. 30 fait apparaître les

principaux composants suivants :


83

Modèle de langage

Souris

Noyau Fonctionnel

Utilisateur

Modèle de langage

Datavox

Modèle de langage

Ecran Tactile

Interpréteur

Interpréteur

Interpréteur

Ecran

File d'attente des Informations

Interface duNoyau Fonctionnel

Base des objets

Contrôleurde dialogue

Figure 30. Architecture interne de LIMSI-Draw

2.3.2.1. Les interpréteursLes interpréteurs ont pour fonction principale de traduire les événements de bas niveau

provenant des périphériques (coordonnées x, y pour l'écran tactile, chaîne de caractères pour lesystème de reconnaissance vocale etc.) en informations de plus haut niveau, ayant unereprésentation unifiée.

A chaque média d'entrée est associé un interpréteur. Les interpréteurs remplissent leursfonctions grâce à l'utilisation d'un modèle de langage propre et à la consultation de la base desobjets.

Le modèle de langage contient l'ensemble des éléments permettant l'interprétation d'unévénement. Par exemple pour un gant numérique, il s'agira d'un modèle de langage gestuel quicomportera la sémantique de chaque geste du langage. Pour un système de reconnaissancevocale, ce sera un modèle de langage parlé qui renfermera le sens de chaque mot ou phrase.De même pour l'écran tactile il s'agira d'un modèle de langage graphique qui contiendra lasignification particulière de chaque pointage selon la position où il s'est produit, etc.


84

2.3.2.2. La file d'attente des informationsLa file d'attente contient les informations produites par les interpréteurs. Nous rappelons

que ces informations peuvent être de trois types : commande, argument, ou valeur. Elles sontinsérées dans la file selon l'ordre chronologique réel des événements associés. Cette file n'estdonc pas une véritable FIFO (First In First Out), puisque les informations peuvent êtreinsérées en milieu de file et non pas systématiquement rajoutées en queue de file.

2.3.2.3. Le contrôleur de dialogueLe contrôleur de dialogue est le composant le plus important dans l'architecture de

LIMSI-Draw. C'est lui qui analyse les informations contenues dans la file dans le but decomprendre l'énoncé exprimé par l'utilisateur.

Le fonctionnement général du contrôleur de dialogue consiste à commencer parreconnaître la commande que l'utilisateur désire exécuter. Puis, en utilisant la description decelle-ci (fournie par l'interface du noyau fonctionnel) et en analysant les informationscontenues dans la file, il essaye d'affecter des valeurs à ses arguments. Une fois que tous lesarguments auront été affectés d'une valeur, il demande à l'interface du noyau fonctionnel delancer l'exécution de cette commande en lui fournissant une structure contenant lesinformations nécessaires.

2.3.2.4. Le noyau fonctionnelLe noyau fonctionnel est composé d'un ensemble de fonctions relatives au domaine de

l'application. Celles-ci peuvent avoir des arguments obligatoires ou optionnels. Elles peuventaussi agir sur un ensemble de variables globales pouvant être accédées par toutes lesfonctions.

Par ailleurs ces fonctions peuvent consulter et/ou modifier la base des objets dont l'accèsest partagé avec les interpréteurs. Cependant, contrairement aux fonctions, les interpréteurs nepossèdent qu'un droit de consultation sur la base des objets.

2.3.2.5. L'interface du noyau fonctionnelL'interface du noyau fonctionnel renferme les informations suivantes :

• La définition des types des arguments et des variables globales.• Pour chaque commande une structure contenant la description de ses arguments.• Des informations permettant de déclencher l'exécution d'une commande.


85

A une commande ayant N arguments est associé un tableau de N structures. Chaquestructure décrit un argument et est composée des champs suivants :

Identificateur : permet d'identifier l'argument.Type : type de l'argument.Genre : indique si l'argument est obligatoire ou optionnel.Etat : ce champ est utilisé de manière dynamique pour indiquer si

l'argument possède une valeur ou pas.Valeur : ce champ contient la valeur de l'argument dans le cas où celui-ci

en possède une.

2.3.2.6. La base des objetsLa base des objets contient toutes les informations concernant les objets créés et

manipulés par l'utilisateur. Selon le type de l'objet, on peut trouver les informations suivantes :

RectangleLes informations mémorisées pour les objets de type rectangle sont:x1, y1 : coordonnées du premier sommet.x2, y2 : coordonnées du second sommet.Couleur : couleur du rectangle.Motif : motif de remplissage du rectangle.Par sommet on entend une extrémité de la diagonale.

CercleLes informations mémorisées pour les objets de type cercle sont:xc, yc : coordonnées du centre du cercle.Rayon : rayon du cercle.Couleur : couleur du cercle.Motif : motif de remplissage du cercle.

TriangleLes informations mémorisées pour les objets de type triangle sont:x1, y1 : coordonnées du premier sommet.x2, y2 : coordonnées du deuxième sommet.x3, y3 : coordonnées du troisième sommet.Couleur : couleur du triangle.Motif : motif de remplissage du triangle.


86

La superposition des objets à l'écran est connue grâce à l'utilisation d'une liste telle quela position d'un objet dans la liste indique sa position par rapport aux différents plans desuperposition. Ainsi, si un objet O se trouve à une position P, cela voudra dire que tous lesobjets ayant une position inférieure à P seront contenus dans des plans situés derrière le plande l'objet O. De même, les objets ayant une position supérieure à P seront contenus dans desplans situés devant le plan de l'objet O.

2.3.3. Fonctionnement du contrôleur de dialogueLe contrôleur de dialogue traite les informations, une par une, au fur et à mesure de leur

arrivée dans la file. Le traitement effectué dépend du type de l'information courante, de l'étatde l'information précédente et de certaines autres conditions. Pour décider du traitement àeffectuer sur une information donnée, le contrôleur de dialogue utilise un ensemble de règlesqui ont été dégagées après analyse de toutes les configurations qui peuvent se présenter dansla file. Ces règles seront décrites après avoir passé en revue les différents états que peutprendre une information.

2.3.3.1. Les états d'informationIl existe sept états possibles : trois sont relatifs aux informations de type argument, trois

autres aux informations de type donnée, et un état pour les informations de type commande.

Etat AF : Argument FusionnéCet état indique que l'information courante est un argument qui vient d'être fusionné

avec l'information précédente. Cette fusion implique que l'information précédente était unedonnée dont le type est compatible avec celui de l'argument et que les événements ayantdonné lieu à ces deux informations sont temporellement proches. Elle a pour conséquencel'affectation de la donnée précédente à l'argument courant.

Etat ANF : Argument Non FusionnéCet état indique que l'information courante est un argument qui n'a pu être fusionné avec

l'information précédente. Cette impossibilité de fusion peut être due à trois causes:

1. L'information précédente n'est pas une donnée.2. L'information précédente est une donnée, mais son type n'est pas compatible avec

celui de l'argument.3. L'information précédente est une donnée. Son type est compatible avec celui de

l'argument, mais les événements ayant donné lieu à ces deux informations ne sont pasproches temporellement.


87

Cependant ceci ne signifie pas que cet argument sera ignoré. En effet, il est très probableque cet argument soit fusionné avec la prochaine information.

Etat AI : Argument InexistantCet état indique que l'information courante est un argument qui ne figure pas dans la

description de la commande courante. Par exemple, l'utilisateur en créant un rectangle, faitréférence au rayon qui est un argument de la commande de création de cercles et non derectangles.

Etat DF : Donnée FusionnéeCet état indique que l'information courante est une donnée qui vient d'être fusionnée

avec l'information précédente. Cette fusion implique que l'information précédente était unargument dont le type est compatible avec celui de la donnée et que les événements ayantdonné lieu à ces deux informations sont temporellement proches. Elle a pour conséquencel'affectation de la donnée courante à l'argument précédent.

Etat DAD : Donnée Associée par DéfautCet état indique que l'information courante est une valeur qui n'a pu être fusionnée avec

l'information précédente soit parce que celle-ci n'est pas un argument, soit parce que lesconditions de compatibilité de types ou de proximité temporelle ne sont pas vérifiées.Cependant, il indique que cette information a pu être associée par défaut à un argument de lacommande. Il s'agit du premier argument de type compatible et n'ayant pas encore de valeur.Cette association conduit à l'affectation de la donnée à cet argument. Cette association n'estpas définitive. Elle peut être annulée. Ainsi, s'il s'avère que la prochaine information est unargument de la commande et que les conditions de compatibilité de types et de proximitétemporelle sont satisfaites, cette donnée sera alors fusionnée avec l'argument, et l'associationpar défaut sera annulée.

Etat DL : Donnée LibreCet état indique que l'information courante est une donnée qui n'a pu être ni fusionnée

avec l'information précédente, ni associée par défaut à un argument de la commande. Ceci nesignifie pas que cette donnée sera ignorée. En effet, s'il s'avère que la prochaine informationest un argument de la commande et que les conditions de compatibilité de type et de proximitétemporelle sont satisfaites, elle sera alors fusionnée avec cet argument.

Etat C : CommandeCet état indique simplement que l'information courante est une commande.


88

2.3.3.2. Les règles de décision

Règle 1 : Fusion Donnée-ArgumentSi l'information courante est une donnée, et

l'état de l'information précédente est ANF, etles conditions de compatibilité de types et de proximité temporellesont satisfaites,

alors affecter la donnée courante à l'argument précédent etmettre l'état de l'information courante à DF.

Règle 2 : Association par DéfautSi l'information courante est une donnée, et

[l'état de l'information précédente est différent de ANF, oules conditions de compatibilité de types et de proximité temporellene sont pas satisfaites], etil existe un argument de type compatible et n'ayant pas encore devaleur,

alors affecter la donnée à cet argument etmettre l'état de l'information courante à DAD.

Règle 3 : Donnée Non FusionnéeSi l'information courante est une donnée, et

[ l'état de l'information précédente est différent de ANF, oules conditions de compatibilité de types et de proximité temporellene sont pas satisfaites ], etil n'existe pas d'argument de type compatible et n'ayant pas encorede valeur,

alors mettre l'état de l'information courante à DL.

Règle 4 : Argument ErronéSi l'information courante est un argument, et

cet argument n'appartient pas à la commande courante,alors mettre l'état de l'information courante à AI.


89

Règle 5 : Fusion Argument-DonnéeSi l'information courante est un argument, et

cet argument appartient à la commande courante, etl'état de l'information précédente est DL, etles conditions de compatibilité de types et de proximité temporellesont vérifiées,

alors affecter la donnée à l'argument etmettre l'état de l'information courante à AF.

Règle 6 : Fusion Argument-Donnée, Annulation Association par DéfautSi l'information courante est un argument, et

cet argument appartient à la commande courante, etl'état de l'information précédente est DAD, etles conditions de compatibilité de types et de proximité temporellesont vérifiées,

alors annuler l'association par défaut, etréaffecter la donnée à l'argument courant etmettre l'état de l'information courante à AF.

Règle 7 : Argument Non FusionnéSi l'information courante est un argument, et

cet argument appartient à la commande courante, et[l'état de l'information précédente est différent de DL et DAD, oules conditions de compatibilité de types et de proximité temporellene sont pas satisfaites ],

alors mettre l'état de l'information courante à ANF.

Règle 8 : CommandeSi l'information courante est de type COMMANDE,alors réinitialiser le contexte.

La fig. 31 présente l'arbre de décision correspondant aux règles énoncées.


90

L'information courante est une commande

L'information courante est un argument

L'information courante est une donnée

Appartient à la commande courante

N'appartient pas à la commande courante

Début de l'analyse

Conditions de fusion satisfaites

Conditions de fusion non satisfaites

Etat de l'information précédente

= ANF

Etat de l'information précédente

# ANF

Il existe un argument

sans valeur, de type

compatible

Il n'existe pas d'argument

sans valeur, de type

compatible

Etat de l'information précédente = DL

Etat de l'information précédente = DAD

Etat de l'information précédente # DL, DAD

Conditions de fusion satisfaites

Conditions de fusion non satisfaites

Regle 5 Regle 6 Regle 7Regle 7 Regle 1 Regle 2 Regle 2 Regle 8Regle 3Regle 4

Figure 31. Arbre de décision


91

REMARQUES1- La réinitialisation du contexte consiste à mettre à jour certaines variables (telles que

le code de la commande courante, son type, le nombre d'arguments ayant une valeur etc.) et àréorganiser la file. Cette réorganisation consiste à supprimer toutes les informationsantérieures à l'information courante (la commande) sauf celles qui sont assez proches d'elles.En effet, il peut arriver que l'entrée des données des premiers arguments de la commande, ouque les références à ceux-ci précèdent la référence à la commande elle-même. Par exemple envoulant effacer un objet affiché à l'écran, il peut arriver que l'utilisateur désigne l'objet avantde référencer la commande (en prononçant le mot "efface" par exemple).

2- Chaque fois que le contrôleur de dialogue affecte une valeur à un argument, ilincrémente une variable représentant le nombre d'argument ayant une valeur, puis la compareau nombre d'arguments de la commande courante. Si l'égalité est vérifiée, la complétude de lacommande est satisfaite et le processus d'exécution de la commande peut alors être déclenché.Il est ensuite procédé au nettoyage de la file. Ce nettoyage consiste à supprimer toutes lesinformations antérieures à l'information correspondant à la dernière donnée entrée ou audernier argument référencé (cette dernière information est également supprimée).

2.3.3.3. Les modes de fonctionnement du contrôleur de dialogueLe contrôleur de dialogue possède deux modes26 de fonctionnements selon le type de la

commande. Selon ce type, l'utilisateur peut disposer ou non d'un contrôle continu lors del'exécution de la commande. Par exemple, l'utilisateur ne peut pas disposer d'un contrôlecontinu lors de l'exécution de la commande d'effacement d'un objet. Par contre, pour lacommande de création de rectangle, il peut s'il le désire contrôler la taille de celui-ci demanière interactive lors de sa création et ceci en maintenant le doigt sur l'écran tactile lors dela désignation du second sommet ou en maintenant le bouton de la souris appuyé et en faisantensuite glisser celle-ci. Si l'utilisateur lève le doigt immédiatement ou relâche le boutonaussitôt après la seconde désignation, il n'y aura pas dans ce cas de contrôle continu.

Avant de décrire ces deux modes de fonctionnement il est nécessaire de formaliser lanotion de contrôle continu afin d'en établir une définition générale qui soit applicable quel quesoit le type de feed-back à produire (visuel, auditif, sensitif etc.) et quelle que soit lacommande.

26Ne pas confondre avec mode de communication !


92

Etant donnée une commande C à N arguments P1 , P2 ,......, Pn et étant donnée une suitede valeurs (V1,V2,...,Vn)1 , (V1,V2,...,Vn)2 , ........, (V1,V2,...,Vn)m des arguments de C, onpeut distinguer deux types de contrôles :

Contrôle cumulatifla suite d'exécutions suivante:C1 C2......Cm où Ci représente l'exécution de la commande C avec les valeurs

(V1,V2,.....,Vn)i .

Il s'agit donc d'un feed-back obtenu par accumulation des exécutions de la commande C.

Contrôle annulatifla suite d'exécutions suivante:C1 A1 C2 A2 ........Cm-1 Am-1 Cm où Ci représente l'exécution de la commande C

avec les valeurs ( V1,V2,.....,Vn)i et Ai l'annulation des effets produits par l'exécution de lacommande Ci.

Le premier type de contrôle concerne les commandes telles que l'exécution de la mêmecommande avec de nouvelles valeurs conduit automatiquement à l'annulation de l'exécutionprécédente comme c'est le cas pour la commande de déplacement d'un objet. Il est donc inutiled'annuler explicitement cette dernière, ce qui pourrait d'ailleurs produire un feed-back nonconvenable si cela était fait.

Le second type de contrôle concerne les commandes telles qu'une nouvelle exécution dela commande n'annule pas les effets produits par l'exécution précédente (exemple :commandes de création d'objets). Il est donc ici nécessaire d'annuler explicitement celle-ci.

On pourrait penser qu'il suffirait, au lieu d'annuler tous les effets produits par l'exécutionde la commande (ce qui nécessite naturellement plus de temps et plus d'espace mémoire),d'annuler uniquement l'effet visuel. En fait ceci impliquerait de se restreind uniquement à unfeed-back visuel, ce qui enlèverait son caractère général à la définition. Si on suppose, parexemple, qu'on dispose d'un système à retour tactile ou à retour d'effort une telle définition neserait alors plus applicable.

Dans LIMSI-Draw nous nous sommes limités au contrôle obtenu par variation d'un seulargument. Ainsi, pour une commande à N arguments, l'utilisateur peut contrôler l'exécution dela commande en fixant les valeurs de N-1 arguments (n'importe lesquels) et en faisant varier le


93

Nième restant. De cette façon, l'utilisateur dispose, pour une commande à N arguments de Ntypes de contrôles possibles. Ces N types de contrôle correspondent au choix d'un argumentparmi les N. Par exemple, pour la commande de tracé d'un cercle, l'utilisateur dispose de deuxtypes de contrôle continu selon qu'il fait varier le centre du cercle ou son rayon.

Voici maintenant la description des deux modes de fonctionnement du contrôleur dedialogue:

Mode sans contrôle continuDans ce mode, dès que tous les arguments de la commande ont été affectés d'une valeur,

le contrôleur de dialogue déclenche l'exécution de la commande puis reprend l'analyse desinformations de la file.

Mode avec contrôle continuDans ce mode, le contrôle continu est obtenu de la manière suivante: dès que tous les

arguments de la commande ont été affectés d'une valeur, le contrôleur de dialogue déterminele média à travers lequel la dernière valeur a été entrée (cette information est contenue dans lastructure de représentation des informations). Les événements qui sont alors envoyés demanière continue à partir de ce média passent par l'interpréteur correspondant, et lesinformations de plus haut niveau résultantes sont alors insérées dans la file. Le contrôleur dedialogue les analyse et aussitôt qu'il détecte une modification de valeur, il demande àl'interface du noyau fonctionnel de déclencher l'exécution de la commande avec la nouvellevaleur du dernier argument. Si la commande est du type nécessitant un contrôle annulatif, ilprend soin auparavant de demander l'annulation de celle-ci avec l'ancienne valeur du dernierl'argument. Ce processus se poursuit jusqu'à ce qu'une condition d'arrêt propre au média enquestion soit satisfaite (relâchement du bouton de la souris, levée de main de l'écran tactileetc.).

2.3.4. Traitement d'un exemple : "mets ça ici"Nous allons traiter cet exemple, d'abord du point de vue des interpréteurs, puis du point

de vue du contrôleur de dialogue. Dans la suite, on désignera par IP l'interpréteur associé ausystème de reconnaissance de parole, par IS celui associé à la souris, et par IE celui associé àl'écran tactile. Le contrôleur de dialogue sera désigné par CD. On supposera que l'ordrechronologique des événements est le suivant (fig. 32):


94

1. Prononciation du mot "mets",2. Clic avec la souris sur un objet,3. Prononciation du mot "ça",4. Prononciation du mot "ici",5. Pointage sur l'écran tactile,

PERIPHERIQUES

TEMPS

Ecran tactile

Souris

S.R.Parole"mets" "ça" "ici"

clic pointage

Figure 32. Ordre chronologique des événements

REMARQUEDans la suite il conviendra de bien distinguer le type de l'information (référence à une

commande, référence à un argument, donnée) du type de la donnée ou de l'argument (type quidépend du domaine de l'application).

2.3.4.1. Du point de vue des interpréteurs• L'IP reçoit l'événement correspondant à la prononciation du mot "mets". En utilisant

son modèle de langage propre, il l'interprète et produit une information de type référence à unecommande. Il s'agit en l'occurrence de la commande de déplacement d'un objet.

• L'IS reçoit l'événement correspondant au clic. Ce clic s'étant produit sur un objet, l'ISproduit une information à double interprétation : une donnée de type position spatiale et unedonnée de type objet graphique.

• L'IP reçoit l'événement correspondant à la prononciation du mot "ça". Il l'interprète etproduit une information de type référence à un argument. Il s'agit en l'occurrence del'argument OBJET.


95

• L'IE reçoit l'événement correspondant au pointage. Si ce pointage s'est produit sur unobjet, l'IE produit une information à double interprétation : une donnée de type positionspatiale et une donnée de type objet graphique. Sinon une information à interprétation unique,en l'occurrence une donnée de type position spatiale, est générée.

• L'IP reçoit l'événement correspondant à la prononciation du mot "ici". Il l'interprète etproduit une information de type référence à un argument. Il s'agit en l'occurrence del'argument POSITION.

On remarquera que l'événement correspondant au pointage est reçu par le système avantl'événement correspondant à la prononciation du mot "ici". Ceci est dû à la différence quiexiste entre les temps de réponse propres à chaque périphérique. En effet, le système dereconnaissance vocale mets plus de temps à reconnaître un mot, que l'écran tactile à trouverles coordonnées du point désigné.

2.3.4.2. Du point de vue du contrôleur de dialogue• Le CD traite l'information relative à la prononciation du mot "mets". Il applique la

règle 8. Il définit une structure de données conforme à la description de la commande dedéplacement d'un objet, fournie par l'interface du noyau fonctionnel.

• Il traite l'information correspondant au clic. Il applique cette fois-ci la règle 2.L'information courante est de type donnée, à double interprétation. Il cherche le premierargument de la commande n'ayant pas encore de valeur (c'est à dire n'ayant pas fait l'objetd'une fusion locale ni d'une association par défaut) et dont le type est compatible avec l'unedes interprétations. C'est l'argument OBJET. Il lui associe alors la donnée de type objet. Ilaffecte ensuite à l'information courante l'état DAD (Donnée Associée par Défaut).

• Il traite l'information relative à la prononciation du mot "ça". Il utilise alors la règle 6.Celle-ci lui indique que si l'information courante est une référence à un argument, et quel'information précédente est une donnée dont l'état est DAD et dont le type est compatibleavec celui de l'argument, et que la condition de proximité temporelle est vérifiée, alors annulerl'association par défaut et affecter la donnée précédente à l'argument référencé dansl'information courante (c'est à dire l'argument OBJET). Il affecte ensuite à l'informationcourante l'état AF (Argument Fusionnée) et à l'information précédente l'état DF (DonnéeFusionnée).


96

On remarque que l'annulation de l'association par défaut précédente était inutile dans cecas, puisque c'est toujours de l'argument OBJET qu'il s'agit. Cependant ceci n'aurait pas étévrai s'il s'était agit de l'argument POSITION (cas de "mets ici ça").

• Il traite l'information relative à la prononciation du mot "ici". Il lui affecte l'état ANF(Argument Non Fusionnée) en appliquant la règle 7.

• Il traite l'information correspondant au pointage. Il utilise alors la règle 1. Celle-ci luiindique que si l'information courante est une donnée, et que l'information précédente est uneréférence à un argument dont l'état est ANF et dont le type est compatible avec celui de ladonnée, et que la condition de proximité temporelle est vérifiée, alors affecter la donnée àl'argument référencé dans l'information précédente. Il affecte ensuite à l'information courantel'état DF et à l'information précédente l'état AF.

• Constatant que tous les arguments de la commande possèdent une valeur, il transmetalors la structure commune contenant les valeurs des arguments à l'interface du noyaufonctionnel qui déclenche l'exécution de la commande.

2.4. ANALYSE DE LIMSI-DRAW

2.4.1. Le type de multimodalité supportéLa multimodalité supportée par LIMSI-Draw est du type synergique, les multimodalités

exclusive et alternée étant également couvertes. La multimodalité de type concurrent n'estcependant pas supportée. LIMSI-Draw permet de disposer d'une multimodalité riche, offrant àl'utilisateur plusieurs scénarios d'interaction possibles pour la réalisation d'une mêmecommande.

2.4.2. Inexistence d'une modalité dominanteUn des objectifs visés lors de la conception de LIMSI-Draw était d'obtenir une

indépendance aussi grande que possible vis-à-vis des modalités, par conséquent lesdifférentes modalités sont traitées par le contrôleur de dialogue de manière équivalente.Cependant, les traitements effectués, au cours de l'interprétation des événements, sontspécifiques à chaque modalité, mais conduisent néanmoins à une représentation unifiée desinformations transmises au contrôleur de dialogue. Il n'existe donc pas de modalité dominantedans LIMSI-Draw.


97

2.4.3. Stratégie de fusionLa stratégie de fusion adoptée dans LIMSI-Draw est du type retardée. Elle a lieu au

niveau du contrôleur de dialogue et consiste en deux opérations se déroulant en parallèle :

• la fusion locale : consiste à apparier une donnée avec une référence à un argument.• la fusion globale : consiste à rassembler dans une structure commune toutes lesdonnées nécessaires à l'exécution d'une commande.

2.4.4. Critères de fusion

2.4.4.1. La fusion localeElle a lieu entre deux informations satisfaisant aux conditions suivantes :

• La complémentarité logique : une des informations doit être une donnée etl'autre une référence à un argument,

• La compatibilité de type : le type de la donnée doit être compatible avec le typede l'argument référencé,

• la proximité temporelle : les événements ayant donné lieu à ces informationsdoivent avoir été produits dans des voisinages temporels proches. Cette proximitétemporelle est mesurée en utilisant un seuil déterminé expérimentalement.

2.4.4.2. La fusion globaleElle obéit à un certain nombre de règles:

• la structure commune doit contenir une seule information de type référence àune commande,

• une information de type donnée qui n'a pas fait l'objet d'une fusion locale estautomatiquement associée au premier argument de la commande en cours satisfaisantaux trois conditions suivantes :

1. Il n'y a pas encore eu de référence à cet argument ayant fait l'objet d'unefusion locale.

2. Il n'y a pas encore eu de donnée ayant fait l'objet d'une associationautomatique avec cet argument.

3. Son type est compatible avec celui de la donnée.

Ceci suppose qu'un ordre par défaut des arguments soit prédéfini.


98

• une information de type donnée qui n'a pas fait l'objet d'une fusion locale et quin'a pu être associée à aucun argument est ignorée. Ce comportement pourrait êtremodifié en engageant un dialogue avec l'utilisateur.

• la fusion globale est achevée lorsque tous les arguments de la commande encours ont été associés à des données.• etc.

2.4.5. Stratégie d'interprétationLa stratégie d'exploration utilisée est une stratégie à interprétation multiple. En effet, les

interpréteurs associés aux différentes modalités réalisent leurs tâches d'interprétation desévénements de façon indépendante et autonome. Ceci a le double avantage de permettre uneextension facile du système à d'autres modalités sans remise en cause de celles déjà existantes,et d'autoriser la parallélisation des processus d'interprétation. Cependant, il est évident quedans ce cas, l'interprétation d'un événement n'est pas déterministe et conduit souvent àplusieurs solutions possibles. Par exemple, la désignation d'un point appartenant à un objetpeut être interprétée soit comme une désignation d'une position spatiale, soit comme unedésignation de l'objet. La connaissance d'un autre événement accompagnant cette désignationet provenant d'une autre modalité (par exemple les mot "ça" ou "ici") pourra lever l'ambiguïtéDans ces cas de figure, les interpréteurs fournissent au contrôleur de dialogue desinformations à interprétations multiples, et c'est ce dernier qui choisit la bonne interprétationpuisque disposant de toutes les informations nécessaires (celles provenant des autresmodalités).

2.4.6. Stratégies d'interactionLes stratégies d'interaction adoptées offrent à l'utilisateur la possibilité de fournir des

données sans avoir à faire de références aux arguments. Pour éviter l'ambiguïté, un ordre pardéfaut des arguments des commandes doit être prédéfini. Cet ordre sera utilisé pourdéterminer à quel argument doit être affectée une donnée non accompagnée d'une référence àun argument.

Considérons un exemple de commande couramment utilisée dans les gestionnaires defichiers : "COPIE_FICHIER" qui permet de dupliquer un fichier. Supposons que les mots"source" et "destination" font référence respectivement au fichier source et au fichierdestination. Si on suppose, que l'ordre par défaut des arguments est, fichier source puis fichierdestination, il devient possible pour l'utilisateur de désigner uniquement les noms des fichierssans avoir à indiquer lequel est le source et lequel est le destinataire. Le premier fichier sera


99

considéré comme étant le fichier source et le second, le fichier destinataire. Par contre, s'ildésire indiquer d'abord le fichier destination, il devra accompagner sa première désignation dumot "destination". La règle peut alors s'énoncer de la façon suivante:

1. Si la donnée entrée est accompagnée d'une référence à un argument, elle sera alorsaffectée à celui-ci, sous réserve que leurs types soient compatibles et que la condition deproximité temporelle soit vérifiée.

2. Si la valeur n'est pas accompagnée d'une référence à un argument, elle sera alorsaffectée au premier argument (selon l'ordre par défaut) n'ayant pas encore de valeur et dont letype est compatible avec celui de la valeur.

Par ailleurs, l'utilisateur a la possibilité d'indiquer des données ou des références auxarguments d'une commande avant même d'indiquer la commande elle-même. Par exemple, ilpeut désigner l'objet à effacer avant même d'indiquer au système que c'est la commanded'effacement qu'il désire exécuter. Cependant cette possibilité est limitée temporellement. Eneffet, lorsque le contrôleur de dialogue rencontre une référence à une commande, il regardedans le voisinage temporel antérieur à cette information s'il n'y a pas de données ou deréférences à des arguments, relatives à cette commande. Ce voisinage temporel est déterminépar un seuil fixé arbitrairement. Par conséquent si ces données ou ces références auxarguments sont trop éloignées temporellement de la référence à la commande, elles serontignorées.

Ce comportement a été choisi délibérément car nous avons voulu donner au temps unrôle correcteur et annulateur27. Bien sûr, ceci n'est vrai que lors d'un changement decommande. Ainsi l'utilisateur peut très bien dire "met ça" accompagné d'un clic, puis attendre5 minutes ; les informations précédentes ne seront pas pour autant ignorées.

Voici un exemple illustrateur :

1- l'utilisateur prononce "met"2- il prononce "ça" en cliquant sur un objet puis il change d'avis et préfère d'abord

effacer un autre objet. Un certain temps s'écoule (quelques secondes) puis,3- il prononce le mot "efface"4- il clique sur un objet

27C'est comme si, avec le temps, le système oubliait ce qui s'était passé.


100

Sans utilisation des informations temporelles, le premier objet aurait été effacé. Letemps peut donc servir a détecter des changements d'intention chez l'utilisateur. Dans tous lescas, le second objet sera également effacé, car la commande courante reste valable tant qu'iln'y a pas eu de référence à une nouvelle commande. Par exemple, il est possible de dire"rectangle" en désignant 2 points, puis pour tracer un nouveau rectangle, effectueruniquement les désignations des sommets.

Enfin lorsqu'une commande est incomplète, le contrôleur de dialogue attend que toutesles informations nécessaires à l'exécution de cette commande soient disponibles. Ceci ne veutpas dire que les événements arrivant seront ignorés s'ils ne correspondent pas à ce qui estattendu. Ainsi, comme dans l'exemple précédent, si une nouvelle commande est entaméeavant que la précédente ait été achevée, cette dernière est annulée.

En règle générale, tant qu'une commande est incomplète les informations suivantesseront ignorées:

• une référence à un argument n'appartenant pas à la commande courante,• une donnée dont le type n'est compatible avec aucun argument de la commande

courante,• une donnée dont le type est compatible avec un des arguments de la commande

courante, mais qui (la donnée) n'a pas fait l'objet d'une fusion locale alors que c'estle cas de l'argument. Ceci exprime le fait que la fusion locale est prioritaire parrapport à l'association par défaut, et donc qu'une association par défaut ne peut pasdéfaire une fusion locale. Seule une fusion locale peut défaire une autre fusionlocale.

Par contre, les informations suivantes ne seront pas ignorées :

• une référence à une commande,• une référence à un argument de la commande,• une donnée dont le type est compatible avec un des arguments de la commande,

cette donnée ayant fait l'objet d'une fusion locale,• une donnée dont le type est compatible avec un des arguments de la commande, et

qui (la donnée) n'a pas fait l'objet d'une fusion locale, et telle que l'argument enquestion n'a pas fait lui non plus l'objet d'une fusion locale.


101

2.4.7. Utilité des références aux argumentsLes références aux arguments sont particulièrement utiles dans les deux cas suivants:

2.4.7.1. CorrectionSi l'utilisateur se rend compte qu'il vient d'entrer une mauvaise donnée, il a toujours la

possibilité de la rectifier. Il lui suffit pour cela d'entrer la nouvelle donnée en l'accompagnantd'une référence à l'argument auquel elle doit être affectée. L'ancienne donnée sera alorsremplacée par la nouvelle. La correction peut être répétée autant de fois que l'utilisateur ledésire.

Reprenons l'exemple de la commande de copie de fichiers. Si l'utilisateur indique unfichier source, puis se rend compte qu'il s'est trompé, il lui suffit alors, pour corriger sonerreur, d'indiquer un autre nom de fichier tout en prononçant le mot "source". L'ancien nomsera alors remplacé par le nouveau.

2.4.7.2. Souplesse de la syntaxe d'interactionL'utilisation des références aux arguments permet de disposer d'une syntaxe d'interaction

très souple. Ainsi l'utilisateur n'est plus contraint de fournir les données aux commandes qu'ildésire exécuter dans un ordre bien précis. En faisant accompagner ces données des référencesaux arguments correspondants, il pourra alors les produire dans l'ordre qui lui convient lemieux.

Comme vu précédemment, si l'utilisateur désire indiquer d'abord le nom du fichierdestination, puis le nom du fichier source, il lui faudra alors simplement prononcer le mot"destination" lors de l'indication du premier fichier. On peut remarquer que la prononciationdu mot "source" lors de l'indication du second fichier est inutile. En effet cette deuxièmedonnée (nom du fichier source) sera de toute façon affectée au premier argument de typecompatible et n'ayant pas encore de valeur donc à l'argument correspondant au fichier source.

L'entrée des données selon des séquences différentes permet dans certains cas dedisposer de différents types de feed-back de contrôle. Par exemple, pour la commande de tracéde cercles, si l'utilisateur décide d'indiquer d'abord le centre du cercle puis son rayon, il pourradans ce cas disposer d'un contrôle continu sur le rayon. Par contre, s'il indique d'abord le rayonpuis le centre, il pourra disposer dans ce cas d'un contrôle continu sur le centre du cercle. Dansle cas de commandes à plus de deux arguments, le contrôle continu peut être obtenu sur ledernier argument indiqué.


102

2.4.8. Traitement des arguments optionnelsLe problème posé par les arguments optionnels concerne la détermination de la fin des

énoncés exprimés par l'utilisateur. En effet lorsqu'une commande possède des argumentsoptionnels, on ne peut savoir à priori si l'utilisateur va faire référence à ces arguments dansson énoncé ou pas. Ceci est particulièrement vrai dans le cas de la parole. Par exemple si onconsidère une commande "IMPRIMER_DOCUMENT", et si on suppose que cette commandepossède deux arguments qui sont le document à imprimer (argument obligatoire) et le nombred'exemplaires (argument optionnel), on ne peut alors savoir si l'utilisateur, en exprimant sonénoncé, va préciser le nombre d'exemplaire ou s'il va l'omettre ("imprime ce fichier" ou"imprime ce fichier en 3 exemplaires").

Pour résoudre ce problème, trois solutions peuvent être envisagées:

2.4.8.1. Indication explicite de fin d'énoncéCette première solution consiste à obliger l'utilisateur à indiquer explicitement la fin de

son énoncé, par exemple par l'intermédiaire d'un bouton OK, ou en prononçant un motparticulier, ou en faisant un geste particulier ou encore en appuyant sur une touche particulièredu clavier (ce qui est le cas de la touche ENTREE dans les shells de commandes UNIX, DOS,etc.).

2.4.8.2. Utilisation d'un délai d'attenteCette seconde solution consiste à ne considérer l'énoncé de l'utilisateur comme étant

complet, qu'après avoir attendu un certain intervalle de temps t. Par convention, si au cours decet intervalle aucune entrée n'est détectée, cela signifiera que l'utilisateur a fini d'exprimer sonénoncé.

2.4.8.3. Se ramener à des commandes dont les arguments sont tous obligatoires.Cette troisième solution consiste à remplacer une commande ayant n arguments

optionnels, par n+1 commandes dont les arguments seront tous obligatoires.

L'utilisation d'un argument optionnel repose sur l'existence d'une valeur par défaut quiest utilisée lorsque l'argument est omis. Par exemple, pour la commande "IMPRIMER",lorsque le nombre d'exemplaire est omis, on utilise une valeur par défaut égale à 1.

Par contre, lorsque la valeur de l'argument optionnel est précisée, deux cas sontpossibles :


103

1. La commande est exécutée avec la valeur précisée, mais la valeur par défaut del'argument reste inchangée.

2. La commande est exécutée avec la valeur précisée, et la valeur par défaut del'argument est mise à jour

Etant donnée une commande C à m arguments obligatoires et n arguments optionnels Aii=1..n ; cette commande sera remplacée par les n+1 commandes suivantes :

• Une commande C' identique à C, mais ayant comme arguments, uniquement les marguments obligatoires. Les n arguments optionnels Ai seront remplacés par n variablesglobales Vi. La commande C' utilisera ces variables globales au lieu des argumentsoptionnels.

• n commandes Ci i=1..n. Chaque commande Ci sera chargée de la mise à jour de lavariable Vi et possédera un seul argument (obligatoire) qui correspondra à la nouvelle valeurqu'il faut affecter à la variable Vi.

Ainsi l'exécution de la commande C, avec indication d'une valeur pour l'argumentoptionnel Ai, sera remplacée par l'exécution en premier lieu de la commande Ci pour fixer lavaleur de Vi, puis de la commande C'.

REMARQUESi l'argument Ai correspond au cas où la valeur par défaut doit rester inchangée, la

commande C' devra veiller, juste avant de terminer, à rétablir la variable Vi à sa valeur pardéfaut.

Choix d'une solutionLa première méthode permet d'avoir une réponse immédiate du système, mais en

contrepartie, elle impose une contrainte à l'utilisateur. La seconde présente l'inconvénientd'augmenter sensiblement les temps de réponse du système. Enfin on peut penser que ladernière méthode crée une surcharge de l'utilisateur, dans le sens où au lieu d'exécuter unecommande, il devra en exécuter deux ou plusieurs selon le nombre d'arguments optionnelsqu'il voudra préciser. En fait il convient de nuancer cet argument car ceci ne se produira pastrès souvent. En effet, un argument est mis en option lorsqu'on sait que c'est sa valeur pardéfaut qui sera utilisée le plus souvent. Par conséquent, on peut dire qu'en général cettesurcharge sera peu fréquente. De plus cette solution évite les inconvénients des deux solutionsprécédentes. C'est pourquoi c'est cette dernière méthode qui a été adoptée.


104

2.4.9. Traitement des anaphores et des ellipsesLIMSI-Draw peut traiter des anaphores de niveau n-1. L'article "le" est utilisé pour

référencer le dernier objet manipulé. Par exemple, un objet qui vient d'être créé peut êtreimmédiatement effacé grâce à la commande vocale "efface le". Ce niveau d'anaphore a étésuffisant et même peu utilisé par les sujets au cours de l'évaluation (cf. §. 2.5). Ceci s'expliqueprobablement par le fait que LIMSI-Draw n'est pas une application ou la composante orale estprédominante. Des cas d'ellipses simples sont également traités à travers la prise en comptedes sélections courantes ou des valeurs par défaut.

2.4.10. Exemple comparatifICP-Draw [Caelen 91a] [Caelen 91b] [Caelen 91c] est une application graphique

similaire à LIMSI-Draw concernant le domaine d'application. Cependant les architecturesmises en oeuvres dans ces deux systèmes sont très différentes. ICP-Draw utilise une structurede tableau noir pour la fusion des informations alors que LIMSI-Draw utilise un ensemble derègles. ICP-Draw n'exploite pas de manière optimale les informations temporelles dans leprocessus de fusion. Il se suffit de la séquence des événements. Or comme nous l'avons vudans le chapitre précédent, la séquence seule n'est pas toujours suffisante pour uneinterprétation correcte des énoncés. LIMSI-Draw présente en ce sens une fusion plus robusteen exploitant non seulement des critères logiques et sémantiques mais également le critère dela proximité temporelle. Par ailleurs, LIMSI-Draw offre une syntaxe d'interaction très souple,et l'utilisateur est complètement libre quant au choix des modalités ou des combinaisons desmodalités qu'il préfère. Enfin, LIMSI-Draw est capable de gérer un feed-back de contrôlecontinu dans la création et la manipulation des objets graphiques (par exemple, contrôlecontinu de la taille d'un objet lors de sa création), aspect qui n'est pas présent dans ICP-Draw.En revanche, ICP-Draw présente un traitement plus élaboré du langage et des situations dedialogue.

2.5. EVALUATIONAu cours de son stage de DEA, D. Fass [Fass 94] a réalisé une étude relative au

domaine des sciences cognitives en utilisant LIMSI-Draw comme plate-forme multimodale.Cette étude entrait dans le cadre de la collaboration entre les deux groupes CognitionHumaine et Communication Non Verbale du LIMSI-CNRS. Elle avait pour but principald'étudier les stratégies cognitives mises en oeuvre par des sujets dans la réalisation de tâchesfaisant appel à l'imagerie mentale, dans un contexte multimodal réel (avec les contraintesinduites par la technologie actuelle). Nous avons profité de cette occasion pour étudiercertains aspects liés plus spécifiquement à l'utilisation d'une interface multimodale. Dans lasuite nous reprendrons uniquement les résultats liés à ce deuxième volet de l'étude.


105

2.5.1. Description de l'expérienceLes sujets devaient réaliser quatre tâches différentes de complexité croissante.La première tâche consistait à reproduire sur l'écran de LIMSI-Draw une figure que le

sujet avait sous les yeux (fig. 33) et qui comportait 9 formes géométriques simples utilisant aumaximum 6 couleurs différentes.

Figure 33. Figure utilisée dans la première tâche

Dans la seconde tâche, il était demandé aux sujets de mémoriser une figure du mêmetype que la précédente, et de la reproduire ensuite en utilisant LIMSI-Draw.

La troisième tâche consistait à fournir aux sujets une description verbale d'une figure.Ceux-ci devaient alors se construire une image mentale de cette figure, la mémoriser puis lareproduire. Pour aider les sujets, la description de la figure suivait un ordre linéaire :

En haut à gauche, il y a un rectangle vert.A droite du rectangle vert, il y a un cercle rouge.A droite du cercle rouge, il y a un triangle violet.

Sous le rectangle vert, il y a un triangle jaune.A droite du triangle jaune, il y a un rectangle marron.A droite du rectangle marron, il y a un cercle blanc.

Sous le triangle jaune, il y a un rectangle blanc.A droite du rectangle blanc, il y a un triangle rouge.A droite du triangle rouge, il y a un cercle vert.


106

La dernière tâche enfin était du même type que la troisième sauf que l'ordre dedescription était cette fois-ci aléatoire.

L'expérience a été menée avec un ensemble de 16 sujets parmi lesquels figuraient desinformaticiens et des non informaticiens (médecin, journaliste, architecte...).

2.5.2. Quelques paramètres étudiésLa multimodalité "riche" offerte par LIMSI-Draw a permis de mettre à disposition des

utilisateurs différents scénarios d'interaction possibles pour la réalisation de leurs tâches. Cecinous a permis d'analyser les paramètres décrits ci-dessous.

2.5.2.1. Relation Média <---> Type informationIl s'agit de voir s'il existe une dépendance entre le type de l'information communiquée

par l'utilisateur et le média utilisé. On remarque d'après la fig. 34 [Fass 94] que lorsqu'il s'agitd'exprimer le nom de la commande à exécuter (par exemple "rectangle"), les utilisateurspréfèrent utiliser la parole (95%). La même remarque est valable pour les noms de couleuravec un pourcentage légèrement inférieur (86%). Enfin concernant les arguments de forme(sommets d'un triangle, centre d'un cercle etc.) et de position, on constate une préférence de lapart des utilisateurs pour l'écran tactile (64%) par rapport à la souris (36%), ce qui est assezinattendu vu que la majorité des sujets étaient déjà habitués à l'utilisation de la souris. Uneanalyse plus détaillée montre qu'il y a rarement alternance dans l'utilisation de l'écran tactileou de la souris. Les utilisateurs choisissent en général soit l'écran tactile, soit la souris, puisn'utilisent plus que le média qu'ils ont choisi pour les opérations de pointage.

Commande Couleur Arguments de forme etde position

Parole 95% 86% 0%Ecran tactile 2% 8% 64%

Souris 3% 6% 36%


107

ParoleEcrantactile Souris

Commande

Couleur

Arguments de forme et de position0%

10%20%30%40%50%

60%

70%

80%

90%

100%

Figure 34. Relation Média <---> Type d'Information

2.5.2.2. Combinaison des médiasLa fig. 35 montre de quelle manière les médias ont été utilisés par les sujets pour

réaliser les tâches demandées. On remarque tout d'abord que l'utilisation des médias demanière isolée est très faible, la souris ayant le plus haut pourcentage (4,75%). Lacombinaison (parole, écran tactile) possède le plus grand pourcentage (57,5%) contre33,125% pour la combinaison (parole, souris). La combinaison (écran tactile, souris) estinexistante, comme on pouvait facilement s'y attendre, alors que la combinaison (parole, écrantactile, souris) a été utilisée une seule fois par un sujet qui s'est embrouillé un instant.

Tâche1

Tâche2

Tâche3

Tâche4

Total

Parole seule 5% 2% 1% 0% 2%Ecran tactile seul 3% 3% 2% 2% 2,5%

Souris seule 0% 3% 7% 9% 4,75%Parole et écran tactile 67% 55% 51% 57% 57,5%

Parole et souris 25% 37% 38,5% 32% 33,125%Ecran tactile et souris 0% 0% 0% 0% 0%

Parole et écran tactile et souris 0% 0% 0,5% 0% 0,125%


108

Tâche1

Tâche2

Tâche3

Tâche4

Parole et écran tactile et sourisEcran tactile et souris

Parole seuleEcran tactile seul

Souris seuleParole et souris

Parole et écran tactile

0%

10%

20%

30%

40%

50%

60%

70%

Figure 35. Combinaison des médias

2.5.2.3. Séquentialité / Simultanéité (geste, parole)Il est intéressant de voir de quelle manière les différents sujets ont combiné le geste à la

parole. D'après la fig. 36 on peut voir que dans la majorité des interactions, la parole précèdele geste (62,25%). Un pourcentage important apparaît pour la combinaison simultanée dugeste et de la parole (30,25%). Ce pourcentage aurait très probablement été plus important sile système de reconnaissance vocal était plus performant. En effet, il a été souvent remarquéque les sujets prononçaient le nom d'une commande, vérifiaient sur l'écran que le résultat de lareconnaissance était correct, puis complétaient leur commande en faisant les gestes dedésignation nécessaires. Ce manque de confiance par rapport au système de reconnaissancevocale semble donc expliquer le pourcentage élevé des interactions dans lesquelles la paroleprécède le geste.

Tâche 1 Tâche 2 Tâche 3 Tâche 4 TotalGeste avant

parole12% 9% 7,5% 1,5% 7,5%

Parole avantgeste

61% 63% 66% 59% 62,25%

Geste et parolesimultanés 27% 28% 26,5% 39,5% 30,25%


109

Tâche 1Tâche 2

Tâche 3Tâche 4

Geste avant parole

Geste et parole simultanés

Parole avant geste

0%

10%

20%

30%

40%

50%

60%

70%

Figure 36. Séquentialité / Simultanéité (geste, parole)

2.5.2.4. Utilisation de la paroleOn remarque facilement ici que les utilisateurs ont tout de suite compris après la

première tâche que les performances du système de reconnaissance étaient plus élevées enmots isolés (71,75%) qu'en parole continue (28,25%). Cependant cette prudence par rapportau système de reconnaissance diminue avec la complexité de la tâche. Celle-ci fait doncoublier un peu aux utilisateurs les contraintes du système.

Tâche 1 Tâche 2 Tâche 3 Tâche 4 TotalParole

continue39% 18% 28% 28% 28,25%

Motsisolés

61% 82% 72% 72% 71,75%


110

Tâche 1Tâche 2

Tâche 3Tâche 4

Parole continue

Mots isolés0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

Figure 37. Utilisation de la parole

2.5.3. Conclusion sur l'évaluationIl convient d'insister sur le fait que l'aspect de l'étude lié à l'utilisation de l'interface

multimodale n'était pas l'objectif principal de cette évaluation. Cependant, il faut noter quec'est la première étude qui ait été menée en utilisant une véritable interface multimodaleprenant en considération les contraintes induites par la technologie actuelle, notamment cellesliées à la reconnaissance de parole. Elle a permis d'effectuer des observations intéressantes.Par exemple, on a pu constater une spécialisation des modalités en fonction du type del'information véhiculée. L'utilisation de la parole et du geste de désignation de manièrecombinée a été très fréquente, avec une importante préférence pour l'utilisation de l'écrantactile plutôt que de la souris en ce qui concerne le geste. Ceci s'explique probablement parl'aspect "plus naturel" de la désignation tactile. Il est également apparu que les utilisateursfaisaient souvent précéder la parole au geste dans l'expression de leurs énoncés (sans que celasoit systématique). Nous pensons que cette observation est liée au degré de confiance accordépar les utilisateurs au système de reconnaissance de parole, ce qui les a souvent amenés àvérifier que les mots prononcés avaient bien été reconnus avant de poursuivre la formulationde leur énoncé. Cette raison les a également amenés à formuler plus souvent des mots isolésque de la parole continue, les performances du système de reconnaissance étant moins bonnesdans ce second cas.


111

2.6. CONCLUSIONDans ce chapitre, nous avons présenté une première réalisation d'interface multimodale.

Cette première expérience nous a permis d'être confronté à des problèmes concrets posés parles interfaces multimodales. Elle nous a en particulier permis de mettre en évidencel'importance de l'aspect temporel dans ce type d'interface.

Nous avons pu remarquer que la fusion dans LIMSI-Draw était réalisé à un niveausémantique, c'est à dire une fois que les événements ont été interprétés en informations d'unniveau d'abstraction plus élevé. Cette fusion nécessite donc une interprétation qui estnécessairement dépendante du domaine de l'application. Nous avons vu dans l'architecture deLIMSI-Draw que les interpréteurs avaient besoin d'accéder à la base des objets pour effectuercorrectement leur tâche d'interprétation. Cette base des objets fait normalement partie dunoyau fonctionnel. Elle représente des entités propres au domaine de l'application. En gardantl'architecture adoptée dans LIMSI-Draw et en changeant de domaine d'application nous seronsdonc obligatoirement amenés à réécrire les interpréteurs afin qu'ils puissent exploiter lesnouvelles entités propres à ce nouveau domaine d'application et effectuer la tâched'interprétation de manière correcte.

On voit donc à travers LIMSI-Draw qu'une fusion à un haut niveau d'abstraction estforcément dépendante du domaine de l'application car elle implique une interprétation liée audomaine de l'application. Nous verrons dans le chapitre suivant que si l'on veut concevoir desoutils génériques pour les interfaces multimodales, nous serons obligés de réaliser la fusion àun niveau inférieur, au niveau des événements, avant toute interprétation. Ceci pourra alorsgarantir la généricité de notre outil.

Par ailleurs, nous avons vu dans LIMSI-Draw comment le contrôle continu a été traité.Nous avons pu remarquer qu'il n'était possible d'avoir un contrôle continu que sur le dernierargument référencé. Ceci est dû au fait qu'une commande ne peut être exécutée que lorsqu'elleest complète. Nous verrons que cette contrainte sera levée dans l'outil qui sera présenté dans lechapitre suivant. Il sera alors possible de produire des messages de sortie ou d'exécuter desactions particulières avant même qu'une commande soit complète.

Chapitre3

Chapitre 3. SPECIMEN : un outil pour la spécification des interactions multimodales

113

Chapitre 3

SPECIMEN: un outil pour la spécification desinteractions multimodales

3.1. INTRODUCTIONCe chapitre est consacré à la présentation d'un outil d'aide au développement des

interfaces multimodales. Les besoins en termes d'outils ont toujours été très importants dans ledomaine des interfaces Homme-Machine. La méthode de conception itérative des interfaces etle désir de rendre la construction de celles-ci accessible à des utilisateurs non informaticiensexpliquent en grande partie ces besoins. Si de nombreux outils existent aujourd'hui pour laconstruction des interfaces graphiques à manipulation directe, il en est tout autrement pour lesinterfaces multimodales.

L'outil que nous décrivons dans ce chapitre permet de spécifier de manière simple desinteractions multimodales et rend transparents pour le développeur les problèmes spécifiquesà ce type d'interfaces. Nous avons conçu et développé un modèle hybride pour lareprésentation des interactions multimodales. Ce modèle combine le modèle des réseaux detransitions augmentés à un modèle de spécification par messages. Il présente l'avantage d'allierl'adéquation des ATNs (Augmented Transitions Networks) pour la représentation desstructures langagières à la souplesse d'un modèle à événements étendu aux besoins spécifiquesdes interactions multimodales. Les interactions multimodales en exploitant aussi bien desmodalités langagières (langage parlé, écrit, langue des signes, etc.) que des modalitésactionnelles (geste ergotique, désignation optique, etc.), intègrent au sein d'une mêmeinterface aussi bien un modèle d'interaction anthropomorphique qu'un modèle physique. Ildevient par conséquent nécessaire de disposer d'outils permettant de construire des interfacessupportant simultanément ces deux modèles.


114

Après avoir décrit les principaux types d'outils d'interfaces existants, quelques notionsfondamentales sur les ATNs seront rappelées. Nous justifions ensuite le choix de notremodèle puis décrivons la structure de SPECIMEN. Une attention particulière sera accordée àla description des différentes catégories de messages et des opérateurs de composition quenous avons introduit dans le modèle. Nous indiquerons ensuite comment s'effectue la fusiondans SPECIMEN pour la génération des messages multimodaux et décrirons la manière dontils sont représentés. Nous terminerons ce chapitre en donnant un exemple de spécificationd'une interaction multimodale.

3.2. POURQUOI DES OUTILS D'INTERFACES ?Depuis toujours l'homme a cherché à fabriquer des outils qui puissent l'aider et lui

faciliter la réalisation de ses tâches. Les outils conçus doivent posséder deux caractéristiquesprincipales : être réutilisables pour une même tâche et pouvoir servir dans différentes tâches.Dans le domaine des interfaces Homme-Machine les besoins en termes d'outils sont trèsimportants. D'une part, la méthode itérative qui est suivie pour la construction des interfaces etd'autre part, le désir de rendre cette construction des interfaces accessibles à des utilisateursnon informaticiens, expliquent en grande partie ces besoins.

3.2.1. Quelques statistiquesDe récentes statistiques [Myers 93b] ont montré que 48% du code d'une application

interactive concernait l'interface. Le temps consacré à l'interface durant la phase de conceptionde l'application est de 45%, de 50% durant la phase d'implémentation et de 37% durant laphase de maintenance. Ces chiffres montrent l'importance de l'interface dans une applicationinteractive. Lorsqu'on constate que la majorité des développeurs (74%) utilisent des outilsd'interfaces, on peut facilement imaginer ce que seraient ces chiffres si les interfacesgraphiques actuelles étaient développées sans l'aide d'outils. Il apparaît que 34% des systèmesinteractifs reposent sur l'utilisation de boîtes à outils, 27% sur les UIMS (User InterfaceManagement System)28, 14% sur des générateurs d'interfaces et 26% sont construits sansl'aide d'outils.

3.2.2. ButsL'utilisation d'un outil d'interface peut viser différents buts [Myers 93a] :

28SGIU en Français (Système de Gestion d'Interfaces Utilisateur).


115

• faciliter la conception de l'interface en partant d'une spécification de la tâche,• faciliter la mise en oeuvre de l'interface en partant d'une spécification de la conception

de l'interface,• construire des interfaces faciles à utiliser,• permettre aux concepteurs de tester rapidement différentes conceptions,• permettre à des non-développeurs de concevoir et de mettre en oeuvre des interfaces,• offrir à l'utilisateur final la possibilité de personnaliser l'interface,• assurer la portabilité des applications interactives,• permettre l'évaluation automatique des interfaces.

A titre d'exemple, considérons l'application de la fig. 38.

Figure 38. Exemple d'application interactive

Sans outils d'interface, le développement d'une telle application nécessiterait d'écrire ducode pour :


116

• dessiner les icônes de la palette des outils, des couleurs, et des épaisseurs,• gérer les menus,• gérer les objets du domaine (par exemple mettre à jour la liste des objets dessinés ainsi

que leurs propriétés),• gérer les événements d'entrée (clavier, souris) et surtout leur séquencement,• dessiner les objets de la zone de travail.

Une telle approche possède de nombreux inconvénients :

♦ dessiner des objets graphiques en utilisant un langage de programmation est unetâche ardue qui de plus élimine nécessairement l'implication de graphistes,

♦ écrire pour chaque application développée du code pour la gestion de menus estun effort de programmation inutile car ce type d'objet se retrouve dans la quasi-totalitédes interfaces graphiques. Il est préférable d'écrire une seule fois un code qui soitréutilisable pour différentes applications.

♦ la syntaxe de l'interaction est figée et difficile à modifier car elle est noyée ausein du code et ne transparaît pas de manière séparée.

♦ il n'y a pas de séparation entre l'interface et le noyau fonctionnel,♦ le code produit est en général spécifique à un environnement donné et n'est

donc pas portable,♦ il est pratiquement impossible d'avoir des informations sur l'interface

(propriétés des différents objets, syntaxe de l'interaction, etc.), aspect qui peut être trèsimportant notamment pour l'adaptation des interfaces à des utilisateurs handicapéscomme il sera décrit dans le chapitre 4.

Les outils d'interface permettent aujourd'hui de remédier à la plupart de cesinconvénients. Il est néanmoins important de signaler qu'on ne trouve pas à l'heure actuelle ausein d'un seul et même outil toutes les caractéristiques nécessaires pour répondre à tous cesproblèmes. Lorsque c'est le cas, l'outil en question ne peut alors servir en général que pour uneclasse d'application bien particulière.

L'utilisation d'outils d'interface permet par ailleurs de disposer d'applications plusfiables. Moins il y a de code écrit à la main, moins il y a de risques de "bugs". Elle permetégalement d'assurer une plus grande cohérence de l'interface pour différentes applications, unmême outil produisant toujours le même style d'interface. Ceci assure par conséquent une plusgrande facilité d'utilisation des applications interactives et une phase d'apprentissage plusrapide. Les principes appris au cours de l'utilisation d'une application sont ainsi directementapplicables dans une autre application construite avec le même outil.


117

3.3. LES DIFFERENTS TYPES D'OUTILSNous décrivons dans ce paragraphe les principaux types d'outils d'aide à la construction

des interfaces.

3.3.1. Les boîtes à outilsCoutaz définit une boîte à outils comme étant une bibliothèque de procédures adaptées à

l'écriture d'interfaces Homme-Ordinateur [Coutaz 88]. Myers fournit une définition plus large,en omettant de donner des précisions sur la forme logicielle sous laquelle se présente cetteboîte à outils (pas forcément des procédures) : une boîte à outils est une librairie de techniquesd'interaction pouvant être utilisées par un programme [Myers 93a]. Ces techniquesd'interaction peuvent être, par exemple, implémentées sous forme de fonctions ou de classesd'objets. Une caractéristique commune à toutes les boîtes à outils est qu'elles s'adressentprincipalement aux programmeurs. Elles nécessitent une période d'apprentissage relativementlongue, car elles comportent en général plusieurs centaines de fonctions, ou plusieurs dizainesde classes comportant elles-mêmes plusieurs dizaines de données et de méthodes. Cependant,une fois leur utilisation bien maîtrisée, elles permettent de développer rapidement desinterfaces incluant les objets d'interaction standards des interfaces graphiques, tels que lesmenus, les boutons poussoirs, les boutons radio, les cases à cocher, les boites à liste, les boitesde dialogue, etc. (fig. 39).

3.3.2. Les boîtes à outils génériquesLes boîtes à outils offrent en général les mêmes fonctionnalités. Elles différent surtout

par l'aspect de présentation qu'elles produisent ("look and feel"). C'est pourquoi certainssystèmes fournissent une boîte à outils générique permettant d'être liée à différentes boîtes àoutils réelles. Cette boîte à outils générique regroupe les fonctionnalités communes à toutesles boîtes à outils réelles qu'elle permet d'englober. C'est le cas par exemple du système XVT[XVT 91] qui permet de produire des interfaces ayant différents look and feel (Motif,Openlook, Macintosh, Windows et OS2).


118

Boîte de dialogue

Boutons poussoirsBoutons radioCases à cocher

Boîte à liste

Scroll-bar horizontale

Barre de menus

Menu avec mnémoniques et raccourcis-clavier

Figure 39. Exemples d'objets interactifs


119

3.3.3. Les squelettes d'applicationUn des inconvénients des boîtes à outils a trait à la duplication, souvent fréquente, du

même code d'une application à une autre. Par exemple, pour créer et afficher une boîte dedialogue, le développeur devra appeler toute une série de fonctions, permettant entre autresd'initialiser différents paramètres, avant de pouvoir atteindre son objectif. Cet inconvénient alargement contribué à l'apparition des squelettes d'application. Un squelette d'applicationfournit au développeur, une sorte de charpente réutilisable, dans laquelle il devra remplircertains trous et adapter certaines parties selon ses besoins particuliers. La plupart dessquelettes d'application existants adoptent une approche orientée objet qui est bien adaptée àce type d'outils. Elle permet, par exemple, d'affecter au constructeur d'un objet interactif toutesles fonctions d'initialisation nécessaires avant de pouvoir utiliser cet objet, et elle fournit àtravers la notion d'héritage un mécanisme efficace pour répondre aux besoins particuliersd'une application donnée. Bien qu'un squelette d'application facilite grandement la mise enoeuvre d'un système interactif en guidant le développeur dans sa tâche de programmation et enlui offrant un moule de départ, il demeure cependant vrai que toute extension nécessite unebonne connaissance de la boîte à outils sous-jacente. Des outils d'un plus haut niveau sontalors nécessaires pour remédier à cet inconvénient.

3.3.4. Les éditeurs de ressourcesL'utilisation d'une boîte à outils impose au développeur de spécifier de manière

procédurale les attributs des objets interactifs (coordonnées de position, taille, couleur, etc.).L'écriture et la modification de ces attributs (particulièrement fréquente vu la méthodeitérative de construction des interfaces) devient alors une tâche ardue. Les éditeurs deressources (fig. 40) la simplifient considérablement et la rendent même accessible à des noninformaticiens. Ils permettent de créer et de modifier rapidement et de manière interactive (enutilisant une interface graphique) les différents objets interactifs standards (menus, boîtes dedialogue, icônes, etc.). Les éditeurs de ressources génèrent alors le code que le développeuraurait dû écrire lui même. Ce code devra être lié au reste de l'application en cours dedéveloppement. Les éditeurs de ressources ne modifient pas le niveau de programmationnécessaire pour le développement de l'interface, mais allègent la tâche de programmation[Jurain 91].


120

Figure 40. L'éditeur de ressources de Borland pour Windows

3.3.5. Les générateurs d'interfacesLes générateurs d'interfaces ressemblent aux éditeurs de ressources. Comme ces

derniers, ils ne peuvent traiter, en général, que la partie statique de l'interface (cf. § 3.3.6).Cependant, ils apportent une aide supplémentaire en facilitant la spécification des liens entrel'interface et le noyau fonctionnel. Ils permettent d'indiquer de manière interactive lecomportement des objets interactifs. Ce comportement est spécifié à travers les procédures dunoyau fonctionnel qui seront attachées aux objets (fonctions callback) et à travers les typesd'événements qui déclencheront l'exécution de ces procédures. Naturellement, les procéduresdevront être écrites dans un langage de programmation conventionnel.

Les outils de type HyperCard sont un cas particulier de générateurs d'interfaces. Ilsorganisent l'interface en un réseaux de pages écrans statiques, chaque page pouvant contenirdivers objets interactifs. Des actions de navigation entre les pages peuvent être facilementassociées aux objets (boutons). Certains outils supportent un langage spécifique qui permet deprogrammer des actions plus élaborées que de simples opérations de navigation.


121

3.3.6. Les UIMSLes types d'outils précédemment décrits aident principalement à la construction de la

partie statique29 de l'interface. Nous entendons ici par statique, la partie de l'interface qui estentièrement prédéterminée avant la phase d'utilisation effective de l'application. Ceci nesignifie pas que cette partie soit figée. Par exemple, un menu peut comporter des rubriques quipeuvent changer d'état (devenir grisées) en fonction du contexte. Les menus contextuelspeuvent même changer de rubriques. Cependant tout ce comportement est défini avant mêmela phase d'utilisation. Par opposition, nous entendons par partie dynamique de l'interface30, lapartie dont l'évolution est déterminée par les actions de l'utilisateur, c'est à dire au cours de laphase d'utilisation. Cette partie correspond en général à ce qui est communément appelé lazone de travail dans une fenêtre. Les types d'outils précédents ne fournissent pas d'aide réelle àla construction de cette partie dynamique de l'interface. Celle-ci, comporte en général undialogue plus complexe et nécessite la gestion de séquences d'interaction plus évoluées que lasimple réaction d'un objet interactif à un événement. Les UIMS sont initialement apparus pourcombler cette lacune. Le terme UIMS (User Interface Management System) lui même estapparu officiellement pour la première fois en 1982 lors d'un Workshop qui s'est déroulé àSeattle et qui était consacré aux techniques d'interaction graphique [Thomas 83]. Le choix dece terme a été fortement inspiré par le terme DBMS (Data Base Management System31).Ainsi, si un DBMS libère de la tâche de gestion des données, un UIMS doit libérer d'une partle développeur du noyau fonctionnel de toutes les tâches d'interaction et d'autre part simplifierau maximum la tâche d'implémentation au développeur de l'interface. Cependant, la définitiond'un UIMS a évolué au fil des années. Il a initialement été défini comme étant la partielogicielle d'un système interactif qui assure la gestion de l'interaction (séquencement deséchanges) entre l'utilisateur et le noyau fonctionnel. Il doit surtout reposer sur unespécification de l'interaction entre ces deux entités qui précise de manière détaillée lastructure de l'interaction. Par la suite, le rôle attribué à un UIMS est devenu plus large. Nonseulement il doit simplifier la tâche d'implémentation de l'interface, mais il doit égalementfaciliter la tâche de conception et d'évaluation de celle-ci. Ainsi, dans [Beaudouin-Lafon 91],on peut trouver la définition suivante : "un UIMS est une collection d'outils qui permettent deconcevoir, implémenter, tester et maintenir des applications interactives".

La fig. 41 présente l'architecture d'un UIMS vue selon Olsen [Olsen 92].

29Egalement appelée interface de contrôle.30Egalement appelée interface de données.31SGBD en Français (Système de Gestion de Bases de Données).


122

Contrôleurde Dialogue

Contrôleur Lexical

Bibliothèque Graphique

NoyauFonctionnel


InterfaceLexicale

Descriptiondu Dialogue

Description dela Présentation

InterfaceSémantique

Figure 41. Architecture d'un UIMS [Olsen 92]

On peut voir sur cette figure que les descriptions du dialogue et de la présentation sontau centre de l'architecture. Le contrôleur de dialogue et le modèle de description sous-jacentont été au coeur des recherches sur les UIMS. Différents modèles ont été utilisés à cet effet.Nous renvoyons le lecteur à l'ouvrage d'Olsen [Olsen 92] ou à [Myers 93a] pour une largerevue des différents modèles utilisés pour la représentation du dialogue dans les UIMS. Nostravaux sur SPECIMEN si situent également au niveau du contrôle et de la spécification dudialogue (ou plus précisément de l'interaction) mais cette fois dans des interfacesmultimodales. Nous présentons plus en détail dans la suite, le modèle des réseaux detransitions que nous avons combiné dans SPECIMEN à un modèle à événements (ou àmessages, pour être plus précis) étendu.

3.4. LES RESEAUX DE TRANSITIONSLes réseaux de transitions sont initialement apparus dans le cadre de la théorie des

langages. Nous présentons dans ce qui suit un bref rappel sur les grammaires formelles pourintroduire les machines abstraites (ou machines à états) ce qui nous amènera aux réseaux detransitions.


123

3.4.1. Les grammaires formellesUne grammaire formelle permet de décrire un langage par un ensemble de règles dites

règles de production. Formellement, elle est définie par un quadruplet (VN,VT,R,S) :

VN représente l'ensemble des non terminaux,VT est le vocabulaire terminal,R est un ensemble de règles,S est le symbole de départ.

Il existe différents types de grammaires. Nous nous intéresserons dans la suite plusparticulièrement aux types qui ont été définis par Chomsky, car ils nous permettrontd'introduire les réseaux de transitions augmentés. Chomsky a défini quatre types degrammaires en fonction de conditions de forme imposées aux règles de production. SoitV=VN ∪ VT. Soit V+ l'ensemble des chaînes quelconques de terminaux et/ou non terminauxnon vides, et V*=V+ ∪ {ε} où ε désigne la chaîne vide.

3.4.1.1. Grammaire de type 0 ou grammaire non restrictiveLes règles de la grammaire sont de la forme :α ---> β

avec α appartenant à V+ et β appartenant à V*.Aucune condition particulière n'est imposée aux règles. C'est le type de grammaire

le moins utilisé car trop arbitraire et peu structuré.

3.4.1.2. Grammaire de type 1 ou grammaire contextuelleLes règles sont de la forme:αNβ ---> αµβavec α, µ, β appartenant à V* et N appartenant à VN.

Ces règles permettent de prendre en compte les phénomènes contextuels. Ellesexpriment le fait que N peut se réécrire µ dans le contexte α β. Ce type de règles estcourant dans les descriptions grammaticales du langage naturel.

3.4.1.3. Grammaire de type 2 ou grammaire hors-contexteLes règles sont de la forme:N ---> αavec α appartenant à V* et N appartenant à VN.


124

Ce type de grammaire est couramment utilisé en informatique. Chaque règle peutexprimer le fait qu'un symbole N peut se réécrire en une suite de terminaux et/ou nonterminaux indépendamment du contexte dans lequel il se produit. Les propriétés de cesgrammaires qui ne prennent pas en considération le contexte sont bien connues, car c'estpour ce type de grammaire qu'a été développée toute la théorie de l'analyse syntaxiqueen informatique [Pierrel 87].

3.4.1.4. Grammaire de type 3 ou grammaire régulièreLes règles sont de la forme:N ---> aM ou N--->MaN ---> Mavec N, M appartenant à VN et a appartenant à VT.

C'est le type de grammaire le plus simple, le plus facilement implémentable maisaussi le moins apte à rendre compte des caractéristiques grammaticales du langagenaturel.

3.4.2. Les machines abstraitesLe modèle des grammaires formelles est plus orienté vers la génération que vers

l'analyse [Sabah 89] bien que des travaux visant une mise en oeuvre concrète existent.Cependant pour des informaticiens, le modèle des machines abstraites est plus adapté à uneimplémentation sur machine. Il existe différents types de machines abstraites. La plus simpleest l'automate à états finis. Il correspond à une grammaire régulière et est caractérisé par unensemble d'états, un ensemble de transitions entre ces états, un état initial et un ensembled'états finals. En rajoutant une pile à cette machine on obtient un automate correspondant auxgrammaires hors-contexte. En imposant comme seule condition le fait que la taille de lamémoire utilisée soit une fonction linéaire de la longueur de l'entrée, on disposera alors d'unemachine plus puissante connue sous le nom d'automate borné linéairement. Ce typed'automate correspond aux grammaires contextuelles. Enfin la machine la plus puissante est lamachine de Türing qui correspond aux grammaires non restrictives.

3.4.3. Les réseaux de transitionsLes réseaux de transitions constituent une extension des automates à états finis. Comme

nous l'avons déjà signalé, il existe une équivalence entre les automates à états finis et lesgrammaires régulières. Cependant, les grammaires régulières sont insuffisantes pour pouvoirtraiter les problèmes liés au langage naturel. En intégrant certaines extensions, les réseaux detransitions ont augmenté la puissance des automates en les rendant équivalents à desgrammaires hors-contexte et même dans certains cas à des grammaires contextuelles.


125

3.4.3.1. Les RTNs (Recursive Transition Network)Les réseaux de transitions récursifs sont des automates dans lesquels un arc de transition

A peut être étiqueté par l'identificateur d'un autre réseau R. Ceci signifie que la transition A nepourra être franchie que si le sous-réseau R est parcouru de son état initial à un de ses étatsfinals. Cette première extension permet d'améliorer la modularité du formalisme. Il devientalors possible d'organiser les réseaux en fonction des catégories syntaxiques qu'ilsreprésentent. Cependant elle n'augmente en rien sa puissance. La seconde extension autoriseun arc à appeler le réseau auquel il appartient (d'où le terme récursif). Il est également possibled'avoir une récursivité indirecte, c'est à dire qu'un arc A1 appartenant au réseau R1 peutappeler un réseau R2, et un arc A2 du réseau R2 peut à son tour appeler le réseau R1. Cetteseconde extension rend les RTNs équivalents aux grammaires hors-contexte. Voici unexemple de réseau de transition récursif (fig. 42) tiré de [Sabah 89] avec la grammaireéquivalente (fig. 43).

GN : Déterminant

Saut

Nom

Adjectif Adjectif

GP

e f g

a b c dP : GN Verbe

GP

GN

Saut

GP :Préposition GN

h i j

Figure 42. Exemple de réseau de transitions récursif


126

P ---> GN GVGN ---> Déterminant GN2GN ---> GN2GN2 ---> NomGN2 ---> Adjectif + GN2GN2 ---> GN2 + GPGP ---> Préposition + GNGV ---> VerbeGV ---> Verbe + GNGV ---> GV + GP

Figure 43. Grammaire hors-contexte équivalente au réseau de la figure 42

3.4.3.2. Les ATNs (Augmented Transition Network)Les RTNs permettent de disposer d'un formalisme dont la puissance est équivalente aux

grammaires hors-contexte. Cependant ceci reste insuffisant pour traiter des problèmes danslesquels le contexte joue un rôle déterminant. C'est pourquoi les réseaux de transitionsaugmentés furent introduits par Woods [Woods 70]. Ces réseaux permettent d'augmenter lapuissance des RTNs en associant aux arcs de transitions des conditions qui vont permettre derestreindre les circonstances selon lesquelles il est possible de franchir un arc, et des actionsqui permettront de réaliser des traitements sémantiques (fig. 44).

Noeud Etat 1

Etat 2

Arc de transition

EtiquetteConditionAction

Figure 44. Eléments de base d'un ATN


127

Les conditions pourront dépendre non seulement de l'étiquette de l'arc correspondantmais également du chemin qui a été parcouru avant d'arriver à cet arc, des résultats des actionsqui auront été exécutées lors du parcours etc. Pour résumer, elles dépendront du contexte danslequel l'arc devra être franchi. Ce type de réseaux permet donc de prendre en compte lesphénomènes contextuels. On pourrait alors penser qu'il représente l'équivalent des grammairescontextuelles. Une précision est ici nécessaire. Nous reprenons ci-après un paragraphe tiré de[Pierrel 87]:

"Or, sans même parler des langages naturels ou pseudo-naturels, il est fréquemmentnécessaire de prendre en compte des phénomènes contextuels pour analyser et traiter deslangages de programmation. Dans de tels cas l'informaticien préfère souvent définir lagrammaire de son langage sous forme d'une grammaire indépendante du contexte etadjoindre à chaque règle des pré-conditions, post-conditions ou actions qui serontdéclenchées lors de l'analyse syntaxique de la phrase à traiter. C'est ce que l'on a coutumed'appeler "actions sémantiques" en compilation. Une mise au point est nécessaire : lorsquel'informaticien effectue un tel traitement, il est amené à définir un langage hors contexte quidécrit un sur-ensemble du langage qu'il veut traiter. Cela n'est pas très grave : son objectifest le plus souvent de reconnaître ou d'analyser une phrase et non de générer des phrases. Il ya là une différence fondamentale entre l'informaticien, qui utilise la syntaxe, et le linguiste,qui cherche le plus souvent à définir un modèle de langage. Ainsi, pour reconnaître lelangage (an bn cn) qui n'est pas hors contexte, on définira le langage (an bn cp) et l'onvérifiera lors de l'analyse que n=p, ce qui se fait aisément, grâce à quelques actions simplesassociées à la grammaire (comptage, sauvegarde, comparaison)."

En fait, le reproche que l'on peut faire aux ATNs est qu'aucun modèle formel necaractérise les conditions et les actions. En effet, celles-ci sont en général écrites dans unlangage de programmation (LISP, C, C++ etc.). Ceci peut alors donner aux ATNs la puissanced'une machine de Türing générale. Cependant, comme l'a fait remarqué Pierrel, ce reprochegène surtout les linguistes qui cherchent à définir un modèle formel de langage afin depouvoir en étudier toutes les propriétés.

Il existe d'autres variantes de réseaux de transitions augmentés. Nous citons à titred'exemple les réseaux à noeuds procéduraux (RNP) qui ont été développés dans le systèmeMYRTILLE [Pierrel 81]. Dans ce type de réseaux les conditions et les actions sont rattachéesaux noeuds au lieu de l'être aux arcs.


128

Les réseaux de transitions augmentés ont largement été utilisés pour le traitement dulangage et la construction d'analyseurs syntaxico-sémantiques [Winograd 83] [Woods 80][Woods 78]. Dans [Sabah 89] on peut lire ceci :

"A l'expérience, on peut enfin remarquer qu'il est difficile d'écrire un réseau detransitions augmenté ayant une couverture linguistique importante, mais que pour une grandeclasse d'applications ne nécessitant pas le traitement de phénomènes linguistiques complexes,il s'agit d'une technique qui s'est révélée très efficace."

3.5. CHOIX DU MODELEComme nous venons de le voir, les réseaux de transitions ont été largement utilisés pour

le traitement du langage. Ils ont également été largement utilisés dans les interfaces Homme-Machine [Edmonds 81] [Edmonds 82] [Wasserman 81] [Feldman 82] [Olsen 84] [Wasserman85] [Jacob 82] [Jacob 85] [Jacob 86] [Harel 87]. Un grand nombre d'UIMS ont utilisé cemodèle pour la représentation du dialogue.

Toutefois, un des principes de la manipulation directe énoncés par Shneidermann(cf. §. 1.6) n'a pas permis à ce modèle de connaître une large extension dans les IHM. Ceprincipe énonçait que l'interaction devait s'effectuer à travers des actions physiques(mouvement et sélection par la souris, pointage écran tactile, etc.) et non plus à travers descommandes syntaxiques. On passait alors d'un modèle langagier à un modèle actionnel. Ilfallait alors passer d'un modèle qui permettait un démultiplexage temporel des entrées à unmodèle offrant un démultiplexage spatial.

Or, les interfaces multimodales remettent en cause ce principe par l'introduction demodalités langagières telle que la parole. Ces modalités exigent naturellement un modèle quisoit notamment capable de supporter aisément des spécifications syntaxiques. Ce problème apu être évité jusqu'à présent dans les interfaces à manipulation directe. Celles-ci étantprincipalement fondées sur des actions physiques à travers l'usage de la souris, la syntaxe del'interaction dans de telles interfaces était forcément très restreinte. Des problèmes se posentlorsqu'il s'agit de répondre non pas à un seul événement mais à une séquence d'événements quidoit survenir dans un ordre précis et on peut constater que dans la majorité des cas la gestiondu dialogue est laissée à la responsabilité du noyau fonctionnel ce qui est contraire au principemême de la séparation de l'interface et du noyau fonctionnel. On utilise alors des variables"drapeaux" indiquant les différents états du système. Ces variables se trouventmalheureusement noyées dans le code et toute modification du dialogue est ainsi renduedélicate.


129

En fait, les interactions multimodales en exploitant aussi bien des modalités langagières(langage parlé, écrit, langue des signes, etc.) que des modalités actionnelles (geste ergotique,désignation optique, etc.), intègrent au sein d'une même interface aussi bien un modèled'interaction anthropomorphique qu'un modèle physique. C'est cette coexistence des deuxmodèles qui fait toute la puissance des modèles d'interactions multimodales. L'exempleclassique "mets ça ici" est très illustratif : l'utilisateur semble s'adresser à un interlocuteur pourlui demander de modifier un monde physique qui leur est commun. La machine joue en faitles deux rôles : le rôle d'un interlocuteur et le rôle d'un monde physique virtuel. Nous voyons àtravers cet exemple que les deux approches peuvent coexister au sein même d'une mêmecommande.

C'est pourquoi nous avons utilisé dans SPECIMEN un modèle hybride pour lareprésentation de l'interaction multimodale. Ce modèle combine le modèle des réseaux detransitions augmentés à un modèle d'interaction par messages. Il allie l'adéquation des ATNspour la représentation des structures langagières à la souplesse d'un modèle à événementsétendu aux besoins spécifiques des interactions multimodales. Dans ce modèle de nouveauxmessages peuvent être définis par l'utilisateur grâce à l'utilisation d'opérateurs de compositionséquentielle et parallèle que nous décrirons dans la suite. De plus, les conditions et les actionspeuvent non seulement être attachées aux arcs de transitions mais également aux messageseux-mêmes. Ceci assure que le système ne soit jamais bloqué dans un état et peut répondre àun message donné même si ce message ne fait pas partie des messages attendus dans cet état.

Par ailleurs, le modèle des réseaux de transitions possède une caractéristique visuellequi le rend bien adapté à une spécification complètement interactive. Une interface graphiquea d'ailleurs été développée pour l'édition interactive de ces réseaux.

3.6. ARCHITECTURE DE SPECIMENL'architecture de SPECIMEN (fig. 45) fait apparaître les différents éléments suivants :


130

Agentsde fusion parallèle

Agents de fusionséquentielle

InterfaceObjet du Média

Médiad'Entrée

Médiade sortie

Médiade sortie




File desévénements

File commune desmessages d'entrée

Générateur des Messages d'Entrée

Contrôleurde Dialogue

Interface du NoyauFonctionnel

NoyauFonctionnel

Réseaux deTransitions

Générateur des Messages de sortie

Tabled'aiguillage

Médiad'Entrée

File desévénements

Figure 45. Architecture de SPECIMEN

3.6.1. Les interfaces objet des médiasChaque média (d'entrée ou de sortie) est représenté par un objet (cf. §. 3.11). Cette

interface objet assure une communication homogène entre le générateur des messages d'entrée(respectivement de sortie) et les différents médias d'entrée (respectivement de sortie). Grâce àcette interface, le générateur des messages d'entrée peut, par exemple, demander au média s'ily a des événements dans sa file propre ou si un événement est en cours de production (parexemple pour un système de reconnaissance vocale, un processus d'acquisition ou dereconnaissance est en cours). De même, le générateur de messages de sortie peut demander aumédia si la production d'un message donné est terminée ou pas (synthétiseur de parole parexemple).


131

3.6.2. La file commune des messages d'entréeCette file est alimentée par deux types de sources : les médias d'entrée qui produisent

des messages élémentaires (événements) et les agents de fusion (séquentielle ou parallèle) quiproduisent des messages composés. Cette file n'est pas une véritable FIFO (First In First Out)car les messages y sont insérés selon leurs positions chronologiques réelles et non pas rajoutésen queue de file.

Pour un message M composé séquentiellement des messages m1, m2, ..., mn, la date dedébut de production est égale à la date de début de production de m1 et la date de fin deproduction est égale à la date de fin de production de mn.

Date_Début (M) = Date_Début (m1)Date_Fin (M) = Date_Fin (mn)

Pour un message M composé parallèlement des messages m1, m2, ..., mn, la date dedébut de production est égale au minimum des dates de début de production des différentsmessages et la date de fin de production est égale au maximum des dates de fin de productiondes différents messages.

Date_Début (M) = MIN (Date_Début (mi)), i=1..nDate_Fin (M) = MAX (Date_Fin (mi)), i=1..n

3.6.3. Les agents de fusion séquentielle (AFS)Les agents de fusion séquentielle ont pour rôle de produire des messages indiquant que

des séquences de messages particulières, spécifiées par le développeur, ont été détectées. Ilsreçoivent des messages de la part du générateur des messages d'entrée et produisent eux-mêmes des messages correspondant aux séquences reconnues. A chaque séquence demessages spécifiée par l'utilisateur est associé un agent responsable de la reconnaissance decette séquence lorsqu'elle se produit.

3.6.4. Les agents de fusion parallèle (AFP)Ils ont pour rôle de produire des messages indiquant que des ensembles particuliers de

messages temporellement proches, spécifiés par le développeur, ont été détectés. Ils reçoiventdes messages de la part du générateur des messages d'entrée et produisent eux-mêmes desmessages correspondant aux ensembles reconnus. A chaque ensemble de messages spécifiépar l'utilisateur est associé un agent responsable de la reconnaissance de cet ensemble demessages lorsqu'il se produit.


132

3.6.5. La table d'aiguillage (TA)Cette table est utilisée par le générateur des messages d'entrée. Elle contient pour chaque

message m (élémentaire ou composé) une liste de pointeurs permettant d'identifier les agentsA1, A2,..., An responsables respectivement de la détection des messages composés M1,M2,...,Mn où m apparaît comme élément composant.

ExempleSoient les messages suivants :

M1M2M3M4=M1+M2M5=M2*M3M6=M1+M3M7=M4*M5

Soient les agents Ai responsables de la détection des messages Mi et les pointeurs PAivers les agents Ai.

Pour cet exemple, la table contiendra les éléments suivants :

Message Liste de pointeurs vers les agentsM1 PA4, PA6M2 PA4, PA5M3 PA5, PA6M4 PA7M5 PA7

3.6.6. Le générateur des messages d'entrée (GME)Le générateur des messages d'entrée a pour rôle, comme son nom l'indique de produire

des messages d'entrée pour les transmettre au contrôleur de dialogue. Lorsque le générateurdes messages d'entrée prélève un message de la file commune des messages, il consulte latable d'aiguillage pour savoir à quels agents il doit le transmettre. Il envoie alors le messageaux agents concernés, puis au contrôleur de dialogue.


133

Considérons l'exemple précédent :

• lorsque le message M1 se produit, le GME consulte la TA qui lui indique qu'il fautenvoyer ce message aux agents A4 et A6 responsables respectivement de la détectiondes messages M4 et M6,

• les agents A4 et A6 reçoivent ce message et se mettent en attente respectivement dumessage M2 et M3,

• lorsque M2 se produit, le GME consulte la TA et l'envoie aux agents A4 et A5,• l'agent A4 détecte alors la production de la séquence M1+M2. Il génére le message

M4 et l'insère dans la file,• l'agent A5 se met quant à lui en attente d'un message M3,• le GME prélève le message M4, et en consultant la TA l'envoie à l'agent A7,• l'agent A7 reçoit le message M4 et se met en attente d'un message M5,• lorsque M3 se produit, le GME l'envoie aux agents A5 et A6,• l'agent A5 détecte alors la production d'un message parallèle M2*M3 et génére le

message M5,• l'agent A6 quant à lui détecte la séquence M1+M3 et génére M6• lorsque le GME prélève le message M5 il l'envoie à l'agent A7,• l'agent A7 enfin détecte la production d'un message parallèle M4*M5 et génére alors

le message M7.

3.6.7. Le contrôleur de dialogue (CD)Ce contrôleur gère la progression dans les réseaux. Il reçoit les messages d'entrée de la

part du GME, décide quel arc de transition il doit emprunter en fonction des messages reçus etdes conditions associées aux arcs de transition, indique au GMS quels messages de sortie ildoit produire, et permet d'activer au fur et à mesure les actions associées aux arcs detransition.

3.6.8. Le générateur des messages de sortie (GMS)Son rôle consiste à distribuer les différents messages de sortie aux médias

correspondants. Dans le cas des messages composés séquentiellement c'est lui qui assure leséquencement des messages. Dans le cas des messages composés parallèlement il assure lasynchronisation temporelle entre les différents messages constituants. Il est possible despécifier au niveau des arcs de sortie deux catégories de messages de sortie:


134

• les messages de sortie bloquants : un message bloquant oblige le contrôleur dedialogue à attendre que le générateur des messages de sortie l'informe de la fin de productiondu message avant de poursuivre sa progression dans le réseau.

• les messages de sortie non bloquants : un message non bloquant permet au contrôleurde dialogue de poursuivre sa progression dans le réseau sans avoir à attendre la productioneffective du message.

3.6.9. Les réseaux de transitionsLes réseaux de transitions décrivent la syntaxe de l'interaction et sont développés dans le

paragraphe suivant.

3.7. STRUCTURE DES RESEAUXLes réseaux sont composés de noeuds et d'arcs de transitions. Les arcs de transitions

possèdent un attribut "ETAT" qui indique si l'arc est activé ou désactivé. Un arc désactivé a lemême effet que s'il n'existait pas sauf qu'il est possible de le réactiver.

3.7.1. Les arcs de transitionsIls peuvent être de quatre types :

• les arcs d'entrée : ils peuvent être étiquetés par un message d'entrée élémentaire oucomposé. La transition s'effectue à travers ce type d'arcs lorsqu'un message, du même type quel'étiquette de l'arc, est produit par le GME et que la condition est vérifiée. L'action est alorsexécutée.

• les arcs de sortie : ils peuvent être étiquetés par un message de sortie élémentaire oucomposé. La transition s'effectue à travers ce type d'arcs lorsque la condition est satisfaite.L'action est alors exécutée puis le message est transmis au GMS pour être généré. Remarquonsque l'exécution de l'action s'effectue avant la génération du message, afin de pouvoir fixerdynamiquement les valeurs des attributs du message.

• les arcs spontanés : ils ne possèdent pas d'étiquette. Cependant une condition et uneaction peuvent leur être associées. La transition s'effectue uniquement si la condition estsatisfaite, et l'action est alors exécutée.

• les macro-arcs : ils sont étiquetés par des identificateurs de réseaux. La transitions'effectue lorsque le réseau étiquette est traversé du noeud initial au noeud final.


135

3.7.2. Les noeudsIls sont de trois types :

• les noeuds d'entrée : un noeud d'entrée est un noeud d'où partent exclusivement desarcs d'entrée et/ou des macro-arcs dont les noeuds initiaux sont des noeuds d'entrée. Lepassage d'un noeud d'entrée à un autre noeud implique l'attente d'un message d'entrée.

• les noeuds de sortie : de ces noeuds partent exclusivement des arcs de sortie et/ou desmacro-arcs dont les noeuds initiaux sont des noeuds de sortie. Le passage d'un noeud de sortieà un autre noeud implique la production d'un message de sortie.

• les noeuds spontanés : un noeud spontané est un noeud d'où partent exclusivement desarcs spontanés et/ou des macro-arcs dont les noeuds initiaux sont des noeuds spontanés. Lepassage d'un noeud spontané à un autre noeud correspond à un traitement interne et n'impliqueaucune opération d'entrée-sortie.

REMARQUEIl n'est pas possible à partir d'un même noeud de faire sortir des arcs de types différents,

car ceci peut mettre le système dans un état d'ambiguïté. Par exemple, si à partir d'un mêmenoeud partent un arc d'entrée et un arc spontané, le système ne peut savoir s'il doit franchir latransition spontanée (en supposant que sa condition soit vérifiée) ou s'il doit attendre laproduction d'un message d'entrée.

3.7.3. Utilité de l'attribut d'étatL'attribut "ETAT" des arcs de transitions possède trois avantages :

1. En traitement interne, il permet d'activer et de désactiver des commandes de manièredynamique au fur et à mesure du déroulement de l'application. Ceci correspond par exempleaux rubriques grisées d'un menu, par exemple la commande "Coller" d'une interfacegraphique lorsque le presse-papiers est vide. Il suffit de désactiver l'arc qui donne accès à unecommande pour empêcher temporairement l'exécution de celle-ci.

2. En sortie, il permet de choisir parmi plusieurs modalités, la modalité adéquate qu'ilfaut utiliser. Etant donné un noeud d'où partent plusieurs arcs de sortie, il suffit d'activer l'arccorrespondant à la modalité (ou à la combinaison de modalités) désirée et de désactiver lesautres.

3. En entrée, il permet d'interdire l'utilisation d'une modalité particulière (par exemple,la parole dans le cas d'un environnement fortement bruité).


136

3.8. LES CATEGORIES DE MESSAGESIl existe trois grandes catégories de messages dans SPECIMEN : les messages

élémentaires, les messages composés séquentiellement et les messages composésparallèlement.

3.8.1. Les messages élémentairesIls correspondent en entrée à la notion d'événements produits par les médias d'entrée

(clic souris, mot, geste, etc.), par le système de fenêtrage, ou par les objets interactifs d'uneboîte à outils. En sortie, ils désignent des messages d'affichage élémentaires produits par unelibrairie graphique, des messages sonores échantillonnés, des phrases synthétisées, etc. Nousne faisons aucune hypothèse sur la granularité des messages car celle-ci peut varier d'uneplate-forme à une autre. Nous supposons simplement que les messages élémentaires sont lesmessages disponibles au départ sur le système.

La deuxième et la troisième catégorie correspondent à des compositions de messagesélémentaires et/ou de messages issus eux-mêmes d'une composition. Nous décrivons dans leparagraphe suivant ces deux catégories de messages.

3.8.2. Les messages composésCes messages sont définis grâce à l'utilisation des opérateurs de composition qui

permettent de créer de nouveaux messages en fonction de ceux déjà définis (messagesélémentaires ou messages eux-mêmes définis par utilisation de ces opérateurs). Il existe deuxopérateurs de composition de messages : l'opérateur de composition séquentielle (ou opérateurhorizontal) et l'opérateur de composition parallèle (ou opérateur vertical). Dans la suite nousdésignerons par '+' l'opérateur de composition séquentielle et par '*' l'opérateur de compositionparallèle. La définition des messages est décrite par la règle suivante :

M ← m / m+M / m*M

où m désigne un message élémentaire.

Autrement dit, tout message correspond soit à un message élémentaire prédéfini, soit àune production séquentielle de messages, soit à une production parallèle de messages soitenfin à une combinaison quelconque de ces deux productions.


137

3.8.2.1. L'opérateur de composition séquentielleEn entrée, l'opérateur de composition séquentielle permet de demander au système de

générer un message particulier chaque fois qu'une séquence donnée de certains messages estdétectée. En sortie, il permet d'indiquer au système une série de messages de sortie à générerséquentiellement.

3.8.2.2. L'opérateur de composition parallèleCet opérateur permet, en entrée, de demander au système de générer un message

particulier chaque fois qu'un ensemble donné de certains messages est produit de manièresimultanée (ou presque, c'est-à-dire dans un certain intervalle temporel pouvant être spécifiépar le développeur). En sortie, il permet d'indiquer au système un ensemble de messages desortie à produire de manière simultanée.

3.8.2.3. Exemple généralSoient m1, m2, m3, m4, m5, m6, m7, m8, m9, m10, 10 messages élémentaires. La

fig. 46 fournit un exemple d'utilisation des opérateurs de composition de messages.

Cette figure équivaut aux définitions suivantes :

M11=m2+m3+m4M12=m4*m5M13=m5+m6+m7M14=m7*m8*m9M15=M11*M13M16=M12+M14M17=M15*M16M18=m1+M17+m10

ou encore

M18=m1+(((m2+m3+m4)*(m5+m6+m7))*((m4*m5)+(m7*m8*m9)))+m10


138

m1 m2 m3 m4 m5 m6 m7 m8 m9 m10

M11 M12 M13 M14

M15 M16

M17

M18

Composition séquentielleComposition parallèle

Figure 46. Exemple de composition de messages

Une représentation temporelle possible de la production d'un message M18 est donnéedans la fig. 47.


139

m1

m5 m6 m7

m8

m9

m10

M11 M12

M13 M14

M15 M16

M17

M18

m2 m3 m4

Composition séquentielleComposition parallèle

Temps

Figure 47. Exemple de distribution temporelle des messages

3.8.2.4. Exemple concret : "mets ça ici"Nous présentons ci-dessous quelques exemples de spécifications possibles pour

l'interaction multimodale composée de la phrase "mets ça ici" (parole) accompagnée de deuxclics souris.

Dans le premier exemple (fig. 48), les messages vocaux "mets", "ça" et "ici" sontd'abord composés de manière séquentielle. Les deux clics sont également composés demanière séquentielle. Les deux messages ainsi définis sont alors à leur tour composés demanière parallèle.


140

Composition séquentielle

Composition parallèle


"mets" "ça" "ici"

clic clic

Temps

Médias


Souris

Figure 48. Premier exemple de spécification

Ceci correspond aux définitions suivantes :M1="mets"+"ça"+"ici"M2=clic+clicM3=M1*M2

Ce premier exemple de spécification présente l'avantage d'une certaine souplesse.L'utilisateur peut cliquer sur l'objet et sur sa nouvelle position à n'importe quelle moment aucours de la prononciation de la phrase "mets ça ici". En revanche, il est difficile de produire unfeed-back intermédiaire (par exemple, inversion vidéo immédiate de l'objet désigné) ou dedétecter immédiatement une erreur de désignation (par exemple, le premier clic necorrespondant pas à un objet).

Dans le second cas (fig. 49), le messages "ça" et le premier clic sont d'abord composésde manière parallèle. Il en est de même du message "ici" et du second clic. Le message "met"et les deux messages précédemment définis sont alors composés de manière séquentielle.Autrement dit, l'utilisateur doit prononcer le mot "ça" au même moment (ou presque) qu'ildésigne l'objet et le mot "ici" au même moment qu'il désigne la position.


141



"mets" "ça" "ici"

clic clic

Temps

Médias


Souris


Figure 49. Deuxième exemple de spécification

Ce second cas correspond aux définitions suivantes :M1="ça"*clicM2="ici"*clicM3="mets"+M1+M2

Cette seconde spécification présente moins de souplesse, mais permet d'avoir un feed-back immédiat et une détection d'erreur immédiate.

Remarquons qu'il est également possible de se passer du message M3 et de représentercette interaction sous forme d'un réseau de transition (fig. 50).

N1"Mets" M1 M2

N2 N3 N4 N5 N6 N7MS1

MS3

MS2 MS4

Null

Null

Arc d'entréeArc de sortie

Figure 50. Troisième exemple de spécification


142

Le message MS1 est un message de sortie chargé d'informer l'utilisateur de lareconnaissance du mot "mets" (par exemple, affichage dans une fenêtre des mots reconnus oudiffusion par synthèse vocale de ceux-ci).

Le message MS3 est un message de sortie (vocal ou visuel) qui indique à l'utilisateurque le clic produit ne correspond pas à un objet.

Le message MS2 est un message de sortie qui indique à l'utilisateur que le système abien reconnu l'objet qu'il a désigné (vidéo inverse ou affichage du contour de l'objet).

Le message MS4 enfin est une composition séquentielle de 2 messages de sortie dont lepremier consiste à effacer l'objet de sa position initiale (c'est à dire afficher, ce qu'il y avait endessous de l'objet) et le second à afficher l'objet à sa nouvelle position.

Bien sûr, des actions peuvent être attachées aux arcs pour mettre à jour la base desobjets. Le message "Null" est un type de message particulier qui est décrit au §. 3.8.3.

Une autre spécification possible est présentée dans la fig. 51.

N1

M1

N2 N3MS1

MS3

MS2

MS4

N4

N7 N8

Déplacement

N5 N6

M2

Relâchement Bouton

MS0


Figure 51. Quatrième exemple de spécification

Les définitions de messages correspondant à cet exemple sont :M0="mets"+"ça"M1=M0*AppuiBoutonSourisM2="ici"*RelâchementBoutonSouris


143

Ici, l'utilisateur peut prononcer la phrase "mets ça" et appuyer en même temps sur lebouton de la souris. Si l'appui du bouton ne correspond pas à un objet, un message d'erreur(message de sortie MS0) est communiqué à l'utilisateur, sinon l'objet est mis en évidence(message de sortie MS1). Puis l'utilisateur peut bouger la souris, tout en maintenant le boutonappuyé. L'objet suit alors le déplacement de la souris (message de sortie MS2). Pour finir,l'utilisateur a le choix entre deux possibilités : soit il relâche le bouton de la souris et prononceen même temps le mot "ici", soit il relâche le bouton de la souris sans rien dire. Ceci est alorsconsidéré comme une annulation et l'objet retrouve sa position initiale.

3.8.2.5. Deuxième exemple : "effacer ligne"Ce second exemple vise à montrer comment les spécifications choisies peuvent influer

sur l'interprétation des énoncés. L'interaction présentée ci-dessous vise à effacer une ligne detexte (dans une application d'édition de textes) désignée par l'utilisateur grâce à un clic sur unde ses caractères.

Dans le premier exemple de spécification, les messages "effacer" et "ligne" sont d'abordcomposés séquentiellement puis le message obtenu est composé parallèlement avec le clic.



"effacer" "ligne"

clic

Temps

Médias


Souris

Figure 52. Premier exemple de spécification

Les définitions des messages correspondants sont :M1="effacer"+"ligne"M2=M1*clic


144

Comme pour la première spécification de "mets ça ici", cette spécification est souplepuisque le clic peut être produit à n'importe quel moment de la prononciation de la phrase"effacer ligne". Cependant, cette spécification n'autorise qu'une seule interprétation quel quesoit l'endroit (temporel) où se produit le clic.

En revanche, les deux spécifications suivantes permettent de disposer de deuxinterprétations différentes selon la position temporelle précise du clic. Pour la premièrespécification (fig. 53), l'interprétation associée est l'effacement de la ligne désignée.



"effacer" "ligne"

clic

Temps

Médias


Souris

Figure 53. Deuxième exemple de spécification

Les définitions des messages correspondants sont :M1="ligne"*clicM2="effacer"+M1

La seconde spécification (fig. 54) entraînera quant à elle l'effacement du mot désigné(on suppose que le clic sert à désigner le mot) et l'affichage visuel ou l'émission sonore dunuméro de la ligne courante (on suppose que la prononciation du mot "ligne" correspond à larequête "quel est le numéro de la ligne courante ?").


145



"effacer" "ligne"

clic

Temps

Médias


Souris

Figure 54. Troisième exemple de spécification

Les définitions des messages correspondants sont :M3="effacer"*clicM4=M3+"ligne"

3.8.3. Le message nulDans certains cas, il peut être utile de spécifier une action à exécuter en cas d'inactivité

de l'utilisateur. A cet effet, un type de message particulier a été prévu. Il s'agit du "messagenul". Il est considéré comme un message d'entrée. Ce message est généré par le système suiteà une inactivité de l'utilisateur (aucun message d'entrée) pendant une durée t spécifiée par ledéveloppeur. Ce message peut servir, par exemple, à engager un dialogue avec l'utilisateurdans les cas où il commence une commande et ne la termine pas afin de lui demander s'ildésire annuler la commande courante ou la compléter.

Il peut également servir, par exemple, à affecter une certaine interprétation à un messagelorsqu'il est produit seul, et une autre interprétation s'il est suivi d'un autre message. Parexemple, dans l'interaction de la fig. 55, si l'utilisateur prononce le mot "ligne" seul, lesystème lui retourne le numéro de la ligne courante. En revanche si ce mot est suivi d'unnuméro de ligne, le système fait défiler le texte jusqu'à la ligne indiquée.


146

N1 N2

MS1

MS2

N5 N6

N3 N4

Null

"ligne"

"<numéro de ligne>"


Figure 55. Exemple d'utilisation du message nul

Le message de sortie MS1 sert à mettre l'affichage du texte à jour. Le message MS2 peutêtre la synthèse vocale du numéro de la ligne courante ou l'affichage visuel de ce numéro.

3.8.4. Commutativité et associativité des opérateurs decompositionL'opérateur de composition parallèle '*' est commutatif et associatif. L'ordre d'apparition

des opérandes dans l'expression de composition n'a aucune importance. Seule comptera laproximité temporelle des messages qui seront produits. Par exemple, les trois spécificationssuivantes de M2 sont équivalentes :

M1=m1*m2 M1=m3*m1 M1=m2*m3ou ou

M2=M1*m3 M2=m2*M1 M2=M1*m1

En revanche, l'opérateur de composition séquentielle '+' est associatif mais pascommutatif. L'ordre d'apparition des messages dans l'expression de composition est iciessentiel puisqu'il indique la séquence même selon laquelle les messages composants devrontêtre produits pour pouvoir générer le message composé. Par exemple, les deux spécificationssuivantes de M2 sont équivalentes :


147

M1=m1+m2 M1=m2+m3ou

M2=M1+m3 M2=m1+M1

En revanche, celles-ci ne le sont pas :

M1=m1+m2 M1=m1+m2ou

M2=M1+m3 M2=m3+M1

3.9. LA FUSION DANS SPECIMENIl existe deux types de fusion dans SPECIMEN : la fusion séquentielle réalisée par les

AFS (Agents de Fusion Séquentielle) et la fusion parallèle effectuée par les AFP (Agents deFusion Parallèle). Les deux fusions utilisent la même méthode que nous dénommons méthodedu loto. Tout un chacun a probablement déjà vu le tirage du loto à la télévision. Analysonscette méthode. Chaque joueur possède une série de nombres. Chaque fois qu'un numéro esttiré il est transmis à chaque joueur à travers le téléviseur. Chaque joueur effectue alors (demanière parallèle avec les autres) un processus de comparaison progressif entre la série denombres qui est en sa possession et les nombres qui apparaissent au fur et à mesure du tirage.Si un des joueurs reconnaît sa série de nombres, il a alors gagné.

Remarquons qu'une autre méthode (théoriquement possible) consiste à donner tous lesbillets des différents joueurs à une seule personne et à lui demander de déterminer le billetgagnant. Cette personne aurait alors à comparer de manière séquentielle, toutes les séries denombres correspondant aux différents billets avec la série gagnante. Il est évident que cettedeuxième méthode est beaucoup moins rapide et moins efficace.

La première méthode correspond en fait, à une méthode de reconnaissance distribuée(fig. 56) alors que la seconde est une méthode de reconnaissance centralisée (fig. 57).


148

Entité àreconnaître

Entité deréférence

Agent dereconnaissance







Entitéreconnue

Agentcentral

Figure 56. Méthode de reconnaissance distribuée





Entité àreconnaître

Entitéreconnue

Agentcentral

Figure 57. Méthode de reconnaissance centralisée

La méthode de fusion séquentielle que nous utilisons s'apparente fortement à la méthodedu loto (distribuée) avec toutefois deux principales différences :

• au loto, toutes les séries comportent 6 nombres plus un septième complémentaire. Lecardinal de chaque ensemble à reconnaître est donc fixe. Dans notre cas, les messagescomposés séquentiellement peuvent comporter un nombre quelconque d'élémentscomposants. On peut avoir des compositions séquentielles de 2, 3, 4,..ou n messages,


149

• au loto dès qu'un joueur reçoit un nombre qui ne correspond pas au nombre qu'ilattendait, il a perdu et la reconnaissance a échoué. Dans notre cas, si un AFS reçoit unmessage qui ne correspond pas au message qu'il attendait ceci ne signifie pas forcémentque la reconnaissance a échoué car il est possible que le prochain message ou celuid'après ou un quelconque futur message corresponde au message attendu. En revanche,la reconnaissance a échoué et doit recommencer si l'AFS reçoit le premier message de saséquence alors qu'il était en attente du ième message avec i>1.

La méthode de fusion parallèle est également similaire à la méthode de fusionséquentielle avec cependant une différence fondamentale qui consiste en la prise en comptedes contraintes temporelles. Dans la fusion séquentielle, aucun délai temporel n'est exigé entrela production de deux messages successifs. En revanche, dans la fusion parallèle, les messagesfusionnés doivent tous se situer dans un voisinage temporel proche (dont la largeur est laisséau choix du développeur).

3.9.1. Comportement des AFSChaque fois que le développeur spécifie une composition séquentielle de messages, un

agent est automatiquement associé au nouveau message ainsi défini. Cet agent sera dès lorsresponsable de la détection de la production de la séquence spécifiée par le développeur et dela génération du message correspondant à cette séquence. Pour cela l'agent dispose d'une listeL1 d'éléments e1, e2,..., en, décrivant la séquence de messages spécifiée par le développeur.Chaque élément ei correspond à un message de la séquence et contient les informationssuivantes :

• le type du message Ti,• un ensemble de valeurs Vi (éventuel),• une condition Ci (éventuelle),• une action Ai (éventuelle),

Un message de la séquence est détecté lorsque :

1. son type correspond au type du message spécifié,2. si le développeur a spécifié un ensemble de valeurs, alors les valeurs des attributs

du message produit doivent correspondre aux valeurs indiquées par ledéveloppeur,

3. si le développeur a spécifié une condition, celle-ci doit être vérifiée,


150

Si ces 3 conditions sont vérifiées, le message est alors détecté et l'action est exécutée.Nous voyons donc ici que les conditions et les actions peuvent non seulement être attachéesaux arcs de transitions mais également aux nouveaux messages définis par le développeur.

Dans la suite nous désignerons par "conditions de validité" les deux conditions 2 et 3.

Chaque agent maintient à jour une seconde liste L2 dans laquelle il met au fur et àmesure les messages qu'il a détectés. Voici l'algorithme exécuté par l'AFS, lorsqu'il reçoit unmessage M de la part du GME :

Déterminer le premier type T parmi les types T1,T2,...,Tn tel que M est de type T etles conditions de validité sont vérifiéessi T existealors rajouter M à la liste L2 à la position correspondante

déclencher l'exécution de l'action associée,si les éléments de L2 sont bien ordonnés chronologiquementalors si la taille de la liste L2=n

alors générer le message détecté et l'envoyer au GMEréinitialiser la liste L2 et commencer une nouvelle détection

sinon attendre le prochain message,sinon parcourir la liste L2 à partir du début

enlever les messages ayant une date antérieure à celle du messageprécédent/*on ne garde que les messages les plus récents afin que la détection nesoit pas bloquée*/attendre le prochain message

sinon ignorer M

3.9.2. Comportement des AFPDe même que pour les compositions séquentielles, chaque fois que le développeur

spécifie une composition parallèle de messages, un agent est automatiquement associé aunouveau message ainsi défini. Cet agent est alors responsable de la détection de la productionparallèle de cet ensemble de messages spécifié par le développeur et de la génération dumessage correspondant. L'agent dispose ici aussi d'une liste L1 d'éléments e1, e2,..., en,décrivant l'ensemble des messages composants spécifiés par le développeur. Chaque élémentei contient les mêmes éléments que précédemment.


151

Un message de l'ensemble est détecté lorsque :

1. son type correspond à un des types de messages spécifiés,2. si le développeur a spécifié un ensemble de valeurs, alors les valeurs des attributs

du message produit doivent correspondre aux valeurs indiquées par ledéveloppeur,

3. si le développeur a spécifié une condition, celle-ci doit être vérifiée,

Si ces 3 conditions sont vérifiées, le message est alors détecté et l'action est exécutée.Comme précédemment chaque agent maintient une à jour une seconde liste L2 dans laquelle ilmet au fur et à mesure les messages qu'il a détectés. Voici l'algorithme exécuté par l'AFPlorsqu'il reçoit un message M de la part du GME :

si le type de M correspond à un des types T1,T2,...,Tn etles conditions de validité sont vérifiées

alors si M est temporellement proche des messages déjà présents dans la listeL2

alors ajouter M à la liste L2,déclencher l'exécution de l'action associée,si la taille de la liste L2=nalors générer le message détecté et l'envoyer au GME

réinitialiser la liste L2 et commencer nouvelle détectionsinon attendre prochain message,

sinon réinitialiser la liste L2ajouter M à la liste L2attendre prochain message

sinon ignorer M

Nous voyons donc qu'ici la séquence selon laquelle les messages ont été produitsimporte peu. Seule compte leur proximité temporelle.

3.10. REPRESENTATION DES MESSAGESL'approche orientée objet a été suivie dans tout le développement (en C++) de

SPECIMEN. Toutes les entités importantes ont été représentées par des classes (médias,messages, arcs, noeuds, etc.). Cette approche a pour avantage de permettre une abstraction desdonnées : vue de l'extérieur une classe se caractérise uniquement par la spécification de sesdonnées et de ses méthodes (fonctions) publiques, les détails de programmation propres à un


152

média donné étant cachés dans sa partie privée. Par ailleurs, elle permet une extensibilité etune réutilisabilité facile des classes déjà définies grâce à la notion d'héritage. Par exemple,l'intégration dans le système de nouveaux médias pourra se faire aisément en créant denouvelles classes dérivées à partir d'une des classes déjà existantes et héritant de sespropriétés.

La hiérarchie de classes de messages (fig. 58) sert à représenter les différents messagesutilisés dans SPECIMEN. Au sommet de cette hiérarchie, figure la classe "Message". Elle sertà représenter les caractéristiques communes à tous les messages (qu'ils soient élémentaires oucomposés, d'entrée ou de sortie), telles que le nom du message, sa nature (élémentaire oucomposé) sa direction (entrée ou sortie) et son type.

La classe "Message Elémentaire" dérive de la classe "Message" et regroupe les donnéeset fonctions propres aux messages élémentaires. On trouve en particulier, une référence versl'origine ou la destination du message. Dans le cas d'un message élémentaire d'entrée, cetteréférence servira à identifier le média d'où est issu le message. Dans le cas d'un messageélémentaire de sortie, elle servira à aiguiller le message vers le média destination.

La classe "Message composé" sert à représenter les compositions de messages. Danscette classe figure en particulier une liste de références vers les différents messagescomposants. La classe "Message Composé Séquentiellement" sert à représenter les messagesdéfinis par composition séquentielle. L'ordre des éléments de la liste est ici important. Laclasse "Message Composé Parallèlement" est utilisée pour représenter les messages composésparallèlement. Ici figure pour chaque message composé le seuil de proximité temporelle fixépar le développeur (ou un seuil par défaut s'il ne l'a pas précisé).

Les classes "Message Elémentaire Entrée", "Message Composé SéquentiellementEntrée", et "Message Composé Parallèlement Entrée" servent à représenter les différentescatégories de messages d'entrée. Ces classes contiennent en particulier deux champs : DateDébut et Date Fin qui indiquent les dates de début et de fin de production du message.

Les classes "Message Elémentaire Sortie", "Message Composé SéquentiellementSortie", et "Message Composé Parallèlement Sortie" servent à représenter les différentescatégories de messages de sortie. Ces classes contiennent en particulier un champ Priorité quipermet aux messages d'alerte d'interrompre d'éventuels messages en cours de production pourêtre produits immédiatement. Il contiennent également un champ booléen Bloquant quiindique s'il s'agit d'un message de sortie bloquant ou pas.

Les autres classes de la hiérarchie "Message" dérivent toutes d'une des deux classes"Message Elémentaire Entrée" ou "Message Elémentaire Sortie", et servent à représenter lestypes de messages produits ou à destination des différents médias.


153

MessageComposé

Parallèlement

MessageComposé

Séquentiellement

MessageComposé

Message

MessagesOculomètr

e

MessageVisuel 3D

MessageSynthèse

Vocale

MessageSonore

Echantillonné

Message MIDI

MessageVisuel 2D

MessageTactile

(braille)

MessageVocal

MessageGestuel

MessageClavier

MessageSouris

MessageElémentaire

Sortie

MessageElémentaire

Entrée

MessageElémentaire

MessageComposé

Séquentiellement

Entrée

MessageComposé

Séquentiellement

Sortie

MessageComposé

Parallèlement

Entrée

MessageComposé

Parallèlement

Sortie

Messagedu système de

Fenêtrage

Messaged'objet

interactif

Figure 58. La hiérarchie des messages


154

3.11. REPRESENTATION DES MEDIASLa fig. 59 présente la hiérarchie des classes utilisées pour la représentation des médias.

Au sommet de la hiérarchie, nous trouvons la classe "Média". Celle-ci sert à représenter lescaractéristiques communes à tous les médias (qu'ils soient d'entrée ou de sortie). Dans cetteclasse figure des données telles que le nom du média (utile pour permettre à l'utilisateurd'identifier le média, par exemple en cas de panne), son type (entrée ou sortie), son état, etc.On y trouve également des fonctions qui permettent par exemple d'activer ou de désactiver lemédia, et de savoir si un message est en cours de production. Cette dernière fonction estimportante, aussi bien dans le cas d'un média d'entrée (cf. § 1.14.3) que dans le cas d'un médiade sortie. Dans ce dernier cas, elle peut servir, lorsqu'un message de sortie occupe un espacetemporel important (message sonore par exemple), à ne pas l'interrompre par l'envoi d'un autremessage.

La classe "Média Entrée" dérive directement de la classe "Média". Elle regroupe, toutesles caractéristiques communes aux médias d'entrée (en plus des caractéristiques héritées de saclasse mère "Média"). Parmi celles-ci, nous pouvons citer en particulier une fonction quianalyse les données brutes en provenance du média, et construit des objets messagescompatibles avec les classes définies dans la hiérarchie des messages (cf. §. 3.10). C'est unedes fonctions clés, car à travers elle, s'établit la liaison entre les deux hiérarchies "Média" et"Message". Elle se charge, aussi, de déterminer les temps de début et de fin de production desmessages, et de rajouter ces derniers dans la file d'attente propre au média. On trouveégalement dans cette classe une fonction qui renvoie l'état du média à un instant t. Cettefonction est utilisée pour gérer les coréférences passives (cf. § 1.14.4).

La classe "Média Sortie" dérive également de la classe "Média". Elle regroupe, toutesles caractéristiques communes aux médias de sortie. On y trouve entre autres, une fonction quireçoit en entrée un objet message, instance d'une classe définie dans la hiérarchie "Message"et plus précisément dans le sous-arbre "Message Elémentaire Sortie" (cf. fig. 58), et produit lemessage en construisant les données brutes, et en faisant les appels de fonctions de bas niveaunécessaires. C'est aussi une fonction clé, car à travers elle s'établit la liaison entre les deuxhiérarchies "Média" et "Message". On y trouve également des fonctions qui servent àinterrompre, suspendre et reprendre la production d'un message. Ces fonctions sont utiles, parexemple, dans les cas de messages d'alerte. En effet, ces messages étant prioritaires, il doiventpouvoir interrompre tout message en train d'être produit.


155

Il faut remarquer que les classes "Média", "Média Entrée", et "Média Sortie" jouent lerôle de classes de base. Autrement dit, il ne sera jamais créé d'instances de ces classes. Lesinstances pourront être créées à partir des classes et sous-classes dérivées décrites ci-dessous.

Les autres classes de la hiérarchie "Média" servent à représenter des catégories demédias de façon plus spécialisée. Par exemple, la classe "Système de Reconnaissance Vocale"sert à représenter les caractéristiques communes à tous les systèmes de reconnaissance deparole, telles que le temps de reconnaissance moyen, le délai de silence, le seuil de rejet, etc.Un système de reconnaissance de parole particulier tel que Datavox sera alors représenté parune classe particulière "Datavox" dérivée à partir de la classe "Système de ReconnaissanceVocale". Il héritera alors des fonctions et données (publiques ou protégées) de ses classesmères, et pourra, de plus, implémenter ses propres caractéristiques.

De même, en sortie, la classe "Système de Synthèse de Parole" servira à représenter lescaractéristiques communes à tous les systèmes de synthèse de parole, telles que des fonctionsde réglage du volume, de la vitesse d'élocution, de la hauteur, etc. Un système de synthèse deparole particulier sera alors représenté par une classe dérivée à partir de cette classe.


156

InfovoxDatavox

Oculomètre

Ecran 3DSystème deSynthèse de

Parole

SynthétiseurMIDI

Reproducteurde sons

Echantillonnés

Ecran 2D

Afficheur Braille

Système de reconnaissance

vocale

Gant Numérique

ClavierSouris

Ecran Tactile

MédiaSortie

MédiaEntrée

Média

Figure 59. La hiérarchie des médias


157

3.12. SPECIFICATION DE L'INTERACTIONL'interaction est spécifiée à travers la description d'un ou plusieurs réseaux de transitions

(arcs et noeuds) et à travers la définition des messages.

3.12.1. Spécification des arcsLorsque le développeur déclare un arc de transition, il peut spécifier différents

paramètres.

Le message associé à cet arcCe message peut-être un message élémentaire prédéfini ou un message composé.

Les valeurs des attributs du messageS'il s'agit d'un type de message en entrée, ces valeurs offrent au développeur un moyen

simple et rapide de spécifier une instance de message particulière en lui évitant d'écrire luimême une condition qui vérifie s'il s'agit bien de cette instance. Ceci est, par exemple,particulièrement utile dans le cas de la parole. Le développeur spécifie uniquement le type demessage "Word" et indique la chaîne de caractères correspondant au mot désiré (par exemple"copier"). L'avantage de cette spécifications de valeurs est qu'elle peut se faire de manièrecomplètement interactive. Dès que le développeur a spécifié le type de message, une boite dedialogue affichant les différents attributs du message peut être affichée et le développeur n'aplus alors qu'à remplir les champs qui l'intéressent. Eventuellement si ces tests d'égalité nesont pas suffisants, le développeur peut bien sûr écrire une condition dans un langage deprogrammation conventionnel offrant plus de puissance et plus d'opérateurs de comparaison.L'utilisation de la condition est également utile dans les cas où l'instance de message désiréene peut être connue qu'au moment de l'exécution (de manière dynamique et non statique), cequi est souvent le cas, par exemple, des messages relatifs à la souris et se produisant dans lazone de travail d'une fenêtre, étant donné que le contenu de cette zone de travail évolue demanière dynamique selon l'activité de l'utilisateur.

S'il s'agit d'un type de message de sortie, ces valeurs permettent d'indiquer de manièreprécise à la machine l'instance du message à produire. Si les valeurs du message à produire nepeuvent être connues de manière statique, le développeur peut écrire une action pour fixer demanière dynamique les valeurs du message à produire. Par exemple, les valeurs d'un messaged'erreur synthétisé vocalement peuvent être en général spécifiées de manière statique. Enrevanche, la spécification des valeurs d'un message correspondant à la lecture vocale d'untexte écrit par l'utilisateur ne peut se faire que de manière dynamique.


158

Une conditionLa condition permet en général d'apporter un contrôle sémantique sur le message avant

son acceptation ou sa production.

Une actionL'action permet de réaliser des traitements sémantiques en réponse au message (entrée)

ou de fixer de manière dynamique les valeurs de ses attributs (sortie).

Le noeud destinationIndique le noeud ou aboutit l'arc.

Le nom de l'arcIl s'agit en général d'un message plus que d'un nom. Il peut avoir différentes utilités. Il

aide le développeur à mieux se rappeler du rôle joué par chaque transition. Il peut égalementservir à fournir une aide contextuelle à l'utilisateur, ou à résoudre les cas d'indéterminisme enengageant un dialogue explicatif.

3.12.2. Spécification des noeudsLa spécification des noeuds comporte moins de paramètres que celle des arcs. Ici,

l'utilisateur doit simplement indiquer le nom du noeud (optionnel) et surtout la liste des arcssortant de ce noeud.

REMARQUEComme nous l'avons déjà signalé, nous avons adopté une approche objet pour la

représentation des arcs et des noeuds. Les différents paramètres spécifiés par le développeurlors de la déclaration d'un arc ou d'un noeud sont stockés au sein de l'entité ainsi créée. Onpeut noter que chaque objet arc possède en son sein un pointeur vers son noeud destination(un arc ne peut aboutir qu'à un seul noeud) et chaque objet noeud possède en son sein une listede pointeurs vers ses différents arcs sortants (plusieurs arcs peuvent partir d'un même noeud).Cette représentation permet un accès rapide aux différents éléments du réseau et occupe unespace mémoire minimal.

Un autre avantage de cette représentation est qu'un même objet arc peut être utiliséplusieurs fois sans qu'il soit nécessaire de le dupliquer. Par exemple, un pointeur vers un arcA1 peut très bien être inclus dans la liste de plusieurs noeuds N1, N2,...Nn. Ce qui reviendraità faire partir un même arc de différents noeuds (fig. 60).


159

N1

N2

N3

N4

N5

A1 N6

Figure 60. Exemple d'arc partagé par plusieurs noeuds

3.12.3. Définition des messagesLa définition d'un message se fait par utilisation des opérateurs de composition

appliqués à des messages élémentaires et/ou à des messages composés définis avant lemessage en cours de définition. Comme pour les arcs de transitions, il est possible à chaquedéfinition de spécifier pour chaque message composant, un ensemble de valeurs, unecondition et une action.

3.12.4. ExempleLa fig. 61 montre un exemple de spécification d'une commande à entrées-sorties

entrelacées. Il s'agit d'une commande permettant à l'utilisateur de tracer un rectangle et demodifier sa couleur au cours même du tracé. Pour cela, le scénario d'interaction adopté est lesuivant :

1. l'utilisateur prononce le mot "rectangle" et appuit en même temps sur le bouton dela souris,

2. en maintenant le bouton appuyé, il déplace la souris; un rectangle est alors dessinéen utilisant la couleur courante, et sa taille change en fonction des mouvements dela souris,

3. à tout moment durant les déplacements de la souris, l'utilisateur peut prononcer lenom d'une couleur; le rectangle prend alors instantanément la couleur spécifiée,

4. quand l'utilisateur a choisi la bonne taille et la bonne couleur, il relâche le boutonde la souris.


160

N1 N2 N3

N4

N5

N6A1 A2

A3A4

A5A4

A6


Figure 61. Exemple de spécification d'une commande de tracé de rectangle avecpossibilité de changement de la couleur au cours du tracé

Nous donnons ci-dessous les déclarations correspondantes :

Spécification des arcs d'entréeA1 (M1, AA1, N2, "Prononcer rectangle et appuyer sur le bouton");A3 (MouseMove, AA3, N5, "Déplacement souris");A5 (M5, AA5, N4, "Prononcer un nom de couleur");A6 (MouseLeftButtonUp, AA6, N6, "Relâchement bouton ");

Spécification des arcs de sortieA2 (N3, MS2, "Afficher mot reconnu");A4 (N3, AA4, MS4, "Mise à jour affichage rectangle");

Spécification des noeudsN1 (A1);N2 (A2);N3 (A3, A5, A6);N4 (A4);N5 (A4);N6 ();


161

Définition des messagesM0=(Word,"rectangle");M1=M0*MouseLeftButtonDown;M5=(Word,CM5);MS4=MS41+MS42;

Explications

• La condition CM5 vérifie que le mot reconnu correspond à une couleur.• Le message MS2 affiche dans une fenêtre le mot reconnu.• Le message MS4 est une composition séquentielle de deux messages : MS41 et

MS42. MS41 restaure l'affichage en dessous d'une zone rectangulaire de l'écran.MS42 affiche un rectangle avec la couleur courante à l'endroit spécifié après avoirsauvegardé le contenu de l'écran à cet endroit32.

• L'action AA1 initialise les coordonnées des deux points définissant le rectangle auxcoordonnées du point où s'est produit l'appui du bouton.

• L'action AA3 met à jour les coordonnées du second point définissant le rectangle àjour et mémorise les anciennes coordonnées dans une variable temporaire.

• L'action AA4 initialise les valeurs de attributs des messages MS41 et MS42 à partirdes coordonnées anciennes et nouvelles du rectangle.

• L'action AA5 change la valeur de la couleur courante en fonction du nom de lacouleur prononcée et met dans la variable temporaire les coordonnées courantes dusecond point du rectangle.

• L'action AA6 mémorise les coordonnées finales et la couleur finale du rectangle.• Remarquons enfin que le même arc A4 a été utilisé à partir des noeuds N4 et N5.

3.12.5. Spécification interactive de l'interactionPour faciliter la tâche de spécification de l'interaction, une interface graphique (fig. 62)

pour l'édition interactive des réseaux a été développée dans le cadre du stage de DESS de M.Krus. Cette interface permet de dessiner avec la souris les réseaux de transitions qui décriventl'interaction et génère par la suite le fichier de déclarations nécessaire à SPECIMEN. Nousrenvoyons le lecteur à [Krus 93] pour plus de détails concernant cette interface.

32On pourrait naturellement définir des messages de sortie plus adéquats afin d'augmenter la vitesse

d'affichage, par exemple en ne restaurant que la partie de l'écran qui redevient visible suite au déplacement de lasouris et en complétant l'affichage du rectangle au lieu de le redessiner complètement. Nous avons considéré cesmessages afin de simplifier l'exemple.


162

Figure 62. Interface d'édition des réseaux

3.13. CONCLUSIONDans ce chapitre nous avons présenté un outil pour la spécification des interactions

multimodales. Celles-ci combinent aussi bien des interactions langagières qu'actionnelles. Ildevient alors nécessaire de disposer de modèles hybrides qui puissent supporter ces deuxtypes d'interaction.

Le modèle que nous avons présenté constitue un premier pas vers cet objectif. Encombinant le modèle des ATNs à un modèle de spécification par messages, nous avons vouluconcevoir un outil apte à supporter aussi bien des interactions langagières qu'actionnelles.

Ce modèle a en particulier permis de montrer, à travers notre méthode de fusiondistribuée, qu'il était possible de disposer d'outils génériques pour le développementd'interfaces multimodales synergiques intégrant en leur sein un processus de fusion efficacemême si les critères sémantiques ne sont pas exploités.

Nous présenterons dans le prochain chapitre un exemple d'une application concrèteréalisée avec SPECIMEN.

Chapitre4


164

Chapitre 4.

Application aux interfaces non visuelles

4.1. INTRODUCTIONNous présentons dans ce chapitre, MEDITOR, un éditeur de textes multimodal pour

non-voyants. Ce travail a été mené dans le cadre d'une collaboration entre le LIMSI-CNRS,l'INSERM (Institut National de la Santé et la Recherche Médicale) et l'INJA (InstitutNational des Jeunes Aveugles). Cette collaboration a été mise en place à la demande del'INSERM pour évaluer l'intérêt de la multimodalité dans les interfaces non visuelles[Burger 92a]. De ce fait, l'objectif visé à travers la réalisation de ce travail était double. D'unepart, il s'agissait de tester la validité de SPECIMEN en tant qu'outil d'aide au développementd'interfaces multimodales à travers une application précise et concrète. D'autre part, il étaitintéressant d'étudier l'apport de la multimodalité au problème de l'accès aux technologiesinformatiques par des utilisateurs non-voyants.

Les systèmes d'accès classiques utilisées par les non-voyants ont donné de bons résultatsavec les interfaces textuelles. En revanche, les méthodes utilisées par ces systèmes s'avèrenttotalement inadaptées aux interfaces graphiques. Celles-ci posent des problèmes complexescar elles exploitent de manière intensive les capacités visuelles de l'être humain. L'adaptationà un utilisateur non-voyant est, de ce fait, rendue beaucoup plus difficile.

Il faut souligner que l'objectif visé à travers la conception de MEDITOR n'était pas derésoudre le problème d'adaptation d'une interface graphique à un utilisateur non-voyant, maisde montrer que la multimodalité doit être intégrée dans la solution de ce problème car ellepeut avoir un apport considérable dans la définition de nouvelles formes d'interaction nonvisuelles conviviales et réellement adaptées aux limites et aux besoins des utilisateurs non-voyants.

Nous commencerons ce chapitre par expliquer l'importance que revêt l'accès auxtechnologies informatiques pour les non-voyants. Nous présenterons les méthodes classiquesqui ont été utilisées pour permettre cet accès et nous montrerons, à travers les problèmesqu'elles soulèvent, pourquoi les interfaces graphiques risquent de remettre en cause les


165

avantages acquis. Nous présenterons et analyserons ensuite quelques systèmes d'accèsexistants ou en cours de développement. Puis, MEDITOR sera décrit, en insistant enparticulier sur certaines fonctionnalités et les scénarios d'interaction qui leur correspondent.Nous verrons à travers ces fonctionnalités comment certains problèmes, rencontrés avec lesdocuments braille papier ou les logiciels d'accès classiques, ont été résolus dans MEDITOR.Nous clôturerons ce chapitre en présentant les résultats d'une évaluation ergonomiquepréliminaire réalisée par l'INSERM qui poursuit actuellement une étude plus complète surl'application mise en service avec plusieurs élèves de l'INJA pour une durée de plusieurssemaines.

4.2. POSITION DU PROBLEMEAvant l'existence du braille, les non-voyants étaient condamnés à l'ignorance et à

l'isolement. Ils ne pouvaient ni lire, ni écrire. Grâce au braille, il leur est devenu possibled'accéder à un certain savoir car la transcription braille n'est pas aussi simple et rapide quel'écriture manuscrite. Elle est aussi plus coûteuse. Enfin, les documents générés occupentbeaucoup plus d'espace que leurs équivalents manuscrits. Cependant, malgré sesinconvénients, le braille a quand même constitué une révolution dans la communauté des non-voyants.

Aujourd'hui les ordinateurs sont devenus des outils de travail quotidiens pour lesvoyants et l'informatique vient lancer un nouveau défi à l'intégration sociale et professionnelledes non-voyants. Ne pas pouvoir accéder aujourd'hui aux technologies informatiques risque deramener la communauté des non-voyants au même stade dans lequel elle se trouvait avantl'existence du braille. Si dans un premier temps (le temps des interfaces textuelles) l'ordinateura été d'un apport considérable pour les non-voyants et leur a ouvert une porte d'accès vers unespace de connaissances beaucoup plus vaste, aujourd'hui les interfaces graphiques sont enpasse de remettre en cause cet acquis. En effet, celles-ci exploitent de manière accrue lescapacités visuelles des utilisateurs, et rendent de ce fait l'accès aux ordinateurs par desutilisateurs non-voyants beaucoup plus complexe. Et il n'est pas inutile de se poser lesquestions suivantes: "les aveugles et les mal-voyants travaillent-ils de la même façon que lespersonnes voyantes ? Ont-ils réellement besoin des mêmes outils ? Est-il réellementnécessaire de présenter l'écran à l'utilisateur aveugle de la même manière dont il est présentéaux personnes voyantes ?" [Fasser 94]33.

33Christina Fasser est aveugle membre de la Fédération Suisse des Aveugles et de l'International Retinitis

Pigmentosa Association. Elle a perdue la vue de manière progressive.


166

Il est évident que les interfaces graphiques nous amènent à nous poser de nouvellesquestions par rapport au problème de l'accès aux ordinateurs par des utilisateurs non-voyants.Nous montrerons dans la suite que la multimodalité constitue un facteur indispensable à sasolution. En effet, pour être ergonomiquement adaptée aux besoins spécifiques des non-voyants, la reconstruction de l'interface doit exploiter de manière maximale leurs capacitéssensori-motrices. La multimodalité peut contribuer à rendre optimale cette exploitation.

4.2.1. Les méthodes classiques d'accès aux interfacesvisuellesLes méthodes classiques d'accès aux interfaces visuelles reposent sur un principe

simple. On suppose qu'à tout instant le contenu de l'écran est complètement représenté enmémoire et est directement accessible par un programme. Ces méthodes supposent que lecontenu de l'écran est composé exclusivement de texte avec éventuellement des attributssimples tels que la couleur ou le clignotement des caractères34. Le programme d'accès auraalors simplement à repérer la position du curseur à l'écran et à lire dans la mémoire-écran letexte correspondant à la ligne courante. Une fois cette information récupérée, il suffira de lacommuniquer à l'utilisateur non-voyant. Pour cela deux méthodes peuvent être utilisées :l'affichage braille ou la synthèse de parole.

4.2.1.1. L'affichage brailleLe braille permet aux non-voyants d'accéder à des informations textuelles (fig. 63).

Figure 63. Lecture d'un document braille.

34Dans ce cas, les programmes d'accès offrent en général deux modes : le premier pour la lecture du texte

et le second pour la lecture des attributs.


167

Un caractère braille traditionnel est composé de six points alignés en deux colonnes(fig. 64). Selon la position levée ou baissée des points, il est possible de disposer de 64configurations différentes. De ce fait il n'est théoriquement possible de représenter que 64caractères. Cependant, certains caractères sont utilisés en tant que codes spéciaux35 etpermettent ainsi d'étendre l'ensemble des caractères représentés.

braille classique

1

2

3

4

5

6

7 8

braille informatique

Figure 64. Structure d'un caractère braille.

Les terminaux braille (fig. 65) quant à eux possèdent en général des cellules braillecomposées de huit points. Ainsi, ils permettent théoriquement de représenter l'équivalent des256 caractères ASCII. Malheureusement, il n'existe pas encore de standard en la matière, cequi a amené l'émergence de différentes tables braille selon les constructeurs. Les terminauxbraille, permettent en général d'afficher une ligne de 20, 40 ou 80 caractères.

Figure 65. Un terminal braille

35Par exemple le caractère [4,6] (points 4 et 6 levés) est utilisé pour représenter les majuscules. Le

caractère suivant ce caractère spécial sera alors considéré comme étant une majuscule.


168

4.2.1.2. La synthèse de paroleLa synthèse de parole représente la technique la plus utilisée par les non-voyants pour

accéder aux ordinateurs. Ceci s'explique par deux raisons. D'une part, seule une minorité desnon-voyants lit le braille [Griffith 90] (moins de 10%). D'autre part, le coût d'un système desynthèse de parole est beaucoup plus faible que celui d'un terminal braille. Plutôt qued'envoyer le texte correspondant à la ligne courante, sur l'afficheur braille, le programmed'accès l'enverra cette fois-ci à un système de synthèse de parole.

REMARQUEOn peut noter que ces méthodes d'accès ne gèrent en fait que l'aspect "sortie" de

l'interface. Aucune solution n'est apportée au niveau des entrées. Dans le cas de la synthèse,l'utilisateur non-voyant est obligé d'apprendre à utiliser le clavier standard. Dans le cas del'affichage braille, si son terminal dispose d'un clavier braille, il pourra alors, en général,utiliser ce dernier à la place du clavier standard. Cependant, il demeure quand même contraintde mémoriser les raccourcis claviers utilisés dans l'interface.

4.2.2. Problèmes posés par les interfaces graphiquesLes techniques utilisées pour l'accès aux interfaces visuelles, consistent comme nous

venons de le voir, à reproduire le contenu de l'écran sur un afficheur braille, ou à travers lasynthèse de la parole. Cette approche, qui a pour avantage de permettre une adaptation directedes informations affichées à l'écran, sans aucune modification du logiciel original, a donné debons résultats avec les interfaces textuelles. En effet, la structure textuelle peut êtrecommuniquée aussi bien à travers les modes visuel, tactile ou auditif. Cependant, cetteapproche est inapplicable pour les interfaces graphiques. Celles-ci sont basées sur lesprincipes de la manipulation directe énoncés par Shneiderman [Shneiderman 86]. Certains deces principes sont difficilement applicables aux interfaces non visuelles, car ils se basentimplicitement sur le mode visuel, pour la présentation des informations. Par exemple, l'état dusystème doit être présenté à l'utilisateur de façon permanente. Il est difficile d'appliquer ceprincipe aux interfaces non visuelles. En effet, seul le mode visuel, peut permettre àl'utilisateur de disposer d'une perception globale de l'état d'un système. Les modes sonore outactile imposent une perception séquentielle, ce qui rend difficile la perception continue del'état d'un système (composé en général de plusieurs informations) par un utilisateur aveugle.Par ailleurs les principes énoncés par Shneiderman recommandent que les objets d'interactionpuissent être manipulés directement à travers des actions physiques. Ces actions se font parl'intermédiaire de dispositifs de désignation 2D (souris, écran tactile, stylo, etc.) quiimpliquent une coordination constante entre le geste et la vision. Enfin, les interfacesgraphiques intègrent beaucoup de structures pictographiques à travers les images et les icônes,


169

et même le texte se trouve enrichi d'attributs (style, police de caractères, taille...) qui nepeuvent être perçus directement et de manière simple à travers les modes tactile ou sonore.

4.2.2.1. Nécessité d'une reconstruction intelligente de l'interfaceToutes ces considérations impliquent donc une reconstruction intelligente de l'interface

visuelle car l'approche qui consiste à reproduire directement le contenu de l'écran à travers lesmodes tactile ou sonore se révèle inappropriée aux interfaces graphiques. Au lieu dereproduire les formes de présentation visuelles sur les modes non visuels, il devientmaintenant nécessaire d'adapter les concepts d'interaction, en leur trouvant de nouvellesformes qui conviennent réellement aux utilisateurs non-voyants (fig. 66). Il faut éviter de sefocaliser sur la présentation visuelle des objets d'interaction, et réfléchir plutôt aux conceptsd'interaction qui sont véhiculés par ces objets36 afin d'imaginer des styles d'interaction nonvisuels conviviaux, adaptés et qui puissent représenter ces concepts.

Adaptation

Forme d'interaction visuelle Forme d'interaction non visuelle

d'interactionConcept

Présentation visuelle Présentation non visuelleReproduction

Approche classique

Approche intelligente

Figure 66. Les approches d'accès aux interfaces visuelles

La reconstruction intelligente de l'interface doit concerner non seulement les sortiesmais également les entrées. Les interactions impliquant l'usage de la souris doivent fairel'objet d'une réflexion poussée afin que des scénarios d'interaction non visuels équivalentspuissent être définis. Cette reconstruction intelligente demeure un problème non encore résolumalgré les tentatives qui ont été menées dans ce sens, et il n'est pas inintéressant de se poser laquestion suivante "Could computer tools for the visually handicapped be someday as friendlyas those for sighted people ?"37 [Burger 94].

36Par exemple, une boite à liste véhicule le concept de choix d'un élément dans un ensemble. Les boutons

radio quant à eux véhiculent le concept de sélection exclusive, etc.37"Les outils informatiques pour handicapés visuels seront-ils un jour aussi conviviaux que ceux utilisés

par les voyants ?"


170

4.2.2.2. Position de MEDITORMEDITOR ne prétend pas apporter une solution au problème de la reconstruction

intelligente de l'interface. En effet, l'objectif visé n'était pas d'adapter une interface graphiqueà un utilisateur non-voyant, mais de montrer à travers une application spécifique, que lamultimodalité est une caractéristique importante qui doit être intégrée dans cettereconstruction. La définition de nouveaux scénarios d'interaction non visuels multimodauxpeut avoir un apport considérable pour l'augmentation de l'efficacité, la convivialité, la facilitéd'apprentissage et d'utilisation de l'interface non visuelle.

4.2.2.3. Accès aux composants de l'interface graphiqueEn amont du problème de la reconstruction intelligente de l'interface, se pose un autre

problème : comment un programme peut-il accéder aux informations affichées à l'écran ? Eneffet, dans le cas des interfaces textuelles, la mémoire écran contient (entre autres)directement les codes ASCII correspondant aux caractères affichés. Par contre, pour lesinterfaces graphiques, elle contient des informations indiquant la couleur de chaque pixel del'écran. Ceci rend complexe pour un programme, la tâche de savoir ce qui est affiché à l'écranà un instant donné. S'il est possible d'envisager l'utilisation des algorithmes de reconnaissancede caractères appliqués à la mémoire écran pour l'identification du texte, la présence dans uneinterface graphique d'entités non textuelles rend cette méthode insuffisante [Harness 93][Gunzenhäuser 94]. C'est pourquoi les solutions appliquées pour récupérer les informationsaffichées à l'écran utilisent une autre technique : l'Off-Screen Model.

4.2.2.4. La technique de l'Off-Screen ModelCette technique repose sur l'exploitation d'une caractéristique commune à la majorité

des systèmes graphiques : la communication par messages. En effet, dans la plupart des cas,chaque fois qu'une opération affectant l'interface est exécutée, un message permettant del'identifier est émis par le système graphique. Ce message permet en général de connaîtreégalement les paramètres de cette opération. Par exemple, chaque fois qu'un programme créeou détruit une fenêtre, affiche un menu, un bouton, une barre de défilement etc., il fait appel àdes fonctions du système graphique. Ces fonctions une fois exécutées générent des messagesqui vont transiter dans le système. L'idée de la technique de l'Off-Screen Model consiste àintercepter ces messages et à les exploiter pour construire une représentation interne quireflète la configuration de l'écran [Schwerdtfeger 91] [Kochanek 94]. Cette représentationinterne va permettre à travers l'utilisation de certaines requêtes, de connaître tout ce qui estaffiché à l'écran (ou presque) mais également des informations qui ne sont pas forcémentvisibles à l'écran à un instant donné (telles que les rubriques d'un menu déroulant) mais quipeuvent être utiles pour l'utilisateur [Berliss 93]. Cette technique a été utilisée pour la


171

première fois par Berkeley Systems dans le cadre du programme OUTSPOKEN (cf. §. 4.3.1).Elle a été par la suite appliquée dans la plupart des systèmes offrant un accès aux interfacesgraphiques. En général l'OffScreen Model utilise une structure arborescente pour représenterles composants de l'interface. Cette structure dérive du fait que dans les interfaces graphiquesles fenêtres possèdent une structure arborescente (notion de fenêtre mère et de fenêtres filles).Vu que la plupart des éléments de l'interface sont considérés comme des fenêtres (en généralce sont des classes spécialisées de fenêtres), il semble logique d'adopter pour l'OffScreenModel une structure similaire.

4.3. EXEMPLES DE SYSTEMES EXISTANTSNous présentons ci-dessous quelques systèmes existants représentatifs des travaux

menés actuellement dans le domaine des interfaces non visuelles, puis nous effectuerons uneanalyse critique des méthodes utilisées.

4.3.1. OUTSPOKENOUTSPOKEN [Berliss 93] [Rubin 92] est un des premiers systèmes offrant à des utilisateursnon-voyants la possibilité d'accéder à une interface graphique. Il a été développé par BerkeleySystems pour le Macintosh d'Apple. OUTSPOKEN utilise principalement la synthèse deparole (plus quelques bips) pour communiquer à l'utilisateur non-voyant, les informationsaffichées sur l'écran du Macintosh. Les touches du pavé numérique du clavier (éventuellementen combinaison avec les touches Shift, Command ou Option) sont utilisées comme touches defonctions servant à l'exploration de l'interface. Ces touches permettent d'exécuter différentesopérations de navigation telles que :

• remonter d'une ligne et lire la nouvelle ligne,• descendre d'une ligne et lire la nouvelle ligne,• se déplacer d'un mot vers la droite ou vers la gauche et lire le nouveau mot,• se déplacer d'un caractère vers la droite ou vers la gauche et lire le nouveau

caractère,• déplacer le curseur en haut à gauche,• déplacer le curseur en bas à droite,• accéder à la barre des menus,• accéder à la liste des fenêtres ouvertes,• etc.


172

La touche SELECT (touche 5 du pavé numérique) est utilisée pour simuler les clics et lesdoubles clics d'une souris. La touche DRAG (touche 0)est utilisée pour simuler le"glisser/déplacer" de la souris (entrée et sortie du mode "glisser/déplacer").

Bien que OUTSPOKEN ait marqué un pas important dans la résolution du problème d'accèsaux interfaces graphiques par des non-voyants (notamment à travers l'introduction de la notiond'OffScreen Model), de nombreux problèmes n'ont cependant pas été résolus. Ainsi, toutes lesapplications basées sur l'utilisation de graphiques (MacDraw, MacPaint, SuperPaint, leslogiciels de composition musicale, etc.) restent inaccessibles. Par ailleurs, même pour lesapplications accessibles (Microsoft Word, FileMaker, Microsoft Excel, QuickMail, etc.)certains problèmes sont restés sans solution. Par exemple, l'utilisateur non-voyant n'auraaucun moyen de distinguer une rubrique grisée d'un menu (indiquant qu'elle n'est pasdisponible) d'une autre rubrique non grisée. Il est également impossible de savoir quelle partied'un texte est actuellement sélectionnée. Si cela peut être aisément connu par un utilisateurvoyant (grâce à l'inversion vidéo), aucun moyen n'a été prévu dans OUTSPOKEN pourfournir à l'utilisateur ce type d'informations. En fait, le problème qui se pose dans ce derniercas est que la sélection est gérée par l'application et non par le système graphique. Parconséquent OUTSPOKEN n'a aucun moyen d'intercepter une telle information. Nous verronsque le système suivant (SCREEN READER) permet de résoudre (d'une certaine manière) cetype de problèmes en offrant aux développeurs, un langage qui va permettre de rajouter desprocédures d'adaptation spécifiques à une application donnée.

4.3.2. SCREEN-READERSCREEN-READER [Thatcher 94a] [Thatcher 94b] [Emerson 91] [Adams 88] est un

programme conçu par IBM qui permet à des utilisateurs non-voyants d'accéder à l'interfacegraphique d'OS2, le système d'exploitation développé par IBM pour les ordinateurs de typePC. Il intègre un langage dénommé PAL (Profile Access Language) qui permet à desdéveloppeurs d'accéder aux composants de l'interface graphique et d'écrire leurs propresprocédures d'adaptation en définissant de nouveaux profiles. Un profile détermine la manièredont l'accès à l'interface se fait par l'utilisateur non-voyant. Il est possible de définir desprofiles propres à chaque application. SCREEN-READER intègre un profile de base (pardéfaut) qui permet à l'utilisateur de naviguer à travers les différentes fenêtres de l'interface etde prendre connaissance de leur contenu. Il est intéressant de définir de nouveaux profiles defaçon à enrichir le profile de base et à améliorer son comportement en fonction del'application courante. Par exemple, il sera possible pour une application donnée de définir unnouveau profile qui permettra de communiquer automatiquement par synthèse de parole lesmessages d'erreurs éventuels que cette application pourrait renvoyer au cours de son


173

exécution. Ceci évitera à l'utilisateur non-voyant d'explorer la boîte de dialogue affichant lemessage d'erreur comme il le ferait avec n'importe quelle autre fenêtre (ce qui correspond à laméthode prévue par le profile de base). Le profile de base définit donc une manière standard,homogène d'accéder à l'interface. Les nouveaux profiles permettent de modifier, d'améliorer etd'optimiser cet accès en fonction de l'application courante.

Comme pour OUTSPOKEN, le profile de base offre une restitution sonore, à travers lasynthèse de parole, du contenu de l'écran. Cependant dans SCREEN READER, cinq formatsde synthèse sont prévus:

• lecture simple,• lecture avec ponctuation (la ponctuation est épelée),• lecture épelée (tous les caractères sont épelés),• lecture phonétique (tous les caractères sont épelés selon l'alphabet phonétique

international),• lecture ASCII (les caractères sont épelés selon leurs codes ASCII).

En entrée, différentes requêtes sont prévues pour l'exploration :

• lecture de tout le contenu de la fenêtre courante,• lecture du caractère, mot, ligne ou phrase courante, suivante ou précédente,• déplacer le curseur vers la droite, la gauche, en bas ou en haut,• etc.

Toutes les requêtes se font à travers un clavier additionnel de 18 touches qui doit êtreraccordé au PC.

Une caractéristique importante du langage PAL est la possibilité de définir des actionsdont l'exécution est liée à la production de certains événements particuliers. Ceci permettrad'informer l'utilisateur non-voyant de certains événements importants qui pourraient seproduire de manière asynchrone (réception d'un mail, fin d'un processus, etc.). Cependant cecidoit bien sûr être programmé et ne se fait pas de manière automatique.

4.3.3. GUIBLe projet GUIB [Fellbaum 94] [Guib 93] (Textual and Graphical User Interface for

Blind People) fait partie du programme TIDE (Technology Initiative for the Disabled andEderly) de la Communauté Economique Européenne. Il regroupe dix organismes de recherche


174

et d'industrie de six pays européens. Comme les deux précédents systèmes, il vise à permettrel'accès aux interfaces graphiques par des utilisateurs non-voyants (deux systèmes graphiquesont été choisis : Microsoft Windows et X-Window). Cependant, le projet GUIB essayed'utiliser le son de manière maximale et en exploitant toutes ses dimensions. Cetteexploitation maximale du son s'effectue essentiellement à travers trois points : l'exploitationde la dimension spatiale du son, l'exploitation de "l'effet de cocktail party" et l'utilisation deplusieurs modalités sonores (parole, icônes auditives, earcons).

4.3.3.1. Exploitation de la dimension spatiale du son.L'exploitation de la dimension spatiale du son consiste à répartir les sons générés dans

l'espace acoustique en fonction de la position à l'écran des objets auxquels ils correspondent.Deux méthodes ont été expérimentées. La première consiste à utiliser une matrice de cinqhaut-parleurs "SoundScreen" (fig. 67) pour générer des sons dans un plan 2D.

Figure 67. Le SoundScreen.

Cette méthode ne s'est pas révélée très précise (ce qui était en fait prévisible vu la trèsgrande résolution des écrans graphiques) et de plus ne permet pas d'exploiter la troisièmedimension spatiale. Bien que l'écran soit lui même en deux dimensions, l'interface graphiquecomporte cependant des éléments (par exemple fenêtres empilées les unes derrière les autres)pour lesquels il peut être utile d'exploiter la troisième dimension. C'est pourquoi, une secondeméthode est en cours de test. Elle consiste à utiliser un casque capable de restituer des sons en3D. Le système utilisé est le système Beachtron38. L'utilisation d'un tel système permet decréer une cartographie spatiale 3D virtuelle à partir de l'interface graphique 2D. La troisièmedimension est utilisée pour représenter des traitements en arrière plan ou des objets interactifs

38Ce système est développé par la firme American Manufacturer Crystal River Engineering.


175

passifs. La spatialisation du son est également appliquée à la synthèse vocale. Ainsi le songénéré par la synthèse d'un texte affiché horizontalement pourra être perçu comme allant degauche à droite. Celui d'un texte affiché verticalement sera perçu de haut en bas (ce qui peutêtre utile dans les cas de tableaux ou de feuilles de calculs).

4.3.3.2. Exploitation de "l'effet de cocktail party"."L'effet de cocktail party" [Cherry 58] décrit le phénomène de perception grâce auquel

un auditeur est capable de faire la distinction entre différentes sources sonores et de seconcentrer sur celles qui l'intéressent en ignorant les autres, si ces sources sonores sontréparties de manière distincte dans l'espace. L'utilisation du son spatial permet d'exploiter ceteffet pour décrire simultanément plusieurs objets interactifs ou fournir à l'utilisateur un feed-back continu de différents processus tournant en arrière plan.

4.3.3.3. Utilisation de diverses modalités sonores.Trois principales modalités sonores sont utilisées dans GUIB : la parole, les icônes

auditives, et les earcons. Les icônes auditives correspondent à des sons naturelséchantillonnés [Gaver 89]. Les earcons sont des sons obtenus par l'utilisation de fréquencesmusicales organisées selon une grammaire plus ou moins complexe faisant intervenir deschangements de hauteur et de rythmes [Blattner 89]. L'utilisation des icônes auditives,minimise l'effort d'apprentissage en comparaison avec celui qui est nécessaire pourl'apprentissage d'une grammaire musicale complexe. En effet, l'utilisation d'icônes auditivesrevient en quelque sorte à utiliser une métaphore auditive pouvant fonctionner de la mêmemanière qu'une métaphore visuelle. Toutefois, il est difficile de trouver des sons naturelspouvant représenter tous les objets qu'on peut trouver dans une interface graphique ainsi queles opérations qui leur sont applicables. C'est pourquoi GUIB exploite les deux modalités.Ainsi l'ouverture d'une fenêtre est indiqué par le bruit d'ouverture d'une porte hydraulique et ledéplacement de la souris par le déplacement spatial d'une note (rimshot).

4.3.4. MATHSLe projet MATHS (Mathematical Access for TecHnology and Science) [Edwards 93]

[Edwards 94] fait également partie du programme TIDE. Il regroupe six membres de cinqétats européens. Le projet MATHS ne s'inscrit pas dans la même problématique que les troissystèmes précédents. Le but ici n'est pas de résoudre le problème de l'accès aux interfacesgraphique mais de développer une application spécifique qui puisse permettre à deshandicapés visuels de lire et de manipuler des formules mathématiques. Les expressionsutilisées en mathématiques sont variées et complexes. Leur traduction sous une forme nonvisuelle n'est pas une tâche facile. C'est pourquoi le projet MATHS s'intéresse plus


176

particulièrement aux expressions textuelles (équations, expressions algébriques, etc.). Lesreprésentations graphiques (courbes, diagrammes géométriques, etc.) et les notationsbidimensionnelles telles que les matrices sont considérées comme trop complexes à ce stadede la recherche. La première phase du projet a été d'évaluer les besoins des utilisateurs. Cetteétude a montré que le nombre d'élèves aveugles étudiant les mathématiques est réduit enraison des problèmes d'accès rencontrés. L'analyse des tâches comparative menée auprèsd'élèves voyants et non-voyants faisant des mathématiques a fait dégager deux hypothèses :

1. Les processus cognitifs de haut niveau mis en jeu ne diffèrent pas pour les deuxcatégories. En revanche, les processus perceptifs de bas niveau sont différents. Les voyantslisent les formules selon un processus top-down (du général vers le particulier) alors que lesnon-voyants utilisent un processus inverse bottom-up (du particulier vers le général).

2. Les voyants s'aident d'une mémoire externe (crayon et feuille de papier) alorsque les non-voyants utilisent davantage leur mémoire interne.

Les participants au projet ont relevé un certain nombre de caractéristiques propres auxformules mathématiques et qui rendent leur traduction sous des formes non-visuellesparticulièrement difficile, telles que la précision des notations et l'absence de redondance. Sipour le langage une erreur sur un caractère ou sur un mot est, en général, sans incidence sur lacompréhension globale de la phrase, en revanche en mathématiques, une erreur sur un seulcaractère ou même un espacement, peut conduire à une interprétation complètement erronéede la formule. Il résulte de cette absence de redondance que de très faibles modificationsd'écriture produisent des changements de sens complets [Edwards 94].

Bien que les acteurs du projet présentent différentes propositions pour résoudre leproblème de l'accès aux formules mathématiques par des non-voyants (notamment l'utilisationde la reconnaissance de la parole, et des règles de Chang [Chang 83] pour les mathématiquesparlées39), peu d'entre elles ont été à l'heure actuelle, effectivement mises en oeuvre et testées.Actuellement, le projet MATHS repose principalement sur une extension du programmeMathTalk. Ce programme permet de présenter des formules mathématiques sous une formesonore (parlée ou non parlée). Cependant, il n'autorise pas leur saisie. MathTalk intègre unlangage de commandes simple. Les commandes sont composées de deux parties : l'action et lacible (fig. 68). Par combinaison des actions et des cibles, on obtient approximativement 80commandes différentes (par exemple déplacement au terme suivant, à l'expression suivante

39Les règles de Chang servent à supprimer l'ambiguïté dans les formules mathématiques en insérant un

parenthésage oral dans l'expression parlée.


177

etc.). L'entrée des commandes se fait à l'aide du clavier en utilisant les initiales des actions etdes cibles (se pour speak expression, ni pour next item, etc.).

Action Ciblespeak expression

current termnext item

previous superscriptinto quantity

out-of fractionbeginning numerator

end levelglance denominator

Figure 68. Langage de commande de MathTalk..

MATHS vise à étendre MathTalk en y intégrant des fonctionnalités qui vont permettrela saisie des formules, et ce à travers la reconnaissance de la parole ou du clavier. Par ailleurs,des expériences ont été menées sur l'emploi des earcons, c'est à dire de l'utilisation d'unenchaînement rythmé de fréquences musicales (chaque fréquence correspondant à unopérateur mathématique donné ou à un type de terme particulier), pour décrire une formulemathématique à travers un "coup d'oeil" rapide. Il semblerait que cette méthode donne unassez bon aperçu de la structure globale d'une formule (ne serait-ce que le degré de sacomplexité) ce qui peut être utile dans certains cas tels que la recherche d'une formuleparticulière (dont l'utilisateur connaît l'aspect général) parmi une liste de formules. Cependantcette méthode exige une phase d'apprentissage qui peut être fastidieuse.

4.3.5. DiscussionOn peut déplorer, pour la plupart des systèmes offrant un accès aux interfaces

graphiques, l'inexistence d'une évaluation ergonomique rigoureuse avec des utilisateurs non-voyants en situation réelle de travail. En outre, il est possible d'émettre certaines critiquesquant aux approches adoptées. Par exemple, tous ces systèmes imposent une approcheexploratoire à l'utilisateur non-voyant. Il doit constamment examiner de manière séquentielleles différentes composantes de l'interface. Si une telle approche peut sembler inévitable, iln'est cependant pas inutile de se poser la question suivante : "Est-il réellement nécessaire demettre toutes les représentations graphiques à la portée des aveugles ?" [Fasser 94]. Il seraitcertainement plus judicieux de filtrer les informations et de ne transmettre à l'utilisateur non-voyant que ce qui lui est réellement nécessaire pour remplir sa tâche à un moment donné (tout


178

en gardant la possibilité de lui transmettre toutes les informations s'il le désire) et ce afind'alléger le processus d'exploration.


179

On peut également remarquer que la plupart des systèmes d'accès existants se contententuniquement de la synthèse de parole pour communiquer des informations à l'utilisateur. Leprojet GUIB a essayé d'exploiter de manière plus poussée le mode sonore. Cependant, les testsd'évaluation relatifs à la spatialisation du son ont montré que les résultats obtenus avec leSoundScreen pour la précision des localisations spatiales étaient médiocres (en particulierdans la direction verticale). De plus ce dispositif est encombrant et occasionne une gêneinévitable pour d'éventuels utilisateurs voisins. Pour ce qui est de la seconde méthode utilisantun casque, les tests ont montré qu'en moyenne les sujets (voyants ou non-voyants) étaientcapables de distinguer 4 positions différentes dans la direction verticale et 14 dans la directionhorizontale, ce qui correspond à une résolution 14x4=56 positions discrètes. Bien qu'on puisseespérer que cette résolution s'améliorera avec l'apprentissage, il reste cependant évident quecette résolution est grossière et que nous sommes là très loin de la résolution actuelle utiliséedans les interfaces graphiques (800x600, 1024x768, 1280x1024 ...), même si les objetsinteractifs occupent en général quelques dizaines de pixels40. Quant à "l'effet de cocktailparty" les tests qui ont été menés (et qui consistaient à demander aux sujets de reconnaître unephrase prononcée par un orateur parmi quatre réparties dans quatre positions différentes del'espace et parlant simultanément) ont donné un taux de reconnaissance moyen de 50%.

On peut aussi noter que les systèmes d'accès aux interfaces graphiques (c'était égalementle cas pour les interfaces textuelles) ne proposent pas de solutions au problèmes des entrées del'interface. Par exemple, dans le cas d'OUTSPOKEN ou de SCREEN READER, les nouvellesentrées introduites par ces systèmes servent simplement à l'exploration de l'interface maisn'offrent aucune alternative aux entrées prévues déjà dans celle-ci. L'utilisateur non-voyant estobligé d'apprendre les raccourcis claviers utilisés dans l'interface. Dans GUIB, il doit mêmeapprendre à utiliser la souris dans le processus d'exploration. De plus, les requêtes denavigation ne s'appliquent en général qu'aux zones textuelles. En ce qui concerne les autresobjets interactifs couramment utilisés dans les interfaces graphiques, l'utilisateur doit se servirdes équivalents claviers standards ou de certaines combinaisons du clavier (additionnel dansle cas de SCREEN READER) qui vont générer ces équivalents claviers ou simuler des clicsou des doubles clics de la souris. Par exemple dans SCREEN READER, pour la boîte dedialogue de la fig. 69, l'utilisateur devra utiliser la touche TAB pour passer d'un objet decontrôle à un autre. SCREEN-READER lui indiquera au fur et à mesure à travers la synthèsede parole le type d'objet sur lequel il se trouve (case à cocher, bouton radio, zone d'édition de

40Par exemple, la barre d'outils de Microsoft Word pour Windows peut comporter jusqu'à 30 éléments en

horizontal. Le menu "File" de ce même logiciel possède 18 rubriques en vertical. Dans une résolution moyennede 800x600, le gestionnaire de fichiers peut afficher, toujours en vertical, plus de 30 icônes représentant desfichiers différents.


180

texte, bouton poussoir, etc.) ainsi que son étiquette textuelle. Il utilisera la barre d'espacementpour cocher ou ne pas cocher une case, les flèches de déplacement du curseur pour passer d'unbouton radio à un autre, etc. Dans le cas où la fenêtre courante (les objets de contrôle sonteux-mêmes des fenêtres) contient un graphique (icône, bouton graphique, etc.) plutôt que dutexte, un signal sonore avertira l'utilisateur de la présence d'un graphique, sans autreindication.

Figure 69. Accès à une boîte de dialogue.

Il nous parait important de passer du concept de lecture d'écran au concept d'adaptationde l'interaction. En effet, l'interface ne peut être réduite à sa forme la plus superficielle, c'est àdire au contenu de l'écran à un instant donné. Par ailleurs, les entrées constituent un aspectessentiel de l'interface. Essayer d'adapter les sorties sans tenir compte des entrées est uneerreur. De même qu'il est illusoire d'adapter les entrées sans tenir compte des sorties. Lessorties de la machine sont dans la plupart des cas dépendantes des entrées de l'utilisateur et lesentrées de celui-ci sont liées aux sorties de la machine. Cet échange permanent, dynamiqueentre la machine et l'utilisateur constitue l'essence de l'interaction. C'est pourquoi, c'estl'interaction dans sa globalité qui doit être repensée et adaptée. Il devient alors nécessaire dedisposer d'outils qui permettent de configurer l'interaction même. Aujourd'hui, de plus en plusd'applications permettent à l'utilisateur de configurer l'interface en fonction de ses désirs.Cependant le champ de cette configuration reste très limité (choix des couleurs, choix despolices, pour certaines, personnalisation des menus et des barres d'outils etc.). Dans la plupartdes cas cette personnalisation de l'interface est restreinte à quelques aspects de sortie. Très peud'applications permettent de modifier les entrées. Il est nécessaire que cette personnalisationpuisse être étendue non seulement au niveau des sorties (possibilités de changer de modalité etmême de mode) mais également aux entrées. Il serait encore préférable que cettepersonnalisation puisse agir sur les interactions elles-mêmes, c'est à dire que l'utilisateur


181

puisse modifier ou définir des séquences d'entrées et de sorties. Il serait très intéressant depouvoir disposer d'outils qui permettent à un simple utilisateur de réaliser une tellepersonnalisation. de manière simple et rapide. Cependant pour atteindre un tel objectif, il estnécessaire que les systèmes graphiques soient repensés, qu'ils soient plus ouverts et qu'ilsoffrent plus d'accès aux informations manipulées. Il est également nécessaire que lesinteractions propres à une application donnée soit représentées explicitement de manière plusou moins déclarative afin que leur modification soit rendue possible et aisée.

4.4. DESCRIPTION DE MEDITOR

4.4.1. IntroductionL'accès aux documents est l'une des tâches les plus courantes que nous effectuons

quotidiennement. Toutefois, cet accès n'est pas toujours une opération passive au cours delaquelle nous pourrions nous contenter de recevoir des informations sans pouvoir y effectueraucune modification. La lecture suppose de pouvoir naviguer dans le document, de pouvoir ymarquer des passages, souligner des termes, en colorier d'autres, porter des annotations, etc.Cela est particulièrement vrai dans l'éducation et la formation où il est souvent demandé àl'élève d'adopter une attitude active face au document traité. MEDITOR a été conçu à l'originepour fournir aux utilisateurs non-voyants un outil convivial et d'utilisation simple pour laconsultation et la modification de documents textuels. En outre, l'accès à des documentsinformatiques ouvre pour les non-voyants une porte vers un colossal volume deconnaissances. Ainsi, le nouveau support d'information que constitue le CD-ROM permet destocker sur un espace de quelques centimètres cubes (disque de 12 cm de diamètre et 3 mmd'épaisseur) plus de 600 méga-octets de caractères, ce qui équivaut à des millions de pagesbraille qui nécessiteraient une étagère d'un kilomètre de longueur pour les stocker[Burger 92b].

Par la suite, de nouvelles fonctionnalités ont été intégrées à MEDITOR afin qu'il puisseservir de support informatique interactif pour les élèves non-voyants dans leurs classesd'enseignement du Français. Ces nouvelles fonctionnalités ont été définies en étroitecollaboration avec un professeur de Français de l'INJA.

La nature même des documents en braille papier impose de nombreuses contraintes auxélèves. Celles-ci peuvent être levées facilement grâce à l'outil informatique. Par exemple,l'impossibilité de modifier de tels documents constitue un inconvénient majeur dansl'enseignement où il est souvent demandé aux élèves de marquer des mots particuliers (enfonction de leur catégorie grammaticale par exemple), de conjuguer des verbes, d'accorder des


182

adjectifs etc. Ceci ne pouvant se faire directement sur le document braille, ils se trouvent alorscontraints de procéder par recopie en utilisant la machine Perkins41 (fig. 70), alors qu'un élèvevoyant pourrait agir directement sur le document en utilisant un marqueur, en remplissant destrous, etc. Cette manière de procéder par recopie implique une manipulation lourde et des va-et-vient incessants entre le document et la machine Perkins.

Figure 70. Ecriture en braille avec la machine Perkins.

Par ailleurs, les textes étudiés par les élèves comportent très souvent des notesexplicatives. Dans un manuel en noir42, ces notes se trouvent sur la marge ou en bas de page,et de ce fait leur consultation est quasi-immédiate pour une personne voyante. En braille, lesnotes sont souvent situées à la fin du texte (le texte en braille pouvant s'étaler sur plusieurspages) ou du volume. Leur consultation est de ce fait rendue difficile puisqu'il devientnécessaire avant de consulter une note de bien mémoriser la position où on se trouve, tournerles pages, rechercher la note, tourner les pages de nouveau et se repositionner dans le texteprincipal. Une telle manipulation est évidemment lourde et casse le fil de la lecture.

Enfin, l'insertion d'annotations personnelles sur un document braille est impossible, vuque le document ne peut être modifié.

41Machine à écrire en braille utilisée par les non-voyants.42C'est ainsi qu'est désigné un document écrit sur papier normal.


183

Les fonctionnalités intégrées dans MEDITOR ont permis de résoudre ces problèmes.Après avoir décrit la configuration matérielle, et la structure des documents utilisés dansMEDITOR, nous décrirons certaines de ces fonctionnalités en les illustrant par des exemplesd'interaction multimodales.

4.4.2. Configuration matérielleMEDITOR a été développé sur un ordinateur de type PC. Les PC constituent le type de

poste de travail le plus répandu parmi les utilisateurs non-voyants. Ceci s'explique par le faitque c'est pour ce type de machine qu'a été développée la majorité des périphériques et deslogiciels pour non-voyants. MEDITOR intègre plusieurs périphériques d'entrée/sortie(fig. 71) :

Figure 71. Configuration matérielle de MEDITOR

• un terminal braille de type BrailleWindowTM43 ou ClioBrailleTM44,• un système de synthèse de parole Synthé3TM45 ou PsolaTM46,• un système de reconnaissance vocale Datavox,• un clavier classique,• un écran et une souris (pour une simulation visuelle).

43BrailleWindow est une marque déposée par la société EHG (Allemagne).44ClioBraille est une marque déposée par la société EuroBraille (France).45Synthé3 est une marque déposée par Electrel (France).46Psola est une marque déposée par Elan-Informatique (France).


184

Le terminal BrailleWindow comprend une ligne de 40 cellules. A chaque cellule estassocié un bouton permettant à l'utilisateur d'effectuer des opérations de désignations. Destouches de fonctions et un clavier numérique sont également disponibles. Ce terminalcomprend quatre cellules supplémentaires sur le coté gauche. Elles sont généralement utiliséespour afficher certaines informations telles que le numéro de la ligne courante.

Le terminal ClioBraille (fig. 72) dispose quant à lui d'une ligne de 20 caractères et d'unvéritable clavier braille. Il intègre également des boutons de désignation, des touches defonctions et un clavier numérique. Il bénéficie d'une meilleure ergonomie.

Figure 72. Le terminal ClioBraille

Les systèmes Synthé3 et Psola permettent de réaliser de la synthèse de parole française àpartir du texte. Les deux systèmes autorisent un réglage de certains paramètres tels que levolume, la hauteur et la vitesse, ainsi que des opérations telles que la suspension et la reprisede la synthèse.

L'affichage tactile est utilisé exclusivement pour la présentation du document (texte,questions, notes...). La synthèse de parole est utilisée, quant à elle, pour communiquer àl'utilisateur des informations sur le bon ou le mauvais déroulement des opérations, ainsi quedes informations relatives au texte édité (attributs, présence de notes, etc.).

L'écran est utilisé pour produire une simulation visuelle de l'afficheur braille et la sourispour simuler l'appui sur les boutons du terminal.


185

4.4.3. La simulation visuelleL'interface visuelle de MEDITOR n'a pas fait l'objet de soins particuliers. Cette partie

visuelle a été développée essentiellement pour deux raisons :

1. Elle nous a permis de réaliser des simulations et ainsi d'avancer dans la mise enoeuvre de MEDITOR sans avoir eu besoin de disposer d'un véritable terminal braille. En effet,les prix des terminaux braille demeurent chers (plusieurs dizaines de milliers de FF) etl'acquisition par le laboratoire de ce matériel n'était pas nécessaire. Nous avons fait lesdéveloppements et les tests à travers ce simulateur. Leur transposition sur les véritablesterminaux braille disponibles à l'INJA n'a posé aucun problème, étant donné l'implémentationorientée objet de SPECIMEN. Nous avons pris soin de définir la même interface pour lesclasses correspondant au simulateur braille et au véritable terminal braille (mêmes donnéespubliques et même méthodes publiques). La transposition a été de ce fait immédiate.

2. Elle permet à une personne voyante de suivre et de contrôler les opérations effectuéespar l'utilisateur non-voyant (par exemple, le professeur voyant qui surveille le travail de sesélèves).

L'écran de MEDITOR (fig. 73) comprend 4 parties :

4.4.3.1. Le simulateur brailleIl affiche une ligne de 20 ou 40 caractères braille (en fonction de la taille de la ligne du

véritable terminal braille). Les caractères dont le point 8 est relevé apparaissent dans unecouleur différente.

4.4.3.2. Le simulateur en noirLe terme "noir" (opposé à braille) est utilisé par les non-voyants pour faire référence aux

caractères ou au textes utilisés par les personnes voyantes. Ce simulateur affiche donc latraduction de la ligne braille pour les utilisateurs voyants. Les caractères sont affichés avecleurs styles (gras, italique, souligné...), leurs couleurs, leurs polices, etc.

Les deux simulateurs (braille et en noir) disposent de boutons situés au dessus descellules braille. En cliquant dessus avec la souris, on simule des clics sur les boutons duvéritable terminal braille.


186

Simulateur braille

Simulateur en noir

Boutons de navigation

Barre d'état

Figure 73. Ecran de MEDITOR

4.4.3.3. La barre d'état et les boutons de navigationLa barre d'état affiche le numéro de la ligne courante, celui de la page courante, et les

mots reconnus par le système. Les boutons de navigation permettent grâce à l'utilisation de lasouris de naviguer dans le texte (ligne suivante et précédente, page suivante et précédente,début et fin du texte).

4.4.4. Structure des documents utilisés dans MEDITORLa structure des documents utilisés dans MEDITOR (fig. 74) est directement inspirée de

la structure des manuels scolaires utilisés par les élèves. Ces manuels comprennent en généralun texte court (1 ou 2 pages), des questions qui peuvent être relatives au texte ouindépendantes du texte (un exercice de grammaire par exemple), parfois une zone vierge danslaquelle l'élève peut répondre aux questions et éventuellement la correction des exercices. Desnotes peuvent être rattachées à des mots du texte principal ou à des mots appartenant auxautres parties du document.


187

Enoncé

Corrigé

Texte principal

Questions

1.......2.......3.......

1.......2.......3.......

1.......2.......3.......

Note

NoteNote

Support

Figure 74. Structure des documents utilisés dans MEDITOR.

Des liens d'accès directs ont été définis entre les trois zones "Questions", "Support" et"Corrigé". Par exemple, si l'élève est en train de lire la 5ème question, et qu'il désire yrépondre, il pourra alors le faire en prononçant le mot "support". Le système le positionneradirectement dans la zone du support réservée à cette question. De même s'il veut consulter lecorrigé, il prononcera le mot "corrigé" et le système le positionnera alors directement sur laréponse correspondant à cette question. L'élève peut ainsi naviguer entre les différentes zonesdu document de manière simple, rapide et efficace. Il est par ailleurs, possible de protéger enécriture certaines parties du document (énoncé, notes...) et en lecture d'autres (correctioncachée par exemple).

4.4.5. Description de quelques fonctionnalitésNous présentons ci-dessous quelques fonctionnalités de MEDITOR en insistant plus

particulièrement sur les interactions mises en jeu. On pourra alors constater que cesinteractions sont très proches des interactions propres aux interfaces à manipulation directe.En effet, l'utilisateur à toujours l'impression d'agir directement sur les objets de l'interface, etperçoit immédiatement, par un feed-back tactile et/ou sonore, les modifications que subissentces objets. La majorité des commandes reposent sur le même principe : sélection d'une entitépuis application d'une commande à cette entité. Si une commande est exécutée sans sélectionpréalable elle est appliquée par défaut au mot si elle est accompagnée d'une désignation, sinonelle est appliquée à la sélection précédente.


188

4.4.5.1. Prise de connaissance du documentLa lecture du texte s'effectue principalement de manière séquentielle. L'utilisateur lit en

braille à l'aide de ses doigts et peut énoncer en même temps des commandes de navigation demanière vocale. Ainsi, les phrases "page suivante", "page précédente", "début du texte", "findu texte" sont fréquemment utilisées. Pour les passages à la ligne suivante ou à la ligneprécédente, les utilisateurs préfèrent en général utiliser les équivalents du clavier braille. Ceséquivalents braille ont été mis en oeuvre dans MEDITOR pour respecter les habitudes detravail des utilisateurs. Remarquons toutefois que pour l'un des terminaux braille utilisés,l'utilisation des équivalents braille permettant de passer à la ligne suivante ou à la ligneprécédente impose à l'utilisateur de quitter la plage tactile, vu que les touches correspondantessont assez éloignées de cette dernière et qu'il est donc impossible de les actionner avec lespouces tout en gardant les index sur la plage tactile (ce qui est habituellement possible sur lesautres terminaux braille).

Le passage d'une section du document à une autre (support, corrigé, questions, etc.) sefait en prononçant simplement le nom de la section désirée.

4.4.5.2. Prise de connaissance des attributsLes logiciels de relecture de documents offrent généralement deux modes de lecture.

Dans le premier mode, l'utilisateur perçoit le texte dénué de tous ses attributs, et dans lesecond il perçoit les attributs mais sans percevoir le texte. Cette méthode est contraire auxprincipes de conception des interfaces qui déconseillent en général ce type d'usage des modes[Foley 90]. Il est important compte tenu de la nature fonctionnelle des attributs (en particulierpour les notes) de permettre à l'utilisateur de détecter la présence des attributs tout en lisant.Cependant cet enrichissement doit perturber le moins possible les habitudes de lecture enbraille qui sont assez rigides.

La solution adoptée permet d'éviter l'utilisation des modes (texte, attributs). De plus, ladistribution des informations à travers deux modes différents (tactile pour le texte proprementdit et sonore pour les informations supplémentaires) permet de ne pas casser le fil de lalecture.

Cette solution comporte trois niveaux :


189

4.4.5.2.1. Premier niveau : utilisation d'un bip sonoreLorsqu'une ligne comporte des attributs particuliers ou bien des mots auxquels sont

rattachées des notes, son affichage est toujours accompagné d'un bip sonore. Ceci permetd'alerter l'utilisateur non-voyant sur la présence d'informations supplémentaires dans la ligneet l'amène à être plus attentif dans sa lecture, car ce bip sonore ne lui indique pas lalocalisation de ces informations supplémentaires.

4.4.5.2.2. Second niveau : utilisation du point 8Pour indiquer de manière plus précise la localisation de ces informations

supplémentaires, nous utilisons le point 8 des cellules braille. Ainsi, lorsqu'un caractère est parexemple, en italique, le point 8 de ce caractère est alors relevé. Si l'attribut en questionconcerne tout le mot, seuls les deux premiers caractères du mot ont leur point 8 relevé. Il enest de même pour la ligne, la phrase et le paragraphe. Le choix de ne relever que les deuxpremiers caractères de l'entité affectée découle des expérimentations qui ont été menéesauprès des utilisateurs. En effet, en n'affectant que le premier caractère de l'entité, nous avionsremarqué que la détection du point 8 était assez difficile pour les utilisateurs ce qui lesamenait à "manquer" certaines informations qui parfois peuvent être importantes. D'un autrecôté, en relevant le point 8 de tous les caractères affectés, nous avons constaté qu'une gêneimportante était occasionnée lors de la lecture, car les utilisateurs ont l'habitude de lire dubraille à 6 points. Finalement, relever uniquement les points 8 des deux premiers caractèress'est révélé être un bon compromis. Toutefois, ceci n'indique toujours pas à l'utilisateur demanière précise la localisation de l'information (puisqu'il ne sait pas à quelle entité elle estrattachée) et de plus, il ne sait toujours pas de quelle information il s'agit. Ces deux élémentssont communiqués à travers le troisième niveau.

4.4.5.2.3. Troisième niveau : utilisation de la synthèse de paroleContrairement aux deux niveaux précédents qui n'exigent aucune initiative de la part de

l'utilisateur, ce troisième niveau n'est communiqué à l'utilisateur que s'il le demandeexplicitement et cela en cliquant sur un des boutons situés au dessus des cellules braille.L'information complète lui est alors communiquée à travers la synthèse de parole. Le messagesynthétisé véhicule le nom de l'attribut ainsi que le type d'entité auquel il s'applique. S'il s'agitd'une note, le message indique l'existence d'une note et le type d'entité à laquelle elle estrattachée.

La fig. 75 illustre l'exemple du mot "bonjour" qui est souligné dans le texte. Les deuxpremiers caractères du mot ont leur point huit relevés. Si l'utilisateur clique sur un boutonsitué au dessus de n'importe quel caractère du mot, le message "mot souligné" est alorssynthétisé.


190

Point 8Indicateur d'attributs

Bonjour

"mot souligné"

2ème Niveau

bip sonore au moment de l'affichage

Cellules marquées

1er Niveau

3ème Niveau

(Synthèse de parole)

Figure 75. Prise de connaissance des attributs.

Si l'utilisateur désigne un caractère auquel ne correspond aucune informationsupplémentaire, le message synthétisé indique simplement à l'utilisateur qu'aucuneinformation particulière n'est présente.

4.4.5.3. Modification des attributsNous avons déjà vu que la modification des attributs des mots (soulignement, mise en

gras, modification de la couleur, etc.) était une exigence fréquente et importante dans lapratique pédagogique. Alors que ces opérations sont irréalisables sur des documents braille enpapier, elle deviennent possibles en utilisant un support informatique et simples à effectuergrâce à l'exploitation de la multimodalité. Par exemple, pour souligner un mot, l'utilisateuraura simplement à prononcer le mot "souligné" tout en désignant (c'est à dire en cliquant surun bouton du terminal braille) un caractère quelconque du mot en question. Un message vocal"mot souligné" est alors synthétisé et les points 8 des deux premiers caractères du mot sontrelevés. Ce feed-back immédiat permet d'informer l'utilisateur sur le bon déroulement del'opération.


191

4.4.5.4. Accès aux notesLa présence d'une note est signalée de la même manière que la présence d'attributs

particuliers sauf que le message synthétisé sera "<type de l'entité> avec note" ou <type del'entité> désigne l'étendue du texte auquel est rattachée la note (caractère, mot, ligne, phrase,etc.). Lorsque le lecteur a reconnu la présence d'une note, il peut en prendre connaissance dedeux manières différentes : tactile ou sonore.

4.4.5.4.1. Accès tactileDans ce cas, l'utilisateur prononce la phrase "afficher note" tout en désignant un

caractère de l'entité à laquelle est rattachée la note. Celle-ci est alors affichée sur le terminalbraille et le message "note affichée" est émis à travers la synthèse de parole. L'utilisateur peutalors lire la note de la même manière qu'il lit le texte principal et utiliser toutes les opérationsd'édition applicables à un texte normal. Lorsque la lecture est terminée, il lui suffit deprononcer le mot "retour" pour revenir dans le texte principal directement à la position où ilse trouvait juste avant l'accès à la note.

4.4.5.4.2. Accès auditifSi l'utilisateur désire écouter la note plutôt que de la lire, il lui suffit de prononcer la

phrase "lire note" tout en désignant un caractère de l'entité à laquelle est rattachée la note. Letexte de la note est alors communiqué par la synthèse de parole.

Par comparaison aux méthodes de lecture traditionnelles, on peut noter que l'accès auxnotes est immédiat et ne casse pas le fil de la lecture. Dans le cas de l'accès tactile, au retour,l'utilisateur retrouve directement la ligne qu'il était en train de lire. Dans le cas de l'accèsauditif, il n'est même plus nécessaire de quitter cette ligne.

4.4.5.5. Annotation personnelleL'attachement d'une note à un mot s'effectue en désignant un caractère du mot et en

prononçant la phrase "insérer note". L'utilisateur est alors invité à saisir sa note soit à traversle clavier braille, soit en utilisant le clavier standard. Une fois que l'utilisateur a terminé desaisir sa note il peut revenir au texte initial en prononçant le mot "retour".

La note peut aussi être attachée à n'importe quelle partie du texte autre que le mot(caractère, ligne, phrase, paragraphe, etc.). Pour cela l'utilisateur doit d'abord sélectionner lapartie de texte désirée puis prononcer la commande "insérer note".


192

4.4.5.6. SélectionUn des problèmes rencontrés dans les interfaces concernent la granularité de la

sélection. Par exemple, dans une tâche de modélisation 3D, il peut exister différents niveauxpour la sélection : le point, la courbe, la surface et le volume. Dans un éditeur de textes,l'utilisateur peut vouloir sélectionner un caractère, un mot, une ligne, une phrase, unparagraphe, une page, etc. Deux solutions sont utilisées dans les interfaces actuelles. Lapremière consiste à faire usage de modes (au sens de [Thimbleby 90], changement decontexte). La même opération de désignation est utilisée pour tous les niveaux mais descommandes de changements de niveau de granularité sont prévues. L'interprétation del'opération de désignation est alors déterminée par le niveau courant. La seconde solutionutilise des opérations de désignation différentes (clic pour le caractère, double clic pour lemot, utilisation des modifieurs (shift, alt, ctrl) combinés au clic, etc.). La première solutionn'est pas efficace si on change de granularité fréquemment. La seconde peut poser desproblèmes si les niveaux de granularité sont nombreux.

Grâce à l'adjonction de la parole, il devient possible en utilisant la même opération dedésignation (ici, clic sur un bouton braille) d'effectuer différents types de sélections. Le niveaude granularité désiré est simplement indiqué à travers la parole, simultanément à l'opération depointage (fig. 76).

Type de sélection Action

Sélection d'un caractère Clic + "caractère"Sélection d'un mot Clic ou Clic + "mot"

Sélection d'une ligne Clic + "ligne"Sélection d'une phrase Clic + "phrase"

Sélection d'un paragraphe Clic + "paragraphe"Début d'une sélection arbitraire Clic + "début sélection"

Fin d'une sélection arbitraire Clic + "fin sélection"Sélection de tout le texte "Sélectionne tout"

Figure 76. Les différents types de sélection.

4.4.5.7. Modification du texteLe texte édité peut être modifié grâce à l'utilisation des commandes classiques "effacer",

"copier", "couper", "coller" etc. Ici l'utilisateur n'a besoin de mémoriser aucun raccourciclavier puisque les commandes s'énoncent vocalement accompagnées de désignationspermettant d'identifier l'entité sur laquelle elles opèrent.


193

Par exemple, pour effacer une partie quelconque du texte, l'utilisateur doit d'abordsélectionner cette partie puis dire "effacer". Le début de la sélection est indiqué en prononçantla phrase "début sélection" et en désignant en même temps le premier caractère appartenant àla partie désirée. De même la fin de la sélection est indiquée en prononçant la phrase "finsélection" et en désignant le dernier caractère. La fig. 77 illustre cet exemple.

Clic (sur le premier caractère)

"début sélection"

Médias

Temps

Système dereconnaissance de parole

Terminal Braille Clic (sur le dernier caractère)

"fin sélection" "effacer"

Système desynthèse de parole

"début sélection" "fin sélection" "sélection effacée"

Figure 77. Effacement d'une partie du texte.

4.4.5.8. EvaluationLes exemples d'interaction décrits ci-dessus ont permis de constater que la

multimodalité pouvait augmenter considérablement l'efficacité, la convivialité, la facilitéd'apprentissage et d'utilisation d'une interface non visuelle. Toutefois seule une évaluationergonomique rigoureuse peut en faire la preuve. Une première et courte évaluation a déjà étéréalisée. Nous présentons brièvement ses résultats dans le §. 4.5. Une évaluation plusimportante est actuellement menée à l'INJA par une équipe de l'INSERM.

4.4.6. Exemple comparatifLa multimodalité permet d'exploiter au maximum les capacités de communication de

l'être humain. Dans le cas d'utilisateurs non-voyants, l'utilisation conjointe des modes tactile,gestuel, oral et auditif aide à compenser la déficience du mode visuel, et à définir des formesd'interaction non visuelle optimales. La fig. 78 présente un exemple comparatif entreMEDITOR et Microsoft WORD. Il s'agit de souligner un mot et de lui affecter la couleur


194

rouge. Dans le cas de WORD, les systèmes actuels d'accès aux interfaces graphiquescontraignent l'utilisateur non-voyant à utiliser les raccourcis claviers. Outre la nécessité demémoriser ces raccourcis claviers, il doit réaliser 9 actions élémentaires pour atteindre sonobjectif. Sous MEDITOR, l'utilisation de la parole diminue l'effort de mémorisation étantdonné que le choix des mots du vocabulaire n'est pas arbitraire mais correspond au sens de lacommande à réaliser. De plus le nombre d'actions élémentaires à exécuter estconsidérablement réduit. Enfin la simultanéité du geste de désignation et de la commandevocale, donne à l'utilisateur l'impression d'agir directement sur les objets qu'il perçoit. Ceci esttrès proche de la manipulation directe. L'utilisateur non-voyant peut vérifier immédiatement lebon déroulement de la commande. Le feed-back est immédiat et multimodal. Les points 8 desdeux premiers caractères du mot sont levés tandis que le message "mot rouge souligné" estsynthétisé vocalement.

MEDITOR WINWORDDire "rouge souligné" tout en désignant uncaractère du mot

Amener le curseur sur le mot

Appuyer la touche F8Appuyer une deuxième fois sur la toucheF8Appuyez sur les touches CTRL+SAppuyez sur les touches ALT+TAppuyez sur la touche CAppuyez sur les touches ALT+LAppuyer sur les touches fléchées (vers lehaut ou vers le bas)Appuyez sur Return

Figure 78. Exemple comparatif pour souligner un mot et le mettre en rouge.

4.4.7. Utilisation des modalitésLa multimodalité supportée par MEDITOR est du type synergique. C'est le type de

multimodalité qu'offre les interfaces développées avec SPECIMEN. Il existe dans MEDITORune certaine spécialisation des modes en fonction du type des informations véhiculées. Parexemple, tous les messages informant l'utilisateur sur le bon ou le mauvais déroulement desopérations sont communiqués à travers le mode sonore. Les éléments du texte sont toujourscommuniqués à travers le mode tactile sauf si l'utilisateur demande explicitement leur lecture


195

à travers le mode sonore. Cette spécialisation a pour avantage de ne pas perturber l'utilisateurdans la lecture. Les informations concernant les attributs du texte sont partagées entre les deuxmodes (cf. §. 4.4.5.2).

4.4.8. Problème des attributsLa méthode utilisée dans MEDITOR pour informer l'utilisateur sur les attributs du texte

n'est pas la méthode idéale bien qu'elle soit meilleure par rapport à la méthode utilisée dans leslogiciels classiques de relecture d'écran. Cette méthode, si elle permet d'éviter l'utilisation desmodes, ne permet pas néanmoins une perception totale et immédiate des attributs. Dans unpremier temps, l'utilisateur est simplement informé de la présence et de la localisation desattributs, mais il n'a aucune information précise sur ces attributs (s'agit-il de couleurs, destyles, de notes... ?). Dans un second temps, il peut, comme nous l'avons vu, demander desinformations plus précises sur ces attributs.

Une autre méthode (peut-être meilleure ?) consisterait à utiliser un dispositif(magnétique ou optique ou même tactile) de détection de position du doigt lecteur. Desmessages vocaux indiquant les attributs particuliers pourraient être automatiquementsynthétisés lorsque le doigt de l'utilisateur non-voyant passe sur une entité dotée de telsattributs. Cependant, il faut bien sûr veiller à offrir à l'utilisateur la possibilité de désactiverces messages s'il le désire. Il est toutefois assez difficile de se prononcer sur l'efficacité decette méthode, sans l'avoir expérimenté, car on peut facilement remarquer que les non-voyantsutilisent plus d'un doigt (et en général les deux mains) dans le processus de lecture.

4.5. PREMIERE EVALUATIONMEDITOR est actuellement en cours d'évaluation à l'INJA. Cette évaluation, menée par

une équipe de l'INSERM, s'étale sur toute l'année scolaire 1994/1995. Par conséquent, lesrésultats de cette importante évaluation ne sont pas encore disponibles. Dans ce paragraphesont repris brièvement les résultats issus d'une première et courte évaluation ergonomiqueréalisée par N. PICAN de l'INSERM [Bellik 94b].

4.5.1. Description de l'expérimentationCette évaluation a fait intervenir trois sujets non-voyants. Elle s'est déroulée sous formes

de trois sessions par sujet. La première session d'une durée de 90 minutes (dont 20 à 30 mnétaient consacrées à la phase d'apprentissage du système de reconnaissance de parole)consistait en une première familiarisation. Les sujets étaient invités à réaliser un exercice defrançais. Les principes généraux du fonctionnement de MEDITOR leur ont été expliqués et ilspouvaient poser des questions à tout moment. La deuxième séance (30 mn) consistait en un


196

entraînement autonome. Les sujets devaient réaliser un exercice en posant le moins dequestions possible sur le fonctionnement de MEDITOR. Enfin la dernière séance (30 mn),correspondait à une situation réelle de travail. Les sujets devaient travailler seul en ayant pourunique aide un manuel en braille résumant les principales commandes de MEDITOR. Lesexercices proposés aux sujets ont été construits à partir d'un modèle fourni par un enseignantde français à l'INJA. Ils comportaient quatre types de tâches :

• Lecture d'un texte.• Lecture des notes associées au texte.• Modification des attributs du texte (ex.: souligner les adjectifs).• Modification du texte (ex.: conjuguer des verbes)

4.5.2. Résultats de l'expérimentationL'apprentissage de l'utilisation de MEDITOR a été rapide. Les explications fournies aux

sujets lors de la première séance ont été suffisantes, et l'utilisation du manuel a été très peufréquente. La mémorisation des commandes a été facile pour les sujets, sans doute due àl'utilisation de mots significatifs (effacer, souligner, etc., plus faciles à mémoriser que desraccourcis clavier (ALT-S, CTRL-D, etc.) et à l'utilisation de principes d'interactions simples,peu nombreux et communs à la majorité des commandes. La multimodalité a été acceptéesans problèmes. La répartition des informations sur différentes modalités n'a pas gêné lessujets, bien qu'ils soient habitués à utiliser soit le terminal braille seul, soit la synthèse deparole seule. Ainsi, la combinaison d'informations auditives et tactiles pour la perception desattributs n'a pas perturbé la lecture du texte. La manière dont est utilisé le point 8 dansMEDITOR n'a nullement perturbé les sujets qui sont habitués à lire du braille à 6 points. Ilsn'ont pas rencontré de difficultés par rapport à l'utilisation des couleurs (ce qui n'était pasévident au départ). En fait les couleurs sont simplement considérées comme des attributsparticuliers. Bien qu'aucune comparaison quantitative n'ait été faite, le temps nécessaire à laréalisation des tâches demandées semble court par rapport au temps nécessaire à la réalisationdes mêmes tâches avec les méthodes classiques. Cependant cette première évaluation n'a pasrévélé que des points positifs. Un certain nombre de problèmes ont été rencontrés par le sujet.Les principaux d'entre-eux concerne le système de reconnaissance de parole. Sesperformances moyennes constituent le problème qui a le plus gêné les sujets. Elles ont étéglobalement moins bonnes que lors de l'évaluation de LIMSI-Draw. Ceci peut s'expliquer pardeux raisons:


197

1. le vocabulaire utilisé dans MEDITOR est plus important,2. les conditions sonores dans lesquelles a été réalisée l'évaluation étaient moins

bonnes par rapport à celles de l'évaluation de LIMSI-Draw.

On peut déplorer que le système utilisé ne dispose pas d'un algorithme d'apprentissageadaptatif. Une fois l'apprentissage effectué, il n'est plus possible de l'améliorer (à moins de lerecommencer). Par ailleurs, l'utilisation involontaire du système de reconnaissance a poséquelques problèmes. La machine n'étant pas capable de savoir si le sujet est en train des'adresser à elle ou à un autre interlocuteur, il a été prévu dans MEDITOR un moyen pouractiver et désactiver la reconnaissance. Bien que ce moyen soit simple à utiliser (appui desdeux touches "ligne suivante" et "ligne précédente" simultanément"), il a été constaté que lessujets omettaient souvent de désactiver le système quand ils voulaient s'adresser à uninterlocuteur voisin (ce qui avait parfois pour conséquence la reconnaissance impromptue decertaines commandes), ou de réactiver le système quand ils voulaient s'adresser à la machine.Il apparaît donc nécessaire de disposer d'un feed-back continu indiquant l'état du système dereconnaissance.

Il a également été constaté parfois une mauvaise coordination du geste de désignation etde la parole, allant jusqu'à l'omission du geste de désignation (le sujet prononce le nom de lacommande mais ne désigne pas l'entité à laquelle elle s'applique). Mais ce problème a surtoutété observé durant la première session ce qui laisse croire qu'il est dû à une mauvaiseassimilation du principe de certaines commandes.

Enfin, certains problèmes liés plus spécifiquement à l'interface (choix des mots duvocabulaire, feed-back insuffisant ou ambigu...) ont pu être révélés.

Cependant, il est possible de dire que les résultats de l'évaluation ont été globalementpositifs et encourageants. Les problèmes liés à l'interface pourront être facilement corrigés.Quant aux problèmes liés à la reconnaissance de parole, on peut espérer que l'on pourradisposer dans les quelques années qui viennent de systèmes (multilocuteurs) beaucoup plusperformants et capables de permettre aux utilisateurs de tirer plein parti des avantages de lamultimodalité.


198

4.6. CONCLUSIONDans ce chapitre, nous avons décrit une interface multimodale développée à l'aide de

SPECIMEN. L'objectif visé à travers cette réalisation était double. D'une part, il s'agissaitd'étudier l'apport de la multimodalité aux interfaces non visuelles; de ce point de vueMEDITOR a été une expérience très encourageante et a permis de montrer tout l'intérêt decette nouvelle approche pour la solution du problème de l'accès aux ordinateurs par desutilisateurs non-voyants. La même approche pourrait sans douter être appliquée avec succèspour les autres classes d'handicap notamment le handicap moteur. D'autre part, elle a permisde tester SPECIMEN sur le développement d'une application précise et concrète et de montrerque le modèle utilisé dans cet outil permet de disposer d'une fusion assez robuste même si ellene s'effectue pas à un haut niveau d'abstraction. Le gain de temps et la facilitéd'implémentation ont été appréciables. Le temps accordé au développement de l'interface deMEDITOR a été de l'ordre de 15% du temps total (85% pour le noyau fonctionnel). De plus,l'utilisation de SPECIMEN permet de rendre les problèmes spécifiques aux interfacesmultimodales (fusion, gestion temporelle, etc.) transparents pour le développeur.

Conclusion et perspectives

199


Dans cette thèse, nous avons présenté notre contribution aux recherches sur l'interactionmultimodale. Après une première expérience qui nous a permis de mettre en évidence certainsproblèmes importants propres aux interfaces multimodales, nous avons conçu et développé unmodèle pour la spécification des interactions multimodales. Ce modèle a donné lieu à un outild'aide au développement des interfaces multimodales que nous avons pu appliquer à laréalisation d'un prototype expérimental opérationnel.

Ces travaux constituent un premier pas vers une interaction Homme-Machine plusefficace et plus conviviale, et de nouvelles perspectives s'ouvrent à présent. Nous présentonsdans ce qui suit les principaux axes futurs vers lesquels nous pensons que les recherches surl'interaction multimodale doivent être orientées.

Communication Homme-Machine intelligenteLa multimodalité ouvre le champ à une communication intelligente entre l'homme et la

machine. En entrée (Homme vers Machine), la machine doit pouvoir être dotée deconnaissances et de capacités de raisonnement sur ces connaissances qui lui permettront d'unepart, de faciliter et de fiabiliser les entrées de l'utilisateur47 et d'autre part, de prendre enconsidération non seulement le contenu des informations reçues mais également la ou lesmodalités à travers lesquelles elles ont été transmises. Ceci permettra à la machine, parexemple, de déterminer les préférences de l'utilisateur et de s'adapter en fonction de cespréférences. La prise en compte de la modalité à travers laquelle une information a étéproduite permettra également de savoir quel degré de précision (voire de confiance) accorder àcette information, en fonction des caractéristiques propres à la modalité en question.

En sortie, la multimodalité a rajouté une nouvelle dimension à la problématique de lacommunication Homme-Machine. En effet, dans les interfaces actuelles, toutes les sorties dela machine vers l'utilisateur sont prédéterminées dans leurs modalités. Le problème qui se

47Par exemple, si une confirmation doit être demandée à l'utilisateur et si ses mains ne sont pas

disponibles à ce moment là, la machine pourrait demander une double confirmation vocale.


200

pose aujourd'hui est de doter la machine de capacités intelligentes qui lui permettront dechoisir de manière dynamique, non seulement le contenu d'une information à communiquer àl'utilisateur, mais également la meilleure modalité ou la meilleure combinaison de modalitéspour transmettre cette information, et ce en fonction du contexte courant. Ce problèmesoulève plusieurs questions : que signifie concrètement le terme "meilleure" (rapidité,fiabilité, concision, etc.) ? Quels sont les éléments qui constituent le contexte (caractéristiquesstatiques et dynamiques du système, de l'utilisateur, de l'environnement, du dialogue, de latâche, etc.) ? Comment représenter ces éléments et comment les exploiter ?

Tout ceci implique tout d'abord qu'une distinction claire soit établie au sein du systèmeinteractif, entre le contenu d'une information et sa forme de présentation (un contenu peut êtreprésenté sous différentes formes et une forme peut s'appliquer à différents contenus). Ilconvient donc d'établir une typologie des informations en fonction de ces deux critères etd'identifier des relations de correspondance entre eux. La réflexion doit être poursuivie dans lesens des travaux de Bernsen et des améliorations que nous avons proposées au chapitre 1.Ensuite, il sera nécessaire de définir concrètement de nouveaux modèles (relatifs àl'utilisateur, à la tâche, à l'environnement, etc.) aptes à intégrer les différentes connaissancesindispensables à l'établissement d'une telle communication (fig. 79) [Bellik 95c].

Interfacedu noyau

fonctionnel

Contrôleurd'

InteractionContrôleurde

Dialogue

UtilisateurNoyauFonctionnel

Modèledu

Dialogue

Modèlede la

Tâche Modèlede l'

Utilisateur

Modèlede l'

Environnement

Modèlede l'

Interaction

Figure 79. Modèle d'architecture d'un système de dialogue multimodal "intelligent"


201

Modèle physique ou modèle anthropomorphique ?Avant l'avènement de la manipulation directe, les interfaces Homme-Machine étaient

des interfaces à forte dominante langagière. La machine jouait alors le rôle d'un interlocuteur(modèle anthropomorphique) à qui l'utilisateur s'adressait pour lui demander d'exécutercertaines instructions. L'apparition des interfaces graphiques, reposant sur les principes de lamanipulation directe, a complètement bouleversé cette approche. La machine n'est plus vuecomme un interlocuteur, mais comme la représentation d'un monde physique virtuel contenantdes objets dotés de réactions spécifiques. L'utilisateur peut agir directement sur ces objets etobserver immédiatement l'effet de ses actions sur eux (modèle physique).

Si les interfaces à manipulation directe ont connu un grand succès, il ne faut cependantpas les considérer comme étant le modèle idéal de l'interaction Homme-Machine. Ainsi, cetype d'interfaces ne supportent pas de références descriptives car elles n'autorisent que ladésignation directe. En fait, nous pensons que selon le domaine d'application l'un des deuxmodèles d'interaction peut-être plus adéquat que l'autre. Ceci se retrouve d'ailleurs dans notrevie quotidienne. Par exemple, un patient souffrant d'une maladie préférera aller voir unmédecin avec lequel il pourra discuter, lui décrire les symptômes de sa maladie, poser desquestions, répondre aux questions posées par le médecin etc., plutôt que d'utiliser soi-mêmeun outil (livres de médecine et de pharmacologie par exemple) pour trouver le remède a sonmal. En revanche, un architecte désirant concevoir le plan d'un bâtiment, préférera disposerd'une planche à dessin, de crayons et de règles, plutôt que dicter des instructions à un sujetintermédiaire.

Enfin, il est fréquent que pour un même domaine d'application, le modèleanthropomorphique soit adapté à un certain champ de l'application et le modèle physique à unautre. Par exemple, l'aide en ligne qui est associée aux interfaces graphiques actuelles imposesouvent à l'utilisateur de parcourir toute une arborescence de mots-clefs avant de pouvoiraccéder à l'information désirée. Sur cet aspect, il est évident qu'une approcheanthropomorphique paraît mieux adaptée et ce quel que soit le domaine d'application.L'utilisateur devrait pouvoir simplement poser une question (comment puis-je faire ceci ?) etla machine devrait alors lui indiquer la réponse.

En d'autres termes, la coexistence de ces deux modèles au sein d'une même interfaceHomme-Machine peut améliorer grandement l'interaction. La multimodalité, en intégrantaussi bien des modalités langagières que des modalités actionnelles contribue à cet objectif.L'exemple classique de l'interaction multimodale (prononciation de la phrase "mets ça ici"accompagnée de deux gestes de désignation) illustre bien cet état de fait. L'utilisateur semble


202

s'adresser à un interlocuteur pour modifier un monde physique commun. La machine joue enfait les deux rôles : celui d'un interlocuteur et celui d'un monde physique virtuel. L'utilisateur adonc la possibilité de dialoguer avec un interlocuteur ou d'agir sur un monde physique ouenfin de demander à son interlocuteur d'agir sur ce monde physique.

Nous voyons à travers cet exemple que les deux modèles peuvent même coexister ausein d'une même commande et que l'interaction ne s'en trouve qu'améliorée. C'est pourquoi ilnous paraît important que la réflexion sur des modèles d'interaction combinant une interactionlangagière à une interaction physique soit poursuivie et que de nouveaux modèlesd'architecture aptes à supporter simultanément ces deux types d'interactions soient définis. Letravail que nous avons présenté au chapitre 3 constitue un premier pas vers cet objectif.

Nouveaux outils pour la construction des interfaces Homme-MachineNous avons vu dans ce même chapitre que les besoins en termes d'outils étaient très

importants dans le domaine des interfaces Homme-Machine. Malheureusement, la majoritédes outils actuels sont inutilisables pour la nouvelle génération des interfaces Homme-Machine (multimédia, multimodales, collecticiel, réalité augmentée, réalité virtuelle...). Parexemple, les outils permettant d'intégrer le facteur temporel dans les interfaces (exploitationriche du son, animation...) sont rares. De plus, cette nouvelle génération d'interfaces nécessiteencore plus d'efforts, aussi bien au niveau de la conception, que de l'implémentation et del'évaluation. C'est pourquoi de nouveaux outils réellement adaptés et permettant d'apporterune aide à ces trois niveaux doivent être construits.

Ces nouveaux outils seront par ailleurs, d'un apport considérable pour l'adaptation desinterfaces aux utilisateurs handicapés. MEDITOR, que nous avons présenté au chapitre 4, amontré que la multimodalité laissait entrevoir des perspectives prometteuses pour leshandicapés visuels. Il a également permis de montrer qu'une interface ne peut être réduite à saforme la plus superficielle, c'est-à-dire au contenu de l'écran à un instant donné. Essayerd'adapter les sorties sans tenir compte des entrées est une erreur. De même qu'il est illusoired'adapter les entrées sans tenir compte des sorties. Les sorties de la machine sont, dans laplupart des cas, dépendantes des entrées de l'utilisateur, et les entrées de celui-ci sont liées auxsorties de la machine. Cet échange permanent, dynamique entre la machine et l'utilisateurconstitue l'essence même de l'interaction; c'est pourquoi, c'est l'interaction dans sa globalitéqui doit être repensée et adaptée. Il devient alors nécessaire de disposer d'outils qui permettentde configurer l'interaction même. Aujourd'hui, de plus en plus d'applications permettent àl'utilisateur de configurer l'interface en fonction de ses désirs. Cependant, le champ de cette


203

configuration reste très limité (choix des couleurs, choix des polices, personnalisation desmenus et des barres d'outils etc.). Dans la plupart des cas cette personnalisation de l'interfaceest donc restreinte à quelques aspects de présentation. Très peu d'applications permettent demodifier les entrées. Il est nécessaire que cette personnalisation puisse être étendue nonseulement au niveau des sorties (possibilités de changer de modalité et même de mode) maiségalement aux entrées. Cette personnalisation devrait même pouvoir s'appliquer auxinteractions elles-mêmes, c'est-à-dire que l'utilisateur puisse modifier ou définir des séquencesd'entrées et/ou de sorties. Il serait très intéressant de pouvoir disposer d'outils qui permettentmême à un utilisateur non-informaticien de réaliser une telle personnalisation de manièresimple et rapide. Cependant, pour atteindre un tel objectif, il est nécessaire que les systèmesgraphiques soient repensés, qu'ils soient plus ouverts et qu'ils offrent plus d'accès auxinformations manipulées. Il est également nécessaire que les interactions propres à uneapplication donnée soit représentées explicitement de manière plus ou moins déclarative afinque leur modification soit rendue possible et aisée.

ConclusionAprès la révolution des interfaces graphiques, la communication Homme-Machine va

probablement vivre dans les prochaines années de nouvelles révolutions. La révolution dumultimédia est d'ores et déjà entamée. D'autres révolutions se profilent déjà. Lamultimodalité, le collecticiel, la réalité augmentée et la réalité virtuelle en font partie.

Dans cette thèse, nous avons présenté notre apport aux recherches actuelles dans ledomaine de l'interaction multimodale et nous venons de présenter quelques axes futurs qu'ilnous paraît importants de suivre. En réalisant deux prototypes opérationnels, nous avons puvalider jusqu'au bout les concepts théoriques élaborés. Ces réalisations nous ont permis deconfronter par l'expérimentation théorie et pratique. Les travaux menés jusqu'à présent et lesdifférents champs que nous avons eu l'occasion d'étudier nous ont permis d'acquérir lesconnaissances nécessaires et une vue plus large pour mener à bien la poursuite de ces travauxde recherche.

Références bibliographiques

204


[Adams 88]F.R. Adams, J. H. McTyre, "Screen Reader: An Audio Access System". Proc. ICAART,Montreal, Juin. 1988.

[Allen 83]J. F. Allen, "Maintaining Knowledge about Temporal Intervals.", Communications ofthe ACM, Vol. 26, Num. 11, Nov. 1983, pp. 832-843.

[Amibe 94]"Projet AMIBE", Rapport d'activité 1994, GDR n° 039, GDR-PRC "CommunicationHomme-Machine", CNRS, MESR, 1994, pp. 59-70.

[Anderson 85]C.D. Anderson, "Application of Speech Recognition and Touch-Screen Input Systemsto Airborne C3 Operations Results of Mission Simulator Evaluation.", Document No.10180-28809-1, The Boeing Co., Seattle. Wash., 1985.

[André 93]E. André, W. Finkler, W. Graf, T. Rist, A. Schauder, W. Wahlster, "WIP: TheAutomatic Synthesis of Multimodal Presentations", Working Material, WorkshopERCIM on Human-Computer Interaction, Nancy, 2-4 Nov. 1993.

[Anglade 94]Y. Anglade, J. C. Dubois, J. M. Pierrel, "Un poste de travail vocal pour une standardistemalvoyante". Actes du séminaire Interfaces multimodales pour handicapés visuels,nouvelles technologies, nouvelles solutions. Paris, 7 Nov. 1994.

[Arch 92]"A Metamodel for the Runtime Architecture of an Interactive System", SIGCHIBulletin, The UIMS Tool Developers Workshop, vol. 24, N° 1, jan 1992, pp. 32-37.

[Arnold 94]M. Arnold, "Dispositif physique / Média / Modalité. Contribution sémiotique à ladéfinition des trois termes.", IHM'94 Sixièmes Journées sur l'Ingénierie des InterfacesHomme-Machine, Lille, 8-9 Déc.1994.

[Azémard 95]F. Azémard, "Des références dans le dialogue Homme-Machine multimodal, uneapproche adaptée du formalisme des graphes conceptuels", Thèse de doctorat,Université Paul Sabatier, Toulouse, Fév. 1995.


205

[Balbo 93]S. Balbo, J. Coutaz, "Automatic Evaluation in Human Computer Interaction", TheErgonomics Society 1993 Annual Conference, Edinburgh, 13-16 Apr., 1993.

[Barnard 87]P. Barnard, "Cognitive Resources and the Learning of Computer Dialogs", InterfacingThought, Cognitive Aspects of Human Computer Interaction, J. M. Carroll Eds., MITPress Publ., 1987.

[Baudel 93]T. Baudel, M. Beaudouin-Lafon, "CHARADE: Remote Control of Objects using Free-Hand Gestures", Communications of the ACM, vol. 36, no. 7, pp.28-35, July, 1993

[Beaudouin-Lafon 91]M. Beaudouin-Lafon, "Interfaces Homme-Machine : vue d'ensemble et perspectives",Génie Logiciel & Systèmes experts, N° 24, Sept 1991, pp. 4-16.

[Bellik 91]Y. Bellik, "Interface de dialogue multimodal", Mémoire de DEA, LIMSI-CNRS, Sep.1991.

[Bellik 92a]Y. Bellik & D. Teil. "Multimodal Dialogue Interface", WWDU'92 Work With DisplayUnit, Berlin, 1-4 Sept 92.

[Bellik 92b]Y. Bellik & D. Teil. "Définitions terminologiques pour la communication multimodale",IHM'92, 4èmes Journées sur l'ingénierie des interfaces Homme-Machine, Paris, 30 Nov- 2 Déc 1992.

[Bellik 92c]Y. Bellik & D. Teil. "Les types de multimodalités", IHM'92, 4èmes Journées surl'ingénierie des interfaces Homme-Machine, Paris, 30 Nov - 2 Déc 1992.

[Bellik 92d]Y. Bellik, D. Teil, "Multimodal Interaction", Cassette vidéo K92-02, LIMSI-CNRS,Orsay, 1992.

[Bellik 93a]Y. Bellik & D. Teil. "A Multimodal Dialogue Controller for Multimodal User InterfaceManagement System, Application : a Multimodal Window Manager", INTERCHI'93,Amsterdam, 24-29 Apr 1993

[Bellik 93b]Y. Bellik & D. Teil. "Interaction multimodale : LIMSIDraw", Recueil des résumés, desdémonstrations, et des conférences, Forum des Recherches en Informatique, Ecolepolytechnique, 2-3 Juin 1993.


206

[Bellik 93c]Y. Bellik & D. Teil. "SPECIMEN: Un outil pour la spécification des interfacesmultimodales", IHM'93, 5èmes Journées sur l'ingénierie des interfaces Homme-Machine, Lyon, 19-20 Oct 1993.

[Bellik 93d]Y. Bellik, D. Teil, "Interaction multimodale : LIMSIDraw", Forum des Recherches enInformatique, Recueil des résumés, des démonstrations, et des conférences, Ecolepolytechnique, 2-3 Juin 1993.

[Bellik 94a]Y. Bellik, D. Burger, "Multimodal Interfaces: New Solutions to the Problem ofComputer Accessibility for the Blind". Proc. CHI'94, Boston, 24-28 Avr 1994.

[Bellik 94b]Y. Bellik, N. Pican, D. Burger, "MEDITOR, un prototype d'interface multimodale pourla manipulation de textes braille enrichis". Interfaces multimodales pour handicapésvisuels, Burger D. (Ed.), Numéro spécial de la revue "Comme les autres", Paris, pp. 47-59.

[Bellik 94c]Y. Bellik, D. Teil, "Proposition de terminologie à propos de la multimodalité",Interfaces multimodales pour handicapés visuels, Numéro spécial de la revue "Commeles autres", D. Burger (Eds.), Paris, Nov. 1994.

[Bellik 94d]Y. Bellik, S. Ferrari, F. Néel, D. Teil, "Communication Multimodale: ApprocheAscendante / Application au Domaine Spatial", Ecole SIC'94, Paris, 25-28 Avr 1994.

[Bellik 94e]Y. Bellik, S. Ferrari, F. Néel, D. Teil, V. Tachoires, "Communication Multimodale",Rapport final du contrat DRET n°92/358, LIMSI-CNRS, Juillet 1994.

[Bellik 94f]Y. Bellik, D. Burger, D. Teil, "Méditor, un prototype multimodal pour l'édition de textesbraille", Cassette vidéo N° K94-03, LIMSI-CNRS, Orsay, 1994.

[Bellik 95a]Y. Bellik, S. Ferrari, F. Néel, D. Teil, "Requirements for Multimoda Dialogue IncludingVocal Interaction", ESCA Workshop on Spoken Dialogue Systems, Vigso, Denmark, 30May-2 June 1995.

[Bellik 95b]Y. Bellik, D. Burger, "The Potential of Multimodal Interfaces for the Blind : anExploratory Study", RESNA'95, Vancouver, Canada, 9-14 June 1995.


207

[Bellik 95c]Y. Bellik, S. Ferrari, F. Néel, D. Teil, "Interaction Multimodale : Concepts etArchitecture", l'Interface des Mondes Réels et Virtuels, Montpellier, 26-30 Juin 1995.

[Bellik 95d]Y. Bellik, "Modality Integration: Speech and Gesture", à paraître dans Survey on HumanLanguage Technology, NSF/CEU, Chapter 8: Multimodality, 1995.

[Ben Amara 91]H. Ben Amara, B. Peroche, H. Chappel, M. D. Wilson, "Graphical Interaction in aMultimodal Interface" in Proc. of the Annual Esprit Conference, Esprit'91, Bruxelles,pp. 303-321.

[Berliss 93]J. Berliss, "Software Solutions to the Problem of GUI Inaccessibility to Blind Persons"in Non-Visual Human-Computer Interactions, D. Burger and J. C. Sperandio, eds.,Montrouge, France: John-Libbey Eurotext, 1993, pp. 131-143.

[Bernabei 94]A. Bernabei, A. D'Atri, G. Di Stefano, "A Multimodal Interface for a MedicalWorkstation", L'interface des mondes réels et virtuels Montpellier'94, Montpellier, Fév.1994, pp. 389-398.

[Bernsen 93]N. O. Bernsen, "Modality Theory: Supporting Multimodal Interface Design", WorkingMaterial, Workshop ERCIM on Human-Computer Interaction, Nancy, 2-4 Nov. 1993.

[Bernsen 94]N. O. Bernsen. "Modality Theory in Support of Multimodal Interface Design". Workingnotes, AAAI spring symposium series, Symposium : Intelligent Multi-Media Multi-Modal Systems, Stanford, 21-23 Mars. 1994.

[Berry 87]G. Berry, P. Couronné, G. Gonthier, "Programmation Synchrone des SystèmesRéactifs : le Langage ESTREL", Techniques et Sciences de l'Informatique, 6 (4), 1987,pp. 305-316.

[Berry 88]G. Berry, G. Gonthier, "The ESTREL Synchronous Programming Language : Design,Semantics, Implementation", Rapport de recherche INRIA, N° 842, 1988.

[Biermann 92]A. W. Biermann, L. Fineman, J. F. Heidlage, "A voice- and touch-driven naturellanguage editor and its performance", International Journal of Man-Machine Studies,37, 1992, pp. 1-21.


208

[Binot 92]J. L. Binot, L. Debille, D. Sedlock, B. Vandecapelle, H. Chappel, and M. D. Wilson,"Multimodal Integration in MMI2 : Anaphora Resolution & Mode Selection", Proc.Work With Display Units, WWDU'92, Berlin, Germany, 1-4 Sept. 1992.

[Blattner 89]M. Blattner, D. Sumiliava, E. GreenBerg, "Earcons and Icons: their structure andcommon design principles". Human-Computer Interaction, Vol. 4, pp 11-44, 1989.

[Blattner 90]M. M. Blattner, R. B. Dannenberg, CHI'90 Workshop on Multimedia and MultimodalInterface Design, SIGCHI Bulletin, Volume 22, N° 2, Oct. 1990, pp. 54-58.

[Bier 94]E. A. Bier, M. C. Stone, K. Fishkin, W. Buxton, T. Baudel, "A Taxonomy od See-Through Tools", Proc. CHI'94, Boston, 24-28 Apr., 1994.

[Bisson 92]P. Bisson, J. F. Nogier, "Interaction Homme-Machine Multimodale : le systèmeMELODIA", Actes Ergo'IA, Biarritz, 1992.

[Bolt 80]R. A. Bolt, "Put-That-There : Voice and Gesture at the Graphics Interface", ComputerGraphics, Vol. 14, N° 3, Aug. 1980, pp.262-270.

[Bolt 85]R. A. Bolt, "The Human Interface. Where People and Computers meet", LifetimeLearning Publications, 1985, pp. 44-51.

[Bolt 87a]R. A. Bolt, "Conversing with Computers", Readings in Human-Computer Interaction,Morgan Kaufmann publishers, 1987, pp. 694-702.

[Bolt 87b]R. A. Bolt, "The integrated multimodal interface", The Transactions of the Institute ofElectronics, Information and Communication Engineers, vol. J70-D, N° 11, Nov. 1987,pp. 2017-2025.

[Bolt 92]R. A. Bolt, E. Herranz, "Two-Handed Gesture in Multi-Modal Natural Dialogue",UIST'92, Montery, California, 15-18 Nov. 1992, pp. 7-14.

[Bos 93]E. Bos, "Easier said or done ?", Thèse de doctorat, Nijmegen Institute for Cognition andInformation, 1993.


209

[Bos 94]E. Bos, C. Huls, W. Claassen, "EDWARD : full integration of language and action in amultimodal user interface", International Journal of Human-Computer Studies, 40,1994, pp. 473-495.

[Bouraoui 94]A. Bouraoui, D. Burger, "Un éditeur d'images multimodales pour enfants handicapésvisuels". Actes du séminaire Interfaces multimodales pour handicapés visuels, nouvellestechnologies, nouvelles solutions. Paris, 7 Nov. 1994.

[Bourguet 91]M. L. Bourguet, R. Descout, J. Caelen, "Le Jeu Multimode : une Application deDialogue Homme-Machine Multimodal", IHM'91 Troisièmes Journées sur l'Ingénieriedes Interfaces Homme-Machine, Dourdan, 11-13 Déc.1991.

[Bourguet 92a]M. L. Bourguet, "ICPplan : dialogue multimodal pour la conception de plansarchitecturaux", 19ème JEP, Bruxelles, Mai 1992, pp. 369-374.

[Bourguet 92b]M. L. Bourguet, "Conception et réalisation d'une interface de dialogue personne-machine multimodale", Thèse de doctorat, ICP, INPG, Grenoble, 1992.

[Braffort 92]A. Braffort, T. Baudel, D. Teil, "Utilisation des gestes de la main pour l'interactionhomme-machine", IHM'92, 4èmes Journées sur l'ingénierie des interfaces Homme-Machine, Paris, 30 Nov - 2 Déc 1992.

[Briffault 93]X. Briffault, A. Braffort, "Toward a model of cooperation between natural language andnatural gestures to describe spatial knowledge", Actes de PacLing'93, Vancouver, 1993.

[Brooks 90]F. P. Brooks, M. Ouh-young, J. J. Batter, J. Kilpatrick, "Project GROPE : HapticDisplays for Scientific Visualisation", Computer Graphics, Vol. 24, n° 4, Aug. 1990.

[Burger 92a]D. Burger, "La Multimodalité: un Moyen d'Améliorer l'Accessibilité des SystèmesInformatiques pour les Personnes Handicapées. L'exemple des Interfaces Non Visuelles"Proc. ERGO.IA'92, Biarritz, France, 1992, pp. 262-290.

[Burger 92b]D. Burger, J. Suchard, P. Barker, J. C. Martin, "Methods for Improving ComputerAccess for the Visually Impaired" Proceedings of 14th Annual International Conferenceof IEEE-EMBS, 1992, pp. 1535-1537.


210

[Burger 93]D. Burger, C. Mazurier, S. Cesarano, J. Sagot, "The Design of interactive auditorylearning tools" in Non-Visual Human-Computer Interactions, D. Burger and J. C.Sperandio, eds., Montrouge, France: John-Libbey Eurotext, 1993, pp. 97-114.

[Burger 94]D. Burger, "Could Computer Tools for the Visually Handicapped be Someday asFriendly as those for Sighted People? " IEEE Transactions on RehabilitationEngineering, Jun. 94.

[Buxton 86]W. Buxton, B. A. Myers, "A Study in two-handed input", Proc. of CHI'86 HumanFactors in Computing Systems (Boston, MA, Apr. 1986), ACM Press, New York,1986, pp. 321-326.

[Buxton 93]B. Buxton, "HCI and the Inadequacies of Direct Manipulation Systems", SIGCHIBulletin, Vol. 25, N° 1, Jan 1993, pp. 21-22.

[Cadoz 93]C. Cadoz, "Le Geste Canal de Communication Homme-Machine". Communication etMultimodalité dans les Systèmes Naturels et Artificiels. 4ème Ecole d'Eté de l'ARC.1993, Chateau de Bonas, Gers, France.

[Cadoz 94a]C. Cadoz, "Le Retour d'Effort dans la Communication Gestuelle avec la Machine. LeConcept de Communication Instrumentale". L'interface des mondes réels et virtuels7-11 Fév. 1994, Montpellier, France.

[Cadoz 94b]C. Cadoz, "Le geste canal de communication Homme-Machine - La communicationinstrumentale". Techniques et Sciences Informatiques, Vol 13, n° 1, 1994, pp. 31-61.

[Caelen 91a]J. Caelen, "Interaction Multimodale dans ICP Draw : Expérience et Perspectives", ActesPRC CHM Interaction multimodale, Lyon, Avr. 1991.

[Caelen 91b]J. Caelen, "Multimodal Interaction : Event Management and Experiments with ICPDraw", Second Venaco Workshop on the Structure of Multimodal Dialogue, Italy, 16-20Sep. 1991.

[Caelen 91c]J. Caelen, Ph. Garcin, J. Wretö, E. Reynier, "Interaction Multimodale autour del'application ICP Draw", IHM'91 Troisièmes Journées sur l'Ingénierie des InterfacesHomme-Machine, Dourdan, 11-13 Déc. 1991.


211

[Caelen 91d]J. Caelen, J. Coutaz, "Interaction Homme-Machine Multimodale : ProblèmesGénéraux". IHM'91 (Déc. 1991), Dourdan.

[Caelen 93]J. Caelen, "Speech and Multimodal Interface : the Case of ICPdraw", ESCA Workshop,Lautrach, Sept 1993.

[Calbris 85]G. Calbris, "Espace-Temps : Expression Gestuelle du Temps", Semiotica, Vol. 55, n°1/2, pp.43-73, 1985.

[Card 83]S. K. Card, T. P. Moran, A. Newell, "The Psychology of Human-Computer Interaction",Lawrence Erlbaum Associates Publ., Hillsdale, .1983.

[Caubet 92]R. Caubet, V. Gaildrat, G. Pérennou, N. Vigouroux, "Interface multimodale pour unmodeleur déclaratif pour la synthèse d'images", Journées du PRC-IHMM, Dourdan,Mar. 1992.

[Chang 83]L. A. Chang, "Handbook for Spoken Mathematics" Technical Report, LawrenceLivermore Laboratory, 1983.

[Chatty 93]S. Chatty, "Interaction à Deux Souris : une Nouvelle Dimension à la Multimodalité ?",IHM'93 Cinquièmes Journées sur l'Ingénierie des Interfaces Homme-Machine, Lyon,19-20 Oct. 1993.

[Cherry 58]E. C. Cherry, "Some Experiments on the Recognition od Speech with One or Two Ears"in J. Acoustical Society of America, Vol. 22, 1958, pp. 61-6.

[Cohen 90]P. R. Cohen, M. Dalrymple, D. B. Moran, F. C. N. Pereira, J. W. Sullivan, R. A.Gargan Jr., J. L. Schlossberg, S. W. Tyler, "Synergistic use of direct manipulation andnatural language", Proc. CHI'89 Human Factors in Computing Systems (Austin, Texas,Apr. 1989), ACM Press, New York, 1990, pp. 155-160.

[Coutaz 87]J. Coutaz, "PAC, an Implementation Model for Dialog Design", Proc. of Interact'87,Stuttgart, Sept. 1987, 431-436.

[Coutaz 88]J. Coutaz, "Interface Homme-Ordinateur: Conception et réalisation", Thèse de Doctorat,Université Joseph Fourier, Grenoble, Déc 1988


212

[Coutaz 91a]J. Coutaz, L. Nigay, "Seeheim at architecture multi-agent", IHM'91 Troisièmes Journéessur l'Ingénierie des Interfaces Homme-Machine, Dourdan, 11-13 Déc. 1991.

[Coutaz 91b]J. Coutaz, A. Gourdol, "Communication Homme-Machine Multimodale : Perspectivespour la Recherche", Ecole organisée par le pôle IHMM du GRECO PRC CHM Lyon,10-12 avril 1991.

[Coutaz 92]J. Coutaz, "Multimedia and Multimodal User Interfaces : A Software EngineeringPerspective", Proc. International Workshop on Human Computer Interaction, StPetersburg, Russia, 1992.

[Coutaz 93c]J. Coutaz, L. Nigay, D. Salber, "The MSM Framework : A design Space for Multi-Sensori-Motor Systems", Lecture Notes in Computer Science, L. Bass, J. Gornostaev, C.Under Eds., EWCHI'93, East-West Human Computer Interaction, Selected Papers,Springer-Verlag, Moscou, Août 1993, pp. 231-241.

[Coutaz 94]J. Coutaz, L. Nigay, "Les propriétés "CARE" dans les interfaces multimodales", IHM'94Sixièmes Journées sur l'Ingénierie des Interfaces Homme-Machine, Lilles, 8-9 Déc.1994.

[Edmonds 81]E. A. Edmonds, "Adaptative Man-Computer Interfaces", Computing Skills and the UserInterface, M. J. Coombs et J. L. Alty Eds, Academic Press, London, 1981.

[Edmonds 82]E. A. Edmonds, "The Man-Computer Interface - a Note on Concepts and Design",International Journal of Man-Machine Studies, 16, 1982.

[Edwards 93]A. D. N. Edwards, R. D. Stevens, "Mathematical Representations : Graphs, Curves andFormulas" in Non-Visual Human-Computer Interactions, D. Burger and J. C. Sperandio,eds., Montrouge, France: John-Libbey Eurotext, 1993, pp. 181-193.

[Edwards 94]A. D. N. Edwards, R. D. Stevens, "Une interface multimodale pour l'accès aux formulesmathématiques par des élèves ou étudiants aveugles". Actes du séminaire Interfacesmultimodales pour handicapés visuels, nouvelles technologies, nouvelles solutions.Paris, 7 Nov. 1994.


213

[Elographics 89a]"Installation Guide and Programmer's Reference Manual", Elographics TouchscreenDriver Program for Serial and PC-Bus Touchscreen Controllers, Version 1.3, 1989.

[Elographics 89b]"User's Manual", Elographics E271-141, Revision B, PC-Bus Touchscreen Controller,1989.

[Emerson 91]M. Emerson, D. Jameson, G. Pike, R. Schwertfeger, J. Thatcher, "Screen Reader/PM,GUI Access by Blind Computer Users", Proceedings of the 1rst World Congress onTechnology, Washington D.C., vol. 3, 1-5 Déc 1991, pp. 65-75.

[Fass 94]D. Fass, "Stratégies cognitives mises en oeuvre dans l'utilisation d'une station de travailmultimodale", Mémoire de DEA, LIMSI-CNRS, 1994.

[Fasser 94]C. Fasser, "Travailler avec un ordinateur lorsqu'on est déficient visuel". Actes duséminaire Interfaces multimodales pour handicapés visuels, nouvelles technologies,nouvelles solutions. Paris, 7 Nov. 1994.

[Faure 92]C. Faure, L. Julia, "TAPAGE : une interface pour l'aide à l'édition de tableaux par laparole et le geste", IHM'92, 4èmes Journées sur l'ingénierie des interfaces Homme-Machine, Paris, 30 Nov - 2 Déc 1992.

[Faure 93]C. Faure, L. Julia, "Interaction Homme-Machine par la parole et le geste pour l'éditionde documents : TAPAGE", L'interface des mondes réels et virtuels, Montpellier, France,22-26 Mars 1993, pp. 171-180.

[Faure 94]C. Faure, L. Julia, "An Agent-Based Architecture for a multimodal Interface", ActesAAAI Spring Symposium on Intelligent Multi-Media Multi-Modal Systems, Stanford, 21-23 Mars 1994, pp. 82-86.

[Feldman 82]M. Feldman, G. Rogers, "Toward the Design and Development of Style-IndependentInteractive Systems", Proc. of Human Factors in Computer Systems, Mars 1982.

[Fellbaum 94]K. Fellbaum, K. Crispien, "Interfaces vocales et auditives destinées à des utilisateursnon-voyants. Résultats préliminaires du projet européen GUIB", Actes du séminaireInterfaces multimodales pour handicapés visuels, nouvelles technologies, nouvellessolutions. Paris, 7 Nov. 1994.


214

[Fels 93]S. S. FELS, G. E. HINTON, "Glove-Talk: A Neural Network Interface Between a Data-Glove and a Speech Synthesizer", IEEE Transactions on Neural Networks, vol 4, n° 1,1993, pp. 2-8.

[Fleury 94]L. Fleury, E. Filliatre, A. Léger, "Approche expérimentale des interactions sensori-motrices et cognitives dans le dialogue multimodal", L'interface des mondes réels etvirtuels Montpellier'94, Montpellier, Fév. 1994, pp. 107-115.

[Foley 90]J. D. Foley, A. Van Dam, S. K. Feiner, J. F. Hughes, "Computer Graphics, Principlesand Practice", Addison-Wesley Publ., Second Edition, 1990.

[Frohlich 91]D. M. Frohlich, "The Design Space of Interfaces, Multimedia Systems, Interaction andApplications", Proc. of 1st Eurographics Workshop, Stockholm, Suède, 18-19 Avril1991.

[Gaver 89]W. W. Gaver, "The Sonic Finder: An Interface that Uses Auditory Icons", Human-Computer Interaction, Vol. 4, pp 67-94, 1989.

[Gaildrat 93]V. Gaildrat, R. Caubet, F. Rubio, "Conception d'un modeleur déclaratif de scènestridimensionnelles pour la synthèse d'images", MICAD'93, Paris, 1993.

[Green 86]M. Green, "A Survey of Three Dialogue Models", ACM Trans. Graphics, Jul. 1986,pp. 244-275.

[Guib 93]TIDE-GUIB, "Access to MS Windows and X-Windows for blind people", TIDE PilotAction Guib, 1993.

[Guimarães 92]N. M. R. Guimarães, N. M. Correia, T. A. Carmo, "Programming Time in MultimediaUser Interfaces", UIST'92, Montery, California, 15-18 Nov. 1992, pp. 125-134.

[Gunzenhäuser 94]R. Gunzenhäuser, G. Weber, "Graphical User Interfaces for Blind People", Proc. of 13thWorld Computer Congress, Hamburg, 28 Aug.-2 Sept. 1994.

[Harel 87]D. Harel, "Statecharts : a Visual Approach to Complex Systems", Science of ComputerProgramming, vol 8.3, 1987, pp.231-275.


215

[Harness 93]S. Harness, K. Pugh, N. Sherkat, R. Whitrow, "Fast Icon and Character Recognition forUniversal Access to WIMP Interfaces for the Blind and Partially Sighted", inRehabilitation Technology, E. Ballabio; I. Placencia-Porrero; R. Puig de la Bellacasa(eds.), IOS Press, Amsterdam, 1993, pp. 19-23.

[Hartson 89]R. Hartson, "User-Interface Management Control and Communication". IEEE Software,Jan. 1989, pp. 62-70.

[Hatfield 81]D. Hatfield, Personal communication and lecture at Conference on Easier and MoreProductive Use of Computer Systems, Ann Arbor, MI 1981.

[Hjelmslev 47]L. Hjelmslev, "Structural Analysis of Language", Studia Phonetica, vol. 1, 1947,pp. 69-78.

[Hutchins 86]E. L. Hutchins, J. D. Hollan, D. A. Norman, "Direct Manipulation Interfaces", UserCentered System Design: New Perspectives on Human-Computer Interaction, Normanand Draper (Eds.), 1986.

[IHM 91]"Production des participants en ateliers", IHM'91 Troisièmes Journées sur l'Ingénieriedes Interfaces Homme-Machine, Dourdan, 11-13 Déc.1991.

[IHM 92]Compte rendu IHM'92, Atelier: "Interfaces multimodales et architecture logicielle".IHM'92. 4èmes Journées sur l'ingénierie des interfaces Homme-Machine, Paris, 30 Nov- 2 Déc 1992

[IHM 93]Compte rendu IHM'93. Atelier: "Interfaces multimodales", IHM'93. 5èmes Journées surl'ingénierie des interfaces Homme-Machine, Lyon, 19-20 Oct 1993

[Ishibuchi 93]K. Ishibuchi, H. Takemura, F. Kishino, "Real Time Hand Gesture Recognition using 3DPrediction Model", Actes de IEEE International Conference on Systems Man andCybernetics, IEEE, Le touquet, vol 5, 1993, pp. 324-328.

[Jacob 82]R.J.K. Jacob, "Using Formal Specifications in the Design of a Human-ComputerInterface", Proc. of Human Factors in Computer Systems, Mars 1982.


216

[Jacob 85]R.J.K. Jacob, "A State-Transition Diagram Language for Visual Programming", IEEEComputer, Aug. 1985, pp. 51-59.

[Jacob 86]R.J.K. Jacob, "A Specification Language for Direct-Manipulation User Interfaces",ACM Trans. Graphics, Oct. 1986, pp. 283-317.

[Jurain 91]T. Jurain, "De l'écrit à l'écran : étude et classification des aides logicielles audéveloppement d'interfaces graphiques". Génie logiciel & Systèmes experts, Sep. 1991,pp. 28-42.

[Kabbash 94]P. Kabbash, "Two-Handed Input in a Compound Task", Proc. CHI'94, Boston, 24-28Apr., 1994.

[Kochanek 94]D. Kochanek, "Designing an OffScreen Model for a GUI", Proc. of ICCHP'94, 4thInternational Conference on Computers for Handicapped Persons, Springer-Verlag,Vienna, Austria, Sep. 1994, pp. 89-95.

[Kramer 93]A. Kramer, "Can one Input Device make a Multimodal Interface?", Working Material,Workshop ERCIM on Human-Computer Interaction, Nancy, 2-4 Nov. 1993.

[Krasner 88]G. E. Krasner, S. T. Pope, "A CookBook for Using the Model-View-Controller UserInterface Paradigm in Smalltalk-80", Joop, Aug/Sep 1988.

[Krus 93]M. Krus, "XSPECIMEN: Un éditeur interactif de graphes de transitions décrivant desinterfaces multimodales", Rapport de stage de DESS, LIMSI-CNRS, Sept 93.

[Kuijpers 92]E. Kuijpers, M. D. Wilson, "A multi-modal interface for man-machine interaction withknowlodge based systems-MMI", Proc. of EWHCI'92, East-West InternationalConference on Human-Computer Interaction, St. Petersburg, Russie, Austria, Aug.1992, pp. 373-378.

[Mackay 92]W. Mackay, P. Wellner, R. Gold, "Special Issue on Computer Augmented Reality",Communications of the ACM, Vol. 23, 7, 1992.


217

[Martin 93]J. C. Martin, D. Béroule, "Type et buts de coopérations entre modalités", cinquièmesjournées dur l'ingénierie des interfaces Homme-Machine IHM'93, Lyon, 19-20 Oct.1993.

[Martin 94]J. C. Martin, "Cadre d'étude de la multimodalité fondé sur les type et buts decoopérations entre modalités", L'interface des mondes réels et virtuels Montpellier'94,Montpellier, Fév. 1994, pp. 97-106.

[Metrovision 93]Metrovision, "Notice technique oculomètre portable", Villeneuve d'Ascq, 1993.

[Murakami 91]K. Murakami, H. Taguichi, "Gesture Recognition using Recurrent Neural Networks",Actes de CHI'91, ACM, New Orleans (Louisiana), 1991, pp. 237-242.

[Myers 89]B. A. Myers, "User-Interface Tools: Introduction and Survey". IEEE Software, Jan.1989, pp. 15-23.

[Myers 93a]B. A. Myers. "State of the Art in User Interface Software Tools". Advances in Human-Computer Interaction, Vol. 4, H. R. Hartson & D. Hix eds., Norwood, NJ: AblexPublishing, 1993, pp.110-150.

[Myers 93b]B. A. Myers, M. B. Rosson, "Survey On User Interface Programming", User InterfaceTools, Tutorial Notes 27, CHI'93, Amsterdam, 24-29 Apr, 1993, pp. 90-97.

[Neal 88]J. G. Neal, C. Thielman, K. Bettinger, J. Byoun, "Multimodal References in Human-Computer Dialogue", in Proc. of AAAI-88, 1988, pp. 819-823.

[Neal 89]J. G. Neal, C. Y. Theilman, Z. Dobes, S. M. Haller, S. C. Shapiro, "Natural Languagewith integrated deictic and graphic gestures", Proc. DARPA/ISTO Workshop, SanMateo, 15-18 Oct 1989.

[Neal 90]J. G. Neal, and S. C. Shapiro, "Intelligent Multi-Media Interface Technology", inIntelligent User Interfaces, J. W. Sullivan and S. W. Tyler, eds., ACM Press, 1990.

[Nelson 80]T. Nelson, "Interactive Systems and the Design of Virtuality", Creative Computing,Vol 6, N° 12, Déc 1980.


218

[Nigay 91a]L. Nigay, "An Example of Multimodal Interactive System : a Voice Enabled NoteBook", Rapport technique, IMAG, Université Joseph Fourier, Grenoble, Octobre 1991.

[Nigay 91b]L. Nigay, J. Coutaz, "Building User Interfaces : Organizing Software Agents", Proc.ESPRIT'91 Conference, Bruxelles, Nov. 1991, pp. 707-719.

[Nigay 93a]L. Nigay, J. Coutaz, "Espace Problème, fusion et parallèlisme dans les interfacesmultimodales", L'interface des mondes réels et virtuels, Montpellier, 22-26 Mars 1993,pp. 67-76.

[Nigay 93b]L. Nigay, J. Coutaz, D. Salber, "MATIS : a Multimodal Airline Travel InformationSystem", SM/WP10, System Modelling, Working Paper 10, The Amodeus Project, EspritBasic Research Action 7040, 23 Fév 1993.

[Nigay 94]L. Nigay, "Conception et modélisation logicielles des systèmes interactifs", Thèse dedoctorat, Université Joseph Fourier Grenoble 1, 1994.

[Nogier 92]J. F. Nogier. "Dialogue Multimodal pour Systèmes de Contrôle & Surveillance", Ecoled'automne Thomson, Jouy-en-Josas, 7-11 Sept 1992.

[Nogier 93a]J. F. Nogier. "Multimodal Man-Machine Dialogue Applied to Control and SupervisionSystems", Interface to Real & Virtual Worlds, 22-26 Mars 1993, Montpellier, France.

[Nogier 93b]J. F. Nogier. "Vers le dialogue Homme-Machine Multimodal pour les systèmesd'Information et de Communication", Journées thématiques DGA/DRET, Informatiquede commandement, 10 Juin 1993, Arcueil, France.

[Olsen 84]D. R. Olsen, "Push Down Automata for User Interface Management", ACMTransactions on Graphics, 3(3), Juil. 1984.

[Olsen 92]D. R. Olsen, "User Interface Management Systems: Models and Algorithms", MorganKaufmann Publishers, San Mateo, California, 1992.

[Oriola 94]B. Oriola, N. Vigouroux, P. Truillet, "Accès multimodal aux documents électroniques".Actes du séminaire Interfaces multimodales pour handicapés visuels, nouvellestechnologies, nouvelles solutions. Paris, 7 Nov. 1994.


219

[Perbet 91a]J. N. Perbet, J. J. Favot, B. Barbier, "Interactive Display Concept For The NextGeneration Cockpit", in SID 91 Digest, May, 1991, pp. 487-490.

[Perbet 91b]J. N. Perbet, J. J. Favot, B. Barbier, "Interactive Display Concept For The NextGeneration Cockpit", Second Venaco Workshop on the Structure of MultimodalDialogue, Italy, 16-20 Sep. 1991.

[Perbet 92]J. N. Perbet, J. J. Favot, B. Barbier, "Système de dialogue multimodal pour cockpitfutur", AGARD CP-521 Advanced aircraft interface : the machine side of the man-machine interface, 1992.

[Pierrel 81]J. M. Pierrel, "Etude et mise en oeuvre de contraintes linguistiques en compréhensionautomatique du discours continu", Thèse d'Etat, Université de Nancy I, Mars 1981.

[Pierrel 87]J. M. Pierrel, "Dialogue oral Homme-Machine", Eds. HERMES, 1987.

[Pinson 88]L.J. Pinson, R. S. Wiener, "An introduction to object-oriented programming andsmalltalk", Addison-Wesley Publ., 1988.

[Poirier 93]F. Poirier, L. Julia, S. Rossignol, C. Faure, "TAPAGE : Edition de Tableaux surOrdinateur à Stylo. Vers une Designation Naturelle", IHM'93 Cinquièmes Journées surl'Ingénierie des Interfaces Homme-Machine, Lyon, 19-20 Oct. 1993.

[Pouteau 93a]X. Pouteau, B. Gaiffe, J. M. Pierrel, "A Knowledge-Based Approach towards OperativeMultimodal Dialogues : Melodia Experiment", ESCA Workshop, Lautrach, Sept 1993.

[Pouteau 93b]X. Pouteau, B. Bacconnet, J. M. Pierrel, "Coréférence Voix+Geste dans un DialogueMultimodal : vers une Interaction Naturelle", IHM'93 Cinquièmes Journées surl'Ingénierie des Interfaces Homme-Machine, Lyon, 19-20 Oct. 1993.

[Rubin 92]A. Rubin, M. Sutton, "Macintosch Access for Persons with Blindness", Technology andPersons with Disabilities, California State University, Northridge, Los Angeles,California, 20 Mar 1992.


220

[Rubio 94]F. Rubio, V. Gaildrat, N. Vigouroux, R. Caubet, "Les commandes progressives dans uneinterface multimodale", IHM'94 Sixièmes Journées sur l'Ingénierie des InterfacesHomme-Machine, Lille, 8-9 Déc.1994.

[Sabah 89]G. Sabah, "L'Intelligence Artificielle et le Langage", Tome I et II, Eds. HERMES, 1989.

[Sagawa 92]H. Sagawa, H. Sakou, M. Abe, "Sign Language Translation System Using ContinuousDP Matching", Actes de MVA'92 - IAPR Workshop on Machine Vision Applications,Tokyo, 1992, pp. 339-342.

[Salisbury 90]M. W. Salisbury. "Talk and Draw : Bundling Speech and Graphics", IEEE Computer,Aug. 1990, pp. 59-65.

[Schmandt 90]C. Schmandt, M. S. Ackerman, D. Hindus, "Augmenting a Window System withSpeech Input", IEEE Computer, 1990, pp. 50-56.

[Schwerdtfeger 91]R. S. Schwerdtfeger, "Making the GUI Talk", Byte Magazine, Déc 1991, pp. 118-128.

[Seeheim 83]"User Interface Management Systems", Proc. of the Workshop on User InterfaceManagement Systems, Ed. Günther E. Pfaff, 1-3 Nov., 1983, Seeheim, FRG.

[Shimazu 94]H. Shimazu, S. Arita, Y. Takashima, "Multi-Modal Definite Clause Grammar", Proc. ofCOLING-94, International Conf. on Computational Linguistics, Kyoto, Aug. 1994.

[Shneiderman 83]B. Shneiderman, "Direct Manipulation: A Step Beyond Programming Languages", IEEEComputer, Août 1983, pp. 57-69.

[Shneiderman 86]B. Shneiderman, "Direct Manipulation: A Step Beyond Programming Languages", IEEEComputer, 1986, pp. 57-69.

[Smart 93]W. D. Smart, A. Cobley, I. W. Ricketts & Y. Alistair, "Practical Multimodality",Working Material, Workshop ERCIM on Multimodal Human-Computer Interaction,Nancy, France, 2-4 Nov. 1993.

[Smart 94]W. D. Smart, I. W. Ricketts, Y. Alistair & A. Cobley, "Multimodality in the ARCHIESystem", Interfaces des mondes réels et virtuels, Montpellier, France, 7-11 Fév. 1994.


221

[Sturman 94]D. J. Sturman, D. ZELTER David, "A survey of Glove-based Input", Computer Graphicsand Applications, vol 14, n° 1, J. 1994, pp. 30-39.

[Tamura 88]S. Tamura, S. Kawasaki, "Recognition of Sign Language Motion Images", PatternRecognition, vol. 21, N° 4, 1988, pp. 343-353.

[Tanner 86]P.P. Tanner et al. "A Multitasking Switch-board Approach to User-InterfaceManagement,". Proc. SIGGraph 86, ACM, 1986, NewYork, pp. 241-248.

[Teil 91a]D. Teil, Y. Bellik, "Multimodal Dialogue Interface on a PC-like Work Station", 2ndVenaco Workshop, The Structure of Multimodal Dialogue, ESCA ETRW, Maratea,Italy, 16-20 Sept 1991.

[Teil 91b]D. Teil, Y. Bellik, "Système de dialogue multimodal sur une station de travail de typePC", IHM'91, 3èmes Journées sur l'ingénierie des interfaces Homme-Machine, Dourdan,Paris, 11-13 Déc 1991.

[Teil 95]D. Teil, Y. Bellik, "Multimodal Interaction Interface Using Voice and Gesture", àparaître dans The Structure of Multimodal Dialog II, M. M. Taylor, F. Néel and D.G. Bouwhuis (Eds.), Amsterdam, 1995.

[Thatcher 94a]J. W. Thatcher, "Screen Reader/2, Programmed Access to GUI", Proc. of ICCHP'94,4th International Conference on Computers for Handicapped Persons, Springer-Verlag,Vienna, Austria, Sep. 1994, pp. 76-88.

[Thatcher 94b]J. W. Thatcher, "How to make OS/2 talk and Why. Access to OS/2 with Screen-Reader/2", Proc. of OS/2 World Conference, Santa Clara, CA, Juil. 1994.

[Thimbleby 82]H. Thimbleby, "What You See Is What You Have Got?", Unpublished paper,Université de York, Angleterre, 1982.

[Thimbleby 90]H. Thimbleby, "User Interface Design", ACM Press, Frontier Series, Addison-WesleyPubl., 1990.

[Thomas 83]J. J. Thomas, G. Hamlin, "Graphical Input Interaction Technique (GIIT) : WorkshopSummary", Computer Graphics, 17 (1), Jan 1983, pp. 5-30.


222

[Vecsys 89a]"Guide de l'Utilisateur", Logiciel DATAVOX Version 2.5, VECSYS, Paris, 1989.

[Vecsys 89b]"Software Interface", DATAVOX Software. Version 2.5, VECSYS, Paris, 1989.

[Vigouroux 92]N. Vigouroux, V. Gaildrat, R. Caubet, G. Pérennou, "Une architecture d'interface pourl'interpretation d'informations multimodales : application à un modeleur déclaratif descènes", IHM'92, 4èmes Journées sur l'ingénierie des interfaces Homme-Machine,Paris, 30 Nov - 2 Déc 1992.

[Vo 95]M. T. Vo, R. Houghton, J. Yang, U. Bub, U. Meier, A. Waibel, P. Duchnowski,"Multimodal Learning Interfaces", Spoken Language Systems Technology workshop,Austin, Texas, Jan. 1995.

[Wasserman 81]A. I. Wasserman, "User Software Engineering and the Design of Interactive Systems",Proc. of the Fifth International Conference on Software Engineering, Mars 1981.

[Wasserman 85]A. I. Wasserman, "Extending State Transition Diagrams for the Specification of Human-Computer Interaction", IEEE Transactions on Software Engineering, vol. se-11, N° 8,Aug 1985.

[Wilson 91]M. D. Wilson, "A Multimodal Interface for Man Machine Interaction with KnowledgeBased Systems", The first MMI2 Demonstrator, Delivrable d7, Esprit Project 2474MMI2, Ed. M. D. Wilson, July 1991.

[Wilson 93]M. D. Wilson, G. A. Ringland, G. Wickler, "Cooperative Dialogue and MultimodalInterfaces", Working Material, Workshop ERCIM on Multimodal Human-ComputerInteraction, Nancy, France, 2-4 Nov. 1993.

[Winograd 83]T. Winograd, "Language as a cognitiv process", vol. I. Syntax, Addison Wesley, 1983.

[Woods 70]W. A. Woods, "Transition Network Grammars for Natural Language Analysis",Communication of the ACM, Oct 1970.

[Woods 78]W. Woods, "Generalisation of ATN grammars" in Research in Natural LanguageUnderstanding, Woods and Brahman, BBN report N° 3963, Bolt Beranek and Newman,Cambridge, USA, 1978.


223

[Woods 80]W. Woods, "Cascaded ATN", AJCL 6, 1980, pp. 1-12.

[Wreto 90]J. Wreto, J. Caelen, "ICP-DRAW", Rapport final du projet ESPRIT MULTIWORKS,No. 2105, 1990.

[XVT 91]XVT Software, Inc., Box 18750 Boulder, CO 80308.

[Zimmerman 87]T. G. Zimmerman, J. Lanier, C. Blanchard, S. Bryson, Y. Harvil, "A Hand GestureInterface Device", Actes de CHI+GI'87, ACM, 1987, pp. 189-192.

Annexes

224

ANNEXE 1Vocabulaire utilisé dans LIMSI-Draw

Le vocabulaire utilisé dans LIMSI-DRAW est assez restreint (donc facile à mémoriser).Il est constitué des 28 mots suivants:

Les commandesrectangle fait référence à la commande de tracé de rectangles.triangle fait référence à la commande de tracé de triangles.cercle fait référence à la commande de tracé de cercles.copie fait référence à la commande de copie d'un objet.met fait référence à la commande de déplacement d'un objet.efface fait référence à la commande d'effacement d'un objet.tout utilisé avec le mot "EFFACE" pour faire référence à la commande

d'effacement de tous les objets.change utilisé avec les mots "COULEUR" et "MOTIF".couleur utilisé avec le mot "CHANGE" pour faire référence à la commande de

modification de la couleur.motif utilisé avec le mot "CHANGE" pour faire référence à la commande de

modification du motif.

Les couleursblanc sélectionne la couleur blanche.vert sélectionne la couleur verte.rouge sélectionne la couleur rouge.jaune sélectionne la couleur jaune.marron sélectionne la couleur marron.violet sélectionne la couleur violet.

Les motifs de remplissagehachuré sélectionne le motif de remplissage hachuré.croisé sélectionne le motif de remplissage croisé.plein sélectionne le motif de remplissage plein.vide sélectionne le motif de remplissage vide.

Annexes

225

Diversça fait référence à l'argument OBJET des commandes de copie, de

déplacement, d'effacement, de la modification de la couleur et du motifde remplissage d'un objet.

ici fait référence à l'argument POSITION de la commande de copie ou dedéplacement d'un objet.

le fait référence au dernier objet crée ou manipulé.centre fait référence à l'argument CENTRE de la commande de tracé de

cercles.bordure fait référence à l'argument RAYON de cette même commande.de mot facultatif.la mot facultatif.en mot facultatif.

Annexes

226

ANNEXE 2Vocabulaire utilisé dans MEDITOR

Le vocabulaire utilisé dans MEDITOR est constitué des mots suivants:

Opérations sur les fichiersfichier, nouveau, charger, enregistrer, sous.

Commandes d'éditioncopier, coller, insérer, couper, effacer, écrire.

Commandes diversesannuler, lire, rechercher, liste.

Gestion des notesnote, créer, afficher, lire, effacer.

Gestion des locuteurslocuteur, nouveau, quel.

Contrôle de la synthèsesynthèse, normale, plus, moins, vite, fort, grave, arrête, continue.

Navigationtexte, début, fin, ligne, page, suivante, précédente, encore, énoncé, support,

corrigé, où suis je, retour.

Sélectioncaractère, mot, phrase, ligne, paragraphe, sélection, tout, début, fin

Stylesnormal, gras, italique, souligné

Couleursblanc, noir, bleu, rouge, vert

Annexes

227

Positionindice, normale, exposant

Nombresde 0 à 9999

Annexes

228

ANNEXE 3Exemple de calcul des temps de début et de fin de

prononciation d'un mot

Le système de reconnaissance vocale DATAVOX est un système qui fait lareconnaissance de mots enchaînés. Dés qu'une phrase prononcée par l'utilisateur est reconnue,il génère une interruption en envoyant une chaîne de caractères ayant la structure suivante:

mot1 [x1,y1,z1] mot2 [x2,y2,z2]........motn [xn,yn,zn]

xi représente le taux de reconnaissance du moti.yi représente le numéro de la première trame du moti dans le signal acoustique.zi représente le numéro de la dernière trame du moti dans le signal acoustique.

Pour pouvoir calculer le temps de début et de fin de prononciation d'un mot, il estnécessaire de savoir que:

1- la longueur temporelle d'une trame est de 12,8 millisecondes2- la fin de phrase est reconnue, lorsqu'un silence de 256 millisecondes est détecté.

Le calcul des temps de début et de fin de prononciation d'un mot se fait alors de la façonsuivante:

1- Dés que l'interruption est générée, on mémorise le temps où elle a été provoquée.

2- On retranche à ce temps, une durée qui correspond au temps de reconnaissancemoyen. L'erreur induite par ce temps de reconnaissance moyen est négligeable.

3- On retranche encore à ce temps 256 millisecondes qui correspondent au silence ayantpermis de détecter la fin de phrase. A ce stade, on retrouve donc, le temps TFP correspondantà la fin de prononciation de la phrase.

4- On calcule le nombre de trames total NBTT. Celui-ci est égal au numéro de ladernière trame du dernier mot, incrémenté de 1 car la numérotation des trames débute à 0.

Annexes

229

5- Le temps de début de prononciation d'un mot peut être alors calculé par la formulesuivante: TDEB = TFP - (NBTT - NPT) * LT

où NPT représente le numéro de la première trame du mot,et LT représente la longueur temporelle d'une trame.

6- Le temps de fin de prononciation d'un mot est quant à lui calculé par la formulesuivante: TFIN = TFP - (NBTT - NDT - 1) * LT

où NDT représente le numéro de la dernière trame du mot.

interfaces multimodales : concepts, modèles et architectures...development of multimodal...

Documents