rechercher sur ergolab

s'abonner au fil rss
newsletter

Entrez votre adresse e-mail pour être informé de l'ajout de nouveau contenu :

 

» En savoir plus

01 Novembre 2003

Feedback
et rapport homme-ordinateur

TAGS : Feedback

accueil > articles > principes > Feedback et rapport homme-ordinateur

« Liste des articles


Introduction
1. Fournir un correspondant visuel aux traitements invisibles
2. Adaptation du feedback à la nature des traitements informatiques
3. Comment transmettre les informations ?
4. Principe de feedback vs critère de feedback immédiat
Conclusion
Pour en savoir plus...

Introduction

L'utilisateur doit toujours être informé des conséquences de ses actions. C'est un principe fondamental en ergonomie des interfaces. L'ordinateur est un être étrange. On a besoin de savoir s'il comprend ce qu'on lui dit. On a donc besoin qu'il nous dise qu'il a vu qu'on a cliqué sur un bouton et qu'il va travailler en conséquence.

1. Fournir un correspondant visuel aux traitements invisibles

Du point de vue utilisateur, le domaine de l'informatique est par définition opaque. On ne sait pas comment le système fonctionne et réagit à nos demandes. Les seules informations qui peuvent nous renseigner sur les actions du système sont celles qu'il veut bien nous donner.

» Choisir les traitements à concrétiser

Le rôle de l'ergonome est donc d'associer aux traitements informatiques un correspondant du côté utilisateur. Ça ne veut pas dire bombarder l'utilisateur d'informations.

On sélectionne parmi les traitements ceux dont l'effet intéresse l'utilisateur. Ce sont en général les états finaux, résultant d'une suite de traitements précédents. Ces traitements intermédiaires et leurs résultats ne sont pas importants pour l'utilisateur et il n'est pas nécessaire qu'il en soit informé. C'est même déconseillé si on veut conserver une charge informationnelle correcte. On doit seulement l'informer que le processus suit son cours.



Le passage d'un état A à un état B peut nécessiter des étapes intermédiaires (états A1, A2, A3).

L'utilisateur qui a cliqué sur le bouton "état b" n'a pas nécessairement besoin d'être informé des résultats des traitements intermédiaires. On doit seulement lui indiquer le résultat de l'ensemble des traitements : est-ce que l'état b a été atteint ou non.



On doit communiquer les informations pertinentes à l'utilisateur car la connaissance du résultat d'un traitement informatique peut l'aider à atteindre ses objectifs, à les atteindre plus rapidement ou avec plus d'assurance.


2. Adaptation du feedback à la nature des traitements informatiques

L'importance du feedback dépend de l'action de l'utilisateur et des traitements qu'elle exige. L'action peut avoir une conséquence visible ou non. De plus, le temps nécessaire à l'exécution de l'action peut être presque instantané ou plus long.

2.1. Visibilité de l'effet du traitement

» Conséquence visible = feedback inutile

Certaines actions ont une conséquence visible directement par l'utilisateur (par exemple la mise en forme dans Word). Le feedback est alors confondu avec l'action effectuée par le système (lorsque le texte est transformé en italique, on sait que le système a compris notre demande). La conséquence de l'action est alors suffisante pour informer l'utilisateur. Lui dire en plus "c'est bon, le système a bien mis en italique le texte que vous aviez sélectionné" serait redondant avec l'indice visuel. L'utilité du feedback doit être jugée en fonction de cette visibilité du résultat de l'action.


» Conséquence invisible = feedback utile

Certaines actions ont une conséquence invisible, par exemple l'enregistrement d'un document. Cliquer sur une icône d'enregistrement ne nous informe en rien sur l'efficacité de l'action. Pour illustration, par peur de perdre leur travail, il est très fréquent que les utilisateurs lancent plusieurs fois d'affilée la commande d'enregistrement.


La conséquence de l'action d'enregistrement est intrinsèque au système. Elle ne suffit donc pas pour informer l'utilisateur sur l'efficacité de son action. Il faut lui adjoindre un message spécifique, attestant du bon déroulement de l'enregistrement. On devra cependant veiller à ce que le message soit le moins intrusif possible.

2.2. Criticité du traitement

