Infrastructures logicielles pour Interfaces Homme-

Machine plastiques

Anne Roudaut

Sous la responsabilité de

Joëlle Coutaz et Lionel Balme

CLIPS, IIHM

Année 2004-2005

- 2 -

- 3 -

Sommaire

• Introduction

1. Sujet et contexte 2. Objectifs et approche 3. Organisation du mémoire

• Chapitre 1 : Etude de l’état de l’art

1. Définition des critères d’évaluation 2. Synthèse d’évaluation

• Chapitre 2 : Analyse détaillée de CAMELEON-RT

1. Le modèle CAMELEON-RT 2. Analyse

• Chapitre 3 : Etude d’ETHYLENE

1. L’implémentation ETHYLENE 2. Etude sur un cas concret

• Chapitre 4 : Analyse critique d’ETHYLENE

1. Les points faibles 2. Révision d’ETHYLENE

• Conclusion • Annexes

- 4 -

- 5 -

Introduction

1. Sujet et contexte

Ces travaux de recherche s’inscrivent dans le domaine naissant de l’informatique ambiante avec, comme sujet d’étude, les infrastructures logicielles pour les Interfaces Homme Machine (IHM) plastiques. L’objectif est double : fournir une évaluation détaillée des infrastructures logicielles existantes pour IHM plastiques et mettre à profit les résultats de cette analyse pour améliorer l’infrastructure logicielle CAMELEON-RT développée au laboratoire CLIPS dans l’équipe IIHM.

L’informatique ambiante correspond à une nouvelle vision de l’informatique que l’on doit à Mark Weiser [1]. L’un des principes de cette vision est que l’interaction avec un ordinateur n’est plus confinée à la seule station de travail conventionnelle, mais peut avoir lieu dans un espace d’interaction configurable à façon, constitué d’une multitude d’ordinateurs enfouis et interconnectés. De nombreux scénarios sont alors envisageables. Par exemple « Pierre, à son domicile, souhaite réserver un hôtel pour les vacances. Alors qu’il

entreprend sa réservation sur son PC, il se souvient qu’il a un rendez-vous d’affaires. Il migre le site

de réservation sur son PDA et continue la réservation sur le PDA tout en prenant le bus pour se

rendre au lieu du rendez-vous. » Ou encore « Julie est en train de traiter un message à partir de son

PDA, mais la batterie faiblit. Le système détectant la proximité d’un ordinateur, migre le courriel du

PDA vers l’ordinateur. Julie peut reprendre l’écriture de son message là où elle l’avait interrompue. »

L’essor des technologies est le moteur de cette évolution : miniaturisation, généralisation des réseaux dans fils et avancée des capteurs on fait que les dispositifs physiques sont à présent performants et très hétérogènes. Cependant les IHM destinées à l’informatique traditionnelle doivent acquérir de nouvelles propriétés pour s’adapter à ces nouveaux dispositifs et satisfaire aux exigences de l’informatique ambiante. Dès lors, en plus d’être utiles (adaptées aux besoins de l’utilisateur) et utilisables (adaptées aux capacités de l’utilisateur et à l’environnement physique), les IHM se doivent d’être plastiques. La plasticité d’une IHM est sa capacité de s’adapter au contexte d’interaction. On entend par contexte d’interaction, le triplet « utilisateur, environnement physique et la plate-forme d’exécution ». À son tour, la plasticité d’une IHM s’appuie sur les capacités suivantes :

• Distributivité : les éléments constitutifs de l’IHM peuvent être répartis sur plusieurs dispositifs (par exemple, une fenêtre de PC est projetée sur un mur tandis que le contenu est manipulé via des boutons de contrôle affichés sur un PDA).

• Migrabilité : tout ou une partie de l’IHM peut dynamiquement changer de dispositif (comme dans le cas du système de réservation de Pierre ou du courriel de Julie).

• Remodelabilité : l’IHM est capable de changer de forme. La conception et la mise en œuvre d’IHM plastiques est une tâche très difficile puisque les situations sont infinies. En réponse, deux stratégies techniques sont envisageables :

- 6 -

• Réaliser des systèmes ad hoc qui offrent une solution adaptée à un problème ou à un ensemble de problèmes bien cernés. Par essence, cette solution manque de flexibilité et ne répond pas au caractère évolutif des technologies et des besoins.

• Réaliser des infrastructures logicielles flexibles qui fournissent des services génériques pouvant satisfaire de nombreuses, voire toutes, les combinaisons possibles de configurations.

C’est cette seconde approche que nous retenons dans cette étude. Une infrastructure logicielle est un intergiciel qui s’exécute continuellement et qui fournit des services d’utilité publique à un ensemble d’applications. Corba est une infrastructure logicielle qui permet à des applications développées dans des langages différents de communiquer entre elles. Jini est une infrastructure logicielle assurant la découverte automatique de services en Java. Pour les IHM en informatique ambiante, ces infrastructures se révèlent très utiles puisque les IHM peuvent être (re)distribuées ou migrer entre différentes machines et que leurs ressources d’interaction nécessitent d’être découvertes dynamiquement. En vérité, l’IHM a ses propres requis que les infrastructures générales actuelles ne sont pas nécessairement en mesure de satisfaire. Dans ces conditions, il convient de considérer des infrastructures logicielles adaptées au cas des IHM en informatique ambiante. Il en existe déjà une grande diversité. ETHYLENE, objet pratique de cette étude, est l’une d’entre elles.

2. Objectifs et approche La finalité concrète de cette étude est l’amélioration de l’infrastructure ETHYLENE. ETHYLENE est une implémentation selon le modèle d’architecture conceptuel CAMELEON-RT [2]. Cette infrastructure a été conçue pour faciliter la mise en œuvre d’IHM distribuables, migrables et remodelables pour des applications Web. Les besoins en migration, distribution et remodelage qui sont communs à ce type d’applications sont assurés de manière externe par ETHYLENE au lieu de les voir traiter entièrement dans le code de chaque application. Pour fournir une réponse rationnelle aux objectifs posés, il convient en premier lieu de se familiariser avec l’outil ETHYLENE et d’évaluer les propositions de l’état de l’art. Sur ce point, on assiste à une grande diversité d’infrastructures. Dès lors, la définition de critères taxonomiques s’impose. Ainsi, je me propose de procéder comme suit : – Identification des infrastructures logicielles en relation avec l’informatique ambiante. – Définition des requis que doivent satisfaire ces infrastructures, ces requis permettant d’établir un

tableau comparatif des solutions existantes. – Analyse critique du modèle CAMELEON-RT et de son implémentation ETHYLENE au regard

des requis précédents. – Propositions d’améliorations, soit inspirées de solutions existantes, soit nécessitant de nouvelles

