Règles et principes d'utilisabilité

Transcription

1 Règles et principes d'utilisabilité D'après Software for Use, Larry L. CONSTANTINE, Lucy A.D. LOCKWOOD, Addison Wesley, 1999, ISBN Règle de l'accès Un utilisateur qui connaît bien le domaine d'application mais qui n'a jamais utilisé le logiciel devrait être en mesure d'utiliser ses fonctions principales sans aide. Un comptable devrait être capable de monter une charte comptable et de dresser des états financiers avec un nouveau logiciel comptable. Un graphiste devrait être en mesure de retoucher une image avec un nouveau logiciel de dessin. Un programmeur devrait arriver à créer un projet et coder dans un environnement de programmation. Un secrétaire devrait être capable de rédiger une lettre dans un nouveau traitement de texte. Si votre logiciel utilise une métaphore trop éloignée du domaine d'application ou ne respecte pas les conventions d'usage dans les logiciels comparables, l'utilisateur sera dérouté. Imaginez un environnement de programmation qui fonctionnerait avec une métaphore agricole: Pour créer un projet, vous demanderiez à Labourer un nouveau champ. Pour créer une classe, choisissez Semer une graine dans le menu Culture. Pour utiliser une extension (plugin), allez dans le menu Équipement et choisissez Ajouter de la machinerie. Pour lancer l'exécution, cliquez sur le bouton Récolter. Pour lancer l'optimiseur, activez l'agronome. Pour lancer le débogueur, cliquez sur Pesticide. Pour assembler votre logiciel et le déployer, choisissez l'assistant d'ensilage. Après combien de secondes auriez-vous désinstallé le logiciel? Règle de l'efficacité Un utilisateur expert ne devrait pas être ralenti par le système. L'utilisateur expert doit être en mesure d'accéder aux fonctions courantes sans être ralenti par les mécanismes qui sont mis en place pour les utilisateurs débutants. Les raccourcis clavier, les barres d'outils et menus configurables, les macros et les options avancées des fenêtres de dialogues sont des moyens d'arriver à cet objectif. Règle de la progression Le logiciel devrait soutenir l'apprentissage graduel de l'utilisateur.

2 L'utilisateur débutant ne devient pas expert instantanément. Le logiciel offrant des fonctions avancées de doit pas imposer un changement trop brusque à l'utilisateur, sans quoi celui-ci pourrait être découragé et changer de logiciel ou demeurer au niveau débutant. Un logiciel supporte mieux l'utilisateur s'il lui permet à un d'accéder à des modes intermédiaires (débutant, intermédiaire, avancé), offre des niveaux de progression différents par fonction (un utilisateur de chiffrier maîtrise peut-être parfaitement la manipulation de graphiques mais est peut-être novices avec les tableaux croisés dynamiques), ou encore offre des conseils lorsqu'il constate qu'une fonction est fréquemment utilisée. Le type d'aide évolue également en fonction du niveau de l'utilisateur. Règle du support Le logiciel doit rendre les tâches de l'utilisateur plus faciles, plus simples, plus rapides ou plus agréables à accomplir en tirant profit de la technologie disponible. Le logiciel doit offrir une valeur ajoutée par rapport au processus manuel. Cette valeur ajoutée prend typiquement la forme d'une économie de temps ou d'effort, ou encore d'une meilleure capacité à sécuriser, retrouver ou retraiter l'information. Par exemple, un gestionnaire de contacts permet de rechercher plus rapidement qu'un carnet d'adresses, particulièrement dans le cas des recherches par d'autres critères que le nom. L'ordre est toujours maintenu et l'ajout d'un contact est toujours facile par rapport au carnet papier qui peut manquer de place entre deux contacts. Règle du contexte Le logiciel devrait être adapté à son environnement d'utilisation. Certains éléments de l'environnement d'opération du logiciel peuvent rendre inefficaces certains mécanismes de son interface. Par exemple, les alertes sonores sont inutiles dans un environnement bruyant et l'éclairage coloré peut faire passer inaperçu les couleurs significatives. Un logiciel de bureau ne devrait pas émettre de son. Un logiciel déployé dans un environnement où l'attention de l'utilisateur est sollicitée (une usine, une voiture) ne devrait pas exiger la lecture de messages complexes. Un logiciel déployé destiné à des utilisateurs qui manipulent des objets en utilisant el système ne devrait pas demander de manipulation complexe des périphériques (comme utiliser une souris pour opérer une caisse enregistreuse ou prendre des commandes dans un restaurant) Principe de structure L'interface devrait être structurée en fonction d'un modèle clair, cohérent et identifiable par l'usager. Les éléments reliés devraient être regroupés et séparés des éléments qui pourraient être vus à tort comme semblables.