En parallèle de cette distinction entre résultats visibles et invisibles à l'écran, il faut tenir compte de la nature de l'action demandée par l'utilisateur. Cette action peut être plus ou moins critique. Cet attribut tient souvent au temps de travail perdu si l'action échoue. Un autre domaine qui peut être critique est la transmission d'informations par le web (la "criticité" de l'action dépend alors de l'importance des informations et des incidences de leur non transmission). On dira ainsi qu'un enregistrement ou l'envoi de données via un formulaire est une action critique. A l'inverse, un changement de mise en forme non pris en compte est facilement rattrapable.

L'importance du feedback devra être adapté en fonction de ces considérations : moins le traitement est critique, moins le feedback est utile (ou en tout cas, moins il devra être intrusif).

2.3. Traitements programmés

Lorsque l'utilisateur a automatisé certaines actions (exemple la mise à jour d'un anti-virus), on doit lui fournir un moyen de choisir d'être informé de l'accomplissement de l'action (ou de ne pas l'être…). On peut décider d'un type de feedback a priori et /ou laisser le choix à l'utilisateur d'en décider (on peut laisser un choix par défaut modifiable par l'utilisateur).


3. Comment transmettre les informations ?

3.1. Feedback sur le déroulement d'un traitement

Pendant que l'ordinateur travaille, il doit donner à l'utilisateur des informations sur le déroulement des traitements. Ces informations sont des données concernant la nature et la durée du traitement, avec indication du point final, correspondant au moment où le traitement sera terminé et à ce que l'utilisateur obtiendra.

3.2. Feedback sur l'accomplissement d'un traitement

Lorsqu'il s'agit d'informer sur le fait qu'une action a été exécutée, le feedback peut prendre diverses formes. Ces types d'interactions peuvent être plus ou moins intrusifs dans l'activité de l'utilisateur :

