Institut National Polytechnique de Grenoble U.F.R...

Institut National Polytechniquede Grenoble

U.F.R Informatique &Mathématiques Appliquées ENSIMAG

I.M.A.G.

ECOLE DOCTORALEMATHEMATIQUES ET INFORMATIQUE

DEA D’INFORMATIQUE :SYSTEMES ET COMMUNICATION

Projet présenté par :

Nicolas Barralon

Interfaces Homme-Machine de Transition

Effectué au laboratoire :

CLIPS-IMAGCommunication Langagière et Interaction Personne Système

Equipe IIHMIngénierie de l’Interaction Homme Machine

Date : le 20 juin 2002

Jury : Joëlle CoutazGaëlle CalvaryJean-Marc VincentPatrick ReignierNabil Layaida

Remerciements

Je tiens à remercier toutes les personnes qui ont permis que cette année de DEA sedéroule de la meilleure façon qui soit.

Je remercie tout particulièrement Joëlle Coutaz, responsable de mon DEA, pour tout letemps qu’elle a su me consacrer, pour ces conseils et orientations précieux, ainsi que son aideinestimable dans la réalisation de ce rapport. J’associe à ces remerciements, Gaëlle Calvary,co-responsable de mon DEA, pour sa gentillesse, son intérêt pour mon projet et son implica-tion dans ce dernier.

Je n’oublie pas tous les membres de l’équipe IIHM, pour leur sympathie, leur bonnehumeur, et pour l’intérêt qu’ils ont porté à mon DEA. Cette équipe est sans cesse grandissante,c’est pourquoi je ne citerai pas nommément tous ses membres, mais je souhaite les remercierpour les très bonnes conditions de travail qu’ils contribuent à créer.

Enfin, un bisou à toute ma famille et particulièrement Cindy, Pierre, Alice et Cathy.

Plan

Chapitre 1 : Introduction .............................................................................. 7

Chapitre 2 : La notion d’IHM de transition et son espace problème ......... 13

Chapitre 3 : IHM de transition : exemples et outils de l’état de l’art ........ 35

Chapitre 4 : IHM de transition : espace de conception et réalisation ........ 57

Chapitre 5 : Conclusion ............................................................................. 73

CHAPITRE 1 Introduction

1. Sujet .................................................................................................................9

2. Justification ......................................................................................................9

3. Objectifs et approche .......................................................................................10

4. Organisation du rapport ...................................................................................11

7

CHAPITRE 1 : Introduction

1. Sujet

Le sujet de cette étude, Interfaces Homme-Machine de transition, s’inscrit dans le domaine del’Interaction Homme-Machine (IHM). L’IHM a pour objectif l’élaboration de théories, de méthodeset de techniques pour la production de systèmes interactifs utiles et utilisables. Par utile, il faut enten-dre des systèmes capables d’offrir les services attendus. Utilisable signifie que les services offertssont accessibles de manière compatible avec les compétences physiques et cognitives des utilisateurscibles. Cette exigence d’utilité et d’utilisabilité implique la coopération de multiples disciplines parmilesquelles la psychologie cognitive. C’est de la psychologie cognitive que nous vient la Théorie del’Action [Norman 1986] qui motive ma recherche sur les IHM de transition.

La Théorie de l’Action modélise l’accomplissement d’une tâche à l’aide d’un système infor-matique sous forme de deux distances : les distances d’exécution et d’évaluation.

• La distance d’exécution représente les efforts cognitifs et physiques que l’utilisateur met en jeupour atteindre le but qu’il s’est fixé. Ces efforts correspondent, en simplifiant, à la constructiond’un plan d’actions et à l’exécution du plan.

• La distance d’évaluation correspond aux efforts cognitifs et physiques nécessaires à la compré-hension de l’état du système, suite à l’exécution du plan d’actions. Il s’agit, pour l’essentiel, d’inte-rpréter l’état observable du système et de le comparer à l’état souhaité avant d’entreprendre unnouveau plan ou corriger le plan en cours.

En d’autres termes, l’utilisabilité d’un système, selon la Théorie de l’Action, se mesure par lesdistances d’exécution et d’évaluation. Il en résulte des principes aujourd’hui largement appliquéscomme celui du “retour immédiat et informatif”. Par exemple, dans l’action de déplacer un objet, lefantôme de l’objet est asservi au curseur de la souris. Dans les éditeurs graphiques, l’action de tracerune figure géométrique est accompagnée d’une forme élastique. Le fantôme et la figure élastique sontdes exemples de retour immédiat qui permet à l’utilisateur d’évaluer l’effet de son action sur l’état dusystème et donc, bien informé, de poursuivre sa tâche dans de bonnes conditions.

Les Interfaces Homme-Machine de transition s’inscrivent dans l’objectif de réduire la dis-tance d’évaluation. Nous en motivons maintenant l’intérêt avec l’adaptation dynamique des Interfa-ces Homme-Machine au contexte d’interaction.

2. Justification

Jusqu’ici, les Interfaces Homme-Machine étaient confinées à l’écran d’une station de travailet envisagées pour une utilisation donnée (typiquement, au bureau ou, pour les bornes interactives,dans un lieu public). Avec les progrès de la technologie sans fil et la miniaturisation des composantsmatériels, l’informatique s’infiltre dans le tissu de nos activités quotidiennes [Weiser 1991]. Il enrésulte que l’hypothèse implicite en conception d’IHM de la plate-forme d’exécution unique et dulieu d’interaction fixe, ne tient plus. En conséquence, l’Interface Homme-Machine d’un système inte-ractif doit pouvoir s’adapter au contexte d’interaction.

9


On entend par contexte d’interaction, l’ensemble des attributs et leurs relations qui caracté-risent le triplet “plate-forme - environnement - utilisateur”.

• Nous reviendrons au chapitre 2 sur la notion de plate-forme. Pour l’instant, considérons qu’il s’agitd’une machine d’exécution (tels un PC, un PDA et un téléphone) avec ses ressources “calcul-mémoire-réseau” et ses ressources d’interaction “clavier-souris-écran”.

• L’environnement désigne le lieu physique dans lequel se situe l’interaction avec ses caractéristi-ques d’ambiance et d’usage social (chez soi, dans le train, au bureau, en forêt, etc.).

• L’utilisateur correspond à la classe prototypique d’utilisateurs envisagée pour le système.

Aujourd’hui, plusieurs équipes (dont l‘équipe IIHM qui m’accueille), travaillent sur les outilsde conception et les mécanismes logiciels nécessaires à l’adaptation des IHM au contexte d’interac-tion [Cameleon]. Les IHM qui s’adaptent au contexte d’interaction tout en conservant leur utilisabi-lité, sont dites plastiques [Thevenin et Coutaz 1999]. Prenons deux exemples simples :

• IHM plastique sensible à l’environnement. Le téléphone mobile, sensible à l’ambiance, suggèreou enclenche le mode “vibreur” parce qu’il détecte qu’il est utilisé dans une réunion.

• IHM plastique sensible au changement de plate-forme. La disposition des informations est réamé-nagée suite au changement d’orientation de l’écran. Ou encore, l’orateur choisit de faire migrerson exposé présenté sur son PDA vers un tableau mural contrôlé par un PC.

• IHM plastique sensible au changement de classe d’utilisateurs. L’utilisateur prête son PDA à unami mal-voyant : la modalité vocale se substitue à la modalité graphique.

Ces quelques exemples illustrent les capacités d’adaptation des IHM futures sans toutefoispréciser comment l’utilisateur est en mesure d’évaluer le changement. Par exemple, dans le cas de lamigration à la volée d’une IHM entre deux plates-formes, comment l’utilisateur sait-il que l’IHMdémarre sa migration, est en cours de migration, puis redevient disponible pour la poursuite du tra-vail? Aujourd’hui, les concepteurs disposent de patrons pour les IHM usuelles, par exemple les for-mes élastiques et les fantômes. Nous n’avons pas l’équivalent pour les IHM à venir. Ce constatjustifie les objectifs de cette étude.

3. Objectifs et approche

L’objectif est d’analyser le changement qui résulte de l’adaptation des IHM aux variations ducontexte d’interaction et d’étudier comment l’IHM d’un système qui s’adapte peut aider l’utilisateur àévaluer cette évolution. J’introduis pour cela le concept d’IHM de transition.

J’appelle Interface Homme-Machine de transition, les composants d’une IHM dont la missionest de réaliser la conduite du changement entre deux états stables du système. Les figures élastiques etles formes fantômes suffisent à exprimer des états intermédiaires pour les cas simples de changementd’état. De même, l’ouverture et la fermeture de fenêtres se manifestent par des animations quidéportent au niveau visuel l’effort cognitif de l’évaluation de l’état du système [Robertson et al.1991]. Avec les IHM envisagées sous la bannière de l’informatique diffuse, il faut, peut être, inventerde nouvelles façons de conduire le changement. La littérature révèle déjà des techniques d’accompa-gnement mais, en l’absence de cadre de conception général, on assiste à des solutions ad hoc.

10


Pour atteindre mes objectifs de généralisation des IHM de transition, je procéderai commesuit:

1. Analyse de la nature du changement : une hypothèse de travail raisonnable est que l’IHM de tran-sition à fournir à l’utilisateur dépend de la cause du changement du contexte d’interaction. Danscette étude, je mettrai l’accent sur les changements de plate-forme. Cette analyse doit aboutir à ladéfinition d’un espace problème, mais doit aussi permettre de cerner le concept même d’IHM detransition.

2. Analyse critique des solutions existantes d’IHM de transition tant du point de vue de l’utilisateurque du point de vue logiciel : quels renseignements fournir à l’utilisateur et quel rendu adopter ?Du point de vue logiciel, quels sont les composants impliqués ? Quelles conséquences sur lesmodèles de référence en architecture logicielle des systèmes interactifs ?

3. Application du travail d’analyse à une étude de cas simple qui valide, au moins en partie, mes pro-positions.

4. Organisation du rapport

L’organisation du rapport traduit la démarche adoptée : Identification de la notion d’IHM detransition et son espace problème : définition formelle et expression des requis selon la double pers-pective : utilisateur et logiciel. C’est l’objet du chapitre 2.

Le chapitre 3 présente l’état de l’art par des exemples d’IHM de transition et propose une cri-tique des outils de mise en œuvre de ces IHM selon la grille d’analyse du chapitre 2. Les constatsd’insuffisance de l’état de l’art conduisent à l’espace solution du chapitre suivant.

Le chapitre 4 propose un cadre utile au choix rationnel de solutions selon les deux perspecti-ves complémentaires de l’étude : utilisateur et logiciel. Pour les aspects logiciels, je propose plusieursapproches selon que le système interactif est responsable ou non des IHM de transition. J’illustrel’une d’entre elles avec la mise en œuvre d’une maquette simple fondée sur la programmation parAspect. Une conclusion résume la contribution et formule un bilan critique vers de nouvelles perspec-tives.

11

CHAPITRE 2 La notion d’IHM de transition et son espace problème

1. Introduction......................................................................................................15

2. Un scénario d’usage.........................................................................................15

3. IHM de transition.............................................................................................163.1 Rappels : tâche utilisateur et Arch ...........................................................16

3.1.1. Tâche..............................................................................................163.1.2. Le modèle Arch..............................................................................17

3.2 IHM de transition : définition ..................................................................173.2.1. IHM de transition élémentaire .......................................................18

3.3 IHM de transition composée....................................................................183.4 Interruptibilité d’une IHM de transition composée .................................20

4. IHM de transition : espace problème ...............................................................214.1 Déclencheur du changement de contexte.................................................224.2 Observabilité d’une transition..................................................................234.3 Nature du changement de contexte d’interaction.....................................23

4.3.1. Plate-forme élémentaire et grappe de plates-formes......................234.3.2. Changement de plate-forme...........................................................27

4.4 Composants système impliqués. ..............................................................31

5. Synthèse ...........................................................................................................32

13

CHAPITRE 2 : La notion d’IHM de transition et son espace problème

1. Introduction

En introduction, j’ai posé le problème de l’adaptation des Interfaces Homme-Machine au con-texte d’interaction. Avec la Théorie de l’Action comme fondement, j’ai introduit la notion d’IHM detransition, sorte de micro-IHM qui doit permettre à l’utilisateur d’évaluer la nature de l’adaptation etd’en suivre l’évolution avant de poursuivre sa tâche.

Dans ce chapitre, nous approfondissons la notion d’IHM de transition. Je propose une analyseen deux étapes : la définition d’une IHM de transition suivie d’une analyse sous forme d’un espacetaxinomique. Les dimensions de cet espace nous permettront de dégager des propriétés et des élé-ments de comparaison entre les outils et solutions techniques présentés au chapitre suivant. Au coursde l’exposé, j’utiliserai l’exemple d’un scénario présenté ci-dessous.

2. Un scénario d’usage

Cathy est chercheuse à l’université. Avec quelques collègues, elle réfléchit à la structure du

prochain article qu’ils vont publier ensemble. Pour cela, ils utilisent le Tableau Magique1, un tableaumural de réalité mixte adapté à la réflexion collective [Bérard 1999]. Le temps imparti à la réunionarrive à son terme. Les collègues doivent partir.

Cathy, qui a encore du temps à consacrer à l’article, s’engage à continuer le travail. Se retrou-vant seule, elle juge plus confortable de poursuivre le travail en position assise avec son calculateurportable. D’un geste, elle commande la migration des inscriptions du tableau vers le portable (laptop).En réponse à la requête de l’utilisateur, le système lance une IHM de transition.

Mais Cathy n’a pas fait attention que le portable était indisponible (le reboot de la machinen’est pas terminé). Le système recherche d’autres ressources interactionnelles disponibles, proches etsemblables, sur le plan interactionnel, aux ressources du calculateur cible demandé. L’IHM de transi-tion propose la Table Augmentée, une surface de réalité mixte horizontale.

Cathy poursuit sa tâche en attendant la disponibilité du portable. Celui-ci prenant du temps,elle décide de faire migrer le tout sur le PDA parce qu’elle a envie de se relaxer au maximum sur sonfauteuil (la table exige une certaine tenue !). Parce que l’écran est petit, seulement un sous-ensembledes services d’édition est disponible. Cathy en est avertie par l’IHM de transition et confirme lademande de migration.

1. Le Tableau Magique permet d’utiliser les feutres usuels, de numériser les inscriptions et de mani-puler ces inscriptions au moyen de ses doigts. Contrairement aux tableaux électroniques usuels, le Tableau Magique permet l’interaction simultanée à plusieurs.

15


Le portable est enfin disponible. Le travail peut migrer du PDA vers la destination initiale-ment désirée. Parce que la surface écran est plus grande que celle du PDA, la présentation de l’IHMest à nouveau adaptée en conséquence. Cathy peut suivre ces changements via l’IHM de transition.

3. IHM de transition

De manière générale, une transition désigne le passage progressif d’un état à un autre. “Detransition, se dit de ce qui ne durera pas, qui est envisagé comme un simple intermédiaire entre deuxétats : Gouvernement de transition” [Larrousse]. Dans les beaux-arts, un style de transition ne com-porte pas encore tous les attributs du style qu’il annonce. De ces définitions, je retiens, pour madéfinition d’IHM de transition, les notions de liaison, de progression, d’étape, d’état initial et d’étatfinal.

A l’évidence, la notion d’état est fondamentale. Il convient donc, pour asseoir notre définition,de préciser ce que l’on entend par “état” pour un système interactif. Pour cela, nous nous appuyonssur des acquis de l’ingénierie de l’Interaction Homme-Machine que je rappelle brièvement ci-des-sous: la notion de tâche utilisateur et le modèle Arch [Bass 1991].

3.1 Rappels : tâche utilisateur et Arch

3.1.1. Tâche

Une tâche utilisateur (ou plus simplement, une tâche) est un but que l’utilisateur se fixe assortide la procédure pour atteindre le but :

• Le but est l’état du système que l’utilisateur souhaite atteindre.

• La procédure est un ensemble de sous-buts liés par des relations temporelles et de composition.

