Christophe Hurter
email: christophe.hurter@aviation-civile.gouv.fr

Vincent Gaits
email: vincent@gaits.fr

Hasna Nadfaoui
email: h.nadfaoui@gmail.com

Jérome Pailler
email: jerome.pailler@laposte.net

Catherine Letondal
email: catherine.letondal@enac.fr

Stéphane Conversy
email: stephane.conversy@enac.fr

Etude exploratoire du stylo électronique pour le contrôle aérien

Keywords: Informatique papier, papier augmenté, stylo numérique, papier interactif, interfaces tangibles, visualisation, contrôle aérien, conception participative Categories and Subject Descriptors H5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous Design, Human Factors Paper computing, augmented paper, digital pen, interactive paper, tangible interfaces, visualization, air traffic control, participatory design

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Le but du contrôle aérien est de maximiser à la fois la sûreté de fonctionnement et la capacité, c'est-à-dire gérer des vols sans compromettre la vie des passagers ou engendrer des retards. Les prévisions montrent que le trafic devrait doubler d'ici 2030 : les systèmes actuels ne seront alors plus adaptés. Aussi, les autorités régulatrices européennes et états-uniennes ont décidé de concevoir de nouveaux systèmes. Les consortia SESAR [START_REF] Ky | SESAR: towards the new generation of air traffic management systems in Europe[END_REF] et NextGen [START_REF] Erzberger | Transforming the NAS: The Next Generation Air Traffic Control System[END_REF], dotés de plusieurs milliards d'euros ou de dollars, visent à changer les matériels, les logiciels, l'organisation de l'espace aérien et les procédures suivies par les contrôleurs humains. Comme dans toute activité, l'efficacité des contrôleurs dépend de l'efficacité de l'instrumentation de l'activité de contrôle. Les systèmes actuels mêlent des visualisations informatiques (images radar par exemple), et des systèmes tangibles, notamment le strip papier, une bande de papier imprimée à chaque entrée d'un vol dans un secteur. Le strip papier contient des informations planifiées pour un vol (sa route par exemple). Bien que le support papier s'avère robuste, souple et complémentaire de l'image radar, les autorités ont décidé de l'abandonner, notamment parce que cette technologie ne permet pas de renseigner le système informatique et ne permet donc pas de bénéficier d'algorithmes d'automatisation potentiels. Les récentes avancées technologiques, comme les écrans multi-touch, semblent leur donner raison car elles permettent d'envisager des systèmes se passant du papier [START_REF] Conversy | Supporting Air Traffic Control Collaboration with a TableTop System[END_REF], mais l'avènement de telles technologies se fait au détriment des qualités de l'interaction avec le papier. Pourtant, les progrès du stylo numérique et du papier augmenté permettent d'envisager leur utilisation dans le cadre du contrôle aérien. En d'autres termes, le futur a changé : des technologies, comme le papier, que l'on croyait dépassées redeviennent d'actualité, et peuvent à nouveau faire partie de l'ensemble des techniques visant à améliorer l'instrumentation de l'activité des contrôleurs.

Cet article présente une étude de l'utilisation de stylos hybrides Anoto1 avec communication continue (streaming) pour le contrôle aérien. Nous avons observé l'activité de contrôle et réalisé un travail de conception des interactions stylo/papier numérique en coopération avec des contrôleurs. Notre objectif est de renseigner le système tout en supportant réellement et efficacement l'activité des contrôleurs et ainsi répondre à la question « comment un système Anoto peut-il améliorer l'interaction par rapport aux systèmes usuels ou par rapport aux systèmes informatiques alternatifs ? » Dans la première partie de cet article, nous introduisons l'activité de contrôle et le système actuel. Puis nous présentons une analyse de l'activité, focalisée sur les transitions entre les visualisations à disposition des contrôleurs, de laquelle nous tirons des besoins. Enfin nous détaillons les interactions que nous avons conçues, ainsi qu'une évaluation préliminaire.

LE CONTROLE AERIEN ET SON EVOLUTION

Dans cette section, nous décrivons brièvement les tâches des contrôleurs « en-route » (par opposition à « en approche » ou en « tour »), en nous concentrant sur les transitions entre les visualisations. Nous expliquons ensuite les raisons qui ont poussé à l'abandon des systèmes actuels, et des problèmes que cet abandon soulève.

Outils et procédures traditionnels de contrôle

L'activité des contrôleurs « en route » consiste principalement à maintenir une distance de sécurité entre avions. Pour cela, l'espace aérien est divisé en secteurs, chacun des secteurs étant sous la responsabilité d'une paire de contrôleurs. Quand un vol traverse un secteur, les contrôleurs guident le pilote en lui donnant des ordres (clearances) de cap, de vitesse ou d'altitude, jusqu'à ce que le vol atteigne un secteur adjacent, où d'autres contrôleurs prennent la responsabilité du vol en question.

Dans un environnement typique, deux contrôleurs sont assis devant une Position de Contrôle, spécialement conçue pour appuyer leur activité. Une position de contrôle traditionnelle comprend un ensemble de sous-systèmes principaux : deux écrans radar (un pour chaque contrôleur), et un tableau horizontal servant de support physique aux strips partagé par les deux contrôleurs [START_REF] Mackay | Is paper safer? The role of paper flight strips in air traffic control[END_REF].

Qualités du papier

De nombreux chercheurs ont souligné l'importance des strips dans l'ATC [START_REF] Sellen | The Myth of the Paperless Office[END_REF] [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF]. L'utilisation de l'outil papier/stylo offre une grande flexibilité et une grande efficacité, tant sur le plan de l'organisation de l'espace de travail, que sur le format ou la procédure. Cette flexibilité permet aux contrôleurs de s'affranchir en partie de certaines règles contraignantes de remplissage des strips papier nécessaire à la fluidité et l'efficacité des interactions [START_REF] Harris | A better mythology for system design[END_REF]. Le papier est également un support de communication aisé : il peut être lu, transmis, voire écrit par plusieurs personnes en même temps. A travers le strip, on ne communique d'ailleurs pas seulement des informations : l'échange d'un strip entre deux contrôleurs représente la transmission de la responsabilité du vol. C'est la liberté de mouvement qui rend fluide ce partage. Elle permet aussi d'adapter l'organisation spatiale des strips sur le tableau, même si celle-ci est précisément définie par les procédures et la culture de tel ou tel centre de contrôle [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF]. Le papier est aussi un moyen de travail beaucoup plus sûr qu'un outil informatique, dans le sens où il ne tombe pas en panne (c'est un argument des détracteurs du stripping électronique), d'autant plus que le tableau de strips réifie une procédure qui permet au contrôleur de construire une représentation mentale du trafic aérien indépendante des outils utilisés.

Problèmes du papier

