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 !