Un modèle de tâche est une représentation hiérarchique de tâches et de sous-tâches. Par exem-ple, la tâche “écrire un article” se décompose en une tâche d’ouverture de fichier (ou de création d’unnouveau document), suivie d’une tâche d’édition, suivie d’une tâche de sauvegarde du document. Ason tour, la tâche d’édition se décompose en un ensemble de sous-tâches répétitives telles que saisirdu texte, dessiner, couper-coller, etc. Une tâche feuille de l’arbre est une tâche élémentaire.

Une tâche élémentaire est une tâche dont la décomposition s’exprime en actions physiques(un clic de souris, une saisie de caractère sont des actions physiques). Par exemple, “sélectionner” estune tâche élémentaire. Une tâche nominale, comme éditer un document, est une tâche qui dépend dudomaine d’application. Son exécution modifie l’état du Noyau Fonctionnel (NF) du système interac-tif. Inversement, une tâche articulatoire, comme réorganiser les fenêtres de l’écran, ne dépend pas dudomaine d’application mais de la nature de l’IHM. Une tâche articulatoire ne modifie pas le NoyauFonctionnel (NF). Nous explicitons maintenant la notion de NF avec le modèle Arch.

16


3.1.2. Le modèle Arch

Arch sert de modèle de référence en architecture conceptuelle des systèmes interactifs [Bass1991]. Comme le montre la Figure 1., Arch propose de structurer un système interactif en cinqniveaux fonctionnels complémentaires :

• Aux deux pieds de l’arche, le Noyau Fonctionnel qui implémente les concepts et les services dudomaine d’application et, à l’autre extrémité, la Présentation Physique (PP) qui présente à l’utili-sateur les concepts et services disponibles et qui lui permet de les manipuler.

• En clef de voûte, le Contrôleur de Dialogue (CD) est chargé de l’enchaînement des tâches nomina-les utilisateur. Ce composant est isolé du NF et de la Présentation Physique par deux adaptateurs:l’Adaptateur du Noyau Fonctionnel (ANF) et le composant de Présentation Logique (PL).

On retiendra que selon ce modèle, l’IHM d’un système interactif est constitué des composantsANF, CD, PL et PP. Ainsi, EIHM, l’état de l’IHM d’un système interactif à l’instant t, est l’union del’état de ses composants EANF, ECD, EPL et EPP à cet instant. De même, l’état E du système interactifà un instant t, est l’union de ENF, l’état de son NF, et de EIHM à cet instant :

EIHM = EANF U ECD U EPL U EPP

E = ENF U EIHM

Figure 1. Le modèle Arch.

Ces rappels faits, nous sommes maintenant en mesure de définir une IHM de transition.

3.2 IHM de transition : définition

Soient Ei et Ef, deux états d’un système interactif et Ti et Tf, les tâches élémentaires nominalesque l’utilisateur accomplit en Ei et Ef respectivement.

Noyau Fonctionnel

Contrôleur deDialogue

PrésentationPhysique

Adaptateur duNoyau Fonctionnel

PrésentationLogique

17


Une IHM de transition Tr entre l’état initial Ei et l’état final Ef, est une fonction qui, sous nchangements de contexte d’interaction C (n>1), assure le passage de Ei à Ef. Elle se note :

Tr [(Ei, Ti), (Ef, Tf), C], où Card(C) > 1

Le passage de Ei à Ef peut se faire en une seule étape (Card(C) = 1): on assiste alors à uneIHM de transition élémentaire. Lorsqu’elle comporte plusieurs étapes, l’IHM de transition est ditecomposée. Par exemple, dans notre scénario, la migration de l’IHM entre le Tableau Magique et laTable Augmentée enclenche une IHM de transition élémentaire. Inversement, la migration entre leTableau Magique et le portable provoque une IHM de transition composée de transitions élémentai-res. Précisons ces deux notions de manière plus formelle.

3.2.1. IHM de transition élémentaire

Soient Ei et Ef, deux états d’un système interactif tels que :

Ei = ENFi U EIHMi et Ef = ENFf U EIHMf

où ENFi est l’état du Noyau Fonctionnel du système en Ei et EIHMi, l’état de l’IHM en Ei et

ENFf est l’état du Noyau Fonctionnel du système en Ef et EIHMf, l’état de l’IHM en Ef.

Une IHM de transition élémentaire notée Tre conserve les états du noyau fonctionnel de mêmeque la tâche élémentaire en cours de l’état initial. Autrement dit, l’utilisateur conserve sa tâche élé-mentaire et le noyau fonctionnel est inchangé ; seule l’IHM a pu subir des modifications dont lanature, on le verra en 4.4, dépend à son tour de la nature du changement du contexte d’interaction. Leprédicat suivant traduit la définition d’une transition élémentaire :

Elémentaire (Tr [(Ei, Ti), (Ef, Tf)] ) => ENFi = ENFf et Ti = Tf et Card(C) = 1

3.3 IHM de transition composée

Dans l’exemple de notre scénario, Cathy souhaite une migration entre le Tableau Magique etson portable. Au lieu de cela, on assiste à un détour à plusieurs étapes : du Tableau Magique (TM) à laTable Augmentée (TA), puis de la table au PDA pour enfin atteindre le portable (OP). Chacune desmigrations enclenche une transition élémentaire. On note que sur la table, Cathy continue son travail.Ce faisant, elle a avancé dans son espace de tâches et par conséquent modifié l’état du noyau fonc-tionnel.

Une IHM de transition composée Tr [(Ei, Ti), (Ef, Tf), C] est une composition de transitionsélémentaires interruptible par l’utilisateur en un point d’interruption. Un point d’interruption setrouve entre deux transitions élémentaires. En raison de cette interruptibilité, une IHM de transitioncomposée ne conserve pas nécessairement la tâche élémentaire initiale Ti et par conséquent, ne con-

18


serve pas nécessairement l’état initial ENFi du noyau fonctionnel. La Figure 2. illustre notre proposavec le scénario.

Figure 2. IHM de transition en relation avec les tâches et l’état du système. On note que sur la Table Augmentée, l’utilisateur a terminé la tâche T1 et est en train de réaliser T2.

Tableau magique

T1 T2 T3

(E1, T1)

Ordinateur portable

T1 T2 T3

Souhait : Tr0

Tableau magique

T1 T2 T3

(E1, T1)

Ordinateur portable

T1 T2 T3

Tr1 = Tre1

Table augmentée

T1 T2 T3

(E1, T1)

Souhait : Tr2

(E2, T2)

Ordinateur portable

T1 T2 T3

Table augmentée

T1 T2 T3

Tre21

(E2, T2)

PDA

T1 T2 T3

(E2, T2)

Tre22

(E2, T2)

Légende :

Trei

Transition Trei effective

Souhait : Tri

Transition Tri souhaitée

L'utilisateur progresse dans la réalisation de ses tâches

T

La tâche T se décompose en deux tâches élémentaires

T1 T2

Tri

Transition élémentaire i

Transition i

Trei

19


L’exemple du scénario se traduit formellement ainsi :

Soit Tr0 une transition mise en place entre (E1,T1) et (E2,T2) :Tr0 = Tr[(E1,T1), ( E2,T2), C0 = CTM→ TA ∪ CTA→ PDA ∪ CPDA→ OP]

Tr0 peut alors se décomposer en Tr0 = Tr2 oTr1 :

Tr1 = Tre1 = Tre[(E1,T1), ( E1,T1), C1 = CTM→ TA]

Tr2 = Tre2 = Tr[(E2,T2), (E2,T2), C2 = CTA→ PDA ∪ CPDA→ OP] = Tr22 o Tr21

Tr21 = Tre21 = Tre[(E2,T2), (E2,T2), C21 = CTA→ PDA]

Tr22 = Tre22 = Tre

[(E2,T2), (E2,T2), C22 = CPDA→ OP]

Au final, nous obtenons : Tr0 = Tr2 oTr1 = Tre22 o Tre

21 oTre1

Une transition composée est représentable sous la forme d’un arbre : elle se décompose ensous-transitions jusqu’à l’obtention de transitions élémentaires. La Figure 3. illustre la décompositionde la transition Tr0 correspondant à notre scénario. On vérifie que les transitions élémentaires sontuniquement des feuilles de l’arbre. L’interruptibilité d’une transition composée appelle quelquesremarques.

Figure 3. Représentation d’une transition composée sous forme arborescente : illustration avec notre scénario.

3.4 Interruptibilité d’une IHM de transition composée

Une IHM de transition composée, nous l’avons vu, est interruptible par l’utilisateur entre deuxtransitions élémentaires. L’interruptibilité d’une transition composée pose le problème théorique determinaison : si Ef est atteignable depuis Ei, l’est-il encore depuis un état intermédiaire atteint sous lecontrôle de l’utilisateur ? Par exemple, dans notre scénario, le système sait qu’il est possible de passerdu Tableau Magique au portable à partir de (E1, T1) via la table et le PDA. Mais sur la table, Bobatteint la tâche T2 qui correspond à un état qui ne permet pas nécessairement de migration.

Tr0

Tr1 = Tre1

Tr2

Tr21=Tre21 Tr22=Tre

22

20


Alternativement, nous pourrions envisager de définir une IHM de transition composée commela composition ininterruptible d’IHM de transitions élémentaires. Ce faisant, nous résolvons notreproblème de terminaison et nous garantissons ENFi = ENFf et Ti = Tf. Inversement, en raison de lapropriété d’ininteruptibilité, la migration initiale de Cathy (du Tableau Magique au portable) setrouve nécessairement décomposée en deux IHM de transition indépendantes. Or, dans l’intention deCathy, la transition entre le Tableau Magique et le portable constitue une unité que l’IHM de transi-tion doit traduire. Par conséquent, il convient que le comportement de l’IHM de transition correspon-dant à la migration entre le tableau et le portable soit cohérent de bout en bout. Si la migration estmodélisée sous forme de deux IHM de transition indépendantes, la mise en œuvre logicielle se trouvesimplifiée (inutile de se souvenir que le but ultime est le portable) au risque cependant de perdre lacohérence de comportement entre les deux IHM de transition.

Dans l’état actuel de la réflexion, le problème de l’interruptibilité d’une IHM de transitioncomposée est laissé ouvert. Ayant fourni la définition d’une IHM de transition, analysons l’espaceproblème qui permet de raisonner plus avant sur cette notion avec ses conséquences ergonomiques etlogicielles.

4. IHM de transition : espace problème

Un espace taxinomique permet de comprendre la nature d’une entité (que ce soit un phéno-mène, une notion, un objet, etc.), d’effectuer des comparaisons entre plusieurs entités, de raisonnersur cet espace (et notamment constater l’absence d’entités en certains points de l’espace), etc. Dans lecas présent, les dimensions de l’espace sont motivées par l’analyse de l’adaptation des IHM à leurcontexte d’interaction et les conséquences sur l’IHM de transition qui en résulte et les outilsnécessaires à la mise en œuvre de cette transition.

La Figure 4. montre les catégories de question qui définissent chacune une dimension del’espace de raisonnement sur les IHM de transition :

1. Qui, du système ou de l’utilisateur, est à l’origine du changement de contexte d’interaction ? Est-cele système ou l’utilisateur ? Dans notre scénario, les deux ont l’initiative du changement de plate-forme : l’utilisateur provoque la migration de plate-forme (du Tableau Magique vers le portable),mais au cours de la transition, le système propose une étape intermédiaire vers la Table Aug-mentée. Nous élaborons ce point en 4.1.

2. Quel que soit l’acteur déclencheur de la transition, l’IHM de transition est-elle observable par l’uti-lisateur ? L’absence de retour système correspond au cas où le système n’assure pas la conduite duchangement avec, comme conséquence, une surcharge cognitive pour l’utilisateur qui n’a aucunmoyen d’évaluer l’avancement de la transition. Lorsque la transition est observable, le systèmepeut ou non engager une négociation avec l’utilisateur. Nous reviendrons sur ce point en 4.2

3. Quelle est la nature du changement de contexte d’interaction : est-ce un changement d’environne-ment, d’utilisateur, ou, comme dans notre scénario, de plate-forme ? S’agit-il de changement derelations entre des attributs de plate-forme, d’environnement ou d’utilisateur ? Nous reviendronssur ce point en 4.3.

21


4. La transition déclenchée, il convient de s’interroger sur les composants logiciels nécessaires à samise en œuvre. Ce point est traité en 4.4.

Figure 4. IHM de transition : Espace problème.

4.1 Déclencheur du changement de contexte

En IHM, toute adaptation, qu’il s’agisse d’adaptation au contexte d’interaction ou non, relèvede l’initiative de l’utilisateur ou du système :

• On parle d’adaptabilité lorsque l’adaptation a lieu sur intervention explicite de l’utilisateur. Lesmenus de préférences, qui permettent d’ajuster les paramètres du système, relèvent de l’adaptabi-lité. L’utilisateur en a le contrôle explicite.

• On parle d’adaptativité lorsque le système prend l’initiative et réalise l’adaptation sans interven-tion explicite de l’utilisateur. Le “paper clip” de MS word est un exemple d’adaptativité.

Si l’adaptativité présente des avantages (elle minimise l’intervention de l’utilisateur parmigration de tâche vers le système), il convient de ne pas surprendre l’utilisateur (risque de l’inter-rompre) et de s’assurer que l’ajustement est conforme à l’attente de l’utilisateur. Selon les principes

Transition

Composant logicielacteur du rendu

Nature durendu

Cause : la naturedu changement

Système

Utilisateur

Changement de Plate-forme

Changement de l'Utilisateur

Changement d'Environnement

Changement des relations entre :plate-forme, environnement, utilisateur

CD

PP

Absence de rendu

Prévenir des effets de bordDécider entre plusieurs solutions

Système interactif

Présence d'un renduavec négociation

Reconfiguration (ajout/retrait de ressources)

Migration de l'IHM

L'acteur déclencheur

Présence d'un rendusans négociation

Rendu de migration

Rendu de reconfiguration

Les deux

InfrastructureANF

PL

Prévenir d'une adaptation de l'IHM

22


fondamentaux de l’interaction, l’utilisateur doit garder le contrôle de l’interaction. Ce requis appellela question de l’observabilité de l’IHM de transition.

4.2 Observabilité d’une transition

En IHM, l’observabilité est la capacité du système interactif à rendre observables à l’utilisa-teur les concepts pertinents pour la tâche en cours. S’agissant des IHM de transition, le concepteurdoit s’interroger sur la nature de ces concepts. Au vu de notre classification, nous proposons lesrecommandations suivantes :

• L’absence de retour système pendant une transition est à proscrire : l’utilisateur a la charge de par-courir, seul, la distance d’évaluation.

• Les concepts à rendre observables dépendent de la nature du changement. Nous verrons en 4.3 uneanalyse détaillée de la nature du changement et les recommandations correspondantes.

• La négociation ou non avec l’utilisateur. Une négociation est un micro-dialogue, recommandéedans les cas suivants :

a) pour prévenir des effets de bord du changement de contexte sur l’état final avec ses incon-vénients (par exemple, certaines tâches ne seront plus atteignables, une partie du travail risqued’être perdue) et ses avantages (par exemple, l’IHM du système peut maintenant migrer dyna-miquement entre les multiples ressources disponibles).b) pour décider entre plusieurs solutions, laissant à l’utilisateur le plein contrôle ; ou pourdemander à l’utilisateur de lui fournir les paramètres manquant à l’élaboration d’une solution.c) pour prévenir que le système a décidé d’adapter l’IHM. L’absence de négociation lorsque lesystème est la cause du changement peut engendrer des effets de surprise pour l’utilisateur etdonc des disruptions dans la continuité interactionnelle.

Voyons en détail la nature du changement de contexte d’interaction.

4.3 Nature du changement de contexte d’interaction

Le contexte d’interaction, nous l’avons vu en introduction, est défini par l’ensemble des attri-buts (et de leurs relations) qui caractérisent le triplet “plate-forme - environnement - utilisateur”. Lanotion d’environnement mérite une étude à elle seule et la modélisation de l’utilisateur dépasse lecadre de nos compétences. Aussi dans cette étude, je retiens les changements de plate-forme unique-ment. Précisons cette notion avant d’affiner les conséquences pour l’IHM de transition. J’introduispour cela, le concept de plate-forme élémentaire, de configuration de base, et de grappe de plates-for-mes.

