Architecture Multimodale et Interfaces

Architecture Multimodale et Interfaces est un standard ouvert en développement par le World Wide Consortium depuis 2005. Actuellement il est considéré comme brouillon de travail (Working Draft) du W3C. Le document est le rapport technique de spécification d'une architecture informatique générique et de ses interfaces pour faciliter l’intégration et la gestion des interactions multimodales dans un environnement informatique. Il a été produit par le Groupe de Travail en Interaction Multimodale du W3C.

Multimodal Architecture and Interfaces
Editeur	World Wide Web Consortium
Auteur	MMI Working Group
Genre	Recommandation
Etat	Working Draft
Première Publication	Avril 22, 2005
Dernière Publication	Janvier 25, 2011
Standard	Dernière Version
Site Web	http://www.w3.org/2002/mmi/

Description

Une Architecture Multimodale

La recommandation Architecture Multimodale et Interfaces se concentre sur la proposition d'un cadre général pour permettre aux modules requis dans un système multimodal, de communiquer les uns avec les autres.

Cette spécification propose une architecture orientée évènement dont le principal objet est le flux de données de contrôle car en tant que cadre général de référence, elle sert à déterminer les infrastructures de base utiles pour le contrôle de l'application et des services multimodaux.

L'architecture est aussi proposée pour faciliter la tâche d'implémentation à plusieurs types de dispositifs fournisseurs de services multimodaux, comme les dispositifs mobiles et portables, les appareils électroménagers, l'internet des objets, la télévision et les réseaux domestiques, les applications d'entreprise, les applications web, ^[[1]] les voitures "intelligentes" ou comme les applications médicales.

Structure Logique

L'architecture dans le MMI Runtime Framework

Architecture Multimodale et Interfaces est la description spécifiée d'une infrastructure de services plus large appelée The Runtime Framework dans laquelle sont fournies les principales fonctions dont un système multimodal a besoin et qui se trouve a un niveau d'abstraction plus haut que l'architecture MMI.^[[2]] Ce framework est le support d'exécution et de communication des modules du système multimodal tandis que l'architecture MMI est la description et la spécification de ses principaux modules, ses interfaces et son mode de communication.

Le Modèle MVC dans MMI-Arch

La recommandation Architecture Multimodale et Interfaces s'inspire du patron de conception d'architecture applicative MVC qui organise la structure des interfaces utilisateur en trois parties : le Modèle, la Vue et le Contrôleur.^[[3]]

L'imbrication dans l'architecture MMI

Une particularité de cette architecture c'est que bien que la couche de présentation représentée par la Vue a été traditionnellement appliquée aux interfaces graphiques; cette recommandation généralise l'abstraction au contexte plus large de l'interaction multimodale où l'utilisateur peut utiliser une combinaison de modalités visuelles, auditives, biométriques et/ou tactiles.

L'architecture MMI fait donc la distinction entre le contrôleur d'interaction (Interaction Manager - IM), le composant de données (Data Component - DC) et les composants modalité (Modality Components - MC). Cette distinction est similaire à la distinction entre le Contrôleur, le Modèle et les documents de présentation de la Vue dans le patron MVC.

Une autre particularité est l'imbrication. Les modules étant des boîtes noires, il est possible d'encapsuler plusieurs composants dans un composant plus complexe, qui communiquerait avec un contrôleur de plus haut niveau. De cette manière l'architecture suit le principe des poupées russes.^[[4]]

La recommandation propose aussi une mise en œuvre de façon distribuée sur plusieurs supports matériels en réseau ou de façon centralisée, avec tous les modules sur un même support matériel. L'échange d'information entre les différents modules se fait avec un couplage lâche qui favorise la faible dépendance entre les modules, la réduction de l'impact des changements dans un module et la réutilisation des modules. De cette manière les modules ont peu ou aucune connaissance du fonctionnement des autres modules et la communication entre les modules se fait grâce à l'échange de messages selon un protocole de communication précis à travers les interfaces de programmation fournies par l'architecture MMI.^[[5]]

Les modules de l'Architecture MMI

Modules de l'Architecture