contributions. – Validation expérimentale par la mise en œuvre d’une application au-dessus d’ETHYLENE révisée.

- 7 -

3. Organisation du mémoire L’organisation de ce mémoire reflète les étapes de l’approche adoptée. – Le chapitre 1 concerne l’étude de l’état de l’art. Cette étude comprend la définition des critères

d’évaluation ainsi qu’une synthèse des résultats obtenus en appliquant ces critères aux infrastructures répertoriées.

– Le chapitre 2 fournit l’analyse détaillée du modèle CAMELEON-RT au regard des critères définis dans le chapitre 1.

– Le chapitre 3 présente l’implémentation ETHYLENE. Dans ce chapitre sont données mes premières contributions sur ETHYLENE.

– Dans le chapitre 4, une analyse critique d’ETHYLENE est fondée sur l’expérience acquise dans le chapitre 3. Ce chapitre présente aussi les améliorations apportées à ETHYLENE.

– Une conclusion résume les contributions de ces travaux de recherches. On trouvera en annexes : – Un glossaire des termes clefs du domaine. – Le scénario sous forme de scénarimage sur lequel s’appuient mes contributions.

- 8 -

Chapitre 1 : Etude de l’état de l’art Comme énoncé dans l’introduction, il existe une grande variété d’infrastructures logicielles pour l’informatique ambiante. Mener une étude bibliographique m’a permis de lister ces infrastructures et de mettre en évidence leurs divergences et similitudes. Ces éléments ont, à leur tour, servi de base à l’identification de critères comparatifs. À partir de là, il était aisé de produire un espace taxonomique de l’ensemble de l’état de l’art en matière d’infrastructures logicielles pour IHM plastiques en informatique ambiante.

1. Définition des critères d’évaluation Pour dresser un schéma global de fonctionnement des infrastructures logicielles pour l’informatique ambiante, il faut partir de la fonction centrale de toutes ces infrastructures : assurer l’adaptation au contexte d’interaction. Le processus d’adaptation opère selon le cycle de la figure1.

Detection de nouvelle situation

Contexte

d’interaction

Utilisateur

Environnement

Plate-forme

Décision et

action

Rendu

Figure 1. Cycle de base des infrastructures logicielles pour l’informatique ambiante – Le contexte d’interaction sert de point de départ à ce cycle. Il inclut des informations sur

l’utilisateur, l’environnement physique et social, et sur la plate-forme d’exécution. Tout changement pertinent du contexte d’interaction est détecté : arrivée/départ de dispositifs d’interaction ou d’utilisateurs, baisse de la luminosité ambiante, diminution de la batterie d’un dispositif, actions utilisateurs, etc. Ce changement peut conduire à une nouvelle situation.

– La nouvelle situation est analysée afin de décider de l’action à entreprendre : sur panne de batterie d’un PDA, une action possible est la migration des services en cours d’exploitation vers le dispositif disponible le plus proche ; une baisse de luminosité de la pièce amène à allumer les lampes de la pièce ou à augmenter l’éclairage de l’écran, etc.

– L’ensemble des actions possibles étant établi, il s’agit ensuite de choisir l’action (sous contrôle de l’utilisateur), puis de la mettre en œuvre ;

– L’action est rendue perceptible à l’utilisateur en sorte qu’il puisse évaluer (comprendre) le processus d’adaptation.

- 9 -

Les critères de comparaison ont été définis à partir de ce cycle de base. Ils sont au nombre de 13. En voici la description : Multi utilisateur Ce critère est relatif au contexte d’interaction. Les systèmes interactifs peuvent être partagés

par plusieurs utilisateurs de deux manières : - Les utilisateurs agissent sans interagir ensemble mais peuvent partager des données - Les utilisateurs peuvent collaborer dans la même tâche

Tous type d’utilisateur

Ce critère est relatif au contexte d’interaction. Tous les utilisateurs potentiels peuvent utiliser les systèmes interactifs gérés par les infrastructures logicielles. Il n’y a pas de limitation sur l’âge, la profession, la culture et la connaissance des systèmes informatiques.

Adaptation à l’environnement

physique

Ce critère est relatif au contexte d’interaction. L’environnement physique est le premier facteur de changement du contexte d’interaction. L’exemple de la luminosité de l’environnement illustre ce problème. Si la luminosité est faible il faut éclairer. Si elle est trop puissante, fermer des volets ou augmenter le contraste des zones d’interaction visuelles.

Mise à l’échelle Ce critère est relatif au contexte d’interaction. Le terme « informatique ambiante » impose que l’information est diffuse partout dans le monde. La plupart des infrastructures logicielles sont développées en premier lieu pour des espaces clos. Cependant il est impératif qu’elle soit exportable dans tous les lieux et à grande échelle.

Plate-forme hétérogène

Ce critère est relatif au contexte d’interaction. Comme énoncé précédemment, le caractère diffus de l’information implique la construction dynamique d’espaces interactifs constitués de machines interconnectées dont les systèmes d’exploitation peuvent différer (MacOS et Windows, Windows CE et PalmOS). De plus, ces machines sont connectées de différentes façons aux réseaux et peuvent posséder des intergiciels (middleware) hétérogènes. Toutes ces combinaisons de technologies forment des plates-formes hétérogènes qu’il faut savoir gérer pour rendre possible l’exécution d’IHM plastiques.

Tout type de dispositifs

Ce critère est relatif au contexte d’interaction. La diversité des dispositifs va grandissante. En partant du simple téléphone pour aller au PDA ou à l’ordinateur portable, en passant par tous les accessoires comme les appareils photos, vidéo projecteur, tablette digitale … leur nature en terme de ressources interactionnelles est très vaste, sans compter la convergence entre tous ces dispositifs. Il est donc essentiel que les infrastructures logicielles prennent part à ce mouvement en permettant l’interaction avec toutes sortes de dispositifs.

Généralité des rôles des

dispositifs

Ce critère est relatif au contexte d’interaction. L’étendue des dispositifs acceptés par les infrastructures logicielles est importante mais ne suffit pas. Il faut aussi que le rôle des dispositifs soit dynamique. Par exemple, un PDA peut servir à la fois d’outils de visualisation d’informations et d’outils de commande d’autres dispositifs. Le rôle du PDA ne doit pas être contraint par avance, mais être décidé dynamiquement, par exemple sur demande de l’utilisateur.

Détection de nouvelles situations