4.3.1. Plate-forme élémentaire et grappe de plates-formes

Une plate-forme élémentaire est un ensemble de ressources physiques et logicielles qui,ensemble, constituent une unité de calcul opérationnelle dont l’état est observable et/ou modifiablepar l’utilisateur. Aucune de ces ressource n’est par elle-même capable de fournir un service opération-

23


nel. Une station de travail, un PDA, un téléphone mobile sont des plates-formes élémentaires. Maisles ressources qui les composent, comme un clavier et un processeur, sont incapables individuelle-ment de fournir un tel service.

Certaines ressources sont organisées en une configuration immuable appelée configuration debase. Par exemple, un laptop est constitué d’une configuration de base. Les ressources qui formentune configuration de base sont des ressources de base. Les autres, tels que les écrans externes, lescapteurs, les claviers externes et les souris, sont des ressources d’extension.

Une grappe est une composition de plates-formes élémentaires. Elle est homogène lorsqu’elleest composée de plates-formes de la même classe. Par exemple, le Dynawall (voir Figure 5.) est unegrappe homogène composée de trois tableaux électroniques [Streitz et al. 1999]. La grappe est hété-rogène lorsqu’elle est constituée de plates-formes de classes différentes comme les surfaces aug-mentées de Rekimoto [Rekimoto 1999] (voir Figure 6.).

Figure 5. Le DynaWall de i-Land.

24


Figure 6. Surfaces augmentées de Rekimoto.

De manière plus formelle, soient :

- C, l’ensemble des configurations de base- E, l’ensemble des ressources d’extension- C', C" ≠ {}: C' ⊂ C et C" = C – C' - E', E": E' ⊂ E et E" = E – E'- c1, …, cn ∈ C , e1, …, em ∈ E pour n ∈ N*, m ∈ N- Operationel, le prédicat sur un ensemble de ressources qui est VRAI lorsque cet ensemble

forme un artefact de calcul opérationnel et dont l’état peut être observé et/ou modifié par l’utilisateur.Alors, une plate-forme se définit ainsi :

P = {c1, …, cn } ∪ { e1, …, em } et Operationel (P)

P est élémentaire si et seulement si :

¬∃ C', E', C", E": Operationel (C' ∪ E') et Operationel (C" ∪ E").

En d’autres termes, P est élémentaire s’il n’est pas possible de construire deux plates-formes àpartir de l’ensemble des ressources constituantes de P.

P est une grappe s’il est possible de construire au moins deux plates-formes à partir del’ensemble des ressources constituantes de P :

∃ C', E', C", E": Operationel (C' ∪ E') et Operationel (C" ∪ E").

Notons que :

25


• Une configuration de base n’est pas nécessairement opérationnelle. Par exemple, le Personal Ser-ver d’Intel [Want et Shilit 2001], un micro-drive relié au réseau par Blue-Tooth, est une configura-tion de base, mais n’est pas une plate-forme élémentaire : son état ne peut être observé ni manipulé(voir Figure 7.). Une fois connecté à des ressources d’interaction (clavier, écran, etc.), on obtientune plate-forme élémentaire.

Figure 7. Le Personal Server d’Intel.

• Un laptop est une plate-forme élémentaire : l’ajout de ressources d’extension, comme le clavier etla souris, ne change pas son caractère de plate-forme élémentaire. Il en va de même pour les Data-Tiles (voir Figure 8.) de Rekimoto qui peuvent être dynamiquement étendues en plaçant des tuilestransparentes sur un plateau constitué d’un écran plat LCD [Rekimoto 2001].

Figure 8. Les DataTiles de Rekimoto.

26


4.3.2. Changement de plate-forme

Comme le montre la Figure 4., le changement de plate-forme résulte de deux phénomènes àl’initiative, rappelons-le, de l’utilisateur ou du système : l’ajout ou le retrait de ressources à une plate-forme, et la migration de tout ou partie du système interactif entre plates-formes. Ces phénomènespeuvent être conjoints car, nous allons le voir, l’ajout et le retrait de ressource peuvent entraîner unemigration d’IHM.

Reconfiguration du système interactif. La Figure 9. illustre, sous forme d’automate,l’enchaînement des différents cas d’ajout ou de retrait de ressources. Soient P, une instance de plate-forme élémentaire et G, une instance grappe :

• Cas 0 : L’ajout de ressources d’extension à une plate-forme non opérationnelle n’en fait pasnécessairement une plate-forme opérationnelle. Par exemple, ajouter un disque externe à un PCsans clavier ni écran ne constitue pas une plate-forme élémentaire. Ce cas ne présente pas d’intérêtpour notre étude.

• Cas 1 et 2 : Le réveil. Une plate-forme non opérationnelle devient une plate-forme élémentaire ouune grappe par l’ajout de ressources d’extension idoines, ou par sa connexion à une grappe. L’IHMde transition doit exprimer le passage de l’état inopérationnel à l’état opérationnel.

• Cas 1’ et 2’ : Le sommeil (ou la panne). Ces conditions traduisent les transitions inverses de 1 et 2:La plate-forme, ou la grappe, qui était opérationnelle, devient inopérationnelle. Avec les ressourcesrestantes ou, lorsque c’est possible, avant la disparition des ressources, l’IHM de transition doitexprimer le cheminement vers la mise en sommeil (ou la panne).

• Cas 3 : Changement interne de ressources. La plate-forme élémentaire est enrichie ou privée deressources d’extension, mais reste une plate-forme élémentaire opérationnelle. L’IHM du systèmeinteractif est centralisée sur une seule plate-forme mais doit, ou a la possibilité, de se reconfigurer.L’IHM de transition doit exprimer l’élargissement (ou le rétrécissement) de l’espace des ressour-ces, de même, s’il y a lieu, le phénomène de reconfiguration de l’IHM du système.

• Cas 4 : Elévation au statut de grappe. La plate-forme élémentaire P, enrichie d’une plate-forme élé-mentaire ou reliée à une grappe, devient une grappe. Dès lors, l’IHM de P a la possibilité d’êtrerépartie sur l’ensemble des ressources d’interaction de la grappe. A son tour, un changement derépartition peut entraîner une reconfiguration. L’IHM de transition doit traduire l’élargissement del’espace des ressources et, s’il y a lieu, la répartition et la reconfiguration de l’IHM du système.(Les différentes formes de répartition seront détaillées plus loin.)

• Cas 4’ : Descente au statut de plate-forme élémentaire. Ici, la grappe perd ses ressources au pointde devenir une plate-forme élémentaire. Alors, l’IHM du système interactif doit être regroupée surune seule plate-forme. Comme en 3, on assiste à une reconfiguration de l’IHM du système, maisici l’IHM de transition doit exprimer le rétrécissement de l’espace des ressources, la centralisationet la reconfiguration de l’IHM du système.

• Cas 5 : Changement de ressources internes. La grappe voit arriver ou partir des ressources, maiselle conserve son statut de grappe. L’IHM du système interactif a la possibilité de changer derépartition. A son tour, le changement de répartition appelle une reconfiguration. L’IHM de transi-tion exprime l’arrivée ou la perte de ressource et, s’il y a lieu, le changement de répartition et dereconfiguration de l’IHM du système.

27


Figure 9. Automate : les effets de l’ajout et de retrait de ressources sur une plate-forme.

Migration de l’IHM du système interactif. La migration d’IHM concerne le transport de tout oupartie de cette IHM entre plates-formes. Comme le montre la Figure 10. je distingue quatre grains demigration :

• La migration de l’IHM dans sa totalité d’une plate-forme à l’autre que ce soit entre plate-formesélémentaires ou entre grappes.

• Toutes les autres formes de migration sont des migrations partielles entre les ressources des plates-formes d’une même grappe. Il s’agit de migration sur frontière d’espace de travail, sur concept dudomaine ou sur pixel.

- La migration sur frontière d’espace de travail. On appelle espace de travail, le regroupementd’un ensemble d’interacteurs qui permet de réaliser un ensemble de tâches logiquement con-nectées. Dans les IHM graphiques usuelles, les palettes d’outils et les canevas de dessin sontdes espaces de travail. Si l’on reprend la métaphore du peintre, l’utilisateur d’une grappe peutfaire migrer la palette des outils entre le PDA tenu dans la main dominante et le tableau mural.- La migration sur concept du domaine. Un concept du domaine est une entité implémentéepar le noyau fonctionnel. Il en a une représentation perceptible et manipulable. Le Pick&Dropde Rekimoto est un exemple de migration d’IHM au niveau du concept du domaine.- Pour les IHM graphiques, la migration au niveau du pixel. Comme dans le Dynawall, lareprésentation graphique d’un concept du domaine ou d’un espace de travail peut se trouver

P

P nonop.

G

0

3

5

11'

4' 4

22'

1, 2 : RéveilL'IHM de transition doit exprimer :

1', 2' : Sommeil

5 : Extension/réduction + distributiono + reconfigurationo

3 : Extension/réduction + reconfigurationo4 : Extension + distributiono + reconfigurationo4' : Réduction + centralisation + reconfiguration

L'opérateur o exprime une opération optionnelle

28


répartie sur des écrans appartenant à des plates-formes distinctes. La topologie de ces écrans,comme leur hétérogénéíté, a un impact sur la continuité du rendu.

Figure 10. Les différentes sortes de migrations.

Quelle que soit la nature de la migration, il convient de s’interroger sur le grain de repriseaprès la migration. En effet, la nature du grain a un impact sur les mécanismes logiciels de sauvegardeet de reprise. On distingue :

• Grain action physique : après migration, l’utilisateur poursuit son activité au milieu de la tâche élé-mentaire en cours. Il n’a rien perdu de son travail.

• Grain tâche élémentaire : si l’utilisateur est au milieu d’une tâche élémentaire, par exemple la sai-sie d’un champ, ce champ doit être ressaisi après la transition.

• Grain tâche composée : l’utilisateur doit reprendre son activité au début d’une tâche mère. Parexemple, s’agissant d’un formulaire composé de plusieurs champs, l’utilisateur trouve, après latransition, un formulaire vierge : les saisies antérieures à la transition (tâches élémentaires de latâche composée) sont perdues.

• Grain session : L’utilisateur doit relancer le système interactif : une situation exigeante pour l’utili-sateur mais confortable pour le programmeur !

L’automate de la Figure 11.montre les différents cas de migration entre plates-formes élémen-taires et grappes. Soient P et P’ deux instances de plate-forme élémentaire de classe distincte, et P1une instance de la même classe que P. Par exemple, P et P1 sont des PC tandis que P’ est un PDA. Demême, soient G et G’ deux grappes de classes distinctes, homogènes ou non. Supposons en outre queG inclut P ou une plate-forme de même classe que P. Par exemple, G est une grappe de PC. Suppo-sons que G’ soit une grappe de PDA. Prenons pour G1 une grappe de même classe que G. Analysonsles différents cas :

• Cas A, A’ : Migration de l’IHM entre plates-formes élémentaires de même classe ou entre grappesde même classe. Il s’agit nécessairement d’une migration totale. Une seule question se pose : legrain de reprise. S’il y a perte de travail, l’IHM de transition doit opter pour un rendu avec négo-ciation afin d’avertir l’utilisateur des conséquences de la migration, puis sur acceptation de l’utili-sateur poursuivre avec un rendu de migration suivant des effets explicités dans lesrecommandations des cas 3 ou 5 correspondant à l’ajout de ressources.

• Cas B, B’ : Migration de l’IHM entre plates-formes élémentaires ou grappes de classe distincte.Deux questions se posent : le grain de reprise et le calcul de la compatibilité des ressources entre

TypeTotale

PartielleFrontière : espace de travailFrontière : concept du domaine

Frontière : pixelMigration

Grain de reprise

Action physique

Tâche élémentaire

Tâche composée

Session

29


les plates-formes source et cible. Typiquement, un téléphone portable ne permet qu’un sous-ensemble des tâches réalisables avec une station de travail. Par exemple, on n’imagine pas pro-grammer le confort de son domicile (tâche plutôt rare et complexe) avec un téléphone portable. Encas d’une incompatibilité, l’IHM doit opter pour un rendu avec négociation qui a deux rôles :exprimer les conséquences de la migration sur l’espace des tâches et forcer la terminaison d latâche en cours si celle-ci n’est pas disponible sur la plate-forme cible. Puis, sur acceptation del’utilisateur, poursuivre avec un rendu comme en A.

• Cas C, C’ : Migration de l’IHM d’une plate-forme élémentaire vers une grappe compatible aveccette plate-forme et inversement. Cette grappe comprend P ou une plate-forme de même classe queP. Le grain de reprise reste une question valide. Après une négociation éventuelle fonction du grainde reprise, l’IHM de transition peut poursuivre selon les recommandations du cas 4 (passage austatut de grappe). Un raisonnement analogue s’applique au cas C’.

• Cas D, D’ : Migration de l’IHM d’une plate-forme élémentaire vers une grappe incompatible aveccette plate-forme. Après une négociation éventuelle en fonction du grain de reprise et de la naturede l’espace de tâches, l’IHM de transition peut poursuivre selon les recommandations du cas 4(passage au statut de grappe). Un raisonnement analogue s’applique au cas D’.

Figure 11. Automate : les effets de la migration d’IHM entre plates-formes.

Ayant analysé les effets de l’adaptation au changement de contexte du point de vue de l’utili-sateur, voyons les conséquences sur les composants logiciels nécessaires à cette adaptation.

P

P'

G

B'

G' G1

P1B

CC'

D

D'

B'

B

A'

A

L'IHM de transition doit exprimer une négociation sur les effets de bord pour :

A : (grain de reprise)o + [migration + (extension/réduction + reconfigurationo)]o

A' : (grain de reprise)o + [migration + (extension/réduction + distributiono + reconfigurationo)]o

B, B' : (grain de reprise, forcer fin d'exécution tâche en courso + espace tâches)o + [migration + (extension/réduction + reconfigurationo)]o

C : (grain de reprise)o + [ migration + (extension + distributiono + reconfigurationo)]o

C' : (grain de reprise, forcer fin d’exécution tâche en courso+espace de tâches)o+ [migration + (réduction + centralisation + reconfiguration)]o

D : (grain de reprise, forcer fin d’exécution tâche en courso+espace de tâches)o + [ migration + (extension + distributiono + reconfigurationo)]o

D' : (grain de reprise, forcer fin d’exécution tâche en courso+espace de tâches)o+ [ migration + (réduction + centralisation + reconfiguration)]o

30


4.4 Composants système impliqués.

De manière générale, on distingue, à l’exécution, deux catégories de composants logiciels :

• Le système interactif proprement dit, qui désigne l’ensemble des composants exécutablesnécessaires à la couverture fonctionnelle d’une application donnée,

• L’infrastructure qui désigne les services et mécanismes “run-time” d’utilité générale auxquels lesystème interactif fait appel au cours de son exécution.

Si l’on considère le cas précis de l’adaptation au changement de contexte, les composantslogiciels qui permettent cette adaptation à l’exécution appartiennent au système interactif et/ou àl’infrastructure. Pour le seul changement de plate-forme, on l’a vu en 4.3, ces composants doiventêtre capables d’assurer les fonctions suivantes :

• Migration de composants du système interactif avec sauvegarde d’état à différents grains (actionphysique, tâche élémentaire, tâche, session) et reprise,

• Détection et gestion de l’arrivée (découverte) et départ (perte) de ressources,

• Reconfiguration de l’IHM du système interactif.