Le contrôleur d'Interaction (Interaction Manager)

Le contrôleur d'Interaction est un composant logique, chargé de tous les échanges de messages entre les composants de modalité du système et l'infrastructure multimodale (le Runtime Framework). Il est un bus de communication et un gestionnaire d'évènements.

Chaque application peut configurer au moins un contrôleur d'interaction (Interaction Manager) pour définir la logique d'interaction souhaitée. Ce contrôleur est au cœur de l'interaction multimodale:

• Il gère les comportements spécifiques déclenchés par les messages échangés entre les différents modules d'entrée et de sortie.
• Il gère la communication entre les modules et l'application cliente.
• Il assure la cohérence entre plusieurs entrées et sorties et fournit une perception de l'état général de l’application.
• Il est responsable de la synchronisation des données.
• Il est responsable de la gestion du focus.
• Il gère la communication avec toute entité externe au système.

Les composants de modalité (Modality Component)

Les composants de modalité sont responsables de tâches spécifiques, notamment la manipulation des entrées et des sorties dans les diverses modalités, comme la parole, l'écriture, la vidéo, etc. Ce sont des entités logiques responsables du contrôle des entrées et des sorties des différents dispositifs matériels (microphone, tablette graphique, clavier) et logiciels (détection de mouvement, changements biométriques) associés au système multimodal. Par exemple (voir diagramme ci-dessous), un composant de modalité A peut se charger de la reconnaissance de la parole avec la gestion des entrées audio. Un autre composant de modalité B peut gérer plutôt les entrées complémentaires provenant de deux dispositifs différents : une tablette graphique et un microphone. Deux composants de modalité C, peuvent gérer séparément deux entrées complémentaires fournies par un même dispositif: une caméra vidéo. Un dernier composant de modelité D, peut utiliser un service externe de reconnaissance et ne contenir que le contrôle des échanges nécessaires à la reconnaissance.

Abstraction des entrées avec les Modality Components

Dans les quatre cas le système possède un composant de modalité pour la détection des commandes vocales en entrée, malgré les différences d'implémentation: le composant de modalité étant une abstraction d'un type d'entrée qui est gérée et implémentée de manière différente à chaque cas. Tout composant de modalité peut éventuellement envelopper de multiples fonctionnalités fournies par plusieurs périphériques physiques, mais aussi plusieurs composants de modalité pourraient être inclus dans un seul appareil. Pour cette raison, la recommandation du W3C dans son état actuel ne décrit pas en détail la structure ou l'implémentation des composants de modalité. Elle porte seulement sur la nécessité de prévoir une interface de communication avec le contrôleur d'interaction et une implémentation qui respecte un protocole de communication précis: les Life-Cycle Events.

Le composant de données publiques et privées

Le composant de données (Data Component)

Le composant de données a pour rôle de sauvegarder les données publiques de l'application qui peuvent être requises par plusieurs composants de modalité ou par d'autre modules (par exemple, le module de session du framework MMI).

Le composant de données peut être un module interne A au contrôleur d'interaction ou externe B (voir diagramme). Ceci dépend de l'implémentation choisie par chaque application. Toutefois le contrôleur d'interaction est le seul à avoir un accès direct au composant de données et lui seul peut consulter et modifier ses données et même communiquer avec des serveurs externes si besoin. En conséquence, les composants de modalité doivent se servir du contrôleur comme intermédiaire pour accéder aux données publiques de l'application multimodale.

En revanche, pour le stockage des données privées, chaque composant de modalité peut implémenter son propre composant de données qui lui-même peut accéder aussi à des serveurs externes B et garder les données dont le composant de modalité peut avoir besoin, par exemple, pour la tâche de reconnaissance de la parole. Ceci peut être un cas d'implémentation du principe des poupées russes de l'architecture MMI.

Protocole de communication entre les différents modules

Dans l'architecture MMI le protocole de communication est asynchrone, bi-directionnel et il est basé sur l'échange de notifications d'événements qui sont levés par le système suite à une action de l’utilisateur ou par une activité interne.

