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 !