Système de représentation d’interfaces centré sur l’usager

Il existe différentes méthodes pour établir les spécifications d’une interface (Carr, 1996) et différents modèles pour évaluer son usabilité (Ivory & Hearst, 2001). Le terme usabilité est un néologisme qui sera employé ici comme équivalent du terme anglais « usability ». Ce terme s’apparent à usager, usage et il a des connotations d’habitude, de coutume et de pratique qui sont absentes des termes utilisabilité (traduction officielle du terme « usability »), utilisateur et utilisation. L’usabilité est définie (ISO 9241-11) comme étant le degré selon lequel un produit peut être utilisé par des usagers identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié. Une application logicielle est efficace si elle permet à l’usager de réaliser une tâche donnée. Elle est efficiente si elle lui permet de réaliser une tâche avec un minimum de ressources (ex. temps d’exécution, effort requis). La satisfaction caractérise le confort et l’acceptabilité fournis à un usager dans son usage d’une application (ex. degré de satisfaction par rapport à la rétroaction observée).

La norme ISO 9126, quant à elle, définit la facilité d’utilisation (« usability ») d’un produit logiciel comme étant un ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs. Cependant, cette norme ne considère pas l’efficacité et le rendement (efficience) comme étant des composants de la facilité d’emploi.

Peu de systèmes permettent actuellement de combiner la spécification et l’évaluation (Hudson, John, Knudsen & Byrne, 1999, John, Prevas, Salvucci & Koedinger, 2004). Le but du présent travail consiste à concevoir un système de représentation permettant de:
1) spécifier les interactions entre l’usager et l’interface pour une tâche donnée et de 2) prédire le temps d’exécution.

Dans l’optique de spécification, les objectifs sont les suivants :
1) Concevoir un langage permettant la spécification des interactions entre l’usager et l’interface au niveau de détail, et ce de façon intuitive.
2) Développer un outil permettant de vérifier la syntaxe d’une spécification.

En ce qui a trait à la prédiction du temps d’exécution, les objectifs sont les suivants:
1) Mettre au point un modèle prédictif du temps d’exécution d’une tâche quelconque exécutée par un usager entraîné sur une interface graphique (Graphical User Interface, GUI).
2) Développer un outil permettant de prédire le temps d’exécution des usagers à partir de la spécification des interactions, et ce dès les premières étapes du développement de l’interface.

Le système Activity-oriented Interface Representation (AIR) a été conçu dans le but de rencontrer ces objectifs. Son développement initial a été subventionné par le Programme de Support Institutionnel à la Recherche et à l’Enseignement (PSIRE) de l’École de technologie supérieure (ÉTS). Le système AIR comprend un langage de spécification, un modèle de prédiction du temps d’exécution et des outils logiciels. Le langage permet de spécifier le déroulement des tâches au niveau de détail. Chaque tâche est décrite par un script dont chaque étape se compose des éléments suivants : 1) Action de l’usager. 2) État interne du système. 3) Rétroaction de l’interface. 4) Durée. Chaque étape d’un script peut être spécifiée à différents niveaux allant d’une description abstraite (ex. déplacer une icône, ouvrir une application) à une description au niveau des opérations explicites. Les opérations explicites ont un effet direct sur l’interface (ex. frappe d’une touche du clavier, mouvement de pointage), par opposition aux opérations implicites, comme les recherches visuelles de composants, ou les activités cognitives. Dans le cadre de ce projet, on a également développé un outil logiciel qui permet d’écrire des scripts sous forme de fichiers texte (ASCII, « American Standard Code for Information Interchange ») ou HTML («Hypertext Markup Language » ), et de vérifier leur syntaxe. Le langage AIR a été validé par le biais d’une enquête réalisée auprès de 78 étudiants en génie logiciel. Cette dernière a permis de comparer le langage AIR à un autre langage de spécification, soit l’UAN (User Action Notation). Les participants ont évalué chacun de ces langages selon trois critères : i) Facilité d’apprentissage. ii) Facilité d’écriture. iii) Facilité de lecture. Cette enquête est présentée aux annexes 9 et 10 de ce document. Selon les résultats, le niveau d’effort requis pour apprendre et utiliser le langage AIR est plus faible que pour l’UAN. Selon ces mêmes résultats, l’AIR est préféré à l’UAN.