Ce protocole définit le mode de communication et la façon d'établir et de terminer la communication. Dans le cas de cette recommandation, il est reflété dans les Life-Cycle Events. Ce sont des événements de contrôle de base qui sont proposés pour la commande des dispositifs et services matériels (par exemple un lecteur vidéo ou un appareil de reproduction sonore) et des notifications pour le monitoring de l'état du système multimodal.

Les événements définis dans l'architecture MMI

Les événements de base (Standard Life-Cycle Events)

La spécification propose huit Life-Cycle Events de base qui sont spécifiés sous la forme des paires d'échanges Request > Response:

• NewContext ( NewContextRequest / NewContextResponse )

Indique la création d'un cycle d'interaction (un contexte) entre zero, un ou plusieurs utilisateur avec une modalité ou plusieurs modalités. Le contexte représente la période la plus longue d'interaction pendant laquelle les modules doivent garder l'information.

Le contexte est associé à la sémantique de l'activité de l'utilisateur et du système pendant le cycle d'interaction; ceci permet de décider si garder l'information a encore un sens en vue du déroulement de l'activité courante.

Généralement le contexte est crée à partir d'une entrée utilisateur. L'évènement est normalement envoyé par un ou plusieurs composants de modalité au contrôleur d'interaction qui devrait répondre à la requête.

Imaginons par exemple, un composant de modalité chargé de gérer les entrées associées au déplacement du doigt (touchmove) dans une page web lue sur un ecran tactile. Lors du démarrage de l'interaction le composant de modalité enverra la requête:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:newContextRequest requestID="myReq1" source="myPointerMC.php" target="myIM.php" data="myMCStatus.xml" />
</mmi:mmi>

A cette requête le contrôleur d'interaction donnera comme réponse:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:newContextResponse requestID="myReq1" source="myIM.php" target="myPointerMC.php" context="myContextID1" status="success" />
</mmi:mmi>

Il est aussi possible que le contrôleur d'interaction soit a l'origine de la requête. Dans ce cas la syntaxe reste la même mais la valeur des propriétés source et target doit changer.

• ClearContext ( ClearContextRequest / ClearContextResponse )

Envoyé par le contrôleur d'interaction, l'évènement indique la fin du cycle d'interaction (le contexte) et demande la libération des ressources qui étaient allouées au contexte d'interaction courant. L'évènement ClearContext peut être associé à la fin de l'activité de l'utilisateur ou du système. Par exemple :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:clearContextRequest requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" />
</mmi:mmi>

Lors de la réception de la requête le composant de modalité peut donner comme réponse:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:clearContextResponse requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" status="success" />
</mmi:mmi>

• Prepare ( PrepareRequest / PrepareResponse )

Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il doit se préparer pour le démarrage de sa tâche et qu'il peut charger les données qui seront nécessaires à l'exécution de la même. Par exemple :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0" xmlns:svg="http://www.w3.org/2000/svg">
   <mmi:prepareRequest requestID="myReq3" source="myIM.php" target="myDisplayMC.php" context="myContextID2" >
       <mmi:content>
           <svg:svg width="100%" height="100%" version="1.1">
              <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
           </svg:svg> 
       </mmi:content>
   </mmi:prepareRequest>
</mmi:mmi>

S'il y a plusieurs documents ou données à charger lors de la phase de préparation, le contrôleur d'interaction pourrait déclencher plusieurs fois l'évènement PrepareRequest sans pour autant démarrer la tâche après chaque envoi. Néanmoins, à chaque envoi il devra recevoir une réponse. Dans notre exemple, si le contenu a été correctement préchargé la réponse est :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:prepareResponse requestID="myReq3" source="myDisplayMC.php" target="myIM.php" status="success" context="myContextID2">
    </mmi:prepareResponse>
</mmi:mmi>

• Start ( StartRequest / StartResponse )

Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il peut démarrer sa tâche. Par exemple :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startRequest requestID="myReq4" source="myIM.php" target="myPlayerMC.php" context="myContextID3" data="myPlayerParams.xml">
        <mmi:contentURL href="myAnimation.swf"/>
    </mmi:startRequest>
</mmi:mmi>

