Mesures de l'utilisabilité du logiciel de transcription automatique nat braille v. 2.0 - entre ergonomie logicielle et design d'interaction homme-machine

3. DISCUSSION

3.1. Données

L'expérience menée consistait à recueillir, de façon qualitative, les avis de sujets non-spécialistes sur l'utilisabilité de l'application NAT Braille 2.0, dans l'optique de son amélioration, mais aussi à mesurer, quantitativement, leurs performances pour étayer l'hypothèse selon laquelle l'interface corrigée avec leur aide est, sinon plus efficace, au moins plus efficiente et plus satisfaisante que la version native. Contrairement aux méthodes décrites dans la littérature, qui mesurent indirectement l'apprentissage au cours de plusieurs itérations successives de tests, corrections et implémentations, nous avons choisi ici de varier l'ordre de présentation des interfaces afin de contrebalancer son impact sur l'utilisation du logiciel.

L'analyse statistique des résultats obtenus montre un effet presque toujours significatif de l'interface corrigée sur l'amélioration des scores des participants ; cet effet reste encore tendanciel sur la diminution du nombre d'erreurs commises. La manière dont ont été comptabilisés les clics pointeurs, puis les étapes, les fausses manipulations et enfin les erreurs, variables dépendantes en quelque sorte imbriquées, permet de dégager une interprétation commune pour ces données : ce serait la multiplication des opérations qui conduirait l'utilisateur à perdre le fil de la tâche en cours, et à procéder par « essais-erreurs » dans la poursuite de son but. Ce type d'interaction avec le système pourrait provenir d'un manque de clarté, et surtout de linéarité, dans la présentation des différentes actions proposées par le logiciel pour la réalisation de la tâche. Les résultats quantitatifs suggèrent que le déroulement de la tâche a entraîné moins d'opérations et s'est fait de façon plus intuitive et plus efficiente à l'aide de l'interface corrigée. En dernier ressort, il apparaît que ce sont les temps globaux de passation qui ont été significativement améliorés.

Par ailleurs, on observe que les sujets se rapprochent du nombre optimal moyen d'opérations à l'aide du pointeur (environ 9) lors de l'utilisation de l'interface corrigée après présentation de l'interface native. Pourtant, cet effet est absent lorsque le sens de présentation change. De même, l'effet de l'interface sur d'autres variables est différent selon l'ordre de passation : présentée après l'interface native, l'interface corrigée permet de diminuer le nombre d'étapes effectuées (voisin du score optimal moyen qui est de 4,5 environ) et de fausses manipulations. En revanche, dans l'ordre inverse, l'utilisateur semble retomber dans les « pièges exploratoires » de l'interface originale, même après apprentissage du fonctionnement général du logiciel avec l'interface corrigée, et n'améliore plus son score ; on note par ailleurs que, s'il effectue un peu moins d'étapes et de fausses manipulations, celles-ci conduisent plus souvent à des erreurs que sur l'interface corrigée. Ce

- 27 -

« lissage » des scores observés lorsque l'interface corrigée est présentée en premier suggère que, indépendamment d'un effet d'apprentissage certain entre les deux tests, l'interface corrigée pourrait permettre de mieux percevoir le fonctionnement du logiciel, et donc d'orienter les scores vers ceux optimaux, même lors de l'utilisation de l'interface native.

Ces effets successifs sont probablement à mettre en lien avec l'évolution des remarques, à caractère négatif ou positif, verbalisées lors de la réalisation des tâches. Cette évolution tend à montrer que, si les sujets sont toujours plus enthousiastes à la découverte de l'application qu'au cours de sa seconde utilisation, ils semblent aussi avoir tendance à exprimer plus facilement les difficultés (déjà rencontrées ou non) sur lesquelles ils achoppent¹⁴. En seconde présentation, l'interface corrigée recueille ainsi moins de remarques négatives, et plus de remarques positives, que l'interface native. En revanche, on comptabilise moins de remarques positives pour cette interface en première utilisation ; nous n'avons pas effectué de tests de corrélation entre ces types de données, mais nous pouvons émettre l'hypothèse que, globalement, l'utilisateur « compense » ses remarques négatives avec d'autres plus positives ; et que dans le cas où la réalisation de la tâche ne soulève pas trop de difficultés, les commentaires (en « bien » ou en « mal ») se font plus rares.

