A. Fruit

Les auteurs de FRUIT [61 Kawai 1996] proposent d’abstraire les widgets classiques. Ils

constatent que ces widgets gèrent à la fois les aspects sémantiques et présentationnels.

Ils proposent de séparer ces préoccupations avec, d’un coté, les widgets abstraits qui

gèreront la sémantique et, de l’autre, les widgets concrets qui gèreront le rendu.

Les auteurs identifient trois grandes classes de widgets abstraits (AW pour Abstract

Widget) :

• Les AW de base modélisent une interaction basique comme l’activation, la

saisie de texte. Ces AW sont en lien direct avec l’utilisateur.

• Les AW container sont chargés d’organiser d’autres AW, par exemple de

gérer la mise en page des IHM graphiques (GUI pour Graphical User

Interfaces).

• Les AW composés groupent des AW dont chacun peut influer sur l’autre.

C’est le cas, par exemple, d’un sélecteur de fichiers. Les AW composés sont

notamment utiles pour atteindre le niveau sémantique désiré.

• Command : Ils se matérialisent généralement dans les GUI par des boutons.

Ils peuvent être aussi des commandes saisies au clavier ou prononcées.

• Selection : En GUI, ce sont les listes, les boutons radio, les menus, etc. En

vocal, ils peuvent se matérialiser par des mots ou des numéros.

• Valuator : En GUI, ils se matérialisent classiquement par des potentiomètres

(type slidebar), des jauges, etc. Dans le cas d’IHM textuelles, l’utilisateur

peut saisir une valeur au clavier. Il peut aussi l’énoncer oralement dans le

cadre d’IHM vocales.

• TextDisplay, TextInput : En GUI, ce sont les libellés et champs texte

classiques. En vocal, c’est toute prononciation système ou humaine.

Les AW container sont eux aussi classés en trois grands groupes :

• Shell : Dans les GUI, ce sont les widgets « toplevel », qui fournissent le

contexte graphique aux autres, c'est-à-dire le plus souvent les fenêtres. Dans

le cadre d’IHM textuelles, ce sont les prompts.

• Menu : C’est un type de shell qui prend temporairement le focus.

• Group : Les groupes gèrent la distribution du focus à leurs fils.

Enfin, les AW composés étant définis à la guise du concepteur, ils n’ont pas de

classement particulier. A titre d’illustration, la Figure II-21, extraite de [61 Kawai

1996], met en correspondance les widgets TK et AW. On peut noter qu’un widget AW

peut avoir plusieurs représentations TK.

Tk widget Abstract widget

toplevel shell

frame group

label textdisplay

message textdisplay

button command

checkbutton command

radiobutton selection

listbox selection

scrollbar valuator

scale valuator

entry textentry

Text textentry

Menu Menu

Canvas group

Figure II-21 : Correspondances entre widgets TK et AW.

Techniquement, une application FRUIT se compose de trois parties (Figure II-22) :

• Les widgets rendus sont répartis dans un ou plusieurs shells d’interaction.

Généralement, l’utilisateur choisit un seul shell (par exemple vocal), mais il

peut décider d’en lancer plusieurs (par exemple graphiques) pour compléter.

• Les widgets abstraits centralisent la logique de l’application. Ils interprètent

au niveau de l’application les opérations faites par l’utilisateur sur les

widgets rendus.

• Le « sessions manager » est l’infrastructure sous jacente à FRUIT.

Le programmeur construit l’IHM à l’aide de widgets abstraits. L'utilisateur agit au

travers de widgets rendus dans un ou plusieurs shells d'interaction (graphique, vocal,

etc.). Ces widgets rendus communiquent aux widgets abstraits, via un protocole

d’interaction, les opérations effectuées. Un « session manager » gère les applications

FRUIT (Figure II-22).

Figure II-22 : Comparaison entre une application classique (a) et une application FRUIT (b).

Le choix de la présentation d’un widget est réalisé par une boîte noire qui raisonne

notamment en fonction de l’AW correspondant et de l’interaction shell. Ce choix de

l’interacteur est du ressort du système seulement. La mise en page (dans le cas

graphique) est aussi laissée à la charge de cette boîte noire.

Conclusion

FRUIT découple la sémantique de l’application de sa présentation. FRUIT s’appuie sur

les BàO existantes (ex : TK) pour le rendu des widgets abstraits. Les mécanismes

d’interaction n’ont pas à être reprogrammés. La notion de shell permet de définir dans

quelle technologie seront rendus les widgets et incidemment dans quelle(s) modalité(s).

Les auteurs insistent sur le fait que des IHM vont ainsi pouvoir être rendues

simultanément en graphique, en vocal et en mode texte. La notion de shell permet

d’envisager le rendu simultané des widgets dans différentes BàO, ce qui pourrait

permettre d’avoir des rendus graphiques traditionnels WIMP, Web, post-WIMP, 3D,

etc. De même, en vocal, on peut imaginer différents shells de reconnaissance vocale

plus ou moins performante ou adaptée au contexte d’usage (langue de l’utilisateur par

exemple). L’approche a toutefois des limites :

• Bien que la notion de groupe apparaisse, ni les opérateurs entre tâches, ni les

décorations ne sont modélisés dans FRUIT. Il est donc impossible de dire

que des AW doivent être entrelacés, en séquence, en disjonction, etc. Cela

limite les possibilités de rendu et oblige, en réalité, le concepteur à câbler ces

opérateurs dans le graphe d’AW.

• FRUIT ne propose pas de système pour sélectionner les types de rendu

associés aux AW. Il semble que cela soit laissé à la discrétion de

l’interaction shell.

Tableau II-6 : Grille d'analyse pour FRUIT.

Niveau sémantique Les Abstract Widgets sont de niveau tâche. Ils sont indépendants de

la modalité.

Empreinte

technologique

En termes de modalités, FRUIT couvre les IHM textuelles,

graphiques avec TK, vocales. Un même AW peut être rendu

simultanément selon plusieurs de ces technologies.

Extensibilité L’extensibilité n’est pas possible au niveau de l’interacteur.

L’extensibilité n’est possible qu’au niveau du shell. C'est-à-dire que

pour enrichir les présentations d’un abstract widget, il faut enrichir

le shell.

Malléabilité Il n’y a pas de transformation applicable au niveau de l’AW.

Contrôlabilité /

Prévisibilité du rendu

Le rendu de l’AW n’est contrôlable qu’en choisissant un shell pour

le rendu. Le rendu à l’intérieur d’un shell est prévisible.

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