Infrastructures et remodelage d’IHM

Dans cette catégorie d’infrastructure, j’ai retenu Eloquence pour sa capacité à générer des IHM multimodales en sortie et ICrafter

pour sa vision informatique ambiante. 4.1 Eloquence

Eloquence [Rousseau06] désigne un ensemble d’outils pour concevoir, générer et exécuter des IHM multimodales de sortie capables de remodelage à l’exécution. La Figure III-14 illustre les capacités d’Eloquence.

Figure III-14 Génération de présentations multimodales exprimant l’arrivée d’un appel téléphonique en fonction du contexte d’interaction (d’après [Rousseau06], p.141).

4.1.1 Analyse

L’architecture de l’infrastructure d’exécution reflète un processus de génération organisé en 4 étapes (voir Figure III-15) :

(1) Quelles informations présenter ? Ces informations sont fournies au Gestionnaire des Présentations Multimodales (GPM) par le Contrôleur de Dialogue (au sens de Arch). Le GPM les découpe en unités informationnelles élémentaires. Par exemple, l’« Appel de Cyril Rousseau » en provenance du Contrôleur de Dialogue est découpé en deux unités informationnelles élémentaires : « Appel » et «appelant».

(2) Quelles modalités choisir pour chacune des unités élémentaires d’information ? La réponse revient au moteur d’allocation qui, à partir des informations contextuelles maintenues par le serveur de contexte et d’une base de règles comportementales¹⁷, détermine le couple « modalité-média » qui

17 Exemples de règle (spécifiées par avance par le concepteur d’IHM) : a) si l’unité informationnelle est un appel et si la batterie est faible, alors exclure la

convient (voire plusieurs couples si la redondance est recommandée). Par exemple, le couple « musique-haut parleur » pour dénoter l’événement d’appel et le couple « photo-écran » pour l’unité élémentaire « appelant ». Les modalités sont ensuite recomposées pour reconstituer l’information initiale provenant du Contrôleur de Dialogue. Le Gestionnaire de Présentation Multimodale et l’allocateur de modalité couvrent le niveau Présentation Logique de Arch.

(3) Comment instancier les modalités choisies ? Nous entrons-là dans le niveau Présentation Physique de Arch. Le Gestionnaire de Présentation Multimodale fait appel au moteur d’instanciation qui, aidé des informations contextuelles, décide de l’incarnation des modalités : par exemple la modalité photo est instanciée par la photo de l’appelant complétée d’attributs de niveau lexical (couleur ou Noir et Blanc par exemple) et la musique par La Marseille jouée selon un certain rythme. Ces informations sont fournies au moteur de rendu pour générer l’IHM finale sur les ressources d’interaction de sortie cibles (appelées médium dans la terminologie de Eloquence).

Figure III-15 L’architecture de l’infrastructure d’exécution de Eloquence. (d’après [Rousseau06], p. 156).

(4) Quand l’adaptation doit-elle avoir lieu ? Le Gestionnaire de Présentation Multimodale mémorise la liste des modalités actives. Lorsque le contexte d’interaction change, cette liste est inspectée. Le processus de regénération est repris si l’une d’entre elles n’est plus valide.

modalité photographie et exclure le médium vibreur. b) si l’unité d’information élémentaire est une identité d’appelant, alors utiliser si possible une modalité analogique (NB : une photo de l’appelant est une modalité analogique au sens de Bernsen [Bernsen93]).

4.1.2 Eloquence en synthèse

Dans mon espace problème, Eloquence traite du remodelage multimodal (avec éventuellement la Redondance et l’Equivalence des propriétés CARE). Le remodelage multimodal se pratique au niveau des interacteurs avec reprise au niveau de l’action (mais ce dernier aspect n’est pas clairement exposé dans les travaux publiés). Le contexte d’interaction semble couvrir les trois dimensions – environnment, utilisateur et plate-forme bien que l’infrastructure d’acquisition du contexte ne soit pas détaillée. L’adaptation se fait sans Méta-IHM et la couverture des espaces technologiques est au mieux inter-ET.

Figure III-16 Eloquence dans l’espace problème. 4.2 ICrafter

