Récupération des logs

A.1.1 L'instrumentation

Pour voir ce qui se passe au sein d'une application, traditionnellement, on doit  instrumenter  le code c'est-à-dire insérer des lignes dans le code source pour suivre son exécution, ou pour écrire ces données dans un chier de logs. Instrumenter le code est en théorie un bon moyen d'obtenir des informations précises : il est facile de spécier quelles informations écrire dans les logs, en choisissant leurs formats et leurs emplacements. Cela peut constituer la base pour diverses formes d'évalua-tion ou de debugging, et pas seulement pour les tests d'utilisabilité. La diculté de l'instrumentation est dans le fait de placer la bonne ligne de code au bon endroit.

Cela implique d'avoir une connaissance détaillée de la structure de l'application et de l'information à enregistrer, un savoir dont ne dispose pas forcément l'ergonome. Celui-ci opère souvent en tant que conseiller durant la conception et le développe-ment, et non en tant que programmeur durant l'implémentation. Par conséquent, l'insertion de ces lignes se fait par l'intermédiaire d'un développeur, dirigé par l'ex-pert, laissant ainsi la porte ouverte aux malentendus et erreurs de programmation. L'instrumentation entraîne aussi la nécessité d'avoir à disposition le code source ou un développeur impliqué dans le projet, ce qui n'est pas toujours le cas. Le plus souvent, les développeurs sont réticents à l'annotation de leur code pour des tests d'utilisabilité, qui n'aectent pas directement leur travail, contrairement au debug-ging des fonctionnalités de l'application. Le temps passé à instrumenter le code, ainsi que le risque accru d'ajouter des erreurs, expliquent pourquoi cela est rare-ment réalisé dans le cadre d'étude d'utilisabilité. Une autre limite à cette méthode est qu'elle n'est valide que pour un seul programme. Autrement dit, le même pro-cédé d'insertion de lignes, incluant le même lot de problèmes, doit être répété pour chaque application que l'on veut évaluer ou déboguer. D'autres moyens plus perti-nent existent pour l'enregistrement d'évènements, exploitant des points d'entrée des librairies graphiques. Nous en présentons deux dans la suite.

A.1.2 Windows Event Logging API

Si on se limite aux tests de programmes tournant sous une plate-forme Windows, on peut obtenir quelques informations sur les évènements d'une interface, comme les saisies clavier et les clics de souris, par le biais d'une API fournie par Windows. De cette manière on peut intercepter des évènements envoyés au système d'exploitation, venant des périphériques d'entrée/sortie : claviers, souris, imprimantes. De ce fait, il est possible d'obtenir la touche du clavier qui a été pressée et ainsi enregistrer ce qu'écrit l'utilisateur. On peut aussi intercepter des informations concernant les clics venant de la souris et sa position à l'écran, en plus du titre de la fenêtre active (i.e. qui possède le focus). Dans certains cas, il est également possible d'obtenir le label de boutons, suite au clic d'un utilisateur mais uniquement sur des fenêtres dépendantes de Windows, comme les fenêtres d'ouverture de chier ou de Préférences. Ces données relèvent donc principalement d'évènements de bas niveau, comme les saisies clavier ou clics de souris, mélangées à quelques évènements de haut niveau, comme le nom de la fenêtre active. Entre les deux, il y a un trou, ne donnant pas à l'évaluateur un suivi précis de la session de test. Pour savoir ce qu'est réellement en train de faire l'utilisateur, nous devons chercher des informations qui ne peuvent être obtenues par l'intermédiaire de la bibliothèque Windows Event Logging, puisqu'elle ne fournit aucune données sur l'interaction réelle au sein du programme.

A.1.3 JAVA Accessibility API

