Introduire des contrôles incohérents: est-il approprié pour des raisons de convivialité?
Nous construisons une application Web basée sur Material UI . Tout au long de l'application, il y a sélectionnez les composants , qui se comportent comme indiqué dans l'exemple ci-dessous: L'étiquette par défaut informe sur la fonctionnalité de la sélection et lorsqu'une valeur est sélectionnée, cette étiquette se rétrécit et monte, de sorte que il est toujours affiché au-dessus de la valeur sélectionnée.
Nous utilisons ces composants principalement pour les opérations en vrac "organisationnelles" standard , telles que sort, group etc. Par conséquent, aucune valeur n'est sélectionnée par défaut, l'étiquette par défaut est affichée et l'utilisateur doit savoir à quoi sert le contrôle.
Cependant, nous avons également une page de paramètres (et des formulaires), où il existe déjà des valeurs définies, comme language. Cela laisse la sélection dans l'état où cette étiquette par défaut d'information a déjà diminué à sa plus petite taille (et resterait toujours de cette façon, car une langue ne peut pas être désélectionnée).
Pour cette raison, je voudrais changer le composant de sélection ici, afin que l'étiquette ne soit pas du tout affichée et introduire à la place une autre étiquette facile à lire qui est placée au-dessus, comme indiqué sur l'image ci-dessous.
Je pense que ce serait une bonne approche en termes de convivialité, rendant les commandes plus faciles à reconnaître et aidant ainsi l'utilisateur à modifier ses paramètres. (Imaginez une multitude de paramètres et recherchez un paramètre spécifique à modifier).
Cependant, il introduit également des incohérences, car il y aurait deux types de sélection dans l'application.
Je voudrais savoir si ce type d'incohérences est acceptable pour une meilleure convivialité. Les avantages l'emportent-ils sur la possibilité d'irriter l'utilisateur? Peut-être pourriez-vous fournir des recherches connexes ou des exemples concrets d'incohérences similaires par souci de convivialité. Peut-être existe-t-il même un moyen de quantifier ces "douleurs vs gains"?
Toute contribution est grandement appréciée!
Il existe différentes perspectives pour répondre à cette question, et elles ont été traitées séparément dans les questions précédentes que vous pouvez considérer:
Cohérence interne vs cohérence dans l'industrie , qui est basé sur l'équilibre entre ce qui est considéré comme la meilleure pratique et la cohérence avec votre propre produit et vos utilisateurs. Si vous avez un nouveau produit et de nouveaux utilisateurs, ce serait différent d'améliorer un produit existant avec une grande proportion d'utilisateurs existants.
Concevoir pour la cohérence de l'application ou suivre la convention du système d'exploitation? , qui est basé sur l'équilibrage de la gamme de produits que vous proposez (qui peuvent suivre différentes conventions de plate-forme) par rapport aux directives de marque et de conception internes.
Prise en charge de la cohérence ou du parcours de l'utilisateur principal? , ce qui en dit plus au point que vous faites sur l'équilibre entre la cohérence avec les besoins et les exigences des utilisateurs.
Mais en fin de compte, il s'agit d'essayer d'aborder tous les points ci-dessus lorsque vous parlez de cohérence et de ce que cela signifie pour vos produits/services ainsi que pour les utilisateurs.
Pour paraphraser, le fait est que dans la nouvelle solution il y a une variabilité initiale, alors que dans les précédentes ce n'est pas?
Afin de rendre l'application plus cohérente, vous pouvez ajouter une valeur initiale à toutes les sortes (toutes les options par défaut) - mais c'est certainement plus de travail: O
Que faire si l'étiquette de langue proposée est identique à la précédente après l'interaction?
