FLASH INFORMATIQUE FI



Le Service Counter System toolkit

ou une boîte à outils pour la construction d’interfaces multimodales




Dominique GUINARD

Pedro DE ALMEIDA

Martin Eric RITZ


Cet article présente le SCS (Service Counter System), un ensemble de composants logiciels permettant la conception d’interfaces utilisateurs multimodales. Dans ce but le SCS fournit une couche d’abstraction orientée-objet des librairies de modalités d’entrées et de sorties existantes. De plus, cette boîte à outils propose une machine à états permettant de modéliser le flux des interactions homme-machine.

Introduction

Présentes depuis longtemps déjà dans les esprits les plus imaginatifs, les interfaces multimodales sont aujourd’hui devenues réalité et commencent, discrètement mais sûrement, à modifier les interactions homme-machine. Une interface dite multimodale s’oppose à la mono-modalité majoritairement utilisée de nos jours. Elle permet à l’utilisateur d’interagir avec la machine en utilisant de nouveaux canaux de communication. Le GUI (Graphical User Interface), standard de facto, se voit agrémenté de TUI (Tangible User Interfaces) [1], de VUIs (Voice User Interfaces) [2] et autres KUI (Kinetic User Interfaces) [3]. Ainsi les interactions homme-machine et machine-homme se réalisent désormais également par la voix, les déplacements, la kinesthésie, l’association d’objets usuels, le toucher, l’odorat, les expressions faciales, etc.
Dans ce contexte en forte mouvance, le SCS (Service Counter System) est un ensemble de composants logiciels (i.e. un toolkit) permettant la conception d’interfaces utilisateurs multimodales. Plus particulièrement, il a été conçu selon deux modèles permettant de faciliter la tâche des concepteurs d’interfaces tangibles et multimodales :

  • d’une part il offre une série d’interfaces (au sens Java™) et de pilotes génériques permettant une agrégation, orientée-objet, de divers frameworks et autres librairies de modalités d’entrées ou de sorties.
  • d’autre part il est axé autour d’une machine à états qui permet, à chaque étape dans le flux d’interactions homme-machine, de modéliser les différentes modalités à prendre en compte.

Motivation

L’idée de ce toolkit n’est pas venue d’elle-même. En effet, afin de pouvoir participer au Memodules Award 2006 nous avions pour mission de concevoir et d’implémenter une interface utilisateur intégrant au minimum deux modalités différentes. Dans ce contexte nous voulions créer un système permettant de simuler un guichet ou comptoir (service counter) afin de pouvoir automatiser certaines tâches telles que la location d’objets (DVD, livres, etc.) où l’obtention d’informations (touristiques, acomptes, etc.). Au fur et à mesure de l’étude préalable de projet nous avons réalisé le manque d’uniformité qui existait au sein des librairies d’interactions homme-machine (et multimodales) existantes. Il en résulte une grande dépense en termes de temps pour obtenir, à chaque nouvelle interface, un modèle d’interopérabilité des librairies clair et conséquent.
L’idée nous est donc venue de construire un prototype de toolkit intégrant différentes bibliothèques au sein d’un unique modèle. De plus l’articulation des composants autour d’une machine à états devait permettre de ne pas limiter nos classes à la programmation d’un seul cas d’utilisation. Enfin l’utilisation du pattern de l’observateur [4] différait la programmation de la logique de l’interface afin de découpler celle-ci des canaux de communication homme-machine.

L’architecture du SCS

Du point de vue du concepteur d’interfaces multimodales, le SCS fournit une aide de trois manières :

  • premièrement en lui offrant un jeu intégré de bibliothèques existantes et de leurs composants sous-jacents. Le prototype actuel permet ainsi l’utilisation de la bibliothèque Papier-Mâché [5] pour la reconnaissance visuelle, de la plupart des composantes physiques Phidgets [6] ainsi que des bibliothèques Sphinx pour la reconnaissance vocale ;
  • deuxièmement en lui fournissant un framework logiciel pour l’intégration de librairies supplémentaires (à l’aide du paradigme de l’orienté-objet) ;
  • finalement en lui permettant d’articuler son application autour d’une machine à états fournie et adaptée à la programmation d’interfaces multimodales.

