Amulet/Garnet

Amulet est un framework de construction d'interfaces graphiques et d'interactions basé sur le langage C++, qui a fait figure de pionnier dans l'innovation en programmation d'IHMs  [Mye97]. Développé sur plus d'une décennie, il se caractérisait par des widgets basés sur un modèle d'objets à prototypes, l'intégration d'un système de contraintes pouvant s'attacher à toutes les variables, la gestion des entrées utilisateur par des objets “Interactors” réutilisables, et des possibilités avancées d'inspection et de modification de l'interface à l'exécution. Ces caractéristiques sont encore aujourd'hui en avance sur les frameworks courants de programmation d'IHM. Amulet est le successeur de Garnet (illustré en figure 22), un framework et environnement de développement basé sur Common Lisp et X11 [Mye90].

Figure 22 : Exemple d'interface construite avec Garnet (figure extraite de [Mye90])

Amulet a été spécifiquement développé pour soutenir la recherche sur les interfaces graphiques. La flexibilité et l'extensibilité étaient donc des thèmes centraux, intégrés dans son modèle innovant de construction des interfaces. Il a servi à explorer des sujets tels que l'interaction distribuée sur le réseau Internet, le support et l'expression des animations, le support de l'action undo, le déboguage graphique des applications interactives, la création d'un outil graphique de définition d'interface (Gilt), l'instanciation de widgets par le dessin à main levée (SILK), et la programmation par démonstration (Gamut). Le modèle à prototypes d'Amulet consiste pour chaque objet à avoir un parent (son

prototype), qui implémente les méthodes de l'objet (tout comme une classe le ferait). Cependant, à la

différence des classes il est possible d'ajouter ou supprimer des champs de chaque objet (indépendamment des autres), et de changer de prototype. On peut ainsi considérer la programmation orientée prototype comme une alternative aux classes plus flexible. Amulet est un des rares travaux ayant exploré l'usage d'un langage dynamique (au sens moderne, nous entendons le typage et la topologie des objets), pour la construction d'interfaces graphiques. Le modèle à prototypes était implémenté en C++ à l'aide de fonctions, sans faire usage de fonctionnalités de métaprogrammation, ce qui explique qu'il ait souffert d'une mauvaise performance.

Aujourd'hui, certaines des fonctionnalités innovantes qu'Amulet a contribué à développer ont acquis une diffusion plus large (gestion des contraintes de Cassowary [Bad01], introspection des interfaces avec les navigateurs Web), tandis que les autres sont restées du domaine de la recherche. Il est à envisager que l'essor de langages dynamiques comme Python et JavaScript permette le développement de frameworks exploitant les objets à prototypes, dont nous nous sommes également inspirés dans ce travail de thèse.

3.1.4 SwingStates et HsmTk

SwingStates est une boîte à outils basée sur le langage Java, s'intégrant avec le framework natif Swing pour y appliquer le formalisme des machines à états [App06]. Elle a été conçue pour structurer le flux de contrôle des applications graphiques, dont la complexité est depuis longtemps reconnue comme problématique, pour la maintenance et l'introspection des interfaces [Mye91]. Elle est notable aussi pour le développement des notions de tags, inspirés de Tcl/Tk, et popularisés par les classes de CSS1 [W3C96]. Les machines à état (ou automates finis) sont un modèle mathématique permettant de décrire le fonctionnement d'un système comme un enchaînement d'états, et l'exécution de transitions entre ces états. Appliqué à la programmation d'IHMs, elles permettent de décrire des techniques d'interaction de façon rigoureuse et systématique — en particulier pour repérer et clarifier les interactions inattendues (ex. appui simultané des deux boutons sur la figure 23).

Figure 23 : Illustration d'une technique d'interaction à deux boutons modélisée par une machine à états (figure extraite de [Bux90]).

HsmTk est une autre boîte à outils, basée sur le C++, et appliquant cette fois le formalisme des machines à états hiérarchiques [Bla06] (voir figure 24). Elle s'intègre à la fois comme une extension du

l'intégration de la logique à la spécification de l'interface). HsmTk est notable pour chercher à s'extraire du modèle de widget, réutilisant des technologies existantes, éprouvées, et bien optimisées (SVG et la syntaxe du C++), pour concevoir des interfaces graphiques innovantes.

Armed Disarmed enter release leave press release /doIt() enter leave InUp OutUp OutDown InDown

Figure 24 : Exemple d'une machine à états hiérarchique (figure extraite de [Bla06]).

SwingStates et HsmTk ont comme points communs d'avoir été toutes deux développées — indépendamment — au LRI (Université Paris-Sud), et d'appliquer le principe d'interaction comme objet

de première classe de Beaudoin-Lafon  [Bea04]. Les machines à état sont un paradigme robuste et

éprouvé pour modéliser des techniques d'interaction, cependant elles ont rarement été utilisées pour du prototypage — y compris pour la recherche académique. En effet les automates s'expriment au mieux par des diagrammes visuels, et se transposent en texte souvent de façon verbeuse. De plus, il sont assez vite limités dans la complexité des interactions qu'ils peuvent modéliser, en particulier lorsqu'il faut considérer la combinaison de plusieurs états, les transitions continues entre états (animations), ou l'expression de feedback et feedforward. Ces besoins impliquent de rajouter des états, et augmentent donc la complexité de façon exponentielle. Pour ces mêmes raisons, les formalismes à états sont généralement très limités dans leurs capacités à faire évoluer le nombre d'états et de transitions. Les paradigmes à états sont cependant très utilisés dans les domaines où l'interaction doit être formellement spécifiée et déterministe, comme les systèmes critiques, avec ICO/Petshop qui est basé sur des réseaux de Petri  [Nav09]. Enfin, InterState est notable pour avoir fourni une représentation graphique unifiée entre machines à états et données des objets (voir figure 25), afin de spécifier des comportements réutilisables sous forme de machines à états [One14].

' bl ack' f i l l ( di v) 313 763 y x pr ot ot ypes no_drag drag_lock 0 0 ' bl ack'y x mous e. x ' navy' mous e. y on('dblclick', this) on('mouseup') on('click') on('mousedown', this) drag mous e. x ' bl ue' mous e. y Add Field own dom. di v

draggable

Figure 25 : Exemple du comportement de glisser-déposer implémenté dans InterState (figure extraite de [One14]).