AnnexeWeb-SICPA-CharteErgonomique - Forge DGA
publicité
Cati SICPA Systèmes d’Informations et Calcul pour le Phénotypage Animal Annexe WEB à la Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 2/38 Table des matières 1 Glossaire ............................................................................................................................. 4 2 Introduction ........................................................................................................................ 5 2.1 Contexte ....................................................................................................................... 5 2.2 Objectifs ....................................................................................................................... 5 2.2.1 Bonnes pratiques ergonomiques........................................................................... 5 2.2.2 Homogénéisation des interfaces ........................................................................... 5 2.2.3 Standardisation des développements .................................................................... 5 2.2.4 Enrichissement continue ...................................................................................... 5 2.3 3 Périmètre d’application ................................................................................................ 5 Concepts et définitions ....................................................................................................... 7 3.1 3.1.1 Application client/serveur .................................................................................... 7 3.1.2 Application web ................................................................................................... 7 3.1.3 Application mobile ............................................................................................... 7 3.2 4 Différents types d’applications .................................................................................... 7 Approches logicielles ................................................................................................... 7 3.2.1 Approche par fonctionnalité ................................................................................. 7 3.2.2 Approche par objet ............................................................................................... 7 3.2.3 Quelle approche choisir ? ..................................................................................... 7 Recommandations générales .............................................................................................. 8 4.1 Cohérence et homogénéisation .................................................................................... 8 4.2 Les éléments à rendre cohérent .................................................................................... 8 4.3 Charte identitaire Inra .................................................................................................. 8 5 Structure et agencement des écrans .................................................................................... 9 6 Contenus et éléments visuels............................................................................................ 12 7 Fonctionnalités / Actions .................................................................................................. 19 8 Les Messages et les notifications ..................................................................................... 21 9 Les listes ........................................................................................................................... 26 10 Les formulaires ................................................................................................................. 28 10.1 Organisation des informations ................................................................................... 28 10.2 Regrouper les informations selon leur thème............................................................. 28 10.3 Enchainement des zones de saisies ............................................................................ 29 10.4 Les différentes sortes de formulaires ......................................................................... 29 10.4.1 Les formulaires simples ..................................................................................... 29 10.4.2 Les formulaires avec onglets .............................................................................. 32 Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 3/38 10.4.3 Les assistants ...................................................................................................... 32 10.4.4 Les formulaires maître-détail ............................................................................. 33 10.4.5 Les formulaires de saisie en tableau ................................................................... 33 10.5 Positionnement des informations ............................................................................... 33 10.6 Aide à la saisie ........................................................................................................... 34 10.6.1 Liste déroulante .................................................................................................. 34 10.6.2 L’auto-complétion .............................................................................................. 34 10.6.3 Rapatrier une valeur ........................................................................................... 34 10.7 Gestion des erreurs et validation des informations saisies ......................................... 34 10.8 Eléments constituant un formulaire ........................................................................... 35 10.8.1 Le Titre du formulaire ........................................................................................ 35 10.8.2 Les onglets.......................................................................................................... 35 10.8.3 Les groupes de champs ...................................................................................... 35 10.8.4 Les boutons d’actions ......................................................................................... 36 10.9 Les mécanismes d’enregistrement ............................................................................. 36 10.9.1 L’enregistrement du formulaire.......................................................................... 36 10.9.2 La cinématique d’enregistrement ....................................................................... 36 11 Les recherches .................................................................................................................. 37 12 Les éditions ...................................................................................................................... 38 Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 4/38 1 Glossaire CATI CSS GA IHM HTML PHASE SICPA Centre Automatisé de Traitement de l’Information Cascading Style Sheets Langage qui décrit la présentation des documents HTML Génétique Animale Interface Homme Machine Hypertext Markup Language Langage de balisage permettant d’écrire des pages web PHysiologie Animale et Systèmes d’Elevage Systèmes d’Information et Calcul pour le Phénotypage Animal Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 5/38 2 Introduction 2.1 Contexte Le Cati SICPA porte, au sein des départements GA et PHASE, une approche intégrée des données de phénotypage animal, depuis l’acquisition jusqu’au traitement statistique et à la valorisation de ces données. Depuis la création du Cati, les applications développées doivent donc répondre aux besoins à la fois de génétique animale et de physiologie animale. De plus, les interfaces hommes machines devront désormais avoir une cohérence ergonomique et graphique. Une démo est disponible à l’adresse suivante : 147.99.156.182/cati L’archive est disponible à l’adresse suivante : 147.99.156.182/cati.zip 2.2 Objectifs 2.2.1 Bonnes pratiques ergonomiques L’objectif principal de cette charte est de proposer aux développeurs d’application, travaillant au sein du Cati SICPA, les éléments pour mettre en œuvre de bonnes pratiques ergonomiques dans leurs développements, afin d’harmoniser les interfaces. Elle a donc pour objectif de proposer : des façons d’organiser l’information au sein des écrans de l’application des solutions dans la dynamique entre les différents écrans 2.2.2 Homogénéisation des interfaces De nombreux utilisateurs sont amenés à travailler avec plusieurs de nos applications. L’homogénéisation des interfaces leur permet de retrouver les mêmes concepts ergonomiques et graphiques réduisant ainsi l’effort d’apprentissage. L’objectif est aussi d’obtenir des applications avec une identité graphique la plus homogène possible. La cohérence et la simplicité des interfaces permettent de faciliter l’adhésion des utilisateurs. 2.2.3 Standardisation des développements La charge de développement, pour la mise en place d’un système d’informations, peut être relativement importante. La standardisation de la conception d’application permet d’homogénéiser les développements et donc réduire cette charge. Pour chaque application, le temps d’analyse peut ainsi être consacré plus sur la compréhension du fonctionnel que sur le moyen de le mettre en œuvre. 2.2.4 Enrichissement continue La prise en compte des retours, au fur et à mesure de son utilisation par les développeurs, mais aussi par les utilisateurs de nos applications, doit permettre d’enrichir et d’améliorer la charte régulièrement. 2.3 Périmètre d’application Cette charte concerne toutes les applications développées au sein du Cati SICPA. Toutefois, en fonction de leur particularité, des annexes seront rédigées pour détailler plus précisément sa mise en œuvre pour : Les applications client/serveur Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Les applications web Les applications mobiles Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 6/38 Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 7/38 3 Concepts et définitions 3.1 Différents types d’applications 3.1.1 Application client/serveur L’application est installée sur le poste de l’utilisateur ou sur un serveur. Le poste (le client) établie ensuite une connexion directe à la base de données. L’avantage est de bénéficier des interfaces très riches offertes par le système d’exploitation. 3.1.2 Application web L’application n’est pas installée sur le client mais sur un serveur web. Elle est accessible grâce à un navigateur. Les possibilités graphiques et matérielles sont désormais aussi riches qu’en client/serveur grâce aux nouvelles technologies (HTML 5, CSS3, Javascript). 3.1.3 Application mobile L’application installée sur l’appareil mobile doit pouvoir fonctionner en autonome (sans connexion) et avoir accès aux ressources de l’appareil (lecture RFID, Bluetooth, …). L’interface doit être le plus simple possible pour s’adapter aux contraintes de l’appareil (petit écran, clavier numérique uniquement, …). Il faut également prendre en compte l’évolution des applications et supports mobiles (type android). 3.2 Approches logicielles 3.2.1 Approche par fonctionnalité Cette approche donne à l’utilisateur l’accès à des fonctionnalités précises, prédéfinies pour manipuler les objets. 3.2.2 Approche par objet Cette approche donne à l’utilisateur des outils pour manipuler, consulter, trouver des objets dans différents contextes. Il peut ainsi, en partant des objets, enchainer des fonctionnalités simples pour réaliser des opérations complexes. 3.2.3 Quelle approche choisir ? Pour des services ponctuels, l’approche par fonctionnalités peut être choisie car l’utilisateur est occasionnel. Il faut donc lui proposer une interface simple qui le guide dans ses fonctionnalités à réaliser. Pour des applications métiers, l’approche par objet permet à l’utilisateur de manipuler à sa guise les objets sans être guidé par un processus. Une solution pourrait être une répartition intelligente de ces deux approches en fonction des fonctionnalités à traiter par l’utilisateur ; avec un choix vers une orientation objet de préférence tout en proposant un mode fonctionnel quand cela s’avère nécessaire. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 8/38 4 Recommandations générales 4.1 Cohérence et homogénéisation L’objectif majeur est la cohérence et l’homogénéisation de tous les aspects de l’IHM. Il est, en effet, préférable d’avoir une ergonomie perfectible mais cohérente plutôt que des écrans très ergonomiques mais disparates dans leur logique de fonctionnement. 4.2 Les éléments à rendre cohérent La logique applicative : navigation entre les objets, même logique d’enchainement d’opération… Le style de rédaction : utiliser toujours les mêmes tournures de phrases dans les messages, info-bulles, libellés, … La présentation de l’information : construire les formulaires, les listes avec une logique toujours identique Le positionnement des composants : placement du label, du champ de saisie, … Le style graphique : police de caractère, couleur, … Des pictogrammes communs : utiliser les mêmes pictogrammes sur les contextes (ex : messages d’information, d’avertissement, d’interdiction, …). Le plus possible ils devront être choisis dans une bibliothèque d’images commune. 4.3 Charte identitaire Inra Une charte identitaire Inra est disponible sur intranet : https://intranet6.inra.fr/charte-identitaire. Cette charte est essentiellement orientée vers la publication de document. Toutefois, elle pourra guider les annexes sur les parties éditions, police de caractère et présentation globale d’une page web. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 9/38 5 Structure et agencement des écrans 5.1 Structure général En fonction des différents types d’applications, la structure générale de nos applications ne pourra pas se présenter de la même façon. Toutefois, les éléments décrits dans ce paragraphe doivent être le plus possible respectés car la structuration des pages représentent un point fondamental dans la standardisation des interfaces. Dans la mesure du possible, il faudra que la totalité de l’écran soit utilisée pour l’affichage de la page. Cela nécessitera l’utilisation d’une méthode javascript afin de redimensionner les éléments affichés en fonction de la taille de la page. 5.1.1 Schéma / Vue d’ensemble La structure des écrans est constituée de 3 grandes zones horizontales : En-tête Corps Pied de page Le schéma du découpage de l’écran est présent sur chaque annexe. Le découpage se fera suivant la structuration des pages par l’HTML5, à savoir le fonctionnement suivant : - Header o Nav - Section o Article - Footer Afin d’assurer la compatibilité avec les anciennes versions d’IE, le package de compatibilité devra être utilisé sur chacune des pages. Dans la mesure du possible, les tableaux et éléments diffusés sur la page doivent pouvoir s‘intégrer sur la hauteur de la page. En ce sens, un script javascript chargé de calculer en temps réel la hauteur de la fenêtre adaptera la diffusion des éléments en fonction de la taille effective de la fenêtre ouverte. 5.1.2 L’en-tête L’en-tête est la zone haute de l’écran. Elle peut se décomposée en une série d’éléments. L’en-tête doit être unique et présent dans toute l’application. Il doit, à minima, contenir : Un icone ou une image représentant l’application Le nom de l’application Une zone pour le menu principal Un bouton ou un lien pour quitter ou se déconnecter de l’application Attention à la hauteur de l’en-tête. Celui-ci ne doit pas empiéter de manière trop importante sur le corps. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 10/38 Le header contiendra l’en-tête de la page du site, avec le logo INRA, le nom de l’appli, suivi de la barre de menu. Ce header restera en position fixe en haut de la page. Il faudra donc que celui-ci ne soit pas trop imposant pour ne pas gêner la bonne utilisation de l’application. Les balises utilisées seront header et nav. Le logo sera identique à celui présent sur la charte identitaire de l’INRA (p. 7) 5.1.3 Le corps Il occupe verticalement tout l’espace non utilisé par les 2 autres zones. La zone du corps est celle destinée à accueillir le « contenu utile » de l’application. Elle contient les données métier, les formulaires, les listes, … 5.1.3.1 Approche objet Les données sont regroupées en unités fonctionnelles appelées modules. Un module est découpé horizontalement en 3 parties : En haut, un en-tête qui contient une icône, un titre, les boutons de redimensionnement et de fermeture (pas en web), un fil d’Ariane (voir 6.3.3) et une zone de recherche. Au milieu, le contenu qui se découpe verticalement en 2 colonnes : o La colonne de gauche permet de naviguer entre les différents objets en utilisant une organisation arborescente et hiérarchique (lien père – fils). Il sera utilisée une liste déroulante telle que celle spécifiée dans le chapitre 9, avec pour chaque sous-liste la création d’une nouvelle liste imbriquée o La colonne de droite permet d’afficher, sous forme de liste, un contenu plus détaillé des objets. Elle présente la liste des fils de l’objet sélectionné dans la colonne de gauche. Ceci se fera en utilisant la technologie javascript afin de ne pas surcharger l’affichage des pages. En bas, un pied de page qui contient le nombre d’éléments présents dans la liste. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 11/38 5.1.3.2 Approche fonctionnelle En fonction de la fonction appelée, les données pourront se présenter soit sous forme d’une liste, soit sous forme d’un tableau, soit sous forme d’un formulaire de saisie. Se reporter donc aux chapitres correspondants pour les préconisations ergonomiques à respecter. 5.1.4 Le pied de page Le pied de page est situé tout en bas de l’application. Il doit contenir des informations correspondant à l’état de l’application Et doit contenir a minima : Le logo Inra (sur la gauche, il doit être complet afin de respecter les recommandations de la charte identitaire de l’Inra) L’utilisateur connecté La version de l’application ? Il sera mis simplement en place en utilisant la balise footer en HTML5. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 12/38 6 Contenus et éléments visuels 6.1 Contenus textuels L’encodage des caractères doit être l’UTF-8 que ce soit pour l’affichage des données ou des libellés. Chaque annexe préconise précisément les aspects des éléments textuels à homogénéiser dans l’application, à savoir : la police de caractère la taille des caractères la couleur l’alignement et le positionnement du texte Et ceci dans les différents cas d’utilisation (consultation ou modification) et différents types (label ou données). La couleur principalement utilisée sur les applications sera le noir. Certains titres, ainsi que les couleurs de bordures ou de menu devront suivre les recommandations de l’INRA en utilisant la couleur Pantone 377 C (#78a22f). La palette de couleurs privilégiée sera la palette institutionnelle (p.17). de couleur verte. La police de caractère utilisée pour les titres sera « Myriad Pro Condensed » (exemple de texte) et « Minion Pro »(exemple de texte) pour les textes courants, comme stipulé dans la charte identitaire de l’INRA (p.13) 6.2 Autre forme de contenu de données De la même manière que le paragraphe précédent, les aspects à homogénéiser pour les autres formes de contenu de données sont décrits dans les annexes. Cela concerne : Les listes déroulantes cf 10.6.1 Les cases à cocher cf 10.4.1.2 Les radio-boutons cf 10.4.1.4 Les calendriers cf 10.4.1.7 Le spin button Le switch button cf 10.4.1.2 Le slider cf 10.4.1.10 6.3 Autres éléments visuels Dans ce paragraphe, les aspects à homogénéiser concernent : Les boutons Les menus et items de menus Le fil d’Ariane Les icones et les images. Une bibliothèque d’images est accessible depuis la Forge. Elle doit être utilisée en priorité pour le choix des images. Les liens hypertexte La fenêtre de connexion. Cette fenêtre doit être présentée à l’ouverture de l’application. Elle doit contenir le logo de l’application, le nom de l’application, la Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 13/38 version, une zone de saisie de l’identifiant, une zone de saisie du mot de passe et un bouton « Connexion ». La fenêtre « à propos ». Cette fenêtre doit permettre à l’utilisateur de connaitre, a minima, la version de l’application. En plus, de ce numéro de version, le nom et le logo de l’application doivent être présents. 6.3.1 Les menus Il est possible de mettre en place plusieurs types de menus sur les applications. Une bonne pratique serait de mettre des menus qui restent fixes en haut de page, afin d’être en harmonie avec les principales applications lourdes existantes. Cela ne perturberait ainsi pas les habitudes de travail des utilisateurs amenés à switcher entre plusieurs types d’applications. On distingue 2 types de menus : - Les menus texte - Les menus de côté 6.3.1.1 Les menus texte (préconisé) Les menus de type texte fixes en haut de page seront intégrés dans la balise HTML5 « nav ». Chaque élément du menu pourra être situé sur la partie gauche du menu ou sur la partie droite (par exemple pour la gestion du compte utilisateur et la déconnexion). Il faut prendre en compte dans les éléments de menus, ainsi que dans les éléments de sousmenus des séparateurs, afin de bien délimiter les parties. Les icônes doivent également être permis afin de faciliter la visibilité des menus. Possibilité d’autoriser les ombres sous-menus ? Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 14/38 6.3.1.2 Les menus sur le côté Il peut être envisagé d’utiliser des menus sur le côté gauche ou droit des pages. Ceci peut se faire notamment pour les liens en relation avec la page sur laquelle l’utilisateur se situe. Le principe de fonctionnement de ces menus est simple. Il faut mettre en place un élément nav contenant une liste ul. Chaque élément de la liste sera ou non déroulable. La mise en place de ce type de menu se fera en utilisant la technologie CSS3, avec les classes pour définir les items de menu. 6.3.2 Les accordéons Les accordéons doivent pouvoir permettre de cacher des parties de page qui sont utiles seulement par moments aux utilisateurs. Ces accordéons doivent pouvoir contenir du texte, mais également des formulaires, des onglets, des liens, et tout type de balises HTML (tableaux, listes, images, …), ou bien d’autres accordéons. Leur développement se fera en couplant HTML5/CSS et jquery. Une puce peut être mise afin de spécifier l’ouverture ou non d’un élément de l’accordéon. Les titres des éléments de l’accordéon seront situés sur la gauche de l’élément. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 15/38 6.3.3 Les fils d’ariane Le rôle des fils d’ariane est de montrer à l’utilisateur l’endroit où il se situe à l’intérieur de l’application. Ce fil sera développé en utilisant les CSS. Une balise nav permettra de définir le fil d’ariane, le fil sera modélisé par une balise ul et chaque élément de ce fil sera situé à l’intérieur d’une liste li. Il doit être possible de définir plusieurs tailles de fils d’ariane, afin de gérer le grain de détail. Chaque élément sera associé à un lien qui permettra de changer de section sur l’application démarrée. 6.3.4 Les tableaux de données Les tableaux de données seront présentés de telle manière qu’il sera facile pour l’utilisateur d’ajouter/modifier/supprimer un élément. Il faudra également prendre en compte la possibilité de modifier des données directement depuis le tableau, ou gérer la pagination et le nombre d’enregistrements affichés par page. Les en-têtes des tableaux devront pouvoir permettre les tris, et seront situés en haut et en bas des tableaux, afin de permettre une plus grande visibilité. Il peut être envisagé la mise en place d’un scrolling vertical et/ou horizontal. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 16/38 Voici les éléments que devra visualiser l’utilisateur sur une page de tableaux de données : - En-têtes situées en haut et en bas de chaque tableaux (centré, gras, flèche pour tri) - L’aspect bicolor des affichages d’enregistrements - Un champ de recherche en haut à droite du tableau - La possibilité de choisir le nombre d’affichages par page en haut à gauche (par défaut 20) - Le récapitulatif des enregistrements affichés en bas à gauche - La pagination en bas à droite La technologie utilisée ici sera le CSS pour la mise en page, et jquery pour les aspects : - Recherche - Suppression d’un enregistrement - Modification d’un enregistrement Ces aspects incluront du développement en AJAX. Le scrolling au niveau du tableau ne devra prendre en compte que les éléments affichés dans le tableau, sans impacter les en-têtes et pieds de page des tableaux. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 17/38 La modification d’un enregistrement se fera par un double clic sur la cellule à modifier 6.3.5 Les formulaires de connexion Les formulaires de connexion peuvent s’afficher en surimpression de l’écran de l’application. Au clic sur le bouton de connexion (représenté par le cadenas sur le menu (voir 6.1.1), celui-ci s’affichera au centre de l’écran dans une fenêtre gérée en javascript/jquery Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 18/38 Lors de la déconnexion, toujours en cliquant sur le même bouton cadenas, une popup s’affichera au centre de l’écran, avec un effet ombre sur le reste de la page, informant l’utilisateur qu’il est déconnecté. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 19/38 7 Fonctionnalités / Actions Les fonctionnalités ou actions présentes dans une application sont de 2 types : Actions de navigation o Elles permettent à l’utilisateur d’atteindre un écran, un module, une liste, un formulaire, … o Elles peuvent aussi renvoyer l’utilisateur vers une autre application (lien hypertexte en Web). Actions de réalisation d’un traitement o Traitements standards (enregistrer, ajouter, supprimer, imprimer, …) o Traitement spécifiques, liés à un besoin métier (valider un dossier, calculer un taux, …) Les icônes ou boutons représentants les actions de traitements standards devront toujours être les mêmes (même logo ou même libellé). De plus, ils ne doivent pas être utilisés pour lancer un autre type d’action. Le positionnement de ces icônes ou boutons doit être cohérent et respecter toujours la même logique. Pour un traitement, le texte doit contenir au moins un verbe comme libellé (ex : « imprimer le dossier » plutôt que « impression du dossier »). Ces fonctionnalités ou actions peuvent être présentes dans les items de menu, les listes et les formulaires. 7.1 Les actions dans les listes Il existe plusieurs possibilités, pour lancer une action sur un élément de la liste : Un lien sur le texte de la colonne identifiant l’élément. Ce lien servira pour accéder aux propriétés de l’élément (formulaire de saisie). Un menu contextuel sur l’élément. Une action de liste, représenté par des boutons d’action situés dans le pied de page de la liste. Une action de ligne, représentée par un bouton ou un lien directement depuis les dernières colonnes de chaque ligne Pour le choix de ces possibilités, il conviendra d’être cohérent entre les applications de même type et surtout au sein même de l’application. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 20/38 7.1.1 Les menus contextuels Les traitements proposés dans le menu contextuel d’un élément de la liste peuvent concernés uniquement l’élément de la liste sélectionné ou l’ensemble des éléments sélectionnés de la liste. 7.1.2 Les actions de liste Les actions doivent toutes être proposées dans la barre d’action, en pied de page de la liste. Ces actions peuvent être lancées sur plusieurs éléments de la liste, les éléments concernés doivent alors être sélectionnés. 7.1.3 Les actions de ligne Ces actions ne peuvent concernées que l’élément de la ligne sur laquelle elle se trouve. Ces boutons ou icônes doivent se situer dans les dernières colonnes. Ils doivent êtres les mêmes pour toutes les lignes (éventuellement grisés si une règle de gestion interdit l’action). 7.2 Les actions dans les formulaires Les actions possibles depuis un formulaire sont : Actions standards o « Annuler » ou « retour » o « Enregistrer » o « Enregistrer et fermer » ou « Enregistrer ou retour » Présenter ces actions toujours dans le même ordre. Autres actions o « Imprimer » o Actions spécifiques de traitement Présenter ces actions dans une zone différente des boutons standards. Par contre, éviter les actions de navigation à l’intérieur des formulaires, cela peut dérouter l’utilisateur : un formulaire doit servir à saisir et modifier et non à naviguer. 7.3 Retour d’une action Le retour d’une action doit être visible par l’utilisateur. Soit par la modification visuelle de sa donnée Soit par l’ajout ou la suppression de l’élément concerné Soit par un message de succès ou d’échec Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 21/38 8 Les Messages et les notifications On distinguera dans ce paragraphe les messages retournés à l’utilisateur en réaction directe à une action qu’il réalise sur l’application, les notifications, qui sont des messages affichés à l’utilisateur indépendamment de toute action (ex : message sur la version, notification d’intervention à réaliser, …). 8.1 Messages de confirmation avant exécution d’une action En fonction du risque lié à l’action, il faut juger s’il est nécessaire de demander ou non la confirmation à l’utilisateur. Dans ce cas, la demande de confirmation doit lui permettre de choisir de continuer ou d’annuler son action. Ces messages s’ouvrent dans une fenêtre modale. Pour une suppression, une demande de confirmation est obligatoire. En web, ces messages seront mis en place en utilisant jquery, et la méthode dialog. Cette méthode, rattachée à une boîte de dialogue ayant un identifiant précis, sera appelé lors d’une moussions de formulaire par exemple. 8.2 Messages d’erreurs, d’avertissements ou de succès 8.2.1 Criticité Un message doit avoir un niveau de criticité. A savoir : Information Avertissement Erreur Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 22/38 En fonction de cette criticité, la couleur du message ou le logo associé au message doit être différent. Les messages d’information ou d’avertissement (plus important qu’une simple information) ne doivent pas bloquer l’utilisateur. Les messages d’erreur doivent bloquer l’action demandée par l’utilisateur. 8.2.2 Message suite au succès d’une action Ce message ne doit pas être systématique. Il permet d’afficher le succès à l’utilisateur quand, dans l’interface, aucune modification n’apparait (ex : « Export réussi »). La criticité est alors de niveau « Information ». En web ce message sera affiché puis s’effacera automatiquement suivant l’effet de fading (jquery). 8.2.3 Messages d’erreur Les messages d’erreur peuvent provenir : Du non-respect d’une règle de gestion D’une erreur de format D’une erreur technique Pour ces messages, la criticité est de niveau « Erreur », ils bloquent donc la réalisation de l’action demandée. Ces messages peuvent être issus de 2 niveaux de contrôles. 8.2.3.1 Contrôles au niveau du client. La vérification peut se faire au niveau du client (format des données, champs obligatoires ou éléments simples à calculer sans aller/retour avec le serveur). Ils sont calculés très rapidement et permettent un premier niveau de contrôle. Ils peuvent être affichés lors de la sortie du champ de saisie ou lors de l’enregistrement du formulaire. L’information de l’erreur doit être portée au niveau du champ concerné. 8.2.3.2 Contrôles au niveau du serveur Ces contrôles vérifient, au niveau du serveur, la validation des règles de gestion. Ils ne peuvent donc se déclencher qu’au moment de l’enregistrement du formulaire. Le message d’erreur doit s’afficher avec un niveau de criticité « Erreur ». L’information peut là aussi être portée au niveau des champs concernés. 8.2.4 Message de confirmation pendant un traitement Ces messages peuvent être proposés pour gérer les données qui paraissent suspectes mais qu’aucune règle de gestion n’interdit. La criticité est de niveau « avertissement ». Le message propose alors de continuer l’enregistrement ou de reprendre la saisie. 8.3 Les notifications Les messages de notifications peuvent arriver Au démarrage de l’application. Pour notifier des alertes fonctionnelles, des messages liés à la version utilisée, une information quelconque… Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 23/38 A tout moment dans l’application pour signaler un problème technique capturé par l’application (ex : accès à la base de données interrompu), … Les notifications ont aussi des niveaux de criticité qui permettent d’attirer plus ou moins l’attention de l’utilisateur : Information Important Très important Urgent En fonction de cette criticité, la couleur du texte ou le logo associé à la notification doit être différent. Dans la zone de notification, plusieurs notifications peuvent être présentes. Dans ce cas, elles seront triées par criticité. Cette fenêtre ou cette zone de notification peut se cacher en fonction de la présence ou non d’une notification urgente. La notification reste présente tant que l’utilisateur n’a pas exécuté une action qui signale qu’il a lu ou traité la notification. En plus du texte, la notification doit donc inclure un bouton ou un lien avec l’action (« Valider l’évènement », « Installer la mise à jour » ou simplement « Fermer »). Ces notices seront présentées sous la forme d’une lightbox s’affichant au chargement de la page. Celle-ci sera développée en jquery et intégrée dans la page par l’utilisation d’une div spécifique relatant la présence d’information à charger. 8.4 Les infobulles Le but des infobulles est de spécifier un attribut ou de détailler les informations sur un champ. Aussi il faut que ces infobulles soient accessibles et visualisables sur tout type d’élément (lien, panel, cellule de tableau, élément de formulaire). La mise en place de celles-ci se fera en Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 24/38 utilisant les CSS, associés à du jquery. Il faudra pouvoir autoriser les infobulles sur les 4 côtés de l’élément à détailler. Il faudra autoriser à rajouter du détail dans les infobulles, notamment un titre, ou quelques spécifications (surbrillance, soulignement, …) 8.5 Les notices Nous pouvons être amenés à mettre en place deux types de notices : - Les notices prédéfinies affichées tout le temps sur la page - Les notices au focus ou au clic 8.5.1 Les notices prédéfinies Ces notices seront visibles directement à l’ouverture de la page de l’application, et seront reconnaissables par un marqueur qui leur sera associé. Ces notices devront pouvoir contenir du texte et être reconnaissable en leur affectant un code couleur. Leur mise en place se fera en utilisant simplement du CSS. Le marqueur, comme pour les infobulles devra pouvoir être situé à l’endroit voulu (toujours en CSS). Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 25/38 Ces notices doivent pouvoir contenir n’importe quel autre élément précédemment défini (liste, tabs, …). Il sera cependant déconseillé de mettre des éléments complexes (type tabs, panels) dans ces notices afin de ne pas alourdir la page. 8.5.2 Les notices au focus ou au clic Pour ce type de notice, le système à mettre en place sera un peu plus compliqué. En effet, il faudra associer au CSS un peu de jquery. Le principe de fonctionnement restera strictement le même en terme de comportement. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 26/38 9 Les listes Une liste est une collection d’éléments qui instancient un même objet. Chaque ligne représente un élément de la liste. Une liste a un titre. Elle peut proposer un système de pagination. Pour chaque élément de la liste, ses propriétés peuvent être affichées en colonne, dans ce cas, la première colonne doit représenter un identifiant unique de l’élément (ex : numéro d’animal). Les libellés des propriétés sont indiqués en en-tête de colonne. 9.1 Nombre d’éléments dans une liste Si l’affichage de l’intégralité d’une liste demande un temps de réponse trop long, il est possible de tronquer cet affichage soit par un système de pagination soit par un filtre par défaut (modifiable ensuite par l’utilisateur). L’affichage de milliers de lignes à l’utilisateur n’a de toute façon aucun intérêt car pas exploitable en tant que tel. Le nombre d’élément maximum est donc à étudier pour chaque liste. Dans ce cas, l’utilisateur doit être averti que sa demande de liste est tronquée et il doit avoir la possibilité d’affiner sa demande par un système de filtre. 9.2 Conception d’une liste Une liste se compose de l’en-tête de liste, d’un corps de liste et d’un pied de liste. 9.2.1 En-tête de liste L’en-tête de liste peut contenir un titre décrivant les données présentées. Il contient obligatoirement les libellés des colonnes affichées. L’utilisateur peut trier la liste à partir des en-têtes de colonnes. Il peut modifier l’ordre d’affichage des colonnes (sauf la colonne d’action qui doit rester en dernière position Cf. 7.1.3 Actions de ligne). 9.2.2 Corps de liste Le nombre de colonnes ne doit pas être trop important afin d’éviter le scroll horizontal. Une colonne peut contenir des données sous forme de : texte avec ou sans lien (Cf. 7.1 Actions dans les listes) d’icône d’un bouton ou d’un lien (Cf. 7.1 Actions dans les listes) Il est recommandé de présenter les lignes paires et impaires avec une couleur de fond différente. La première colonne doit correspondre à un identifiant unique de l’élément et peut disposer d’un lien vers son formulaire de saisie. Ce choix doit être homogène dans toutes les applications d’un même type. 9.2.3 Pied de liste Le pied de liste est obligatoire. Il peut contenir : Le nombre d’éléments présents dans liste (et le fait de savoir si la liste est tronquée ou non) Les éléments de pagination La barre d’action (Cf. 7.1.2 Les actions de liste) L’objectif des listes est de permettre la visualisation d’une arborescence d’informations, comme par exemple une ontologie ou un plan d’application. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 27/38 En HTML, ces listes peuvent se créer en utilisant simplement les balises ul, et en y appliquant du CSS et du jquery, ou alors en utilisant des balises div avec du CSS et du jquery. Chaque sous-élément sera identifié par un retrait. Les listes à dérouler seront indiquées par une puce distinctive. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 28/38 10 Les formulaires Les formulaires permettent la consultation, la saisie ou la modification des informations de l’objet concerné. 10.1 Organisation des informations De manière générale, il conviendra d’éviter les gros formulaires. Ceux-ci présentent, en effet les inconvénients suivants : L’apprentissage par l’utilisateur est plus long Le contrôle des règles de gestion peut devenir très complexe et long à développer La maintenance peut s’avérer plus difficile Il est possible de développer différents formulaires pour le même objet si des processus fonctionnels amènent à modifier différentes parties de l’objet. Ceci afin de n’afficher que les données nécessaires. Au besoin, des liens entre ces formulaires peuvent être mis en place si cela a du sens pour le processus. Si une information est présente à plusieurs endroits de l’application, son libellé doit toujours être le même. Si la mise en place d’un gros formulaire s’avère nécessaire, il convient alors d’utiliser des onglets. En ce qui concerne les couleurs, nous nous baserons sur ce qui est préconisé dans la charte de l’inra, ce qui sera également le cas pour les polices de caractères. 10.2 Regrouper les informations selon leur thème L’utilisation de groupe de champs de saisie (group box en C#, FieldSet en HTML) est important pour faciliter la visibilité des différentes informations. En fonction du langage, ces groupes peuvent se replier/déplier. Dans ce cas, il est conseillé de replier à l’ouverture du formulaire, les groupes dont leur contenu n’est pas systématiquement modifiable. La logique de regroupement doit être la même dans tous les formulaires de l’application. On peut utiliser le principe des panels 3 catégories de panels différents possibles: - Le panel standard avec titre et contenu - Le panel coloré avec classe CSS définissant la couleur de l’en-tête - Le panel repliable avec bouton de repli Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 29/38 Le repli (dans le cas d’un panel repliable) se fait une nouvelle fois grâce au framework jquery. Le développeur pourra créer ces trois types de panels à sa guise. Attention, il faut toutefois mettre ces blocs « panels » dans une div principale permettant aux blocs de se situer les uns à côté des autres. Une autre méthode possible pour les formulaires courts est d’utiliser les fieldset. Ceux-ci contiennent une légende ainsi qu’une bordure aux couleurs définies par la charte de l’INRA, sur fond gris clair. La légende devra être encadrée de la même couleur. Cette méthode sera préconisée pour les petits formulaires avec peu de champs ou pour les thèmes de quelques éléments. Pour les formulaires importants, il sera utilisée une méthode permettant de replier le fieldset sur lui-même, en cliquant sur la légende. 10.3 Enchainement des zones de saisies Le passage d’une zone de saisie à une autre doit pouvoir se faire avec le clavier (touche tabulation principalement) et ceci de manière la plus cohérente possible (généralement de la gauche vers la droite puis de haut en bas). Au tant que possible utiliser les technologies pour basculer rapidement d’un champ de saisie à un autre (masque de saisie, touche entrée, …). En HTML ce principe peut facilement être mis en place en utilisant javascript, afin de spécifier des codes touches pour accéder directement à certaines parties du formulaire. 10.4 Les différentes sortes de formulaires 10.4.1 Les formulaires simples Ces formulaires présentent une saisie courte et directe de quelques données. Les éléments de formulaire HTML/CSS Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 30/38 10.4.1.1 Les champs texte Les champs texte doivent pouvoir se présenter de 2 façons différentes - Label et champs sur même ligne (de préférence) - Label et champs sur 2 lignes successives Il peut s’avérer très utile d’utiliser les placeholders afin de faciliter la saisie des utilisateurs, ainsi que des codes couleur autour des champs afin de spécifier leur rôle/importance - Rouge : obligatoire - Vert : optionnel - Bleu : champ informatif (ex : rappel nom utilisateur par exemple) - Orange : champ précalculé + 10.4.1.2 Les cases à cocher Les cases à cocher peuvent se présenteront sous la forme de cases cochées Il sera possible de les passer en mode switch dans les cas où il n’y aura que 2 possibilités en ajoutant au CSS la classe switch 10.4.1.3 Les champs password Ils suivront le même principe que les champs texte. On peut leur ajouter une fonctionnalité afin de permettre à l’utilisateur de voir ce qu’il est en train de taper à l’aide d’un icône imbriqué sur le champ. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 31/38 10.4.1.4 Les boutons radio Les boutons radios se présenteront sous la forme suivante (bouton plein) 10.4.1.5 Les listes déroulantes et les zones de textes (textarea) Ces éléments suivront les mêmes principes que les champs input text en ce qui concerne la couleur de contour, sinon ils suivront les principes généraux de l’HTML 10.4.1.6 Les champs file Ils suivront les principes des champs text, mais le bouton parcourir sera remplacé par l’icône fichier afin de suivre la logique des icônes définis précédemment. L’icône sera positionné comme un bouton situé à côté du champ file 10.4.1.7 Les champs date Ceux –ci devront suivre les principes de design des calendriers présents sur les interfaces de type windows. Compte-tenu du non-respect des normes HTML5 par certains navigateurs, il faudra une nouvelle fois utiliser jquery afin de faire afficher ces calendriers. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 32/38 10.4.1.8 Les boutons de soumission Ceux-ci suivront les recommandations de la charte INRA. 10.4.1.9 Les formulaires de recherche Ils se présenteront sous la forme d’un champ de type texte suivi d’une loupe afin de lancer la recherche. Lors du clic sur la loupe, le formulaire sera soumis 10.4.1.10 Les sliders 10.4.2 Les formulaires avec onglets Ces formulaires doivent être développés quand les données à saisir méritent d’être organisées par thème. Cf partie 10.1 10.4.3 Les assistants Les assistants permettent de faire saisir à l’utilisateur une tâche précise et ordonnée. Ils ont un début et une fin et présentent une navigation séquentielle d’une étape à une autre. Pour un processus de création complexe, l’utilisation de l’assistant simplifie le travail de l’utilisateur car les différentes étapes le guide dans sa saisie. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 33/38 10.4.4 Les formulaires maître-détail Ces formulaires présentent à la fois une liste d’élément et une zone qui détaille les informations de l’élément sélectionné dans la liste. En fonction du langage, le détail peut être présenté pardessus la liste dans une zone modale. Dans tous les cas, l’affichage du détail se déclenche en cliquant sur une ligne de la liste. Il est conseillé de forcer l’enregistrement à chaque changement d’élément. Ce type de formulaire peut se mettre en place de plusieurs manières en utilisant jquery. Le plus simple étant de définir le formulaire détail à la suite de la ligne sélectionnée, en la déroulant (mode fadein). En ce qui concerne l’ajout ou la modification d’informations, tout se fera de la même manière qu’expliqué dans le paragraphe sur les tableaux. Au-dessus du formulaire détail sera placé un bouton « ajouter un enregistrement » ajoutant automatiquement une ligne au tableau de données. Ces formulaires sont à la fois complexes à développer et difficiles à comprendre pour l’utilisateur. Ils sont donc à réserver pour des besoins spécifiques. La logique écran de listes séparées des formulaires reste à privilégier. 10.4.5 Les formulaires de saisie en tableau Ces formulaires présentent plusieurs données modifiables sous forme d’un tableau. Les actions possibles sont « Création », « Suppression » ou modification du contenu. Cette saisie en tableau peut être présentée seule, sur un onglet d’un formulaire ou dans un groupe de champs. La mise en place de ce type de saisie se fera pour la partie Web en utilisant le javascript. Chaque ligne correspondra à un formulaire de modification sur la ligne, avec possibilité de changer chaque champ. En utilisant l’évènement adéquat, le formulaire sera soumis et la mise à jour effectuée. Pour la suppression d’un enregistrement, un simple clic sur le bouton de suppression (idéalement une croix rouge) suffira à soumettre le formulaire de suppression de la ligne. Le jquery se chargera alors de rafraîchir le tableau. 10.5 Positionnement des informations Les champs de saisie sont alignés à gauche si la donnée est de type texte. Ils sont alignés à droite si la donnée est numérique ou de type date. Les libellés sont placés à gauche du champ de saisie (ou à défaut au-dessus) et sont alignés à gauche avec le : pour séparer du champ de saisie. Dans la mesure du possible, tous les couples libellé-champs de saisie doivent être alignés verticalement entre eux (Cf. schéma ci-dessous). Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Annexe applications web Page 34/38 10.6 Aide à la saisie L’aide à la saisie est primordiale pour l’utilisateur. Pour cela, il est possible d’orienter l’utilisateur par des aides contextuelles et, le cas échéant, des solutions d’interface de saisie facilitant le choix d’une valeur. L’utilisation d’info-bulle et zones d’aides est bien plus efficace que des descriptions sur le manuel utilisateur. Elles sont, en effet, contextualisées et visibles sans quitter l’écran de saisie. 10.6.1 Liste déroulante Elle permet à l’utilisateur de sélectionner une valeur pré-alimentée par l’application. Le contenu de cette liste de valeur peut être modifiable en fonction du contexte. Attention à ne pas proposer des listes déroulantes avec un trop grand nombre d’élément. 10.6.2 L’auto-complétion L’auto-complétion propose à l’utilisateur de compléter sa saisie automatiquement (des suggestions lui sont faites au fur et à mesure qu’il frappe son texte). Dans le cas où le nombre de valeurs possibles est trop important ce mode est saisie est préférable par rapport à une liste déroulante (Ex : nom de commune). L’auto-complétion peut aussi être combinée avec la liste déroulante. Dans ce cas, les éléments proposés dans la liste se réduisent au fur et à mesure de la saisie de l’utilisateur. Pour la partie web il faut privilégier la méthode mise en place par jquery. Elle crée un mini menu-déroulant sous le champ à remplir. D’un simple clic sur l’élément de la liste déroulante auto-générée, le champ sera rempli avec la valeur sélectionnée. 10.6.3 Rapatrier une valeur Il est parfois utile de proposer à l’utilisateur l’ouverture d’un formulaire pour récupérer une information complexe. Cette page doit s’ouvrir dans une zone modale bloquant ainsi la saisie du formulaire. Cette page peut proposer un formulaire de recherche pour aider l’utilisateur dans son choix. De plus elle peut déjà être filtrée en fonction d’un début de saisie de l’utilisateur (utilisation du « commence par… » pour l’initialisation du filtre). Le retour au formulaire peut se faire soit par fermeture explicite de la zone modale soit par récupération de la valeur par l’utilisateur. 10.7 Gestion des erreurs et validation des informations saisies Lors de la création ou la modification d’un objet, l’utilisateur peut saisir des données erronées ou incohérentes. La validation permet de définir des règles autorisant ou non l’enregistrement. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 35/38 Une icône doit apparaitre à droite de la zone de saisie concernée. Lié à cet icône, une info bulle affichera à l’utilisateur le message d’erreur. Le format des messages d’erreur est décrit dans le paragraphe 8 Les messages et les notifications. La validation se déclenche juste avant l’enregistrement du formulaire et sortie de chaque champ de saisie. En web, la validation des formulaires se fera en utilisant le javascript ey jquery. Lors de l’insertion/modification d’une valeur, la validité des données entrées sera évaluée par le système qui renverra un code couleur en cas de données erronées. Lors de la validation du formulaire, en cas de souci, celui-ci ne sera pas soumis, et une infobulle (identique à celle présente lors de la déconnexion) s’affichera indiquant à l’utilisateur les erreurs. Les champs incriminés seront surlignés en rouge lors du retour sur la page de soumission. 10.8 Eléments constituant un formulaire Un formulaire peut contenir l’ensemble des éléments présentés dans le schéma ci-dessous. Avec certains éléments obligatoires : Titre du formulaire Une zone pour les boutons avec au moins un bouton « Annuler » 10.8.1 Le Titre du formulaire Il contient un titre dynamique selon le contenu du formulaire faisant référence à l’identification de l’objet présenté. Exemple : Propriétés du traitement Zenol. Le texte du titre est aligné à gauche. 10.8.2 Les onglets Les onglets permettent le découpage du formulaire en plusieurs sous parties. Le titre de chaque onglet doit être concis et préciser son contenu. 10.8.3 Les groupes de champs GroupBox en C#, FieldSet en HTML Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 36/38 Ils permettent de regrouper les champs de saisie afin que l’utilisateur ait une meilleure perception des informations à saisir. En fonction du langage, ils doivent être repliables et être déjà repliés si leur contenu n’est pas systématiquement modifiable. 10.8.4 Les boutons d’actions Ils doivent être positionnés en bas à droite du formulaire. 10.9 Les mécanismes d’enregistrement 10.9.1 L’enregistrement du formulaire L’enregistrement du formulaire se fait par simple clic sur le bouton « Enregistrer ». Ce bouton doit être systématiquement présent en mode création ou modification. Dans le cas d’un assistant, il est conseillé d’enregistrer onglet par onglet à chaque changement d’étape. Dans ce cas, il conviendra d’ajouter le bouton « Enregistrer et suivant > ». L’enregistrement onglet par onglet peut aussi se faire sur un formulaire où le contenu des onglets est dense. Dans tous les cas, l’option choisie doit être la même dans toute l’application. 10.9.2 La cinématique d’enregistrement En cas de succès de l’enregistrement du formulaire, il y a un retour à l’écran d’où a été ouvert le formulaire (liste, module, …). S’il y a échec, un message d’erreur doit s’afficher et le formulaire doit rester ouvert. Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web 11 Les recherches Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 37/38 Charte ergonomique et graphique pour les applications développées au sein du Cati SICPA Annexe applications web 12 Les éditions Réf. : CEG_TC Version : 0.3 Date : 29/01/2015 Page 38/38