Si pendant l'exécution de sa tâche le composant de modalité reçoit un nouvel évènement StartRequest il peut, soit démarrer au nouveau sa tâche, soit signaler l'échec. Dans le cas d'une exécution réussie la réponse doit être:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startResponse requestID="myReq4" source="myPlayerMC.php" target="myIM.php" status="success" context="myContextID3">
    </mmi:startResponse>
</mmi:mmi>

Dans le cas d'un échec la réponse peut être, par exemple:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startResponse requestID="myReq4" source="myPlayerMC.php" target="myIM.php" status="failure" context="myContextID3">
         <mmi:statusInfo>
         NoContent
         </mmi:statusInfo>
    </mmi:startResponse>
</mmi:mmi>

• Cancel ( CancelRequest / CancelResponse )

Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit arrêter le processus en cours. Par exemple :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:cancelRequest requestID="myReq5" source="myIM.php" target="mySpokerMC.php" context="myContextID4" Immediate="true"/>
</mmi:mmi>

La réponse du composant de modalité peut être:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:cancelResponse requestID="myReq5" source="mySpokerMC.php" target="myIM.php" context="myContextID4" status="success" data="myMCStatus.xml"/>
</mmi:mmi>

• Pause ( PauseRequest / PauseResponse )

Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit mettre en pause le processus en cours. Par exemple, la requête pour une composant qui gère les entrées d'une tablette graphique peut être:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:pauseRequest requestID="myReq6" source="myIM.php" target="myWriterMC.php" context="myContextID5" immediate="false"/>
</mmi:mmi>

Et la réponse du composant de modalité peut être:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:pauseResponse requestID="myReq6" source="myWriterMC.php" target="myIM.php" context="myContextID5" status="success" data="myMCStatus.xml"/>
</mmi:mmi>

• Resume ( ResumeRequest / ResumeResponse )

Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit reprendre la tâche précédemment mise en pause par un évènement Pause.

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:resumeRequest requestID="myReq7" source="myIM.php" target="myWriterMC.php" context="myContextID5"/>
</mmi:mmi>

La réponse du composant de modalité peut être:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:resumeResponse requestID="myReq7" source="myWriterMC.php" target="myIM.php" context="myContextID5" status="success"/>
</mmi:mmi>

• Status ( StatusRequest / StatusResponse )

Il est envoyé indifféremment par le contrôleur d'interaction ou par les composants de modalité. Cet événement indique si le cycle d'interaction est encore en cours, c'est-à-dire, si le contexte est "en vie". Par exemple, un composant de modalité peut avoir besoin de surveiller l'état du système pour arrêter un processus en cas de faille ou mise en veille du système. Dans ce cas, il peut envoyer cette requête au contrôleur d'interaction :

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:statusRequest requestID="myReq8" source="myRecorderMC.php" target="myIM.php" requestAutomaticUpdate="true" />
</mmi:mmi>

Etant donnée que la requête n'indique pas le paramètre context, le contrôleur d'interaction doit fournir l'état du système ou du serveur hôte et pas du contexte courant d'interaction. A cette requête le contrôleur d'interaction peut donc donner comme réponse:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:statusResponse requestID="myReq8" source="myIM.php" target="myRecorderMC.php" status="alive" AutomaticUpdate="true" />
</mmi:mmi>

Les notifications

