Intégration du parti pris perceptuel

L’interface graphique est le moyen privilégié pour accéder aux fonctionnalités d’une application. C’est un objet intéressant car elle représente une vue intermédiaire de l’application : une certaine forme de représentation de celle-ci et des fonctionnalités qui y sont rattachées, sans toutefois en être l’exacte image. On a par exemple pu établir, à l’aide de recueils de corpus, les difficultés inhérentes à leur utilisation, en particulier dans le contexte de l’exploration qui conduit à des représentations erronées des fonctionnalités.

De par sa triple caractéristique de représentation intermédiaire de l’application, de point d’accès à l’application et de source d’erreur pour l’utilisateur, l’interface graphique représente un bon candidat pour notre modèle médiateur pour l’agent assistant. Les modèles que nous allons proposer s’appuient sur un composant essentiel de ces interfaces graphiques : le Widget. C’est en effet par l’intermédiaire de ces outils d’interaction que l’utilisateur accède aux fonctionnalités de l’application.

5.1 - Introduction

Ce choix a également été appuyé par l’étude de corpus que nous avons recueillis lors de sessions d’expérimentation avec des sujets humains.

Les requêtes présentées dans la Table 13 sont issues d’une session d’assistance où un utilisateur a pour consigne de poser des questions à propos de ce qu’il voit. Parmi les catégories de requêtes que nous avons identifiées on trouve aussi des requêtes portant sur l’agent en lui-même et des requêtes portant sur l’application (classe E dans la Table 13). Ces « méta-requêtes » sortent du cadre de notre étude.

A _{clique sur le bouton le plus a droite...}

B

tu t'en vas si je clique sur Fermer ?

pourquoi tu clignes tout le temps des yeux ? Teletron est une marque connue ?

C ^{c'est normal le bug dans la taille de l'image en haut ?}

D

peux tu agrandir la fenetre de l'appli ?

j'aimerais changer la déco, comme je peux faire ? je voudrais changer la couleur du chiffre au milieu peux-t'on mettre une image derrière le nombre ?

le truc bizarre a droite, au dessus des boutons, permet de connaitre l'etat du compteur ???

E

coco est bien le nom de l'appli ?

a quoi sert le truc au-dessus du scrolbar ? quel est le nom du truc dans lequel j'ecris ? a quoi sert le bouton à gauche de la chatbox ? a quoi sert le truc avec les 2 fleches ?

Table 13 : retranscription d’une session d’assistance des expériences Daft. Les requêtes sont regroupées

par catégories générales : on trouve des requêtes de type commande (B) et des métas requêtes (E), ainsi que les trois catégories de requêtes spécifiquement liées à notre problématique : les questions-pourquoi (A), les questions-comment (C) et les questions-quoi (D).

Outre qu’on retrouve les différentes catégories (les catégories quoi, pourquoi et

requêtes font références à des Widgets. On constate donc un rôle central des Widgets dans les requêtes récupérées. A partir de cette analyse, on peut catégoriser les rôles des Widgets dans les différentes situations qui découlent de ces différentes catégories de requêtes :

- Situation d’échec d’action : l’utilisateur n’arrive pas à obtenir ce qu’il veut ou aimerait obtenir quelque chose mais il ne sait pas comment faire. Il cherche alors à accéder à une fonctionnalité et ne trouve pas le moyen, la succession d’actions à effectuer pour l’obtenir. Accéder à une fonctionnalité implique généralement la manipulation d’un ou plusieurs composants : à partir d’un menu, d’un ‘click’ sur un bouton etc. Fournir une réponse cohérente à un utilisateur qui demande comment obtenir telle fonctionnalité revient à lui fournir la suite d’actions à exécuter, ce qui fait intervenir les composants de l’interface graphique.

- Situation d’échec d’identification : l’utilisateur perçoit l’interface graphique et ses composants mais ne réussit pas à comprendre la fonction ou le rôle de ce qu’il voit. Par exemple, il ne perçoit pas à quoi sert un Widget placé à l’écran. Cela l’amène à poser des questions sur le rôle de ce composant. Ici, le problème est directement lié à la présence, non comprise, d’un Widget à l’écran. La réponse à fournir consiste à expliquer la relation qu’entretient le Widget en cause avec l’application.

- Situation de perte de contrôle: quelque chose d’inattendu se produit à l’écran et l’utilisateur ne comprend plus ce qui se passe. De façon similaire, l’utilisateur interagit avec certains Widgets croyant arriver à un certain résultat, mais le ‘feedback’ de l’interface graphique ne correspond pas à ce qu’il attendait. Dans le premier cas, il s’agit d’expliquer à l’utilisateur le comportement de l’application. Celui-ci peut être dû à une erreur du programme mais peut aussi être dû à un comportement tout à fait normal de l’application mais qui échappe à l’utilisateur : c’est le changement soudain de l’état de l’un ou de plusieurs de ses constituants qui va alerter l’utilisateur. Le rôle de l’agent conversationnel sera alors de repérer ce qui peut avoir choqué l’utilisateur. Ce cas n’est pas traité dans le cadre de cette étude. On constate que dans le second cas c’est la manipulation de Widgets qui a causé le trouble dans l’esprit de l’utilisateur.

Dans tous les cas que nous avons exposés, on se rend compte que les Widgets sont au centre de la perception de l’utilisateur et que des troubles de l’utilisateur auront pour source des Widgets. Cela justifie de commencer notre étude de construction du modèle par l’étude de la modélisation de l’interface graphique par ses constituants, c'est-à-dire les Widgets.

Nous appellerons Daft-Swing la librairie proposant des modèles de Widgets que le concepteur de l’application peut utiliser pour construire le modèle de son application. La question du contenu de la modélisation passe pour une grande partie de « que doit-on

représenter dans le modèle de l’application ? » à « que doit-on représenter dans le modèle d’un Widget ? ». Il faudra prendre garde à vérifier que le modèle ainsi constitué

5.1 - Introduction