L’état est au centre

Comme le suggère la fig. 1, la machine à états est au centre du SCS.

JPEG - 3.9 ko
fig. 1
l’architecture du SCS

C’est avec l’aide de ce générateur d’automates [1] spécialement conçu pour les interfaces multimodales que le programmeur va décrire le flux des interactions homme-machine. Autrement dit, il va pouvoir créer les états du système et leurs transitions. Modélisant par exemple le fait qu’après s’être authentifié (i.e. après avoir changé d’état) un adhérent peut emprunter (première transition possible) ou rendre (deuxième transition possible) un DVD. A titre d’exemple la fig. 2 représente l’automate résultant de la conception du cas d’utilisation décrit plus loin (bibliothécaire intelligent).

JPEG - 3.1 ko
fig. 2
l’automate du bibliohécaire intelligent

Les drivers d’entrées/sorties

Comme mentionné précédemment le SCS réalise une abstraction de différentes librairies d’interactions homme-machine créant ainsi une plate-forme multimodale. Les classes-clés de cette abstraction sont les pilotes ou drivers. Ils représentent une manière uniforme d’accéder aux librairies et composants sous-jacents. Chaque librairie utilisée en entrée ou en sortie communique avec un pilote générique étendant la classe InputDriver, respectivement OutputDriver. Ainsi, par exemple, les phobs de la bibliothèque Papier-Mâché, les events handlers des Phidgets ou bien encore les tags du projet Sphinx sont accessibles de manière uniforme au concepteur d’interfaces multimodales.

Les InputDrivers

Les InputDrivers représentent les modalités d’entrées de l’utilisateur (canaux homme -> machine). Ils étendent tous la classe (abstraite) InputDriver et offrent principalement deux fonctionnalités. Ils sont capables de répondre à un certain nombre de transitions, entendez par là qu’ils peuvent ou non faire changer la machine à états selon le contexte courant. Ainsi par exemple le RFIDDriver, abstraction au sein du SCS d’un lecteur RFID (Radio Frequency IDentification) Phidget pourra être utilisé pour une transition de type authentification mais ne pourra l’être pour une transition de type confirmation. Il est important de saisir le fait que les transitions auxquelles le RFIDDriver réagit ne sont pas codées dans celui-ci mais sont définies par le concepteur de l’interface au moment de l’instanciation. Ceci permet donc de créer des pilotes plus génériques. En plus de communiquer ou non leurs observations en fonction du contexte les InputDrivers offrent des fonctionnalités de signalisation d’activation. En effet, étant donné que plusieurs InputDrivers peuvent répondre à une transition donnée, il faut offrir au programmeur un moyen de notifier l’utilisateur des modalités d’entrées activées à chaque étape. A cet effet chaque pilote offre une méthode de notification permettant soit d’utiliser les classes fournies (aspect boîte à outils du SCS) : allumer des leds Phidget, déclencher un signal sonore ou bien encore afficher des informations dans les différents composants du GUI, soit d’implémenter son propre système de notification (aspect framework du SCS). De la même manière, il peut utiliser les pilotes concrets fournis (p.ex. TouchDriver, VoiceDriver, JoystickDriver, VisionDriver, ButtonDriver, etc.) ou programmer ses propres pilotes en étendant la classe InputDriver.

Les OutputDrivers

