Infrastructures et redistribution d’IHM

Dans cette catégorie d’infrastructure, j’ai retenu BEACH et Aura

qui visent des objectifs complémentaires : la première, les activités de collaboration dans une salle interactive, la seconde, la migration de l’utilisateur entre lieux sans perdre son travail.

3.1 BEACH

À notre connaissance, BEACH (Basic Environment for Active Collaboration with Hypermedia) [Tandler01] est l’une des toutes premières infrastructures motivées par la mise en œuvre de salles de réunion interactives (smart rooms), en l’occurrence i-LAND [Streitz99]. Le projet i-LAND inclut quatre « roomware »¹⁵ : DynaWall, InteracTable, CommChair et ConnecTable. DynaWall est un mur interactif de près de 5m² qui permet à plusieurs utilisateurs de travailler simultanément, de manière soit indépendante, soit collaborative. InteracTable est une table interactive mobile qui offre à un maximum de six utilisateurs disposés tout autour, le moyen de créer, d’afficher, de discuter et d’annoter des éléments d’information. Les CommChair sont des fauteuils mobiles qui intègrent un ordinateur de type « tablette » avec lequel il est possible d’interagir à l’aide d’un stylet. Enfin, les ConnecTable [Tandler01-2] sont des tables interactives dotées d’un écran également accompagné d’un stylet. Deux ConnecTables disposées côte à côte ont la particularité de mettre en commun leurs ressources interactives : par exemple, leur deux écrans n’en forme plus qu’un. Ainsi, deux ConnecTables mises l’une en face de l’autre deviennent adaptées à un travail collaboratif entre deux personnes se faisant face.

3.1.1 Analyse

La Figure III-5 montre comment BEACH facilite la mise en œuvre de ces roomware.

15 Dans ce contexte, le terme « roomware » désigne des éléments de mobilier augmentés de capacité de calcul.

Figure III-5 Vue générale de l'architecture logicielle de BEACH

BEACH est structuré en 4 niveaux d’abstraction (core layer, model layer, generic layer, module layer) qui facilitent la mise en œuvre des roomware dont la structuration est censée respecter les 5 préoccupations suivantes : interaction model, physical model, UI model, tool model, et document model. Pour simplifier et en reprenant la décomposition Arch qui fait référence en IHM, le tool model et le document model correspondent à l’adaptateur de noyau fonctionnel et au noyau fonctionnel de Arch, mais avec une orientation collecticiel. Le user interface model aborde le problème du remodelage : il a la charge de définir une IHM en fonction des dispositifs cibles. La redistribution d’IHM est gérée par le physical model qui inclut un modèle de la plate-forme physique avec ses ressources d’interaction. Il a la charge de la présentation physique au sens de Arch.

Comme le montre la Figure III-6, cette décomposition fonctionnelle est déployée selon le modèle client-serveur. Chaque PC doit exécuter un client BEACH. Un serveur central, situé sur une machine dédiée, permet la synchronisation et la persistance des données issues des clients répartis sur chaque roomware.

Figure III-6 Les clients BEACH, situés sur chaque plate-forme élémentaire, sont synchronisés par un serveur unique.

La mise en œuvre de ces cinq aspects s’appuie sur les services de base des couches de BEACH. La couche core layer complète les insuffisances des systèmes d’exploitation et des window managers natifs. Elle inclut notamment la gestion des capteurs qui permet de déterminer que deux tablettes sont connectées selon des orientations données. Le core layer inclut la gestion d’objets partagés qui sert notamment au maintien de la cohérence des vues graphiques réparties ou répliquées sur différents écrans, mais aussi, comme le pratique I-AM, les transformations (affines) de ces vues graphiques par l’introduction de wrappers, et la gestion des événements provenant des dispositifs d’entrée gérés par des machines distinctes. La couche « modèle » fournit les classes abstraites nécessaires aux roomware. Par exemple, c’est ici, que sont offerts les mécanismes de création et de mise à jour de vues et de controller (au sens de MVC). La couche « générique » implémente des services d’utilité publique orientée collecticiel et la couche « module » (module layer) permet l’implémentation d’éléments sur mesure pour des tâches applicatives spécifiques. 3.1.2 BEACH en Synthèse

Dans mon espace problème (voir Figure III-7), BEACH couvre la redistribution des IHM au niveau du pixel avec reprise au niveau de l’action physique : comme dans I-AM, le rendu d’un interacteur peut être réparti sur deux écrans contigus. Le remodelage est à la charge du développeur. Comme I-AM, BEACH s’occupe des transformations de la scène graphique pour tenir compte de l’orientation et du couplage des écrans.

