Sur les pages autres que la home, le favicon n'est pas chargé.

L'entrée du menu Interaction de chaque composant intègre une iframe du storybook.

Il serait bien d’intégrer la partie Docs storybook afin d'avoir une réelle intéraction.

Pour cela , il faut :

• Attendre que le storybook intègre la partie doc ( AxaFrance/react-toolkit#726)
• Intégrer l'iframe avec la bonne url (viewMode=docs)

16. Restitution

a) Définition

(1) Essence

(a) Un bloc de restitution résume l’ensemble des données qui ont été saisies ou générées sur l’outil. Il permet à l’utilisateur d’avoir une vue d’ensemble de ce qu’il a produit sur l’outil.

(2) Emploi

(a) La restitution est utilisée doit être utilisée pour des données fixes, de types variés et non filtrables.
(b) Plusieurs blocs peuvent être empilés pour détailler des informations sensiblement différentes sur une même page

(3) Mésusage

(a) Le bloc de restitution ne peut être utilisé pour des données dynamiques (l’affichage se met à jour en temps réel)
(b) Le bloc de restitution ne peut pas être utilisé pour un but que la restitution de données saisies ou générées par l’outil.

b) Utilisation

(1) Position

(a) Le bloc est aligné à gauche et peut prendre toute la largeur de la page.

(2) Alignement

(a) Selon la version utilisée, le contenu de la restitution peut être présenté en tables ou en liste, avec le label descriptif ferré à droite et la donnée ferrée à gauche sur la même ligne.

(3) Contenu

(a) La table doit obligatoirement être titrée, elle peut contenir un ou plusieurs sous-ensembles titrés, un certain nombre de labels concis et de valeurs clairement exprimées avec leur unité.

(4) Rédaction

(a) Tous les types de valeurs exprimés, notamment les chiffres doivent être accompagnés de leur unité (€ / %).

(5) Pictogrammes

(a) Aucun pictogramme ne doit être utilisé.

There are some typos, I'm creating an issue to fix this.

This issue to log a pull request about adding all necessary files (CONTRIBUTING.md, ISSUE_TEMPLATE.md, CODE_OF_CONDUCT.md, PULL_REQUEST_TEMPLATE.md, LICENSE) for people to contribute.

Also updating .editorconfig so that trailing whitespace in .pug files are not automatically deleted.

9. Header

a) Définition

(1) Essence

(a) Le Header est un bloc situé en Haut de page regroupant un ensemble d’informations et d’éléments de navigation principale.

(2) Emploi

(a) Le header est obligatoire pour chaque page d’un produit.
(b) Le header doit être le premier élément visuel d’une page donnée.

(3) Mésusage

(a) Le header ne doit pas comporter d’éléments ou de navigation secondaire.
(b) Le header ne doit pas prendre plus de 20% de la hauteur de l’écran

b) Utilisation

(1) Position

(a) Le header doit être le premier élément visuel d’une page donnée.
(b) Aucun élément (sticky) ne peut recouvrir le header ou ses éléments interactifs (liens, boutons, etc).

(2) Alignement

(a) Le header doit prendre toute la largeur de la page.

(3) Contenu

(a) Au minimum, le header doit contenu le logo de la marque, le nom du produit et son accroche, l’identifiant de l’utilisateur, un bandeau de titre de page ou un menu de navigation principale.

(4) Rédaction

(a) Le header et l’ensemble des liens qui le composent doivent être le plus concis et le plus structuré que possible (représentatif des fonctionnalités).

(5) Pictogrammes

(a) Des pictogrammes peuvent être utilisés pour certaines fonctionnalités spécifiques (sauvegarder, quitter, etc.)

(6) Action

(a) L’ensemble du contenu interactif (liens notamment) doit être disponible et visible sans aides à la navigation générés par le navigateur (ascenseurs horizontaux et verticaux)

(7) Variations

(a) Header avec bandeau titre de page
(b) Header avec menu principal de fonctionnalités

à ranger dans "Patterns"
sur une page dédiée: "Erreurs"