Les modalités de sortie (canaux machine -> homme) sont quant à elles modélisées à l’aide des OutputDrivers. D’un point de vue génie logiciel les OutputDrivers sont très similaires aux InputDrivers. Les pilotes de sortie sont tous des descendants de la classe (abstraite) OutputDriver et répondent tous à certaines transitions qu’ils reçoivent par le biais d’événements (DriverEvents) en provenance des InputDrivers. Toutefois, au contraire des InputDrivers très génériques et ne nécessitant que peu de modifications de la part du concepteur, les OutputDrivers renferment la logique de l’application et doivent donc être modifiés pour créer celle-ci. Par exemple, le DatabaseDriver doit connaître la nature de la requête à formuler. Le concepteur n’est toutefois pas laissé seul devant cette tâche. En effet les nombreux pilotes fournis (p.ex. DatabaseDriver, ConsoleContainerDriver, CameraMotorDriver, ObjectContainerDriver) ne nécessitent que peu de modifications (ou pas du tout) pour modéliser différents cas d’utilisation. Ainsi, par exemple, le DatabaseDriver ayant reçu (d’un InputDriver) le numéro de l’utilisateur à identifier devra être uniquement modifié afin de contenir la requête exacte à formuler.

Communiquer et Observer

Afin de contextualiser l’utilisation concurrente des modalités, la machine à états doit pouvoir communiquer aux pilotes (i.e. Input/OutputDrivers ) l’état courant ainsi que les transitions possibles. Cela se fait au moyen d’une variation du pattern de l’observateur du désormais célèbre Gang of Four [4]. Les pilotes offrent tous une méthode update(ArrayListtransitions) permettant à leur gestionnaire respectif (le MultimodalInput/OutputManager) de les informer des transitions possibles pour l’état courant. Ainsi, à chaque fois qu’une transition valide a été sélectionnée et exécutée, la machine change d’état et communique aux gestionnaires les nouvelles transitions acceptées. Dès lors, les pilotes d’entrées concrets communiquent leurs observations aux pilotes de sorties uniquement s’ils acceptent l’une des transitions actuellement valides.

Le bibliothécaire intelligent

Le bibliothécaire intelligent est né d’un regroupement d’idées ayant pour but de démontrer l’utilisation du SCS afin de créer une interface multimodale. Il s’agit en effet d’un cas d’utilisation particulier du SCS. Le bilbiothécaire intelligent simule un comptoir de bibliothèque modernisé permettant aux abonnés d’effectuer des emprunts ou des retours de livres automatiquement sans devoir passer par une tierce personne. La création d’un cas d’utilisation capable de mettre en valeur le véritable apport de la multimodalité n’est pas toujours trivial. C’est pourquoi ce cas d’utilisation a été conçu non seulement dans l’optique d’être accessible par toutes les catégories de personnes mais également d’apporter une nouvelle dimension aux interfaces multimodales en mettant en avant l’intuitivité résultant d’une telle approche.

Description du cas d’utilisation

L’environnement du bibliothécaire intelligent suppose que chaque membre soit connu du système et que les livres à disposition dans le catalogue de la bibliothèque soient munis d’un tag (transpondeur) RFID, les rendant ainsi identifiables.
Dès lors, l’utilisateur pourra accéder aux différentes fonctionnalités de l’interface multimodale disponibles selon l’état du système et qui varient selon la transition (ou action) complétée. Ces fonctionnalités peuvent être accessibles soit par l’utilisation des phidgets activés soit au travers des périphériques plus standards (souris ou clavier) mais également par la voix ou la vision comme représenté par les fig. 3 et 4 (aspect multimodal du cas d’utilisation).

JPEG - 5.9 ko
fig. 3
Représentation graphique de l’interface du libraire intelligent
JPEG - 8.4 ko
fig. 4
Représentation physique du bibliothécaire intelligent

Description des fonctionnalités

Après avoir démarré le bibliothécaire intelligent, ce dernier se met automatiquement en veille, attendant l’activation du système par l’utilisateur. Malgré le fait que l’interface multimodale offre de multiples commandes, l’utilisateur connaît à chaque instant l’étendue des possibilités d’interaction disponibles. Cela même grâce aux LED des phidgets, signifiant qu’ils peuvent être utilisés, mais également au travers de l’interface graphique et de son menu d’options. De plus, la voix est disponible dans chaque état du système et permet par exemple de se déplacer dans le menu ou de valider comme d’annuler une action.
Une fois le système activé (fig. 5), le membre de la bibliothèque peut s’authentifier soit par le formulaire de connexion de l’interface graphique ou directement en déposant sa carte de membre (contenant une puce RFID) sur la zone usercard. Il accède alors au menu principal dans lequel il peut naviguer en utilisant la voix (en prononçant up ou down), le mini-joystick ou tout simplement la souris ou bien encore les touches fléchées du clavier.

