Remarquons que la plupart des recommandations fournies plus loin sont indépendantes des modes physiques d'entrée ou de sortie. En particulier, les recommandations ultérieures sur les entrées et les sorties s'appliqueront en majeure partie aux divers types de dialogue présentés ci-après.
Le mode question/réponse est un type de dialogue adapté quand les informations à obtenir ne peuvent être organisées sous forme de liste ou ne peuvent être facilement codées. Pour chaque réponse attendue de l'utilisateur, il est souhaitable de fournir un exemple de syntaxe correcte et de contenu approprié.
Ce type de dialogue est souhaitable notamment quand une certaine flexibilité est nécessaire pour l'entrée d'éléments optionnels. De plus, c'est utile quand l'utilisateur doit entrer des commandes ou des informations déjà écrites ou imprimées sous forme papier. Dans le cas d'utilisation de formulaires papier, la disposition de l'écran doit être, autant que possible isomorphe à ces derniers (dans la mesure ou ceux-ci sont eux-mêmes bien adaptés).
Pour réduire le temps de réponse, quand le type de terminal le permet, il est souhaitable d'enregistrer les entrées de l'utilisateur dans un buffer et d'effectuer le transfert des informations en une seule fois (i.e., la page de formulaire entière) plutôt qu'item par item.
Quand l'utilisation d'un tel dialogue est fréquente, des fonctions de tabulation sont nécessaires.
Un autre avantage de ce type de dialogue est que, dans certaines circonstances, il est possible de détecter facilement certaines erreurs syntaxiques en établissant des contraintes sur les champs d'entrée.
L'utilisation de menus est conseillée quand le nombre des commandes est si élevé qu'on peut prévoir qu'il dépassera les capacités mémoire des utilisateurs. Dans ce cas les menus jouent le rôle d'aide mémoire. Cela permet d'ailleurs de passer ensuite à des langages de commande. En effet, après l'entrée fréquente de commandes, l'utilisateur acquiert une certaine expérience d'utilisation qui lui permet ensuite de passer à un type de dialogue qui soit plus à sa propre initiative (dans la mesure où le logiciel dispose de plusieurs niveaux de dialogue).
De façon générale, les menus sont appropriés quand on souhaite s'assurer d'une bonne qualité initiale des entrées (i.e., limiter les erreurs lors de premières utilisations), quand les utilisateurs ne sont pas familiers avec toutes les fonctions du système.
Notamment pour des utilisateurs inexpérimentés, chaque menu ne devrait requérir qu'une seule sélection à la fois, laquelle devrait se faire par pointage direct.
Cependant, occasionnellement quand un choix parmi des options dont la longueur est courte s'avère nécessaire, la sélection peut se faire au moyen de l'entrée des codes correspondants ou par des touches fonctions dénommées de façon appropriée sur l'écran ou sur les touches elles-mêmes.
Les options du menu doivent être formulées pour permettre le pointage ou l'entrée d'un code plutôt qu'exprimées comme questions.
Si l'entrée se fait par des codes, chaque code devra être la(les) lettre(s) initiale(s) des labels des options, plutôt qu'un nombre (ou un code alphanumérique) arbitraire, excepté quand il y a un ordre implicite ou pour des listes très longues. Ces codes doivent être utilisés de façon homogène dans toutes les étapes du dialogue. Les labels auxquels ils correspondent doivent être localisés aussi de façon homogène.
S'il y a une numérotation, elle doit commencer par 1 et pas par 0. Après ce nombre, il doit y avoir un point et un espace, ainsi qu'un point après le texte de l'option. Ces nombre doivent être justifiés à droite.
Le texte des options doit être aligné en colonnes et justifié à gauche.
Les options d'un menu doivent être présentées selon un ordre logique du point de vue de la tâche, ou bien s'il n'existe pas un tel ordre, selon leur fréquence d'utilisation. Quand les deux ordres précédents sont inopérants, il convient alors d'utiliser l'ordre alphabétique.
Les menus doivent être formatés de façon à refléter l'organisation hiérarchique des options, plutôt que sous la forme d'une liste amorphe.
Chaque menu affiché ne devrait comporter que les options appropriées à l'étape de la transaction dans laquelle se trouve l'utilisateur.
Quand la sélection doit se faire à partir d'une longue liste d'options, et que toutes les options ne peuvent être affichées sur un même écran, une séquence hiérarchique de menus doit être offerte plutôt qu'une longue liste de plusieurs pages.
Dans les menus hiérarchisés, l'accès à des options critiques et/ou fréquentes doit être facilité. De plus, la position dans la structure des menus doit être fournie (e.g., en présentant une liste des options successives déjà sélectionnées).
Le nombre d'étapes dans une suite de menus doit être minimisé.
Les menus doivent être présentés successivement à la même place, plutôt que simultanément à différents endroits de l'écran.
Le format des différents menus doit être homogène à chaque niveau de menu et une fonction d'accès au niveau immédiatement supérieur doit être fournie.
Toutes les options doivent être bien entendu cohérentes du point de vue de leur dénomination et de leur ordre.
Quand une sélection est faite, il doit y avoir un feed-back immédiat (e.g., message, illumination de l'option choisie).
Pour des utilisateurs plus expérimentés, il est souhaitable de fournir la possibilité d'utiliser des raccourcis, d'anticiper la séquence des options par l'emploi de commandes (lesquelles peuvent être les codes des options).
Les touches fonctions comportent un certain nombre d'avantages. L'utilisateur n'a qu'à reconnaître la fonction (au lieu d'avoir à la rappeler), ce qui occasionne plus d'erreurs. Toutes les options sont toujours visibles et immédiatement disponibles. Les touches fonctions permettent assez facilement d'apprendre tout un ensemble d'entités, rendent la frappe aisée et évitent les erreurs typographiques. Pour réduire encore plus les efforts et le temps de transaction, on peut regrouper spatialement (et/ou avec codage couleur) les fonctions les plus fréquentes ou celles qui tendent à être utilisées conjointement dans une même séquence.
L'inconvénient majeur des touches fonctions est que lorsqu'elles sont nombreuses, cela nécessite des claviers volumineux, plus coûteux, et cela permet difficilement des changements d'applications informatiques. Par ailleurs il y a le risque de trop simplifier la tâche, mais surtout, même s'il y a moins de risques d'erreurs typographiques par rapport à la frappe de caractères, les erreurs de touches fonctions peuvent avoir des conséquences plus importantes.
Assigner plusieurs fonctions à la même touche, même si c'est une solution pour réduire l'espace du clavier, est générateur d'erreurs, pas seulement parce que l'utilisateur doit presser plusieurs touches à la fois, mais parce qu'il risque d'oublier dans quel mode fonction il se trouve. En général, une seule fonction doit être affectée par touche, en particulier pour un ensemble assez réduit de fonctions de type routinier, ou pour un ensemble de fonctions distinguables aisément d'autres fonctions (e.g., édition d'écran et entrée de données).
Ce type de dialogue est particulièrement approprié pour des utilisateurs naïfs, quand la syntaxe est simple ou bien quand un guidage est effectué. Si ce n'est pas le cas, une formation est nécessaire.
Les touches fonctions sont particulièrement utiles quand la tâche requiert un nombre limité de commandes, en complément d'autres types de dialogue, pour entrer des données critiques, du point de vue de la tâche, quand cela doit être fait rapidement et sans erreur de syntaxe. Elles sont très utiles pour des entrées très fréquentes (e.g., fonctions de type validation, impression, changements de page, etc.), et pour des entrées "provisoires", i.e., des actions qui peuvent être faites avant la fin d'une transaction (e.g., fonctions de tabulation, de répétition, d'appel à des valeurs par défaut, help, etc.).
Les touches fonctions doivent être codées de façon informative pour désigner les fonctions qu'elles exécutent. Ces fonctions doivent être assignées de façon cohérente tout au cours du dialogue. Quand plusieurs fonctions sont assignées à une même touche, elles doivent être choisies de la façon la plus homogène possible (par exemple, une fonction appelée Arrêt ne doit pas dans un cas effacer les données, les sauver dans un autre, et signaler l'exécution dans une troisième). Dans tous les cas, il devrait y avoir un affichage indiquant quelle fonction est active.
Les fonctions qui ne sont pas nécessaires dans une transaction particulière devraient être désactivées, rendues indisponibles. Si l'utilisateur presse une telle touche, aucune action ne doit avoir lieu, si ce n'est un message d'aide. Quand certaines fonctions sont actives et d'autres pas, le sous-ensemble des fonctions actives devrait être indiqué (e.g., intensité lumineuse supérieure).
Les touches fonctions devraient être regroupées dans un endroit distinct et facile d'accès. Les touches correspondant à des fonctions d'urgence doivent être disposées de façon prégnante, avec un codage distinctif (e.g. taille ou couleur).
Les touches ayant un effet potentiellement destructeur devraient être protégées physiquement.
Les touches fonctions doivent nécessiter une seule pression pour être activées. Si elles sont pressées à plusieurs reprises consécutivement, leur effet ou fonction ne doit pas changer pour autant.
L'exécution des fonctions doit toujours être signalée à l'utilisateur ou bien par une réponse immédiate et observable (e.g. son résultat), ou bien par un message, ou par l'illumination de la touche.
Les langages de commandes sont indiqués pour les systèmes disposant de nombreuses fonctions, et pouvant accepter un large éventail d'entrées, notamment quand ces entrées comportent des séquences arbitraires.
L'avantage d'un tel type de dialogue par rapport à des touches fonctions est qu'il autorise plus de flexibilité pour changer les fonctions à mesure que le système évolue ou bien lorsqu'il apparaît que certaines fonctions vont être plus ou moins fréquemment utilisées. Les changements sont alors des modifications du logiciel et pas des changements du matériel.
Cependant ce type de dialogue comporte un certain nombre d'inconvénients.
En particulier, l'apprentissage et le rappel d'un ensemble des commandes est plus difficile que la reconnaissance de touches fonctions. Par ailleurs, les utilisateurs n'emploient parfois qu'un sous-ensemble limité des commandes disponibles, ce qui les conduits à avoir recours à des documents, listings pour déterminer ou revoir les commandes utilisées moins fréquemment.
La nécessité de frapper plusieurs touches comporte un risque plus élevé d'erreurs de frappe, bien que de telles erreurs puissent être de moindre conséquence que celles occasionnées par la pression sur une mauvaise touche fonction. Taper plusieurs touches est aussi évidemment moins rapide que de presser une seule touche fonction. Ces inconvénients sont d'autant plus évidents que les utilisateurs ne sont pas des dactylographes expérimentés. Cependant, on peut estimer que des individus ayant eu une expérience même limitée avec une machine à écrire et qui n'ont à entrer qu'un ensemble relativement restreint et bien défini de commandes peuvent apprendre à le faire dans un laps de temps assez court, de l'ordre de quelques semaines.
L'aire d'entrée de commandes doit être située de façon consistante sur chaque page d'écran, preférentiellement en bas de l'écran. A côté de cette aire, il doit y avoir une aire d'affichage pour le guidage des entrées et pour la récapitulation des séquences de commande entrées précédemment.
L'utilisateur doit pouvoir effectuer ses manipulations, lancer ses commandes sans aucune considération liée au traitement informatique interne. Par exemple, l'utilisateur doit être capable de demander un fichier par son nom, sans autre information supplémentaire, telle que la localisation physique du fichier.
Le nombre de commandes doit être aussi réduit que possible. Il faut éviter l'existence de plusieurs commandes pour la même fonction.
Un langage de commande doit être organisé en groupes de commandes, fonctionnellement similaires, et à différents niveaux de complexité pour tenir compte des niveaux d'expérience des utilisateurs.
L'utilisateur doit pouvoir requérir des aides pour déterminer la nature des paramètres de commande requis. Pour les utilisateurs naïfs, il peut être souhaitable d'avoir un guidage automatique.
Les commandes doivent pouvoir être entrées sans ponctuation. Si une ponctuation est nécessaire, alors un symbole standard devrait être utilisé de façon homogène.
L'utilisation de quantificateurs et de connecteurs logiques, d'emploi malaisé, doit être évitée.
L'utilisateur ne doit pas avoir à faire de distinction liée au nombre d'espaces blancs dans une expression de commande; une séquence de commandes doit être valide qu'il y ait un seul espace, deux ou plus, avant ou entre les commandes ou les paramètres.
Le logiciel devrait être capable de reconnaître les erreurs de frappe ou de syntaxe les plus communes et corriger les commandes avec confirmation de l'utilisateur plutôt que de requérir une nouvelle entrée.
Les séquences de commande doivent être dictées par les choix de l'utilisateur plutôt que par des considérations de traitement interne (e.g., un utilisateur devrait pouvoir entrer ses données dans l'ordre où elles lui parviennent).En général, un langage de commande est constitué d'un terme de commande, qui définit une fonction et souvent de paramètres qui spécifient les différentes options de la fonction. Le format d'une commande peut être de type positionnel (dans ce cas les paramètres sont identifiés par leur position fixée ou relative), ou bien de type mots-clefs (dans ce cas ce sont les mots-clefs qui identifient à la fois le type des paramètres et leur valeur). Le format positionnel, qui impose une plus grande charge mémoire, n'est pas recommandé pour des utilisateurs débutants.
Il peut arriver qu'une commande soit lancée avec un ou plusieurs paramètres manquants. Dans ce cas, le logiciel ne devrait jamais ignorer complètement la commande. Une possibilité est d'indiquer à l'utilisateur ce qui manque. Une meilleure solution est d'assigner automatiquement une valeur (par défaut) aux paramètres manquants. Ces valeurs par défaut sont les valeurs le plus souvent utilisées dans les mêmes circonstances. Bien évidemment, si des valeurs par défaut sont proposées, l'utilisateur doit en être informé, et pouvoir les confirmer ou les changer aisément.
Un certain nombre d'autres considérations qui s'appliquent aux langages de commande, mais pas exclusivement, seront évoquées dans la section sur le codage.
|
|