Même si le papier dispose de nombreux avantages par rapport au numérique, il n'en conserve pas moins des défauts. Le strip ne peut servir ni de dispositif d'entrée, ni de dispositif d'affichage dynamique. D'une part, même si les représentations strip et image radar sont deux vues sur les mêmes informations [START_REF] Conversy | A Descriptive Model of Visual Scanning[END_REF], et même si des liens existent entre ces deux représentations à travers les divers identifiants (vol, balise, …), ces liens ne sont pas explicites, ce qui rend difficile le passage d'une vue à l'autre. D'autre part, dans le cas du contrôle aérien, l'entrée d'information est souvent redondante : certaines inscriptions portées sur les strip doivent être reportées sur l'image radar (par exemple particulariser un avion sur le strip et l'écran radar).

Par ailleurs, dans le but d'accroître la capacité de manière significative, les programmes SESAR et NextGen promeuvent l'automatisation de la surveillance de la séparation entre avions [START_REF] Ky | SESAR: towards the new generation of air traffic management systems in Europe[END_REF] [START_REF] Erzberger | Transforming the NAS: The Next Generation Air Traffic Control System[END_REF]. Cependant, la précision et l'efficacité de la séparation automatique dépendent de la mise à jour de la connaissance par le système des trajectoires prévues et modifiées. L'interaction usuelle, à base de papier/stylo et de parole au micro, ne fournit pas au système les modifications et les ordres des contrôleurs. C'est ce qui a conduit à des projets visant à remplacer le papier/stylo et la parole par des outils informatiques.

Le projet Cameleon [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF] a montré l'intérêt de conserver les strips papier et de créer des liens entre strips et systèmes informatiques. Ce projet s'appuyait sur des technologies non abouties en termes de fiabilité et d'efficacité. Aujourd'hui, le stylo numérique est une technologie arrivée à maturité qui permet de communiquer efficacement avec les systèmes informatiques. Cameleon a exploré en largeur les différentes techniques et services envisageables pour des strips « connectés » au système informatique. Notre travail est une étude en profondeur de l'une de ces technologies : les stylos Anoto, avec communication continue des actions du stylo.

ETAT DE L'ART

Notre approche s'apparente au stripping électronique, ainsi qu'aux travaux sur les vues multiples et sur l'informatique papier.

Stripping électronique

Quelques projets de recherche ont eu pour but de concevoir des systèmes de stripping électronique cherchant à préserver la qualité de l'interaction avec le papier. DigiStrips [START_REF] Mertz | The influence of design techniques on user interfaces: the DigiStrips experiment for air traffic control[END_REF] est un prototype qui utilise deux écrans tactiles résistifs (un par contrôleur). L'un des objectifs de ce projet était de proposer une interaction proche de celle offerte par le papier (dessin libre par ex.), tout en renseignant le système avec les ordres écrits. Ainsi, les auteurs ont pris un soin particulier à concevoir des interactions et retours graphiques, de façon très détaillée. ASTER [START_REF] Benhacene | Tackling the problem of flight integration. 7th ATM seminar Barcelone[END_REF] est un projet similaire utilisant des tablettes2 et une interaction avec un stylet. Enfin, SmartStrip, une version de Digistrip (stripping électronique) vient d'être installée dans les centres de controles en Angleterre.

Vues multiples

Comme nous l'avons vu, le système de contrôle en route est composé de sous-systèmes, donc de vues différentes et séparées représentant les mêmes données [START_REF] Conversy | A Descriptive Model of Visual Scanning[END_REF]. En tant que telles, elles sont sujettes aux mêmes problematiques que celles des vues multiples en visualisation d'information [START_REF] Baldonado | Guidelines for using multiple views in information visualization[END_REF]. Le système que nous envisageons ne remet pas en cause la nature de ces vues, mais cherche à les adapter. Il n'est soumis qu'à la problématique suivante parmis celles de [START_REF] Baldonado | Guidelines for using multiple views in information visualization[END_REF] : comment passer d'une vue à l'autre (notamment retrouver une entité de la vue A dans la vue B, appelé linking). Les systèmes ASTER [START_REF] Benhacene | Tackling the problem of flight integration. 7th ATM seminar Barcelone[END_REF], MAMMI [START_REF] Conversy | Supporting Air Traffic Control Collaboration with a TableTop System[END_REF] et Cameleon [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF] permettent aux utilisateurs de repérer des vols sur l'image radar, à partir d'une interaction sur le strip correspondant.

Informatique papier

L'informatique papier (paper computing) Erreur ! Source du renvoi introuvable. s'intéresse à la combinaison du papier et de l'électronique : intégration de contenu manuscrit dans des systèmes électroniques ou plus généralement manipulation de documents électroniques et interactions à partir du papier [START_REF] Tsandilas | Musink: composing music through augmented drawing[END_REF] [24], notamment par l'intermédiaire d'un stylo numérique. Les approches varient en termes de types d'utilisation, de techniques d'interaction et de modes de visualisation de contenus hybrides. La co-visualisation de contenus hybrides permet de juxtaposer ou de mélanger documents numériques ou tracés manuscrits de plusieurs manières superposée, par exemple en projetant des informations sur le papier [START_REF] Song | MouseLight: bimanual interactions on digital paper using a pen and a spatially-aware mobile projector[END_REF], adjacente [START_REF] Liao | PapierCraft: a command system for interactive paper[END_REF] ou par coindexation temporelle [START_REF] Letondal | L'écriture augmentée: enregistrer des explorations interactives avec une feuille de données scientifiques[END_REF]. L'affichage d'informations manuscrites dans l'image radar relève donc du mode adjacent. Différents traitements du tracé ont été proposés, depuis le nontraitement, où le tracé est restitué et intégré numériquement tel quel jusqu'à la reconnaissance de caractères (LiveScribe), de gestes (comme pour tagger les documents [START_REF] Liao | PapierCraft: a command system for interactive paper[END_REF]) ou de formes, notamment pour les applications de sketching. L'interaction peut être continue avec un système de streaming [START_REF] Song | MouseLight: bimanual interactions on digital paper using a pen and a spatially-aware mobile projector[END_REF], embarquée sur le stylo [START_REF] Song | MouseLight: bimanual interactions on digital paper using a pen and a spatially-aware mobile projector[END_REF], ou encore différée [START_REF] West | MEMENTO: a digitalphysical scrapbook for memory sharing[END_REF]. Dans notre projet, nous utilisons le streaming pour pouvoir renseigner immédiatement le système des actions effectuées au stylo.

Etude de l'activité

La prise de connaissance des règles de travail au travers les livrets de formation du contrôle aérien, comme la tenue de strip et la phraséologie, a dû être complétée par une observation de l'activité réelle du contrôleur. En effet, l'application des procédures donne lieu à de nombreuses variations d'un centre de contrôle à l'autre. De plus, les méthodes de travail des contrôleurs ayant évolué régulièrement avec la mise en opérationnel de nouveaux systèmes informatiques, les études ethnographiques précédentes [START_REF] Bisseret | représentation et décision expertepsychologie cognitive de la décision chez les aiguilleurs du ciel[END_REF] [16] devaient être complétées. Trois séances d'observation ont été effectuées avec neuf contrôleurs confirmés (avec plus de 5 ans d'expérience) dans le cadre de séances de formation avec du trafic aérien simulé (dans les salles de simulation du centre de contrôle en route de l'ENAC). A l'issue de chaque séance d'observation, nous avons posé des questions pour éclaircir certains points techniques comme les différences entre la théorie des livrets et leur application, ou encore pour nous aider à identifier les tâches réalisées par les contrôleurs qui semblent difficiles (forte charge cognitive) ou qui sont des facteurs de risque pour la sécurité du trafic aérien (par exemple les phases de détection de conflit entre avions). Nous avons axé les séances sur l'observation en profondeur de l'activité des contrôleurs au regard des interactions entre l'écran radar et le tableau de strip (linking, homing de Keystroke [START_REF] Card | The keystroke-level model for user performance time with interactive systems[END_REF] et dans une moindre mesure la collaboration).

Résultats et scénarios de travail

Nos observations confirment celles des études précédentes [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF], concernant notamment la tenue du strip qui peut changer en fonction de la charge de travail, le placement des strips variant d'un centre à l'autre ou la tangibilité des strips qui sont souvent le support d'une communication non verbale (le geste de transmission d'un strip entre contrôleurs porte parfois une information : le strip peut être posé délicatement ou encore « jeté » en travers sur le tableau de strips).

Plus spécifiquement, nous avons observé un certain nombre de tâches récurrentes :

 recherche d'un avion sur l'écran radar. Cette activité est la plus fréquente, par exemple lors de l'intégration d'un nouvel avion par le contrôleur aérien lorsque son strip est imprimé. Le contrôleur doit alors lire le nom de l'avion sur le strip et le chercher sur l'écran radar,  calcul de distance entre avions et estimation de la distance minimale dans le cas d'un croisement,  message de clairance à un avion (changement de cap, niveau de vol ou vitesse) et ainsi renseigner les systèmes informatiques avec l'image radar,  particularisation d'un avion (message d'alerte, texte libre..).

Ces tâches peuvent être instrumentées plus efficacement par l'utilisation du papier augmenté.

Workshops, design walkthrough et prototype

A l'aide de ces scénarios de travail, une séance de brainstorming a été réalisée avec trois autres contrôleurs aériens confirmés et deux chercheurs en IHM. Pendant cette séance, les caractéristiques techniques du papier augmenté ont été expliquées, puis nous avons validé les scénarios choisis, et nous avons étudié des paradigmes d'interactions avec le papier augmenté. A l'issue de cette séance, nous avons réalisé des prototypes du logiciel qui ont été évalués dans une séance de design walkthrough [START_REF] Mackay | Educating Multi-disciplinary Design Teams[END_REF] avec deux autres contrôleurs aériens confirmés. Enfin, nous avons réalisé un prototype opérationnel que nous avons évalué au cours de séances de test filmées avec deux contrôleurs, qui ont également rempli un questionnaire.

BESOINS, EXIGENCES

Les observations in situ, la séance de brainstorming, et le design walkthrough nous ont permis de synthétiser les besoins (B) et exigences (E) pour instrumenter efficacement l'activité du contrôleur aérien avec la technologie Anoto.

B1 : renseigner les systèmes informatiques avec les actions des contrôleurs aériens

