Cours ISI - Les principes de Tognazzini - Isiwiki

Stephane

Informations

• Publié par: Endrui
• Nombre de lectures: 155
• Langue: Français

Extrait

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.

Contents

1 Anticipation

2 Exemples

3 Autonomie

4 Visualiation de l'état du système

5 Perception des couleurs

6 Consistance

6.1 Catégories de consistance

6.2 Limites de la consistance

7 Efficacité de l'utilisateur

8 Interface explorable

9 Objets de l'interface

10 Loi de Fitt

11 Réduction de l'impression d'attente

12 Facilité d'apprentissage

13 Lisibilité

14 Eviter le jargon du développeur

14.1 ...ou le jargon de l'entreprise

15 Navigation visible

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

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.

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.

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.

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).

Consistance

Différents niveaux de consistance / par ordre d'importance

actions des utilisateurs (ex. raccourcis clavier)

1.

structures invisibles (les décrire)

2.

petites structures visibles (icones, flèches, ...)

3.

look d'une application

4.

look d'une suite de produits

5.

...

6.

Attention: consistance ne doit pas signifier uniformité

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

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

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

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.

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

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.

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.

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.

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

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

...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

.

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.

Retrieved from "http://cui.unige.ch/isiwiki/index.php/Cours_ISI_-_Les_principes_de_Tognazzini"

This page was last modified 14:48, 3 May 2008.