Les deux premières fonctions, migration de composant et gestion des ressources, sont indé-pendantes de toute application. En conséquence, elles devraient être assurées par l’infrastructure. Parexemple, en Java, le mécanisme de sérialisation des objets et Java-RMI servent la migration de com-posant et la distribution de l’IHM sur les ressources d’une grappe de plates-formes. Mais le niveaud’abstraction de ces services reste de trop bas niveau pour le développeur. En particulier, l’hétérogé-néité des grappes et plates-formes élémentaires, l’arrivée et le départ dynamiques de ressources, mili-tent pour la mise en œuvre d’une machine d’interaction abstraite qui masque cette diversité audéveloppeur de système interactif. C’est le sujet d’une thèse en cours dans l’équipe IIHM [Lachenal2002]. PoinRight, qui permet à un utilisateur de contrôler plusieurs écrans avec une seule souris etclavier, relève du même esprit [Johanson 2000]. Quand bien même les mécanismes de migration et degestion de ressources sont fournis au bon niveau d’abstraction, il revient au développeur de systèmeinteractif d’implémenter la politique qui convient au cas de l’application ou de réutiliser des politi-ques standard prêtes à l’emploi.

La troisième catégorie de fonction, la reconfiguration de l’IHM, revient, pour l’essentiel, ausystème interactif. Comme l’indique D. Thevenin dans son mémoire de thèse sur la plasticité desIHM [Thevenin 2001], la reconfiguration d’une IHM peut toucher un ou plusieurs niveaux fonction-nels du système interactif (voir Figure 12.) :

• Niveau Présentation Physique (Figure 12.a) : le type des interacteurs physiques est conservé maisleur rendu peut différer.

• Niveau Présentation Logique (Figure 12.b) : les interacteurs sont de type différent mais leurs capa-cités représentationelles et fonctionnelles sont équivalentes. Par exemple, un champ de saisie etune listbox sont fonctionnellement équivalents.

• Niveau Contrôleur de Dialogue (Figure 12.c) : la nature des tâches reste inchangée, mais leuragencement diffère. Par exemple, le passage du style manipulation directe (sélectionner objetd’abord puis spécifier fonction) au style langagier (spécifier fonction puis sélectionner objet)relève de ce type d’adaptation.

31


• Niveau Adaptateur du Noyau Fonctionnel (Figure 12.d) : la nature des tâches et des concepts mani-pulés a changé. Par exemple, les fonctions Sélectionner, Visualiser, Modifier, disponibles pour unestation de travail ne le sont plus sur PDA qui ne peut alors que Visualiser.

La mise en œuvre de l’adaptation des niveaux Présentation Physique et Présentation Logiqueest facilitée par l’existence de boîtes à outils dédiées. Pour le niveau physique, Awt/Swing [SUN/J2SE] prend en charge cette adaptation : une application développée sous Windows peut être exécutéesous MacOS, mais cette adaptation concerne la modalité graphique seulement. Pour le niveau logi-que, une boîte à outils d’interacteurs plastiques comme décrits dans [Daassi 2002] allègerait la tâchedu programmeur. Les deux autres niveaux, ANF et CD sont plus complexes. Dans Thevenin [Theve-nin 2001], on trouvera la description d’un environnement de développement qui permet de produiredes ANF et CD différents en fonction de la plate-forme cible. Mais les solutions proposées ne cou-vrent que des IHM exécutables sur plates-formes élémentaires et où le grain de reprise est la session.

Figure 12. Adaptation de l’IHM selon Arch.

5. Synthèse

Ce chapitre a permis d’identifier le concept d’IHM de transition, élémentaire ou composée,dont la fonction première est de permettre à l’utilisateur d’évaluer l’adaptation du système interactif àun changement de contexte d’interaction : changement d’utilisateur, changement d’environnementphysique, changement de plate-forme et changement des relations entre utilisateur - environnement -plate-forme.

32


Face à la complexité du problème, j’ai restreint l’étude au cas du changement de plate-formeque celle-ci soit une plate-forme élémentaire ou une grappe. Le changement peut être l’ajout ou leretrait de ressources, la migration de tout ou partie de l’IHM d’autre part. L’analyse de la nature duchangement a permis d’identifier des requis pour l’IHM de transition : expression de l’élargissementou du rétrécissement des ressources disponibles, expression des phénomènes de migration et dereconfiguration, présence ou non d’une négociation préalable avec l’utilisateur.

En dernière partie de ce chapitre, nous avons étudié la nature des composants logiciels impli-qués dans l’adaptation à un changement de contexte : l’infrastructure et les niveaux fonctionnels dusystème interactif (ANF, CD, PL et PP). Chaque type de composant (infrastructure et niveau Arch) estresponsable d’un aspect de l’adaptation au changement de contexte. Par conséquent, il a un rôle àjouer dans la mise en œuvre de l’IHM de transition correspondant au changement. Au chapitre sui-vant, nous allons découvrir les outils utiles à cette mise en œuvre, identifier leurs apports et lacunes.

33

CHAPITRE 3 IHM de transition : exemples et outils de l’état de l’art

1. Introduction......................................................................................................37

2. Exemples d’IHM de transition.........................................................................38

2.1 Mac Os X...............................................................................................382.2 Surfaces augmentées et DataTiles de Rekimoto ......................................412.3 i-Land.......................................................................................................43

3. Outils de Spécification.....................................................................................463.1 Seescoa XML...........................................................................................463.2 Cicero.......................................................................................................473.3 QTk ..........................................................................................................483.4 SMIL 2.0 ..................................................................................................50

4. Boîtes à outils...................................................................................................514.1 Multimodal Toolkit ..................................................................................514.2 Jazz...........................................................................................................524.3 Adraw.......................................................................................................52

5. Infrastructures ..................................................................................................535.1 Molène .....................................................................................................535.2 BEACH et COAST..................................................................................54

6. Synthèse ...........................................................................................................55

35

CHAPITRE 3 : IHM de transition : exemples et outils de l’état de l’art

1. Introduction

Après avoir défini la notion d’IHM de transition et son espace problème, nous portons mainte-nant l’attention sur l’état de l’art lié à notre sujet. Dans une première partie (section 2), nous présen-tons des exemples d’IHM de transition avec I-Land, les travaux de Rekimoto et Mac OS X. La suitedu chapitre est consacrée aux outils de mise en œuvre répartis en trois catégories complémentaires :les outils de spécification (section 3), les boîtes à outils (section 4) et les infrastructures (section 5).Nous verrons que, indépendamment de leur catégorie, certains outils sont dédiés à l’adaptation dyna-mique des IHM au changement de contexte d’interaction. Nous regardons alors s’ils incluentl’expression d’IHM de transition. D’autres outils ne concernent pas l’adaptation d’IHM au contexted’interaction, mais présentent des capacités utiles à l’expression des IHM de transition.

Chaque outil sera analysé selon les éléments de l’espace problème présenté au chapitre précé-dent, offrant ainsi des moyens de comparaison systématiques de l’existant au regard des requis desIHM de transition. Comme au chapitre précédent, seuls sont considérés les changements de plate-forme. La Table 1. correspond à l’outil idéal attendu. Cet outil doit permettre la prise en charge destransitions que celles-ci soient à l’initiative du système ou de l’utilisateur.

Concernant le rendu de l’IHM de transition, l’outil doit permettre l’expression a) pour lamigration d’IHM : la distribution ou, inversement, la concentration de l’IHM du système, b) pourl’ajout ou le retrait de ressources : le réveil, la mise en sommeil, la réduction et l’extension del’espace des ressources, c) la négociation avec l’utilisateur et d) le phénomène de reconfiguration del’IHM du système. Ensuite, il convient de spécifier qui, des composants logiciels de l’infrastructureou du système interactif, prennent en charge l’expression de l’IHM de transition. La dernière ligneprécise, pour le cas des migrations d’IHM, le grain de sauvegarde et reprise.

Table 1. Outil idéal pour l’expression des IHM de transition

Acteur déclencheur Système et Utilisateur

Rendu de l’IHM de transi-tion

a) Migration : distribution/concentration de l’IHM du système interactif

b) Ajout/Retrait de ressources : réveil, sommeil, extension/réduction de l’espace des ressources

c) Négociation avec l’utilisateur

d) Reconfiguration

Cause du changement Migration et reconfiguration (Ajout/Retrait de ressources)

Composant logiciel acteur du changement

Infrastructure ou Système interactif

Composant logiciel acteur du rendu

Infrastructure ou Système interactif

Grain de sauvegarde et reprise

Action physique

37


2. Exemples d’IHM de transition

Cette section regroupe trois exemples représentatifs d’IHM de transition avec Mac OS X, lestravaux de Rekimoto sur les surfaces augmentées et les DataTiles, et i-Land.

2.1 Mac Os X

Mac OS X [Mac Os X] est le dernier système d’exploitation d’Apple dont l’interface utili-sateur, Aqua [Aqua Guide], se démarque des précédentes versions par de nouveaux services et uneprésentation fondée sur l’esthétisme [Mac Os X Theater] et les principes usuels [Mac Guide] : utili-sation de métaphores, manipulation directe, feedback informatif, etc. J’ai relevé deux effets (anima-tions) en relation avec notre sujet : la “minimisation/maximisation” des fenêtres-documents dans le

Dock1, et la plasticité des barres de menu.

La Figure 1. montre l’effet “Génie” qui accompagne l’entrée et la sortie de documents. Ceteffet constitue une IHM de transition qui permet à l’utilisateur d’évaluer la provenance et la destina-tion, c’est-à-dire la migration, de concepts du domaine (ici les documents) au sein d’une plate-formeélémentaire.

Figure 1. Effet génie pour la minimisation/maximisation des documents.

1. Le Dock, concept introduit par NeXT, est une barre où l’utilisateur peut accéder directement à ses applications préférées de même aux applications en cours et documents ouverts.

Le Dock

Effet “génie”

38


La Figure 2. illustre les capacités de plasticité de Mac OS X où la nature des informationsobservables dépend de la surface d’affichage disponible [Mac Os X Theater]. Cet exemple corres-pond au choix d’une police de caractères.

En A), l’utilisateur dispose d’une grande fenêtre : il a alors un accès direct à toutes les infor-mations (concepts du domaine) nécessaires à l’accomplissement de sa tâche. Puis il rétrécit la fenêtrepar la droite : il obtient B) qui se traduit par la suppression des concepts du domaine les moins impor-tants (ici, les grandes catégories de police). Il s’agit d’une adaptation de type Adaptateur de NoyauFonctionnel (Cf. chapitre précédent). L’utilisateur rétrécit B) par le bas. Il obtient C) où l’on assiste àun changement d’interacteurs : les listes sont remplacées par des menus jaillissants à faible empreintegraphique. Il s’agit d’une adaptation du niveau Présentation Logique. En élargissant C) sur la droite,les grandes catégories réapparaissent, mais sous forme de menu jaillissant (la hauteur de la fenêtrerestant insuffisante).

Ainsi, tandis que l’utilisateur modifie la taille de la fenêtre, le contenu est adapté dynamique-ment, mais la transition entre deux présentations est instantanée : on assiste à une absence d’IHM detransition dont le rôle ici serait d’exprimer la reconfiguration du contenu.

39


Figure 2. Plasticité (reconfiguration) dans Mac OS X : choix d’une police de caractères. Les flèches pleines indiquent le changement de taille de la fenêtre support.

A)

B)

C)

D)

40


La Table 2. résume les capacités de Mac OS X au regard de nos requis.

2.2 Surfaces augmentées et DataTiles de Rekimoto

Avec ses surfaces augmentées, Rekimoto permet à un utilisateur de transférer par manipula-tion directe, des “objets” entre son ordinateur portable et une table augmentée [Rekimoto 1999].Comme le montre la Figure 3., un lien appelé “anchored link” permet à l’utilisateur de visualiser leprolongement de la souris du portable sur la table. Ce rendu est une IHM de transition dont le rôle, ici,est d’exprimer la migration d’un concept du domaine entre plates-formes d’une grappe. En outre, lesobjets manipulés n’ont pas le même rendu lorsqu’ils se trouvent sur l’ordinateur portable (représenta-tion en 3D) ou sur la table (représentation en 2D vue de dessus). Il s’agit de plasticité (adaptation à lasurface et à sa relation spatiale avec l’utilisateur).

Figure 3. Le concept d’anchored link des Tables Augmentées de Rekimoto. Un trait jaune asservi au mouvement de la

souris du portable sert d’IHM de transition dans une migration d’objets entre plates-formes.

Les DataTiles [Rekimoto 2001] se présentent sous la forme de petites tuiles transparentes quel’utilisateur dispose sur une table et sur lesquelles des informations sont rétro-projetées (voir Figure4.). Chaque tuile est identifiée et joue un rôle particulier (curseur, carte géographique, etc.). L’utilisa-

Table 2. Synthèse Mac Os X



Migration au sein d’une plate-forme élémentaire

Cause du changement Migration et reconfiguration


Infrastructure


Infrastructure


Action physique

41


teur peut les combiner, par exemple placer la tuile “météo” sur la tuile “ligne du temps” pourdécouvrir quel temps il fera demain.

Figure 4. DataTiles

L’utilisateur peut aussi transférer de l’information entre tuiles par drag&drop. Dans l’exemplede la Figure 5., une tuile joue une vidéo tandis qu’une autre sert de portail (Portal Tile) vers le projec-teur vidéo d’une salle de réunion. Le glissement de la vidéo jouée par la tuile “vidéo” vers la tuilePortal a pour effet la projection de la vidéo sur le projecteur de la salle de réunion. Une brève anima-tion concrétise ce transfert. Il s’agit d’une IHM de transition représentant la migration de données ausein d’une même plate-forme. Chaque tuile est une ressource d’extension (Cf. chapitre précédent).

42


Figure 5. Transition sur un transfert de données.

La Table 3. résume ensemble les techniques de transition des Tables Augmentées et des Data-Tiles.

2.3 i-Land

Comme le montre la Figure 6., i-Land est un espace d’interaction (dit smart room) répartieentre le DynaWall (ensemble de trois tableaux augmentés) et l’InteractTable. L’utilisateur disposed’une grande surface verticale (le DynaWall formé de trois tableaux électroniques disposés côte àcôte) et d’une surface plus restreinte horizontale, l’InteractTable.

Table 3. Synthèse Rekimoto.

Acteur déclencheur Utilisateur


Migration : distribution/concentration de l’IHM du système interactif

Cause du changement Migration


Système interactif


Système interactif


Action physique

Transition

Connexion

43


Figure 6. Vue globale d’i-Land.

Comme le montre la Figure 7., i-Land permet deux types de migration :

• Des migrations partielles d’IHM au niveau pixel entre les trois tableaux du DynaWall. L’IHM detransition est un retour d’information graphique comme sur les écrans usuels : la fenêtre est asser-vie au mouvement glisser-déposer et ceci sans rupture au franchissement d’une frontière detableau. L’absence de rupture dans la transition est facilitée par une topologie particulière etimmuable des trois tableaux physiques disposés côte à côte. C’est pourquoi, i-Land propose desmigrations totales entre surfaces disjointes comme l’InteractTable.

• Des migrations totales entre le DynaWall et l’InteracTable au moyen d’un phicon dédié [Ishii etUllmer 1997] appelé Passage (voir Figure 7.). La migration d’un document du DynaWall vers latable se fait en déplaçant la représentation graphique du document vers la tablette physique rése-rvée au Passage, au bas du tableau. Si le Passage est présent sur la tablette (détection par capteur depoids), la représentation graphique du document disparaît instantanément du tableau. Ensuite,l’utilisateur prend le Passage pour le déposer sur la tablette de l’InteractTable. Passage constituel’IHM de transition. Il traduit de manière tangible la migration de concepts entre deux plates-for-mes d’une grappe. Il manque néanmoins dans cette IHM de transition, l’expression de la migrationdes concepts vers (ou depuis) le Passage.

DynaWall

InteractTable

44


Figure 7. Le DynaWall et l’InteractTable.

Phicon “Passage”

Rotationd’une fenêtre

pour le transfert de données

45


Sur l’InteracTable, les fenêtres peuvent être soumises à des rotations en sorte que toute per-sonne autour de la table puisse voir l’information sans se tordre le cou (voir Figure 7.). Il s’agit d’uneforme élémentaire, mais combien indispensable, de reconfiguration. L’IHM de reconfiguration est unsuivi de rotation de la fenêtre.