Certaines procédures réalisées par les contrôleurs aériens demandent de renseigner à la fois les systèmes informatiques (par le biais de l'image radar) et les strips en les annotant. C'est par exemple le cas de la particularisation d'un avion : le contrôleur utilise la souris pour mettre le nom de l'avion d'un certaine couleur dans l'image radar et inscrit un « P » sur son strip. Ce mécanisme peut entrainer des oublis ou des incohérences entre la représentation du trafic donnée par les strips et celle fournie par l'écran radar. Renseigner le système est une procédure coûteuse en temps car elle doit être faite pour chaque système (écran radar, système de gestion des plans de vol, contrôleurs).

B2 : améliorer l'efficacité pour la réalisation des actions du contrôleur aérien

Nous avons relevé des tâches redondantes et coûteuses, tant au niveau cognitif qu'au niveau temporel. Les objectifs de ces tâches doivent être intégrés au nouveau système et les tâches doivent être réalisées de manière plus rapide qu'avec le système précédent. Par exemple, le temps de passage d'un outil de travail à un autre (passage du stylo et de l'annotation des strips à la souris pour interagir avec l'écran radar) est apparu lors des observations comme une perte de temps.

B3 : faciliter le passage entre visualisations

Les contrôleurs passent très fréquemment de la visualisation fournie par les strips à la visualisation fournie par l'écran radar. L'activité la plus courante est la recherche de la correspondance entre la comète radar (positions passées et courante de l'avion) et le strip papier du même avion (linking). Ces changements fréquents obligent les contrôleurs à déplacer leur attention et leur centre d'intérêt d'une visualisation à une autre et de rechercher un objet d'intérêt (scanning) [START_REF] Conversy | A Descriptive Model of Visual Scanning[END_REF]. Notre système s'attachera donc à faciliter ces passages entre visualisations.

B4 : assurer la collaboration entre contrôleurs

Les contrôleurs aériens travaillent en collaboration sur leur poste de travail. Les strips circulent entre les contrôleurs ; ils peuvent être analysés et annotés par chacun d'eux. Le système doit conserver les qualités du papier pour appuyer la collaboration.

E1 : respecter la méthodologie de travail actuelle

Dans le domaine du contrôle aérien, toute modification matérielle ou méthodologique a un coût très élevé en termes de développement et de vérification pour assurer les exigences de sécurité. Les utilisateurs, en général, sont aussi très réticents à tout changement entrainant de fait une phase d'apprentissage qui peut être pénalisante (augmentation de la charge cognitive, et nouveaux facteurs de risques identifié et non identifiés pour l'activité).

L'utilisation du stylo numérique permet de conserver l'ensemble des outils de travail des contrôleurs. En effet, ceux-ci utilisent déjà un stylo pour annoter leurs strips. Bien que l'aspect du stylo Anoto diffère légèrement de celui d'un stylo classique (diamètre plus large, etc…), sa prise en main reste similaire. De plus, le format des strips n'est pas modifié par l'augmentation du papier : seule une trame doit être imprimée au préalable, affectant très peu leur rendu visuel avec un léger voile gris. Enfin, la méthodologie de contrôle, les différents symboles, notations et codes couleurs théoriques, ou observés peuvent être conservés.

DESCRIPTION DU SYSTEME

Suite à notre démarche d'analyse et de conception, plusieurs interactions ont été implémentées dans un prototype fonctionnel. Ce prototype a été réalisé en C# avec le langage .net 2.0 qui permet de s'interfacer très simplement avec les librairies du constructeur Anoto. Nous avons utilisé le bus logiciel IVY [START_REF] Buisson | Ivy: un bus logiciel au service du développement de prototypes de systèmes interactifs[END_REF] pour faire communiquer les modules logiciels du prototype (gestion du stylo, écran radar, reconnaissance d'écriture).

Dans cette partie, nous décrivons nos choix de design et d'interaction (I) pour l'implémentation de fonctions qui respectent les besoins et contraintes précédemment détaillés.

I1 : sélection d'un avion sur l'écran radar à partir de son strip

I3 : modification du niveau de vol d'un avion pour l'échange entre secteurs de contrôle

La « ModS » consiste à modifier l'altitude de vol pour le transfert d'un avion au secteur de contrôle suivant. Cette modification permet d'imprimer sur le secteur suivant le strip avec la bonne altitude de vol de l'avion.

Comme pour la particularisation d'un vol, le contrôleur doit utiliser la souris pour effectuer une ModS sur l'écran radar. Avec le stylo Anoto, il suffit d'écrire le nouveau niveau de vol dans la case correspondante. Pour cette interaction, il est nécessaire de produire un feed-back pour confirmer à l'utilisateur que le système a effectué correctement la reconnaissance d'écriture et la mise à jour du système. L'étiquette radar est ainsi modifiée en affichant le nouveau niveau de coordination (Figure 3). Cette interaction, comme I2, respecte B1, B2 et E1. Cette interaction ne modifie donc pas les méthodes de travail (E1). L'échange d'informations entre contrôleurs de secteurs différents se fait aujourd'hui par l'intermédiaire du téléphone. En permettant de conserver sur l'image radar les informations manuscrites, cette interaction permet une communication facilitée entre les centres de contrôle (B4).

I6 : alarmes différées

Les alarmes différées n'existent pas dans le système actuel. Ce concept permet aux contrôleurs de déléguer la mémorisation de certains évènements comme « ne pas oublier de rappeler un avion lorsqu'il va entrer dans un secteur … ». Pour définir une alarme, le contrôleur inscrit un T (pour timer) dans une case du strip qui contient le nom d'une balise (Figure 5, gauche). Un symbole dans l'étiquette radar de l'avion indique qu'une alarme a été définie et lorsque l'avion approchera de cette balise Figure 5, milieu), un cercle bleu va entourer la comète radar (Figure 5, droite). En déléguant la planification de ces tâches au système, le contrôleur diminue sa charge cognitive (B2).

I7 : filtrage des avions par niveau de vol

Actuellement, pour détecter des conflits potentiels entre avions, les contrôleurs effectuent mentalement du filtrage par altitude à l'aide des informations contenues sur les strips. La réalisation informatique d'un tel outil a été proposée lors du premier brainstorming.

Pour utiliser cet outil dans le prototype, l'utilisateur doit pointer, avec son stylo la case « niveau de vol » d'un strip. Ainsi, tous les avions qui ne volent pas à la même altitude que celui pointé par l'utilisateur sont grisés. Ce design utilise les principes établis par Wheelie [START_REF] Bering | WHEELIE -a mobile horizontal display filter to ease controller's separation task[END_REF] avec l'affichage en gris au milieu de l'écran des niveaux de vol filtrés. Nous avons amélioré ce design en ajoutant des flèches qui s'affichent lorsqu'un avion filtré est à l'extérieur de l'écran radar, ce qui est particulièrement utile pour prendre en compte les avions non visibles qui vont entrer dans le secteur. L'utilisateur peut aussi modifier les valeurs du filtrage en traçant un trait vers le haut ou vers le bas. La plage du filtre évolue en fonction de la longueur et de la direction du trait (Figure 6). Cette interaction permet d'améliorer l'efficacité du contrôleur pour analyser les strips (B1).

CONCLUSION ET PERSPECTIVES

En terme de contribution, ce projet combine l'intégration de contenu manuscrit/numérique avec reconnaissance d'écriture, la co-visualisation (disjointe) et la commande à partir du papier. Dans le domaine du contrôle aérien, il complète la démarche initiée dans le cadre du projet Cameleon [START_REF] Mackay | Reinventing the familiar: exploring an augmented reality design space for air traffic control[END_REF] qui ne disposait pas des technologies adéquates au moment de sa publication. Sans avoir encore implémenté tous les scénarios qui étaient imaginés, ce projet propose un prototype abouti et fonctionnel qui permettra d'explorer et d'évaluer les interactions papier/ordinateur dans le détail. Il propose également de nouvelles interactions, telles que l'alarme différée ou les interactions multi-strips de calcul de distance. Enfin, comparé aux approches de striping électroniques (Digistrip, Aster) qui mettent en oeuvre une représentation de type strips électroniques respectueuse de la tâche du contrôleur, ce projet représente une alternative effective à laquelle ces systèmes pourront se comparer, notamment sur le plan de la collaboration et de la gestion de la tâche.

Figure 1 :

 1 Figure 1: sélection d'un avion : le contrôleur pointe la case information du strip, ce qui déclenche une animation sur l'image radar avec un cercle qui rétrécit et se centre sur l'avion. I2 : particulariser un vol sur l'écran radar Pour particulariser un vol, le contrôleur doit aujourd'hui utiliser la souris et ouvrir un menu contextuel sur la vue radar puis sélectionner le type de particularisation (particularisation simple ou warning). Dans le cas du warning, il doit inscrire la lettre W sur le strip. Avec le stylo Anoto, le contrôleur peut directement particulariser un avion en écrivant un « P » dans la case d'informations ou un « W » dans un des cases de route (Figure 2). Le système de reconnaissance d'écriture détecte la lettre inscrite. Ces fonctions permettent d'améliorer l'efficacité de l'application par rapport à l'ancien système en éliminant le temps de « homing », c'est-à-dire le temps que le contrôleur met pour passer du stylo et de son tableau de strip à sa souris et son image radar. Elles permettent ainsi au contrôleur de ne pas avoir à changer d'outil de travail (B2). De plus, certaines de ces actions (comme l'écriture du « W » sur le strip) sont déjà des actions intégrées dans les procédures de contrôle et ne nécessitent aucun apprentissage de la part de l'utilisateur (E1). La mise en place de ces fonctions permet aussi d'assurer une cohérence entre la tenue du strip et l'image radar (B1), ce qui permet d'éviter les erreurs et les incohérences entre les informations présentes sur le tableau de strip et sur l'image radar.

Figure 2 :

 2 Figure 2: particulariser un vol. Lors du design walktrough, deux autres modes d'interaction différents avaient été proposés pour ces fonctions : l'impression de zones associées à une fonction (équivalant à des « boutons ») directement sur le strip, et la création d'une feuille annexe servant de barre de commande. Mais ces choix de design ne permettent pas de respecter E1 (garder l'existant), et allongent la durée de l'action de pointage.

Figure 3 :

 3 Figure 3: Mods, modification du niveau de vol de coordination entre secteurs. I4 : calcul de distance entre avions La distance entre deux avions est régulièrement calculée pour détecter les conflits. Le contrôleur doit connaitre la route de chaque avion et calculer en fonction de leur vitesse le point de croisement. Cette action est facilitée par l'utilisation du strip Anoto : le contrôleur pointe séquentiellement la même balise sur deux strips. L'image radar affiche alors la route des deux avions avec l'indication de distance en rouge au point de passage sur la balise. Cette fonction est « non intrusive » : elle ne fait que présenter des informations au contrôleur et le laisse juge de la détection des conflits potentiels (E1). Elle permet aussi un gain de temps (B2) dans l'évaluation des conflits, en fournissant les différentes informations au contrôleur sans avoir besoin de changer d'outil (prendre la souris pour utiliser l'outil de mesure de distance sur l'écran radar) ni de faire de calculs mentaux. I5 : écriture d'un texte d'information sur le strip D'après nos observations, les contrôleurs utilisent le strip comme support pour mémoriser des informations : « problème technique », « passager malade »… A l'aide du stylo numérique, les informations manuscrites inscrites dans une case vide du strip apparaissent automatiquement sur l'image radar et ainsi être partagées par plusieurs contrôleurs (Figure 4).

Figure 4 :

 4 Figure 4: le contrôleur inscrit du texte libre sur le strip.