Ce critère est relatif à la découverte de nouvelles situations. Comme l’indique le cycle de la figure 1, les infrastructures logicielles doivent être pourvues des mécanismes nécessaires à la détection automatique de situations. Elles doivent être dotées de mécanismes d’observation (ou capture) du contexte d’interaction, complétés par des capacités d’interprétation de ces observations. Par exemple, l’utilisateur peut agir sur le système interactif par le biais d’une technique d’interaction (Voir Glossaire), telle que parler ou lever la main. Ces gestes ont un sens. Ils doivent être interprétés pour permettre à l’utilisateur d’intervenir dans le processus d’adaptation.

Migrabilité des interfaces

Ce critère est relatif à l’action. Permettre aux interfaces de migrer d’un dispositif à un autre est un critère primordial. En effet, cette caractéristique participe au caractère diffus de l’information. La migration d’une IHM peut être totale : l’intégralité de l’IHM est transférée sur un autre dispositif. Elle peut être partielle : seulement une partie de l’IHM est transférée. Par exemple, un menu ou une palette d’outils est transféré vers un PDA.

- 10 -

De plus, la migration des interfaces doit pouvoir se faire à plusieurs niveaux de granularité : pixel, interacteur, espace de travail, application. Pour illustrer cette caractéristique, prenons le couplage de surfaces : deux écrans sont mis côte à côte et ne forment plus qu’une seule grande surface. Une application est ouverte sur le premier écran.

- Si la granularité est au niveau pixel, lorsque l’on déplace la fenêtre vers l’autre écran, le mouvement s’effectuera de manière fluide. Chaque pixel est fidèlement reconstruit de part et d’autre des écrans.

- Au niveau interacteur, l’unité est l’interacteur (un bouton par exemple). Il y aura plus de saccades. Lorsque la fenêtre est déplacée vert l’autre écran, cela s’effectue de sorte qu’un interacteur ne soit jamais à cheval sur plusieurs surfaces.

- Au niveau espace de travail, l’unité est l’espace de travail (Une fenêtre, par exemple).

- Enfin au niveau application, l’application n’est jamais séparée entre les surfaces : elle reste centralisée sur une surface.

Adaptation des

interfaces utilisateurs aux

dispositifs

Ce critère est relatif au rendu. La migration de tout ou une partie de l’IHM d’une tâche peut impliquer un remodelage de l’IHM en raison du changement des ressources d’interaction. Par exemple, migrer d’un PC vers un PDA requiert un remodelage suite au changement de la taille de l’écran. Les infrastructures logicielles doivent donc posséder des mécanismes d’adaptation de l’information aux dispositifs. Les composants IHM des applications peuvent être élaborés selon une combinaison de deux méthodes :

- Adaptation interne : Ils sont capables de s’adapter en interne à certaines situations : l’infrastructure fait appel à une base de composants IHM correspondant à des situations prévues par les concepteurs de ces composants. L’adaptation consiste alors à remplacer tout ou partie des composants inadaptés de l’IHM actuelle par des composants répondant à la nouvelle situation.

- Adaptation externe : Pour des situations imprévues, les composants sont capables de signaler à l’infrastructure leur incompétence. Dans ce cas, le rôle de l’infrastructure est de prendre le relais et d’assurer l’adaptation.

Intégration dans

des systèmes interactifs variés

Ce critère est relatif aux caractéristiques physiques de l’infrastructure. L’informatique ambiante, par nature, permet aux utilisateurs d’effectuer tout type de tâche dans toutes sortes d’environnements. Ce qui implique que les systèmes interactifs gérés par les infrastructures logicielles sont de natures variées. Les utilisateurs peuvent autant échanger des données multimédias que surfer sur le Web ou travailler sur Word. Les infrastructures doivent s’intégrer dans ces systèmes interactifs, et continuer à offrir la même qualité de services tout en utilisant les nouvelles possibilités apportées par le système interactif.

Déploiement léger de

l’architecture implémentation

nelle

Ce critère est relatif aux caractéristiques physiques de l’infrastructure. Les dispositifs comme les téléphones portables ont moins de capacité de mémoire et de rapidité de traitement que les PDA et les stations de travail. Il faut donc que les infrastructures logicielles prévoient un déploiement physique du code adapté aux capacités de calcul des plates-formes élémentaires constituant la plate-forme d’exécution.

Délais d’adaptation

Ce critère est relatif aux caractéristiques physiques de l’infrastructure. En IHM, on appelle latence, le temps écoulé entre l’instant où l’utilisateur effectue une action et son effet perceptible en sortie. En IHM plastiques, cette latence dépend du type d’adaptation choisie (rendu) : la migration totale d’une IHM d’une station de travail vers un PDA peut prendre plus de temps que la migration d’une fenêtre sur deux écrans couplés. Dans tous les cas, ce temps ne doit pas être une gêne pour l’utilisateur. L’infrastructure doit respecter cette exigence. À défaut, elle doit connaître le temps prévu pour l’adaptation et en informer l’utilisateur en sorte de le rassurer.

- 11 -

2. Synthèse d’évaluation Le tableau ci-dessous résume mon analyse d’une dizaine d’infrastructures selon les critères qui viennent d’être présentés. Suit une discussion synthétique de ces résultats.

Aur

a

Bea

ch

Cam

eleo

n-R

T

D

ynam

o

Mul

ti cu

rsor

Peb

bles

Pla

sma

Pos

ter

Poi

ntR

ight

Rek

imot

o’s

Pic

k an

d D

rop

Web

Spl

itte

r

Multi utilisateur

Pas collaboratif � Pas

collaboratif � � � Pas collaboratif

Pas collaboratif � Pas

collaboratif

Tous type d’utilisateur � � � � � � � � � � Adaptation à l’environnement physique

� � Mise à l’échelle � � � � � Plate-forme hétérogène ⁄ � � � � � �

Tous type de dispositifs � � � ⁄limité

utilisation de pointeur

Généralité des rôles des dispositifs

� � � ⁄

Détection de nouvelles situations

� � � ⁄ � � �

Migrabilité des interfaces

⁄totale niveau

application ⁄niveau pixel

� ⁄niveau espace

de travail

⁄niveau pixel

⁄niveau espace

de travail

⁄niveau espace de

travail Adaptation des interfaces utilisateurs aux dispositifs

� � � � �

Intégration dans des systèmes interactifs variés

� � � Echange de média � � � � � Web

Déploiement léger de l’architecture

� � � � � � � � Délais d’adaptation � ? � ? � � � ?

� critère satisfait ⁄ critère pas complètement satisfait ? non renseigné

- 12 -

