Cours ISI - Les principes de Tognazzini
From Isiwiki
| ← | ^ Cours ISI - Principes ergonomiques | → |
Référence : http://www.asktog.com
Bruce Tognazzini propose de suivre les principes ci-dessous pour concevoir les interfaces.
[edit] Anticipation
Anticiper les besoins et désirs de l'utilisateur
Amener à l'utilisateur les outils et informations nécessaires à sa tâche
ne pas s'attendre à ce qu'il cherche lui-même
[edit] Exemples
La rubrique Enregistrer Sous du menu Fichier propose un dossier (le même que celui du fichier, le dernier utilisé, etc.)
Après "Copier" prévoir que l'utilisateur va probablement faire "Coller"
À l'ouverture d'un document : repositionner à la dernière position modifiée, c'est probablement là que l'utilisateur voudra continuer à travailler.
Sur une page Web : proposer des liens vraisemblables depuis cette page (qu'est-ce que l'utilisateur qui lit cette page peut bien avoir envie de faire ensuite). Par exemple, après avoir vu l'horaire d'un train il voudra probablement commander un billet ou connaitre le prix du billet.
[edit] Autonomie
L'ordinateur, l'interface et l'environnement appartiennent à l'utilisateur apprentissage plus rapide quand l'utilisateur se sent responsable
Mais il faut aussi des limites sinon l'utilisateur est désécurisé (comme les enfants)
ex. guider l'utilisateur dans certaines tâches
ex. panneaux de saisie de paramètres
L'autonomie implique le contrôle de l'état du système.
[edit] Visualiation de l'état du système
La visualisation de l'état du système permet à l'utilisateur d'adapter son comportement ou son travail. Cet état doit être immédiatement visible (pas forcément en détail), mais de manière discrète.
Comme la montre le diagramme ci-dessous, une visualisation précise de l'état n'est pas si simple. Dans le cas présent, on veut montrer à l'utilisateur s'il est en mode "italique" ou non. En principe deux icones différentes suffiraient (un "I" sur fond blanc ou sur fond gris) mais en fait il faut tenir compte de la position du pointeur (sur le bouton ou non) et du bouton de la souris (enfoncé ou non) pour montrer un feedback complet.
[edit] Perception des couleurs
Environ 10% des adultes males sont daltoniens et ne perçoivent pas certaines couleurs. Les deux images ci-dessous présentent la même copie d'écran selon deux perceptions différentes : l'une avec toutes les couleurs, l'autre telle qu'un certain type de daltonien la voit (il se peut que vous ne voyez pas ou peu de différence si vous êtes vous-même daltonien)
Pour rendre l'interface utilisable par tous il faut offrir des clés de compréhension indépendantes des couleurs. Pour cela on peut utiliser
- des variations de gris
- textes en plus des codes de couleur
- des formes différentes
- des positions différentes (p.ex. dans l'interface Aqua sur Mac il y a trois icônes rondes rouge, jaune et verte pour fermer, minimiser ou maximiser la fenête. Un daltonien se repérera par la position à gauche, au milieu ou à droite des icônes (voir images ci-dessus).
[edit] Consistance
Différents niveaux de consistance / par ordre d'importance
- actions des utilisateurs (ex. raccourcis clavier)
- structures invisibles (les décrire)
- petites structures visibles (icones, flèches, ...)
- look d'une application
- look d'une suite de produits
- ...
Attention: consistance ne doit pas signifier uniformité
[edit] Catégories de consistance
La consistance apparait à différents niveaux.
La consistance interne concerne tout ce qui se passe dans une même application (qui peut servir à réaliser plusieurs tâches). Elle concerne le choix de la terminologie, des couleurs, des polices de caractères, de la mise en page, etc. La consistance terminologique veut que l'on utilise si possible toujours le même terme pour désigner la même chose.
La consistance externe est plus large, elle se réfère à un ensemble d'applications, à tout un système d'informatin, etc. L'illustration ci-contre montre que dans l'environnement MS Office les menus Edition sont consistants.
compatibilité avec les choses familières icônes, métaphores, ...
Consistance externe
[edit] Limites de la consistance
Impossible d'appliquer toujours les mêmes règles ex. choix de l'option à présélectionner la dernière utilisée la plus probable ... dépend de l'action
Consistance inter-application ne facilite pas toujours l'apprentissage mieux vaut bien distinguer les choses
Inconsistance nécessaire quand les choses agissent différemment
[edit] Efficacité de l'utilisateur
La productivité de l'utilisateur avant celle de la machine
Exemple - four mico-ondes Quel est le plus efficace ? chauffer de l'eau pendant 1 min. et 1 sec chauffer de l'eau pendant 1 min et 11 sec Pour la machine Pour l'utilisateur
Ne pas avoir peur d'utiliser la puissance de la machine Affichage WYSIWIG Calculs "instantanés« Actions pendant que l’utilisateur tape (p.ex. avec AJAX)
Qui va gagner du temps avec le système ?
Exemples: vote par internet
Pour l'utilisateur un peu plus long que la technique papier surtout si l'utilisateur doit vérifier lui-même la sécurité
Pour l'administration beaucoup plus rapide que le dépouillement manuel possibilité de faire des statistiques
Ecrire des messages d'aide compacts.
Et qui répondent bien au problème
Une bonne formulation paie bien en compréhension et en efficacité
Les mots clés en premier dans les menus
Non
Insérer saut page Ajouter note Mettre à jour info. utilisateur Modifier note
Oui
Insérer Saut de page Note Modifier info. utilisateur Note
[edit] Interface explorable
Donner de bons repères et une route bien balisée à l'utilisateur. Puis le laisser s'aventurer où il veut
- l'utilisateur inexpérimenté peut réaliser sa tâche sans se perdre
- ceux qui le veulent peuvent aller plus loin
Dans certains cas il faut cependant fournir un guidage plus fort. En particulier pour les tâches peu fréquentes effectués par des débutants (ex. configurer un accès réseau)
Donner des clés visuelles stables
- l'utilisateur doit se sentir chez lui (repères fiables)
- P.ex. avec des codes de couleurs
Les actions doivent être réversibles, ce qui permet
- l'exploration des fonctions que l'on ne connait pas
- la réparation des accidents (fautes de frappe, clique à côté du bon bouton, etc.)
- de travailler plus vite (sentiment de sécurité)
- de supprimer de nombreux dialogues du genre "Etes-vous vraiment sûr ?"
Toujours fournir une porte de sortie : l'utilisateur doit pouvoir revenir à un point connu depuis n'import où.
D'un autre côté il est souhaitable de donner un sentiment d'être "dans l'application". On évitera par exemple de "décorer" (ou charger) les pages web avec des objets et options qui n'ont rien à y faire. Idéalement les menus des navigateurs devraient disparaitre lorsque l'utilisateur est engagé dans une tâche. Comparez l'impression donnée par chacun des écrans ci-dessous à un utilisateur qui veut réserver un billet d'avion
Avec les boutons de navigation et le menu des marque pages.
En cachant tous les menus et boutons.
[edit] Objets de l'interface
Ne pas confondre avec les objets de la programmation orientée-objet
Objets de l'IHM perceptibles pas seulement visuels, penser à l'ouïe ont une manière standard d'interagir fournissent un résultat standard compréhensibles, consistants, stables
[edit] Loi de Fitt
Selon la loi de Fitt, le temps pour atteindre une zone dépend de la taille de la zone. Par conséquent il est fortement recommandé de prévoir de grands boutons pour les fonctions importantes ou fréquemment utilisée.
De plus, les bords de l'écran "agrandissent" les objets. En effet, si un bouton se trouve contre le bord de l'écran, même si l'utilisateur fait un déplacement de souris qui irait théoriquement plus loin que le bouton, le bord de l'écran bloque le pointeur. Donc tout se passe comme si le bouton s'étendait virtuellement bien au delà de l'écran (voir figure). Par la loi de Fitt, l'accès à ces boutons est donc beaucoup plus rapide (vu leur taille virtuelle) que l'accès à un même bouton placé ne serait-ce qu'un pixel en dessous du bord.
On peut également utiliser les coins de l'écran, sans même dessiner un bouton, pour certaines fonctions.
[edit] Réduction de l'impression d'attente
Lorsqu'une opération prend plus d'une à deux secondes, l'utilisateur doit être informé que la machine travaille effectivement pour lui et n'est pas bloquée ou en attente d'une commande (feedback). Mais il faut également agrémenter cette attente pour diminuer le sentiment de frustraton qui peut naitre. Pour cela on peut employer divers techniques :
- Acquiesser tout click sur un bouton par un retour visuel ou auditif dans les 50 millisecondes
- Afficher une montre pour toute action qui prendra entre 1/2 et 2 seondes
- Animer la montre pour que l'utilisateur sache que le système n'est pas mort
- Afficher un message indiquant la durée d'attente probable pour toute action qui prendre plus de 2 secondes.
- Communiquer la durée réelle à traver une barre de progression processes, such as server saves, to be completed.
- Offrir des messages (animations) engageants qui informent et distraient l'utilisateur lorsqu'il attend sur un processus long (p.ex. la sauvegarde sur un serveur)
- Générer un son et afficher une indication bien visible quand la système a terminé un long processus (>10 secondes), ainsi l'utilisateur saura qu'il peut continuer son trvail
- Détecter les cliques multiples sur un bouton et n'en retenir qu'un. À cause de la lenteur de certains processus ou de l'internet les utilisateurs on tendance à cliquer plusieurs fois le même bouton croyant qu'ils n'ont pas déclenché l'action voulue.
[edit] Facilité d'apprentissage
Tout système possède une courbe d'apprentissage « practice makes perfet » : plus on répète une tâche plus on arrive à la faire vite et bien. La courbe d'apprentissage représente l'efficacité obtenue après un nombre x de répétitions. La pente de la courbe indique la vitesse d'apprentissage, plus elle est grande plus les progrès sont rapides. Il est clair qu'au bout d'un certain temps la courbe s'aplatit et qu'on ne fait plus guère de progrès. La figure ci-dessous montre des courbes d'apprentissage de différents systèmes (en vert le plus facile à apprendre, en jaune le plus difficile).
Il faut se souvenir que facilité d'apprentissage et utilisabilité sont orthogonales. L'idéal serait évidemment d'avoir une interface facile à apprendre et très utilisable (grande efficacité de l'utlisateur) mais ce n'est pas toujours possible.
Par exemple, l'écriture d'équations s'apprend vite avec une interface graphique, par contre l'utilisateur ne sera jamais aussi efficace qu'avec un système comme LaTeX qui demande l'apprentissage d'un langage d'écriture d'équations.
En pratique il est bon de fixer une priorité entre facilité d'apprentissage et utilisabilité mais il faut bien sûr viser les deux. La priorité dépend évidemment du contexte d'utilisation et des types d'utilisateurs : ont-ils du temps pour apprendre ou non ? Répéteront-ils la tâche souvent ?
L'introduction de raccourcis clavier pour les experts s'inscrit dans cette logique : l'interface est conçue pour être utilisable par un débutant, à l'aide de menus et de guides. L'experts pourra être plus efficace en utilisant des raccourcis, qui nécessitent en contrepartie un effort de mémorisation.
[edit] Lisibilité
Les textes à lire (par opposition aux simples étiquettes) doivent être en noir sur blanc (ou jaune pâle). Les autres combinaisons de couleurs sont plus difficiles à lire (voir Cours ISI - Texte).
Dans les formulaires il faut utiliser de grands caractères pour le texte à entrer, surtout pour les nombres. Les étiquette peuvent être plus petites. Par exemple
[edit] Eviter le jargon du développeur
Il faut absolument parler dans les termes de l'utilisateur (termes métier ou termes généraux) et éviter les termes propres au développement informatique (même s'ils ont l'air d'être plus corrects). Par exemple :
| Remplacer | ... | Par |
| String length | Number of characters | |
| Reboot | Restart | |
| Mouse-up event | Mouse click | |
| User-visible text | Onscreen text | |
| Focus ring | Highlighted area; area ready to accept user input | |
| Dirty document | Document with unsaved changes | |
| Data browser | Scrolling list or multicolumn list |
[edit] ...ou le jargon de l'entreprise
Si l'interface est destinée au grand public il faut éviter d'utiliser un jargon propre à l'entreprise. Par exemple, dans le jargon des Chemins de fer fédéraux on parle de correspondance pour désigner ce qu'on appelle habitiellement un itinéraire.
[edit] Navigation visible
Au cours de l'utilisation de certains systèmes, en particulier les hypertextes, l'utilisateur a l'impression de naviguer d'un point à un autre dans un espace de pages ou de formulaires ou de fenêtres. Dans la plupart des navigateurs Web actuels on ne voit que la page courante, et pas l'espace entre les pages, l'utilisateur doit se construire un modèle mental de sa position : D'où suis-je venu? Où puis-je aller? En rendant la navigation plus visible on peut diminuer cette surcharge cognitive. Pour cela ou peut utiliser différents indicateurs qui présentent
- le contexte de la page courante (liste de pages adjacentes, carte locale, carte globale)
- le chemin parcouru
- la situation de la page dans la hiérarchie (si cette hiérarchie existe)
Un autre technique consiste à donner l'impression que l'utilisateur est fixe et que l'information vient vers lui. Dans ce cas on peut se passer de cartes et l'utilisateur aura un meilleur sentiment d'autonomie et de maîtrise.
