rectangles contre coins arrondis des champs de texte sur mobile
Pensez-vous qu'il y a une différence dans la perception des champs de texte qui ont des coins ronds\rectangles?
Mon objectif est d'établir une convention selon laquelle les coins arrondis sont des champs que l'utilisateur peut saisir en entrée et les coins rectangulaires sont des champs en lecture seule. Je sais qu'il existe d'autres moyens pour atteindre cet objectif, mais ma question se concentre uniquement sur ces éléments visuels.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il y a une différence de perception entre les coins arrondis et carrés, mais ce n'est pas sémantique - ce qui signifie que c'est un choix de conception et n'a pas de signification explicite . Donc, si vous choisissez d'utiliser le style de coin comme quelque chose de sémantique, vous allez confondre beaucoup de gens. Ne le fais pas.
Si vous devez désactiver un champ ou le rendre non modifiable, utilisez les méthodes standard pour celui qui fonctionne bien.
La perception psychologique des coins arrondis vs carrés est traitée dans une question sur La psychologie des formes de tous les jours
Pour répondre à la question, uniquement en termes de forme, je connecterais le rectangle avec un champ de texte (modifiable ou non), et la forme arrondie davantage avec une action comme un bouton. Les zones de recherche sont en effet souvent arrondies et combinent fréquemment plusieurs éléments - elles sont comme un cas particulier de zone modifiable et de zone d'action.
Mon interprétation est presque perpendiculaire à votre question de savoir si une forme signifie modifiable ou non, dans la mesure où je ne trouve ni l'un ni l'autre et j'observe en fait une autre signification.
Combiner votre sens voulu avec le mien serait très déroutant et le vôtre serait probablement perdu dans la traduction.
Cependant, dans un monde mobile où le le contenu est l'interface et où il devrait y avoir une utilisation accrue d'interfaces utilisateur naturelles basées sur l'intuition humaine, je dirais qu'il n'est pas nécessaire de mettre une bordure autour du contenu en lecture seule et de préférence évité. (Je me rends compte que c'est quelque chose d'une généralisation.)
Contenu en lecture seule est simplement: contenu.
En posant cette question, vous vous donnez presque la réponse: il vaut mieux utiliser des mécanismes acceptés déjà familiers aux autres.
Comme dit précédemment, les bords arrondis sont plus attrayants. Selon cela article par UXMovement , ils sont plus doux pour les yeux, et ne présentent pas de danger de "netteté". Récente recherche psychologique soutient cette notion, montrant des sentiments négatifs surgissent dans le cerveau à la suite de la vue des arêtes vives. Si vous pouvez vous permettre d'utiliser uniquement des formes arrondies, mieux c'est. Cela montrera également mieux, lorsque les gens, des utilisateurs aux parties prenantes, doivent juger du succès de votre conception.
Je ne pense pas qu'il existe une convention forte séparant les champs de texte arrondis des coins. Notez que dans iOS, presque tous les champs de texte sont à moitié arrondis en standard, donc ici vous avez peu de place pour jouer (encore une autre merveille du design d'Apple). De plus, si la plupart du temps le champ de texte n'est pas modifiable, je ne vois pas du tout pourquoi garder le cadre du champ de texte. Montrez simplement le contenu dans une simple étiquette.
Impliquer en lecture seule avec des formes est une idée intéressante. Je ne compterais pas uniquement sur cette dimension différenciante, car les utilisateurs pourraient prendre un certain temps pour la saisir. Si vous le supportez avec les marqueurs conventionnels de lecture seule, comme suggéré ici par d'autres, vous pourriez faciliter la tâche de l'utilisateur pour déterminer l'attribut de lecture seule avec une grande facilité et vitesse. Mais cela ne se produirait que si l'utilisateur est régulièrement et fréquemment exposé aux deux groupes de contrôles, sinon la convention ne ferait pas son chemin dans les attentes de l'utilisateur.
La convention existe déjà, disabled = "disabled" rend la zone de saisie en lecture seule, c'est aussi du HTML sémantique. Cet attribut change également la couleur de l'arrière-plan de la zone de saisie en gris et le texte semble un peu décoloré. Une technique similaire est utilisée pour afficher les éléments de menu inactifs.