Les services et effet de migration et rotation sont assurés par une infrastructure, BEACH(Basic Environment for Active Collaboration with Hypermedia) et COAST présentés à la fin de cechapitre en 5.2.

Après ces exemples concrets centrés sur l’utilisateur, adoptons la perspective outil avec l’ana-lyse de techniques de spécification, de boîtes à outils et d’infrastructures représentatives. Dans letemps imparti à cette étude, je ne prétends pas fournir une liste exhaustive de l’existant.

3. Outils de Spécification

J’ai retenu, d’une part, Seescoa XML qui vise la migration d’IHM (section 3.1), et d’autrepart, Cicero (section 3.2) et Qtk (en 3.3) qui couvrent la reconfiguration d’IHM. Aucun de ces troisoutils n’intègre d’IHM de transition pourtant nécessaire à l’expression de la migration et de la recon-figuration. SMIL, résumé brièvement en 3.4, propose des éléments intéressants pour l’expression deces transitions.

3.1 Seescoa XML

Seescoa XML a pour objectif de servir de langage de description d’IHM graphiques et de leurétat d’exécution. Ce faisant, il est possible de faire migrer une IHM dynamiquement entre plates-for-mes [Luyten et Coninx 2001]. Seescoa XML s’appuie sur le mécanisme de réflexion de Java qui per-met d’analyser dynamiquement l’interface graphique et de générer la description XMLcorrespondante. Cette description peut ensuite être envoyée sur une autre plate-forme pour y être ins-

Table 4. Synthèse i-Land



Migration partielle au niveau du pixel : suivi de fenêtre

Migration totale : phicon Passage

Reconfiguration : suivi de fenêtre

Cause du changement Migration partielle (pixel) et totale

Reconfiguration (rotation de fenêtre)


Infrastructure


Infrastructure


Action physique

46


tanciée en une interface graphique équivalente à l’originale et dans le même état. Le système est donccapable de cloner des IHM au niveau du grain action physique.

Si Seescoa fournit des mécanismes de migration, il n’intègre pas la notion d’IHM de transi-tion. Mais Seescoa XML présente l’intérêt de pouvoir décrire des IHM à partir desquelles il seraitpossible de réaliser des calculs et IHM de transition.

3.2 Cicero

Arens et Hovy s’intéressent à la difficulté croissante de développer des systèmes multimédiaen raison de la diversité croissante des plates-formes. La taille du code et les coûts liés à la program-mation d’une interface graphique les dirigent vers une approche d’adaptation dynamique de l’IHM.Dans cette optique, Arens et Hovy proposent le système Cicero [Arens et Hovy 1995], (système nonimplémenté dans son ensemble), permettant de faire de l’adaptation dynamique organisée autour d’unmédiateur (l’Interaction Manager).

Cicero est un outil de spécification d’IHM multi-cible, et le médiateur est intégré dans l’appli-cation générée. L’intérêt pour nous, serait d’intégrer un modèle de transition aux cinq modèles déjàprésents permettant la construction de l’IHM.

Table 5. Synthèse Seescoa XML

Acteur déclencheur Système


Absence de rendu

Cause du changement Migration totale d’IHM


Infrastructure


Sans objet


Action physique

Table 6. Synthèse Cicero



Absence de rendu

Cause du changement Migration totale d’IHM et reconfiguration


Infrastructure


Sans objet


Inconnu

47


3.3 QTk

QTk [Grolaux et al. 2001] est un outil de spécification d’interfaces homme-machine construitau-dessus du langage Oz [Mozart]. Oz et QTk constituent un environnement de prototypage rapidefondé sur un ensemble de modèles (en particulier, le modèle des plates-formes cibles). QTk force laséparation entre IHM et données abstraites du Noyau Fonctionnel. Ainsi, il est aisé d’associer plu-sieurs interfaces graphiques au même Noyau Fonctionnel. QTk exige du développeur d’exprimer lesdifférentes IHM d’un Noyau Fonctionnel, de même les conditions de choix entre ces IHM. Mais Qtkn’inclut pas de transition entre ces vues. Il serait intéressant pour nous, d’ajouter des mécanismes quipermettent au programmeur de décrire les IHM de transitions entre les différentes vues.

FlexClock [Grolaux 2000], présentée à la Figure 8., a été réalisée avec QTk. FlexClockadapte son contenu en fonction de la surface d’affichage qui lui est allouée. Au départ, la surfaced’affichage est suffisante. Tous les concepts sont représentés : heure complète, date complète avec uncalendrier.

Figure 8. FlexClock : Affichage maximal.

Les figures suivantes montrent l’évolution de FlexClock alors que la surface d’affichage estréduite. Les effets et principes sont similaires à la plasticité présentée à propos de Mac OS X.

48


Figure 9. Réduction de la surface d’affichage.

Nous observons deux types d’adaptation :

• une adaptation de l’organisation des concepts : la position de la date entre C) et D) : adaptation dela Présentation Physique.

A) B)

D) C)

E) F)

49


• une adaptation des concepts représentés : entre D) et E) le format de la date, et la double représen-tation de l’heure ; et entre E) et F) : adaptation de l’ANF.

3.4 SMIL 2.0

Le langage SMIL (Synchronized Multimedia Integration Language) [SMIL 2.0] a été déve-loppé par un groupe de travail dépendant du W3C et soucieux de fournir un méta-langage permettantde décrire des documents multimédia. SMIL2.0 se présente sous la forme de modules fonctionnelsdont le “Transition Effects” qui répertorie un grand nombre d’effets de transition. Voici un exemplede code (un ensemble complet de tests est disponible à [SMIL 2.0 TestSuite]).

<smil xmlns="http://www.w3.org/2001/SMIL20/Language"xmlns:it="http://www.w3.org/2001/SMIL20/InlineTransitions"systemRequired="it"><head>

<layout><root-layout backgroundColor="white" width="640" height="480"/><region top="270" left="10" /><region id="r" fit="fill"/>

</layout></head><body>

<par dur="indefinite"><video region="r" id="m1" src="../videos/nasa.qt" begin="2" dur="20" fit="hidden">

<it:transitionFilter id="trans1" type="barWipe" begin="2" dur="6" calcMode="linear" fill="freeze"/></video>

</par></body>

</smil>

Concrètement, ce scénario joue une vidéo “nasa.qt” à partir de la seconde 2 pour une durée de20s. Une transition de type “barWipe” commence au bout de 2s (en même temps que la vidéo) et aune durée de 6s.

SMIL est un langage interprété. Toute reconfiguration ou migration relèverait alors demécanisme annexes intégrés éventuellement à l’interpréteur. Ces mécanismes n’existent pas à l’heure

Table 7. Synthèse QTk



Absence de rendu

Cause du changement Reconfiguration (Ajout/Retrait de ressources)


Système interactif


Sans objet


Sans objet

50


actuelle, mais SMIL 2.0 a été conçu pour pouvoir s’adapter (à l’installation du fichier SMIL sur leplayer) à l’utilisateur (à sa langue), au hardware (ressource CPU par exemple), au software (parexemple au système d’exploitation), à la taille de l’écran (avec la gestion de position relative). SMILprésente ici un problème un peu différent de celui étudié, puisque nous parlons ici de document,nécessairement exploité par une application, et non pas d’application directement. L’inventaire destransitions entre images nous a paru intéressant, c’est pourquoi nous avons décidé de le faire apparaî-tre dans cet état de l’art, sans toutefois créer de synthèse.

4. Boîtes à outils

Parmi les boîtes à outils, j’ai relevé Multimodal Toolkit pour la reconfiguration d’IHM, etJazz et Adraw pour l’expression de phénomènes évolutifs dans les IHM graphiques.

4.1 Multimodal Toolkit

Multimodal Toolkit [Crease et al. 2000] est une boîte à outils dont les interacteurs, de naturemultimodale, permettent à l’IHM d’un système interactif de s’adapter au contexte d’interaction etnotamment à la plate-forme : adaptation aux ressources (dispositifs) d’interaction disponibles (écran1024*768 d’une station de travail ou 160*160 d’un PalmPilot), adaptation à la variation de la charged’utilisation des ressources (par exemple, surcharge du dispositif sonore), adaptation au retrait oul’ajout d’une ressource d’interaction (souris, clavier).

Si l’IHM du système est capable de s’adapter dynamiquement aux changements de ressourcesd’interaction, je n’ai pas constaté la présence d’IHM de transition lors des tests que j’ai effectués avecMultimodal Toolkit. Toutefois, la résolution de la plasticité par la multimodalité est, je pense, uneapproche intéressante au problème de la plasticité. Dans ce cadre, je modéliserais une IHM de transi-tion sous forme d’un interacteur et la résolution de la meilleure transition comme le choix de la moda-lité la mieux adaptée à la situation (au sens de [Nigay et Coutaz 1996]).

Table 8. Synthèse Multimodal Toolkit



Absence de rendu



Composants de la boîte à outils


Sans objet


Sans objet

51


4.2 Jazz

Jazz [Bederson et al. 2000] est une boîte à outils implémentée en Java qui permet de cons-truire des interfaces utilisateur zoomable (Zoomable User Interface). Elle permet de créer des anima-tions comme la rotation de widget et un positionnement de ces mêmes widgets selon toutes lesorientations. Jazz ne permet pas de réaliser directement des IHM plastiques ni des IHM distribuéescomme dans le cas des surfaces augmentées de Rekimoto, mais elle fournit au développeur des outilsintéressants de manipulation de widgets. Pour cette raison, Jazz apparaît dans notre état de l’art. Si lerendu de type multi-surface n’est pas facile à réaliser avec Jazz, le rendu de reconfiguration (laréorganisation de widget par exemple, la rotation d’une interface selon l’orientation du PDA, ...) peutêtre facilement envisagé.

4.3 Adraw

Thoms et Calder dans [Thomas et Calder 2001] étudient comment améliorer l’interaction enutilisant des animations imitées des dessins animés (cartoons). Par exemple, comme le montre laFigure 10., le redimensionnement d’une forme donne l’impression que l’on “tire” réellement sur cetteforme avec des adhérences.

Figure 10. Animation d’un redimensionnement

Table 9. Synthèse Jazz

Acteur déclencheur Sans objet


Reconfiguration



Système interactif


Système interactif


Sans objet

52


Les effets d’animation de Adraw conviennent particulièrement aux migrations à l’initiative del’utilisateur en Interaction Fortement Couplée (IFC) [Bérard 1999]. Le déplacement d’une icône dansles IHM à manipulation directe est un exemple d’IFC. Un tel effet pourrait par exemple être utilisédans i-Land pour exprimer le transfert d’un concept dans/vers le Passage.

5. Infrastructures

Les infrastructures qui permettent la migration et la reconfiguration dynamique d’IHM sontencore rares. Des travaux sont en cours dans l’équipe IIHM sur le sujet, mais aussi à Stanford dansl’équipe de Winograd, au MIT avec le projet Oxygène, à CMU avec le projet AURA et chez Miscro-soft System avec EasyLiving. Les résultats sont soit confidentiels, soit très parcellaires. Je présenteici Molène et BEACH.

5.1 Molène

Molène [Segarra et André 2000] est une infrastruture générique pour la construction d'applica-tions mobiles et adaptatives (par rapport aux variations de l’environnement). Elle est orientée compo-sants organisés en deux sous-structures (voir Figure 11.) : Detection/Notification Framework (DNF)et Reactive Framework (RF). Alors que la première partie sert de lien avec l’environnement, le Reac-tive Framework est composé d’une partie Interaction (avec l’utilisateur), d’une partie Implementation(peut être vue comme le NF de Arch), d’un Controler contrôlant l’Interaction et l’Implementation etréalisant les choix d’adaptation. Ces choix font référence à une Adaptation Strategy qui décrit sous laforme d’un automate, les conditions d’exécution en s’appuyant à son tour sur des Transitions. UneTransition représente des variations de l’environnement ainsi que les réactions à ces variations.

Table 10. Synthèse Adraw



Migration

Cause du changement Migration


Sans objet (IFC)


Système interactif


Sans objet

53


Figure 11. Composants de Molène.

Molène, est à ma connaissance, la seule architecture à prendre en compte le concept de transi-tion. Cependant, aucun mécanisme d’aide n’est fourni au programmeur pour l’expression d’IHM detransition.

5.2 BEACH et COAST

BEACH (Basic Environment for Active Collaboration with Hypermedia) et COAST formentune infrastructure dédiée à la mise en œuvre de pièces intelligentes (Smart rooms) dont i-Land est unexemplaire [Tandler 2001]. COAST prend en charge la gestion de l’affichage, des transactions, et desobjets partagés (voir Figure 12.). Si la migration est assurée, cette infrastructure ne permet pas dereconfiguration d’IHM. Implémenté en Smalltalk, COAST est disponible en “open source”, mais estdifficile d’accès au programmeur étranger au logiciel.

Table 11. Synthèse Molène



Reconfiguration

Cause du changement Reconfiguration (et changement d’environnement)


Infrastructure et Système interactif


Infrastructure et Système interactif


Sans objet

54


Figure 12. Niveaux d’architecture BEACH/COAST.

6. Synthèse

Cette étude de l’état de l’art appelle les constats suivants :

• Aucun outil ne répond à l’ensemble des requis en matière d’IHM de transition résumés dans la"Table 1. Outil idéal pour l’expression des IHM de transition".

• Les exemples les plus avancés en matière d’IHM (i-Land, Tables Augmentée et DataTiles)négligent certaines composantes de l’IHM de transition : dans i-Land, l’expression de la migrationvers le Passage est inexistante. Avec les Tables Augmentées, la reconfiguration des représentationsdes objets entre 3D et 2D n’est pas exprimée.

Table 12. Synthèse i-Land



Migration partielle au niveau du pixel : suivi de fenêtre

Migration totale : phicon Passage

Reconfiguration : suivi de fenêtre

Cause du changement Migration partielle (pixel) et totale

Reconfiguration (rotation de fenêtre)


Infrastructure


Infrastructure


Action physique

55


• Les outils dédiés à l’adaptation dynamique des IHM, couvrent soit la reconfiguration, soit lamigration d’IHM, mais pas les deux. Une exception vaut pour BEACH, mais, avec la rotation desfenêtres, il s’agit de reconfiguration très limitée. Quand bien même ils permettent une formed’adaptation, ils n’incluent pas de techniques pour l’expression des IHM de transition.

• Les outils dédiés à l’expression de phénomènes évolutifs (Adraw, SMIL, Jazz) ou les techniquesde morphing [Beier 1992], supposent une exécution sur une plate-forme élémentaire. Les grappesne sont pas couvertes. La migration au sein d’une grappe ou entre grappes nécessite une infrastruc-ture.

Tous ces constats démontrent la pertinence de cette étude sur les IHM de transition et condui-sent naturellement au sujet du chapitre suivant avec la proposition d’un espace solution.

56

CHAPITRE 4 IHM de transition : espace de conception et réalisation

1. Introduction......................................................................................................59

2. Espace de conception.......................................................................................592.1 Compétences cognitives de l’utilisateur ..................................................592.2 Coûts humains et numériques ..................................................................602.3 Modalités pour le rendu d’IHM de transition ..........................................61

2.3.1. Modalité visuelle............................................................................612.3.2. Modalité sonore .............................................................................622.3.3. Combinaison des modalités visuelles et sonores ...........................62

3. Solutions techniques ........................................................................................633.1 Infrastructure............................................................................................633.2 Boîte à Outils pour IHM de transition .....................................................64

4. Maquette de prospective ..................................................................................654.1 Scénario d’usage ......................................................................................654.2 Choix de langage et technique d’implémentation....................................66

4.2.1. Le système interactif ......................................................................664.2.2. L’infrastructure ..............................................................................66

4.3 Modèle d’exécution .................................................................................674.3.1. Infrastructure..................................................................................674.3.2. Aspects...........................................................................................694.3.3. Exécution récapitulée.....................................................................70

4.4 Maquette : analyse critique ......................................................................70

5. Synthèse ...........................................................................................................71

57

CHAPITRE 4 : IHM de transition : espace de conception et réalisation

1. Introduction