Supprimer le texte présent dans "Actions régressives" sous la section d) Erreurs, le replacer ici:

Erreurs

Guidelines générales:

1. • Une erreur se produit lorsqu’un processus échoue ou que la donnée ne correspond pas à la demande. Elle doit être exprimée clairement pour que l’utilisateur sache quelle action mener pour la résoudre. Elle doit être représentée en rouge.
2. • Pour un processus, il faut exprimer la raison de l’échec et l’action à mener: « Le document n’a pas pu être chargé, veuillez réessayer. » Pour un champ de données, il faut indiquer le bon format de données ou rappeler quels champs sont vides/obligatoires: « Veuillez indiquer la date au format JJ/MM/AAAA. » ou « Veuillez compléter les champs obligatoires. ».
3. • Le rédactionnel ne doit jamais mettre en défaut l’utilisateur. Il doit permettre de comprendre pourquoi l’erreur a eu lieu et comment la résoudre.
4. • Préférer limiter le texte à deux lignes.

Exemples d'erreurs

Ces exemples donnent une raison claire et concise, ne mettent pas en défaut l'utilisateur (même lorsque ses droits sont insuffisants), leur donnent un moyen de résolution.

Erreur liée au fonctionnement attendu

Le montant du comptant n’a pas pu être calculé, le comptant doit être forcé par le siège.
Veuillez prendre contact avec le siège pour résoudre le problème.

Données mises à jour

Des données client ou portefeuille ne sont plus concordantes.
Veuillez créer un nouveau devis.

Raison non expliquée car trop technique/ non nécessaire

Le projet ne peut être repris.
Veuillez retourner dans Salesforce pour créer une nouvelle opportunité.

Droits insuffisants

Vous ne pouvez pas effectuer de remplacement.
L’agent général du client doit effectuer cette action.

Evènement bloquant

Les données du véhicule étant incomplètes, le remplacement est impossible.
Vous devez résilier le contrat et effectuer une Affaire Nouvelle.

Annexe : Rappel des critères d’usabilité de Bastien et Scapin sur la rédaction des erreurs :

1. GESTION DES ERREURS

a) Définition :
Le critère Gestion des Erreurs concerne tous les moyens permettant d’une part d’éviter ou de réduire les erreurs, et d’autre part de les corriger lorsqu’elles surviennent. Les erreurs sont ici considérées comme des saisies de données incorrectes, des saisies dans des formats inadéquats, des saisies de commandes avec une syntaxe incorrecte, etc. Trois sous-critères participent à la Gestion des Erreurs : Protection Contre les Erreurs, Qualité des Messages d’Erreurs et Correction des Erreurs.

b) Justification(s) :
Les interruptions provoquées par les erreurs ont des conséquences négatives sur l’activité des utilisateurs. De manière générale, elles rallongent les transactions et perturbent la planification. Plus les erreurs sont limitées, moins il y a d’interruptions au cours de la réalisation d’une tâche et meilleure est la performance.

2. PROTECTION CONTRE LES ERREURS

a) Définition :
Le critère Protection Contre les Erreurs concerne les moyens mis en place pour détecter et prévenir les erreurs d’entrées de données ou de commandes ou les actions aux conséquences néfastes.

b) Justification(s) :
Il est préférable de détecter les erreurs lors de la saisie plutôt que lors de la validation : ceci évite de perturber la planification.

Exemples de recommandations :

• Quand les utilisateurs terminent une session et qu’il y a un risque de perte de données, il doit y avoir un message le signalant et demandant confirmation de fin de session.
• Les labels de champs doivent être protégés.
• Les aires d’affichage doivent être protégés : les utilisateurs ne doivent pas pouvoir changer les informations contenues dans ces champs.
• Toutes les actions possibles sur une interface doivent être envisagées et plus particulièrement les appuis accidentels des touches du clavier afin que les entrées non attendues soient détectées.