Figure 5 :

 5 Figure 5: le contrôleur inscrit la lettre T pour définir une alarme lorsque l'avion approchera la balise LERGA.

Figure 6 :

 6 Figure 6 : filtrage des avions par niveaux de vol. L'utilisateur trace un trait vers le haut pour filtrer les niveaux supérieurs. I8 : écriture manuscrite du nom de l'avion sur l'étiquette radar Dans le cas d'un avion dont le plan de vol est non renseigné, l'étiquette radar affiche uniquement le code transpondeur de l'avion (identifiant sur quatre digits) à la place de son nom usuel

Figure 7 :

 7 Figure 7: le contrôleur inscrit le nom de l'avion en écriture manuscrite dans l'étiquette radar.

7 .

 7 EVALUATION DU PROTOTYPE FONCTIONNELUne évaluation a été réalisées avec deux contrôleurs aériens en utilisant du trafic simulé et un scénario de travail guidé. Il était demandé aux contrôleurs d'effectuer des tâches de contrôle avec les outils traditionnels, puis la même tâche avec le stylo Anoto.Les évaluations ont été filmées. Les retours d'utilisateurs ont été recueillis par des questionnaires d'évaluation.Le Tableau 1 résume les résultats des questionnaires remplis par les deux contrôleurs (C 1 et C 2 ) pour évaluer les fonctionnalités implémentées avec le classement de leur intérêt (1 pour le plus intéressant) et du niveau de satisfaction concernant leur implémentation (++ pour le plus satisfaisant). Le Tableau 1 reporte les commentaires des contrôleurs à l'issue des tests.Tableau 1 : classement des fonctions par les contrôleurs. manière générale, les contrôleurs ont particulièrement apprécié que l'utilisation du stylo ne modifie pas exagérément leurs méthodes de travail et permet même de la simplifier. Cependant, les choix initiaux de design de l'affichage ont dû être atténués pour conserver une certaine sobriété de l'image radar. Ainsi, les animations et les couleurs saturées doivent prioritairement être utilisés pour signaler des alertes et des situations dangereuses (I1, I2, I5, I7, I8

  ). Certaines contraintes techniques ont été jugées contraignantes comme la faiblesse de la reconnaissance de geste et le manque de feedback sur le succès des actions du stylo. Aussi, un feedback sonore a été ajouté pour la deuxième séance d'évaluation, ce qui a permis au contrôleur de prendre plus rapidement confiance avec le système. En contrepartie, les sons produits deviennent rapidement gênants et devront sans doute être reconçus. La succession des actions finit par altérer le strip et a été jugé comme un problème potentiel pour une tenue claire du strip. Ce problème est connu : une solution proposée serait d'utiliser un stylo avec deux mines, une qui laisse de l'encre et l'autre non, mais cette solution nécessiterait une modification matérielle et un changement de mode physique (écriture ou non).Une des hypothèses forte du projet, qui nous a servi de fil directeur tant durant la phase d'observation que pour les choix de conception, est le double besoin de combler le fossé entre media, et de combler le fossé entre les représentations radar et strips. C'est à ce double besoin que répondent les interactions de sélection et de particularisation d'un vol, de changement de niveau, de filtrage et de calcul de distance où le strip devient non plus seulement un outil de gestion du processus de contrôle, mais aussi un lien sélectif avec l'image et le système informatique, interactions pour lesquelles le stylo se révèle un bon dispositif de pointage. Pour certaines interactions, ce lien est potentiellement d'autant plus « direct » et économique qu'il résulte d'une action d'écriture qui aurait lieu de toutes manières pour la maintenance du strip (par exemple la ModS). Ce gain, en terme d'efficacité (moins d'opérations complexes et redondantes), se traduit par un mélange potentiel entre les deux représentations : ainsi, l'entrée manuscrite de vignette atteint le « sanctuaire » de l'image radar. Cet aspect devra sans doute être discuté au regard des besoins des contrôleurs : la séparation des représentations est-elle seulement un reliquat historique (l'image radar s'est rajoutée au tableau de strips), ou correspond-elle à un besoin fonctionnel consistant à dissocier les vues, l'une nette, objective et disposée géographiquement (l'écran radar), l'autre (le tableau de strips) orientée vers la gestion de la tâche et la collaboration, supportant l'information informelle, et disposée selon la logique des opérations ? Une réaction de rejet d'un des contrôleurs ayant participé à l'étude à l'idée de note manuscrite affichée sur l'image radar, déclarant que cela pourrait « salir » l'écran.

	unanimement apprécié la sélection d'un avion sur l'écran radar à Les contrôleurs ont	8. DISCUSSION
	partir de son strip (I1) : elle leur fait économiser du temps et
	diminue leur charge cognitive. Lors des tests, les contrôleurs ont proposé d'autres utilisations similaires : désignation d'un avion à
	un autre contrôleur, ou aide aux contrôleurs en formation pour
	connaitre un secteur.
	Tableau 2 : remarques sur les fonctions implémentées.
	Fonctions	remarques
	I1 : sélectionner	L'animation du feedback doit être plus
	un avion	rapide.
	I2 : filtrage par niveaux	Texte du filtrage des présents sur l'image radar.	niveaux trop
	I3 : ModS	Réduire le feedback et se contenter de le mettre autour de l'avion /balise
		seulement.
	I4 : saisie d'une information	Information trop présente et cache une partie de l'image radar.
	I5 : warning	Problème de reconnaissance du caractère
		« W ».
	I6 : calcul de	La distance minimale de séparation n'est
	distance	pas une simple différence de distances. Les couleurs utilisées pour l'affichage des
		routes sont inappropriées.
	I7 : particulariser	Pas de remarque.
	I8 : alarmes différées	Feedback jugée exagéré par rapport à l'intérêt qu'il présente.
	I9 : changement d'étiquette	Ne ressemble pas à une étiquette « normale ».
	La fonction de filtrage par niveau de vol (I2) n'a pas fait l'unanimité parmi les deux contrôleurs. Ceci s'explique par la
	différence de leurs méthodes de travail. Un contrôleur préférait faire du filtrage directement sur l'écran radar (I2 est alors apprécié), l'autre utilise principalement les strips (I2 est alors peu
	utile). I7 (particulariser) a été appréciée. Mais la reconnaissance d'écriture à moins bien fonctionnée avec un utilisateur, ce qui
	explique la différence des classements. Les alarmes temporelles
	(I8) sont basées sur les estimées de passages aux balises. Bien que
	ce système ne soit pas très précis, il a été jugé suffisant par les contrôleurs, car il n'a aucun impact sur la sécurité des vols. L'affichage dans l'étiquette radar d'informations manuscrites a tout d'abord été refusé par les contrôleurs sous prétexte que la vue
	radar allait perdre son caractère codifié. Avec un design moins

prégnant (petite étiquette, pas de couleur de fond), cette fonctionnalité a été mieux reçue. Lorsque le contrôleur effectue des actions sur le strip avec le stylo Anoto (e.g. sélectionner un avion, changer le niveau de filtrage…), une trace écrite est laissée.

http://www.anoto.com

LCD WACOM4. METHODOLOGIENous avons effectué une étude de l'activité du contrôle aérien en utilisant des méthodes classiques participatives de l'IHM, avec une étude ethnologique basée sur des observations, suivie de la génération de scénarios de travail réalistes, ainsi que des séances de brainstorming et de conception.

Avec les outils traditionnels, pour trouver un avion sur son écran radar à partir de son strip, le contrôleur aérien doit lire la route de l'avion sur le strip et évaluer mentalement sa position réelle en fonction de l'heure courante. Avec notre système, le contrôleur pointe, avec son stylo, la case information du strip ce qui déclenche une animation sur l'image radar avec un cercle qui rétréci et se centre sur l'avion sélectionné[START_REF] Baudisch | Halo: a technique for visualizing off-screen objects[END_REF] (Figure1). Cette fonction permet de réaliser une correspondance entre deux visualisations de l'espace aérien (B2 : visualisations par les strips et visualisations par l'image radar).

Nous allons axer nos travaux futurs sur une étude plus fine des transitions entre visualisations en fonction des tâches utilisateurs, en distinguant plus spécifiquement celles qui partent de l'écran radar et celles qui partent du tableau de strips. D'autre part, il nous faut explorer de meilleures solutions de feedback des actions réalisées à l'aide du stylo (retour visuel, audio, haptique, …).


Benjamin Tissoires
email: tissoire@cena.fr

Stéphane Conversy
email: stephane.conversy@enac.fr

Hayaku: Designing and Optimizing Finely Tuned and Portable Interactive Graphics with a Graphical Compiler

Keywords: Human-Computer interfaces, User Interface Design, Methods and Applications, Optimization ACM Classification H.5.2 User Interfaces: GUI

Although reactive and graphically rich interfaces are now mainstream, their development is still a notoriously difficult task. This paper presents Hayaku, a toolset that supports designing finely tuned interactive graphics. With Hayaku, a designer can abstract graphics in a class, describe the connections between input and graphics through this class, and compile it into runnable code with a graphical compile chain. The benefits of this approach are multiple. First, the frontend of the compiler is a rich standard graphical language that designers can use with existing drawing tools. Second, manipulating a data flow and abstracting the low-level run-time through a front-end language makes the transformation from data to graphics easier for designers. Third, the graphical interaction code can be ported to other platforms with minimal changes, while benefiting from optimizations provided by the graphical compiler.

INTRODUCTION

