Le texte en lecture seule doit-il apparaître en texte brut ou dans une zone de texte en lecture seule?
Dois-je utiliser des étiquettes pour les informations en lecture seule ou dois-je utiliser des zones de texte en lecture seule pour conserver l'apparence des champs?
Il me semble que si quelque chose se trouve dans une zone de texte, cela implique qu'il existe un moyen de le modifier, alors que le texte brut est explicitement en lecture seule.
Mise à jour: Bien que ma question soit similaire à Verrouiller les champs du formulaire de saisie, est-ce logique? , le mien est différent en ce que je fais référence à des champs qui ne sont jamais modifiables par personne. Ce n'est pas basé sur les droits ou le rôle de l'utilisateur.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
S'il n'est pas modifiable, affichez-le en texte brut, sans champ de texte.
Mettre du texte non modifiable dans un champ de texte peut créer de la confusion. L'utilisateur peut se demander (et pour cause) pourquoi il ne peut pas modifier la valeur.
En termes d'UX, la copie dans le presse-papiers doit être prise en compte.
J'emprunterai votre maquette. D'après ce que vous indiquez, votre application est plus commerciale que de divertissement. Dans les applications professionnelles, la possibilité de copier des données dans le presse-papiers est cruciale pour l'UX - même pour les données en lecture seule.
Sur la page Web
vous pouvez créer une sélection et copier des données dans le presse-papiers même si elles sont présentées sous forme de texte. Aucun problème avec les champs Id et Stock Number ici:
... et les boîtes déroulantes?
- Vous pouvez les afficher sous forme de champs de texte ou d'étiquettes en lecture seule
En application
ce qui n'est pas dans la zone d'édition, est inaccessible et semble également incohérent
... et les boîtes déroulantes?
- Vous pouvez les afficher sous forme de champs de texte en lecture seule
- Lorsqu'ils sont modifiables, vous pouvez les modifier pour Ctrl+C sur la liste déroulante focalisée copie son texte affiché dans le presse-papiers
Si les utilisateurs ne peuvent pas modifier l'entrée, préférez utiliser une étiquette pour éviter la confusion des utilisateurs.
Si les utilisateurs peuvent modifier l'entrée dans certains cas, préférez utiliser des zones de texte en lecture seule.
Cette réponse est pour les interfaces utilisateur de bureau avec des types de contrôle distincts, pas pour les formulaires dans le navigateur où la plupart du contenu peut être sélectionné de toute façon, qu'il s'agisse d'un contrôle modifiable ou non.
C'est ma préférence personnelle en tant qu'utilisateur (et c'est ce que je fais lorsque je développe des interfaces utilisateur): j'utilise toujours des zones de texte verrouillées avec du texte noir (non grisé) et un fond gris pour les informations non modifiables. (Je le fais même si un champ particulier n'est jamais modifiable.)
La raison en est que, de cette façon, l'utilisateur peut toujours sélectionner et copier ces informations à partir de l'interface utilisateur sans avoir à les saisir ailleurs. Je supprime généralement la bordure de la zone de texte afin qu'elle ne se démarque pas, mais si l'utilisateur double-clique/clique avec le bouton droit sur la zone de texte, il peut sélectionner Sélectionner tout et Copier .
J'utilise également cette approche pour certaines étiquettes de formulaire (principalement les plus longues), car les longues instructions d'interface utilisateur doivent parfois être copiées dans des e-mails ou d'autres documents et il est plus facile pour les utilisateurs de copier et coller que de taper correctement de longues phrases.
Si le champ ne fournit pas réellement d'informations utiles à l'utilisateur, il doit s'agir d'un champ masqué (comme dans display: none;). Dans certains cas, ces informations doivent être sous la forme à envoyer au serveur (comme l'ID de la transaction), mais cela n'aide pas l'utilisateur à prendre une quelconque décision. Dans de tels cas, il n'y a aucune raison d'afficher réellement le champ et il doit être masqué.
Cette suggestion ne s'applique évidemment pas aux informations qui sont pertinentes pour les décisions des utilisateurs, auquel cas les données doivent être en texte brut, en aucun cas du champ de texte.
Ma préférence est d'ombrer l'arrière-plan pour indiquer un champ dont le contenu n'est pas modifiable, mais peut être sélectionné et copié dans le presse-papiers. Un texte de premier plan sombre sur un arrière-plan de couleur modifiable me suggérerait un "filigrane" qui ne fait pas partie du contenu du champ (par exemple, un champ de date qui indique faiblement "MM/YY" m'indiquerait pas que le champ contient ces caractères, mais plutôt que le champ voulait transmettre le message "MM/YY" à l'utilisateur). En général, je m'attendrais à ce que le texte qui ne se trouve pas dans les boîtes soit utilisé pour les étiquettes, plutôt que pour les données.
Je dirais que la règle de base est, si dans le contexte:
- le texte est jamais modifiable, utilisez une étiquette
- le texte est parfois modifiable en fonction d'autres variables du contexte, utilisez une zone de texte en lecture seule (qui passera bien sûr en modifiable le cas échéant)
Cela inculquera à l'utilisateur les différences potentielles en fonction de ses choix.
Ma suggestion serait une combinaison de la plupart des autres réponses.
- Si le champ n'est pas important pour l'utilisateur (comme l'id du champ dans ce cas l'est très probablement), ne le montrez pas à l'utilisateur.
- Si l'utilisateur peut vouloir copier l'entrée (clé RSA, URL, ...), une zone de texte en lecture seule le rendra plus facile (idéalement avec une sélection de tout sur focus).
- Si l'utilisateur peut théoriquement modifier la valeur des champs, mais pas maintenant (c'est-à-dire un e-mail uniquement modifiable dans les paramètres du profil) * et/ou qu'il se trouve dans un tableau avec beaucoup de zones de texte, une zone de texte en lecture seule peut toujours être le chemin à parcourir afin d'indiquer une entrée donnée par l'utilisateur et/ou de conserver la ligne dans le même style que les autres lignes de champ de saisie. Dans l'exemple, l'ID rompt clairement le style des lignes et semble moins cohérent.
- Dans tous les autres cas, vous devriez probablement utiliser une étiquette.
* Si tel est le cas, vous devez l'indiquer à l'utilisateur, c'est-à-dire "pour modifier votre e-mail, veuillez vous rendre dans les paramètres du profil".
Il y a certaines circonstances où il y a des avantages à styliser un champ qui n'est jamais directement modifiable comme ayant un état `` désactivé '': par ex. le champ fait partie d'une soumission de formulaire et/ou l'utilisateur doit vérifier que les informations sont correctes.
Par exemple:
- si une valeur est remplie sur la base d'une autre combinaison de valeurs modifiables par l'utilisateur sur le formulaire
- si l'utilisateur ne voit les champs que pour confirmer ou rejeter leur contenu (par exemple, signer une facture), généralement parce que les données proviennent d'une autre source (et votre application peut ne jamais avoir un formulaire dans lequel ces champs sont modifiables) .
La valeur de ceci serait de faire la distinction entre les informations contextuelles qu'un utilisateur n'est pas tenu de traiter (un ID) et les informations contenues dans la soumission du formulaire (même si la soumission du formulaire elle-même n'est strictement qu'un identifiant de transaction, l'effet de la soumission du formulaire est d'autoriser l'utilisation de ces valeurs).
si vous êtes contraint avec certains framework et ce sont les deux seules options alors
Les réponses de Leaf et Doddy sont les meilleures solutions à votre dilemme.
Cependant, si vous n'êtes pas contraint et que vous pouvez vraiment concevoir pour optimiser l'expérience utilisateur, je suggère les états suivants:
Modifiable
Pour l'édition les entrées doivent être légèrement 3D, pour donner une certaine profondeur, et l'utilisateur saura qu'elles sont modifiables
Non modifiable
Le fait que les données appartiennent au même modèle et aient également une apparence et une sensation distinctes, soit dans une zone de texte, soit dans une étiquette, n'est pas cohérent et agréable à l'œil.
ne solution est que ces champs non modifiables ont une couleur différente et une couleur de fond contrastée et ce sont complètement plats. L'appartement est comme imprimé, fin de l'histoire, rien de plus à faire ici.
Pour les postes de travail avec curseur:
N'oubliez pas de régler le curseur sur curseur à main. L'action est que lorsque l'utilisateur clique sur ce champ plat, vous obtenez une copie du texte dans le presse-papiers. Assurez-vous également qu'il y a info-bulle qui informe l'utilisateur de l'action de copie vers le presse-papiers afin d'éviter de perdre des données de presse-papiers déjà existantes.
Il serait préférable de séparer complètement ces informations du formulaire, afin que vos utilisateurs n'aient pas à réfléchir à la signification de ces informations et pourquoi elles ne peuvent pas les modifier. S'il est séparé, ils peuvent simplement se concentrer sur le remplissage du formulaire seul.
Je suis d'accord avec les autres réponses, vous devez utiliser une étiquette pour éviter toute confusion si le champ n'est pas modifiable, mais parfois il est très utile d'utiliser une zone de texte en lecture seule pour que l'utilisateur puisse copier à partir de celui-ci. Bien que cela dépende de ce que vous utilisez pour exécuter le programme, les étiquettes ne peuvent généralement pas être copiées.