JPEG - 5.9 ko
fig. 5
L’interface graphique après l’activation du système

L’utilisateur pourra par exemple consulter les livres disponibles dans le menu Catalog, la liste de ses livres empruntés dans le menu My Books ou se déconnecter avec le menu Logout. Mais les fonctionnalités liées à la gestion des livres sont d’autant plus intéressantes que faciles d’utilisation. En effet, l’utilisateur n’a qu’à déposer un livre sur la zone out pour que le système détecte ce dernier, affiche les informations concernant le livre et propose à l’utilisateur de l’emprunter (comme illustré par la fig. 6). Si ce dernier confirme alors le livre sera automatiquement réservé à son nom. Inversement, si l’utilisateur dépose un livre dans la zone in alors le système vérifie si le livre en question est réservé à son nom et, si tel est le cas, il le replace dans le catalogue de la bibliothèque.

JPEG - 10.2 ko
fig. 6
Détection des livres grâce aux lecteurs RFID

Enfin, certaines fonctionnalités sont réservées aux administrateurs et permettent, depuis le menu Administration de gérer la bibliothèque intelligente. En particulier, il pourra calibrer la caméra grâce aux sliders depuis le menu Vision Configuration et même insérer un nouveau livre depuis le menu Book Edition. Dans ce dernier cas, l’administrateur dépose un livre sur la zone centrale afin que la caméra prenne un aperçu de ce dernier et entre, dans la zone d’édition à gauche, les informations relatives au livre comme illustré par la fig. 7. Enfin, la dernière étape consiste à lier le livre avec un identifiant ou plutôt un tag RFID inconnu du système en déposant ce dernier sur une des deux surfaces in ou out. Une fois l’identifiant reconnu, l’administrateur peut alors valider l’édition et le livre pourra être dorénavant emprunté par les membres de la bibliothèque.

JPEG - 8.7 ko
fig. 7
L’insertion d’un nouveau livre dans le catalogue

Etat de l’art

Avec la croissance (fulgurante) de la puissance computationnelle les HCI (Human Computer Interactions) et en particulier le domaine des interfaces multimodales et tangibles connaît un nouvel essor. Ce n’est donc pas étonnant que plusieurs toolkits soient apparus ces dernières années.
Ainsi la bibliothèque Papier-Mâché [5] propose une couche logicielle permettant d’abstraire les Phidgets ainsi que de nombreuses fonctionnalités liées à la vision. L’ARToolKit [7] quant à lui offre des méthodes de haut niveau permettant de construire des interfaces tangibles basées sur la traçabilité de marqueurs (de type code-barres). Ces systèmes facilitent le travail des concepteurs d’interfaces multimodales puisqu’ils leur permettent d’éviter une réflexion et une conception à trop bas niveau. Ils ne proposent en revanche pas de solution pour la modélisation des interactions et de la logique de l’interface.
Le Mutlimodal Swing Extension Framework [2] [9] permet d’étendre le contrôle d’un GUI à des canaux d’entrée divers. Par exemple, l’utilisateur peut piloter la sélection dans un menu contextuel en utilisant la voix (via Sphinx) ou un bouton Phidget. Cette approche très intéressante permet le pilotage d’une interface graphique en utilisant plusieurs modalités mais nécessite donc de pouvoir modéliser toutes les interactions à l’aide de composants graphiques.
Nous citerons enfin d.tools dont les fonctionnalités pour le prototypage d’interfaces physiques et digitales sont impressionnantes. A la différence de Papier-Mâché, de l’ARToolKit ou du Mutlimodal Swing Extension Framework, d.tools propose également une solution pour la modélisation des interactions. Le développeur d’interfaces peut ainsi s’abstraire totalement dans le développement de la logique des interactions. Ce fait le rapproche encore plus du SCS, toutefois d.tools va encore plus loin dans ce domaine puisqu’il permet de créer ces interactions aux moyen d’outils graphiques. En effet, là où le SCS propose une approche programmatique de l’implémentation du flux d’interactions (via la machine à états et les OutputDrivers), d.tools permet la modélisation par glisser-déplacer (ou drag and drop). Malheureusement, cette simplicité d’utilisation à un coût puisqu’elle requiert l’utilisation de composants physiques compatibles avec d.tool. Le SCS se distingue ici en offrant la possibilité d’intégrer n’importe quelle bibliothèque avec un minimum d’efforts.

