Nous passons en revue les outils de codage selon les termes de notre taxonomie : boîtes à outils graphiques abstraites, boîtes à outils multi-modales avec Multimodal Toolkit, boîtes à outils multi-environnement avec Context-Toolkit et mécanisme avec Seescoa XML.
4.1. BOÎTESÀ
OUTILS GRAPHIQUES ABSTRAITES
Tk dans Tcl [Ousterhout 1994], GTK [GTK] et AWT/Swing dans Java [SUN/J2SE] sont des boîtes à outils graphiques abstraites. Elles diffè-rent par le modèle d’exécution : Tcl/Tk est interprété, GTK est compilé et AWT/Swing/Java est précompilé en “byte code” puis interprété par une machine virtuelle.
Pour une classe de plate-forme donnée, Swing et Tk, avec la notion de layouts manager, permettent la reconfiguration dynamique du place-ment des interacteurs physiques selon des règles précalculées, voire décrites sous la forme de contraintes. Il s’agit d’une adaptabilité dyna-mique à la surface d’affichage.
37
Notons que la portabilité est une forme limitée d’adaptation à la plate-forme. En l’état, les boîtes à outils graphiques abstraites ne tolèrent que des variations réduites des attributs de plate-forme. En raison des diffé-rences de ressources (écran, mémoire, performances), une IHM pro-grammée pour une machine de bureau ne peut être portée telle quelle sur PDA. Néanmoins, le “logiciel de base pour le multiplate-forme” se développe progressivement. Citons Java/AWT et toutes ses déclinai-sons pour système embarqué (comme Waba, SuperWaba, Kada, KVM), VisualBasic (qui devrait être porté pour WinCE) et son homo-logue RealBasic (disponible sur MacOS 9, MacOS X et Windows), la bibliothèque Qt (disponible sous Unix, Windows, MacOS X et en cours de portage pour les PocketPC sous Linux).
La table 2 résume notre synthèse des boîtes à outils graphiques abstrai-tes.
4.2. MULTIMODAL
TOOLKIT
Multimodal ToolKit [Crease et al. 2000] est une boîte à outils multimo-dale construite pour adapter l’interface de sortie d’un logiciel au con-texte d’interaction. Elle permet une adaptation à la plate-forme et notamment aux dispositifs d’interaction disponibles (écran 1024*768 d’une station de travail ou 160*160 d’un PalmPilot), à la variation de leur charge d’utilisation (surcharge du dispositif sonore), ou à leur retrait ou ajout au système (retrait ajout d’une souris, d’un clavier). Elle permet également une adaptation au lieu d’utilisation de l’applica-tion.
Un apport important de ce travail est de proposer une architecture, pour la boîte à outils, construite de manière à séparer le comportement d’un interacteur, de son interface utilisateur d’entrée/sortie. De cette manière, l’interface peut s’adapter dynamiquement sans changement du comportement interne des interacteurs.
Une limite de ce système par rapport à nos objectifs est l’absence de gestion d’un modèle de présentation. Ce manque limite l’adaptation au seul changement d’interacteur, sans réorganisation de l’interface. En outre, l’utilisation d’un gestionnaire de présentation permet de distin-Table2. Synthèse des boîtes à outils graphique abstraite
Acteurs (phase de conception)
Sans objet
Support au dévelop-pement
Outils de codage (boîte à outils graphique)
Constituants adaptés Système : Interaction Utilisateur : Interface
Cible Plate-forme
IHM exécutable Dépendant de l’approche (par exemple AWT/Swing, Tk : dynamique) Acteurs (phase
exé-cution)
38
guer le coût d’utilisation d’un interacteur donné, du coût de l’interface (qui correspond à l’utilisation d’un ensemble d’interacteurs, organisés selon un modèle de présentation).
4.3. CONTEXT
-TOOLKIT
Context-toolkit [Dey 2000], vient de l’analogie avec les bibliothèques graphiques de widgets. Comme pour les boîtes à outils graphiques qui offrent un modèle computationnel et des widgets d’utilité publique (menu, formulaire, bouton), Contex-Toolkit inclut un modèle d’exécu-tion et des composants de base réutilisables.
Le constituant de base de l’architecture est un “context widget”, com-posant autonome qui encapsule un capteur physique. Son rôle est de communiquer à un (ou plusieurs) serveur(s) ou interpréteur(s) les informations perçues en fonction des données reçues par le capteur. Les interpréteurs ont pour objectif de fournir une sémantique aux signaux qui leur sont transmis. Par exemple, un interpréteur de locali-sation de personne peut fournir comme informations :
• Personne A dans la salle B204
• Personne A dans le Bâtiment B de l’IMAG
• Personne A dans le Campus de Grenoble
Les serveurs collectent l’ensemble des signaux émis par les autres composants et font le lien entre les applications et les “contexts-wid-gets”. Les serveurs ont également la charge de synthétiser les informa-tions en informainforma-tions de niveau d’abstraction supérieur. Cependant le mécanisme de synthèse n’est pas décrit et revient au programmeur. Table3. Multimodal ToolKit en synthèse
Acteurs, phase con-ception
Le concepteur. Il construit l’interface à la main
Support au dévelop-pement
Boîte à outils multimodale + boîte à mécanismes
Constituants adaptés Point de vue système : OIA
Point de vue utilisateur : Interface (la présentation)
Cible Plate-forme (dispositifs d’interaction et capacité) et environnement IHM exécutable Dynamique
Acteurs, phase exé-cution
Système. Une dérive de cette adaptation est un changement explicite de la taille d’une fenêtre pour forcer l’adaptation. Dans ce cas, l’initiative de l’adaptation revient à l’utilisateur.
39
Sur le plan technique, le système de communication entre les context-widgets et l’application se fait par souscriptions et la réaction aux sous-criptions s’effectue sous forme de call-back (réaction).
4.4. SEESCOA XML L’objectif de Seescoa XML est de servir de langage de description non
seulement d’IHM graphiques mais aussi de leur état d’exécution. Ce faisant, il devra être possible de faire migrer ces IHM dynamiquement entre plates-formes [Luyten et Coninx 2001]. Seescoa XML s’appuie pour cela sur le mécanisme de réflexion de Java qui permet d’analyser dynamiquement l’interface graphique et de générer la description XML correspondante. Cette description peut être ensuite envoyée sur une autre plate-forme pour y être instanciée en une interface graphique équivalente à l’originale et dans le même état. Le système est donc capable de cloner des IHM.
En l’état, [Luyten et Coninx 2001] ne gèrent qu’une adaptation à la boîte à outils graphique par le principe des OIA et OIC.
Table4. Context-Toolkit en synthèse. Acteurs (phase
con-ception)
Sans objets
Support au dévelop-pement
Boîte multi-environnement + mécanismes.
Constituants adaptés Point de vue système : sans objet. Le context-toolkit ne fournit pas de mécanismes ou de compo-sants décidant de la nature de l’adaptation.
Point de vue utilisateur : sans objet
Cible Environnement
IHM exécutable Sans objets Acteurs (phase
exé-cution)
Sans objets
Table5. Seescoa XML en synthèse. Acteurs (phase
con-ception)
Sans objets
Support au dévelop-pement
Boîte à mécanismes.
Constituants adaptés Point de vue système : OIA, OIC Point de vue utilisateur : Interface
Cible Plate-forme
IHM exécutable Dynamique Acteurs (phase
exé-cution)
40