Figure III-7 Projection de BEACH dans l'espace problème.

La plate-forme est dynamique mais homogène : toutes les plates-formes élémentaires sont supposées être des stations de travail de type PC. Les ressources d’interaction peuvent être hétérogènes, mais pas au sein d’un roomware. Par exemple, le Dynawall est constitué de plusieurs SmartBoard de taille et de résolution identiques. Il en va de même pour les connectTables composées de deux tablettes identiques. Tous les roomware sont censés avoir été développés dans la technologie BEACH. Autrement dit, des clients développés avec une autre technologie ne peuvent ni s’intégrer au sein d’un système interactif développé avec BEACH, ni bénéficier des mécanismes et outils offerts. Nous sommes donc dans une situation intra-espace technologique et monomodale graphique. Dans le cas des ConnecTables, le couplage dynamique des deux tablettes par rapprochement est un exemple de méta-IHM sans négociation.

Alors que BEACH est une infrastructure pour les activités humaines de collaboration au sein d’une même salle, Aura vise, non pas la collaboration, mais la migration des activités d’une personne d’un lieu à l’autre : une activité d’édition de document peut être commencée en un lieu, suspendue, puis reprise ailleurs. 3.2 Aura

Le projet Aura¹⁶, lancé au début des années 2000 à l’université de Carnegie Mellon, s’appuie sur l’hypothèse suivante : l’attention humaine est devenue la plus précieuse des ressources qu’un système informatique se doit de protéger. Partant de là, l’objectif est de fournir à chaque utilisateur un halo computationel qui le

suit dans ses activités et ceci sans rupture, d’où le nom du projet : Aura personnelle d’informations.

3.2.1 Analyse

La notion de tâche est le concept central de la solution Aura assortie de l’expression de qualité de service. Ici, la notion de tâche désigne une activité humaine, par exemple l’édition de document avec l’écoute de morceau musical. En IHM, une telle tâche serait la racine d’un arbre de profondeur 1 dont les feuilles seraient des applications comme MS Word. Aura procède donc à très gros-grain. L’expression de la qualité de service accessible à l’utilisateur permet de guider le système dans ses opérations de reconfiguration et de reprise. Par exemple, si le contexte le permet, jouer un morceau musical tout en éditant un document, sinon s’en tenir à l’édition de document.

Une tâche Aura est l’unité d’exécution entre contextes d’interaction. Ceci signifie que si l’utilisateur commence l’édition d’un document en un lieu avec MS Word et qu’il s’arrête à la page 24, cette tâche sera reprise automatiquement en un autre lieu ne disposant pas de Word mais d’un autre éditeur avec le document ouvert à la même page, et ceci sans que l’utilisateur ait à faire autre chose que se déplacer : son aura informationnelle le suit de manière transparente de contexte en contexte. La Figure III-8 illustre ce principe. La couche « Task Management » détermine ce dont l’utilisateur a besoin en ce lieu et à cet instant, tandis que la couche « Managed Environment » détermine comment configurer l’environnement pour satisfaire ce besoin. Les modèles de tâches, qui expriment ces besoins à haut niveau d’abstraction, sont partagés entre environnements par le biais d’un système de gestion de fichiers distribués.

Figure III-8 L’aura informationnelle suit l’utilisateur dans ses déplacements [Extrait de Sousa05, p. 10].

La Figure III-9 montre un exemple de modèle de tâche Aura. Cette tâche (l’identificateur 34 la désigne de manière unique dans l’espace de noms de l’utilisateur) comprend deux services : « play

video » (id=1) et « edit text » (id =2). Ces services utilisent un « material » (matériau) c’est-à-dire une ressource d’information. Par exemple, le service « play video » joue le matériau « 11 » qui se trouve être à l’arrêt et au début (cursor = 0). Ce matériau (un film) est visualisé dans une fenêtre d’une certaine taille placée en un certain endroit de l’écran. La réalisation de la tâche Aura 34 peut se faire selon deux configurations : la configuration de nom « all » est préférée à la configuration de nom « only video » : son poids (weight = « 1.0 ») est supérieur à celui de « only video » (weight = « 0.7 »). La configuration « all » spécifie l’exécution des deux services « play video » et « edit text » (désignés par leur id) ouverts sur les deux matériaux fichier vidéo et fichier texte (id respectifs 11 et 21).