Le tableau ci-dessus montre que toutes les infrastructures considérées sont multi-utilisateurs. En informatique ambiante, la collaboration est un aspect important qu’il s’agisse de collaboration médiée par la machine entre plusieurs utilisateurs, de collaboration entre individus et machines, ou de collaboration entre machines permettant le partage de ressources. Tivoli s’inscrit parmi les premiers systèmes développés dans cet esprit. Tivoli [5] propose le partage d’un grand écran entre plusieurs utilisateurs qui interagissent au moyen de stylets. Cette idée a été poussée plus avant avec Multi-cursor [6] et le Single Dispay Groupware [7] avec le développement de l’application KidPad [8]. KidPad permet à des enfants de jouer ensemble autour d’un même écran en disposant chacun d’une souris, l’écran et la souris étant gérés par un même ordinateur. Dynamo [9] permet l’échange de documents multimédias entre des utilisateurs par le biais d’un grand écran géré par un PC auquel les utilisateurs connectent leurs dispositifs personnels (appareil photo, lecteur mp3, ordinateur portable, etc.). Ces systèmes supposent un travail en collaboration dans un lieu clos. Les projets Plasma Poster Network [10] et CWall [11] assurent le partage de ressources à plus grande échelle. Ils proposent la mise en place de grands écrans interactifs en des lieux publics. Toutes les personnes de la communauté peuvent l’utiliser pour des tâches simples (envoi de mail, recherche d’informations …). Ces panneaux interactifs sont l’avenir des tableaux à punaises. Ils ont déjà été installés dans plusieurs entreprises d’Asie. Un autre élément de progrès est l’amélioration des ressources d’interaction. Par exemple, dans le projet i-Room [12] comme dans I-Land, plusieurs écrans identiques sont disposés côte à côte pour former une grande surface d’affichage. Dans le cas de i-Room, PointRight [13] permet à autant de pointeurs que l’on veut de se déplacer sur les 3 écrans comme s’ils ne formaient qu’un. Mais dans i-Room comme dans i-Land, les plates-formes d’exécution sont homogènes. Avec le « pick and drop » de Rekimoto [14] apparaissent les plates-formes hétérogènes et les premières IHM distribuées. L’utilisateur tient dans la main non-dominante une tablette contenant la palette des outils de dessin, tandis qu’avec le stylet tenu dans la main dominante, il dessine sur un grand tableau. Avec Pebbles [15], on retrouve une idée similaire : l’utilisateur, voire plusieurs utilisateurs, peuvent contrôler les applications d’un écran PC via leur PDA. Avec ces systèmes, émerge une première forme de distribution des IHM entre PC et PDA. Cependant, il n’y a pas encore de migration d’IHM. Avec WebSplitter [16], l’idée de la migration voit le jour (migration des pages Web d’un dispositif à l’autre). La diversité des dispositifs est plus grande que dans le cas des systèmes vus jusqu’ici. Cependant les limites sont encore là dans le rôle et l’étendue des dispositifs. On ne peut pas combiner plusieurs dispositifs entre eux à moins que des règles d’interaction aient étés définies auparavant. C’est une collaboration ad hoc. De ce point de vue, la collaboration de machines à machines est limitée car l’utilisateur ne peut pas faire interagir deux dispositifs quelconques. Aura [17], Beach [18] et Cameleon-RT [2] apportent des éléments de réponse plus complets. Toutefois, Aura comme Beach ne traite pas le cas des plates-formes hétérogènes. Aura ne traite que la migration et celle-ci, on l’a vu, est totale. En synthèse, les infrastructures logicielles pour l’informatique ambiante se caractérisent par une grande diversité. Celles-ci traitent des problèmes variés dont les domaines s’entrelacent souvent. Cependant, aucune d’elles ne traite l’ensemble des problèmes de l’informatique ambiante pour fournir un cadre de développement générique. CAMELEON-RT a été conçue comme réponse à ces lacunes.

- 13 -

Système Hardware

Système interactif

DMR

Chapitre 2 : Analyse détaillée de CAMELEON-RT

1. Le modèle CAMELEON-RT CAMELEON-RT est un modèle conceptuel d’infrastructure logicielle servant de cadre pour la mise en œuvre d’IHM en informatique ambiante. CAMELEON-RT comprend trois couches (voir Figure 2).

Figure 2. Le modèle d’architecture CAMELEON-RT

• Au niveau d’abstraction le plus bas, le matériel et les systèmes d’exploitation natifs

constitutifs de l’espace d’interaction. C’est la plate-forme d’exécution brute. • Au niveau le plus haut, les systèmes interactifs que l’utilisateur exploite dans l’espace

d’interaction. Les IHM de ces systèmes sont supposées organisées en composants (selon le style d’architecture composant-connecteur), facilitant ainsi la reconfiguration dynamique de tout ou une partie de l’IHM.

• Au cœur de CAMELEON-RT, l’intergiciel DMR (Distribution-Migration-Remodelage) comprend :

o L’infrastructure de contexte chargée de la capture du contexte d’interaction au bon niveau d’abstraction sous forme d’observables grâce à des contexteurs.

o Le gestionnaire de plate-forme et sa boîte à outil pour l’interaction. Le gestionnaire de plate-forme cache l’hétérogénéité de la plate-forme brute en un espace de ressources d’interaction normalisées. Il est aux plates-formes hétérogènes, ce que X Window est à la station de travail conventionnelle. La boîte à outil pour l’interaction fournit les

- 14 -

widgets (interacteurs) d’utilité publique adaptés aux IHM distribuées, migrables et remodelables. En particulier, cette boîte à outil est de type Post-WIMP, incluant des widgets déformables et rotatifs, extension des widgets actuels.

o Le gestionnaire d’adaptation est au cœur du processus d’adaptation. Il comprend un identificateur de situation, un moteur d’évolution, et un producteur d’adaptation

correspondant au cycle de la figure 1. Tout changement de valeurs d’observables calculées par l’infrastructure de contexte est reçu par des observateurs (observateur de plate-forme, observateur de l’utilisateur, observateur de l’environnement physique, observateur des

tâches en cours d’exécution par l’utilisateur). Ces observateurs alimentent le synthétiseur de situation qui calcule la situation actuelle. Tout changement de situation est notifié au moteur d’évolution. Celui-ci construit l’ensemble des réactions possibles, en choisit une, et produit un plan à l’adresse du producteur d’adaptation. Et ce dernier est chargé d’exécuter le plan : remplacement/suppression de composants de l’IHM actuelle à partir de composants exécutables de la base de composants. Si, parmi ces composants, certains ne sont pas exécutables, mais sont des descriptions à haut niveau d’abstraction (par exemple, un modèle de tâches), les composants exécutables correspondant sont calculés à la volée par les outils dits de transformation. Par exemple, TERESA [3] génère une IHM à partir d’un modèle de tâche. Inversement, ReversiXML [4] applique une opération d’abstraction (rétro-conception) à un exécutable, puis une traduction vers la cible demandée avant de réifier (génération). Le configurateur du producteur d’adaptation réalise la reconfiguration recommandée.

