Guide d'ergonomie de conception des IHO

3 - Séquences de commande

Tout en rappelant que la conception des transactions doit être établie en fonction d'analyses du travail préalables, et représenter des unités logiques du point de vue de l'utilisateur, on peut définir un certain nombre de recommandations concernant les séquences de commande (ou séquences de fonctions, par opposition à entrée de données).

a - Simplicité

Les séquences de commande doivent être simplifiées au maximum, en particulier pour des tâches en temps réel qui requièrent des actions rapides de la part de l'utilisateur.

b - Conformité des buts

La facilité des séquences de fonctions doit correspondre aux buts poursuivis. Par exemple, les actions fréquentes doivent être faciles à exécuter alors que les actions potentiellement destructrices doivent être suffisamment difficiles pour nécessiter une certaine attention de la part de l'utilisateur.

c - Conformité vis-à-vis de l'expérience

Les séquences de commande doivent aussi correspondre aux capacités des utilisateurs: pas-à-pas pour les inexpérimentés, transactions rapides et puissantes pour les expérimentés (e.g., raccourcis, anticipation par empilage de commandes). Il doit être possible aux utilisateurs de définir leurs propres macro-commandes pour les séquences de commande fréquemment utilisées.

d - Contrôle

Les séquences de commande doivent être contrôlées par l'utilisateur, en fonction de ses besoins, disponibilités, attention, plutôt que par le traitement interne ou les événements extérieurs.

L'ordinateur ne doit pas interrompre l'utilisateur en cours d'entrée pour requérir des corrections mais attendre jusqu'à ce que l'utilisateur signale la fin de la transaction (ou demande de l'aide).

Idéalement, la plupart des actions de l'utilisateur devraient être anticipées et des options appropriées à chaque cas devraient être fournies. Ceci permet à l'utilisateur d'avoir toujours la main. Il ne doit jamais y avoir de voie sans issue dans une transaction, sans aucune action ultérieure possible.

e - Caractère explicite

Les séquences de commande doivent résulter d'actions explicites de la part de l'utilisateur et non pas être une conséquence de traitements antérieurs.

f - Entrées différées

Si les entrées de l'utilisateur doivent être différées, le clavier (ou autre moyen d'interaction) doit être bloqué jusqu'à ce que la prochaine transaction soit possible. Ceci doit être accompagné par la disparition du curseur ou par un signal auditif. Quand la transaction peut reprendre, le logiciel doit en informer l'utilisateur.

g - Cohérence et contexte

Les séquences de commande doivent être consistantes du point de vue de leur forme et de leurs conséquences: des moyens similaires doivent être mis en oeuvre pour des résultats similaires, d'une transaction à une autre, et d'une tâche à une autre. Si les conséquences d'une commande diffèrent selon le contexte (établi à partir d'une commande passée précédemment), un moyen approprié d'affichage du contexte doit être fourni à l'avance à l'utilisateur. Rappelons aussi que les affichages doivent être conçus de sorte que les éléments pertinents de l'entrée de commandes (listes d'options, aires d'entrée, etc.) soient distincts en position et en format.

h - Interruptions de dialogue

L'utilisateur doit pouvoir interrompre, différer ou annuler de façon consistante une transaction en cours. Si disponibles, les fonctions suivantes peuvent être définies.

Une option d'annulation doit avoir l'effet de régénérer l'écran, sans traiter aucun des changements effectués par l'utilisateur.

Une option de retour-arrière doit avoir l'effet de revenir à l'affichage obtenu dans la transaction précédente.

Une option de recommencer (restart) doit avoir l'effet de retourner au premier affichage d'une séquence de transactions, afin de permettre à l'utilisateur de revoir sa séquence d'entrées et d'effectuer les changements nécessaires.

Une option détruire doit avoir l'effet d'annuler toutes les entrées dans une séquence de transactions. L'utilisateur, en particulier pour une activité d'entrée de données, doit pouvoir confirmer son ordre d'annulation.

Une option de fin doit avoir pour effet de conclure une séquence de transactions et de retourner au menu général d'options.

i - Feed-back

Toutes les commandes doivent être répercutées de façon non ambiguè soit par leur exécution immédiate, soit par un message indiquant que l'exécution est en cours ou différée, ou que les commandes nécessitent une correction ou une confirmation. Le feed-back pour les entrées de commande devrait consister en des changements d'état ou de valeur des éléments affichés affectés par les fonctions considérées, de façon attendue et naturelle.