Les commentaires relevés appuient finalement l'idée qu'une application peut être tout à fait efficace mais pour autant « mal aimée » si cette efficacité n'est pas adossée à d'autres critères, en particulier ergonomiques. Nous donnons en annexe E un aperçu d'une retranscription de la première rencontre d'un professeur d'intégration avec NAT (interface native). On remarque que l'utilisateur se rend souvent responsable de l'échec - mais aussi de la réussite - de la transcription, et blâme - ou félicite - rarement l'application elle-même.

Les figures en annexe F soulignent la complexité des chemins logiques (ou « attentionnels ») empruntés par l'utilisateur pour mener à bien les tâches proposées sur l'interface originale par rapport à ceux suivis sur l'interface corrigée. En particulier, la disposition des éléments de menus dans l'interface native n'incite pas l'utilisateur à vérifier ou modifier sa configuration avant de lancer le processus de transcription. De même, le participant ne fait pas le lien entre les messages de fin de traitement et l'utilisation de l'éditeur intégré, reporté en début de fenêtre et qui constitue pourtant la suite logique de la tâche de transcription. On comprend alors que les précisions demandées par NaT (sous formes de fenêtres supplémentaires) pour la transcription de texte en abrégé perturbent d'autant plus ce cheminement non-linéaire.

14 Tandis qu'on compte souvent moins d'une verbalisation à caractère « positif » par passation, celles « négatives » oscillent entre une et six.

- 28 -

3.2. Inspection analytique

Nous nous sommes appuyés, en parallèle de la première série de tests utilisateurs, sur le guide d'utilisabilité et le modèle d'inspection analytique (IA) proposés par Bastien et Scapin en 1996 pour tenter de dégager les problématiques inhérentes à l'interface étudiée (les résultats de cette inspection sont rapidement exposés en annexe G ; les vrais et faux, positifs et négatifs, ainsi que les « véritables ratés », y sont précisés). Nous avons retrouvé - par comparaison des résultats obtenus avec les remarques émises par les participants - les critiques développées dans la littérature vis-à-vis de ce type d'analyse : une précision accrue concernant les défauts de guidage et d'utilisabilité générale de l'application, tandis que des difficultés, parfois importantes, qui apparaissent à des étapes précises ne sont pas relevées. Il est fort possible que ce décalage entre les recommandations issues de l'évaluation experte et celles émises par les sujets proviennent de la tâche : tandis que le participant est placé dans une situation d'utilisation effective du logiciel, l'évaluateur, adossé au guide d'utilisabilité, s'attarde sur des problématiques de surface (ordre de présentation, complexité des réponses du système, utilité ou aspect de certains boutons d'interface). Il aurait donc peut-être fallu réaliser cette inspection dans le même cadre et avec le même objectif que les utilisateurs, ce qui aurait sûrement permis de relever plus de défauts présents « en profondeur » dans l'application.

