J'ai un formulaire montrant les propriétés d'une entité dans une application Web: certains des champs du formulaire sont en lecture seule et certains sont modifiables. Dans les champs modifiables, certains doivent être remplis avec une valeur et certains sont facultatifs.
Comment marqueriez-vous cette distinction?
La réponse évidente serait d'utiliser un astérisque pour marquer les champs obligatoires, mais cela me semble problématique car les champs en lecture seule sont également obligatoires - ils ne peuvent pas avoir une valeur vide, seul l'utilisateur n'est pas celui qui fait l'édition mais l'application attribue la valeur automatiquement ...
J'ai pensé à faire l'inverse - marquez plutôt les champs facultatif modifiable avec le texte 'facultatif' ... Quelqu'un en connaît un exemple? Ou a une meilleure solution?
La meilleure façon ici est de supprimer tous les champs en lecture seule du formulaire. Vous devez trouver un autre moyen d'afficher ces informations. Mais s'il n'y a aucun moyen de les supprimer, assurez-vous qu'ils ne ressemblent pas à un champ de saisie.
Pour les champs avec une valeur par défaut, vous n'avez qu'à y mettre de la valeur; avec la couleur de police d'entrée noire. (la couleur grise les confondra, car beaucoup de formulaires l'utilisent comme étiquette à mettre en place)
Pour les champs obligatoires, utilisez simplement un astérisque près de l'étiquette.
Les champs en lecture seule de l'OMI ne doivent pas du tout être des champs. Cela ressemblerait à quelque chose comme ça:
Je suis d'accord avec Phil, la lecture seule ne doit pas être des champs. Il est maintenant préférable de dire à l'avance "Tous les champs sont obligatoires sauf indication contraire" ou similaire et de marquer clairement les champs facultatifs. Si vous n'avez pas besoin de demander quelque chose, vous ne devriez vraiment pas le demander.
Encore une fois, je vous réfère à une recherche exhaustive réalisée par Luke Wroblewski http://static.lukew.com/webforms_lukew.pdf (ceci est un lien vers un PDF). Voici une lecture connexe de Luke W: Marquage requis vs champs de formulaire facultatifs - Luke Wroblewski
Les valeurs facultatives auxquelles une valeur sera attribuée par le système pourraient utilement montrer ce que sera cette valeur par défaut.
Quelque chose comme l'image suivante vient à l'esprit où l'élément du haut est en lecture seule, celui du milieu est modifiable et affiche la valeur par défaut (en gris clair) si elle n'est pas modifiée par l'utilisateur, et celle du bas est modifiable, obligatoire, et n'a pas de valeur par défaut. Dès que l'élément du milieu obtient le focus ou est modifié, la valeur par défaut grise est remplacée par tout ce que l'utilisateur entre.
[modifier] J'ai changé le champ du haut pour qu'il ne ressemble pas du tout à un champ
Bien que je convienne que les champs non modifiables ne doivent pas ressembler à des champs, il existe des arguments pour les conserver à des fins d'accessibilité. Les champs de formulaire ont des attributs désactivés et en lecture seule que vous pouvez utiliser. Parfois, il est logique de les utiliser dans diverses situations. La clé est qu'ils semblent différents et semblent ne pas être modifiables par défaut.
En ce qui concerne le marquage requis par rapport à facultatif, j'aime marquer quelle que soit l'exception. Si seulement quelques-uns sont requis, j'ajoute (requis) à l'étiquette. Si seulement quelques-uns sont facultatifs, j'ajoute (facultatif) à ceux-ci. Cela dit, d'après les recherches auxquelles j'ai participé, de nombreux utilisateurs commentent s'ils ne voient pas les astérisques "standard" marquant les champs obligatoires. Je trouve que c'est un exemple de familiarité qui l'emporte sur les meilleures pratiques (il y a un terme UX pour cela qui m'échappe complètement ... quelqu'un m'aide avec ça ...)
Une simple recherche sur Google donnera des résultats assez cohérents. Il existe un consensus croissant sur le fait que sur la plupart des formulaires, la majorité des champs sont obligatoires et que seuls quelques-uns sont facultatifs et que seuls les champs facultatifs (non requis) doivent être indiqués comme tels.
Selon les recherches que j'ai trouvées, cela semble provenir de l'époque où nous utilisions des formulaires papier. (Le papier était un matériau très fin et flexible fabriqué à partir du bois des arbres, et était utilisé pour enregistrer et transmettre des informations en raison de son poids léger et de sa capacité à stocker l'encre.) Pendant cette période, on a supposé que chaque question était requise sauf indication contraire .
Par conséquent, la recherche conclut qu'il est préférable de laisser les champs obligatoires non marqués, tout en fournissant un indicateur de texte, tel que le mot "Facultatif", pour les champs qui ne sont pas obligatoires. Les indicateurs textuels sont plus accessibles que les symboles ou les icônes, qui ne peuvent pas être traduits et dont la signification n'est pas immédiatement apparente.
Il semble que la raison pour laquelle vous voyez généralement exactement le contraire dans la nature est due au code HTML. <input/>
les éléments sont facultatifs par défaut; ce n'est que lorsque vous ajoutez l'attribut required
qu'ils deviennent obligatoires. Dans le monde des formulaires HTML, la "nécessité" est opt-in. Cette convention de codage semble avoir été appliquée à la conception. Peut-être parce que CSS vous permet de faire ceci:
input[required]::after { content: '*'; color: red; }
Ce n'est peut-être pas toujours une bonne chose.
Voici du matériel de lecture:
Je ne voudrais pas que les données en lecture seule fassent partie d'un champ en premier lieu, mais si vous avez vraiment doit, il existe un modèle existant de grisonnement des champs en lecture seule. Cela était courant dans les produits Microsoft, en particulier Windows 9x. Considérez le champ "cible" ci-dessous:
Je n'aime pas ce modèle. C'est frustrant (il apparaît d'offrir des fonctionnalités d'édition aux utilisateurs non familiers, seulement pour les échouer), il est plus difficile à lire (à cause du bourbier de gris), et il suggère généralement que le texte est modifiable - parfois (ce qui n'est pas le cas dans votre cas). Pourtant, il est un modèle existant et familier qui fait ce dont vous avez besoin.
Aussi, je dois demander: pourquoi affichez-vous les données en lecture seule en même temps que vous demandez des modifications? Selon le cas d'utilisation, votre flux de travail peut rendre cela inutile (surtout si les personnes effectuant les modifications et lisant les données ne sont pas réellement les mêmes).