Validation et divulgation progressives
J'essaie de trouver un exemple de validation progressive. Nous avons une interface utilisateur pour un éditeur visuel où un utilisateur fait des choses comme indiquer les dimensions en pixels ou en pourcentage.
Les propriétés de l'éditeur sont dans des ensembles d'onglets, donc tous les champs ne sont pas visibles en même temps. Nous avons discuté comment et si nous effectuons la validation dans cette interface utilisateur.
Je viens du point de vue que: a) La validation est utile car elle créera un canal de communication où l'utilisateur pourra apprendre les attentes du logiciel et "s'améliorer" à ce qui est requis. b) Il est toujours préférable d'indiquer directement les erreurs de validation sur les champs de saisie (qu'un résumé soit utilisé ou non ailleurs) afin que les utilisateurs aient une indication visuelle de ce qui doit être changé.
Mon collègue, pour qui je n'ai que le plus grand respect, n'est pas d'accord. Sa logique est la suivante: a) Il sera plus judicieux d’empêcher certains types d’entrée ou, dans le cas de certaines entrées, de la remplacer par une valeur plus appropriée si elle n’est pas valide. Par exemple, si quelqu'un utilise une valeur de pourcentage supérieure à 100, l'interface utilisateur réinitialise la valeur à 100 dans un événement de focus perdu. b) Parce que nous sommes dans un environnement d'onglets, certaines des erreurs ne seront pas visibles pour l'utilisateur. L'utilisation d'un résumé est inutile car il peut y avoir "beaucoup" d'erreurs de validation.
J'ai pensé qu'une solution autour de cela pourrait être une divulgation progressive des valeurs invalides. Lorsqu'un utilisateur entre des valeurs qui peuvent être incorrectes, elles sont signalées dans une sorte de résumé. Le résumé permet également aux utilisateurs d'accéder aux champs en question sans qu'ils soient visibles.
J'aimerais être une personne originale mais je suis sûr qu'il y a des précédents ici. Mes questions sont les suivantes:
Quelque chose à ajouter aux perspectives de moi ou de mon collègue?
Des exemples d'une interface utilisateur comme celle-ci avec une entrée complexe qui effectue une validation progressive?
Nous sommes actuellement aux prises avec le même problème pour une application de bureau, mais pas basé sur des onglets. Vous pouvez essayer une approche comme celle-ci:
où une petite icône apparaît si quelque chose requiert l'attention de l'utilisateur. Peut-être même utiliser deux couleurs: le jaune pour les avertissements et le rouge pour les choses qui doivent être fixées avant que l'utilisateur puisse aller plus loin.
La meilleure chose que vous puissiez faire dans cette situation complexe est de créer un prototype de la plus grande partie possible de l'interface utilisateur et testez-le sur votre base d'utilisateurs pour voir ce qui se passe. Vous pouvez utiliser HTML en combinaison avec quelque chose comme jQuery UI pour obtenir rapidement un grand nombre de contrôles interactifs disponibles et prêts à être testés rapidement.
Votre système d'onglets semble compliqué, je dois donc suggérer quelques choses pour simplifier:
- Créez des boutons "Appliquer" dans chaque onglet pour que l'état ne soit enregistré que pour les propriétés que l'utilisateur peut voir en ce moment. Si cela se traduisait par un état d'application non valide, remodelez vos onglets afin que les utilisateurs aient des propriétés regroupées qui peuvent être enregistrées indépendamment les unes des autres.
- Si vous ne pouvez pas le faire, vous pouvez mettre en surbrillance les onglets avec une icône "invalide" et une couleur pour indiquer que les propriétés de cet onglet nécessitent une attention. Bien que tous les onglets ne soient pas valides, le bouton "Appliquer" est désactivé. Vous pouvez envisager d'ajouter une notification au bouton si vous cliquez dessus pour afficher un message indiquant qu'il y a encore des erreurs. Des résumés de ce qui ne va pas seraient affichés dans chaque onglet au lieu d'avoir un résumé global.
- Un résumé global pourrait fonctionner, mais j'hésite à le suggérer car il semble qu'il n'y aurait pas d'emplacement immédiatement évident pour le mettre, et à moins que ce soit le cas, les utilisateurs vont-ils le remarquer?
- Comment les propriétés sont-elles regroupées? Probablement fonctionnel? Essayez de les regarder sous un angle différent, par exemple par probabilité d'utilisation. Cela fait partie de la façon dont Microsoft a abordé la conception du ruban pour ses produits Office 2007. Vous pourriez peut-être concevoir vos onglets de telle manière que la plupart des utilisateurs n'ont besoin que de jouer avec les propriétés du premier onglet, ou immédiatement visibles, et les autres onglets pourraient être considérés comme "avancés" ou contextuels.
Finalement, et je l'ai déjà dit, testez votre design! :-)
En ce qui concerne la gestion des erreurs, mon expérience a été que si vous empêchez certaines entrées, les utilisateurs seront confus. Par exemple, s'il n'est pas clair à partir d'un champ de saisie que seuls les chiffres sont autorisés, mais que vous interdisez tout autre caractère de toute façon, cela va être frustrant pour l'utilisateur - il ne le ressentira pas comme un formulaire intelligent qui essaie de l'aider. . Je vous suggère donc d'utiliser une microcopie claire tout au long si vous décidez de suivre la voie de l'utilisation des événements et de la détection d'entrée pour corriger automatiquement les choses.
Mais tout cela est anecdotique - je n'ai fait aucune recherche dans ce domaine. Au lieu de prendre ma parole pour cela, reportez-vous au livre de Luke Wroblewski, Web Form Design: Filling in the Blanks , et à ses recherches sur la gestion des erreurs pour obtenir des informations utiles sur la façon de gérer des situations comme celle-ci (pour par exemple, ceci publier sur la refonte du formulaire de paiement d'Apple explique comment ils traitent les erreurs en détail).
J'ai récemment travaillé sur un projet qui a rencontré un problème similaire. Vous pouvez voir une capture d'écran de la façon dont nous l'avons résolu dans mon article " Minimizing Complexity " de l'année dernière.
J'ai pensé à un cas où un résumé de nombreuses erreurs est utilisé et à un genre de travaux, peut-être.
Dans tout IDE comme dans Visual Studio, il y a un risque d'erreurs infinies lors de la création ou de l'utilisation d'outils d'analyse statique lors de l'écriture de code. En général, il existe des dizaines ou des centaines de fichiers et beaucoup d'entre eux s'ouvrent dans onglets, avec un ou deux visibles à tout moment,
Les erreurs sont ensuite répertoriées dans une liste redimensionnable déroulante qui glisse (par défaut) sous l'interface utilisateur principale. Cela pourrait être fait dès qu'une erreur est interceptée. Lorsqu'une erreur est cliquée ou double-cliquée, elle vous amène au bon endroit et vous concentrez pour la corriger - et l'erreur disparaît de la liste lorsqu'elle n'est plus valide.
(En réalité, beaucoup de ces erreurs nécessitent une action initiée par l'utilisateur pour être réévaluées, mais il existe de nombreux compléments d'analyse statique qui le font en arrière-plan et mettent à jour la liste d'erreurs dynamiquement lors de l'édition du code) .
a) Par exemple, si quelqu'un utilise une valeur de pourcentage supérieure à 100, l'interface utilisateur réinitialise la valeur à 100 dans un événement de focus perdu.
Bon point, mais alors vous devez vous assurer:
- L'utilisateur se rend compte que son entrée a été corrigée.
Peut-être, par exemple, faire clignoter le champ pendant une seconde si vous fixez la valeur. - Vous pouvez raisonnablement deviner ce que l'utilisateur voulait vraiment dire.
Par exemple, prenez un sélecteur de couleurs avec lequel j'ai lutté hier. Je voulais que quelques éléments correspondent à ceux d'un autre site, alors je me suis procuré les valeurs hexadécimales et les ai collées dans les minuscules zones de texte ad hoc. La première valeur était#202040, mais pour une raison quelconque, je n'ai collé que#20204, qui a été rapidement "corrigé" en#020204. La deuxième valeur que j'ai collée était#BCD(raccourci pour#BBCCDD), qui était également "fixé" à ...#000BCD. Soupir.