Rappelons que les participants n'étaient soumis à aucun impératif d'efficacité ou de temps, hormis leurs propres contraintes écologiques, lors des différentes passations : celles-ci prenaient place sur leur lieu professionnel, en des moments libres de leur emploi du temps, et les tâches proposées étaient en relation plus ou moins directe avec des aspects de leur travail. Nous avons estimé que le but principal était, du point de vue de l'utilisateur potentiel, de parvenir à réaliser la tâche, voire de pouvoir participer activement, volontairement, à un projet dont il pense qu'il peut impacter son quotidien. Finalement, nous estimons que le participant exécute bien la tâche le plus rapidement et le plus correctement possible, mais selon son propre emploi du temps, et sa propre motivation. Du point de vue de l'expérimentateur, le but de la passation est de pouvoir cerner les raisons d'un éventuel défaut d'utilisabilité, et donc de laisser le participant explorer, autant qu'il le souhaite et comme il le souhaite, l'outil avec lequel il est amené à interagir - et qu'il est invité à « commenter ». De la même façon, nous avons estimé qu'il était sûrement peu probable que les futurs utilisateurs de NAT puissent avoir accès à une formation raisonnable sur ce logiciel, ce qui nous a incité à ne pas en faire de présentation, même succincte, en début de passation comme c'est le cas habituellement lors de tests d'utilisabilité. Nous avons imaginé, au contraire, qu'une présentation de ses fonctionnalités de la façon la plus simple qui soit pourrait permettre une prise en

- 29 -

main plus rapide et intuitive ; les nombreuses options de personnalisation de NAT (qui constitue, en ce sens, un logiciel extrêmement adaptable) devraient permettre par la suite d'ajuster le niveau d'expertise du logiciel à celui de son utilisateur. Dans le temps séparant les deux séries de tests, nous nous sommes donc attachés à la réorganisation du « système d'options » de NAT.

3.3. Configurations et options

Les options de l'application permettent en effet de contrôler à la fois les règles de transcription utilisées, la mise en page appliquée, le format d'entrée et de sortie des documents, les options générales d'interface, et enfin les options avancées du logiciel. Sur l'interface native, il s'est avéré que les utilisateurs montraient de grandes difficultés à comprendre la signification des « configurations » proposées par défaut (dites configurations système). Or, à peu de choses près, une configuration enregistre ensemble tous les paramètres décrits précédemment (cf. figure 8) : l'application testée présentait ainsi onze configurations système différentes, quand les recommandations ergonomiques en préconisent douze au maximum.

On note que la présence de l'« ascenseur » à droite de l'élément d'interface n'est pas toujours remarquée, et que certaines configurations deviennent alors invisibles pour l'utilisateur. Plusieurs termes n'étaient pas compris des sujets (« mep », « césure », « UTF8 », « 30x27 »...). Par ailleurs, sur l'interface native, les options de chaque groupe sont réparties en plusieurs onglets (huit) dans le menu d'options ; et modifier certains items d'un onglet entraîne des modifications sur d'autres onglets. Par exemple, choisir « Aucune mise en page » dans l'onglet « 1. Général » modifie le titre

- 30 -

et les options disponibles de l'onglet « 3. Mise en Page ». Plus généralement, le choix de présentation des options et leur activation par défaut tendent à montrer que NAT a été conçu dans une optique d'utilisation experte. La majorité des contributions utilisateurs ordinaires (recueillies à distance via le réseau) proviennent d'ailleurs de spécialistes en transcription braille - voyants ou non - et en informatique. Dans ce contexte, l'utilisateur non expert de l'un ou l'autre domaine, désireux de se confronter à ce type d'outil, se retrouve littéralement en situation de... handicap.

Cet utilisateur devrait pouvoir, en fonction des règles de transcription, de mise en page, et de

format, construire et enregistrer une ou plusieurs « configurations utilisateur », qu'il rappellera

ultérieurement en fonction de la tâche à réaliser. Pour ce faire, nous avons d'abord classé, en lien

avec l'équipe de développement, les variables contrôlées par les options de NAT en cinq groupes :

- transcription

- mise en page

- formats d'entrée-sortie

- interface

- avancé

Nous avons ensuite fait le lien entre chaque variable et chaque proposition du menu d'options existant, puis nous avons classé ces propositions de façon "logique" (par exemple, en tenant compte de leur caractère « basique » ou « avancé ») dans chacun de ces cinq groupes.