Interactive graphics development is a notoriously difficult task [START_REF] Myers | Challenges of HCI design and implementation[END_REF][START_REF] Myers | How designers design and program interactive behaviors[END_REF]. In particular, rich interactive systems design requires finely-tuned interactive graphics [START_REF] Hartmann | Design as exploration: creating interface alternatives through parallel authoring and runtime tuning[END_REF], which consists of a mix of graphical design, animation design and interaction design. Subtle graphics, animations and feedback enhance both user performance and pleasure when interacting [START_REF] Mertz | The influence of design techniques on user interfaces: the DigiStrips experiment for air traffic control[END_REF]. The success of the iPhone demonstrates it: finely tuned widgets, reactive behavior, and rich graphics together make the iPhone interface superior to other products. Designing such systems is a recent activity that has rarely been supported explicitly in the past. Yet, their quality is essential for usability. Unfortunately, developing such software is not reachable by all stakeholders of interactive system design. This requires highly trained specialists, especially when it comes to using very specific graphic concepts and optimize the rendering and interactive code. Hence, there is a clear need for making interactive graphical programming more usable.

Moreover, even within a given style of computing (either web or mobile), new means of thinking, designing and developing interfaces arise every couple of years. For example, we successively saw the rise of Java2D, Adobe Flash, Adobe Flex, Microsoft dot net, XAML, SVG, WMF, Web 2.0 interfaces programmed in javascript in the browser (with the Canvas and HTML5), OpenGL etc. 1 . In order to design and develop interactive systems on those platforms, interface designers have access to a plethora of toolkits, usually incompatible with one another. This results in the failure of reusability, one of the most praised property in computing: designers have to redevelop existing software in order to port it to another platform, with the associated drawback of not reusing well crafted and tested software. For example, the menu subsystems that have reached a good level of usability in traditional desktop platforms (i.e. Windows or MacOSX) are poorly imitated in Web 2.0 interfaces, where the user is for instance required to follow a tunnel strictly when navigating in a hierarchical menu. Hence, there is a need for the ability to reuse existing software, especially if we assume that new platforms will keep appearing in the future (see WebGL for example). This paper addresses the two requirements presented above: design usability and reusability of finely-tuned interactive gra-phics. In particular, we introduce Hayaku, a toolset that targets interactive graphics that Brad Myers refers to as the "insides" of the application [START_REF] Myers | Survey on user interface programming[END_REF], and that no widget toolkit can support. After a review of related works, we present the exact audience that we target, and the requirements of such an audience. We then present the toolset using three use cases, and some of the internal mechanisms that implement its features. We finally provide a number of elements to evaluate the toolset according to our claims. Related Work This work is related to two topics in the user interaction software and technology community: methods to design interactive systems, and graphical toolkits.

Interactive System Design Methods

Chatty et al. [START_REF] Chatty | Revisiting visual interface programming: creating GUI tools for designers and programmers[END_REF] present a method and associated tools to involve graphic designers in interactive system design and development. Programmers and graphic designers first agree on a conceptual and simple SVG skeleton of the scene. While programmers code the interaction with a low quality representation, graphic designers can work on their design in parallel. Since programmers and designers respect a contract, the production of the final system consists in the replacement of the low quality representation by the designer's one. However, the tools oblige the graphic designer to use a library to transform the high-level language (SVG) to a lowerlevel one (a Tk-like canvas) with a lesser expressive power. This hinders exploration of alternative design since changing gra-phics implies many manipulations to reflect the change in the final application. Furthermore, when optimizing code, the approach falls back to a sequential process: programmers have to wait for designers' solutions before optimizing by hand the rendering code, and designers have to wait for optimizations to assess if their design is usable.

Microsoft Expression Blend makes heavy use of XAML to describe the graphical parts of the application. Like Intuikit, the aim is to separate the graphical description from the functional core of the application. The designer can produce one design per C# class that has to be drawn, but he still needs to manipulate the low level code in order to implement interactions and animations. The concept of "binding" allows programmers to link the graphical shapes and the source objects. The Adobe Flex and Flash suite also provides a means to separate the graphical description from the functional core. However, even if the designer can rely on Flash to build her graphical components, she has to develop the rest of the application using the ActionScript language. Furthermore, there is no abstraction of the graphics, nor a way to express properties with a data-flow. Finally, even if Flex runs on a variety of platforms in its own window, it is not possible to embed the graphics among the graphical scene of another application.

Toolkits

Many toolkits address the problem of performance: Prefuse [START_REF] Heer | Prefuse: a toolkit for interactive information visualization[END_REF], Jazz [START_REF] Bederson | an extensible zoomable user interface graphics toolkit in Java[END_REF], Piccolo [START_REF] Bederson | Toolkit design for interactive structured graphics[END_REF], and Infoviz Toolkit (IVTK) [START_REF] Fekete | The InfoVis Toolkit[END_REF] for instance. Performance is maximized by using specialized data structures explicitly (tables for Prefuse and IVTK), or hidden data structures (spatial tree for Piccolo). The first limitation of this approach is that the language used to describe graphics is both inappropriate and not rich enough: describing graphics in Java code with SwingStates [START_REF] Appert | SwingStates: adding state machines to Java and the Swing toolkit[END_REF] is verbose, Java concepts do not match graphics exactly, and rich graphics created with tools for graphic design cannot be directly used in the toolkit. Rich graphics toolkits exist, such as Batik2 , but they are not efficient performance-wise. Fur-Other works use compiler-like optimizations to produce efficient graphical code (Java3D, LLVM [START_REF] Lattner | LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation[END_REF] with Gallium3D3 in Mesa). However these tools are only accessible to low level graphical programmers that manage to write code for the graphic card directly. They are not supposed to be used by the average interactive application developer, with basic understanding of the factors that accelerate rendering.

The solution we propose here consists in helping the production of efficient code for heavy graphics handling. In order to compile the graphical part, we rely on a dataflow, and a mechanism that is able to track the dependencies between input data and graphical elements. Dataflow has been used in graphical interactive toolkits (Icon [START_REF] Dragicevic | Support for input adaptability in the ICON toolkit[END_REF] for the input, and Garnet [START_REF] Vander Zanden | Lessons learned about one-way, dataflow constraints in the Garnet and Amulet graphical toolkits[END_REF] for the constraints), and have been showed to help building interactive systems efficiently. However, the main difficulty with such a system is to make it fast for both graphical rendering and the dependency updating mechanism. This point is addressed in [START_REF] Tissoires | Graphic Rendering Considered as a Compilation Chain[END_REF], which introduces a compile chain for interactive graphical software. This work shows that using a graphical compiler (GrC) together with a dataflow leads to good performance. However, the tools were more a proof of concept than a real toolset: the authors present a way to implement optimizations, but do not detail how programmers of the graphical interface can connect all parts together. Another problem of the GrC is that it generates a program that is linked to the runtime of the GrC. This forces the designer to describe all graphical parts of the application with the GrC. However, when dealing with high performance applications, there are parts of the code that the programmer still wants to write manually, in order to maximize the performances. Meanwhile, this programmer may not want to write every piece of the software, if only because they already exist.

The work we present in this paper improves on the concepts described in [START_REF] Tissoires | Graphic Rendering Considered as a Compilation Chain[END_REF]. In particular, we show how our new tool can help the programmer and the graphic designer to use graphical compiling in a simpler manner, and what benefits can be gained from the new functionalities. We also improve it by allowing it to be modular and thus producing embeddable components. Finally this modularity allows us to turn this proof of concept into a real compiler that can handle multiple graphics back ends and run-time modules.

TARGET AUDIENCE AND REQUIREMENTS

The work presented here targets members of interactive system design teams. A large body of work aims at supporting interactive system design. For example, Participatory Design (PD) partly aims at facilitating production and communication between all designers, be they user-experience specialists, graphic designers, users, programmers [START_REF] Muller | Participatory design: The third space in HCI[END_REF]. PD employs multiple means to elicit design and communicate it efficiently in groups where people do not share the same culture. Use cases in the form of stories, drawings and mock-up [START_REF] Buxton | Sketching User Experiences: Getting the Design Right and the Right Design[END_REF], paper prototypes [START_REF] Snyder | Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (The Morgan Kaufmann Series in Interactive Technologies)[END_REF]: all tools aim at maximizing expression, exploration by iteration and understanding by culturally different designers. After these tools have led to initial static prototypes, the designers have to work on dynamic, graphical interactive prototypes [START_REF] Beaudouin-Lafon | Prototyping tools and techniques[END_REF] [6] (figure 1). As said in the introduction, part of the work is the design of finely-tuned interactive graphics, which consists in a mix of graphical design, animation design and interaction design. The quality of the artifacts designed during this stage in the process is essential for usability. The overall user experience of interacting depends on how well all features (be they graphical, animation, behavior) mix together: the designer must address all concerns at the same time, and dispatching the task between a graphical designer and a programmer does not work anymore. Hence, this activity requires designers with skills in graphic design, animation, interaction design and programming. Our work especially targets this kind of designers.

As demonstrated by Artistic Resizing [START_REF] Dragicevic | Artistic resizing: a technique for rich scale-sensitive vector graphics[END_REF], we think that technical support has a great influence on the experience of designers engaged in the activity. A recent survey analyzes how designers design and program interactive behaviors with current tools [START_REF] Myers | How designers design and program interactive behaviors[END_REF]. Among the findings, the designers expresses that "the behavior they wanted were quite complex and diverse [. . . ] and therefore requires full programming capabilities"; that "the design of interactive behaviors emerge through the process of exploration [. . . ] and that today's tool make it difficult to iterate on behavior or revert to old versions"; "Details are important, and you never have them all until full implementation"; "I can represent very exactly the desired appearance. However, I can only approximate the backend behaviors"; and they want to do "Complex transitions / animations."