2. Analyse CAMELEON-RT possède toutes les caractéristiques requises d’une infrastructure logicielle pour les IHM en informatique ambiante. Elle permet à tous type d’utilisateurs d’agir dans un système interactif. Elle s’adapte à l’environnement physique. Elle s’exécute sur des plates-formes hétérogènes et est compatible avec tout type de dispositif. Ces dispositifs n’ont pas de rôles prédéfinis. Les tâches utilisateur sont de tout type. CAMELEON-RT dispose de tous les modules nécessaires pour découvrir et analyser les nouvelles situations et permet les migrations partielles et totales. La granularité de ces migrations est quelconque. Son point fort est l’existence d’un module pour adapter les interfaces utilisateurs aux dispositifs : Une base de donnée contient les composants des interfaces utilisateurs mais en plus un autre module utilise des outils pour recréer dynamiquement des interfaces utilisateurs par des mécanismes de « reverse engineering », traduction et forward engineering. Cependant, certains points ne sont pas traités : – La collaboration de plusieurs utilisateurs dans un système interactif n’est pas prévue. – CAMELEON-RT ne gère pas l’adaptation de l’information mais seulement des interfaces

graphiques. L’éventualité de classer des informations en fonction de groupe d’individu n’est donc pas possibles (Par exemple le contenu d’une page web protégée si l’utilisateur est un enfant).

– CAMELEON-RT n’apporte pas de réponse sur le bon dosage entre adaptation interne et externe lors de la réalisation des composants IHM. Ce point est à étudier.

– Le critère délais d’adaptation n’est pas traité.

- 15 -

Chapitre 3: Etude d’ETHYLENE L’analyse de l’état de l’art a montré que le modèle CAMELEON-RT possède toutes les fonctionnalités requises pour les systèmes de l’informatique ambiante. Cependant CAMELEON-RT est un modèle conceptuel qui ne permet pas toujours de résoudre les problèmes soulevés par l’analyse détaillée. L’étude de l’implémentation EHTYLENE permet, par la pratique, d’apporter des solutions réalistes à certains de ces problèmes.

1. L’implémentation ETHYLENE ETHYLENE correspond à l’implémentation du composant clef de CAMELEON-RT : Le gestionnaire d’adaptation de la couche DMR qui permet les distributions et migrations d’IHM. La figure 3 montre le fonctionnement global d’ETHYLENE sur un exemple de migration d’application entre un écran d’ordinateur et un PDA.

ETHYLENE

BD

ROUTE 66 (Bus de données)

ORDINATEUR DE BUREAU

PDA

Sauvegarde un contexte d’interaction

Figure 3. Fonctionnement global d’ETHYLENE

Route 66 est un bus de données à travers lequel circulent tous les messages XML qui s’échangent entre les composants d’interfaces utilisateur, EHTYLENE et ses différents modules. Les premiers messages qui transitent dans ce bus de données vont provenir des contexteurs [19]. Les contexteurs regroupent un ensemble de capteurs qui vont détecter des changements de situations (arrivée d’un utilisateur, baisse de luminosité …). Les contexteurs envoient des messages contenant ces informations de bas niveau sur le bus logiciel Route 66.

- 16 -

Ensuite, trois observateurs interceptent les messages des contexteurs (suite à abonnement) : - L’observateur de plate-forme qui s’abonne aux messages relatifs à la description de la plate-

forme. - L’observateur d’utilisateur qui s’abonne aux messages relatifs à la description des utilisateurs. - L’observer du système interactif qui s’abonne aux messages relatifs aux tâches en cours dans

le système interactif. Ces observateurs vont synthétiser les informations reçues à un plus haut niveau d’abstraction et en transmettre d’autres sur le bus logiciel Route 66. Par exemple, si l’observateur d’utilisateur sait que l’utilisateur Pierre est arrivé et qu’il travaille sur la machine A, il va renvoyer le message « Pierre travaille sur la machine A ». En plus de renvoyer ces messages, les observateurs enregistrent les informations contextuelles dans une base de donnée qui permet de sauvegarder l’état du contexte. Au plus haut niveau d’abstraction on trouve 4 processus ETHYLENE :

- Le processus correspondant à l’identificateur de situation et le producteur d’adaptation - Le processus correspondant au moteur d’évolution

- Le processus correspondant au gestionnaire de composants qui permet de gérer le stockage des composants

- Un processus MYSQL qui permet d’assurer la sauvegarde des informations du contexte grâce à une base de donnée.

Le synthétiseur de situation s’abonne aux messages envoyés par les trois observateurs. En synthétisant les informations reçues, il détecte l’apparition d’une nouvelle situation puis envoie sur le bus logiciel Route 66 un message décrivant la nouvelle situation. Le moteur d’évolution récupère les messages de description de nouvelles situations provenant du synthétiseur de situation puis les traite en trois phases :

- En analysant ces messages et en observant l’état du système, il produit un ensemble de propositions,

- Ces propositions sont analysées pour détecter des contradictions possibles. Si une contradiction ne peut pas être résolue automatiquement, l’intervention de l’utilisateur est requise.

- Ces propositions sont combinées pour former un plan de (re)configuration qui va être envoyé sur le bus logiciel Route 66.

Le producteur d’adaptation récupère les messages de plan de configuration envoyé par le moteur

d’évolution et exécute ce plan grâce à un message qui décrit comment doit être faite l’adaptation des composants à la nouvelle situation. Ce plan est effectué sur les composants du système interactif. En l’état actuel du développement, le gestionnaire de composant et le moteur d’évolution ne sont pas intégrés au projet ETHYLENE. De ce fait, les mécanismes de recherche et de choix de composants adaptés pour remplacer un composant inadapté, ne sont pas opérationnels. Les applications du système interactif sont donc développées en adaptation interne, c'est-à-dire que le développeur doit prévoir les composants pour toutes les situations.

2. Etude sur un cas concret Le développement d’une application a été pour moi le moyen le plus adapté pour me familiariser avec les mécanismes d’ETHYLENE. Ce chapitre présente le scénario d’usage imaginé ainsi que les travaux réalisés à partir de celui-ci. En annexe est donné le scénario sous forme de scénarimage.

- 17 -

1. Le scénario “Pierre et Marie”

Ce scénario est typique des possibilités de contexte qu’offre l’informatique ambiante. La durée de mon stage m’a permis de réaliser deux portions de ce scénarios : La migration du travail de Pierre sur son PDA et la migration des photos de Marie sur grand écran. Intéressons-nous maintenant à leur développement.

2. L’application de travail de Pierre L’application de travail de Pierre consiste en un site de commande de composants électroniques. Pierre peut commander des composants sur son ordinateur et migrer l’application entière sur son PDA. Sa tâche n’est pas interrompue puisque Pierre retrouve son panier de commande au même point sur le PDA.

