180 lines
7.7 KiB
Plaintext
180 lines
7.7 KiB
Plaintext
Vendredi 13 février 2009
|
|
Cours d'ergonomie
|
|
M. PULLVERMULLER
|
|
|
|
====== Cours ======
|
|
|
|
Plusieurs critères après avoir fait des centaines et des centaines d'IHM : critères de Bastien
|
|
|
|
===== Compatibilité =====
|
|
|
|
Compatibilité entre le logiciel et son utilisateur (pour une cible particulière d'utilisateur)
|
|
|
|
* Adéquation du logiciel vis à vis de son utilisateur
|
|
* de ses habitudes de travail
|
|
* de son contexte (physique et social) de travail (simplifier la vie de l'utilisateur)
|
|
* La logique d'utilisation du système doit correspondre à la logique de l'utilisateur : par exemple des liens raccourcis pour des habitudes qu'on a quand on lance le logiciel
|
|
* Objectif : minimiser le transcodage de la connaissance entre le métier et le logiciel (utiliser le vocabulaire de l'utilisateur)
|
|
* Présenter les informations sous forme utilisable : parler le langage de l'utilisateur
|
|
|
|
===== Guidage =====
|
|
|
|
* Moyens mis en ½uvre pour orienter l'utilisateur et lui permettre de s'orienter :
|
|
* faire connaître l'état du système : quand on commence des billets SNCF, pendant la recherche il faut informer l'utilisateur qu'on est en cours de recherche
|
|
* établir des liens de causalité entre les actions de l'utilisateur et l'état du système
|
|
* Objectif : faciliter l'apprentissage et l'utilisation
|
|
* Deux niveaux de guidage :
|
|
* guidage explicite (on explique des choses à l'utilisateur via un message d'aide ou d'erreur)
|
|
* guidage implicite (on s'arrange pour guider l'utilisateur en agissant sur la présentation et l'organisation des informations)
|
|
|
|
==== Guidage par l'incitation (implicite) ====
|
|
|
|
Amener l'utilisateur à mener des actions spécifiques :
|
|
* Griser les commandes non disponibles
|
|
* Donner le format de saisie des données (explicite)
|
|
* Compléter les saisies partielles non ambiguës (exemple : Ja -> Janvier)
|
|
* Fournir une liste des saisies attendues (liste de sélection par exemple)
|
|
* établir des liens explicites entre les différentes valeurs à saisir
|
|
|
|
==== Guidage par groupement/distinction ====
|
|
|
|
* Par le format : distinguer visuellement les informations de types différents
|
|
* Par la position : rapprocher les commandes de même type (Functional chunking)
|
|
|
|
NB : Ordre d'utilisation par la fréquence de l'utilisation ou l'importance de l'utilisation !!!
|
|
|
|
==== Guidage : lisibilité ====
|
|
|
|
* Les minuscules sont moins discriminantes que les majuscules => dans une page Web il ne faut pas écrire en majuscule, sauf quand c'est indiqué de le faire !
|
|
|
|
==== Lisibilité et typographie ====
|
|
|
|
* Choisir une taille correcte : mini 8points, maxi 16 points
|
|
* Police de caractère en fonction des critères de lisibilité : une police de caractère à empattement prend plus de place qu'une police sans
|
|
* éviter plus de 3 polices de caractères différentes dans une même fenêtre (ou sur plusieurs fenêtres affichées simultanément)
|
|
|
|
Attention, très contextuel à l'applicatif.
|
|
|
|
===== Homogénéité =====
|
|
|
|
* La logique d'utilisation du système doit être constante, tant au niveau des procédures que de la représentation
|
|
* Graphsime, localisation, vocabulaire, etc.
|
|
* Homogénéité syntaxique des items de menu (courts de préférence)
|
|
|
|
Les trois petits points indiquent à l'utilisateur qu'il y aura une confirmation ou l'ouverture d'une nouvelle fenêtre.
|
|
|
|
===== Fléxibilité =====
|
|
|
|
Souplesse, flexibilité = Capacité de l'IHM à s'adapter à une population variée d'utilisateur :
|
|
* différents types d'utilisateurs
|
|
* différentes stratégies d'utilisation
|
|
|
|
Donner tout les moyens/procédures possibles pour atteindre le même objectif mais de façon différente.
|
|
|
|
Objectif : L'utilisateur choisit la procédure qui lui convient le mieux
|
|
|
|
Exemple:
|
|
* accès par menu, pour les débutants
|
|
* par raccourcis clavier (experts)
|
|
* Défauts utilisateur / Paramètrage => avec les macros on peut automatiser une tâche, ce qui assure une rapidité optimale !
|
|
|
|
===== Contrôle explicite =====
|
|
|
|
* Moyens pour permettre à l'utilisateur de maîtriser/contrôler les traitements réalisés par le système
|
|
* Les effets d'une commande doivent être prévisibles aux yeux de l'usager
|
|
* Objectifs : Meilleure compréhension du système (modèle mental exact)
|
|
* Facteur important d'acceptation du système
|
|
* Ex :
|
|
* Valider explicitement les commandes importantes ou difficilement réversibles
|
|
* Autoriser les interruptions
|
|
|
|
----
|
|
|
|
7 mai et 15 Mai TD
|
|
|
|
22 mai TP : présentation de notre première charte graphique
|
|
28 mai TP : pour seconde présentation
|
|
|
|
Mi - juin rendre la charte d'ergo, la charte graphique et quelques captures d'écran, une ou deux pages HTML de nos écrans montés
|
|
|
|
----
|
|
|
|
==== Actions explicites ====
|
|
|
|
Le système ne doit exécuter que des opérations demandées par l'utilisateur
|
|
|
|
Ex : action physique de validation, bouton ok ou clic.
|
|
|
|
===== Les erreurs =====
|
|
|
|
* Prévoir que l'utilisateur fera des erreurs
|
|
* Concevoir des moyens de pallier ce problème
|
|
* On doit pouvoir :
|
|
* protéger l'utilisateur contre des erreurs : détection de la part du système (saisie des dates, décimaux)
|
|
* l'avertir losqu'il a commis une erreur que l'on peut détecter
|
|
* corriger ou l'aider à corriger ses erreurs : guider l'utilisateur (étapes à suivre pour rectifier l'erreur)
|
|
* Minimiser le risque d'erreur améliore l'utilisabilité du système car les erreurs :
|
|
* rallongent le temps de réalisation de la tâche
|
|
* perturbent la planification
|
|
* diminuent la performance
|
|
* Prévenir des erreurs par une analyse des causes
|
|
|
|
Ne pas disperser l'utilisateur dans son objectif métier.
|
|
|
|
On doit toujours caller un libellé à gauche (plus simple à parcourir pour faire une recherche dans un écran).
|
|
|
|
==== Prévention ====
|
|
|
|
* Rendre clairement visible les changements de mode et les états du système
|
|
* éviter les erreurs cognitives (exemple : raccourcis clavier A, B, C, D pour Create, Delete, Append, Backup => il aurait fallu attacher Backup à B, etc.)
|
|
* éviter les incohérences
|
|
* Mettre en jeu la reconnaissance plutôt que le souvenir :
|
|
* Reconnaissance : choisir parmi plusieurs possibilités
|
|
* Souvenir : Se rappeler de la valeur à saisir
|
|
* La reconnaissance est moins sujette à l'erreur (exemple : utilisation des menus, listes)
|
|
* Erreurs motrices
|
|
* mouvements difficiles : F1, puis F12 : déplacement de la main d'un bout à l'autre du clavier
|
|
* contraintes temporelles
|
|
* faciliter le mouvement de la main
|
|
* augmenter la taille des objets sélectionnés
|
|
* Minimiser l'utilisaterion des modifieurs (Ctrl Alt Shift)
|
|
* Agrandir la taille des objets à sélectionner (éventuellement "au survol")
|
|
|
|
==== Comment gérer les erreurs ? ====
|
|
|
|
2 niveaux de protection contre les erreurs : prévention et détection (par correction)
|
|
|
|
Prévenir des erreurs en guidant l'utilisateur (Guidage/incitation) :
|
|
* Griser les commandes non disponibles
|
|
* Fournir la liste des valeurs possibles
|
|
* Indiquer les modes de fonctionnement du systèmes (feed-back)
|
|
|
|
Détecter les erreurs au plus tôt.
|
|
|
|
Faciliter la correction des erreurs :
|
|
* Message d'erreur pertinent :
|
|
* Nature de l'erreur
|
|
* Moyens de la corriger
|
|
* Rendre possible la correction
|
|
* accès et modification partielle => ne pas "scroller pour arriver à l'erreur"
|
|
|
|
Messages :
|
|
* mettre en évidence le champ erroné
|
|
* placer le message d'erreur là où l'utilisateur est sensé regarder
|
|
* Messages d'erreurs explicits, brefs, non réprobateurs et auto - suffisants
|
|
|
|
Correction de l'erreur :
|
|
* Retour en arrière ("Undo") avec Ctrl + Z
|
|
|
|
Rendre le message d'erreur **instructif**
|
|
|
|
Les messages doivent énoncer :
|
|
* quelle erreur a été détecté
|
|
* quel champ de saisie contient l'erreur
|
|
* quelle action correctrice doit être effectuée
|
|
|
|
===== Charte mentale =====
|
|
|
|
|
|
|