Comment gérer les nombres superflus dans les champs de texte d'entrée?
Je travaille sur des champs de texte d'entrée pour les assistants de laboratoire, par ex. un champ de texte pour entrer une valeur de température (dans une interface utilisateur personnalisée, pas sur un site Web). Les utilisateurs n'ont pas à entrer l'unité Celsius ou Fahrenheit, juste la valeur. Il y a une limite inférieure et une limite supérieure, mais comme recommandé dans Validation du champ de texte vs prévention , elles sont gérées par la validation, pas par la prévention. Si l'utilisateur a entré une valeur valide (c'est-à-dire une valeur entre la borne inférieure et supérieure), il/elle peut appuyer sur une sorte de bouton de soumission, afin de reconnaître la nouvelle valeur.
Mon problème est que je ne sais pas comment mon interface utilisateur doit gérer les entrées superflues. Par exemple, lorsqu'un de mes utilisateurs entre "0015" pour une température, cela doit être changé à 15,0 dans mon système. Et la précision décimale superflue? Si je n'empêche pas un utilisateur d'entrer plus de décimales que je n'ai de précision, est-ce correct si le système arrondit automatiquement les décimales vers le haut ou vers le bas (par exemple, 37,48 devient 37,5 après l'acquittement d'entrée)?
Je sors le cerveau si les utilisateurs peuvent se sentir mal à l'aise lorsque le système effectue ce type de modifications automatiques après la confirmation d'entrée, même si elles sont logiques et cohérentes.
Edit: Quelqu'un sait-il ce que les chercheurs de HCI recommandent à ce sujet?
J'aurais tendance à penser qu'un utilisateur qui entre 0015 ne serait pas surpris si l'entrée le change automatiquement en 15.
Ils ne seront probablement pas non plus trop surpris de voir 15 passer à 15,00. Cela dit, ils peuvent alors être conscients que le nombre requis peut être entré dans 2dp après coup, ce qui n'est pas la meilleure pratique au sens strict.
Bien que les utilisateurs soient également susceptibles de se rendre compte lors de l'arrondi, un tel changement de la valeur sous-jacente (et pas seulement du format) doit être accompagné d'une explication claire que cela va se produire, avant l'application d'une règle.
Dans cet esprit, chaque fois qu'il existe une exigence de format de saisie, il est généralement judicieux de fournir au champ de saisie une valeur d'espace réservé initiale dans ce format, ou une note à côté du champ pour informer les utilisateurs du format, ou les deux.
Généralement, cela crée le moins de problèmes (collision avec les entrées utilisateur) pour attendre qu'un champ perde le focus. Ensuite, formatez les données - à condition qu'elles soient valides - selon vos spécifications. Plus précisément, supprimez tous les zéros non significatifs et arrondissez les valeurs à deux décimales, dans cet exemple. Je ne m'inquiéterais pas du tout d'imposer cela aux utilisateurs tant qu'il est cohérent. La plupart des gens comprendront rapidement.
Si vous allez contraindre une valeur dans une plage, ce serait bien dans votre étiquetage de l'indiquer, par exemple "-20 à 100". Rien de plus frustrant que de faire apparaître un avertissement après coup, alors qu'il pourrait facilement être géré à l'avance. Si l'utilisateur persiste à entrer des données non valides, il est bien sûr normal d'escalader les avertissements avec une interface utilisateur plus intrusive.
Je regarderais attentivement le moment où l'utilisateur est informé des modifications apportées à la valeur entrée: si vous pouvez suivre les conseils suggérés dans une autre réponse pour effectuer la validation en quittant le champ de saisie (pas en appuyant sur SUBMIT), le focus est toujours sur le champ.
Les changements de formatage ne sont pas critiques, je pense.
Cependant, l'arrondi peut être accompagné d'un avertissement "14,35 arrondi à 14,4" immédiatement en dessous (ou en plus) du champ de saisie (tel qu'un message "les mots de passe ne correspondent pas" que vous voyez parfois dans les boîtes de dialogue de changement de mot de passe sur le deuxième champ de mot de passe). Pour cela, vous devez réserver l'espace pour le message dans le formulaire - je ne sais pas si l'espace est limité dans votre cas (ne faites pas scintiller la disposition du formulaire).
Il existe trois domaines différents que vous pouvez essayer de résoudre le problème. Le principe de base ici est de s'assurer que le résultat correspond aussi étroitement que possible aux attentes de l'utilisateur. Voici donc ce que je proposerais:
Avant que l'utilisateur ne fournisse une entrée, montrez à quoi pourrait ressembler le résultat. Vous pouvez le faire en tant qu'exemple de valeur grisée dans le champ de saisie, ou en tant qu'étiquette en dessous ou à propos du champ de saisie.
Pendant le processus de saisie de valeur, affichez une transition claire ou une notification/messagerie pour montrer que la conversion a lieu (au moins la première fois). De cette façon, l'utilisateur peut voir le changement se produire au fur et à mesure qu'il se produit, minimisant ainsi les chances de le réaliser plus tard ou de ne pas pouvoir effectuer les ajustements corrects.
Après l'entrée, confirmez l'entrée utilisateur et la sortie système résultante afin que le processus ait été capturé dans son intégralité (au moins la première fois). De cette façon, l'utilisateur comprend le changement du début à la fin et peut choisir de modifier son comportement à l'avenir.
La combinaison de ces stratégies que vous appliquez dépend de la conception exacte de l'interface et de l'interaction, mais le principe de prendre en compte le comportement des utilisateurs et de les aider à mieux utiliser le système en répondant à leurs attentes est le même.