Aussi souvent que possible, le logiciel doit indiquer les options disponibles, celles qui sont actives et récapituler les options précédentes, à la demande de l'utilisateur.

Le logiciel doit garder trace du contexte de sorte que l'utilisateur n'ait pas à entrer à nouveau des commandes, des données ou des paramètres concernant la transaction en cours.

Le feed-back doit être consistant et distinct en position et dénomination.

j - Limitation des erreurs

Le logiciel doit d'une part ne pas provoquer d'erreurs et d'autre part anticiper l'erreur humaine. Par exemple, si l'utilisateur sélectionne une touche fonction invalide, aucune action ne devrait en résulter si ce n'est un message indiquant quelles fonctions sont appropriées à cette étape de la transaction.

L'utilisateur doit pouvoir modifier ses commandes avant son action explicite de validation.

Si une commande ou un paramètre n'est pas reconnu ou est inapproprié, il devrait y avoir un message indiquant de corriger cet élément, sans avoir à entrer à nouveau la commande complète pour confirmation par l'utilisateur.

Quand l'utilisateur entre une commande qui peut être destructrice ou causer des dommages importants aux données stockées, cette commande doit être explicitement confirmée. Le guidage pour une telle confirmation doit être clairement exprimé et la touche de confirmation doit être libellée de façon explicite et différente de la touche de validation.

Quand l'utilisateur termine une session (log-off) et s'il y a un risque de perdre des données, il doit y avoir un message le signalant et demandant confirmation de l'arrêt.

C - LES SORTIES

1 - Le temps de réponse

Le temps de réponse de l'ordinateur est le temps qui s'écoule entre une action (e.g., une commande) de l'utilisateur et une réponse de l'ordinateur.

Tout d'abord, il faut indiquer qu'il n'existe pas de temps de réponse unique acceptable car cela dépend de la tâche et des attentes de l'utilisateur. Cela signifie qu'un temps de réponse particulier peut être acceptable pour un utilisateur avec un certain objectif en tête, mais que ce ne sera pas acceptable pour le même utilisateur avec un autre objectif.

Cependant, bien que les capacités informatiques limitent le temps de réponse, un effort doit être fait pour garder le temps de réponse dans des limites acceptables. Ceci est important dans la mesure ou le temps de réponse affecte l'attitude de l'utilisateur vis à vis du système, ses habitudes de travail, et même les circonstances dans lesquelles il va utiliser l'ordinateur.

Un temps de réponse qui dépasse 10-15 secondes est totalement inacceptable car la continuité des processus de pensée de l'utilisateur devient difficile à maintenir. Quand le temps de réponse est aussi long, il faut restructurer la tâche.

Dans la plupart des applications informatiques, ce n'est pas un seul, mais des temps de réponse acceptables qui doivent être envisagés. En effet, les utilisateurs sont prêts à attendre de façon variable selon leurs types de requêtes. Par exemple, un utilisateur acceptera d'attendre plus longtemps à la fin d'une série de commandes plutôt que durant une seule transaction.

Un problème crucial concerne la variabilité du temps de réponse: celui-ci devrait être contrôlé de sorte que des délais identiques s'écoulent entre des actions identiques de l'utilisateur et la réponse de l'ordinateur.

De plus, chaque fois que le temps de réponse prévu est relativement long (i.e., plus de 5 secondes après le feed-back d'entrée de l'utilisateur), un message devrait être affiché et indiquer que le logiciel est en cours de traitement. Si cela continue, ce message devrait apparaître toutes les 10 secondes.

Pour cependant donner un temps de réponse souhaitable, on s'accorde sur 2 secondes, en particulier pour la plupart des tâches de bureau, sauf si les transactions nécessitent l'accès à un ordinateur central, à un réseau.

Une dernière remarque est que des temps de réponse assez longs peuvent être acceptables quand les transactions sont généralement génératrices d'erreur (ce qui ne devrait pas être le cas), car des délais longs augmentent les possibilités d'auto-détection des erreurs préalablement à l'entrée.

Rappelons enfin que même si le temps de réponse est un aspect important de l'interface, il est encore plus important de s'assurer que l'information présentée est pertinente pour l'utilisateur.