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

A62/Cours2

@@ -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 !
+
+