Si l'on se limite aux applications JAVA, il existe un moyen d'obtenir tous les évènements d'une interface graphique sans instrumenter le code. La solution est donnée par l'utilisation de JAVA Accessibility API qui est traditionnellement utili-sée pour adapter l'interface aux personnes ayant divers handicaps. Les technologies d'accessibilité orent une variante de l'interface graphique pour aider ces personnes à interagir avec le logiciel. Des exemples de ces applications sont les lecteurs d'écrans, programmes lisant à haute voix ce qui est montré à l'écran ou la loupe, qui agrandit la zone où se situe le pointeur de souris. Des applications comme celles-ci doivent posséder des informations précises sur l'interface pour connaître ce qu'elles ont à présenter dans leur interface modiée. La possibilité d'utiliser les technologies d'ac-cessibilité existe dans la JVM (Java Virtual Machine) depuis la version 1.2. Cela limite donc l'enregistrement des évènements sur les interfaces Java développées de-puis cette version. Un réel avantage est que Java est indépendant de la plate-forme donc l'enregistrement des évènements fonctionne sur tous les systèmes.

Tous les évènements générés se retrouvent dans une le d'attente de la JVM en attendant d'être traités, cette le étant contrôlée par le programme d'accessibilité. Pour y avoir accès, l'application d'accessibilité doit tourner sur la même JVM que le programme principal. Dans ce but, il faut ajouter les classes de Java Accessibility dans le JRE puisqu'elles n'y sont pas par défaut. Elles sont téléchargeables sur le site de Sun sous la forme d'un jar, nommé jaccess.jar que l'on placera dans le répertoire  jre<n° de version>/lib/ . De plus, il faut placer dans le répertoire  ext  situé au même endroit, un chier nommé  accessibility.properties  contenant la ligne suivante :

assistive_technologies = Nom de la classe de l'enregistreur d'évènements. A la suite de cela, toutes les applications Java ayant une interface graphique AWT/Swing et tournant sur cette JVM seront  écoutées  et éventuellement adap-tées par le programme.

La le est remplie par les évènements venant des packages AWT et Swing de Java. Par exemple, un clic sur un bouton engendre un ActionEvent et l'ouverture d'un menu insère un MenuEvent dans la le des évènements. En tout, il y a 28 types d'évènements pouvant être présents dans la le, orant ainsi une riche source d'in-formation utilisable pour l'analyse. Ces évènements peuvent servir dans un contrôle temps réel ou être sauvegardé sous forme de chier de logs.

L'énorme quantité d'évènements générés et récupérés dans la le pose une pre-mière diculté de traitement. Tous ne sont pas pertinents pour l'étude d'utilisabilité. Seuls certains fournissent des indications sur ce que fait l'utilisateur. Les autres ne ré-vèlent rien, ou dans la plupart des cas, sont redondants. Nous pouvons, par exemple,

mettre de côté tout évènement relatant la perte du focus par un composant, cette information pouvant être induite par le fait que d'autres l'obtiennent. Chaque action de l'utilisateur peut produire un à plus d'une douzaine d'évènements. Le dé se situe donc dans l'élaboration de ltres permettant l'enregistrement des seuls évènements utiles à une étude d'utilisabilité. Dénir des ltres généraux, applicables sur plu-sieurs interfaces, est délicat. En eet, un évènement peut paraître sans importance pour une application tandis qu'il donne une indication précieuse pour une autre. Les évènements relatifs à la souris, par exemple, ne sont pas forcément utiles pour une application du type Éditeur de texte. En revanche, ils se relèvent indispensables si le programme est une application de cartographie routière (utilisation de la fonction de déplacement sur la carte, etc.).

Pour résumer, il n'est pas nécessaire que le programme testé soit spécialement conçu, pour utiliser cette technique d'enregistrement des évènements. Mais le pro-gramme d'enregistrement, lui, doit être adapté au type d'interface à étudier.

Il faut ajouter qu'utiliser les évènements d'une interface graphique pour des tests d'utilisabilité suppose qu'une bonne conduite de programmation ait été faite en amont, c'est-à-dire que les objets soient tous nommés et que les informations soient préalablement initialisées. Autrement il sera dicile d'extraire des informa-tions utiles des chiers de logs.