Au chapitre 2, nous avons vu le rôle et les requis d’une IHM de transition sous la forme d’unespace problème. Une IHM de transition, on le rappelle, doit permettre à l’utilisateur d’évaluer lanature de l’adaptation de l’IHM de son système et d’en suivre l’évolution avant de poursuivre satâche. Pour que cette évaluation puisse se faire dans de bonnes conditions, l’IHM de transition :

• peut éventuellement initier une négociation avec l’utilisateur,

• doit exprimer la nature et la cause de l’adaptation : distribution (migration totale ou partielle) del’IHM, re-concentration de l’IHM, reconfiguration, expansion et réduction de ressources, mise ensommeil ou réveil,

• doit garantir la continuité spatiale, temporelle et informationnelle du processus d’adaptation.

Ces requis posés, ce chapitre propose un espace de conception comme cadre utile au choixrationnel de solutions. Cet espace fait l’objet de la section 2 complétée en 3 par la perspectivecomplémentaire de la mise en œuvre technique. En 4, nous présentons la réalisation d’une maquetteselon ces principes.

2. Espace de conception

Comme le montre la Figure 1., l’espace de conception d’IHM de transition comporte troisclasses de facteurs : la compétence cognitive de l’utilisateur cible, les coûts en terme de ressourceshumaines et numériques, et les modalités d’interaction. Ces trois points sont détaillés en séquence.

Figure 1. IHM de Transition : Espace de conception.

2.1 Compétences cognitives de l’utilisateur

L’un des paramètres à prendre en compte dans le choix d’une transition est le niveau de com-pétence cognitive de l’utilisateur. Rasmussen [Rasmussen 1986] classe les utilisateurs en trois catégo-ries reprises dans la Figure 2.:

Modalité sonore

Facteurs pour le mise enœuvre d'IHM de transition

Compétences cognitivesde l'utilisateur

Deep knowledge

Skill

Rule based

ComputationnelHumain (physique, cognitif, conatif)Coûts

Modalité visuelleModalités pour le rendud'IHM de transition

59


• skill : comportement basé sur les habiletés (réflexes),

• rule based : comportement basé sur les règles (procédés),

• deep knowledge : comportement basé sur les connaissances (savoir).

Je reprends ces trois catégories à mon compte pour les IHM de transition. Il convient de repé-rer l’utilisateur non expert (deep knowledge) qui devra faire l’objet d’une attention particulière.

Figure 2. Niveaux de compétence cognitive l’utilisateur en IHM de transition

2.2 Coûts humains et numériques

Comme le montre la Figure 3., les coûts inhérents à une transition sont de deux ordres :humains et numériques.

Parmi les coûts humains, il faut considérer les coûts physiques, cognitifs et conatifs [White-field 1991] :

• Les coûts physiques représentent l’effort que devra faire l’utilisateur pour percevoir la transition(tourner la tête, se déplacer, etc.). La nature des modalités dont il est question dans la section quisuit, sera choisie en sorte de faciliter, voire forcer, cette perception.

• Les coûts cognitifs désignent l’effort mental mis en jeu pour comprendre le rendu de la transition,c’est-à-dire franchir la distance d’évaluation au sens de Norman. L’absence d’expression desrequis, nous l’avons dit en introduction, entraîne nécessairement une surcharge cognitive (l’utilisa-teur doit combler “les trous”). Inversement, un utilisateur skill en IHM de transition, pourra réuti-liser ses compétences, allégeant ainsi la charge cognitive.

• Les coûts conatifs correspondent à l’effort de motivation auquel l’utilisateur doit faire appel pouraccomplir une tâche donnée. Cette dimension est difficile à cerner et ne concerne pas directementl’évaluation d’une IHM de transition.

Figure 3. Coûts d’une transition

Sur le plan numérique, la réalisation d’une transition s’effectue en plusieurs étapes parmi les-quelles le calcul et le choix de la transition la mieux adaptée. Les facteurs peuvent être contradictoiresentre les coûts humains, pour lesquels on dispose de peu de métriques, et les coûts de production de

Rule basedCompétences cognitivesde l'utilisateur

Deep knowledge

Skill

Coûts Humain (physique, cognitif, conatif)Computationnel

60


l’IHM de transition proprement dite. Par exemple, des calculs de morphing sur des images sont pluscoûteux en temps de calcul, que jouer un son évocateur de quelques kilo-octets ou tracer un trait à lamanière des Surfaces Augmentées de Rekimoto (encore faut-il que l’infrastructure le permette!) UneIHM de transition adaptée du point de vue cognitif et physique peut être trop coûteuse à mettre enœuvre conduisant à des temps de réponse insuffisants.

L’évaluation du coût de calcul et de mise en œuvre d’une transition est nécessaire au choix dela “meilleure” IHM de transition parmi plusieurs solutions. S’il est réaliste d’estimer les ressourcescomputationnelles, le calcul du coût humain est, dans l’état des théories de l’Interaction Homme-Machine, imprécis. En conséquence, la seule évaluation précise reste expérimentale avec des tests uti-lisateurs. Avec l’hypothèse que l’on dispose un jour de métriques générales raisonnables sur le coûthumain, il est possible d’envisager la réalisation d’un système de résolution pour une situation don-née.

Ce système de résolution pourrait être un résolveur de contraintes dans lequel seraient intro-duits les coûts computationnels supposés pour le calcul des différentes transitions mais aussi le coûtde leur mise en œuvre. Nous ajouterions aussi les coûts physiques et cognitifs inhérents à chaquetransition. Le but absolu serait alors de minimiser les coûts computationnels, physiques et cognitifs.Nous précisons “but absolu”, car en l’état, nous ne pouvons dire si l’on doit privilégier la réduction ducoût computationnel ou celui du coût physique ou cognitif. La résolution de la meilleure IHM de tran-sition est un problème à part entière que je ne prétends pas résoudre dans le cadre de ce DEA. Mais leproblème est posé.

2.3 Modalités pour le rendu d’IHM de transition

Dans le cadre de cette étude, j’entends par modalité, l’un des sens perceptifs de l’être humain.Je ne tiens compte ici que des modalités sonore et visuelle (voir Figure 4.), celles-ci servant de base àla quasi totalité des systèmes interactifs actuels. Il ne faut cependant pas ignorer les travaux en courssur l’odorat comme [France Telecom 2000], le sens tactile [Cadoz 1996], le goût étant encore peu étu-dié.

Figure 4. Modalité pour le rendu d’IHM de transition.

2.3.1. Modalité visuelle

La modalité visuelle est la plus utilisée dans les systèmes interactifs actuels. En effet, la confi-guration de base envisagée dans la plupart des systèmes considère l’existence d’un écran comme dis-positif de sortie.

Modalités pour le rendud'IHM de transition

Modalité visuelle

Modalité sonore

61


La modalité visuelle présente les avantages suivants : elle permet la représentation de donnéespersistantes et les utilisateurs n’ont pas besoin d’apprentissage dans la majorité des cas. Mais elle aaussi des inconvénients : la présence d’information sur l’écran n’implique pas que l’utilisateur lesaura vues. C’est que la modalité visuelle, au contraire du son, est évitable. La modalité visuelle aaussi des requis sur les temps d’affichage et de rafraîchissement : une vidéo (ou animation), parexemple, doit être livrée au rythme, environ, de 20 images par secondes pour être perçue commefluide [Card et al. 1983]. De plus, un stimulus visuel requiert environ 100 ms pour être perçu [Card etal. 1983].

Dans le choix et la mise en œuvre d’IHM de transitions, ces propriétés doivent être prises encompte afin de produire le rendu adéquat. En particulier si l’on sait par avance que les ressources decalcul du système ne peuvent assurer un rendu de 20 images par seconde, mieux vaut envisager uneautre modalité, tel le son, à la place d’une animation graphique.

2.3.2. Modalité sonore

La modalité sonore se présente comme un bon complémentaire à la modalité visuelle. Combi-nées, ces deux modalités peuvent permettre d’augmenter l’utilisabilité d’un système interactif[Brewster et Crease 1999].

Le son peut aussi se présenter comme un média d’ambiance. En effet, le canal auditif est tou-jours disponible à l’utilisateur et ne nécessite pas forcément d’actions physiques pour être utilisé(contrairement au visuel pour lequel l’utilisateur est obligé de se positionner face à l’écran). De plus,la zone de perception est plus étendue que la modalité visuelle. De ce fait, le son peut être utilisé pourle rendu d’informations périphériques comme dans l’Audio Aura [Mynatt et al. 1998]. Plusieursinformations peuvent ainsi être rendues, car l’utilisateur peut tirer parti de ce que l’on appelle “l’effetcocktail”. Ce dernier permet d’identifier et de se concentrer sur un son particulier parmi plusieurs,comme par exemple la partition de violoncelle dans un concert. Cet effet cocktail, expliqué dans[Bregman 1990], constitue une option intéressante pour le rendu d’IHM de transition.

Le son présente aussi des inconvénients. Impossible par exemple de réaliser un arrêt sur le son(par analogie avec un arrêt sur image), ni même trouver un son inverse (par rapport à la réversibilitéd’une vidéo). Le son étant inévitable, nous devrons aussi veiller à ne pas surcharger le canal auditif cequi provoquerait l’effet contraire aux objectifs. En effet, des sons fréquents ou répétitifs provoquentrapidement une fatigue. Enfin, l’utilisation de sons non analogiques requiert un apprentissage.

2.3.3. Combinaison des modalités visuelles et sonores

En introduction, nous avons vu que l’un des requis d’une IHM de transition est de garantir lacontinuité spatiale et temporelle. La combinaison des modalités sonores et visuelles est une optionenvisageable pour un rendu spatio-temporel des effets de transition. On peut pour cela s’inspirer destechniques de dessins animés et du cinéma.

62


Après avoir envisagé l’espace de conception côté utilisateur, analysons l’espace des solutionstechniques.

3. Solutions techniques

Dans cette analyse, je fais l’hypothèse de l’existence d’une infrastructure de type BEACHadaptée aux nouvelles formes d’interaction pour des grappes de plates-formes et capable de détecterles changements de contexte d’interaction. L’analyse se limite au problème particulier de la mise enœuvre d’IHM de transition. Comme annoncée au chapitre 2, la réalisation de l’IHM de transition peutrevenir à l’infrastructure, au système interactif, ou à une combinaison des deux. Lorsque l’infrastruc-ture se charge de l’IHM de transition, je parle de système interactif “transition unaware”. Dans lesdeux autres cas, on assiste à un système interactif de type “transition aware”. La Figure 5. représenteles deux situations affinée chacune en deux sous-cas. Chaque feuille désigne une solution d’implé-mentation.

Figure 5. Solutions pour la mise en œuvre d’IHM de transition dans les systèmes interactifs.

Qu’il s’agisse d’un système interactif “transition aware” ou d’un système interactif “transitionunaware”, je propose, avec l’hypothèse d’une infrastructure idoine, le développement de boîtes àoutils (BAO) spécialisées dans le rendu d’IHM de transition. Reprenons ces deux points : infrastruc-ture (élément commun aux différentes solutions) et boîtes à outils en mettant l’accent sur les particu-larités de chacune.

3.1 Infrastructure

L’infrastructure représente l’ensemble des composants logiciels exécutables nécessaires à lamise en œuvre des différentes formes d’adaptation étudiées dans ce mémoire. Dans ce qui suit, leterme serveur désigne un service que devra rendre l’infrastructure.

Système interactif "transitionaware"

Système interactif "transition unaware"

IHM de transition dans les SystèmesInteractifs

BAO pour le développement BAO pour la génération BAO + runtime BAO + mécanismes de transformation de code

BAO intégrée dans ARTStudio+ Infrastructure

BAO type Swing / Jazz+ Infrastructure

BAO intégrée dans la JVM+ Infrastructure

BAO + AOP+ Infrastructure

a b c d

63


Cette infrastructure devra comprendre :

• Un serveur de contexte [Rey 2001] permettant à l’infrastructure elle-même, ainsi qu’au systèmeinteractif, d’obtenir des informations sur le contexte d’interaction. Typiquement, il s’agit de lalocalisation du (des) utilisateur(s), de la lumière et bruit ambiants, etc. Ces données sont partagéesavec le serveur de grappe et le serveur d’adaptation.

• Le serveur de grappe est une machine abstraite d’interaction qui, d’une part masque au program-meur de système interactif, l’hétérogénéité multiplate-forme sous-jacente, et d’autre part constitueun environnement d’exécution qui assure la migration d’IHM et gère l’arrivée et le départ de res-sources.

• Le serveur d’adaptation est chargé des reconfigurations et de la mise en œuvre des IHM de transi-tion. Celui-ci doit donc fournir (grâce au serveur de contexte) toutes les informations nécessairesaux calculs de plasticité (plate-forme cible : type (OS), ses ressources physiques (taille d’écran,CPU, par exemple), ...) et cela quel que soit le type d’IHM visée (pré-calculée, hybride, dynami-que). Le serveur peut aussi être utilisé comme calculateur (la résolution de la plasticité étant coû-teuse en ressources); dans ce cas, le système interactif possède des mécanismes pour être adapté,mais n’embarque pas, par exemple, de résolveur. Ce dernier pourra être fourni par le serveurd’adaptation. Il est également susceptible d’être utilisé pour les calculs et la mise en place des IHMde transition en collaboration avec le serveur de grappe. Ce serveur fera l’objet d’une attentionparticulière dans les perspectives de cette étude.

3.2 Boîte à Outils pour IHM de transition

Dans le contexte de cette étude, le rôle d’une Boîte à Outils (BAO) est de fournir lesmécanismes nécessaires à la mise en œuvre d’IHM de transition, par exemple :

• la transition d’un interacteur sur lui-même (lors de son redimensionnement par exemple),

• la transition entre deux interacteurs de capacité représentationnelle équivalente (par exemple entreun champ de saisie et une “list box”),

• la transition entre deux colonies d’interacteurs,

• la transition lors de changements de position ou de réorganisation d’interacteurs,

• la transition spatiale d’une surface à une autre,

• la transition entre deux tâches,

• etc.

Comme le montre la Figure 5., la nature et l’utilisation d’une “BAO pour IHM de transition”diffèrent. Prenons d’abord le cas des systèmes interatifs construits avec une représentation explicitedes IHM de transition (systèmes interactifs de type “transition aware”) :

• Cas de la Figure 5.a). La BAO peut être une API (Application Programming Interface) du typeAWT/Swing [SUN/J2SE] ou Jazz [Bederson et al. 2000]. Elle doit permettre d’implémenter unsystème interactif capable de réaliser lui-même les IHM de transition (au-dessus d’un serveur degrappe), ou bien de fournir des éléments (description, pointeurs, ..) suffisants au serveur d’adapta-tion (et de transition) afin qu’il réalise lui-même les IHM de transition. Cependant, les requis enmatière de plasticité poussent vers l’utilisation de générateurs d’IHM plastiques.

64


• La Figure 5.b) correspond au cas de la génération d’IHM répondant au requis “spécifier une fois,générer n fois” [Thevenin et Coutaz 1999]. Ainsi en intégrant une BAO pour IHM de transition àun outil comme ARTStudio [Calvary et al. 2001], il devient possible de générer des IHM pré-cal-culées intégrant directement les IHM de transition. Les interacteurs multimodaux de [XXdead’olfa] relèvent de cette approche.

Etudions maintenant les cas des systèmes interactifs “transition unaware” :

• Cas de la Figure 5.c. Il est envisagé ici de créer un environnement d’exécution (ou de modifier unenvironnement existant) qui permet de manipuler directement les systèmes interactifs et permettreainsi à ces systèmes de réaliser des transitions. Nous pourrions entrevoir ce type de solution enmodifiant, par exemple, le comportement de la machine virtuelle java (Java Virtual Machine) en yajoutant des mécanismes d’IHM de transition. Ce principe est à la base de JAC [JAC], qui intègredes mécanimes de programmation par aspect mais en fournissant un environnement d’exécution(différents de la JVM classique de Java). L’intérêt d’une telle solution réside dans la possibilité deréaliser une adaptation du code source en cours d’exécution (sans recompilation préalable).