Based on these concerns, we propose a set of requirements for our tools. Similarly to paper prototypes in PD, tools should maximize expression, exploration, and communication between designers. Maximizing expression requires rich graphics, hence a toolset should be able to handle heavy graphical scenes, with lots of subtle graphical properties. Designing such scenes requires efficient design tools, such as vector graphics editors. However, in order to be usable in interactive system, the toolset should deliver enough performance. Maximizing exploration implies a system in which changing things (e.g. a graphical property) should be as inexpensive as possible, i.e. with as little manipulation as possible required to reflect the change in the subsystems.

TOOLKIT DESIGN AND CONCEPTUAL MODEL

Designing a system that addresses all the requirements above is beyond the scope of this paper. In this work, we describe Hayaku, a tool set that partly addresses these requirements. In particular, we address richness of expression, exploration, performances, and reusability. Hayaku mainly focuses on the rendering part of the application. It also provides hooks to implement interaction with the user and communication with the rest of the application. The functional part of the application (what happens in the system when the button is pressed for instance) is out of the scope of the paper.

General Idea: the Interaction Designer is in Charge

As said before, this activity requires designers with skills in graphic design, animation, interaction design and programming. Omniscient individuals that possess all skills are rare, if existing. In order to tackle this problem, teams include specialists in each domain, and design is distributed among the members of the team. In particular, graphical designers and computer scientists (or more precisely interaction programmer) are among the kind of specialists involved in the design of interactive software. The general idea of our approach is wider than the Intuikit approach [START_REF] Chatty | Revisiting visual interface programming: creating GUI tools for designers and programmers[END_REF]: instead of acknowledging the irreconcilability between graphical designers and interaction programmer, and maximizing communication between two different specialists, we tried to make the programmer's concerns accessible to the graphical designer. More precisely, what we target is a graphic designer that has basic programming skills, and that the tool empowers. As depicted in Figure 2, Hayaku provides the required graphical expressive power, while offloading optimizations to the graphical compiler. This turns the interaction coder and the graphic designer into an interaction designer. Again, we assume that the artefacts produced at this stage in the design should be done with all concerns (graphics and code) in mind, and thus by a unique person, or a very close team that share tools and artefacts. The approach is similar to Artistic Resizing: instead of describing with code the behavior of graphical elements under size change, Artistic Resizing enables graphic designers to express the behavior with means closer to their knowledge.

We provide the interaction designer with a tool chain that uses a standard vector graphics editor (Inkscape or Adobe Illustrator) as its first link. This has two advantages: the designer leverages on her experience with such tools, and she can express graphics using the full expressive power of the tools. The other links of the toolchain consist in a compile chain that takes two inputs: graphics elements edited with the graphical editor, and abstractions of graphical element to control them. The remaining of this section enumerates the main features of Hayaku. One of the contributions of this work is the identification of those features. The goal of the paper is to present the concepts used by the tool, and show why they are adapted to the activity we target. Though there is not enough information to fully describe the system because of limited space, the concepts presented here can be used by readers if they want to design a similar system.

Abstract and Control Graphical Elements The graphic editor stores the drawings in an SVG description. SVG drawings are like "classes" of graphical objects. In order to use SVG drawings in a real application, the designer has to provide three descriptions, all written in JSON 4 . The first one is the "conceptual language" shared with the functional core coders, and serves as a bridge between the functional core and interactive graphics. As in [START_REF] Chatty | Revisiting visual interface programming: creating GUI tools for designers and programmers[END_REF], the designer and the rest of the team must agree on a common data structure, or "models" which also acts as classes of concepts. This language is illustrated by the right part of Figure 3. The second one describes how the models defined in the first description is related to SVG graphics, by connecting fields of the models to nodes and attributes in SVG drawings with a mini, dataflow-like functional language. It is similar to a stylesheet. In Figure 3, the connections are represented by the lines between the SVG part and the abstract model part. Finally, the last description is the "scene", i.e. a list of instances of the classes (not represented on Figure 3). Though this conceptual model of application design seems complex, it is no more than existing ways of writing code: the first JSON description can be considered as a class definition, the second one as a stylesheet, while the last one corresponds to the instantiation phase of classes at the launch of a program. The only addition is the SVG description, which corresponds to "graphical classes" definitions.

Fast Application Generation

Hayaku includes a compiler that takes the SVG description and the three JSON files as input, and generates an application. The compiler uses various strategies to maximize compile speed and launch speed of the generated application. This allow for rapid fixes and tests, and thus efficient exploration of design. 4

Javascript Object Notation

Fast and Portable Code Generation

As many compilers, the graphical compiler is able to optimize the generated code. Thanks to a data-flow analysis, and user-provided hooks, the code allows the use of complex graphics (expressive power) with a rendering speed compatible with interaction. Furthermore, the compiler is able to target different graphical back-ends, such as OpenGL or Cairo. This guarantees that the design is portable.

Generate Whole Application or Embeddable Code The compiler can generate either a stand-alone application, or embeddable code. With traditional toolkits, embedding is often limited to a window that the host application displays next to its own windows. The kind of embedding that we target is more useful: graphics should appear inside an existing scene of the host application. Such embeddable code allows for creation of dynamic applications, in which the number of graphical elements is not known at compile-time. This also allows designers to use the compiler as a translation tool between SVG and a run-time environment. More generally, this transforms our toolset in a toolkit for graphical toolkit design (a toolkit of toolkits).

USE CASES

In order to illustrate our approach, we describe how to use Hayaku to implement three different kinds of applications. Though the descriptions look like a tutorial, they enable to understand and assess how a designer is supposed to use the features provided by the tool, and help evaluate how efficient the features are at supporting the designer's activity. The first one is a basic multi-touch application that enables multiple users to move and resize simple graphical objects. It is not very rich in terms of graphics, but since it is simple, it allows for a gentle introduction and short code examples. The second one is a more graphically complex application: a resizeable keyboard with a fish-eye effect that is activated only if the size of the keyboard is too small. The last example is a generic pie-menu that can be reused in an existing application.

Writing a Simple Application

This test-case consists in writing a simple multi-touch application (Figure 4). The interaction consists in controlling in a simple and natural way each of the "heads" that appears on Figure 4. The properties that users of the application can control are the position, size and rotation of each shape.

For the designer, the first phase consists in defining four graphical "classes" (here the "head"-shapes) with Inkscape, and save them in a SVG file.

{ "model": "SMILEYS", "classes": [ { "name":"Object", "extends":null, "attributes": { "ID":"key", "X0":"vint", "Y0":"vint", "SCALE":"vfloat", "ROTATION":"vfloat", "PRIORITY":"vfloat", "Picked_Key":"vint" }}, { "name":"Object_0", "extends":"Object", "attributes": {}}]} Figure 6. Connection between the model of the multi-touch widget and the graphic parts (smiley svg).

{ "name":"Smileys", "model":"SMILEYS", "content": [ { "type":"Object_0", "attributes": { "ID":0, "ParentID":0, "X0":100, "Y0":100, "SCALE":0.5, "ROTATION":0.0, "Picked_Key":-1 }}] } The third phase consists in defining the connections between the model and the graphical part (Figure 6), again in a JSON file. Connections are straightforward and need no explanation. The fourth description pertains to the scene, in another JSON file. This file consists in instantiating the different elements of the graphical scene (Figure 7).

The designer has to provide the reactive part of the application, i.e. the connection between input events and reaction of the graphical objects. Since Hayaku focuses on the rendering part only, it does not provide any multi-touch capabilities. Rather, it is up to the designer to describe with the run-time language and input toolkit how events act on the conceptual model, by updating the corresponding fields of the instances. However, when generating the code corresponding to the conceptual model, the toolset offers the possibility to concatenate user-defined code. This enables the designer to abstract behavior (see Figure 8). Furthemore, Hayaku provides a picking mechanism that can be called from user-defined code.

In order to test and launch the application, the interaction designer edits a Python script that contains a call to the function load with the three JSON files as arguments (the model, the model-to-svg connection, and the scene). She then launches the command hayaku with the script as a parameter. If the compile phase succeeds, Hayaku launches the generated application.

The compilation time for this example is 2.2 seconds the first time. Further recompilations requires 1.9 secs only. The first time of compilation is longer due to some tools that need to be embedded in the final application and that does not need to be recompiled each time a change occurs (OpenGL shaders and utility functions). The application takes less than one second to launch, and runs at 515 frames per second (see Table 2). Again, this application is simple and not demanding in terms of computation power. Still, it shows that the toolkit is reactive enough to deal with high-rate incoming data.

A Fish-eye Keyboard

The second application is a 40 auto-expanding keys keyboard, designed for motor-disabled users (Figure 9) [START_REF] Raynal | Fisheye keyboard: Whole keyboard displayed on small device[END_REF]. The keyboard consists in two parts: the keyboard itself, and a one line screen to display the result. The caps-lock key is fully functional: the key mapping changes accordingly. The key "123" toggles the numeric mode. Finally, the keyboard can be resized, and at low sizes the keys close to the cursor expand thanks to a fish-eye effect [START_REF] Furnas | Generalized fisheye views[END_REF]. This example demonstrates the ability of the toolkit to handle rich graphics with high rendering performance. The design of the keyboard uses a full vectorial description for its components. This leads to high quality graphics even when the keyboard is resized. The design also uses rich graphic properties: gradients, transparency, shadows. . .

Realisation

