B. Multimodal Widget

II. Boîtes à outils d’interacteurs plastiques

Figure II-24 : L'architecture en action sur l’exemple du feedback lors du passage de la souris sur un bouton.

Figure II-25 : Différentes présentations d'un même widget "jauge". Elles consomment plus ou moins de surface d’affichage.

Tableau II-7 : Grille d'analyse des Multimodal Widgets.

II. Boîtes à outils d’interacteurs plastiques

II.2. B. Multimodal Widget

Constatant que les situations d’interaction peuvent être variées (à l’intérieur, dehors,

environnement calme/bruyant, seul/en groupe, etc.), l’auteur identifie la nécessité pour

une application de pouvoir être rendue perceptible à l’utilisateur au travers de différents

sens humains (visuel, auditif, tactile, etc.). L’auteur propose une BàO d’interacteurs

multimodaux (mettant en jeu différents sens humains) visant à faciliter la construction

de telles applications. Les multimodal widgets [30-31Crease 2000-2001] répondent à

quatre requis :

• Un widget doit pouvoir être rendu simultanément dans plusieurs modalités.

• Un widget doit pouvoir sélectionner la modalité la plus adaptée au contexte

d’usage et limiter l’utilisation d’une modalité n’ayant pas les ressources

nécessaires.

• Le feedback d’un widget doit pouvoir être facilement changé pour une ou

plusieurs modalités sans que cela ait des effets sur les autres.

• Les feedbacks des différentes modalités doivent être cohérents non

seulement pour un même widget mais aussi entre widgets.

Du point de vue du développeeur, la BàO des multimodal widgets reprend l’API de la

BàO SWING. Les habitudes du programmeur sont ainsi préservées. Par exemple, pour

créer un bouton sous SWING et l’ajouter à un panel, le code est le suivant :

JButton button = new JButton("Progress"); panel.add(button);

Avec les multimodal widgets, l’exemple équivalent est le suivant :

MButton button = new MButton("Progress"); panel.add (button.getTheWidget());

La Figure II-23 fournit l’architecture d’une application utilisant les multimodal widgets.

Le feedback controller assure que les modalités sont traitées d’égales à égales et que

chaque widget est multimodal. Il traduit les événements reçus en termes indépendants

de la modalité et les transmet aux modality mappers.

Le ressource manager assure la connaissance des ressources disponibles et de leur

adéquation à l’environnement. Il reçoit des informations de la part de trois modules : le

control panel (préférence de l’utilisateur quant à la modalité à utiliser) ; les output

modules (indiquent si les ressources sont suffisantes pour rendre les widgets via une

modalité, compte tenu de l’importance accordée par l’utilisateur à celle ci) et d’autres

applications (via son API, ces applications peuvent renseigner le système sur l’état de

l’environnement).

Les outputs modules et le control panel assurent en outre que le feedback des widgets

pourra être facilement changé. En effet, les outputs modules peuvent facilement être

remplacés au travers du control panel.

Enfin, la cohérence de l’ensemble est assurée par le rendering manager. Le rendering

manager peut modifier un son pour qu’il n’interfère pas avec un autre (en changeant le

timbre par exemple). De même, il assurera qu’un bouton texturé comme du bois n’est

pas associé à un son métallique.

La Figure II-24, extraite de [30 Crease 2000] illustre le comportement de l’architecture

dans le cas d’une souris survolant la représentation graphique d’un bouton. Il s’agit

d’associer un feedback à cet événement : il combine ici le graphique et le vocal.

La Figure II-25 extraite de [30 Crease 2000] montre différents rendus graphiques pour

une jauge. La sélection du rendu se fait en fonction, d’une part, de l’importance donnée

à la modalité graphique pour ce widget et, d’autre part, des ressources écran disponibles.

C’est au concepteur de widgets de fournir les différentes présentations.

Les multimodal widgets offrent une BàO permettant au concepteur de construire

simplement des IHM qui pourront être rendues dans plusieurs modalités (c'est-à-dire

mettant en jeu différents sens humains). Le style de programmation est très proche de

SWING. La surcharge par rapport à SWING est pratiquement nulle puisque le

programmeur n’a pas à se soucier du rendu multimodal. Il est pris en charge par le

système. La cohérence entre widgets et entre modalités est assurée par le rendering

manager. Le choix de privilégier telle ou telle modalité est, en partie, laissé à

l’utilisateur via le control panel.

Toutefois, en voulant rendre la programmation d’IHM multimodales aussi proche que

possible de la programmation SWING, les multimodal widgets se trouvent confrontés

aux limites de SWING en terme d’expressivité des IHM :

• Les opérateurs entre tâches ne sont pas modélisés. Les tâches ne le sont pas

vraiment.

• Les widgets n’ont pas de sémantique explicite. On peut ainsi douter que le

rendering manager sera capable de maintenir des cohérences du type « tous

les widgets associés au concept C1 doivent être cohérents entre eux et

différenciables de ceux associés au concept C2 ».

• L’exemple de la jauge semble montrer qu’un certain polymorphisme est

possible au sein d’une même modalité. Cependant, c’est au concepteur de

l’output module de ce widget de fournir ces présentations. Il semble alors

difficile pour un autre concepteur d’ajouter de nouvelles présentations à un

output module déjà existant.

• Les outputs modules graphiques sont intrinsèquement liés à SWING. Il

semble difficile de changer de BàO, par exemple pour créer du post WIMP.

Niveau sémantique Les multimodal widgets sont plus une architecture qu’une BàO. Il

n’y a que deux widgets : le bouton et la jauge. Il est donc difficile de

caractériser le niveau sémantique. Toutefois, on peut dire que les

widgets sont au moins de niveau AUI puisqu’ils n’ont pas de

représentation intrinsèque.

Empreinte

technologique