Pierre est à son bureau et travaille sur son ordinateur.

- A 16h00 il a rdv avec Marie mais il n’a pas fini son travail. Il

décide de migrer son application sur son PDA pour continuer à

travailler dans le bus.

- Alors qu’il quitte le bâtiment, il rencontre son collègue de

travail Jacques qui veut absolument récupérer des fichiers importants.

Les deux collègues approchent leurs PDA et échangent les fichiers.

Pierre repart pour se rendre chez son amie Marie.

Dans le bus Pierre continue son travail.

- Pierre ne se souvient plus où se situe la rue dans laquelle habite

Marie. Pierre va sous l’abribus devant le mur interactif sur lequel

est affiché un plan de la ville. A l’aide de son PDA, Pierre

communique au mur l’adresse de Marie. L’emplacement s’affiche sur

la carte, et le plan propose alors à Pierre la visualisation de

l’itinéraire. Comme Pierre n’a pas du tout le sens de

l’orientation, il migre cet itinéraire sur son PDA et se rend chez

Marie.

- Une fois arrivé chez Marie, il rencontre Paul. Paul et Marie sont en

train de regarder les photos de vacances de Marie sur son PDA. Pierre

se joint à eux.

- Puis Sylvie arrive chez Marie et veut aussi participer à la

visualisation mais ne voit rien.Marie migre alors les images sur un

grand écran et se sert du PDA pour commander le diaporama.

Les photos passent jusqu’à ce que Pierre en trouve une très belle et

demande à Marie s’il peut la récupérer. Marie accepte et d’un geste,

il migre la photo sur son PDA.

- Alors qu’ils continuent le diaporama, les rayons du soleil viennent

éblouir l’écran ; on ne voit plus rien. Pour résoudre le problème,

les volets peuvent êtres fermés et l’écran peut pivoter. Comme les

utilisateurs ne verront plus les images si l’écran pivote, les volets

sont fermés.

- 18 -

Pour réaliser cette application j’ai d’abord commencé par réaliser les composants des interfaces graphiques en mode non distribué :

- L’interface graphique pour l’ordinateur - L’interface graphique pour le PDA - Le noyau fonctionnel gérant la base de donnée de composants et la base de donnée

modélisant le panier. Ce noyau est commun aux deux interfaces. Ces composants sont réalisés en PHP/MYSQL. Pour intégrer la partie ETHYLENE qui permet la migration de l’application sur PDA, il faut ensuite suivre certaines étapes :

- Il faut tout d’abord que chaque plate-forme (ordinateur et PDA) indique à ETHYLENE leur présence. Dans notre cas, nos deux plates-formes sont des pages PHP lancées sur deux explorateurs. Chaque explorateur possède un numéro d’identification unique. Lorsque le PDA et l’ordinateur se connectent, les pages indiquent à EHTYLENE le numéro d’explorateur sur lequel elle s’affiche ainsi que les caractéristiques de l‘utilisateur.

- Ensuite, il faut s’assurer que l’explorateur qui héberge l’application du PDA est capable de réagir aux messages qu’il reçoit. Les explorateurs actuels ne le peuvent pas en raison du protocole http. C’est pourquoi l’équipe IIHM a mis au point le plastic explorer. C’est un explorer Windows augmenté qui peut charger une page sur demande extérieure (par l’envoi sur socket notamment).

- Enfin, il suffit de rendre possible la migration. Celle-ci est détectée par une technique d’interaction (geste, son …). Dans notre cas c’est le clic d’un bouton. Lorsque l’utilisateur clique sur ce bouton, la page PHP envoie un message XML de changement de plan de configuration à ETHYLENE qui se chargera de réaliser la migration. Ce message contient l’url de l’application version PDA ainsi que le numéro d’explorateur sur lequel l’afficher (Ce numéro d’explorateur est récupéré par l’envoi d’une requête à ETHYLENE).

La figure 4 montre comment s’est effectuée l’intégration de la partie ETHYLENE pour permette la migration de l’application sur PDA.

Message d’information sur l’utilisateur et la plate-forme (numéro d’explorateur) Requete d’information sur les plate-forme et utilisateur présents Message de changement de plan de configuration

Index.php IndexPDA.php

M

Bouton de migration

ORDINATEUR PDA

Serveur PHP

ETHYLENE

Figure 4. Fonctionnement de l’application travail de Pierre

- 19 -

La figure 5 montre les résultats en image.

Figure 5. En haut, l’interface sur ordinateur de bureau, en bas l’interface migrée sur PDA

- 20 -

3. Le visualisateur de photo de Marie Le visualisateur de photo de Marie est aussi une application PHP qui permet de visualiser des photos sur un PDA et de les migrer sur un autre écran, tout en continuant à manipuler le diaporama avec le PDA. Cette application a été réalisée selon les mêmes procédés que l’application de travail de Pierre. La seule différence réside dans le fait qu’en mode distribué, la commande du diaporama reste sur le PDA et seules les photos migrent sur l’écran. Pour rendre cela possible il suffit de modifier le code des boutons de diaporama en mode non distribué. Par exemple, le bouton « suivant » effectue le même algorithme pour chercher la photo suivante, mais en plus il va envoyer un message de changement de plan de configuration à ETHYLENE. Ce message permet d’afficher cette photo sur l’écran et non plus sur le PDA. Les figures 6 et 7 montrent les résultats en image.

Figure 6. Visualisateur en mode non distribué (interface sur PDA)

- 21 -

Figure 7. Visualisateur en mode distribué (visualisation au mur et commande sur le PDA)

- 22 -

Chapitre 4 : Analyse critique d’ETHYLENE L’implémentation d’ETHYLENE ainsi que l’élaboration du projet « Pierre et Marie » ont permis de soulever plusieurs problèmes. La recherche des faiblesses d’ETHYLENE s’est effectuée au regard des critères d’évaluation ainsi que sur ma propre expérience.

1. Les points faibles Les premiers points à aborder concernent les questions restées en suspens lors de l’analyse de CAMELEON-RT, à savoir le délai d’adaptation et l’équilibre souhaitable entre adaptation interne et adaptation externe.

• Le problème du délai d’adaptation reste tel. Cependant une réflexion est à faire au sujet du

