256 lines
12 KiB
Plaintext
256 lines
12 KiB
Plaintext
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 !
|
|
|
|
|