Guidelines Composants: Text Input

[djaumes]

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é

[jforatier]

A votre avis, ça aurait du sens de faire un fichier README.md / DESIGN.md pour chaque préco dans le repo plutôt qu'une issue ?