déploiement physique d’ETHYLENE. En effet, lors de l’élaboration de mes applications j’ai utilisé un seul processus ETHYLENE qui était lancé sur le réseau. Si on augmente l’échelle de la démonstration, plusieurs processus ETHYLENE doivent être lancés sur le réseau afin de ne pas centraliser les messages XML sur un seul processus. Mais cette multiplication de processus amène aussi une diffusion des informations contextuelles qui se trouveront réparties entre chaque processus. Cela implique donc l’élaboration de nouvelles techniques de communication entre tous les processus ETHYLENE actifs pour échanger des données contextuelles. Ces données sont en très grand nombre dans les milieux réels (mouvements, changement de luminosité, arrivée de nouveaux utilisateurs …) et cela entraîne des coups de gestion des messages qui risqueraient de rendre le système interactif trop lent. L’étude des infrastructures logicielles implique donc une étude approfondie des contextes d’interactions afin de trouver des règles qui minimiseraient les données contextuelles relatives à un contexte d’interaction donné.

• La question sur l’équilibre entre adaptations interne et externe reste pour l’instant sans réponse.

En effet, toutes les applications que j’ai testées ont été réalisées en close-adaptive. Dans ces conditions, il est difficile d’apprécier le bon dosage entre ces deux approches. Les travaux sur les infrastructures logicielles en informatiques ambiantes sont nouveaux et cette question exige, soit des études théoriques avancées (calculs prédictifs de performances) soit le développement par la pratique de nouvelles expériences à grande échelle (ce qui dépasse le cadre de cette étude de magistère).

Lors de mes travaux sur ETHYLENE j’ai constaté deux failles auxquelles j’ai pas pu remédier :

• J’ai tout d’abord remarqué que les messages sont très ciblés sur l’utilisateur ou la plate-forme (« utilisateur 1 connecté », « machine A connectée», «utilisateur 1 commence une tâche sur la machine A » …) et l’environnement est assez oublié. Par exemple, on pourrait avoir une baisse de luminosité dans la pièce qui pousserait l’application à augmenter le contraste de l’interface graphique. Ce cas n’est pas encore prévu dans ETHYLENE. Cependant introduire la gestion totale du contexte d’interaction demande une possibilité de traitement très grande. Comme il est dit précédemment, il est difficile de gérer toutes les données contextuelles. Les contexteurs envoient d’énormes quantités d’information et il faut les filtrer en fonction des contextes d’interaction. C’est pourquoi on pourrait imaginer des

- 23 -

agents logiciels situés dans des lieux clefs (une pièce, un café, devant un plan…). Ces agents filtrent les données contextuelles en fonction du contexte et les transmettent à ETHYLENE. Par exemple, un agent logiciel situé dans une salle de cours ne s’intéressera qu’aux mouvements du professeur et considèrera les élèves comme une seule entité. Ou encore un agent logiciel dans un café va s’intéresser au niveau d’activité et au niveau sonore …etc. Cela permettra de minimiser le flot de données tout en prenant compte du contexte d’interaction.

• Le second point à étudier concerne la structure des messages qui ne sont pas assez généraux.

En effet si on prend en compte toutes les données contextuelles qui peuvent parvenir à ETHYLENE, il faut être capable de toutes les interpréter. Comme on ne peut pas ajouter un nouveau message à chaque nouvelle configuration, il faut imaginer un langage de description qui serait commun à tous les messages échangés sur le réseau ETHYLENE. Pour ce faire il faut classer les éléments du contexte d’interaction qui peuvent envoyer des messages sur leur état. Il y a les utilisateurs, la plate-forme et l’environnement physique qui forment le triplet du contexte d’interaction mais aussi le système interactif qui décrit les tâches en cours d’exécution. Parmi ces 4 éléments, on peut constater qu’ils envoient tous des messages lors d’un chargement d’état. Par exemple, le soleil se couche, la luminosité change d’état ou encore un PDA arrive dans la pièce, la plate-forme s’agrandit … D’autre part, les éléments utilisateurs et tâches peuvent aussi exprimer des souhaits tels que la demande de migration pour l’utilisateur. Au niveau des tâches on peut imaginer des applications possédant une part d’intelligence artificielle qui gère un environnement donné (Par exemple un logiciel d’aide aux enfants qui se déconnecte à partir d’une certaine heure). Cette réflexion est un début pour imaginer un langage à balises de la forme suivante : <Envoyeur = environnement, plate-forme, utilisateur, tâche>

<Identification de l’envoyeur> <Paramètres>

<Action>

Evidemment l’étendue des contextes est énorme. Il est difficile d’explorer toutes les possibilités dans l’état actuel des recherches, C’est pourquoi, créer un tel langage de description est un projet ambitieux.

Pour finir, j’ai recensé quelques failles d’ETHYLENE que je n’ai pas pu résoudre. Elles fourniront cependant des pistes de réflexion pour les versions futures d’ETHYLENE.

• Tout d’abord, le plastic explorer a causé quelques problèmes lors de la démonstration de l’application travail de Pierre. En effet, il n’affiche pas certaines balises html.

• Il n’existe pas de mécanismes d’abonnement simple aux événements du contexte d’interaction.

En effet, dans l’application de travail de Pierre, le bouton de migration pourrait apparaître seulement lorsque le PDA de Pierre est détecté. Dans ce cas, l’application sur l’ordinateur s’abonne aux arrivées de PDA dans la pièce et peut afficher le bouton de migration lorsque le PDA est dans la pièce.

- 24 -

2. Révision d’ETHYLENE L’amélioration apportée à ETHYLENE a pour but d’ajouter des mécanismes d’abonnement à des situations précises du contexte d’interaction telles que l’arrivée ou le départ d’un PDA. Pour réaliser cette modification, des changements ont été apportés à ETHYLENE. La figure 8 présente le nouveau schéma fonctionnel de CAMELEON-RT.

Figure 8. Nouveau schéma du modèle CAMELEON-RT

Dans ce schéma on peut noter l’apparition d’un nouveau module, l’identificateur de situation qui va gérer la reconnaissance de patterns (patrons). Comme nous l’avons vu, ETHYLENE récupère de nombreux messages XML provenant du synthétiseur de situation. Cependant, le système interactif n’a pas connaissance de ces situations et ne peut réagir en conséquence. C’est pourquoi des patterns de situation ont été ajoutés. Un pattern est une description de caractéristiques attendues dans un contexte d’interaction, comme par exemple l’arrivée du PDA qui possède un plastic explorer. Le système interactif va pouvoir s‘abonner à des patterns donnés, et notifier cet abonnement au nouveau module identificateur de situation. Ce module va filtrer les messages envoyés par le synthétiseur de situation. Lorsqu’il détecte des caractéristiques contextuelles conformes aux patterns existants, il exécute la méthode callback déterminée par le système interactif. Pour rendre compte de l’évolution d’ETHYLENE, j’ai appliqué des modifications à l’application travail de Pierre : Lorsque le PDA n’est pas connecté, l’interface graphique de l’application ne possède pas de bouton de migration. A l’arrivée du PDA, une méthode callback est appelée. Celle-ci va recharger le site de travail de Pierre dont l’interface graphique possède un bouton de migration. Par la suite, la migration s’effectue de manière similaire à la première démonstration.

