Évolutions

En ce qui concerne l’évolution de VXT, il est dans un premier temps nécessaire de finaliser la re-présentation des branchements conditionnels, même si leur absence (temporaire) dans l’environnement de développement ne nuit pas de manière importante au langage du strict point de vue de l’expressi-vité, puisqu’il est souvent possible d’exprimer les branchements conditionnels de manière détournée, en

et moyens de référencement adaptés aux différents contenus et modes d’utilisation de ces variables. Enfin, il faudrait prendre en compte les évolutions récentes des schémas de documents et proposer une extension du langage visuel pour la représentation d’instances de documents XML et de DTD. L’ex-tension à des langages comme TREX, qui apportent assez peu d’expressivité par rapport aux DTD en ce qui concerne les contraintes structurales, ne devrait pas poser de gros problèmes. Il n’en va pas de même pour les XML Schema recommandés par le W3C qui proposent de nombreuses évolutions, comme le sous-typage, l’héritage et les types de données primitifs. Il serait possible d’utiliser comme solution temporaire les travaux récents autour de la gestion de schéma XML en Circus pour proposer une repré-sentation approximative des contraintes structurales d’un XML Schema en passant par une conversion vers le format pivot exprimé en Circus. Mais il faudrait aussi à terme adapter l’outil aux nouvelles pro-positions du W3C, à savoir XPath 2.0 [18] et XSLT 2.0 [83]. XPath 2.0 utilise par exemple les types de données primitifs définis par XML Schema. Avoir une représentation visuelle de ces nouvelles contraintes dans le langage pour la visualisation de (classes de) documents nous permettrait d’enrichir les VPMEs tout en conservant un formalisme unifié. Les nouveaux concepts proposés par les XML Schema sont cependant très riches et très complexes, et il n’est pas évident de trouver un formalisme visuel capable de capturer cette complexité tout en conservant les propriétés que nous avons tenté de donner à notre proposition, c’est-à-dire une relative simplicité des constructions visuelles et un formalisme unifié pour la représentation des instances de documents, des classes de documents, et des règles de transformation.

Deuxième partie

Applications

Boîte à outils pour le développement

d’interfaces graphiques

Le code associé aux interfaces utilisateur graphiques (GUI : Graphical User Interface) représente une part très importante des applications. Une étude [170] réalisée en 1992 montre qu’en moyenne 48% du volume de code et 50% du temps d’implémentation étaient alors dédiés au développement de l’interface. Ces proportions ont probablement encore augmenté, les interfaces devenant de plus en plus complexes du point de vue de la programmation afin de fournir une interaction de qualité toujours croissante. De nombreuses fonctionnalités liées à l’interface sont désormais considérées comme naturelles et indis-pensables : fonctions de copier/coller, barres de progression reflétant l’état d’avancement d’une tâche, raccourcis clavier et d’une manière générale fonctions d’accessibilité, constructions facilitant l’interna-tionalisation et la localisation. Elles doivent donc être proposées par l’environnement. Sur un plan plus subjectif, l’apparence visuelle (le look and feel) de l’interface est aussi important. Ainsi, des critères purement esthétiques, comme le soin apporté au dessin des icônes, ayant a priori peu à voir avec les aspects cognitifs (utilisabilité) de l’interface graphique, entrent en ligne de compte et modifient la per-ception qu’a l’utilisateur du logiciel quant à sa qualité globale. Il faut tout de même faire attention à ne pas se baser sur des critères uniquement esthétiques, ce qui peut amener à la création d’interfaces parfois confuses (voir par exemple l’interface du logiciel de création de paysages tridimensionnels Bryce [61]). La complexité inhérente du code lié à la gestion de l’interface utilisateur, due aux différents aspects à traiter (gestion de l’affichage, gestion des événements utilisateurs, liens avec les autres parties du pro-gramme) et au nombre de composants ne cesse d’augmenter. On assiste cependant depuis plusieurs années à une normalisation des interfaces graphiques autour du modèle WIMP (Windows, Icons, Menus, and Pointers) initié par l’Alto puis le Xerox Star et utilisé dans la plupart des environnements graphiques actuels : Microsoft Windows, Mac OS, Motif, et les environnements tels que KDE pour Linux. Cette nor-malisation permet de proposer des systèmes de gestion d’interfaces utilisateurs (UIMS : User Interface Management System) aidant à la conception de l’interface graphique des applications. Il existe plusieurs types de systèmes positionnés à différents niveaux d’abstraction, sachant qu’il devient difficile de les classifier du fait qu’ils couvrent souvent différents niveaux :