• Cas de la Figure 5.d. Le code source de l’application est modifié a posteriori afin d’y intégrer lesIHM de transition. Cette solution, moins lourde que la précédente, permet de rendre “transitionaware” un système interactif qui ne l’est pas à l’origine. La programmation par aspect sert de sup-port technique à cette approche [Kiczales et al. 2001] [AspectJ]. Nous l’avons appliquée à unemaquette de prospective.

4. Maquette de prospective

L’objet de cette maquette est de montrer l’utilité d’une infrastructure sommaire pour des ren-dus de reconfiguration et de migration pour le cas de systèmes interactifs “transition unaware”. Lamaquette n’inclut pas de serveur d’IHM de transition (complet) ou ni de BAO d’IHM de transition.Cette contribution technique doit se voir comme une première pierre à l’adaptation dynamique et à lamise en place d’IHM de transition. Dans un premier temps, nous repréendrons notre scénario d’usagepour créer une suite nous servant de support à l’implémentation, puis nous discuterons nos différentschoix avant d’aborder notre modèle d’exécution.

4.1 Scénario d’usage

Le scénario d’usage choisi pour cette maquette s’inscrit dans la continuité du scénario du cha-pitre 2 sur l’espace problème d’une IHM de transition. Rappelons-nous, Cathy et ses collèguesréfléchissent à la structure de leur prochain article de recherche à l’aide du Tableau Magique. Après laréunion, Cathy se retrouvant seule et désireuse de continuer, fait migrer le contenu du tableau sur sastation de travail.

Nous prolongeons le scénario comme suit : Cathy lance des impressions qu’elle compterécupérer avant de rentrer chez elle. Elle décide de faire migrer son travail de la station de travail versson ordinateur portable. Une fois chez elle, elle compte reprendre son travail sur le portable qu’elle

65


retrouvera dans le même état que sur la station de travail. Le système d’exploitation de la station de

travail est Microsoft Windows tandis que celui du portable est Mac Os X.

Autrement dit, nous assistons à une migration totale entre deux plates-formes compatiblesd’une même grappe (il s’agit de stations de travail aux ressources similaires), mais hétérogènes sur leplan des systèmes d’exploitation et des boîtes à outils graphiques. En conséquence, les IHM des sys-tèmes interactifs exécutables sur ces stations divergent par la Présentation Physique.

En résumé, l’IHM de transition doit exprimer deux phénomènes pour un système interactif“transition unaware”, mais portable :

• d’une part, la migration totale avec reprise au niveau de l’action physique,

• d’autre part, la reconfiguration de la Présentation Physique du système interactif.

4.2 Choix de langage et technique d’implémentation

On détaille successivement des choix techniques d’implémentation en partant des propriétésdu système interactif pour justifier ceux de l’infrastructure.

4.2.1. Le système interactif

Le système interactif est “transition unaware” mais portable : réalisé en Java [SUN/J2SE], lesystème interactif hérite de facto l’adaptation de sa Présentation Physique grâce à la machine Java/AWT.

4.2.2. L’infrastructure

Dans le cadre de ce DEA, l’objectif est de réaliser une infrastructure minimale qui permet de“rendre plastique et multi-surface” des applications qui “n’embarquent” pas de mécanismes de plasti-cité ni de rendu d’IHM de transition. Ce choix minimaliste est motivé par le fait que nous disposeronsà terme (travaux de l’équipe IIHM) d’une machine abstraite d’interaction prenant en charge la gestiondes ressources et la migration d’IHM entre les plates-formes d’une grappe. Comme nous l’avons vudans la Figure 5., la mise en œuvre d’IHM de transition pour des systèmes interactifs “transitionunaware”, relève de deux approches. Avec nos objectifs de simplicité, la solution de la Figure 5.d)s’impose : BAO + AOP + infrastructure.

Le système interactif étant réalisé en Java, j’ai retenu AspectJ [AspectJ] comme langaged’AOP. Un aspect permet d’exprimer une propriété transversale à toutes les classes (et leurs instan-ces) en-dehors de ces classes. La programmation par aspect permet de “capturer” l’entrée ou la sortiedes méthodes spécifiées dans un point de jonction pour effectuer un traitement particulier. Ce faisant,le programmeur d’aspect peut modifier le comportement d’un programme pré-existant sans modifierce code de manière directe. Dans le cas d’AspectJ, toutefois, le code source est instrumenté par les

66


aspects et doit être recompilé. Il n’est donc pas possible de changer d’aspect en cours d’exécution.(D’autres approches de la programmation par aspect (en Java) proposent une modification de lamachine virtuelle, présentant l’avantage de ne pas avoir à recompiler le code de l’application source).

La Figure 6. présente la structure générale de la maquette: le code source Java (transitionunaware) du système interactif, l’infrastructure pour la prise en charge de la migration et de l’IHM detransition, des aspects permettant de manipuler le système interactif source pour l’expression del’IHM de transition.

Figure 6. Structure générale du mécanisme de mise en œuvre d’IHM de transition de la maquette.

Nous allons maintenant détailler le modèle d’exécution des composants “infrastructure” et“Aspects”.

4.3 Modèle d’exécution

La structure d’exécution que je propose s’appuie sur un modèle client-serveur à raison d’unclient par plate-forme élémentaire. Ce client inclut le système interactif original instrumenté desAspects. Je présente en détail la structure de l’infrastructure, le rôle des Aspects, puis le protocole decommunication.

4.3.1. Infrastructure

Comme le montre la Figure 7., l’infrastructure comprend un Serveur de Transition (ST) quicoordonne un ensemble de Clients de Transition (CT) à raison d’un CT par plate-forme élémentaire. .Le ST et les CT sont constitués de threads communiquant par socket.

Codesource dusystèmeinteractif

InfrastructureAspects

67


Figure 7. L’infrastructure et ses relations avec le système interactif original.

Un client de transition a la charge de :

• La communication entre les aspects et le serveur de transition,

• L’envoi de données propres à la plate-forme (seulement la surface d’affichage pour notre proto-type), ces informations seront fournies à terme par le serveur de contexte,

• L’arrêt/reprise de système interactif,

• L’expression des IHM de transition.

Le serveur de transition a pour rôle :

• La coordination des clients (qui coopèrent pour le rendu de l’IHM de transition),

• La représentation des relations spatiales entre les clients (normalement à l’aide d’un serveur decontexte. Pour l’instant, il s’agit d’un choix fait dynamiquement par l’utilisateur.).

Le serveur comprend un thread qui permet aux clients de se connecter pour être ensuite rediri-gés sur un port particulier pour une liaison privilégiée au serveur. Cette liaison privilégiée est assuréepar un thread chargé de l’écoute sur le port dans l’attente de messages, envoyés de manière asyn-chrone, par le client. Nous avons ainsi un thread dédié à chaque client.

Chaque client est constitué d’un thread à l’écoute du serveur pour traiter ses requêtes (parexemple, l’arrêt/reprise de système interactif). Un autre thread, par système interactif, est à l’écoute

Client detransition

CT1

Serveur de transitionST

Connecté

ApplicationA1

Aspects

Connecté

Plate-forme 1

Client detransition

CT2

ApplicationA1'

Aspects

Connecté

Plate-forme 2

Connecté

68


des messages provenant du système interactif, comme la demande de transition. Le dernier maillon dela chaîne sont les “aspects” présentés maintenant.

4.3.2. Aspects

Les aspects servent de lien entre le système interactif et l’infrastructure. Dans notre maquette,ils assurent les fonctions suivantes :

• Connexion entre l’application et l’infrastructure,

• Fourniture d’une image (bitmap) représentant l’état courant de l’application,

• Sauvegarde/restauration de l’état du système interactif,

• Transmission d’événement pour le déclenchement de l’IHM de transition.

Le processus de connexion des aspects au client de transition est similaire à celui du client detransition vers le serveur de transition : dans un premier temps, il y a ouverture d’une socket prédéfi-nie, puis le client de transition redirige les aspects vers une socket dédiée. Dans la pratique, la partie“aspects” crée un thread d’écoute des messages en provenance du client de transition. Ainsi “le sys-tème interactif” pourra réagir à des événements du type : “quel est ton état ?”, “ferme l’application”,etc.

Nous obtenons le schéma de communication de la Figure 8. Les Reader sont les écouteurs surles sockets. Le lien interrogation représente la phase de connexion sur le port socket prédéfini.

Figure 8. Schéma de communication de l’infrastructure.

Connecté

Aspects

Reader

Serveur de transition

Reader Reader

Interrogation

Client de transition

Reader

Reader Reader

ConnectéInterrogation

69


Après avoir détaillé les différents composants de la maquette, voici un récapitulatif représen-tant l’exécution de notre scénario et en particulier la phase d’initialisation

4.3.3. Exécution récapitulée

Au départ, le serveur de transition ST est lancé sur une machine identifiée. ST ouvre alors unesocket sur un port prédéfini dans l’attente de connexions de clients de transition. Lors du démarraged’une plate-forme, un client de transition CT est lancé. Il se connecte au serveur de transition sur leport prédéfini. Lorsque la connexion est établie, le serveur redirige le client vers un autre port afin decréer une connexion privilégiée entre lui et le client et libère le port de connexion (commun à tous lesclients pour le “premier contact”).

Les systèmes interactifs que nous voulons rendre “transition aware” ont été recompilés avecAspectJ pour inclure les fragments de code permettant les IHM de transition. Au lancement d’un telsystème interactif, une connexion entre le système interactif instrumenté et le client de transition estréalisée. Le principe est le même qu’entre ST et CT, c’est-à-dire connexion sur un port prédéfini puisconnexion sur un autre port. A ce moment-là, le système interactif est disponible.

Lorsque l’utilisateur exprime son désir de faire migrer le système interactif, (dans la maquette,par la frappe d’une combinaison de touches), un déclencheur de transition est envoyé au client detransition, puis vers le serveur de transition qui détermine la plate-forme cible. Le serveur de transi-tion envoie ensuite ses ordres aux clients de transition afin de générer le rendu propre à la reconfigu-ration et à la migration. L’hypothèse est que tous les clients de transition sont capables de produirel’IHM de transition demandée par le serveur de transition.

A la fin de la transition, l’application source (son état) a migré vers la plate-forme cible etl’utilisateur reprendre la tâche suspendue.

4.4 Maquette : analyse critique

Certains choix techniques retenus pour la maquette sont discutables au regard de l’état del’art, en matière de code mobile notamment. Mais la mobilité n’est pas le sujet de cette étuded’autant, qu’à termes, l’infrastructure inclura une machine d’interaction abstraite développée parailleurs dans l’équipe. Les choix effectués ont été motivés par la simplicité de programmation et ladisponibilité des outils sans nous préoccuper des performances.

L’approche par AOP est intéressante pour des systèmes interactifs “transition unaware” ennombre dominant pour l’instant. Mais il conviendrait d’en étudier les limites : en particulier, peut-t-ontraduire en AOP tous les requis d’une IHM de transition ?

L’organisation générale, en serveur de transition et clients de transition, constitue une implé-mentation possible des différents services identifiés dans l’espace des solutions techniques de la sec-tion 3. Inversement, certaines informations, comme la taille de l’écran fournie, dans l’exemple de lamaquette, par le système interactif, transgresse volontairement les règles : dans notre modèle de lasection 3, ces informations devront être produites par le service de contexte). La maquette servira

70


aussi à étudier plus avant la nature des échanges entre les différentes classes de composants (ST, CTet Système interactifs par le biais de leurs Aspects).

Sur le plan de l’utilisabilité, la maquette offre l’avantage de tester le bien fondé d’IHM detransition auprès d’utilisateurs.

5. Synthèse

Dans ce chapitre, nous avons étudié l’espace de conception d’IHM de transition tant du pointde vue de l’utilisateur que du point de vue logiciel.

Côté utilisateur, la notion de coûts, bien que difficile à cerner, et les propriétés des modalitéssont des facteurs importants dans le choix du rendu d’une IHM de transition. Un rapide survol desmodalités nous a notamment appris que le son permet de représenter des données spatiales et qu’ilconstitue un bon complément à la modalité visuelle. Si les qualités des modalités visuelles et audioont été étudiées pour les plates-formes élémentaires (avec un utilisateur face à un écran de station detravail), il n’en va pas de même pour l’informatique diffuse et les grappes de plates-formes : toutl’espace devient alors un lieu d’interaction. A l’heure actuelle, nous ne sommes pas armés pourrépondre à cette question. Le cinéma devrait être source de solutions pour traiter les coupures spatia-les et temporelles. Par exemple, les références de S.M. Eisenstein considéré comme l’un des maîtresen la matière, devraient nous être utiles.

Côté logiciel, la notion de Boîte à Outils d’IHM de transition constitue un point clef. Les dif-férents modes d’implémentation envisagés laissent cependant penser qu’il sera indispensable de met-tre en œuvre, en plus d’une BAO, une infrastructure supportant les transitions. Cette dernière nepourra cependant pas fonctionner de façon autonome et devra être intégrée à une infrastructure glo-bale incluant les services de gestion de grappe et de contexte. Notre serveur d’IHM de transitiondevra en plus être étudié conjointement à un service ou à des mécanismes d’adaptation dynamique.

71

CHAPITRE 5 Conclusion

1. Synthèse de la contribution..............................................................................75

2. Perspectives......................................................................................................76

73

CHAPITRE 5 : Conclusion

Cette étude sur les IHM de transition traite un problème nouveau, conséquence des progrès del’informatique diffuse. Avec l’informatique diffuse, l’Interface Homme-Machine d’un système inte-ractif devient plastique et se voit répartie dynamiquement entre les ressources de multiples plates-for-mes. Si l’on se réfère aux principes fondamentaux de la Théorie de l’Action, l’utilisateur doit être enmesure d’évaluer et de suivre le processus de reconfiguration et de migration d’une IHM. C’estl’objet des IHM de transition.

Ce chapitre de conclusion résume ma contribution sur le sujet, puis présente les perspectivespour de futures recherches en thèse.

1. Synthèse de la contribution

Les contributions de cette étude sont essentiellement de nature conceptuelle. J’ai introduit leconcept d’IHM de transition pour lequel je propose une définition formelle complétée d’un espaceproblème. Cet espace, qui couvre à la fois les perspectives utilisateur et logiciel, sert deux rôlescomplémentaires : 1) comme cadre de référence à l’analyse des solutions existantes en matièred’IHM de transition, 2) comme expression explicite des requis des IHM de transition. En regard del’espace problème, j’ai proposé un espace de conception qui structure de manière rationnelle leschoix de solution. Comme pour l’espace problème, j’ai considéré la double perspective utilisateur etlogiciel.

Voici en résumé le détail de ces contributions :

• Définition formelle d’une IHM de transition : Une IHM de transition Tr entre l’état initial Ei etl’état final Ef du système est une fonction déclenchée par un changement de contexte d’interactionet qui assure le passage de Ei à Ef . Le passage de Ei à Ef peut se faire en une étape : on assiste alorsà une IHM de transition élémentaire. Lorsqu’elle comporte plusieurs étapes, l’IHM de transitionest dite composée. Une IHM de transition, élémentaire ou composée, a pour fonction première depermettre à l’utilisateur d’évaluer l’adaptation du système interactif, consécutive à un changementde contexte d’interaction.

• L’espace problème des IHM de transition couvre les dimensions suivantes : le déclencheur duchangement de contexte (utilisateur, système) ; la nature du changement de contexte d’interaction(changement d’environnement physique, de plate-forme ou des relations entre utilisateur-environ-nement- plate-forme) ; l’observabilité du rendu de l’IHM de transition (présence ou non d’unenégociation préalable avec l’utilisateur, expression de l’élargissement ou du rétrécissement desressources disponibles, expression des phénomènes de migration et de reconfiguration, mise ensommeil ou réveil de la plate-forme) ; composants logiciels impliqués (système interactif, infras-tructure). Ces dimensions ont permis d’analyser et de relever les lacunes des techniques existantesparmi les plus représentatives : exemples d’IHM de transition, outils de spécification, boîtes àoutils et infrastructures.