La spécification propose aussi deux types de notifications dont une, l'Extension Notification, peut contenir des données de contrôle ou de commande des dispositifs ou services matériaux et pour cette raison cette notification est considérée comme un évènement de base qui exceptionnellement n'est pas décrit comme une paire Request > Response (dans des version précédentes il était appelé l'évènement data). Ces deux notifications sont:

• Extension ( ExtensionNotification )

Cet évènement est utilisé pour communiquer des données de contrôle spécifiques à chaque application. Il peut être généré par le contrôleur d'interaction ou par l'un des composants de modalité indifféremment. Il assure l'extensibilité de l'architecture, dans le sens de donner une API générique dédié aux besoins propres des applications. Par exemple, un composant de modalité qui gère un lecteur DVD peut indiquer au système l'interaction avec le menu principal:

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:extensionNotification requestID="myReq9" source="myPlayerMC.php" target="myIM.php" context="myContextID6" name="playerNavigation">
     <applicationdata> 
         <data id="menu" selected="true" />
     </applicationdata>
     </mmi:extensionNotification>
</mmi:mmi>

• Done ( DoneNotification )

Cette notification est envoyée par le composant de modalité au contrôleur d'interaction dès qu'il a fini sa tâche. Par exemple, lorsque un composant de modalité a fini sa reconnaissance d'image (un visage):

<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:doneNotification requestID="myReq10" source="myDetectorMC.php" target="myIM.php" context="myContextID7" status="success">
         <mmi:data>
           <data id="detectionList">
               <users>
                   <user id="u58" confidence=".85" />
                   <user id="u32" confidence=".75" />
                   <user id="u87" confidence=".60" />
               </users>
           </data>
         </mmi:data>
     </mmi:doneNotification>
</mmi:mmi>

References

Références Externes

Standards et notes du W3C associés à cette recommandation

MMIF: Multimodal Interaction Framework (en) par James A. Larson, T.V. Raman and Dave Raggett, Ed., W3C, 2003. Cette note du W3C propose un framework qui identifie de manière abstraite les principaux composants d'un système multimodal. Ce framework est une base pour développer des applications multimodales en termes de langage de description à utiliser, les scripts, les styles et d'autres ressources utiles.

SCXML: State Chart XML. A State Machine Notation for Control Abstraction (en) par Jim Barnett et al. Ed. W3C, 2006. C'est un langage de machine à états à usage général basé sur des événements. Il peut être utilisé : comme un langage de contrôle de dialogue invoquant différents types de reconnaissance; comme un métalangage d'application vocale qui peut également contrôler l'accès à des bases de données et des modules de logique métier; comme un langage de contrôle multimodal combinant les dialogues VoiceXML avec des dialogues dans d'autres modalités, y compris le clavier, la souris, l'encre, la vision, les dispositifs haptiques, etc; comme un langage de gestion de centre d'appels étendu et finalement comme langue de contrôle de processus généraux dans d'autres contextes ne comportant pas de traitement de la parole.

CCXML: Voice Browser Call Control Version 1.0 (en) par R.J. Auburn Ed., W3C, 2005. CCXML permet de contrôler les appels vocaux dans des systèmes de dialogue capables de gèrer divers médias comme c'est le cas des systèmes utilisant VoiceXML.

EMMA: Extensible Multimodal Annotation markup language (en) par Michael Johnson et al. Ed., W3C, 2005. Format XML pour annoter l'interprétation des entrées utilisateur avec des informations spécifiques à chaque application telles que le taux de confiance, l'horodatage, la modalité d'entrée et les hypothèses utiles pour la reconnaissance des données saisies.

MMIUse: Multimodal Interaction Use Cases (en) par Emily Candell and Dave Raggett, Ed., W3C, 2002. Cette Note du W3C décrit plusieurs cas d'utilisation pour l'interaction multimodale et les présente en termes de capacités de l'appareil variables et les événements nécessaires à chaque cas d'utilisation de coupler les différentes composantes d'une application multimodale dans laquelle il est possible d'interagir avec de multiples modalités, par exemple, en utilisant la parole, l'écriture, des raccourcis, des commandes vocales et avoir une sortie sonore et visuelle en retour.

SMIL: Synchronized Multimedia Integration Language Version 2.1 (en) par Dick Bulterman et al. Ed. W3C, 2005. Langage qui permet d'écrire des présentations multimédias interactives en décrivant le comportement temporel de la présentation, en associant des liens hypertextes aux médias et en décrivant la disposition de la présentation sur l'écran. Il apporte aussi de la temporisation et de la synchronisation à d'autres langages qui en ont besoin.

VoiceXML: Voice Extensible Markup Language Version 2.0 (en) par Scott McGlashan et al. Ed., W3C, 2004. Il permet de créer des pages avec lesquelles on intéragit avec la voix et le son. Il permet la création de dialogues entre l'utilisateur et la page web avec une voix synthétisée, un signal sonore numérisé, une entrée vocale ou une tonalité DTMF.

HTML: HyperText Markup Language Version 4.01 (en) par Raggett et al. Ed., W3C, 1999. Il permet de décrire la présentation et le texte des pages web et d'inclure dans les pages des liens vers des textes complémentaires; des ressources média (images, vidéo, sons) et des ressources média interactifs (formulaires, animations interactives, univers 3D). Cette description est faite avec des balises écrites selon un code structuré et peut être complétée par des informations de style graphique (CSS) ou par une programmation de l'interaction par script (ECMAScript) .

SVG: Scalable Vector Graphics 1.1 (en) par Jon Ferraiolo et al. Ed., W3C, 1995. SVG est un format de fichier qui permet de décrire des ensembles de graphiques vectoriels adaptables.

XMLSig: XML-SignatureSyntax and Processing (en) par Eastlake et al. Ed., W3C, 2001. Permet d'authentifier l'auteur de la page et de garantir son intégrité grâce a la signature numérique des documents XML.

Autres standards associés à cette recommandation

RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 in R. Fielding et al. editors. IETF, 1999.
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels in IETF, 1997.
RFC 2396: Uniform Resource Identifiers in IETF, 1995.

References Académiques

Multimodal Interaction in Distributed and Ubiquitous Computing (en) par Pous, M. et Ceccaroni, L, Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, Barcelona, Spain, 2010.
A Multimodal Interaction Manager for Device Independent Mobile Applications (en) par Wegscheider, F. et al., Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, Barcelona, Spain, 2010.
(en) Adrian STANCIULESCU, A Methodology for Developing Multimodal User Interfaces of Information Systems, Presses universitaires de Louvain, 2008 (ISBN 2874631140) 
A Model for Adaptive Multimodal Mobile Notification (en) par William Brander, Nelson Mandela Metropolitan University, Port Elizabeth, South Africa, 2007.
Providing multimodal context-sensitive services to mobile users (en) par Ardit, C et al., National Event on Virtual Mobile Guides, Turin, Italy, 2006.
Articles présentés dans le Workshop W3C autour de l'Architecture Multimodale et Interfaces du 19-20 Juillet 2004. Sophia Antipolis, France (en)
Mobile Field Data Entry for Concrete Quality Control Information par Irina KONDRATOVA dans Proceedings of the European Conference on Products and Processes Modelling (ECPPM 2004).NRC Publication Number: NRC 47158.

Autres Références Utiles

W3C Drafts New Multimodal Standard (en) par Leonard Klie, speechtechmag, Feb, 17, 2009.
Workshop W3C autour de l'Architecture Multimodale et Interfaces du 16-17 Novembre 2007. Keio University, Japon.
The W3C Multimodal Architecture, Part 2: The XML specification stack. Multimodal authoring with SCXML, XHTML, REX, and more (en) par Gerald MCCOBB, IBM, 31 May 2007.
Multimodal interaction and the mobile Web, Part 1: Multimodal auto-fill. Automatically enter personal information into forms (en) par Gerald MCCOBB, IBM, 15 November 2005.
Multimodal interaction and the mobile Web, Part 2: Simple searches with Find-It How to enable voice access to the Yahoo! local search engine (en) par Gerald MCCOBB, IBM, 06 December 2005.
Multimodal interaction and the mobile Web, Part 3: User authentication. Secure user authentication with voice and visual interaction (en) par Gerald MCCOBB, IBM, 10 January 2006.
Distributed Multimodal Synchronization Protocol (DMSP) (en) par Chris Cross With Contribution from Gerald McCobb and Les Wilson, IBM Corporation, July 13, 2006.
W3C leads a New European Project: Multimodal Web (en) Ercim News, 2004.
Multimodal interaction promises device integration, accessibility, and enhanced communication services (en) Techrepublic, 2003.
Interview to Dr. Deborah Dahl (en) par Paolo Baggia. VoiceXML Italian User Group, July, 2003.

Éditeurs

(en) Multimodal Interaction Activity
(en) Multimodal Interaction Activity dans le site du W3C

• Portail de l’informatique