c) Commentaire(s) :
Protection Contre les Erreurs vs Incitation
Plusieurs façons d’offrir une protection contre les erreurs sont possibles. On peut par exemple mettre en place un mécanisme automatique de vérification des entrées. Ainsi, au moment de la validation des entrées, un message d’erreur apparaît si le format d’entrée n’est pas conforme à ce qui est attendu. Il s’agit bien dans ce cas-ci du critère Protection Contre les Erreurs. Une autre façon consiste à fournir une information renseignant les utilisateurs sur le type de données attendues ou encore sur le format de ces entrées : il s’agit alors du critère Incitation. Ces deux mécanismes peuvent aussi coexister.

3. QUALITÉ DES MESSAGES D’ERREUR

a) Définition :
Le critère Qualité des Messages d’Erreur concerne la pertinence, la facilité de lecture et l’exactitude de l’information donnée aux utilisateurs sur la nature des erreurs commises (syntaxe, format, etc.) et sur les actions à entreprendre pour les corriger.

Justification(s) :
La qualité des messages favorise l’apprentissage du système en indiquant aux utilisateurs les raisons ou la nature de leurs erreurs et en leur indiquant ce qu’il faut ou ce qu’ils auraient dû faire.

Exemples de recommandations :

• Si l’utilisateur sélectionne une touche fonction non valide, aucune action ne doit en résulter, si ce n’est un message indiquant les fonctions appropriées à cette étape de la transaction.
• Fournir des messages d’erreurs orientés tâches.
• Utiliser des termes aussi spécifiques que possibles pour les messages d’erreur.
• Utiliser des messages d’erreur aussi brefs que possible.
• Adopter un vocabulaire neutre, non personnalisé, non réprobateur dans les messages d’erreur; éviter l’humour.

b) Commentaire(s) :
Qualité des messages d’erreur vs Incitation
Un message d’erreur, peut comporter des incitations sur la manière de corriger une erreur. Il s’agit là du critère Qualité des Messages d’Erreur et non pas du critère Incitation. L’Incitation concerne uniquement le guidage en situation normale.

Qualité des Messages d’Erreur vs Lisibilité
Quand les messages d’erreur ne sont pas adéquats, même du point de vue lexical, il s’agit du critère Qualité des Messages d’Erreur, et non du critère Lisibilité. Le critère Qualité des Messages d’Erreur concerne toutes les caractéristiques des informations relatives aux erreurs des utilisateurs.

Qualité des Messages d’Erreur vs Concision
Le critère Concision ne s’applique pas aux messages d’erreurs. Lorsque ces derniers ne sont pas suffisamment succincts, il s’agit du critère Qualité des Messages d’Erreur.

4. CORRECTION DES ERREURS

a) Définition :
Le critère Correction des Erreurs concerne les moyens mis à la disposition des utilisateurs pour leur permettre de corriger leurs erreurs. Justification(s) : Les erreurs sont d’autant moins perturbatrices qu’elles sont faciles à corriger.

Exemples de recommandations :

• Fournir la possibilité de modifier les commandes lors de leur saisie.
• À la suite d’une erreur de saisie d’une commande ou de données, donner aux utilisateurs la possibilité de corriger seulement la portion de données ou de commande qui est erronée.
• Si les utilisateurs se rendent compte qu’ils ont commis une erreur d’entrée de données, leur donner la possibilité d’effectuer, au moment de leur détection d’erreur, les corrections souhaitées.

b) Commentaire(s) :
Correction des Erreurs vs Actions Minimales
Les problèmes liés au critère Actions Minimales peuvent résulter de mécanismes de correction des erreurs inadéquats. Lorsque le nombre d’actions nécessaires à la correction des erreurs peut être réduit, il s’agit d’un problème de Correction des Erreurs. Le critère Actions Minimales concerne donc les procédures autres que celles liées à la correction des erreurs.

Le code HTML est/peu être différent de ce que le composant renvoi. Avec storybook il serait judicieux de voir si on ne peut pas généré ce HTML pour éviter d’écrire en double (composant + html) ce qui est source d'erreur.
En plus de cela s'il y a des nouvelles règles d'accessibilité ou autres, il faut le reporter soit sur le design system soit sur les composants.
Qui est la source unique de vérité ?

Pagination