Fonctionnellement, l'utilisateur pourra créer et modifier ses règles de transcription ou de mise en page (sortes de « sous-configurations »), puis les mélanger pour créer une ou plusieurs configurations de base. Dans ce cas, il peut aussi plus facilement créer « à la volée » une configuration précise, pour une tâche atypique par exemple. De plus, il est renseigné sur ce qui impacte directement le résultat de sa transcription, séparé de ce qui concerne son « environnement » de travail, puisque les options d'interface (taille des fenêtres, accessibilité...) et avancées (gestion des fichiers temporaires...) n'influent pas sur le résultat final fourni par NAT. Nous obtenons finalement la conversion des huit onglets du « système d'options » du logiciel en trois fenêtres de paramétrages (Mode de transcription, Mise en page et Formats : cf. figure 9), qui apparaissent à la demande de l'utilisateur en tant que « détails d'une configuration », et deux fenêtres d'options (d'interface et avancées).

- 31 -

Le mode (intégral, abrégé, mathématique) peut ainsi être combiné facilement avec la mise en page (aérée, basique, compacte) et le format (WindowsTM ou LinuxTM) pour la création de la configuration voulue. Plutôt que de décrire ces quelques paramètres dans la liste de choix déroulante, on préfère inciter l'utilisateur à découvrir par lui-même leur édition dans les fenêtres correspondantes, et donc à explorer plus avant les possibilités offertes par NAT. En annexe H sont reportés les dessins techniques finaux proposés pour les fenêtres principales, d'éditeurs et d'options.

3.4. Bilan et perspectives

Nous avons donc pu mettre en évidence des défauts d'utilisabilité importants de l'application testée. Les défauts de surface ont renvoyé à des problématiques plus « profondes » concernant le fonctionnement global, qui nous ont amené à revoir le paramétrage du logiciel. Cependant, du point de vue du développement, cette réorganisation implique un enregistrement des paramètres, leur prise en compte lors des calculs, et enfin leur présentation par le biais de l'interface, très éloignés de l'implémentation actuelle. Comme le prévoyait la littérature dans ce domaine, ces modifications, préconisées trop tardivement dans le processus de développement de l'application, se sont avérées très gourmandes en codage informatique et en temps. Cette suggestion - qui s'apparente plus à du « design d'interaction » qu'à de l'« ergonomie logicielle » -, ainsi que d'autres recommandations issues de l'inspection analytique ou des tests utilisateurs, avaient donc peu de chances d'être mises en place sur l'interface corrigée dans le temps imparti. Si les modifications de surface préconisées sur la fenêtre principale ont pu être en partie implémentées, en revanche les remarques concernant la gestion des erreurs ou l'uniformisation des différentes fonctionnalités de l'application n'ont pas pu, faute de temps, voir le jour. La refonte du paramétrage et des options, qui implique de modifier

- 32 -

plus profondément l'implémentation actuelle de NaT, constituait selon nous un aspect critique de la perception du fonctionnement du logiciel et de son utilisabilité ; cette modification a donc été émulée dans la version corrigée (la fonctionnalité est visible sur l'interface, mais non implémentée dans le code).

4. CONCLUSION

Si NAT v. 2.0 est sans conteste une des solutions de transcription braille automatisée les plus efficaces et les plus puissantes éditées à ce jour, il reste que l'utilisation efficiente et satisfaisante de ses fonctionnalités - toujours plus nombreuses, en particulier à la demande de ses utilisateurs actuels - ne pourra se faire sans une refonte approfondie de son interface graphique et de ses principes d'interaction avec l'opérateur humain. Une prise en compte plus exhaustive et « anticipatrice » des possibilités d'erreurs, une gestion unifiée et précise des fenêtres de dialogue et des messages système, l'uniformisation globale de la sémantique, de la charte graphique et de l'emploi des icônes, enfin et surtout, l'implémentation d'un véritable éditeur intuitif, sont les défis à relever pour que NAT puisse bénéficier du succès et de la popularité qu'il est indéniablement en droit d'attendre.

- 33 -

RÉFÉRENCES

Abhishek, & Basu, A. (2006). Iconic interfaces for assistive communication. (Indian Institute of Technology, Kharagpur, India). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 295).

