cours0708/A62/Cours2~

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 !