3 La structure d'une interface est créée en grande partie par les groupes de fonctions. Ces groupes de fonctions devraient se retrouver dans la structure des menus, des barres d'outils et des fenêtres de paramétrage. Par exemple, les opérations sur une en-tête et un pied de page devraient se trouver à proximité des opérations sur le format général de page, dans un menu de formatage. Les options de numérotation de page et d'en-têtes/pieds de pages alternatifs pour les pages paires et impaires devraient aussi être à proximité. Dans OpenOffice.org Writer: Menu Format Page... la fenêtre de paramétrage permet de changer la taille du papier, les marges, les bordures et la couleur de fond, les en-têtes, les pieds de pages, les colonnes de texte et le format des notes en bas de page. Il est aussi possible d'ajouter une en-tête ou un pied de page à partir du menu Insert. Par contre, le menu contextuel du pied de page n'offre pas de fonctions spécifiques aux pieds de pages, et pour numéroter, il faut aller dans le menu Insert Fields Page Number Principe de simplicité Les tâches courantes devraient être simples à exécuter. L'interface devrait utiliser le vocabulaire de l'utilisateur. Les fonctions les plus courantes devraient être aussi simples que possibles à utiliser, quitte à prendre pour acquises les réponses à certaines options peu utilisées. Les termes utilisés devraient être tirés du jargon de l'utilisateur. Par exemple, l'opération coller prend un certain nombre de choses pour acquises étant donné qu'elle est souvent utilisée et que les hypothèses quant aux options par défaut sont souvent correctes. Pour les cas particuliers où l'utilisateur veut un meilleur degré de contrôle, l'opération de collage spécial est offerte. C'est le même principe pour la sauvegarde: la sauvegarde normale prend pour acquis le remplacement de l'ancien fichier et ne demande pas de confirmation. Sauvegarder sous... offre plus de contrôle sur l'opération. Encore la même idée avec l'impression rapide qui prend l'imprimante par défaut et les options standard versus l'impression normale qui amène à la fenêtre de paramétrage. Principe de visibilité Les outils nécessaires à une tâche devraient être accessibles sans pour autant distraire l'utilisateur avec des outils superflus ou redondants. Les fonctions appropriées pour le contexte devraient être à portée de main, tandis que les fonctions non applicables devraient être écartées. Par exemple, lorsqu'une image est sélectionnée dans Microsoft Word, des outils supplémentaires apparaissent. Ils disparaissent lorsque la sélection change. Le menu contextuel est devenu un incontournable quand il faut offrir des fonctions spécifiques au contexte.

