Test d'ajout de TOUT mes fichiers (moins ceux mis en git reset HEAD à cause de l'histoire des trailings machins choses)
Cf: http://www.agavemountain.com/2008/01/git-tralining-whitespace-error-during.html
This commit is contained in:
Olivier DOSSMANN
123
A62/Cours1
Normal file
123
A62/Cours1
Normal file
@ -0,0 +1,123 @@
|
||||
A62, Jeudi 13 mars 2007
|
||||
|
||||
pulvermuller@dept-info.u-strasbg.fr\\
|
||||
2 cours\\
|
||||
ULP et Caisse d'épargne\\
|
||||
|
||||
====== L'ergonomie et I.C.H.M ======
|
||||
|
||||
Plutôt méthodologique que applicatif
|
||||
|
||||
ICHM = Interface de Communication entre l'Homme et la Machine
|
||||
|
||||
On l'étudie pour éviter de générer des erreurs => Charte d'ergonomie
|
||||
|
||||
But : Capter l'intérêt des utilisateurs et rendre efficace
|
||||
|
||||
Lors de la conception on ne peut ps penser à tout : il faut tester.
|
||||
|
||||
Feedback utilisateur : progression de la tâche
|
||||
|
||||
Adopter les logiciels à l'utilisateur maître
|
||||
|
||||
Principe essentiel : le guidage de l'utilisateur. Ex : campagne d'annonces Google
|
||||
|
||||
Penser aux exemples ou aux aides contextuelles.
|
||||
|
||||
Exemple :
|
||||
* Trame avec visibilité sur le panneau d'affichage
|
||||
* Compte d'étudiant avec plusieurs numéros
|
||||
|
||||
Caisse d'épargne : poste de travail avec 250 applications
|
||||
|
||||
Style ou bouton défini : utiliser toujours le même => lecture iconographique
|
||||
|
||||
Architecture d'imformation : on les découpe en petits morceaux pour les rendre assez compréhensibles et ordonnés
|
||||
|
||||
Pertinence de l'information. Ex : Carte d'accès au site.
|
||||
|
||||
Actions irréversibles => prévoir un message de confirmation qui sert à quelque chose !
|
||||
|
||||
===== Définition =====
|
||||
|
||||
L'ergonomie (ou l'étude des facteurs humains) est la discipline scientifique qui vise à la compréhension fondamentale des interactions entres les êtres humains et les autres composants d'un système.
|
||||
|
||||
Spectre de l'oeil humain . 555 : entre vert et jaune (le plus visible possible)
|
||||
|
||||
3 paramètres :
|
||||
* Teinte
|
||||
* Saturation (vers - gris)
|
||||
* Luminosité
|
||||
|
||||
Utiliser un maximum de 5 couleurs (+/- 2)
|
||||
* rouge (orange et jaune)
|
||||
* vert
|
||||
* bleu (violet)
|
||||
|
||||
Ne pas brouiller la lecture
|
||||
|
||||
Couleurs complémentaires :
|
||||
* Rouge - vert
|
||||
* Bleu - orange
|
||||
* Jaune - violet
|
||||
|
||||
Couleurs différentes selon les messages.
|
||||
|
||||
Les couleurs ont une signification différente selon le pays.
|
||||
|
||||
Distances perçues. Plan des couleurs différent. Dans un texte prendre des couleurs proches.
|
||||
|
||||
9% hommes daltoniens à un degré plus ou moins important.\\
|
||||
0,6% des femmes
|
||||
|
||||
Outils pour voir comme des daltoniens
|
||||
|
||||
Ne pas juxtaposer le rouge et le vert
|
||||
|
||||
Le jaune et le bleau sont bien reconnus. Une forte luminosité et saturation va limiter le problème.
|
||||
|
||||
FAIRE IMAGE ICI
|
||||
|
||||
Processus métier : l'utilisation ne doit pas retenir toutes les informations
|
||||
|
||||
Mnème = quantité d'information connue, familière, traitée par la mémoire à court terme et à caractère d'unité
|
||||
|
||||
Expérience de Conrad :
|
||||
* 8 chiffres => 72,6%
|
||||
* précédé de 0 => 37,5 % réussissent
|
||||
|
||||
Dépassement de capacité = on perd tout
|
||||
|
||||
====== Les critères de BASTIEN (1993) ======
|
||||
|
||||
===== Compatibilité =====
|
||||
|
||||
Adéquation du logiciel vis - à - vis de l'utilisation et de sa classe métier :
|
||||
* ses habitudes
|
||||
* son contexte de travail
|
||||
|
||||
La logique d'utilisation du système doit correspondre à la logique de l'utilisateur.
|
||||
|
||||
===== Le guidage =====
|
||||
|
||||
Tout les moyens mis en oeuvre pour lui permettre de s'orienter :
|
||||
* Faire connaître l'état du système
|
||||
* Liens de causalité entre ses actions et l'état du système
|
||||
|
||||
Faciliter l'apprentissage de l'utilisation
|
||||
|
||||
2 niveaux :
|
||||
* Guidage explicite (évènements et aide)
|
||||
* Guidage implicite (présentation et organisation)
|
||||
|
||||
Incitation :
|
||||
* griser les commandes non disponibles
|
||||
* donner le format de saisie des données
|
||||
|
||||
Lisibilité : les minuscules sont plus faciles à lire, -20% de temps. Éviter l'italique (astigmates)
|
||||
|
||||
===== Homogénéité =====
|
||||
|
||||
Zoning des pages (descendre, monter pour chercher l'information)
|
||||
|
||||
Syntaxe des items de menus (faire courts).
|
||||
123
A62/Cours1~
Normal file
123
A62/Cours1~
Normal file
@ -0,0 +1,123 @@
|
||||
A62, Jeudi 13 mars 2007
|
||||
|
||||
pulvermuller@dept-info.u-strasbg.fr
|
||||
2 cours
|
||||
ULP et Caisse d'épargne
|
||||
|
||||
== L'ergonomie et I.C.H.M
|
||||
|
||||
Plutôt méthodologique que applicatif
|
||||
|
||||
ICHM = Interface de Communication entre l'Homme et la Machine
|
||||
|
||||
On l'étudie pour éviter de générer des erreurs => Charte d'ergonomie
|
||||
|
||||
But : Capter l'intérêt des utilisateurs et rendre efficace
|
||||
|
||||
Lors de la conception on ne peut ps penser à tout : il faut tester.
|
||||
|
||||
Feedback utilisateur : progression de la tâche
|
||||
|
||||
Adopter les logiciels à l'utilisateur maître
|
||||
|
||||
Principe essentiel : le guidage de l'utilisateur. Ex : campagne d'annonces Google
|
||||
|
||||
Penser aux exemples ou aux aides contextuelles.
|
||||
|
||||
Exemple :
|
||||
* Trame avec visibilité sur le panneau d'affichage
|
||||
* Compte d'étudiant avec plusieurs numéros
|
||||
|
||||
Caisse d'épargne : poste de travail avec 250 applications
|
||||
|
||||
Style ou bouton défini : utiliser toujours le même => lecture iconographique
|
||||
|
||||
Architecture d'imformation : on les découpe en petits morceaux pour les rendre assez compréhensibles et ordonnés
|
||||
|
||||
Pertinence de l'information. Ex : Carte d'accès au site.
|
||||
|
||||
Actions irréversibles => prévoir un message de confirmation qui sert à quelque chose !
|
||||
|
||||
=== Définition ===
|
||||
|
||||
L'ergonomie (ou l'étude des facteurs humains) est la discipline scientifique qui vise à la compréhension fondamentale des interactions entres les êtres humains et les autres composants d'un système.
|
||||
|
||||
Spectre de l'oeil humain . 555 : entre vert et jaune (le plus visible possible)
|
||||
|
||||
3 paramètres :
|
||||
* Teinte
|
||||
* Saturation (vers - gris)
|
||||
* Luminosité
|
||||
|
||||
Utiliser un maximum de 5 couleurs (+/- 2)
|
||||
* rouge (orange et jaune)
|
||||
* vert
|
||||
* bleu (violet)
|
||||
|
||||
Ne pas brouiller la lecture
|
||||
|
||||
Couleurs complémentaires :
|
||||
* Rouge - vert
|
||||
* Bleu - orange
|
||||
* Jaune - violet
|
||||
|
||||
Couleurs différentes selon les messages.
|
||||
|
||||
Les couleurs ont une signification différente selon le pays.
|
||||
|
||||
Distances perçues. Plan des couleurs différent. Dans un texte prendre des couleurs proches.
|
||||
|
||||
9% hommes daltoniens à un degré plus ou moins important.\\
|
||||
0,6% des femmes
|
||||
|
||||
Outils pour voir comme des daltoniens
|
||||
|
||||
Ne pas juxtaposer le rouge et le vert
|
||||
|
||||
Le jaune et le bleau sont bien reconnus. Une forte luminosité et saturation va limiter le problème.
|
||||
|
||||
FAIRE IMAGE ICI
|
||||
|
||||
Processus métier : l'utilisation ne doit pas retenir toutes les informations
|
||||
|
||||
Mnème = quantité d'information connue, familière, traitée par la mémoire à court terme et à caractère d'unité
|
||||
|
||||
Expérience de Conrad :
|
||||
* 8 chiffres => 72,6%
|
||||
* précédé de 0 => 37,5 % réussissent
|
||||
|
||||
Dépassement de capacité = on perd tout
|
||||
|
||||
== Les critères de BASTIEN (1993) ==
|
||||
|
||||
=== Compatibilité ===
|
||||
|
||||
Adéquation du logiciel vis - à - vis de l'utilisation et de sa classe métier :
|
||||
* ses habitudes
|
||||
* son contexte de travail
|
||||
|
||||
La logique d'utilisation du système doit correspondre à la logique de l'utilisateur.
|
||||
|
||||
=== Le guidage ===
|
||||
|
||||
Tout les moyens mis en oeuvre pour lui permettre de s'orienter :
|
||||
* Faire connaître l'état du système
|
||||
* Liens de causalité entre ses actions et l'état du système
|
||||
|
||||
Faciliter l'apprentissage de l'utilisation
|
||||
|
||||
2 niveaux :
|
||||
* Guidage explicite (évènements et aide)
|
||||
* Guidage implicite (présentation et organisation)
|
||||
|
||||
Incitation :
|
||||
* griser les commandes non disponibles
|
||||
* donner le format de saisie des données
|
||||
|
||||
Lisibilité : les minuscules sont plus faciles à lire, -20% de temps. Éviter l'italique (astigmates)
|
||||
|
||||
=== Homogénéité ===
|
||||
|
||||
Zoning des pages (descendre, monter pour chercher l'information)
|
||||
|
||||
Syntaxe des items de menus (faire courts).
|
||||
255
A62/Cours2
Normal file
255
A62/Cours2
Normal file
@ -0,0 +1,255 @@
|
||||
A62, 27 mars 2008
|
||||
|
||||
Pour le 9 mai 2008 :
|
||||
* Charte graphique (PDF) => pas de PDF de plus de 10Mo !
|
||||
* Charte ergo (PDF)
|
||||
* 3 copies d'écrans (PNG)
|
||||
|
||||
A la boîte aux lettres pulvermuller@dept-info.u-strasbg.fr
|
||||
|
||||
OBJET : LPRO-Acrobatt Groupe ???
|
||||
CORPS : Noms des membres
|
||||
FICHIERS : Groupe5-CharteGrap ou Groupe5-CharteErgo, etc.
|
||||
|
||||
Il faut penser à faire une version papier, et à la fin de la réalisation, le professeur doit pouvoir jouer sur l'interface
|
||||
|
||||
====== SUITE CRITERES DE BASTIEN ======
|
||||
|
||||
===== Flexibilité =====
|
||||
|
||||
Application de meilleure ergonomie
|
||||
|
||||
* Flexibilité = Capacité de notre application, de nos interfaces à s'adapter à une population très variées d'utilisateurs
|
||||
* différents types d'utilisateurs
|
||||
* différentes stratégies d'utilisation
|
||||
* Procédures / Moyens différents pour atteindre le même objectif
|
||||
* Objectif : l'utilisateur choisit la procédure qui lui convient le mieux
|
||||
* Ex :
|
||||
* Accès par menu (débutants)
|
||||
* Par raccourcis clavier (experts)
|
||||
* Défauts utilisateur / Paramétrage
|
||||
|
||||
Paramétrage forcé : permettre à l'utilisateur __d'attribuer__ des raccourcis claviers à chacune des fonctions de l'application
|
||||
|
||||
Paramétrage possible : ensemble de fonctionnalités nommées MACRO !
|
||||
|
||||
Pour une population hétérogène, la flexibilité est TRES importante !
|
||||
|
||||
===== 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 yeus de l'usager
|
||||
* Objectif : 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.
|
||||
* Sur un bouton, un menu, du texte, une icône, quand il y a trois petits points on sait d'avance qu'il y aura une boîte de dialogue !
|
||||
* Autoriser les interruptions
|
||||
* L'utilisateur doit toujours garder le contrôle des traitements en cours
|
||||
* Ex :
|
||||
* Prévoir des possibilités d'interruption
|
||||
* Autoriser les retours en arrière
|
||||
* Le rythme de saisie ne doit pas être imposé par le système
|
||||
* Laisser l'utilisateur choisir ses unités de mesures
|
||||
|
||||
===== Les erreurs =====
|
||||
|
||||
* Sort l'utilisateur de son processus métier
|
||||
* Fait perdre du temps, rallonge la tâche
|
||||
|
||||
Gestion des 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 les erreurs : détection de la part du système (saisie dates, décimaux)
|
||||
* l'avertir lorsqu'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
|
||||
|
||||
==== Erreurs perceptives ====
|
||||
|
||||
Ne pas faire la différence entre un i majuscule et un L minuscule => génère des erreurs
|
||||
|
||||
Solution : prendre une police de caractère avec empattement
|
||||
|
||||
* Rendre clairement visible les changements de mode et les états du système
|
||||
* etc.
|
||||
==== Erreurs cognitives ====
|
||||
|
||||
Dues à une réflexion ou une conclusion qui n'est pas bonne.
|
||||
|
||||
Ex: confision entre raccourcis et actions
|
||||
A. Create
|
||||
B. Delete
|
||||
C. Append
|
||||
D. Backup
|
||||
|
||||
Soluton :
|
||||
* Mettre en jeu la reconnaissance plus que le souvenir
|
||||
* Reconnaissance : choisir parmi plusieurs possibilités
|
||||
* Souvenir : Se rappeler de la valeur à saisir
|
||||
* La reconnaissance est moins sujette à l'erreur
|
||||
* Ex. Utilisation de menus, listes
|
||||
|
||||
==== Erreurs motrices ====
|
||||
|
||||
* Mouvements difficiles
|
||||
* F1 puis F12 : Déplacement de la main d'un bout à l'autre du clavier
|
||||
* Interaction "clavier, souris puis clavier"
|
||||
* Contraintes temporelles
|
||||
* Précisions sur [...]
|
||||
|
||||
Solutions:
|
||||
* Pas d'élément trop petit sur l'écran
|
||||
|
||||
|
||||
===== Comment gérer les erreurs ? =====
|
||||
|
||||
* 2 niveaux de protection : Prévention et Détection
|
||||
* Prévenir des erreurs en guidant l'utilisateur ("Guidage/ Incitation")
|
||||
* Détecter les erreurs au plus tôt => griser les boutons
|
||||
* 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
|
||||
* Messages
|
||||
* Mettre en évidence le champ erroné
|
||||
* Placer le message d'erreur là où l'utilisateur est sensé regarder => exemple messages d'erreurs à CÔTÉ des erreurs (pour éviter le "scrolling").
|
||||
* Messages d'erreur explicites, brefs, non réprobateurs et auto - suffisants
|
||||
* Correction de l'erreur
|
||||
* Retour en arrière ("Undo")
|
||||
* Autoriser les interruptions pour les commandes longues
|
||||
* Permettre une modification partielle
|
||||
|
||||
==== Les messages d'erreurs ====
|
||||
|
||||
* Rendre le message d'erreur **instructif**
|
||||
* Les messages d'erreurs doivent toujours énoncer au moins
|
||||
* Quelle erreur a été détectée ?
|
||||
* Quel champ de saisie contient l'erreur ?
|
||||
* Quelle action correctrice doit être effectuée ?
|
||||
|
||||
Préférer :
|
||||
Le vol doit comporter la date AAAA/MM/JJ puis être suivi du code de l'aéroport XXX
|
||||
et
|
||||
Saisie: 20030515TOU
|
||||
|
||||
Préférer encore :
|
||||
Le vol doit....
|
||||
Ex : Vol du 15 avril 2003, Destination TOULON
|
||||
Saisie : 20030515TOU
|
||||
|
||||
Et encore:
|
||||
Le même message, mais avec des couleurs
|
||||
|
||||
===== Charge mentale =====
|
||||
|
||||
Globalement, sachant que nous ne sommes pas vraiment fourni en terme de mémorisation dans la mémoire immédiate, il ne faut pas demander à l'utilisateur de retenir quoi que ce soit.\\
|
||||
Il ne doit pas le faire à notre place !
|
||||
|
||||
Eviter les textes trop verbeux, etc ...
|
||||
|
||||
|
||||
===== GIU : Guide de l'Interface Utilisateur =====
|
||||
|
||||
Pas de rendu ou de look, pas d'image, mais on définit __les principes d'ergonomie__.
|
||||
|
||||
Comment faire pour demander à 5 développeurs pour qu'ils soient d'accord sur une forme d'action, les principes d'ergonomies, etc ...
|
||||
|
||||
Charte ergonomique = Liste de directives expliquant au concepteur comment concevoir un écran (menu à gauche, si en haut = fonctions transversales, si on a un fil d'ariane, etc.)\\
|
||||
Contient beaucoup de chapitres
|
||||
|
||||
Formats utilisés :
|
||||
* Disposition des éléments dans une IHM
|
||||
* Aligner les libellés (calés à gauche, espace, double point, puis champ de saisie, et finalement précision sur format attendu) => à utiliser le plus souvent possible
|
||||
* Calés à droite SI les libellés n'ont pas la même taille => Cas particulier
|
||||
* Disposition possible : en ligne, de haut en bas, libellé, puis champ de réponse, à nouveau libellé, champ, etc. => Colonne de navigation
|
||||
* Les saisies libres
|
||||
* Initialiser les champs de saisie (quand possible)
|
||||
* Valeur avec la plus grande probabilité d'être choisie
|
||||
* Valeur précédemment choisie
|
||||
* Différencier ce qui est obligatoire / facultatif => ce qui est aujourd'hui utilisé : Libellé du champ, double point, étoile rouge, puis champ de saisie => A METTRE DANS LA CHARTE D'ERGONOMIE
|
||||
* Les saisies à nombre limité d'options
|
||||
* Les radio-button => définir des règles (à partir de combien de choix faisons nous un menu déroulant ?)
|
||||
* Les cases à cocher
|
||||
* Les tableaux de données (et les listes)
|
||||
* Attribuer un titre aux listes
|
||||
* Respecter les alignements standards des traitements de texte :
|
||||
* Le texte en général à gauche
|
||||
* Les numériques à droite (attention aux décimales)
|
||||
* Éviter les alignements centrés (effets de vagues verticales)
|
||||
* Les menus
|
||||
* utiliser si possible un seul mot
|
||||
* Les couleurs
|
||||
* Dans la charte d'ergonomie dire : tout les champs qui sont en erreurs sont de fond rouge, focus par défaut, libellé d'erreur dessous (principe d'ergonomie, rouge = alerte), mais pas donner la couleur RGB (ça c'est charte graphique !)
|
||||
|
||||
__NB__ : La charte graphique est en deux :
|
||||
* D'une part la CSS (avec des RGB, etc ...)
|
||||
* D'autre part (et en premier lieu), la charte graphique elle même , avec, par exemple : input_error, input_error_border et input_error_msg
|
||||
|
||||
==== Navigation inductive ====
|
||||
|
||||
Dans charte d'ergonomie on doit définir la navigation intra - fenêtre :
|
||||
* Ex : "On préconise un maximum de cet onglet"
|
||||
* On peut mettre des onglets sur plusieurs niveaux, mais c'est pas bon (2 niveaux oui, 3 trop !!)
|
||||
* Bouton OK et ANNULER sont par exemple pour l'ensemble des onglets, et non pas pour un onglet en particulier
|
||||
* Un onglet est presque égal à un écran
|
||||
|
||||
* Les processus par étapes permettent d'effectuer dans un ordre prédéfini une activité complexe
|
||||
* Processus de type assisté "Wizard"
|
||||
* Nombre d'étapes : 4 à 6 selon les cas
|
||||
* Nom des étapes en haut et endroit où nous nous trouvons
|
||||
* Concentré de l'étape au milieu
|
||||
* En bas on peut aller à l'étape suivante ou précédente
|
||||
*
|
||||
|
||||
__NB__ : Dans la charte ergonomique, procéder par boîte "fil de fer" (des carrés grossiers) et donner un peu le principe de chaque boîte, etc ...
|
||||
|
||||
==== Navigation multi-fenêtrage ====
|
||||
|
||||
Une fenêtre appelle une autre fenêtre qui appelle une autre fenêtre, etc. => Profondeur de la navigation => doit être limité à 3 niveaux !!!
|
||||
|
||||
==== Aides à la navigation ====
|
||||
|
||||
* Lorsque la navigation est complexe, la mémoire à court terme est rapidement saturée (nombreux choix)
|
||||
* L'utilisateur a des difficultés à savoir où il est et par où il est passé
|
||||
* Fournir des moyens de guidage pour éviter à l'utilisateur de se "perdre"
|
||||
|
||||
====== Démonstration Caisse d'épargne ======
|
||||
|
||||
===== Charte d'ergonomie =====
|
||||
|
||||
Dans la charte d'ergonomie (environ 250 à 300 pages) il faut définir :
|
||||
* Le zoning de notre application => bandeau ici, navigation principale est rétractable, à cet endroit, j'ai une barre d'état, etc.
|
||||
* Définir les différents cas d'agencement des contenus
|
||||
* Conception de la structure
|
||||
* Groupement des rubriques
|
||||
* Ordre des rubriques
|
||||
* Si onglet : décrire avantages, inconvénients, conditions, cas particuliers, onglets versus boutons radios (servent à filtrer une information de nature unique alors que les onglets permettant d'afficher des morceaux d'une donné unique)
|
||||
* Processus à étapes logiques : fonction, usage, typographie, nombres d'étapes, contenu des étapes, étapes dynamiques (quand on dit qu'on prend la même adresse de livraison et de facturation => saisie de l'adresse de facturation est grisé, on saute l'étape), l'utilisateur doit pouvoir revenir sur une étape précédente
|
||||
* Comment se présente et s'architecture un processus à étape
|
||||
* Quand on dépasse 6 étapes : on fait 5/10, et on affiche un fil d'ariane des étapes, et on mets au centre le libellé de l'étape sur laquelle nous sommes
|
||||
* Libellés des boutons d'actions : dire dans quel cas ils sont utilisés, et les formulaires qui pourraient les utiliser => faire un inventaire des boutons qui pourraient répondre à l'ensemble des actions dans 95% des cas
|
||||
* Donner la règle à respecter pour les formulations de boutons :
|
||||
* Verbe à l'infinitif : souscrire
|
||||
* VB à l'INF. + Substantif : ajouter un RIB
|
||||
* Substantif seul : Créer un nouveau rendez vous
|
||||
* Etat des boutons : Normal, Séléctionné, Inactif, Critique (juste dire qu'ils seront différents, pas donner les couleurs)
|
||||
* Les boutons critiques doivent être séparés des autres boutons (définition de grands principes)
|
||||
* Pour les champs de saisie, idem
|
||||
|
||||
===== Charte graphique =====
|
||||
|
||||
FAIRE UNE CSS pour l'aperçu avant impression !
|
||||
|
||||
* On définit un gabaris des couleurs permises !
|
||||
* Explication ce qui va se passer au niveau des CSS (principe qu'on utilise)
|
||||
* Pour chaque élément, donner : rangée impaire, tr.impair et pas les couleurs pour chaque truc ! Il faut donner les noms à utiliser ! Toute façon le "dessinateur" Web passera derrière !
|
||||
|
||||
Document PowerPoint, avec le nom des classes qui ciblent sur des éléments d'une image PNG (photoshop ou autre).
|
||||
|
||||
Faire un index visuel : le nom du style qui prend la forme du style !
|
||||
|
||||
|
||||
255
A62/Cours2~
Normal file
255
A62/Cours2~
Normal file
@ -0,0 +1,255 @@
|
||||
A62, 27 mars 2008
|
||||
|
||||
Pour le 9 mai 2008 :
|
||||
* Charte graphique (PDF) => pas de PDF de plus de 10Mo !
|
||||
* Charte ergo (PDF)
|
||||
* 3 copies d'écrans (PNG)
|
||||
|
||||
A la boîte aux lettres pulvermuller@dept-info.u-strasbg.fr
|
||||
|
||||
OBJET : LPRO-Acrobatt Groupe ???
|
||||
CORPS : Noms des membres
|
||||
FICHIERS : Groupe5-CharteGrap ou Groupe5-CharteErgo, etc.
|
||||
|
||||
Il faut penser à faire une version papier, et à la fin de la réalisation, le professeur doit pouvoir jouer sur l'interface
|
||||
|
||||
== SUITE CRITERES DE BASTIEN ==
|
||||
|
||||
=== Flexibilité ===
|
||||
|
||||
Application de meilleure ergonomie
|
||||
|
||||
* Flexibilité = Capacité de notre application, de nos interfaces à s'adapter à une population très variées d'utilisateurs
|
||||
* différents types d'utilisateurs
|
||||
* différentes stratégies d'utilisation
|
||||
* Procédures / Moyens différents pour atteindre le même objectif
|
||||
* Objectif : l'utilisateur choisit la procédure qui lui convient le mieux
|
||||
* Ex :
|
||||
* Accès par menu (débutants)
|
||||
* Par raccourcis clavier (experts)
|
||||
* Défauts utilisateur / Paramétrage
|
||||
|
||||
Paramétrage forcé : permettre à l'utilisateur __d'attribuer__ des raccourcis claviers à chacune des fonctions de l'application
|
||||
|
||||
Paramétrage possible : ensemble de fonctionnalités nommées MACRO !
|
||||
|
||||
Pour une population hétérogène, la flexibilité est TRES importante !
|
||||
|
||||
=== 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 yeus de l'usager
|
||||
* Objectif : 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.
|
||||
* Sur un bouton, un menu, du texte, une icône, quand il y a trois petits points on sait d'avance qu'il y aura une boîte de dialogue !
|
||||
* Autoriser les interruptions
|
||||
* L'utilisateur doit toujours garder le contrôle des traitements en cours
|
||||
* Ex :
|
||||
* Prévoir des possibilités d'interruption
|
||||
* Autoriser les retours en arrière
|
||||
* Le rythme de saisie ne doit pas être imposé par le système
|
||||
* Laisser l'utilisateur choisir ses unités de mesures
|
||||
|
||||
=== Les erreurs ==
|
||||
|
||||
* Sort l'utilisateur de son processus métier
|
||||
* Fait perdre du temps, rallonge la tâche
|
||||
|
||||
Gestion des 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 les erreurs : détection de la part du système (saisie dates, décimaux)
|
||||
* l'avertir lorsqu'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
|
||||
|
||||
==== Erreurs perceptives ====
|
||||
|
||||
Ne pas faire la différence entre un i majuscule et un L minuscule => génère des erreurs
|
||||
|
||||
Solution : prendre une police de caractère avec empattement
|
||||
|
||||
* Rendre clairement visible les changements de mode et les états du système
|
||||
* etc.
|
||||
==== Erreurs cognitives ====
|
||||
|
||||
Dues à une réflexion ou une conclusion qui n'est pas bonne.
|
||||
|
||||
Ex: confision entre raccourcis et actions
|
||||
A. Create
|
||||
B. Delete
|
||||
C. Append
|
||||
D. Backup
|
||||
|
||||
Soluton :
|
||||
* Mettre en jeu la reconnaissance plus que le souvenir
|
||||
* Reconnaissance : choisir parmi plusieurs possibilités
|
||||
* Souvenir : Se rappeler de la valeur à saisir
|
||||
* La reconnaissance est moins sujette à l'erreur
|
||||
* Ex. Utilisation de menus, listes
|
||||
|
||||
==== Erreurs motrices ====
|
||||
|
||||
* Mouvements difficiles
|
||||
* F1 puis F12 : Déplacement de la main d'un bout à l'autre du clavier
|
||||
* Interaction "clavier, souris puis clavier"
|
||||
* Contraintes temporelles
|
||||
* Précisions sur [...]
|
||||
|
||||
Solutions:
|
||||
* Pas d'élément trop petit sur l'écran
|
||||
|
||||
|
||||
=== Comment gérer les erreurs ? ===
|
||||
|
||||
* 2 niveaux de protection : Prévention et Détection
|
||||
* Prévenir des erreurs en guidant l'utilisateur ("Guidage/ Incitation")
|
||||
* Détecter les erreurs au plus tôt => griser les boutons
|
||||
* 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
|
||||
* Messages
|
||||
* Mettre en évidence le champ erroné
|
||||
* Placer le message d'erreur là où l'utilisateur est sensé regarder => exemple messages d'erreurs à CÔTÉ des erreurs (pour éviter le "scrolling").
|
||||
* Messages d'erreur explicites, brefs, non réprobateurs et auto - suffisants
|
||||
* Correction de l'erreur
|
||||
* Retour en arrière ("Undo")
|
||||
* Autoriser les interruptions pour les commandes longues
|
||||
* Permettre une modification partielle
|
||||
|
||||
==== Les messages d'erreurs ====
|
||||
|
||||
* Rendre le message d'erreur **instructif**
|
||||
* Les messages d'erreurs doivent toujours énoncer au moins
|
||||
* Quelle erreur a été détectée ?
|
||||
* Quel champ de saisie contient l'erreur ?
|
||||
* Quelle action correctrice doit être effectuée ?
|
||||
|
||||
Préférer :
|
||||
Le vol doit comporter la date AAAA/MM/JJ puis être suivi du code de l'aéroport XXX
|
||||
et
|
||||
Saisie: 20030515TOU
|
||||
|
||||
Préférer encore :
|
||||
Le vol doit....
|
||||
Ex : Vol du 15 avril 2003, Destination TOULON
|
||||
Saisie : 20030515TOU
|
||||
|
||||
Et encore:
|
||||
Le même message, mais avec des couleurs
|
||||
|
||||
=== Charge mentale ===
|
||||
|
||||
Globalement, sachant que nous ne sommes pas vraiment fourni en terme de mémorisation dans la mémoire immédiate, il ne faut pas demander à l'utilisateur de retenir quoi que ce soit.\\
|
||||
Il ne doit pas le faire à notre place !
|
||||
|
||||
Eviter les textes trop verbeux, etc ...
|
||||
|
||||
|
||||
=== GIU : Guide de l'Interface Utilisateur ===
|
||||
|
||||
Pas de rendu ou de look, pas d'image, mais on définit __les principes d'ergonomie__.
|
||||
|
||||
Comment faire pour demander à 5 développeurs pour qu'ils soient d'accord sur une forme d'action, les principes d'ergonomies, etc ...
|
||||
|
||||
Charte ergonomique = Liste de directives expliquant au concepteur comment concevoir un écran (menu à gauche, si en haut = fonctions transversales, si on a un fil d'ariane, etc.)\\
|
||||
Contient beaucoup de chapitres
|
||||
|
||||
Formats utilisés :
|
||||
* Disposition des éléments dans une IHM
|
||||
* Aligner les libellés (calés à gauche, espace, double point, puis champ de saisie, et finalement précision sur format attendu) => à utiliser le plus souvent possible
|
||||
* Calés à droite SI les libellés n'ont pas la même taille => Cas particulier
|
||||
* Disposition possible : en ligne, de haut en bas, libellé, puis champ de réponse, à nouveau libellé, champ, etc. => Colonne de navigation
|
||||
* Les saisies libres
|
||||
* Initialiser les champs de saisie (quand possible)
|
||||
* Valeur avec la plus grande probabilité d'être choisie
|
||||
* Valeur précédemment choisie
|
||||
* Différencier ce qui est obligatoire / facultatif => ce qui est aujourd'hui utilisé : Libellé du champ, double point, étoile rouge, puis champ de saisie => A METTRE DANS LA CHARTE D'ERGONOMIE
|
||||
* Les saisies à nombre limité d'options
|
||||
* Les radio-button => définir des règles (à partir de combien de choix faisons nous un menu déroulant ?)
|
||||
* Les cases à cocher
|
||||
* Les tableaux de données (et les listes)
|
||||
* Attribuer un titre aux listes
|
||||
* Respecter les alignements standards des traitements de texte :
|
||||
* Le texte en général à gauche
|
||||
* Les numériques à droite (attention aux décimales)
|
||||
* Éviter les alignements centrés (effets de vagues verticales)
|
||||
* Les menus
|
||||
* utiliser si possible un seul mot
|
||||
* Les couleurs
|
||||
* Dans la charte d'ergonomie dire : tout les champs qui sont en erreurs sont de fond rouge, focus par défaut, libellé d'erreur dessous (principe d'ergonomie, rouge = alerte), mais pas donner la couleur RGB (ça c'est charte graphique !)
|
||||
|
||||
__NB__ : La charte graphique est en deux :
|
||||
* D'une part la CSS (avec des RGB, etc ...)
|
||||
* D'autre part (et en premier lieu), la charte graphique elle même , avec, par exemple : input_error, input_error_border et input_error_msg
|
||||
|
||||
==== Navigation inductive ====
|
||||
|
||||
Dans charte d'ergonomie on doit définir la navigation intra - fenêtre :
|
||||
* Ex : "On préconise un maximum de cet onglet"
|
||||
* On peut mettre des onglets sur plusieurs niveaux, mais c'est pas bon (2 niveaux oui, 3 trop !!)
|
||||
* Bouton OK et ANNULER sont par exemple pour l'ensemble des onglets, et non pas pour un onglet en particulier
|
||||
* Un onglet est presque égal à un écran
|
||||
|
||||
* Les processus par étapes permettent d'effectuer dans un ordre prédéfini une activité complexe
|
||||
* Processus de type assisté "Wizard"
|
||||
* Nombre d'étapes : 4 à 6 selon les cas
|
||||
* Nom des étapes en haut et endroit où nous nous trouvons
|
||||
* Concentré de l'étape au milieu
|
||||
* En bas on peut aller à l'étape suivante ou précédente
|
||||
*
|
||||
|
||||
__NB__ : Dans la charte ergonomique, procéder par boîte "fil de fer" (des carrés grossiers) et donner un peu le principe de chaque boîte, etc ...
|
||||
|
||||
==== Navigation multi-fenêtrage ====
|
||||
|
||||
Une fenêtre appelle une autre fenêtre qui appelle une autre fenêtre, etc. => Profondeur de la navigation => doit être limité à 3 niveaux !!!
|
||||
|
||||
==== Aides à la navigation ====
|
||||
|
||||
* Lorsque la navigation est complexe, la mémoire à court terme est rapidement saturée (nombreux choix)
|
||||
* L'utilisateur a des difficultés à savoir où il est et par où il est passé
|
||||
* Fournir des moyens de guidage pour éviter à l'utilisateur de se "perdre"
|
||||
|
||||
== Démonstration Caisse d'épargne ==
|
||||
|
||||
=== Charte d'ergonomie ===
|
||||
|
||||
Dans la charte d'ergonomie (environ 250 à 300 pages) il faut définir :
|
||||
* Le zoning de notre application => bandeau ici, navigation principale est rétractable, à cet endroit, j'ai une barre d'état, etc.
|
||||
* Définir les différents cas d'agencement des contenus
|
||||
* Conception de la structure
|
||||
* Groupement des rubriques
|
||||
* Ordre des rubriques
|
||||
* Si onglet : décrire avantages, inconvénients, conditions, cas particuliers, onglets versus boutons radios (servent à filtrer une information de nature unique alors que les onglets permettant d'afficher des morceaux d'une donné unique)
|
||||
* Processus à étapes logiques : fonction, usage, typographie, nombres d'étapes, contenu des étapes, étapes dynamiques (quand on dit qu'on prend la même adresse de livraison et de facturation => saisie de l'adresse de facturation est grisé, on saute l'étape), l'utilisateur doit pouvoir revenir sur une étape précédente
|
||||
* Comment se présente et s'architecture un processus à étape
|
||||
* Quand on dépasse 6 étapes : on fait 5/10, et on affiche un fil d'ariane des étapes, et on mets au centre le libellé de l'étape sur laquelle nous sommes
|
||||
* Libellés des boutons d'actions : dire dans quel cas ils sont utilisés, et les formulaires qui pourraient les utiliser => faire un inventaire des boutons qui pourraient répondre à l'ensemble des actions dans 95% des cas
|
||||
* Donner la règle à respecter pour les formulations de boutons :
|
||||
* Verbe à l'infinitif : souscrire
|
||||
* VB à l'INF. + Substantif : ajouter un RIB
|
||||
* Substantif seul : Créer un nouveau rendez vous
|
||||
* Etat des boutons : Normal, Séléctionné, Inactif, Critique (juste dire qu'ils seront différents, pas donner les couleurs)
|
||||
* Les boutons critiques doivent être séparés des autres boutons (définition de grands principes)
|
||||
* Pour les champs de saisie, idem
|
||||
|
||||
=== Charte graphique ===
|
||||
|
||||
FAIRE UNE CSS pour l'aperçu avant impression !
|
||||
|
||||
* On définit un gabaris des couleurs permises !
|
||||
* Explication ce qui va se passer au niveau des CSS (principe qu'on utilise)
|
||||
* Pour chaque élément, donner : rangée impaire, tr.impair et pas les couleurs pour chaque truc ! Il faut donner les noms à utiliser ! Toute façon le "dessinateur" Web passera derrière !
|
||||
|
||||
Document PowerPoint, avec le nom des classes qui ciblent sur des éléments d'une image PNG (photoshop ou autre).
|
||||
|
||||
Faire un index visuel : le nom du style qui prend la forme du style !
|
||||
|
||||
|
||||
Reference in New Issue
Block a user