– Les serveurs d’affichage et les systèmes de fenêtrage : positionnés au-dessus de la couche sys-tème d’exploitation, ils permettent la manipulation de fenêtres (création, déplacement, etc.) dans l’environnement graphique, offrant ainsi la possibilité de séparer l’espace d’affichage en diffé-rentes zones indépendantes. Ils offrent aussi des primitives de dessin de bas niveau pour dessiner le contenu des fenêtres (rectangle, cercle, polygone, texte) et gère les événements de la souris et du clavier (touche du clavier ou de la souris pressée, déplacement de la souris, etc...). Dans le cas de X-Windows, le système de fenêtrage est une application indépendante et peut être changé à tout instant. Même si son cas est un peu spécial1, l’API Java 2D [162] se trouve à ce niveau d’abstraction.

– Les boîtes à outils (toolkits) : elles offrent un ensemble de composants graphiques (widgets) comme les menus, barres de défilement et champs textuels ainsi qu’une API pour les manipu-ler. Cette API inclue des événements de plus haut niveau que dans le cas précédent, comme par exemple press et release dans le cas d’un bouton de commande ou la sélection d’un item dans un menu. Ces systèmes, fournissant seulement une interface programmatique, ne sont utilisables

1Faisant partie de la machine virtuelle Java (multi-plateformes), cette API offre un grand nombre de primitives graphiques de bas niveau utilisables à l’intérieur de composants Java spécifiques mais ne permet pas de gérer les fenêtres qui restent à la charge du système de fenêtrage natif.

le cadre de la visualisation de grandes quantités d’objets, les interfaces 3D présentent des avantages par rapport aux interfaces 2D (compacité de la représentation, perception du contexte) comme le montrent les mesures effectuées pour les Virtual Images [222]. Les représentations tridimensionnelles ne sont ce-pendant pas adaptées à toutes les tâches ni à toutes les structures de données2. Le nombre de degrés de liberté plus élevé peut être encombrant pour l’utilisateur ; la navigation est plus complexe et il peut être plus difficile de s’orienter. Il semble alors intéressant d’explorer une voie intermédiaire entre l’interface purement 2D et l’interface 3D : l’interface 2.5D (ZUI : Zoomable User Interface). Celle-ci offre un en-vironnement 2D combiné à une fonction de zoom continu permettant un contrôle plus fin et plus rapide de l’altitude d’observation comparé aux possibilités limitées de zoom discret de certains environnements 2D. Comme nous l’avons vu dans le chapitre 3, les interfaces zoomables sont une alternative aux tech-niques de focus+contexte comme les vues hyperboliques et les vues multiples (radar). Elles offrent des mécanismes adaptés à la représentation de grandes quantités d’information. Nous pensons aussi qu’elles rendent possible ou tout du moins plus aisée l’utilisation de certaines techniques de visualisation comme les treemaps [130] qui représentent les structures d’arbres au moyen de formes emboîtées et nécessitent donc des fonctions de zoom pour explorer les branches profondes de la structure. Une variante de cette technique est utilisée pour la représentation des structures dans VXT (chapitre 4).

Les interfaces 2.5D ont fait leur apparition dans les années 90 et il existe encore peu de boîtes à outils dédiées. On peut citer Pad++ [15, 16], Jazz [17] (une évolution de Pad++ en Java) et Zomit [186]. Dans ce chapitre, nous présentons XVTM (Xerox Visual Transformation Machine), une boîte à outils expérimentale que nous avons développé dans le cadre de ce travail de thèse. XVTM est implémentée en Java et permet notamment la conception d’interfaces zoomables. Son but est de faciliter la conception de l’interface d’environnements de visualisation/édition dans lesquels l’utilisateur doit manipuler et animer de grandes quantités d’objets aux formes géométriques pouvant être complexes. Les fonctionnalités de la XVTM reposent sur les principes étudiés dans le chapitre 3 «Langages visuels : État de l’art», dans le but d’aider les programmeurs à créer plus facilement des interfaces visuelles de bonne qualité.

5.1 Origines