- L'information peut être transmise par l'ouverture d'une fenêtre de message ; dans ce cas, on doit exiger de l'utilisateur qu'il clique sur un bouton pour attester qu'il a lu (on ne peut en effet pas prendre le risque de laisser la fenêtre visible uniquement pendant un temps qu'on estime suffisant pour avoir lu le message). Ce feedback peut donc être considéré comme très intrusif puisqu'il interrompt l'utilisateur dans son activité et requiert une action de sa part.

- L'information peut être transmise par un changement d'état de l'icône du programme concerné ou d'un élément visuel dans la fenêtre de l'application. Des codes couleurs peuvent être utilisés à cet effet (exemple : icône verte = programme mis à jour).

- L'information peut être transmise par un indicateur visuel apparaissant quelques secondes à l'écran. Ce feedback présente le risque de ne pas être vu par l'utilisateur. Il peut être intéressant lorsque le traitement est régulier et très fréquent. C'est par exemple le cas de l'enregistrement dans la plupart des applications de traitement de texte.

- L'information peut être transmise par un indicateur disponible dans une fenêtre définie du programme en question. Cet indicateur peut préciser le moment où a été effectué le traitement informatique. Ce type de feedback n'est pas fourni de façon automatique à l'utilisateur. Il est placé à un endroit défini a priori. L'utilisateur n'accédera alors au feedback que lorsqu'il décidera d'aller consulter cette information. On est là dans le type d'affichage du feedback le moins intrusif.

3.3. Feedback, expertise et préférences individuelles

Il est intéressant du point de vue utilisateur d'avoir le choix de décider quel type de feedback on souhaite obtenir de la part du système. En effet, les préférences individuelles sont déterminantes dans ce type d'interaction.

On peut imaginer que les personnes les moins à l'aise avec l'outil informatique préféreront être trop informées que pas assez et que les experts préféreront les types de feedback les moins intrusifs. Quoiqu'il en soit, on doit laisser une certaine liberté à l'utilisateur dans le choix de l'affichage du feedback.

3.4. Feedback dans le domaine du web

Le principe général de feedback prend une signification particulière dans le domaine du web. Les informations à transmettre sont différentes de celles d'une application client. Les façons de transmettre ces informations sont aussi différentes.

Le feedback sur le web est beaucoup plus lié à la notion de temps, par analogie avec la métaphore du voyage que représente la navigation sur internet, et du fait que les "moyens de transport" ne sont jamais assez rapides à notre goût. Le feedback doit être disponible sur les actions passées, sur le présent et le futur.

On peut avoir besoin de fournir du feedback sur divers éléments :

- Feedback sur l'envoi d'informations : si l'envoi est long, on doit informer l'utilisateur de son avancée. Lorsqu'il est terminé et s'il est court, on informera l'utilisateur du résultat de l'envoi (information envoyée ou non, si non pourquoi et comment résoudre le problème).

- Feedback sur le chargement de la page : l'utilisateur doit savoir si ce chargement est terminé, et s'il ne l'est pas, l'état d'avancement du processus. Cette information est en général fournie par le navigateur, à un endroit déterminé.

- Feedback sur la progression d'un téléchargement : les téléchargements de données peuvent être de tailles variables. L'utilisateur doit pouvoir connaître la taille totale des données, une indication sur le temps présumé de téléchargement, le temps écoulé et le temps restant. Ces informations sont souvent représentées sous la forme de visuels (classiquement, barre horizontale se remplissant au fur et à mesure de l'avancement du téléchargement).

- Indications sur la navigation (ce qu'on a déjà visité, où l'on se trouve …). Ces indications sont souvent fournies par des modifications de format des éléments de navigation (couleur, taille…) ou par des indicateurs textuels :



Exemple de feedback doublé : la rubrique active est la rubrique 'ELECTRO'. Cette information est donnée à la fois par le titre de la page et par la mise en valeur du bouton de navigation correspondant (couleur différente des autres boutons de navigation).

Source : www.bokson.net/electro

2 types de feedback sont fournis dans cet extrait :
- Le titre de page "electro" nous renseigne sur la rubrique que l'on visite
- La différence de couleurs des boutons de la barre de navigation nous donne le même renseignement
Il s'agit ici de fournir des indicateurs de statut.




4. Principe de feedback vs critère de feedback immédiat

On doit distinguer le principe général de feedback et le critère ergonomique de feedback immédiat proposé par Scapin & Bastien (1993, voir l'article sur les critères ergonomiques).

Donner du feedback en général correspond à tout ce qu'on a évoqué dans cet article. Il s'agit globalement de donner des informations à l'utilisateur et de ne pas le laisser dans l'expectative.

Le critère de feedback immédiat est beaucoup plus restrictif puisqu'il ne concerne que les réponses de l'ordinateur à une action spécifique de l'utilisateur, à un moment donné. Dans ce cas, le problème se pose surtout lorsque le feedback immédiat est absent. Lorsque les concepteurs ont pensé à l'introduire, il est généralement pertinent et assez rapide.

L'indication de la rubrique active dans un site web n'est donc pas considérée comme du feedback immédiat. C'est pourtant du feedback puisque cela permet de donner de l'information à l'utilisateur concernant le système.

Le principe de feedback que nous avons détaillé doit donc être vu comme un principe général qui doit sous-tendre chacune des procédures et la conception des éléments de l'interface. Il permet de guider l'utilisateur à travers l'interface.

Le feedback fourni devra être contextuel, c'est à dire adapté à la situation de l'utilisateur et à son activité dans l'interface. Il s'agit de lui fournir l'information dont il a besoin au bon moment.

Conclusion

L'utilisateur doit pouvoir sentir qu'il contrôle le système. Il doit donc pouvoir en obtenir des renseignements. Quand il demande quelque chose, on doit l'informer du résultat du traitement. De la même façon, il doit pouvoir être informé du résultat de ses actions. Le système doit garder trace des actions de l'utilisateur et pouvoir l'en informer lorsque c'est pertinent.

Fournir du feedback, c'est donc à la fois informer l'utilisateur de l'efficacité de ses actions et le guider à travers l'interface. C'est lui donner des indices concernant le fonctionnement du système. C'est développer un type de communication pour rendre plus transparents les traitements effectués par le système.

Pour en savoir plus

» Ressources externes

Bastien, J.M.C., Leulier, C., & Scapin, D.L. (1998). L'ergonomie des sites web. In J.-C. Le Moal & B. Hidoine (Eds.), Créer et maintenir un service Web (pp. 111-173). Paris : ADBS.

Bastien, J.M.C. & Scapin, D.L. (1993). Critères Ergonomiques pour l'Évaluation d'Interfaces Utilisateurs (version 2.1). Technical report Ndeg.156, May 1993. INRIA. Programme 3 Artificial intelligence, cognitive systems, and man-machine interaction.

Scapin, D.L. & Bastien, J.M.C. (1997). Ergonomic criteria for evaluating the ergonomic quality of interactive systems. Behaviour and Information Technology, 6 (4-5), 220-231.




« Liste des articles

ergolab