cours0708/A62/Cours2~

256 lines
12 KiB
Plaintext
Raw Normal View History

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 !