On le voit, le niveau d’abstraction d’un modèle de tâche est indépendant des applications effectives. De plus, l’état de reprise (checkpoint) correspond à un état perçu par l’utilisateur : les applications ne sont pas nommées directement, mais accessibles à travers le concept de service et les fichiers sont modélisés sous forme de matériau dont l’état est exprimé en caractéristiques externes (le film vidéo est à l’arrêt et en début). Pour cela, Aura fait une hypothèse forte sur la capacité d’ouverture des applications patrimoniales. Il convient en effet que les applications patrimoniales comme MS Word offrent les bonnes «API» d’inspection en sorte d’élaborer et de maintenir l’état perçu en question.

Figure III-9 Un modèle de tâche Aura [Extrait de Sousa05, p. 29].

Figure III-10 Exemple de méta-desripteur pour la tâche Aura 34 [Extrait de Sousa05, p. 38].

Le modèle de la Figure III-9 sert à l’infrastructure Aura pour la migration de tâche entre environnements. Comme le montre la Figure III-10, ce modèle est complété par un méta-descripteur orienté utilisateur dont certains champs, comme le nom (« review semifinals game ») et date de terminaison prévue (« due = 2/07/04 »), sont spécifiés par l’utilisateur. D’autres, comme

l’historique (lieu d’accès « at home », « at office »), sont maintenus par Aura.

La Figure III-8 montre les principes de l’architecture sur deux nœuds (ou environnements). La Figure III-11détaille l’architecture d’Aura en un environnement selon le modèle composant-connecteur.

Figure III-11 Les composants d’Aura pour un environnement. [d’après Sousa05, p.42].

L’utilisateur interagit avec les applications natives App via leur IHM native. Il interagit aussi avec Aura via une méta-IHM pour définir ses tâches et exprimer ses préférences. La Figure III-12 en donne un exemple. Cette méta-IHM est reliée au composant Prism qui est le représentant de l’utilisateur (proxy).

Figure III-12 Méta-IHM de Aura pour définir une tâche incluant une édition de texte (« edit text » avec les « materials » pubsFormat.doc et paper2004.doc), l’utilisation du web sur citeseer et d’un tableur. La partie droite de l’écran permet de spécifier des préférences.

Prism construit et maintient un modèle de tâche et son méta-descripteur conformément aux spécifications de l’utilisateur (comme illustré par les Figure III-9 et Figure III-10). Il suspend et relance les tâches à la demande explicite de l’utilisateur ou lorsque le « context observer » signale le départ/l’arrivée de l’utilisateur dans l’environnement. Les préférences de l’utilisateur sont traduites en QoS à l’adresse des suppliers (fournisseurs) de

service, wrappers chargés d’interfacer les applications natives « App ». Le « management environment » quant à lui, trace la disponibilité des fournisseurs et met en correspondance les demandes de services et les préférences issues de Prism avec les fournisseurs effectifs. Cette mise en correspondance pose le problème d’alignement entre les espaces de nom utilisés respectivement par Prism et les fournisseurs.

3.2.2 AURA en synthèse

Dans mon espace problème (voir Figure III-13), Aura traite de la redistribution au niveau de granularité « total » : l’unité la plus fine de migration est la tâche qui elle-même correspond à une, voire à plusieurs, applications. Une application (ou configuration d’applications) peut être remplacée par une autre. S’il y a redistribution fine de l’IHM, remodelage ou multimodalité, c’est uniquement le fait des applications natives. L’état de reprise dépend de la finesse des inspections (API) permises par les applications. Il est au moins du niveau tâche. Aura a une bonne couverture du contexte d’interaction en termes de plate-forme (mais pour les services logiciels seulement), utilisateur (en termes d’expression des préférences), et environnement physique (avec le context observer, mais ce composant est peu décrit dans les travaux de Sousa). Aura est clairement inter-espace technologique, mais à gros-grain. Comme le montre la Figure III-12, Aura inclut une méta-IHM de type négociation.

Figure III-13 Aura dans l’espace problème de la plasticité.

En somme, Aura est un middleware dont la force est de permettre à l’utilisateur de retrouver, à moindre effort et selon ses préférences, son aura d’informations alors qu’il change d’environnement. L’unité de migration n’est pas l’application ou partie d’application, mais le desktop ou espace de travail au sens de Rooms [Card87]. Avec ICrafter, l’espace de travail est celui

d’une salle interactive, et cette fois-ci le problème central traité est celui du remodelage.