The graphical part of the application has been realised with Inkscape (Figure 10). In a first SVG file, the designer creates a key by using eight separate graphical layers. The layers are grouped and named in a unique SVG component. In order to build the global composition, the keys are then cloned, organized and modified to generate an artwork of the final keyboard. The creation of the upper area, including the text display, the backspace key and a background with a gradient completes this artwork. The whole keyboard contains 400 graphical elements. Once the global composition is satisfactory, three examples of the different type of keys are put in a separate SVG file, to serve as "graphical classes" : char key, func key and enter key. The graphical components correspond to the component described in the model, and are named accordingly.

The blocks that describe the background and the display of the result are also added to this file. A parent class Key has been defined to handle the common properties of the different keys. The class is inherited by the different types of key (char, func and enter).

The layout of the keyboard is given in the JSON scene file. However, Hayaku does not provide a visual editor for the scene. Thus, the designer has to provide it. Since the production of this file can be laborious, a script has been written to produce it. This script allows the interaction designer to rapidly change the layout of the keyboard by changing some variables in the script, instead of a bunch of values and parenthesis into the JSON file.

The fish-eye effect is implemented by computing the distance between the cursor and each key, and by using this distance to set the scaling property of the key accordingly. Each time the cursor moves, a redraw is triggered, and the key is scaled with is current scale before being drawn.

A Generic Pie-menu

To assess that Hayaku can be considered as a toolkit of toolkits 5 , we implemented a generic pie-menu (Figure 11). The objective was to provide an implementation-independent description in order to use it inside an actual, existing application (Figure 12). The pie-menu we designed includes a feedback when flying over a slice: the underlying slice is enlarged. Thus we can not use a mere circle, but several distinct slices. We also need to be able to control the number of elements inside the menu. 5 here, Hayaku can be considered as a toolkit for building a widget

Realisation

The design in itself resembles the design of the keyboard: we designed the pie-menu to be a set of slices. Each slice has 7 main graphical parameters: a position, a label, an angle, an internal radius, an external radius, a rotation, and a color parameter. To describe the scene, we wrote a script similar to the one that generated the keys in the keyboard. The script generates the slices and their parameters according to the number of slices.

The behaviour part maps the picking value of each slice with a callback that changes the internal radius, the external radius and the color as needed. High-level events, such as "menu 7 has been selected", have to be generated by the behaviour part, since Hayaku only provides the graphical part of the application.

Embedding in an Existing Application

We have embedded the pie-menu into an existing radar-like application for Air Traffic Control (see Figure 12). This application is written in C++ and makes extensive use of OpenGL. The application is extensible, and provides a mechanism for loading dynamic external libraries. We used this mechanism to plug our pie-menu into this system. The steps involved were the following. First, we had to write a C++ class that interacts with the dynamically loaded objects generated by Hayaku. This class is the glue that links the host application and the generated interactive graphics, and factorizes the setup code for all embedded Hayaku code.

Then we wrote a subclass specific to the pie-menu, to handle the pie-menu behaviour with respect to user interaction. This subclass represents 112 lines of code. It is a transcription in C++ of previously written Python code, developed during the prototyping phase of the pie-menu widget. As

Figure 12 shows, the pie-menu smoothly integrates into the host application, and does not reduce the frame rate.

This use case shows that it was possible to externalize the creation of widgets and reuse them in other applications. However, in general, existing systems do not support extensions with external dynamic plug-in: in this case, the code generated by Hayaku must be embedded at source-level. The glue between the original code and the graphical part is simpler (just a "#include" at the beginning). Drawing is initiated by calling the exported draw function.

TOOLKIT IMPLEMENTATION

How the Toolset Works

The command hayaku automatically calls the GrC. The GrC then creates a directory named BUILD in which it places all its productions. The JSON files are transformed into Python ones, and a set of C files and their headers are written. Then, the GrC calls gcc to compile those C files and produce the object files that can be embedded into C applications. It generates a dynamic library that can be either linked to the runtime of the GrC, or embedded into an existing application.

To reduce compile time, the compiler is able to detect parts that have been modified between two successive compilations, and compiles those parts only. In addition, we designed a monitoring system on the files, and the recompilation occurs automatically whenever a file is modified and saved. The change is automatically reflected in the generated application while it is still running. For example, changing the color of one of the shapes in the example above with Inkscape, and saving the SVG file automatically updates all shapes of this class in the running application. This illustrates the advantage of separating graphics from behavior and using data-flow mechanisms: since the graphical pipeline is clearly delimited, the toolset is able to trigger it at any time, without affecting the behavior of the whole application. Such tools reduce the time needed between envisioning an idea and testing it.

Generation of Portable Code

As we already said in the previous sections, the designer produces the graphical shapes thanks to SVG files. The abstractions and connections between those graphical shapes and the models are given through JSON files. Then, Hayaku loads them into the GrC.

The GrC in itself is written in Python. The GrC is able to produce different types of outputs, in terms of target language and run-time (currently C and Java), and in term of graphical backend (currently OpenGL, and partly Cairo). To be able to reuse the code of the transformations, we implemented our own partial class mechanism. We separate the description of the intermediate languages and the transformation between them. At the beginning of the compile chain, the GrC chooses which languages and transformations it needs to produce the final code by attaching the transformation functions to the descriptions nodes. The trees that are generated can then be transformed just by visiting each node. This mechanism allows us to modularize the graphi-cal compiler and thus to plug different behaviour at different stages as needed.

Generation of Static and Semi-static Code

Most examples are instances of application in which the number of objects is not variable (sliders, pie-menus, keyboard).

For other types of applications, such as radar image where the number of flights is in theory not bounded, the data-flow architecture does not allow for simple description and handling of dynamic creation of objects. In this case, Hayaku provides two strategies.

The first one is to consider the number of elements to be displayed bound by an upper limit [START_REF] Tissoires | Graphic Rendering Considered as a Compilation Chain[END_REF]. This requires to start the application with a pool of available invisible graphical objects, which are allocated to any new data that appear during run-time. In practice, this strategy works well: for example, the number of flights in a sector is bounded by regulation agencies in order to enable a limited numbers of controllers to handle the traffic. It comes at the expense of internal handling of invisible objects (which may hinder performance uselessly) and longer compile time. But the benefits outweigh the drawbacks, since it helps keeping the application simple to write and understand.

The second strategy consists in generating pieces of specific interactive graphical code that can be reused in a larger program. In the radar image, this would consist in designing the graphics for a single flight, and generating the corresponding display code. The main program would then manage creation of new flights and deletion of disappearing ones, and use the display code whenever necessary. With this solution, the compile time is reduced, since the graphical code is not unrolled as in loop unrolling for instance, and the constraint of the upper limit of objects is removed.

Generated code must follow a number of requirements to make it embeddable. First, the generated code has to keep the state of the application. For instance, when working with OpenGL applications, the drawing code has to keep the pipeline in the same state it was before its use. A second requirement is to produce "human readable" code. Since most of the time a designer will connect the generated code to the other application, the names of the functions that are exported have to be understandable by the programmer. For instance, set0 25 2 1 is less readable than set component0 -key25 backgroundColor red.

Picking Support

The generated code must provide a way to send back information. For instance, when the end-user moves the mouse, the code has to inform the caller that the picking state changed. Hayaku provides a picking mechanism, together with a callback system. The host application has to register callbacks if it wants to be notified by the graphics code, or by the underlying dataflow. Care must be taken when handling picking. For example, a usual picking algorithm consists in rendering the scene in a tiny rectangle around the cursor, and storing each graphical object that owns pixels actually rendered in the rectangle. Applying the same algorithm in a multitouch application requires as many passes as the number of touches, which is costly. Instead, we used a onepass color-keying algorithm [START_REF] Hanrahan | Direct WYSIWYG painting and texturing on 3D shapes[END_REF]. Each graphical shape is assigned a unique color in an associative array, and rendered with their unique solid color in an off-screen buffer. Picking shapes consists in reading back the color of the pixel under each touch, and retrieving the corresponding shape from the color with the associative array.

PRELIMINARY EVALUATION

As with any method that aims at supporting design, evaluating a toolset requires controlled experiments, with multiple design teams under different conditions (with or without the tested toolset for example). Such an experimentation is a heavy task, and is beyond the scope of this paper. However, we provide in this section a preliminary evaluation in terms of descriptive power, performance, and usability.

Descriptive Power

We provide two dimensions of analysis to evaluate the descriptive power of the toolkit: the size of the class of visualizations that can be described by the toolkit in a reasonable amount of work, and the simplicity of the description of typical applications. A toolset must target the right balance between the class size and simplicity. A thin class may indicate that the toolset is so specialized that the benefits provided are not very significant. On the other hand, expanding the class usually comes at the expense of simplicity.

Class of Application: previous work showed that the GrC is able to handle basic WIMP interaction (sliders) and graphical scene with a large number of objects, such as a radar image. We showed with the use-cases of this paper that Hayaku can implement multiple types of interactive graphical software: interactors (pie-menus), graphically rich interactive software (fish-eye keyboard), and multitouch applications.

As said before, most examples are instances of application in which the number of objects is not variable (sliders, piemenus, keyboard). For other types of applications, such as radar image where the number of flights is in practice bounded, a strategy consists in picking objects in a pool of available invisble objects. Hayaku enables to use a second strategy that relies on embeddable, generated code, thus expanding the class of applications.

Using a graphical editor also enables the designer to expand the class of representation he can employ. However, we did not try to design very dynamic applications such as graphical editors with Hayaku because we think that Hayaku is not made for that kind of applications. We suspect that writing such systems would require to twist the conceptual model of application design so much, that it would be too cumbersome to do.