Se référer aux guidelines du Tableau:
https://axaguildev.github.io/design-system/molecules/table/

(a) La pagination est activée quand le nombre de résultat dépasse l’option d’affichage.
(b) Le sélecteur d’affichage est ferré à gauche.
(c) La pagination est composée de liens << précédent et suivant >> aux extrémités, encadrent les valeurs de pages suivantes: active, suivante, …,dernière.
(d) La pagination est ferrée à droite.

8. Footer

a) Définition

(1) Essence

(a) Le Footer est un bloc situé en bas de page regroupant un ensemble d’informations et de liens secondaires.

(2) Emploi

(a) Le footer est obligatoire pour chaque page d’un produit.
(b) Le footer doit être le dernier élément visuel d’une page donnée.

(3) Mésusage

(a) Le footer ne peut pas être utilisé comme menu secondaire pour des fonctionnalités clés.

b) Utilisation

(1) Position

(a) Le footer doit être le dernier élément visuel d’une page donnée.
(b) Aucun élément (sticky) ne peut recouvrir le footer ou ses liens.

(2) Alignement

(a) Le footer doit prendre toute la largeur de la page.

(3) Contenu

(a) Au minimum, le footer doit contenu le logo de la marque, l’année de la dernière version de l’outil, et « tous droits réservés ».

(4) Rédaction

(a) Le footer et l’ensemble des liens qui le composent doivent être le plus concis et le plus structuré que possible.

(5) Pictogrammes

(a) Des pictogrammes peuvent être utilisés pour des liens de type « réseaux sociaux ».

(6) Action

(a) L’ensemble du contenu interactif (liens notamment) doit être disponible et visible sans aides à la navigation générés par le navigateur (ascenseurs horizontaux et verticaux)

(7) Variations

(a) Footer « public »
(b) Footer « distributeur »

Issue and Steps to Reproduce

Versions

1.3.23

Screenshots

Expected

I suggest you add a tab that contains the css code, it will help people who do not use sass in their projects.

Actual

Text input

a) Définition

(1) Essence

(a) Un text input est un composant de saisie de texte.

(2) Emploi

(a) Un text input est utilisé pour compléter des données textuelles.
(b) Un text input peut être utilisé pour une large variété de données comme nom, prénom, adresse… qui rentrent sur une ligne de texte..

(3) Mésusage

(a) Un text input doit être remplacé par un text area si le contenu attendu est supérieur à une phrase.
(b) Le text input doit être remplacé par un date picker la donnée attendue par l’utilisateur est une date proche.
##b) Utilisation

(1) Position

(a) Le text input doit être ferré à gauche dans le bloc parent.
(b) Le text input doit prendre toute la largeur disponible dans le bloc parent ou la partager avec d’autres champ de manière égale (1/2 -1/2)
(c) Deux champs seront séparés de 24px d’espacement dans la largeur ou la hauteur.

(2) Alignement

(a) Le label du champ doit être aligné horizontalement avec sa consigne.
(b) Le label est aligné verticalement avec le champ.

(3) Contenu

(a) Le placeholder dans le champ doit être présent et clair pour faciliter la saisie.
(b) Celui-ci doit être [gris clair] tant que le champ n’est pas actif.
(c) Le label doit être présent si aucune consigne n’est juxtaposée au champ.
(d) Un bouton d’information peut accompagner le champ si celui-ci nécessite un contexte.
(e) Dans le cas d’un text area le champ de formulaire pourra s’étendre sur plusieurs lignes, avec un placeholder correspondant.

(4) Rédaction

(a) Le label d’un text input doit clairement indiquer la donnée demandée à l’utilisateur.
(b) Le placeholder doit clairement indiquer un exemple ou un format de données correspondant au label.

(5) Pictogrammes

(a) Aucun pictogramme ne peut être utilisé en tant que placeholder, dans le label.

(6) Action

(a) Pour les actions critiques — comme la suppression définitive d’un contenu — la couleur de fond sera obligatoirement « rouge ». Un bouton secondaire accompagnera obligatoirement pour annuler l’action en cours.

