B. WAHID

II. Boîtes à outils d’interacteurs plastiques

Figure II-14 : A gauche, la scroll bar classique. A droite, la scroll bar Horseshoe.

Figure II-15 : L’architecture externe permet une représentation a posteriori multiple.

Tableau II-4 : Grille d'analyse pour WAHID.

II. Boîtes à outils d’interacteurs plastiques

II.1. B. WAHID

WAHID [57 Jabarin 2003] se place explicitement dans le domaine de la plasticité au

niveau widget. WAHID propose des widgets polymorphes s’adaptant à la plate-forme

d’exécution. Les auteurs pensent que ce type d’approches est moins puissant qu’une

plasticité « à la main » qui permet au concepteur un contrôle total de l’adaptation.

Toutefois l’approche widget plastique est intéressante, du point de vue du programmeur,

puisqu’elle préserve son savoir-faire. Il suffit d’utiliser la BàO WAHID dont l’API est

calquée sur la Microsoft Foundation Classes (MFC) [87 Prosise 1999].

L’appui de WAHID dans la MFC lui confère une originalité : la plasticité, à l’exécution,

d’IHM à l’origine non plastiques, mais construites à l’aide de la MFC.

WAHID propose deux architectures logicielles pour prendre en charge la plasticité des

widgets : l’une interne, basée sur une BàO de widgets plastiques ; l’autre externe, qui

permet de coupler des widgets plastiques à des applications déjà existantes dont les

sources ne sont pas disponibles.

Architecture interne

Le but principal de « l’architecture interne » est de permettre le développement

d’applications à base de widgets plastiques, capables de s’adapter à la plate-forme

d’exécution. WAHID pose deux requis supplémentaires :

• Le développement d’une application plastique ne doit pas être plus

compliqué que celui d’une application classique.

• Le développement d’une application plastique doit se faire à l’aide des outils

et méthodes auxquels les développeurs sont accoutumés.

WAHID atteint le premier but en offrant une boîte à outils dont les widgets s’adaptent

automatiquement à la plate-forme lors du lancement de l’IHM. Le second but est atteint

en se basant sur MFC, une bibliothèque d’interacteurs architecturés selon MVC et

largement utilisée dans le monde windows. WAHID spécialise les classes MFC et

maintient la compatibilité avec le Wizard de VisualC++ utilisé par les concepteurs pour

spécifier des IHM.

La méthode consiste à nommer les classes WAHID en suffixant celles de MFC par la

lettre ‘P’. Une simple substitution des noms de classes dans le code rend alors plastique

l’application. Le surcoût de développement est donc très faible.

La scroll bar Horseshoe illustre l’approche (Figure II-14). Elle est conforme à l’API de

la scroll bar MFC. Le programmeur n’a aucun surcoût à l’utiliser.

Selon [77 Myers 2000], WAHID offre un low threshold. Le ceiling, par contre, n’est pas

élevé : la plasticité se limite à une substitution de présentation sur des plates-formes

classiques (PC de bureau, tableau tactile ou tablette PC). Cette approche ne permet pas

des réarrangements d’éléments à l’écran, encore moins de revoir toute la conception de

l’IHM. Selon les auteurs, pour pouvoir prendre en charge une adaptation à des

plates-formes de type PDA ou smart phone, caractérisées par un faible nombre de pixels, il

faudrait pouvoir spécifier des adaptations au niveau applicatif et non plus widget.

La section suivante décrit l’architecture externe pour une plasticité a posteriori d’IHM

existantes.

Architecture externe

L’ « architecture externe » a comme objectif de rendre une IHM existante plastique sans

retoucher à son code. Ceci est précieux si justement le code n’est pas disponible. La

plasticité se fait par ajout de nouveaux widgets, sans qu’ils se substituent aux anciens.

Ces widgets ne peuvent pas s’insérer dans l’IHM, au mieux peuvent-ils être superposés

à l’IHM, tel le menu en fleur par exemple (Figure II-15). Le menu classique ne disparaît

pas pour autant. L’architecture externe permet une représentation multiple a posteriori,

sans modifier le code applicatif.

Conclusion

En synthèse, l’architecture interne proposée dans WAHID est spécifique à la MFC.

Cependant, le principe peut être étendu à n’importe quelle BàO. Le concepteur de telles

BàO devra faire face à des problèmes techniques comme substituer un widget par un

autre de façon transparente pour l’application. Du point de vue du programmeur

(l’utilisateur de ces BàO), le surcoût lié à la plasticité sera pratiquement inexistant.

L’architecture externe permet d’ajouter des widgets simulant ceux de l’IHM d’origine

(ex : menu en fleur, HorseShoe affiché dans une fenêtre à part…) sans que l’IHM soit, à

l’origine, prévue pour (elle doit cependant respecter les standards de la MFC). Les

widgets ne sont pas insérés dans l’IHM. Ils sont ajoutés « au dessus » de celle-ci. Ici

encore, la transposition à d’autres BàO parait faisable.

Le pari de WAHID semble réussi : les requis posés par les auteurs sont respectés. Le

programmeur peut continuer à utiliser sa BàO favorite et les outils associés. Il n’y a

pratiquement pas de surcoût par rapport à un développement classique.

Le principal problème de WAHID réside, en réalité, dans la « faiblesse » des BàO

visées (la MFC). Ces BàO n’offrent pas un niveau sémantique suffisant. Il est, par

exemple, difficile de transformer un menu déroulant en boutons radio ou en liste

déroulante. En effet, rien n’exprime que ces widgets ont tous pour but de faire un choix

parmi un ensemble d’éléments. Leurs API peuvent, par ailleurs, être sensiblement

différentes. Ce problème peut se résumer au fait que les widgets ne représentent pas les

tâches utilisateur, mais des façons de réaliser une tâche, ces façons pouvant parfois être

incohérentes entre elles. Les auteurs reconnaissent la faiblesse d’une adaptation au

niveau widgets :

• Il n’y a aucun contrôle possible de la part de l’utilisateur ou du

programmeur.

• On ne peut pas agir sur une composition de widgets mais seulement sur un

widget.

• On ne peut pas changer la mise en page. Il n’existe pas de widgets incarnant