Conclusion

Selon les créateurs de la bibliothèque Papier-Mâché, la création d’interfaces tangibles nécessite de ré-inventer la roue à chaque nouveau projet [5]. Une telle approche comporte un problème : les créateurs d’interfaces tangibles se perdent souvent à régler des détails peu liés aux interactions utilisateurs (communication avec les périphériques physiques, programmation d’un cadre applicatif permettant de gérer les événements, etc.). La perte de temps ainsi engendrée diminue de façon significative les possibilités de focalisation des chercheurs sur les interactions homme-machine. La création d’interfaces multimodales n’échappe pas à cette constatation.
Dans son état actuel le SCS est un prototype et ne prétend donc pas offrir une solution totalement aboutie à ce problème de fond. Ainsi le toolkit nécessite encore des optimisations permettant notamment d’améliorer la responsivité des interactions. Toutefois, il pose les bases théoriques et pratiques (démontrées à l’aide du bibliothécaire intelligent) d’une solution flexible permettant de créer de nombreuses interfaces multimodales. D’une part en offrant un système d’intégration des librairies liées aux modalités d’entrées et de sorties, d’une autre en permettant de modéliser le flux des interactions au moyen d’une machine à états centrale et la logique applicative au moyen des OutputDrivers.
La version actuelle du SCS ainsi que sa documentation et des vidéos du bibliothécaire intelligent sont téléchargeables.

Références


[1] Ullmer B. et Ishii H. (2001). Emerging Frameworks for Tangible User Interfaces. In J. M. Carroll (Ed.), Human Computer Interaction in the New Millenium, Addison-Wesley.
[2] Cohen M. H., Giangola J. P. et Balogh J. (2004). Voice User Interface. Addison-Wesley Professional.
[3] Pallotta V., Brocco A., Guinard D., Bruegger P. et De Almeida P. (2006). RoamBlog : Outdoor and Indoor Geo-blogging Enhanced with Contextual Service Provisioning for Mobile Internet Users. In Proceedings of the Workshop on Distributed Agent-based Retrieval Tool, DART 06 Italy, www.gmipsoft.com/guinard.
[4] Gamma E., Helm R., Johnson R., et Vlissides J. (1995). Design Patterns : Elements of Reusable Object-Oriented Software. Professional Computing Series. Addison-Wesley.
[5] Klemmer S., Li J., Lin J., et Landay J. A. (2004). Papier-Mâché : Toolkit Support for Tangible Input. CHI Letters, Human Factors in Computing Systems : CHI 2004.
[6] Greenberg S. et Fitchett C. (2001). Phidgets : easy development of physical interfaces through physical widgets. User Interface Software & Technology, CHI Letters, 2001.
[7] Kato, H., M. Billinghurst, et I. Poupyrev. ARToolKit (2000). University of Washington HIT Lab, www.hitl.washington.edu/artoolkit/.
[8] Hartmann B., Klemmer S.R., Bernstein M., Abdulla L., Burr, B., Robinson-Mosher A., Gee J. (2006). Reflective physical prototyping through integrated design, test, and analysis. In proceedings of UIST 2006, September 2006.
[9] Bruegger P., Locher P., Koenig R. (2006), Mutlimodal Swing Extension Framework. Presenté au Memodules Awards 2006

[1] Un générateur de DFAs (Deterministic Finite Automata ou automates finis déterministes), pour être précis.

[2] Le Mutlimodal Swing Extension Framework a également été présenté au Memodules Awards 2006.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.