(7) Variations

(a) Simple
i) Renvoie une erreur si laissé vide par l’utilisateur alors qu’obligatoire.
(b) Autocomplete
i) Un text input avec une fonction autocomplete sera pertinent dans le cas d’adresses (ou autres données consultant une base de données).
(c) Format de donnée imposé (mail, date)
i) Renvoie une erreur si le format de donnée ne correspond pas à l’input attendu.
(d) Date
i) Le format attendu est jj/mm/aaaa.
(e) Mot de passe
i) Afficher un message d’erreur si la saisie ne correspond pas.
ii) Afficher un indicateur de force pendant la saisie si les paramètres correspondent.
iii) Afficher un indicateur de correspondance pendant la saisie si elle correspond.
(f) Text area
i) La zone de texte libre est dédiée à la saisie d’informations secondaire et de longueur variable et supérieure à une phrase: commentaire, avis etc.

(8) États

(a) Inactif (vide)
(b) Actif (saisie effectuée)
(c) Focus (saisie en cours)
(d) Erreur
(e) Désactivé

De manière global la note Lighthouse n'est pas optimale et j'ai constaté des suites de heading pas cohérent notamment. Il faudrait faire une passe.

12. Menu / navbar

a) Définition

(1) Essence

(a) Un menu permet de naviguer entre différentes sections ou fonctionnalités d’un produit, il représente le niveau de hiérarchie entre les différents éléments qui le composent.

(2) Emploi

(a) Un menu est utilisé pour la navigation principale et secondaire d’un produit.
(b) Un menu peut être composé d’une navigation principale et d’une navigation secondaire pour chaque élément de navigation principale.

(3) Mésusage

(a) Un menu ne peut pas être utilisé pour lier des éléments qui ne font pas partie du produit.
(b) Un menu et ses liens ne peuvent pas altérer la disponibilité des fonctionnalités du produit, cacher/désactiver des fonctionnalités ouvertes aux utilisateurs de manière momentanée ou permanente.

b) Utilisation

(1) Position

(a) Le menu est positionné dans le header de la page.

(2) Alignement

(a) Le menu doit prendre toute la largeur disponible,

(3) Contenu

(a) On limitera le nombre d’éléments à 7 par section ou sous-section. Au-delà, le menu demande un effort de mémoire à l’utilisateur.

(4) Rédaction

(a) Le contenu doit être extrêmement conçis, de préférence un seul mot, représentatif de la fonctionnalité/page vers laquelle redirige.

(5) Pictogrammes

(a) Aucun pictogramme ne peut être utilisé dans le menu

(6) Action

(a) La navigation doit être disponible constamment et de façon inaltérée sur l’ensemble des pages du produit.

(7) Variations

(a) Simple
i) Seul la navigation principale est utilisée pour le menu
(b) Double
i) Une sous section est disponible pour au moins un des éléments de navigation principale

(8) États

(a) Inactif
(b) Actif
(c) Focus
(d) Désactivé

It would be better imo if the readme:

• explained what it is for
• linked to the deployed website
• had steps to startup, and contribute

Afin de pouvoir partager l'onglet Guidelines d'un composant, par exemple, il faudrait que ce sous menu possède une ancre afin de pouvoir partager l'url et retourner sur les guidelines.

Bonjour,

Voici quelques styles à corriger sur les composants suivants:

Popover:

• Correction de padding sur la partie intérieur du contenu de la bulle: 8px 16px 8px 16px;
  
  

• Centrer l'exemple de Popover sous Storybook pour montrer les 4 positions de Popover: top, right, bottom et left.

Tags/Badge

• Centrer verticalement les textes et pictogrammes

Stepper

• Revoir des couleurs et des tailles des icones
• Centrer verticalement les textes et icones
  https://www.sketch.com/s/73328776-a6d4-47b7-a18b-fbb294f8d790/a/gnPYbq#Inspector

Le design system ayant changer d'url passant de https://axaguildev.github.io/react-toolkit/latest/design à https://axaguildev.github.io/design-system/, il faudrait supprimer l'ancien.