Contrairement à Eloquence, ICrafter reste centré sur les IHM graphiques conventionnelles de type WIMP. Mais comme i-LAND, ICrafter [Ponnekanti01] cible les salles interactives sans toutefois s’intéresser à la dimension collaborative ni, contrairement à Aura à la reprise de tâche utilisateur suite à un changement de salle. ICrafter vise trois objectifs principaux : l’adaptabilité des IHM au contexte d’interaction (et notamment à la diversité des salles interactives – configuration physique et hétérogénéité des dispositifs d’interaction), la capacité de déploiement de nouveaux services et la capacité d’agrégation de services.

4.2.1 Analyse

Dans la terminologie de ICrafter, un service désigne une application (par exemple, un navigateur Web, MS PowerPoint), mais aussi des dispositifs utilitaires physiques comme une lampe, un scanner, un vidéoprojecteur. L’utilisateur interagit avec les

services au moyen d’appareils¹⁸ (un laptop, un PDA). C’est sur les appareils que sont exécutées les IHM des services. L’agrégation de services, telle que l’entend ICrafter, rappelle la notion de tâche Aura sans toutefois véhiculer la QoS centrée utilisateur : alors qu’Aura choisit dynamiquement les services les mieux adaptés aux préférences de l’utilisateur, dans ICrafter ce choix revient à l’utilisateur par le biais de la méta-IHM de la Figure III-17. La sélection du bouton « Show interface » retourne à l’utilisateur une IHM agrégat, union des IHM des services choisis.

Figure III-17 Méta-IHM permettant à l’utilisateur de choisir les services dont il a besoin parmi les services actuellement disponibles dans la salle interactive.

Figure III-18 Le Gestionnaire d'Interface dans ICrafter. La partie (a) représente les relations entre ce gestionnaire et les autres principaux acteurs logiciels. La partie (b) détaille la structure interne du

Gestionnaire d’Interface.

La génération d’IHM est organisée selon l’architecture logicielle de la Figure III-18-a. Le Gestionnaire d’Interface (Interface Manager) en est l’élément central. À la réception de la requête

initiée par l’utilisateur depuis l’appareil où s’exécute la méta-IHM de la Figure III-17, le Gestionnaire d’Interface sélectionne le générateur d’IHM idoine et renvoie à l’appareil demandeur l’IHM produite. La Figure III-18-b détaille la structure interne du Gestionnaire d’Interface.

Comme le montre la Figure III-18-b, les générateurs sont répertoriés dans une base de données centrale. À la réception d’une requête de génération d’IHM, le « Sélecteur de Générateur » y choisit le générateur adéquat qu’il transmet à un « Processeur de Générateur » chargé de mettre en œuvre la génération proprement dite. Le processus de génération s’appuie pour cela sur les connaissances suivantes :

- Description de l’appareil à l’origine de la requête. Cette description inclut notamment l’ensemble des langages et interprètes exécutables sur cet appareil (par exemple, html et un navigateur Web). La description est transmise lors de la requête initiale faite au Gestionnaire d’Interface ;

- Définition des services logiciels disponibles (en gros, leur API). Les services disposent d’un médium de diffusion¹⁹ pour annoncer périodiquement leur présence ;

- Description de la configuration de la salle interactive : localisation physique et dimensions des différents dispositifs utilitaires équipant la pièce (par exemple, localisation des sources lumineuses et des tableaux), informations d’ordre sémantique sur ces utilitaires (« Ecran Z est l’écran central ») ou encore expression de relations entre ces utilitaires (« Projecteur X projette sur Ecran Y »). Cette description est répertoriée dans une mémoire commune de type t-uple space appelée « Context Memory ».

Toutes ces connaissances sont représentées dans des langages « maison » non-standard, mais fondés sur XML (par exemple, SDL pour la description des services). La Figure III-19 illustre le processus de génération d’une IHM pour le service « Projecteur » demandé par l’utilisateur depuis un appareil équipé d’un navigateur Web. La description du service « projecteur » indique l’existence de l’opération « input » dont l’exécution permet de changer l’allocation du projecteur vidéo à l’un des ordinateurs connectés (partie a). La mémoire de contexte (partie b) décrit ProjectorService1, un exemplaire de service « projecteur ». Le sélecteur de générateur choisit le générateur d’IHM adapté aux

