D'abord, du fait que les utilisateurs naïfs ont tant à assimiler, les procédures doivent être conçues de manière à limiter leur charge en mémoire. Une bonne méthode est d'incorporer des aide-mémoire dans les procédures. Une façon de le faire est d'utiliser des langages de commande dans lesquels les commandes font effectivement bien ce qu'attendent les utilisateurs. Une autre est d'utiliser des valeurs par défaut pour les données ou paramètres que l'utilisateur omet. Une autre façon est de fournir des menus.
Par ailleurs, le concepteur devrait fournir des ressources informatiques qui permettent aux utilisateurs d'augmenter progressivement la complexité et la sophistication de leurs interactions. Cela signifie par exemple: permettre à l'utilisateur de supprimer certaines des procédures les plus banales (i.e., les plus fréquentes, et souvent les mieux connues) qui ont été fournies au bénéfice des naïfs. Cela signifie aussi permettre à l'utilisateur de développer des procédures définies selon ses besoins (e.g., macro-fonctions sur mesure).
Enfin, il est souhaitable de prévoir une introduction aux procédures de dialogue, pour les naïfs. Cela peut être un guidage on-line ou un document permettant à l'utilisateur d'effectuer une ou plusieurs transactions complètes avec le système afin d'accomplir un objectif. Ceci peut se faire au moyen de scenarios, i.e., de transactions enregistrées entre le système et des utilisateurs expérimentés, ce qui permet à un utilisateur naïf d'observer comment un expérimenté utilise les procédures existantes pour atteindre un objectif particulier. Une fois qu'un ensemble suffisant de procédures a été défini, les utilisateurs peuvent s'y essayer sur des exemples dont les solutions sont connues du logiciel.
Idéalement, de cette manière, le logiciel peut amener l'utilisateur vers la bonne solution, au pas à pas quand c'est nécessaire, et à mesure que l'utilisateur acquiert de l'expérience, le logiciel intervient de moins en moins.
On reviendra sur certains de ces aspects procéduraux dans la section sur les entrées, à propos des séquences de commande.
Quand des données sont utiles pour des transactions ultérieures, ces données devraient être automatiquement affichées.
Excepté pour les numéros de série, l'entrée de caractères "0" en début d'item doit être optionnelle.
L'utilisateur ne doit pas avoir à faire la distinction entre un ou plusieurs espaces blancs.
L'utilisation de délimiteurs spéciaux entre données doit être évitée.
Quand les items à entrer sont de longueur variable, l'utilisateur ne doit pas avoir à les justifier que ce soit à gauche ou à droite, ni à supprimer des caractères de délimitation inutilisés.
La double frappe, les codes contrôle doivent être évités.
Quand des codes arbitraires doivent être entrés, utiliser de préférence des menus.
Le nombre de caractères à frapper doit être minimisé, par exemple en utilisant des abréviations signifiantes et distinctes. Les abréviations doivent suivre une règle explicite (e.g., troncature) et devraient être de longueur fixe. Les abréviations ne suivant pas la règle usuelle devraient être peu nombreuses et utilisées pour des exigences de clarté. Quand ces abréviations ne sont pas reconnues, un dialogue de clarification doit s'établir.
Quand des parties de longues informations sont très familières, elles devraient être entrées les dernières (excepté si cela contredit la logique ou l'usage établi).
Quand l'entrée de données comprend la transcription de documents source, les écrans de remplissage doivent correspondre aux formulaires papier (c'est aussi souhaitable pour le mode question/ réponse en ce qui concerne l'ordre des données).
Quand aucun document papier n'est concerné, la séquence des entrées doit suivre un ordre logique, du point de vue de la tâche, auquel on sait que l'utilisateur s'attend.
Dans le remplissage de formulaires, l'entrée d'items logiquement reliés doit se faire par une action explicite à la fin plutôt qu'une entrée séparée pour chaque item. L'utilisateur doit pouvoir revoir les données entrées. Quand cela est possible, l'utilisateur devrait avoir la possibilité de modifier les données si nécessaire, avant l'action explicite d'entrée ou de validation.
S'il y a une position d'origine (home position), celle-ci doit être consistante sur tous les affichages.
Le curseur doit rester où il se trouve jusqu'à ce qu'il soit déplacé par l'utilisateur. Cependant, dans le cas de remplissage de formulaires, le curseur doit être placé automatiquement au premier caractère du premier champ d'entrée. De plus, les mouvements du curseur doivent être minimisés. Par exemple, il faut aligner les champs d'entrée, prévoir une touche de tabulation permettant de passer d'un champ à un autre, grouper les entrées requises en haut de l'écran et celles qui sont optionnelles en bas, sauf quand cela contredit d'autres critères de regroupement (logique, séquentiel, etc.).
Les déplacements séquentiels entre champs devraient se faire plutôt avec des touches fonctions que de façon automatique.
Les mouvements du curseur doivent être consistants dans toutes les directions et isomorphes à la taille des caractères.
Les aires non nécessaires pour l'entrée de données doivent être protégées et le curseur ne devrait pas s'y arrêter.
Quand un utilisateur doit contrôler le déplacement d'objets, le déplacement de la main de l'utilisateur doit être identique à celui de la direction du mouvement de l'objet.
Les écrans tactiles sont recommandés pour les dialogues à base de menus.
La tablette graphique avec un stylet est recommandée pour les entrées graphiques. Cependant, la tablette graphique n'est pas un très bon outil pour l'entrée de caractères (la reconnaissance de caractères à la main est d'ailleurs envisageable seulement quand le dialogue n'a pas besoin d'être rapide).
La tablette graphique doit être au moins aussi grande que l'écran.
L'entrée vocale représente une option possible quand les autres canaux sont saturés.
L'entrée vocale , en alternance avec d'autres modes d'entrée, est utile pour distinguer par exemple entre données et commandes (e.g., commandes par la voix et données par clavier).
L'entrée vocale ne doit pas être utilisée dans un environnement sonore élevé.
Les appareils de reconnaissance doivent être "entraînés" dans des conditions qui reproduisent de façon aussi proche que possible les conditions d'utilisation.
La répétition des mots pendant l'entraînement doit être randomisée. Les vocabulaires utilisés doivent être tels que les mots et les phrases enregistrés soient aussi dissemblables que possible.
Le nombre de mots admis doit être limité.
Le microphone d'entrée doit comporter un bouton de déconnexion pour éviter des confusions avec les conversations annexes.
L'entrée de données doit être guidée explicitement par des messages d'aide et des labels de champs, explicites et plaçés de façon consistante sur les écrans par rapport aux aires d'entrée (e.g., toujours au dessus à gauche).
Ces labels doivent être dénommés de façon distinctive, afin d'éviter des confusions avec d'autres catégories (entrée de données, commandes, etc.).
Quand l'écran est encombré (ce qui ne devrait pas arriver), un code auxiliaire doit être utilisé (inverse-video, intensité lumineuse, couleur) pour distinguer les éléments affichés, en particulier pour distinguer labels et données.
Seuls des termes sur lesquels les utilisateurs s'accordent doivent être utilisés.
Les labels et champs d'entrée doivent être compatibles avec les labels et champs d'affichage.
Le label de chaque champ d'entrée devrait se terminer par un symbole spécial (e.g., ":") signifiant qu'une entrée est attendue. Des éléments additionnels de guidage peuvent aussi être utiles (e.g., Date (JJ/MM/AA: _ _/_ _/ _ _)). D'autres guidages implicites permettent par exemple d'indiquer une longueur fixe ou maximale d'entrée, et permettent aussi de distinguer entre entrées requises (e.g., soulignement par tirets) et entrées optionnelles (e.g., soulignement par points).
Quand des unités de mesure sont associées avec une entrée, elles devraient apparaître dans le label du champ d'entrée au lieu d'avoir à être entrées par l'utilisateur. Bien entendu, ces unités de mesure doivent être familières aux utilisateurs et ne pas requérir un traitement des données brutes de la part de ces derniers.
Par ailleurs, les labels doivent être protégés des interventions des utilisateurs, à moins que des changements soient permis par l'utilisation explicite d'une fonction d'édition des labels. Quand plusieurs items (particulièrement s'ils sont de longueur variable) doivent être entrés, il doit toujours y avoir un espace entre les champs d'entrée. Cet espace doit être protégé et un signal auditif devrait alerter l'utilisateur quand celui-ci tente d'entrer dans ce champ.
|
|
