A. UBIT

Considérant les BàO « classiques », E. Lecolinet constate que [65-66 Lecolinet 1999 et

2003] :

• Les BàO sont artificiellement figées. Seules les IHM de type WIMP sont

faciles à réaliser. Elles posent des contraintes qui n’ont plus lieu d’être.

• Il existe une séparation artificielle entre les IHM WEB et non WEB. Il n’y a

pas de raison que la programmation d’une IHM pour le WEB soit si

différente. Cette séparation s’explique par des raisons historiques. Elle doit

être surmontée.

• De nombreuses personnes se disent, et sont, capables de coder de petites

IHM en HTML. Inversement, très peu s’estiment, et sont capables, de coder

des IHM à l’aide des BàO classiques (SWING, QT…).

Le but d’UBIT est de dépasser ces divisions et de permettre au programmeur de

facilement définir de nouveaux widgets. Je ne m’intéresse pas ici aux différences entre

UBIT et les BàO classiques, mais aux caractéristiques d’UBIT qui pourraient faciliter le

développement d’IHM plastiques. Je repére le contexte généralisé, l’héritage, la notion

de style et la structure en Directed Acyclic Graph (DAG).

Propriétés utiles pour la plasticité

Une IHM UBIT (comme d’ailleurs une IHM SWING ou HTML) peut être vue comme

un graphe orienté où chaque nœud représente un élément d’interface et chaque relation

entre deux nœuds représente la notion « contient ». L’affichage de l’interface se fait

relativement au parcours de ce graphe. Chaque nœud est affiché en fonction de son père

et en fonction d’un contexte graphique courant. Par exemple, si le contexte graphique

courant indique que la couleur est noire, alors un texte sera affiché en noir. Cette notion

de contexte graphique vient du monde de la synthèse d’image et des graphes de scène.

Ce contexte est généralement réduit à une transformation spatiale, la couleur, la texture,

etc. UBIT propose de généraliser cette notion en y incorporant potentiellement

n’importe quelle information, par exemple la fonte, mais aussi des informations

spécifiques à une application. La Figure II-26 illustre le rendu d’un graphe UBIT

représentant un bouton.

Figure II-26 : Graphe UBIT représentant un bouton. Des éléments du graphe comme "bold" ou "blue" modifient le contexte ainsi le texte « Image » est-il affiché en bleu gras.

Les informations de style (fonte, couleur, etc.) placées dans le contexte sont transmises

lors du parcours du graphe UBIT. Ainsi, pour modifier la fonte utilisée par défaut dans

toute l’application, il suffit d’ajouter une information de style dans le contexte

généralisé du noeud racine de l’application.

Un style global peut être donné en spécifiant des valeurs pour la fonte, la couleur du

texte, la couleur de fond, etc. Ces valeurs sont transmises aux descendants. Le style peut

être surchargé à n’importe quel niveau du graphe. Cette façon de faire est à rapprocher

des langages de style existants, par exemple, CSS pour le Web. Le style donné peut

n’être limité qu’à des informations de mise en forme de type couleurs ou fonte, mais il

est aussi possible de l’utiliser pour réaliser des modifications plus complexes, comme

des zooms sémantiques (l’interface change en fonction du zoom).

Cette notion de style, de contexte généralisé, permet de modifier l’apparence d’une

IHM. Couplé à une structure en DAG, elle permet de réaliser des vues multiples

synchronisées.

Alors que les BàO classiques imposent une structure d’arbre au graphe de widgets,

UBIT, s’inspirant des BàO 3D (graphe de scènes) et de certaines BàO 2D ([47 Fresco]

[73 Linton 1994], [80 OpenInventor], [58 Jazz] [12 Bederson 2000], etc.) propose

d’utiliser une structure en DAG. Cela permet à un élément d’avoir plusieurs pères et

donc d’être partagé (Figure II-27).

Figure II-27 : a) Structure en DAG (Directed Acyclique Graph). Les numéros représentent le nombre de fois que le nœud sera affiché. b) Une même interface affichée deux fois, avec différents facteurs de zoom.

Le facteur de zoom est un élément du contexte.

La partage permet de réaliser facilement des vues multiples : il suffit d’hériter de

plusieurs pères. Les différences entre les vues seront assurées par des contextes

différents. Par exemple, le même bouton pourra être affiché deux fois, à des endroits

différents et avec une couleur de fond différente (Figure II-28). Ce même principe peut

être appliqué à la réalisation de vues radars, à la réplication d’interfaces, etc.

Root Frame 1 fond gris Frame 2 Fond blanc Bouton text OK OK OK

Figure II-28 : Exemple de vue multiple affichée selon différents styles propagés par le contexte généralisé. A gauche, le graphe montre un bouton ayant deux frames pour pères, chacune redéfinit la couleur

courante. A droite, le résultat.

L’utilisation de cette structure de DAG permet de réaliser une certaine forme de

polymorphisme La Figure II-29 montre l’utilisation de nœuds « Conditions » qui sont

mutuellement exclusifs (un et un seul est vrai à la fois). Les conditions portent sur le

contexte généralisé, par exemple la place disponible, les préférences utilisateur, des

informations propres à l’application, etc. Si la condition est fausse, le sous DAG n’est

pas affiché. Seule une forme est donc affichée à un instant donné. Les conditions I et N

accèdent au même sous DAG : celui-ci sera affiché différemment en fonction des

contextes I et N.

Widget Root Condition 1 Condition I (contexte I) … Forme 1 Condition N (contexte N) Forme paramétrique

Figure II-29 : Exemple de réalisation de widget polymorphe.

Conclusion

UBIT permet de réaliser des IHM extrêmement flexibles, ne se limitant pas aux IHM

standardisées (SWING, TK…). Cela facilite l’innovation. La notion de style, de

contexte généralisé est un pas en direction d’une harmonisation entre les conceptions

d’IHM Web et non Web. L’objectif est d’allier la facilité de développement en HTML

et la puissance des BàO classiques. UBIT fournit des éléments extrêmement modulaires.

La création de nouveaux widgets revient à construire des brickgets, assemblages de

bricks. De nouvelles bricks peuvent être ajoutées par programmation, par exemple pour

fournir un canevas 3D. Enfin, la structure en DAG permet de réaliser de façon aisée des

vues multiples et offre une façon simple pour réaliser des widgets polymorphes.

Si UBIT est une BàO d’interacteurs innovante, elle reste au niveau CUI/FUI. Il n’y a

pas de modélisation de l’interface au niveau tâche utilisateur par exemple.

Tableau II-8 : Grille d'analyse pour UBIT.

Niveau sémantique CUI/FUI

Empreinte

technologique

C++ / X11

Extensibilité Extensibilité par ajout de bricks. Des interacteurs sur mesure sont

faciles à définir.

Contrôlabilité /

Prévisibilité du rendu

Le rendu de l’interacteur (brickget) est contrôlable via le contexte

généralisé.

Dans le document Modèles et outils pour la conception et l'exécution d'Interfaces Homme-Machine Plastiques, Ecosystème (Page 45-48)