Archambault, D. (2010). Interaction et usages des modalités non visuelles, accessibilité des

contenus complexes. Mémoire de synthèse pour l'obtention de l'Habilitation à Diriger les Recherches. Université Pierre et Marie Curie ; Paris VI. France.

Bach, C., & Scapin, D. L. (2005). Critères ergonomiques pour les interactions homme-environnements virtuels : définitions, justifications et exemples. Rapport de Recherche n° 5531. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bastien, J. M. C., & Scapin, D. L. (1993a). Ergonomic criteria for the evaluation of human-computer interfaces. Rapport Technique n° 156. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bastien, J. M. C., & Scapin, D. L. (1996). Inspection d'interfaces et critères ergonomiques. Rapport de Recherche n° 2901. Institut National de Recherche en Informatique et en Automatique, Rocquencourt, France.

Bobillier-Chaumon, E., Carvallo, S. Tarpin-Bernard, F., & Vacherand-Revel, J. (2005). Adapter ou uniformiser les interactions personnes-systèmes ? Revue d'interaction homme-machine, Vol. 6, n° 2, 2005.

Christou, G. S. (2006). The use and evolution of affordance in HCI. (Cyprus College, Cyprus). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 668).

Danielson, D. R. (2006). Usability barriers. (Standford University, USA). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 652).

Ferre, X., Juristo, N., & Moreno, A. M. (2006). Obstacles for the integration of HCI practices into software engineering development processes. (Universidad Polytécnica de Madrid, Spain). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 423).

Henley, M., & Noyes, J. (2006). Traditional vs. pull-down menus. (Flow Interactive Ltd., London,

UK et University of Bristol, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 622).

- 34 -

Karoulis, A., Demetriadis, S., & Pombortsis, A. (2006). Cognitive graphical walkthrough interface evaluation. (Aristotle University of Thessaloniki, Greece). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 73).

Knight, J., (2006). Engagability. (University of Central England, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 197).

Mascret, B., Mille A., & Ollier M. (2008). Un transcripteur braille idéal ? Conférence Handicap, Paris.

Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Retrieved March, 13, 2010 from Jakob Nielsen's Alertbox web site :

http://www.useit.com/alertbox/20000319.html

Singh, S., & Dix, A. (2006). Software engineering and HCI. (University of South Africa, South Africa, et Lancaster University, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 549).

Sperandio, J.-C. (2007). Concevoir des objets techniques pour une population normale, c'est-à-dire comprenant aussi des personnes handicapées ou très âgées. PISTES, Vol. 9, n° 2.

Thoumie, P. (2004). Recherche technologique et diffusion de l'innovation au service du handicap. Rapport public de mission de réflexion. Secrétariat d'État aux personnes handicapées ; ministère de la recherche et des nouvelles technologies ; France. Retrieved January, 27, 2010 from La Documentation Française, Bibliothèque des rapports publics web site : http://www.ladocumentationfrancaise.fr/rapports-publics/044000064/index.shtml

Uzan, G. (2005). Ergonomie cognitive du handicap visuel : une contribution à la conception d'aides informatiques. Thèse de Doctorat. Université René Descartes ; Paris V. France.

Woolrych, A., & Hindmarch, M. (2006). Understanding and improving usability inspection

methods. (University of Sunderland, UK). In Ghaoui C. (Ed.), Encyclopedia of human computer interaction (p. 641).

- 35 -

COMPLÉMENTS BIBLIOGRAPHIQUES

Brangier, E., & Barcenilla, J. (Eds.) (2003). Concevoir un produit facile à utiliser. Adapter les technologies à l'homme. Editions d'Organisation.

Nogier, J.-F. (2008). Ergonomie du logiciel et design web : le manuel des interfaces utilisateur. Dunod, collection InfoPro.

Valléry, G., Le Port, M.-C., Zouinar, M. (Eds.) (2010). Ergonomie et conception de produit et de services médiatisés. Presses Universitaires de France.

- 36 -