19 « Broadcast medium » dans le texte original. C’est un médium sur lequel toutes les entités logicielles sont capables d’écouter. Ainsi, un message émis par un service peut-être reçu par tous les générateurs.

services de type « projecteur » et lui passe le paramètre $serviceName (partie c). Au moyen de ce paramètre, le générateur récupère l’information de configuration dans la mémoire de contexte et produit le code html de la partie d. Ce code est transmis à l’appareil à l’origine de la requête. Son interprétation par le navigateur de l’appareil engendre l’IHM finale de la partie e.

La partie e de la Figure III-19 montre un exemple de générateur d’IHM. Tous les générateurs disponibles dans ICrafter sont exprimés sous forme de template qui incluent des scripts Python ou Tcl pour accéder à la mémoire de contexte et aux descriptions de service. Quand le générateur est exécuté, les scripts sont remplacés par leurs résultats de sortie. Les templates peuvent être génériques ou spécifiques : un template générique est capable de produire une IHM pour plusieurs classes de services mais pour une seule classe d’appareils cibles. Un template spécifique produit une IHM pour une seule classe de services, mais pour des classes d’appareils cibles éventuellement distinctes.

Figure III-19 Illustration du processus de génération d’IHM dans ICrafter pour un service « projecteur » demandé depuis un appareil équipé d’un navigateur Web [D’après Ponnekanti01, p.11].

L’exemple de la Figure III-19 correspond au cas où l’utilisateur a choisi un seul service. Si comme le montre la Figure III-17, l’utilisateur retient plusieurs services, et si, parmi les services sélectionnés certains sont du type producteur et consommateur (de données), le Gestionnaire d’Interface présente également à l’utilisateur l’ « IHM des flux de données »²⁰ de la Figure III-20 qui lui permet de lier les services producteurs aux services consommateurs.

Figure III-20 Méta-IHM pour spécifier les flux de données entre services de type producteur-consommateur.

L’IHM des flux de données montre une vue de dessus de la salle interactive et localise sur cette vue la position des différents services qui intéressent l’utilisateur. Par glisser-déposer, l’utilisateur configure les connexions entre les sorties des services producteurs et les entrées des services consommateurs.

4.2.2 ICrafter en synthèse

La Figure III-21 situe ICrafter dans mon espace problème. ICrafter ne traite pas la redistribution d’IHM puisque le processus de génération d’IHM cible un appareil à la fois – celui d’où émane la requête de génération. Le remodelage d’IHM est entièrement externe aux services. L’avantage est de faciliter le déploiement de nouveaux services par réutilisation de générateurs génériques, mais aussi la génération d’IHM agrégat dans laquelle figurent des informations contextuelles (comme la représentation de relations spatiales entre des services physiques). L’existence de générateurs spécialisés permet d’envisager du remodelage à tous les niveaux d’abstraction, y compris du remodelage intermodal. Inversement, les services qui incluent leur propre IHM (tel MS Word) échappent aux mécanismes de remodelage de ICrafter.

20 Data movement UI.

ICrafter ne traite pas le problème de la reprise : la granularité de l’état de reprise est celui de la session. Toutefois, le déploiement d’IHM est commandé dynamiquement sous le contrôle de l’utilisateur grâce à une méta-IHM de négociation générée de la même façon que les autres IHM. Il s’agit donc de méta-IHM plastique (mais remodelage seulement) avec adaptation à l’environnement physique (grâce à la mémoire de contexte) et à l’appareil cible. Deux appareils pouvant offrir des espaces technologiques différents (rappelons que la description d’un appareil inclut la liste des langages d’expression des IHM avec leur interprète), les IHM générées via ICrafter peuvent être exprimées dans des espaces technologiques différents. Sur ce point, ICrafter est de niveau inter-ET.

Figure III-21 Projection d'ICrafter dans l'espace problème.