- 25 -

- 26 -

Conclusion Le modèle CAMELEON-RT est un projet qui mobilise de nombreux chercheurs au sein de l’équipe IIHM. A l’état actuel du développement, l’équipe avait besoin d’un état des lieux de ce projet. Ma contribution a été de répondre à ce besoin en fournissant tout d’abord une étude de l’état de l’art afin de valider le modèle CAMELEON-RT, et ensuite d’étudier l’implémentation ETHYLENE en vue de l’améliorer. Ce double objectif a été atteint. J’ai pu constater que CAMELEON-RT est une infrastructure logicielle complète et adaptée aux nouvelles IHM de l’informatique ambiante. Certains concepts sont encore difficiles à cerner, telle que l’équilibre entre adaptation interne et adaptation externe. Mais leurs réponses viendront avec l’expérience et l’avancée de l’informatique ambiante dans le monde. L’étude d’ETHYLENE m’a permis de soulever des problèmes auxquels j’ai proposé des solutions et des éléments de réflexion. Ce travail permet d’une part de rendre compte des acquis d’ETHYLENE, et d’autre part de fournir une aide aux développeurs pour combler les faiblesses restantes. Sur un plan plus personnel, ce stage a confirmé mon envie de continuer dans la recherche en IHM. En effet j’ai pu me rendre compte en réalisant le scénario d’utilisation que dans le domaine de l’IHM, l’imagination n’est pas bornée. Ce domaine ne demande qu’à découvrir de nouvelles techniques d’interaction, de possibilités de couplage de gadgets électroniques en tout genre. Cela demande de la créativité et de l’imagination et ce qui me plaît le plus est le coté ludique et esthétique de ces recherches. Ce que j’apprécie aussi dans le domaine de l’IHM, est que cette science couple la technique de l’informatique avec des techniques d’ergonomie, de psychologie cognitive ou des réflexions sur l’éthique. On étudie autant les systèmes informatiques que les comportements humains afin de répondre au mieux aux besoins de l’homme. Cette dualité est pour moi très intéressante car à chaque projet mené, on acquiert de nouvelles techniques informatiques en étant au plus proche de l’homme et en imaginant les répercutions sur la société. On se projette dans le futur, et dans un futur pas si éloigné qu’il paraît !

- 27 -

REFERENCES [1] http://www.ubiq.com/weiser/ [2] L. Balme, J. Coutaz, A. Demeure, G. Calvary “CAMELEON-RT: a Software Architecture Reference Model for Distributed, Migratable, and Plastic User Interfaces.” Second European Symposium on Ambient Intelligence, EUSAI 04, LNCS 3295, Markopoulos et al, 2004, pp. 291-302. [3] G. Mori, F. Paterno, C. Santoro “Design and Development of Multidevice User Interfaces through Multiple Logical Descriptions.“ [4] L. Bouillon, J. Vanderdonckt “User Interface Reverse Ingineering” [5] E. Ronby Pedersen, K. McCall, T.P. Moran, F.G. Halasz “Tivoli: An Electronic Whiteboard for Informal Workgroup Meetings” [6] G.Wallace, P. Bi, K. Li, O. Anshus, “A Multi-Cursor X Window Manager Supporting Control Room Collaboration” [7] J. Stewart, E.M. Raybourn, B. Bederson, A. Druin “When Two Hands Are Better Than One: Enhancing Collaboration Using Single Display Groupeware” [8] K.M. Inkpen, W. Ho-Ching, O. Kuerderle, S.D. Scott, G.B.D. Shoemaker “«This is Fun! We’re All Best Friends and We’re All Playing.»:Supporting Children’s Synchronous Collaboration” [9] H. Brignull, S. Lzadi, G. Fitzpatrick, Y. Rogers, T. Rodden “The Introduction of a Shared Interactive Surface into a Communal Space” [10] E.F. Churchill, L. Nelson, L. Denoue, A. Girgensohm “The Plasma Poster Network: Posting Multimedia Content in Public Places”” [11] A. Grasso, F. Roulland, D. Snowdon, M. Muehlenbrock, M. Mesenzani, R. Morici “Supporting Informal Communication across Local and Distributed Communities” [12] B. Johanson, A. Fox, T. Winograd “The Interactive Workspaces Project: Experience with Ubiquitous Computing Rooms” [13] B. Johanson, G. Hutchins, T. Winograd “PointRight: Experience with Flexible Input Redirection in Interactive Workspaces” [14] J. Rekimoto, “A multiple Device Approach for Supporting Whiteboard-based Interactions“ [15] B. Myers, H. Stiel, R. Gargiulo “Collaboration Using Multiple PDAs Connected to a PC”

[16] R. Han, V. Perret, M. Naghshineh “Websplitter : A unified XML Framework for Multi-Device Collaborative Web Browsing” [17] J.P. Sousa, D. Garlan, “The Aura Software Architecture: an Infrastructure for Ubiquitous Computing“ [18] P. Tandler “The BEACH Application Model and Software Framework for Synchronous Collaboration in Ubiquitous Computing Environments“ [19] Thèse de G. Rey “Contexte en Interaction Homme-Machin : le conteteur”

- 28 -

ANNEXE 1 : GLOSSAIRE Contexte d’interaction = C’est le triplet composé de l’utilisateur, la plate-forme et l’environnement physique. Adaptation interne = Ce dit d’une application dont les composants IHM sont capables de s’adapter en interne à des situations prévues par les concepteurs de ces composants. Ressource d’interaction = C’est une entité physique qui permet à l’utilisateur de modifier et/ou observer l’état interne d’un système. Les souris et clavier sont des instruments, les écrans sont des surfaces. Technique d’interaction = C’est un geste convenu entre les utilisateurs et le système interactif qui correspond à une action désiré de la part de l’utilisateur. Adaptation externe = Ce dit d’un application dont les composants IHM se trouvant dans une situation imprévue, sont capables de signaler leur incompétence à une infrastructure qui prendra le relais pour assurer l’adaptation. Plate-forme est élémentaire = Une plate-forme est élémentaire quand elle est compose que d’un seul ordinateur. Plate-forme est homogène = Une plate-forme est homogène quand elle est composée de plusieurs ordinateurs présentant des caractéristiques identiques. Plate-forme est hétérogène = Une plate-forme est hétérogène quand elle est composée de plusieurs ordinateurs dont les caractéristiques et les ressources peuvent être de nature différente.

- 29 -

ANNEXE 2: SCENARIO « Pierre et Marie »

- 30 -

- 31 -

- 32 -