• L’espace de conception des IHM de transition inclut : les coûts cognitifs et computationnels demise en œuvre, les compétences cognitives de l’utilisateur, les propriétés des modalités de rendu(son et image), et quatre approches à la mise en œuvre technique selon que le système interactif est

75

CHAPITRE 5 : Conclusion

“transition aware” ou “transition unaware”. La réalisation d’une maquette simple a permisd’explorer ces idées.

Si cette étude présente l’intérêt de poser un concept nouveau (IHM de transition), et d’en pro-poser des éléments conceptuels de base utiles à sa maîtrise et à sa mise en œuvre, il n’offre pas desolution technique solide, ni un cadre systématique pour l’évaluation de l’efficacité des IHM de tran-sition du point de vue de l’utilisateur. Ces deux points justifient les perspectives suivantes.

2. Perspectives

Les perspectives se répartissent en deux activités complémentaires mais fortement corréléesavec les perspectives logiciel et utilisateur :

• Dans le rapport nous avons identifié deux composants prépondérants : une boîte à outils d’IHM detransition et l’infrastructure. Pour cette dernière, il semble important de fournir un serveur dereconfiguration et un serveur d’IHM de transition embarquant un résolveur de contraintes visant la“meilleure” transition tout en respectant le requis du temps de réponse. L’ensemble de ces servicesdevra être intégré à la future machine abstraite d’interaction développée dans l’équipe IIHM.

• Du point de vue de l’utilisateur, il convient d’approfondir la nature des négociations et doncd’être capable de prévoir les effets de bord du changement de contexte d’interaction, de même queles coûts humains de ces négociations, trouver notamment le bon équilibre entre la négociation quiallonge la trajectoire d’interaction et les effets de surprise. Il conviendra de produire des heuristi-ques d’utilisation des négociations dans les IHM de transition. Plus généralement, on sera conduità créer des patrons d’IHM de transition, explorant les modalités et le savoir-faire en cinéma afind’assurer la continuité spatio-temporelle. Ces patrons devront faire l’objet d’évaluation par l’expé-rimentation auprès de réels utilisateurs.

En synthèse, ce travail de DEA a permis d’identifier différentes pistes de faisabilité vers unerecherche approfondie et systématique dans le cadre d’une thèse.

76

Table des matières

Remerciements ........................................................................................... 3

Plan ............................................................................................................. 5

Introduction .................................................................................7

1. Sujet .........................................................................................................................92. Justification ..............................................................................................................93. Objectifs et approche .............................................................................................104. Organisation du rapport .........................................................................................11

La notion d’IHM de transition et son espace problème ........13

1. Introduction ...........................................................................................................152. Un scénario d’usage ..............................................................................................153. IHM de transition ..................................................................................................16

3.1 Rappels : tâche utilisateur et Arch ..................................................................163.1.1. Tâche ......................................................................................................163.1.2. Le modèle Arch ......................................................................................17

3.2 IHM de transition : définition .........................................................................173.2.1. IHM de transition élémentaire ...............................................................18

3.3 IHM de transition composée ...........................................................................183.4 Interruptibilité d’une IHM de transition composée ........................................20

4. IHM de transition : espace problème .....................................................................214.1 Déclencheur du changement de contexte ........................................................224.2 Observabilité d’une transition .........................................................................234.3 Nature du changement de contexte d’interaction ...........................................23

4.3.1. Plate-forme élémentaire et grappe de plates-formes ..............................234.3.2. Changement de plate-forme ...................................................................27

4.4 Composants système impliqués. .....................................................................315. Synthèse .................................................................................................................32

IHM de transition : exemples et outils de l’état de l’art ........35

1. Introduction ...........................................................................................................372. Exemples d’IHM de transition ..............................................................................38

2.1 Mac Os X“ ......................................................................................................382.2 Surfaces augmentées et DataTiles de Rekimoto .............................................412.3 i-Land ..............................................................................................................43

3. Outils de Spécification ..........................................................................................463.1 Seescoa XML ..................................................................................................463.2 Cicero ..............................................................................................................47

3.3 QTk .................................................................................................................483.4 SMIL 2.0 .........................................................................................................50

4. Boîtes à outils ........................................................................................................514.1 Multimodal Toolkit .........................................................................................514.2 Jazz ..................................................................................................................524.3 Adraw ..............................................................................................................52

5. Infrastructures ........................................................................................................535.1 Molène ............................................................................................................535.2 BEACH et COAST .........................................................................................54

6. Synthèse .................................................................................................................55

IHM de transition : espace de conception et réalisation ........57

1. Introduction ...........................................................................................................592. Espace de conception .............................................................................................59

2.1 Compétences cognitives de l’utilisateur .........................................................592.2 Coûts humains et numériques .........................................................................602.3 Modalités pour le rendu d’IHM de transition .................................................61

2.3.1. Modalité visuelle ....................................................................................612.3.2. Modalité sonore ......................................................................................622.3.3. Combinaison des modalités visuelles et sonores ...................................62

3. Solutions techniques ..............................................................................................633.1 Infrastructure ...................................................................................................633.2 Boîte à Outils pour IHM de transition ............................................................64

4. Maquette de prospective ........................................................................................654.1 Scénario d’usage .............................................................................................654.2 Choix de langage et technique d’implémentation ...........................................66

4.2.1. Le système interactif ..............................................................................664.2.2. L’infrastructure ......................................................................................66

4.3 Modèle d’exécution ........................................................................................674.3.1. Infrastructure ..........................................................................................674.3.2. Aspects ...................................................................................................694.3.3. Exécution récapitulée .............................................................................70

4.4 Maquette : analyse critique .............................................................................705. Synthèse .................................................................................................................71

Conclusion ..................................................................................73

1. Synthèse de la contribution ...................................................................................752. Perspectives ...........................................................................................................76

Table des matières .................................................................................... 77

Bibliographie ............................................................................................ 791. Références littéraires .............................................................................................792. Références sur Internet ..........................................................................................83

Bibliographie

1. Références littéraires

[Arens et Hovy 1995]Y. Arens et E. Hovy, The Design of a Mode-Based Multimedia Interaction Manager. Paru dans Artificial Intelligence Review, v°9, n°2-3, pp.167-188.

[Balbo 1994]Sandrine Balbo, Evaluation ergonomique des interfaces utilisateur : un pas vers l’automatisation, Thèse de l’Université Joseph Fourier, Grenoble 1, 5 septembre 1994.

[Bass 1991]L. Bass, R. Little, R. Pellegrino, S. Reed, R. Seacord, S. Sheppard, The Arch Model : Seeheim Revisited (version 1.0). The UIMS Tool Developers Workshop (Avril 1991) in ACM SIGCHI Bulletin Vol.24, No 1, Janvier 1992.

[Bederson et al. 2000]Benjamin B. Bederson, Jon Meyer, Lance Good, Jazz: An Extensible Zoomable User Interface Graphics ToolKit in Java, in Proceedings of UIST 2000, ACM, New York.

[Beier 1992]Thaddeus Beier, Feature-Based Image Metamorphosis, in Porceedings of SIGGRAPH’92, pp. 35-42, 1992.

[Bérard 1999]François Bérard, Vision par ordinateur pour l’interaction homme-machine fortement couplée, Thèse de l’université Joseph Fourier, Grenoble 1, 1999.

[Bregman 1990]Albert Bregman, Auditory Scene Analysis: The Perceptual Organization of Sound., MIT Press, 1990.

[Brewster et Crease 1999]S.A. Brewster, M.G. Crease, Correcting menu usability problems with sound, Behaviour and Technology, vol. 18, n° 3, pp 165-177, 1999.

[Cadoz 1996]C. Cadoz, Réintroduire les sensations physiques, La Recherche, n°285, pp. 80-84, mars 1996.

79

[Calvary et al. 2001]G.Calvary, J. Coutaz, D. Thevenin, A Unifying Reference Framework for the Development of Plastic User Interfaces, in Proceedings of the 2001 Engineering of Human-Computer Interaction Conference, EHCI'2001.

[Card et al. 1983]S.K. Card, T.P. Moran, A. Newell, The Psychology of Human-Computer Interaction, 1983.

[Coutaz 2001]Joëlle Coutaz, Cours de Modélisation en Interaction Homme-Machine, 2001.

[Crease et al. 2000]M.Crease, P.D. Gray, S.A. Brewster, A Toolkit of Mechanism ans Context Independant Widgets. Actes du workshop Design, Specification, and Verification of Interactive Systems, DSVIS’00, 2000, pp. 121-133.

[Crowley et al. 2002]James L. Crowley, Joëlle Coutaz, Gaeten Rey, Patrick Reignier, Perceptual Components for Context Aware Computing, to appear in Ubicomp 2002.

[Daassi 2002]Olfa Daassi, Les Interacteurs en plasticité des interfaces homme-machine, rapport de DEA d’Informatique Systèmes et Communications, Université Joseph Fourier, Grenoble I, 2002.

[Gamma et al. 1995]E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software. Chez Addison-Wesley Professional Computing series, 1995.

[Grolaux et al. 2001]D. Grolaux, P. Van Roy and J. Vanderdonckt, QTk : An Integrated Model-Based Aproach to Designing Executable User Interfaces. Acte de la conférence Design, Specification, ans Verification of Interactive Systems, DSVIS’01, 2001.

[Ishii et Ullmer 1997]Hiroshi Ishii , Brygg Ullmer,Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms, in Proceedings of ACM CHI '97, pp. 22-27, 1997.

[Johanson 2000]B. Johanson, G. Hutchins, T. Winograd, PointRight: A System for Pointer/Keyboard Redirection among Multiple Displays and Machines, tech. report CS-2000-03, Computer Science Dpt., Stanford Univ., Cal., 2000.

[Kiczales et al. 2001]Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm and William G. Griswold, An Overview of AspectJ, appears in ECOOP 2001, pp.327-353.

80

[Kolski 2001]C. Kolski, Analyse et conception de l'IHM, Interaction pour les Systèmes d'Information, volume 1, L. Nigay, J. Coutaz, Chap 7, Architecture logicielle conceptuelle des systèmes interactifs, mai 2001.

[Lachenal 2002]Christophe Lachenal, Requis logiciels pour l’Interaction Multi-Surface, soumis à IHM’2002, 2002.

[Larrousse]Encyclopédie Larousse.

[Luyten et Coninx 2001]K. Luyten et K. Coninx, An XML-based runtime user interface description language for mobile computing devices. Acte de la conférence Design, Specification, ans Verification of Interactive Systems, DSVIS’01, 2001.

[Maloney et Smith 1995]John H. Maloney, Randall B. Smith, Directness and Liveness in the Morphic User Interface Construction Environment, Acte de la conférence User Interface Software & Technology, UIST’95, pp. 21-28, 1995.

[Myers et al. 2000]Myers, B., et al. Collaboration using multiple PDA’s connected to a PC. In Proceedings of the ACM Conference on CSCW (CSCW98), (1998), pp. 285-294.

[Mynatt et al. 1998]Elizabeth D. Mynatt, Maribeth Back, Roy Want, Designing Audio Aura, in Proceedings of ACM CHI’98, pp 566-573, 1998.

[Nigay et Coutaz 1996]L. Nigay, J. Coutaz Espaces conceptuels pour l’interaction multimédia et multimodale, TSI, spécial Multimedia et Références littéraires Collecticiel, AFCET&Hermes Publ., Vol 15(9), 1996, pp. 1195-1225.

[Norman 1986]Donald Norman, User Central System Design, 1986.

[Rasmussen 1986]J. Rasmussen, Information Processing and Human-Machine Interaction, North-Holland, New York, 1986.

[Rekimoto 1999]Jun Rekimoto, Masanori Saitoh, Augmented Surfaces : A Spatially Continuous Work Space for Hybrid Computing Environments, in Proceedings of ACM CHI’99, pages 378-385, May 1999.

[Rekimoto 2001]Jun Rekimoto, Brygg Ullmer, Haruo Oba, DataTiles : A Modular Platform for Mixed Physical and Graphical interactions, CHI’2001, 31 March 2001.

81

[Rey 2001]Gaëtan Rey, Systèmes interactifs sensibles au contexte, rapport de DEA d’Informatique Systèmes et Communications, Université Joseph Fourier, Grenoble I, 2001.

[Robertson et al. 1991]George G. Robertson, Jock D. Mackinlay, and Stuart K. Card, Cone Trees : Animated 3D Visualizations of Hierarchical Information, in Proceedings of ACM CHI’91, pp 189-194, 1991.

[Streitz et al. 1999]N. A. Streitz, J. Geißler, T. Holmer, S. Konomi, C. Müller-Tomfelde, W. Reischl, P. Rexroth, P. Seitz, R. Steinmetz, I-LAND: An interactive landscape for creativity and innovation, in Proceedings of the ACM CHI’99, pp. 120-127, 1999.

[Tandler 2001]Tandler Peter, Software Infrastructure for Ubiquitous computing Environments : Supporting synchronous Collaboration with Heterogenous devices, in Proceedings of UBICOMP 2001.

[Thomas et Calder 2001]Bruce H. Thomas, Paul Calder, Applying Cartoon Animation Techniques to Graphical User Interfaces, Published in : ACM Transactions on Computer-Human Interaction, Vol. 8, No. 3, September 2001.

[Thevenin et Coutaz 1999]D. Thevenin, J. Coutaz, Plasticity of User Interfaces : Framework and research Agenda, dans les actes de la septième conférence IFIP on Human Computer Interaction, Interact’99, edinburgh, Ecosse, pp. 110-117, 1999.

[Thevenin 2001]David Thevenin , Adaptation en Interaction Homme-Machine : le cas de la plasticité, Thèse de l’université Joseph Fourier, Grenoble 1, 21 décembre 2001.

[Segarra et André 2000]Maria-Theresa Segarra, Françoise André, A Framework for Dynamic Adaptation in Wireless Environments, Workshop on Software Engineering and Mobility, ICSE01,Toronto, May 2001.

[Want et Shilit 2001]R. Want, B. Shilit, Expanding the Horizons of Location-Aware Computing, IEEE Computer, 34(8), pp. 31-34, august 2001.

[Weiser 1991]M. Weiser.The Computer for the 21rst century, Scientific American, 265(3), 1991, pp. 94-104.

[Whitefield 1991]A. Whitefield, F. Wilson & J. Dowell, “A framework for human factors evaluation”, Behaviour and information technology, vol. 10, no. 1, pp. 65-79, 1991.

82

2. Références sur Internet

[Aqua Guide]Aqua Human Interface Guidelines, 2001.http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/index.html

[AspectJ]http://aspectj.org/

[Cameleon]Cameleon Project.http://www.plasticity.org

[France Telecom 2000]http://www.francetelecom.com/vfrance/actualite/commdosp/actu270900.htm

[Grolaux 2000]D. Grolaux, FlexClock. http://www.info.ucl.ac.be/people/ned/flexclock/

[i-Land]http://www.ipsi.fhg.de/ambiente/i-land.html

[JAC]Java Aspect Components.http://www.jac.aopsys.com/

[Mac Guide]Macintosh Human Interface Guidelines, Addison-Wesley Publishing Company,1995.http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html

[Mac Os X]http://www.apple.com/macosx/

[Mac Os X Theater]http://www.apple.com/macosx/theater/

[Mozart]The Mozart Programming system.http://www.mozart-oz.org/

[Rekimoto]Rekimoto personnal web page.http://www.csl.sony.co.jp/person/rekimoto.html

83

[SMIL 2.0]Synchronized Multimedia Integration Language (SMIL 2.0), W3C Recommendation 07 August 2001.http://www.w3.org/TR/2001/REC-smil20-20010807/

[SMIL 2.0 TestSuite]http://www.w3.org/2001/SMIL20/testsuite/s2transition.html

[SUN/J2SE]Java 2 Standard Edition.http://java.sun.com/j2se/1.3/docs/

84

Institut National Polytechnique de Grenoble U.F.R...

Documents

Transcript of Institut National Polytechnique de Grenoble U.F.R...