4 Le danger de cette approche est de dérouter l'utilisateur qui ne cerne pas bien les nuances du contexte et qui cherche des fonctions au mauvais endroit. C'est la principale raison qui fait qu'à peu près tout le monde (qui trouve comment faire) désactive l'option de cacher certains items des menus de MS Office Principe de rétroaction L'utilisateur devrait être tenu au courant des actions, interprétations, changements d'états et erreurs du logiciel qui sont pertinents pour lui et l'aident à comprendre le fonctionnement. Cette information devrait être formulée le plus clairement possible. Les opérations qui changent le comportement du logiciel, qui prennent du temps ou qui causent des erreurs sont particulièrement importantes pour l'utilisateur et l'aident à comprendre comment le logiciel est structuré. Les tâches longues devraient indiquer une progression (pourcentage, barre de progression) ainsi que la tâche courante (repagination, préparation de l'impression, envoi à l'imprimante). L'utilisation d'une barre d'état est pratiquement inutile. Les messages de confirmation sont également généralement inutiles parce qu'ignorés lorsque présentés en trop grand nombre. Un message demandant la confirmation avant de quitter le logiciel est inutile si le travail a été sauvegardé étant donné que la seule conséquence pour l'utilisateur qui ne voulait pas quitter est qu'il devra redémarrer l'application et ouvrir son document à nouveau. Les messages d'erreur devraient indiquer de manière claire et concise quelle erreur vient de survenir, d'où vient l'erreur, comment éviter qu'elle se reproduise, comment en minimiser l'impact et comment avoir plus d'aide. Les messages d'erreurs incompréhensibles et non destinés à l'utilisateur (écran bleu de Windows, erreurs rapportés uniquement dans un journal d'événements, codes d'erreurs sans messages ou messages du type «contactez votre administrateur de système») sont à éviter. Principe de tolérance L'application devrait être souple en minimisant les conséquences des erreurs, en évitant à l'utilisateur de commettre des erreurs et en supportant des séquences multiples d'opérations. Le logiciel devrait donner le plus grand degré de liberté possible à l'utilisateur. Lorsque la séquence des opérations n'est pas importante (mettre en gras puis en italique ou en italique puis en gras), aucune séquence ne devrait être imposée. Les formats de saisie devraient offrir une certaine souplesse: offrir un champ avec un masque de date est bien, mais interpréter une date saisie dans un format différent est encore mieux. Si le format attendu est mm-jj-aaaa, est-il vraiment utile de faire reprendre la saisie si l'utilisateur entre ? Et si l'usager francophone entre , est-ce que le logiciel devrait lui faire recommencer ou lui demander si la date est le 5 février ou le 2 mai? Et si on le faisait choisir la date sur un calendrier à la place? Dans un dialogue, le focus devrait toujours se trouver sur le bouton qui entraîne le moins de conséquences en cas d'erreur. Les boutons radios ne devraient pas avoir de sélection initiale s'ils sont obligatoires de manière à former l'utilisateur à choisir.

5 L'option annuler (undo) devrait annuler les changements significatifs (dans un traitement de texte, annuler la frappe d'un seul caractère est peu pratique) et garder un grand nombre d'opérations en mémoire. Les restrictions artificielles ne devraient pas être imposées, par exemple l'impossibilité d'annuler une sauvegarde lorsqu'une copie de sûreté est prise, ou l'impossibilité d'annuler au-delà d'une opération non annulable (formatage en gras, puis sauvegarde. Impossible d'annuler la mise en gras si la sauvegarde n'est pas annulable). Il peu aussi être important de distinguer refaire (redo) qui annule une annulation erronée, et répéter (repeat) qui réapplique la dernière opération effectuée. Plusieurs logiciels graphiques offrent aussi des annulations non linéaires permettant d'annuler une opération sans avoir à annuler toutes celles qui ont été effectuées par la suite, ce qui peut être particulièrement pratique. Principe de réutilisation La structure et le comportement des éléments d'interfaces devraient être réutilisé pour assurer une bonne cohérence. La constance dans la structure et le comportement permet à l'utilisateur de mieux anticiper le fonctionnement de l'interface lorsqu'il a déjà utilisé d'autres éléments semblables. L'idée principale est de présenter ce qui est semblable de la même manière. Par exemple, les icônes, les dialogues et les menus standardisés permettent aux utilisateurs de reconnaître les fonctions habituelles d'une application à l'autre. Les fonctions comparables devraient être invoquées par des éléments d'interfaces semblables. Par exemple, dans un traitement de texte, l'insertion d'une table des matières devrait ressembler de près à une insertion de table des figures ou à une bibliographie. Exporter en PDF devrait ressembler à une sauvegarde tout en faisant une distinction étant donné que le document PDF ne sera plus éditable.