Dans le cadre du projet, on a également réalisé un outil permettant de prédire les temps d’exécution des usagers (réalisant des tâches sur interfaces GUI) à partir des scripts écrits en langage AIR. La prédiction s’effectue sur les trois opérations explicites suivantes: 1) Frappe d’une touche du clavier (K). 2) Mouvement de pointage (P). 3) Clic d’un bouton de la souris (C). Dans un premier temps, on transforme le script AIR en une séquence d’opérations explicites, sans tenir compte des changements d’état interne ou des rétroactions de l’interface. Une telle séquence est appelée un modèle KPC. Ensuite, pour chaque opération, on multiplie son nombre d’occurrences dans la séquence par un estimé de son temps moyen d’exécution. Ceci permet d’estimer le temps mis par un usager qui exécute le script AIR.

Le modèle KPC assume que les usagers sont habiles, c’est à dire hautement familiers avec les interfaces GUI. C’est le cas de la plupart des usagers actuels d’ordinateurs. Notre hypothèse est que même s’ils ne connaissent pas une interface donnée (état naïf), les usagers habiles apprendront rapidement à l’utiliser grâce aux automatismes acquis. Le modèle KPC a été mis au point et validé par le biais d’une étude expérimentale impliquant 20 sujets habiles avec les interfaces GUI. Avec les dix premiers sujets, on a estimé les temps moyens d’exécution des opérations K, Pet C. Avec les dix autres sujets, on a vérifié la précision des prédictions. Un article scientifique sur le modèle KPC a été soumis en août 2005 au International Journal of Human-Computer Studies (IJHCS).

Le système AIR est utilisé pour résoudre des problèmes d’efficacité et d’efficience dans les interfaces GUI. Un exemple d’un tel problème réside dans l’enregistrement d’un usager (« login ») dans une fenêtre réservée à cette fin. Il arrive que l’usager tente de confirmer son enregistrement en faisant un retour de chariot dans le dernier champ de texte rempli. Si l’interface ne lui permet pas cela, l’usager devra, par exemple, utiliser la souris pour aller cliquer sur le bouton de confirmation situé plus bas. Il perdra alors du temps sans compter la frustration et l’inconfort causés par cette situation. Le coût cumulatif de ces petits problèmes devient vite considérable lorsque l’interface est utilisée fréquemment. Par exemple, une perte de temps de 5 secondes répétée 4 fois par jour par mille usagers correspond à plus de 1300 heures par an.

Les interfaces Web présentent trop souvent des problèmes d’efficience ponctuels. Par exemple, l’usager doit employer trop d’hyperliens pour atteindre son objectif. Un autre exemple est l’absence d’informations importantes et/ou fréquemment consultées sur la page d’accueil d’un site Web. Le cas échéant, l’usager aura de la difficulté à obtenir ces informations ou ne les obtiendra jamais.

Le système AIR est utilisé pour aider à minimiser ces problèmes dès la conception. Pour ce faire, on choisira un ensemble de tâches simples et fréquentes. On utilisera le langage AIR afin de spécifier les séquences d’opérations correspondantes. On utilisera ensuite le modèle KPC afin d’obtenir un estimé du temps d’exécution et du nombre d’opérations exécutées pour chacune des séquences. En comparant, pour chaque tâche, les temps obtenus dans différentes implémentations possibles de l’interface, on sera capable de choisir l’interface la plus efficiente ou même d’estimer l’écart d’efficience entre l’implémentation actuelle et une bonne implémentation.