2 - Etapes de conception des écrans
On peut distinguer deux étapes importantes dans la conception des écrans. La première concerne les caractéristiques de contenu, i.e., ce qu'il faut afficher. La seconde concerne les caractéristiques de surface des affichages, i.e., comment afficher.
Comme il a été indiqué précédemment, une activité des plus importantes dans la conception des écrans (mais aussi des entrées) est l'analyse de la tâche et de la population des utilisateurs. Bien que souvent ce soit l'analyse de l'activité qui reçoive le moins d'attention, c'est celle qui permet de savoir précisément ce qui doit être sur l'écran, à quel moment et en conséquence le type d'affichage à utiliser, sa taille, sa compatibilité avec d'autres affichages, etc.
Sachant cela, et en admettant que les analyses préalables ont permis de s'assurer que l'on possède les informations adéquates et de bons critères de sélection, on peut suggérer quelques étapes importantes dans la conception des écrans:
- en fonction des données recueillies, sélectionner les informations à afficher, et leur place dans les séquences de transactions;
- choisir les moyens de présentation à employer (papier, pages écran, fenêtres, etc.);
- établir les groupements appropriés, du plus élémentaire (groupement d'items) au plus vaste (groupes de groupes), en fonction de principes explicites de groupement;
- développer des labels et des titres pour les items, les groupes;
- essayer différentes organisations spatiales, en utilisant des critères explicites et choisir celle qui permet la meilleure performance;
- choisir des titres pour les affichages;
- développer des instructions et autres guidages qui doivent être placés sur les écrans ou sur des supports annexes;
- tester les écrans et autres présentations sur des sujets représentatifs de la population des utilisateurs futurs;
- reconcevoir si nécessaire.
3 - Codage
Dans cette partie seront évoquées des généralités sur les caractéristiques souhaitables des codages, et des notions sur diverses formes de codage d'écrans.
Le codage s'utilise pour identifier des items particuliers (e.g., des commandes ou des labels d'écrans) et pour distinguer différentes classes d'items simultanément présents (e.g., sur l'écran pour des informations, ou sur le clavier pour des touches fonctions). Les deux problèmes à considérer sont donc des problèmes d'identification et des problèmes de discrimination. Sans établir une frontière stricte entre ces deux problèmes, disons cependant qu'on traitera surtout de problèmes de discrimination dans la partie codage d'écrans et de problèmes d'identification dans une partie ultérieure sur le labeling (laquelle est en relation avec les considérations présentées précédemment sur la dénomination).
Dans tous les cas, il s'agit d'optimiser le choix du codage, c'est-à-dire d'une part de permettre une identification, une reconstruction et une compréhension rapides et aisées de la part de l'utilisateur et d'autre part d'éviter au maximum des confusions.
a - Généralités
Le codage doit être conçu en fonction des caractéristiques humaines, non pas pour s'adapter à des formulaires ou au logiciel. En d'autres termes, le choix d'un codage ne doit pas résulter de choix de codes liés à l'activité de programmation, ni se faire forcément à partir de codes existants. L'un comme l'autre de ces types de codes ont un sens, mais pas nécessairement pour l'utilisateur. Par exemple l'un peut résulter de contraintes d'organisation matricielle des items pour le programmeur; l'autre peut correspondre à des habitudes administratives, éventuellement obsolètes. Chacun d'entre eux ne correspond donc pas forcément aux caractéristiques de l'utilisateur considéré, pour la tâche qu'il se donne.
Dans la construction de codes, afin d'éviter les erreurs des utilisateurs, un certain nombre de règles devraient être suivies.
a1 - Unicité
Chaque code doit être unique (éviter toute proximité visuelle ou auditive entre codes). Comme les utilisateurs tendent à faire des erreurs sur des codes tirés de registres auditifs ou visuels similaires (i.e., qui sonnent de façon similaire ou qui ont l'air similaire visuellement), il est souhaitable de choisir des codes tirés de vocabulaires distincts.
a2 - Familiarité
Les codes doivent être familiers chaque fois que possible, correspondre aux attentes et à l'expérience des utilisateurs, et clairement être associés avec les objets codés. Cependant, dans certains cas d'ambiguités avec le langage naturel, il peut être utile d'adopter un langage technique approprié.
La similarité d'un code vis-à-vis du descripteur complet d'un objet, d'une action, d'une instruction influence la compréhension. Les codes qui sont similaires à leur définition (i.e., qui contiennent les mêmes caractères et dans le même ordre), telle qu'elle est fournie à l'utilisateur (manuels, help, etc.) sont mieux compris et rappelés que ceux qui apparaissent différemment dans la définition.
a3 - Règle d'encodage
Utiliser autant que possible une règle systématique d'encodage, c'est-à-dire utiliser la même technique pour coder tous les items (sauf quand cela est en contradiction avec d'autres règles). La règle d'encodage utilisée devrait être connue (et donc explicitée) des utilisateurs. Les codes qui sont dérivés, de façon consistante, de règles établies ont en effet plus de sens que ceux dont les règles d'encodage sont soit inconsistantes, soit peu claires, car l'utilisateur, dans le doute, tend à utiliser la règle d'encodage connue.
a4 - Taille
Les utilisateurs ont des limites en termes de volume maximal d'informations perceptibles à un instant donné. Grouper de longs items ou codes en chunks de 5 caractères aide à compenser ces limitations (c'est le fameux chiffre magique 7 +/-2).
De façon générale, quand cela est possible, des codes courts (2 ou 3 caractères) sont préférables à des codes longs. Plus le code est long, plus le risque d'erreur est grand.
a5 - Conformité vis-à-vis du Iangage naturel
Les codes doivent avoir des similarités avec la langue française. L'ordre de similarité selon ce critère est le suivant: mots complets, abréviations standard ou usuelles, abréviations proches visuellement du mot ou celles qui sont facilement prononçables.
Les codes ne doivent pas comporter de combinaisons de lettres inexistantes ou inhabituelles dans le langage naturel de référence Par exemple, un code du type QVIL sera plus sujet à erreur que QUIL, car il n'y a pas de pattern du langage tel que QV (en tout cas en français).
Les codes doivent être prononçables car mieux répétables, mieux appris, et mieux rappelés que ceux qui sont difficilement prononçables.
a6 - Fréquence
La fréquence selon laquelle un code sera utilisé influence sa compréhension. Ainsi quand le caractère signifiant ne peut être fourni à tous les codes, quand on ne peut les optimiser tous, alors, ceux qui seront le plus souvent utilisés doivent avoir la priorité (notamment pour des premières utilisations d'un système particulier).
a7 - Contexte
Le contexte dans lequel un code est utilisé influence sa compréhension. En effet, les utilisateurs rappellent d'autant mieux des codes que le contexte au moment du rappel est similaire à celui de l'apprentissage. Par exemple, les codes qui sont placés avec consistance au même endroit, donneront lieu à une meilleure compréhension et un meilleur rappel que ceux apparaissant de façon désordonnée ou aléatoire, car la localisation fournit une indication complémentaire sur la signification du code. Les codes qui font partie d'une longue phrase ont une meilleure signification que ceux qui se trouvent seuls, car la signification d'un code au sein d'un ensemble (set) est en partie acquise du set entier.
a8 - Codes mixtes
Les codes alphabétiques sont meilleurs que les codes numériques ou symboliques. Les codes tirés seulement de 2 vocabulaires (alphabétique et numérique) sont meilleurs que des codes tirés de 3 vocabulaires (e.g., alphabétique, numérique et symbolique).
a9 - Utilisation immédiate
Les codes, surtout s'ils sont nouveaux ou peu évocateurs, devraient être utilisés aussi immédiatement que possible après avoir été vus ou entendus.
a10 - Performance/préférences
Le choix des codes doit se faire en fonction de la performance des utilisateurs plutôt qu'à partir de leurs préférences. En effet, dans ce domaine, les opinions ne sont pas fiables.
b - Différentes formes de codage
Les éléments importants affichés sur l'écran, ou qui demandent une attention particulière de la part de l'utilisateur doivent être mis en valeur sur l'écran avec un codage auxiliaire, particulièrement quand ils apparaissent peu souvent (e.g., valeurs de variables récemment modifiées, données qui ne cadrent pas avec les valeurs attendues, valeurs dépassant les limites acceptables). Un codage positionnel peut suffire, mais des éléments très importants peuvent nécessiter d'autres formes de codage, telles que la couleur ou l'intensité lumineuse.
Par ailleurs, le codage d'écran doit être utilisé quand les éléments d'information sont disposés de façon irrégulière sur l'écran.
b1 - Alphanumérique
Les caractères alphanumériques peuvent être utilisés sans limite de combinaisons quand la présentation de données n'est pas elle-même alphanumérique (e.g., graphique).
Une convention consistante doit être adoptée pour choisir si les lettres seront soit en majuscules soit en minuscules. Pour les affichages, les lettres capitales sont plus lisibles. Pour les entrées, l'utilisateur doit pouvoir entrer indifféremment les deux.
Quand des codes combinent des lettres et des chiffres, les caractères de chaque type doivent être regoupés plutôt que dispersés (e.g., HW5 est meilleur que H5W).
Des codes signifiants doivent être adoptés plutôt que des codes arbitraires (e.g., DOS est meilleur pour dossier qu'un code numérique à 3 chiffres, en admettant que dossier est un bon terme pour l'objet considéré).
Les affichages (et les entrées) doivent être conformes aux stéréotypes de la population et aux abréviations acceptées.
Quand des codes ont une signification particulière (i.e., différente de leur acception usuelle), une définition doit être affichée en bas de l'écran (e.g., légende sur une carte). De plus, la définition doit répéter le code (e.g., Rouge=dangereux, en rouge).
Quand ils sont arbitraires, les codes qui doivent être rappelés ne doivent pas dépasser 4 ou 5 caractères (quand ils sont signifiants, comme un mot ou une abréviation, ils peuvent être plus longs).
Il faut éviter d'associer des paires de caractères qui risquent facilement d'être confondus, tels I-1, o-0, z-2.
b2 - Symbolique
Les symboles et autres codes doivent avoir une signification homogène d'un écran à un autre.
Sur des écrans alphanumériques, les symboles spéciaux, tels qu'astérisques, flèches, etc., peuvent être utilisés pour attirer l'attention de l'utilisateur sur des items particuliers. De tels symboles, s'ils sont utilisés pour des objectifs d'alerte, ne doivent pas être utilisés aussi pour autre chose.
Quand un symbole spécial est utilisé pour marquer un mot, il doit être séparé de ce mot d'un espace.
b3 - Couleur
Le codage couleur peut être considéré dans des applications où l'utilisateur doit distinguer rapidement parmi plusieurs catégories d'informations, particulièrement quand ces informations sont dispersées sur l'écran. Le codage couleur doit être utilisé de façon parcimonieuse, avec relativement peu de couleurs pour désigner des catégories d'informations critiques (il vaut mieux ne pas en utiliser plus de 5 ou 6).
Le codage couleur est une aide supplémentaire sur les écrans qui ont déjà été formatés aussi efficacement que possible avec une seule couleur. Il ne faut pas utiliser la couleur pour compenser un mauvais format d'écran. Il vaut mieux re-concevoir l'écran.
Le codage couleur peut convenir pour des titres, des données dépassant leur fourchette de valeurs normales, des données entrées récemment, des informations requérant une attention immédiate, pour souligner des champs importants, pour différencier des groupes d'informations, etc.
Le codage couleur doit être redondant avec d'autres caractéristiques, telle la symbologie. Chaque couleur ne doit représenter qu'une seule catégorie d'informations.
Ce codage doit être compatible avec les associations familières (e.g., nombres négatifs en rouge en comptabilité, rouge pour danger, jaune pour précaution, vert pour OK, bleu seulement pour des éléments de fond et pas pour des données critiques).
b4 - Autres codages (Intensité/Inverse vidéo/Clignotement/Son)
- Les différences d'intensité doivent seulement prendre 2 valeurs. Ce moyen peut être utilisé par exemple pour distinguer les labels de champs et les données en diminuant l'intensité des uns et en augmentant l'intensité des autres, ou pour souligner des options dans une liste, etc. Pas plus de 10% des éléments de l'écran doivent comporter une intensité lumineuse élevée.
- L'inverse vidéo peut être utilisée pour souligner des items qui nécessitent une attention particulière.
- Le codage par clignotement doit être utilisé en cas de besoin urgent d'attirer l'attention de l'utilisateur. Le clignotement devrait fonctionner sur un pointeur (e.g., une astérisque) plutôt que sur l'élément lui-même. L'utilisateur doit être capable d'arrêter le clignotement, lequel doit par ailleurs s'arrêter automatiquement dès que l'utilisateur a répondu. Même si on peut distinguer plusieurs fréquences de clignotement, il vaut mieux ne l'utiliser que comme codage binaire.
- Des sons distinctifs doivent être utilisés pour coder les items requérant une attention spéciale. Une variété de signaux de différentes fréquences est disponible. Les sons peuvent être présentés en séquence pour élargir le répertoire des signaux.
4 - Recommandations d'affichage
a - Caractéristiques générales des écrans
On peut identifier certaines caractéristiques ergonomiques souhaitables pour les écrans.
- Ils doivent être visibles, i.e., les éléments qui les composent doivent pouvoir être perçus par l'oeil humain. Il est donc nécessaire de s'assurer de la taille des caractères, de la fréquence de papillotement (flicker rate), du contraste, etc.
- Ils doivent être lisibles, i.e., communiquer de façon appropriée l'information nécessaire à l'utilisateur. S'assurer de la lisibilité signifie optimiser le groupage, l'espacement, l'ordre séquentiel des informations, etc.
- Ils doivent être consistants, cohérents entre eux vis-à-vis des séries de transactions et être compatibles avec les séquences d'entrée.
- Ils doivent être concis, i.e., fournir toute l'information nécessaire, pas plus, pas moins.
- Ils doivent fournir des informations directement utilisables, ne nécessitant qu'un minimum d'interprétations, de traductions, et de traitements de la part de l'utilisateur (quand ceux-ci peuvent être effectués automatiquement par le logiciel).
En plus de ces objectifs généraux de conception, certains domaines demandent une attention particulière. Il s'agit des messages, du contenu des écrans, du labeling, du groupement d'informations, de la standardisation, du texte, des listes, des tables, du défilement et des fenêtres, du rafraîchissement d'écrans.
b - Messages
Les messages peuvent comprendre une large palette d'informations. Ils peuvent être des suggestions (prompts) pour des entrées supplémentaires, des diagnostics d'erreur, des informations sur l'objet du travail, etc.
Quel qu'en soit le type, les messages doivent être concis et clairement compréhensibles par leur destinataire. Des codes sybillins, des acronymes, et des abréviations sont souvent difficiles à comprendre pour des utilisateurs débutants. Cependant, des utilisateurs plus expérimentés ne voudront pas de messages longs et pourront utiliser sans difficulté un ensemble d'abréviations bien construites. Malgré tout, dans ce dernier cas, des messages détaillés devraient être disponibles à la demande, même pour des expérimentés.
L'utilisateur qui est en période d'apprentissage ou l'utilisateur occasionnel tend à avoir besoin de plus d'instructions et d'aide de la part du logiciel. D'un autre côté, l'expert ou l'utilisateur fréquent ne veut rien voir apparaître qui ne soit essentiel pour atteindre le but qu'il s'est fixé. L'expérimenté souhaite des messages aussi courts et concis que possible et pourra s'estimer frustré s'il est obligé d'attendre que des messages contenant des informations inutiles ou redondantes défilent sur l'écran pour enfin accéder à ce qui l'intéresse. Les expérimentés devraient donc avoir la possibilité de supprimer ou d'interrompre des messages trop longs.
Une autre approche possible, comme indiqué précédemment, est de construire le logiciel à deux niveaux. Au premier niveau, le logiciel affiche des messages destinés au débutant; au second niveau, le logiciel présente un autre ensemble de messages destinés aux expérimentés. L'interaction devrait donc idéalement varier en fonction des capacités et du niveau de l'utilisateur.
Considérant que les utilisateurs peuvent être à mi-chemin entre ces deux catégories, d'autres facilités peuvent être incorporées au dialogue, comme par exemple une possibilité d'interruption et des messages courts complétés, à la demande, par des explications plus détaillées.
Les messages d'erreur sont un autre type habituel de messages. Quand des erreurs sont détectées, un effort doit être fait afin d'en indiquer la localisation, d'en donner la cause et de fournir un moyen approprié de correction. En conséquence, tout message d'erreur devrait indiquer ce qu'est l'erreur et ce que l'utilisateur peut faire pour la corriger.
Un exemple de conception erronée est un logiciel qui, lorsqu'il ne peut interpréter une commande, donne automatiquement une liste de toutes les commandes possibles. Une façon plus appropriée est d'imprimer un message court montrant que la commande n'a pas été comprise et conseillant l'utilisateur sur la manière d'obtenir les commandes disponibles en fonction de la transaction en cours.
Une autre notion importante est que la documentation papier (ou on-line) doit fournir des informations supplémentaires, et ne pas être seulement une traduction de codes d'erreur abscons.