Simplicity: Despite our research in the literature, we could not find a clear definition for simplicity. Thus, we measured it in terms of compactness of the code required to describe interactive graphics, by providing the number of lines of code (LOC) of previously described examples. (Table 1). As said before, the JSON description of the scene (the graphical components of the interface) has been judged as "laborious", and a Python script to produce it has been required. It corresponds to the "generator" column. For example, the 890 LOC for the keyboard have actually been generated by the 210 lines of code generator. As we can see, the amount of code is in the hundreds, which is low considering the richness and variability of the three examples.

Performance

In Table 2, we show the performances of the three use-cases, compiled with Hayaku, and rendered through OpenGL. For each example, we show the frame rate of the produced code (C+OpenGL), and the time needed to compile it. We differentiate "first compile-time" from "re-compile time", because Hayaku caches some computation between two consecutive compile phases (text fonts for example). The most significant time is the re-compile time, since a designer using Hayaku will spend most of her time doing small increments to her description, and will launch recompilation from time to time. If performances may not be as good as expected, they could be much higher (8.6 sec re-compile time for the keyboard).

The implementation of the toolkit we show here is a prototype (written in the Python language), and could be improved in many ways. For instance, the produced OpenGL code does not use Vertex Buffer Objects, which could significantly improve the run-time performances. In addition, the internal data structures of Hayaku and the GrC (graphs of tiny Python objects) should be changed to decrease compile time.

Usability

Evaluating the usability of a toolkit is an open research problem [START_REF] Myers | Usability issues in programming languages[END_REF]. For this purpose, we discuss how Hayaku ranks against Cognitive Dimensions of Notation [START_REF] Green | Cognitive dimensions of notations[END_REF], which help make explicit what a notation (i.e a language) is supposed to improve, or fails to support. Cognitive dimensions are based on activities typical of the use of interactive systems. We chose to evaluate the following activities: incrementation, transcription, modification, and exploratory design; along the following dimensions: closeness of mapping, hidden dependencies, premature commitment, progressive evaluation, abstraction, viscosity, and visibility.

Closeness of Mapping: the designer creates (incrementation) drawings directly into a graphical editor: it is very close to the final product, at least closer than textual graphical language. This allows the use of existing exploratory design tools (inkscape), and thus maximizes this property. Modification of the graphics is eased since it modifies in turn an SVG file that keeps the same properties (e.g. naming), which in turn is compiled i.e. transformed computationally.

Porting can be considered as a transcription, and is efficient thanks to the use of a compiler with multiple front-ends and back-ends. The front end of the compiler is the conceptual model JSON file. Since the interaction designer designs the conceptual model, she can make it as close as possible to the domain she models. Hence, closeness of mapping is maximized. However, setting the link between the graphics, the conceptual models, and the data-flow language requires a switch of notation (a graphical editor vs a textual notation).

Hidden Dependencies: the dataflow we provide is not entirely visible. It is difficult for the designer to know exactly what happens once the models and transformations are given. However, the designer is mostly interested in the part of the data-flow he wrote. The part of the data-flow generated by the compiler is less susceptible to be read and understood, except for debugging purpose. Premature Commitment: using a graphical compiler inherently prevents premature commitment. For example, changing the run-time environment can occur at any time during the design process. Furthermore, changing a property of the graphics may require a simple recompile to be reflected in the application. Moreover, as Hayaku relies on style-sheets to link the graphical model to the graphical shapes, the design can be rewritten several times without having to rewrite the behaviour part. However, the structure of the graphics must not change too often, since other descriptions rely on it (see viscosity). Progressive Evaluation: evaluating a recently modified graphics is immediate. However, evaluating the behavior with respect to the interaction requires to launch the software. Clearly, a tool such as artistic resizing is needed for this kind of activity and concerns.

Abstraction: Hayaku relies on JSON files to abstract the graphical model, the connections and the graphical scene. However, if this language is well adapted to represent abstract data, and forces the user to keep it abstract, it is not very well adapted to the human that needs to write it into his/her text editor. In particular, the connection between the models and the graphics would be better defined directly in a graphical editor.

Viscosity: the conceptual model requires all graphical elements to be declared in the JSON file. Hence, if a graphical element is used multiple times (such as the key element in the keyboard example), a change in the "prototype" requires propagating the change in all instances of that element. A solution to this viscosity problem is to design a small program that generates all instances from a prototype in a JSON file. This program can be considered as another link in the compile chain, and helps abstract concepts from the conceptual model of the application to be designed.

A change in the conceptual model itself must be reflected into the connection description, and the scene description. This is the problem that the programmer of a C++ class encounters when he adds a field for example: he has to update all calls of the class constructor if a parameter to set up the field is required. Various mechanisms exist to cope with this problem (e.g. a default value), but none is implemented in Hayaku. Similarly, a change in the graphical structure (i.e. the hierarchy of SVG elements) can have a large impact on the model-graphics connection description.

Visibility: currently, the visibility of the toolkit is limited. For example, JSON files tend to be verbose and long, which hinders searching or exploratory understanding.

EARLY FEEDBACK FROM DESIGNERS

We provided Hayaku to the graphical designer of the original Fish-Eye Keyboard, and we asked him to recreate it. This designer is used to both design graphics and write interaction code. The designer praised the reliability of the rendered scene. Since Hayaku relies on a graphical compiler, the final generated code does not suffer from a trade-off between speed and power of expression. The final rendered scene is then very close to a static one, produced by Inkscape for instance. Thanks to the expression power of SVG, the graphic designer is not limited when dealing with graphics.

The designer found that one of the most interesting thing was to design the graphical objects by keeping in mind their graphical behaviour during the interaction. This behaviour has been defined by targeting the graphical properties that need to be connected to the models in the graphical scene. The evolution of the parameters are then described, either "relatively" with a mathematical expression (similar to the one-way constraints in Garnet [START_REF] Vander Zanden | Lessons learned about one-way, dataflow constraints in the Garnet and Amulet graphical toolkits[END_REF]), or with a value computed by the behaviour part. For example, the anchor of the shape of a key depends on its width ("FORM X0": "(self. WIDTH -100) / -2"): since the width depends on the distance with the cursor, the anchor is updated automatically. Considering all the inputs and outputs of the generated application as a data flow simplified the work of the designer. For instance, implementing the global resize of the keyboard took around 10 minutes, the time needed to understand and implement the solution to connect the two variables screen width and screen height to the application. The "connections" allow the graphic designer to quickly build complex behaviour, such as the "fish-eye" function of the keys.

However, there still are some pitfalls. The main problem was the hand writing of the different JSON files. This has been judged as laborious, since the coherence between those files had to be maintained manually. Furthermore, writing a JSON file for the scene is also annoying, since a scene can contain many similar elements. As explained, a solution to this problem is to write a script that generates the scene, which makes it more controllable.

CONCLUSION

In this paper, we have identified that there is a lack of tools to support designers in producing graphically rich, finely tuned and highly reactive graphical applications. We have presented Hayaku, a toolset that aims at supporting this activity, by turning the interaction coder and graphical designer into an interaction designer. The interaction designer writes the program in a high-level, known language (SVG) and through JSON files that abstract the graphical elements. He then compiles it into an runnable application or embeddable code.

Like the keyboard example shows, the compile time hinders design exploration, and must be improved. We have developed Hayaku in Python in order to prototype it rapidly, and we are aware that parts of the code are sub-optimal (notably trees traversal). Many optimizations can be done to improve that part of the toolset. Future works also include expanding the sets of back ends, both for graphics platform and languages. Finally, using multiple JSON files as a description language is cumbersome, especially when describing the connection between models and graphic models. Specialized tools must be designed, such as a graphical editor.

Figure 1 .

 1 Figure 1. Targeted activity

Figure 2 .

 2 Figure 2. Role repartition with Intuikit and XAML (a) and role repartition with Hayaku (b).

Figure 3 .

 3 Figure 3. Representation of the connections (the black lines) between the graphical classes (the SVG) and the model.

Figure 4 .

 4 Figure 4. A simple multi-touch application.

Figure 5 .

 5 Figure 5. Model of the multi-touch widget.

Figure 7 .Figure 8 .

 78 Figure 7. Instantiation of the multi-touch widget. def translate(self,dx,dy): self.x0.set(self.x0.eval() + dx) self.y0.set(self.y0.eval() + dy) def rotate(self, dr): self.rotation.set(self.rotation.eval() + dr) def zoom(self, z): if self.scale.eval() + z >= 0.1: self.scale.set(self.scale.eval() + z) Figure 8. The Python code of the three commands to control the graphical objects.

Figure 9 .

 9 Figure 9. The test application in action.

Figure 10 .

 10 Figure 10. The SVG description of the different components of the keyboard, realized with Inkscape.

Figure 11 .

 11 Figure 11. The pie-menu in action.

Figure 12 .

 12 Figure 12. The pie-menu inside a real application.

Table 1 .

 1 The number of lines of code (LOC) of the different examples.

	use case	conceptual model to model SVG	scene	generator of the scene
	multi-touch	43 LOC	90 LOC	54 LOC	∅
	keyboard	129 LOC	199 LOC	890 LOC	210 LOC
	pie-menu	40 LOC	42 LOC	102 LOC	46 LOC

Table 2 .

 2 The performances of the different examples.

. . . , Cairo, Qt, Prefuse, Protovis, iPhone SDK, Open Handset Alliance's Android, Palm WebOS to name a few more

http://xmlgraphics.apache.org/batik/ thermore, the problem with these toolkits is that even if they are efficient, they force the toolkit user to work with a specific language and a specific run-time. For instance, users of toolkits can not use Prefuse to write a C or C++ application.

http://wiki.freedesktop.org/wiki/Software/gallium