Dégradation harmonieuse d'interfaces utilisateur - UsiXML

La deuxième technique se base sur l’utilisation de clients génériques (browsers) et/ou de
toolkits virtuels (ex : Java Swing, Tcl/Tk). Dans ce cas précis, l’adaptation n’est pas, en tant
que tel, perceptible par l’utilisateur. A l’exception de quelques différences de présentation et
de représentation de l’information entre les browsers et entre les toolkits, l’utilisateur ne
remarque rien. Cependant, ce système n’offre pas de solution réellement satisfaisante en
regard d’applications devant s’exécuter sur des dispositifs très différents en termes de
capacités en entrée/sortie. Ex : le système XWeb [Xweb] produit des IUs pour différents
dispositifs à partir d’une description multi-modale de l’interface utilisateur abstraite. Ce
système s’utilise sur des serveurs XWEB spécifiques et via des browsers prédisposés pour les
capacités des plate-formes spécifiques en communiquant suivant un protocole XTP approprié.
La troisième approche étend et complète le client générique de la deuxième technique
(utilisation de documents XML transformés (WML, XHTML, …)). Les interfaces générées
via cette approche deviennent alors consistantes du point de vue de l’information, même si la
présentation peut changer sensiblement. Néanmoins, cette technique impose encore de réaliser
un document XML par plate-forme cible (car le langage peut varier), ce qui est encore
inefficace.
Les outils récents issus de la même veine utilisent dorénavant une approche basée modèle
(cfr. supra). On peut citer par exemple ARTStudio, ou TERESA qui sont plus focalisés sur
génération automatisée, ou encore LiquidUI, qui se concentre plus sur la spécification accrue
des interfaces.
ARTStudio est un outil de génération utilisant différents modèles : la tâche (spécification d’un
modèle de la tâche ConcurTaskTree (nous reviendrons plus en détails sur la modélisation
CTT par la suite) avec certains paramètres additionnels), le domaine (spécification en UML),
la plate-forme, les objets interactifs, l’interface abstraite (AUI) représentant le premier
processus de réification des modèles de la tâche et du domaine à un haut niveau d’abstraction,
et l’interface concrète (CUI).
TERESA, quant à lui, génère des interfaces multiplate-formes à partir d’un modèle de tâche
CTT unique. Pour chaque tâche, les objets qui seront manipulés ainsi que la cible choisie
seront mentionnés. Ensuite, ce modèle est passé sous différents filtres afin de produire un
modèle de tâche spécifique à une plate-forme bien précise. Après quoi, ce modèle est
transformé en AUI (un ensemble de présentations et leur comportement dynamique) suivant
un algorithme particulier (Enable Task Sets algorithm), qui produit l’ensemble des tâches à
accomplir en même temps par présentation. Ensuite, chaque présentation est définie en termes
d’objets interactifs abstraits. Et pour terminer, chaque objet interactif abstrait est transposé en
son homologue concret suivant la plate-forme désirée.
LiquidUI utilise le langage UIML. Une interface spécifiée en UIML inclut trois composants :
- le composant logique : décrivant la manière de communiquer avec l’application
indépendamment des protocoles, noms de méthodes, …
- le composant de présentation : décrivant la manière de présenter l’IU
indépendamment des widgets finaux et de leurs propriétés ainsi que la gestion
d’évènements concrets.
- Le composant de l’interface : décrivant l’interaction entre l’utilisateur et l’application
indépendamment de la plate-forme. Ce composant est subdivisé en quatre parties : la
structure, le style (couleur, taille de la fonte utilisée, …), le contenu (texte, images,
14