Le marquage automatique dans les formulaires est-il utile ou dangereux?
Je travaille dans un environnement qui fait un usage intensif des systèmes mainframe. La maintenance de ces systèmes étant coûteuse, il a été décidé il y a des années de remplacer le mainframe par des systèmes basés sur le Web.
Au fur et à mesure que de plus en plus de personnes quittent l'ordinateur central pour le Web, une demande courante est que nous implémentions la tabulation automatique (c'est-à-dire que nous déplacions automatiquement le curseur vers le champ suivant une fois le champ actuel rempli). Je suis généralement opposé à l'autotabbing, mais je n'ai aucune donnée pour étayer ma position.
Existe-t-il des arguments quantifiables pour ou contre l’autotabbing? Des recherches spécifiques dans ce domaine seraient très appréciées.
J'ai eu ma juste part de projets mainframe -> refactoring web au fil des ans, et le sujet de tabulation automatique revient de temps en temps.
Tant que vous êtes cohérent dans la façon dont vous appliquez la tabulation automatique, cela peut être une très bonne fonctionnalité permettant de gagner du temps pour les tâches de saisie de données intensives.
Par exemple, définissez des règles de tabulation et suivez-les rigoureusement pour TOUS les champs.
- Assurez-vous que tous les champs INPUT ont une police à largeur fixe comme Courier/mono-espace appliqué.
- Assurez-vous que tous les champs INPUT ont les attributs "taille" et "longueur maximale" appropriés appliqués.
- Tabulation automatique lorsque l'utilisateur a épuisé tout l'espace dans le champ de saisie.
Les deux premiers sont importants car ils permettent à l'utilisateur d'évaluer avec précision le moment où le système effectuera une tabulation automatique. Si nous n'utilisions pas de police à largeur fixe, "iiiii" et "WWWWW" occuperaient une quantité d'espace différente dans le champ de saisie, et les utilisateurs ne seraient pas en mesure de dire combien de caractères il leur reste jusqu'à ce que les tabulations automatiques démarrent dans, car ils ne bénéficient pas du trait d'union "_ _ _ _ _" du mainframe.
Je sympathise avec OP, car lorsque vous travaillez avec un ensemble restreint et défini d'utilisateurs qui deviennent experts de leur application, les directives d'utilisation conventionnelles axées sur les applications axées sur le consommateur peuvent être difficiles à vendre.
C'est une question d'attentes. Normalement, sur les formulaires Web, une personne ne s'attend pas à ce que le curseur saute automatiquement autour de l'endroit et voudrait contrôler les tabulations d'avant en arrière comme elle le souhaite.
Cependant, votre application peut être très spécialisée ou avoir une base d'utilisateurs très spécifique, et cela peut avoir du sens dans cette situation.
Une suggestion serait d'envisager d'en faire une préférence d'utilisateur que les individus pourraient activer s'ils le désiraient.
D'accord, donc la première question est ... pourquoi n'aimez-vous pas le marquage automatique? Une réponse qui vous donnera raison de ne pas l'appliquer.
La tabulation automatique est un comportement inhabituel sur le Web, et cela ne fonctionne pas bien à moins que les utilisateurs ne soumettent des données qu'à un champ d'une longueur et d'un format particuliers. L'application de la tabulation automatique à des onglets spécifiques uniquement signifie un comportement inattendu et incohérent, sauf s'il existe toujours une justification claire pour l'utilisateur, ou si vos utilisateurs sont déjà exposés au concept via des outils qu'ils utilisent déjà dans le domaine. Un utilisateur qui s'attend de manière incorrecte à la tabulation automatique va trébucher, ce qui érode sa confiance en sa capacité à juger le fonctionnement de votre application, et un utilisateur qui ne s'attend pas à ce qu'il soit surpris de la même manière - et si d'autres messages apparaissent lorsque le nouveau champ prend le focus, je m'attends à ce que les utilisateurs supposent qu'ils ont accidentellement déclenché un événement quelconque.
Cela signifie donc que l'auto-tabulation devra être appliquée à au moins une classe particulière de formulaires, et cela va appliquer une contrainte plutôt stricte. Les contraintes sont la kryptonite pour le développement de logiciels car, comme nous le savons tous, les exigences changent et la contrainte raisonnable d'hier devient un point de crise demain.
Cela étant dit, si votre plus gros problème avec le marquage automatique est que vous ne pouvez pas mettre à jour le logiciel existant, vous avez des problèmes bien plus importants que l'UX. Les applications doivent encapsuler suffisamment leur logique d'affichage pour éviter que cela ne pose problème. Là encore, il semble que vous ayez hérité d'un logiciel hérité, donc le cheval peut avoir déjà boulonné sur celui-ci.
Je pense qu'une autre chose à considérer est ce qui fonctionne pour vos utilisateurs - s'ils le demandent, faites des tests rapides pour voir si cela fonctionne vraiment bien dans votre application ou non. Le même comportement peut être génial pour certaines personnes et frustrant pour d'autres.
J'ai eu cette discussion plusieurs fois et nous l'utilisons uniquement sur les champs de date.
Notre solution tabule automatiquement après que tous les espaces soient utilisés sur le terrain, mais seulement si elle est validée.
Exemple: ------- Année, inséré 3000 (en dehors de la plage possible), l'arrière-plan devient rouge et ne saute pas au champ suivant.
Année, inséré 2010 (à l'intérieur), l'arrière-plan clignote en vert pour indiquer qu'il est enregistré et passe au champ suivant.
Mois, inséré 04, (...) enregistré et passe au champ suivant
Mois, inséré 13, (en dehors de la plage possible), l'arrière-plan devient rouge et ne saute pas au champ suivant.
Problèmes possibles: ------ Mois, insère 4, ne sautera pas car ne remplit pas l'entrée (2 lettres). Nous avons des étiquettes indiquant MM sous l'entrée, les utilisateurs doivent donc comprendre l'entrée requise. Même si nous acceptons un seul 4 comme mois, mais les utilisateurs doivent se tabuler.
Il s'agit toujours d'une fonctionnalité discutée avec nous, et les commentaires des utilisateurs sont à la fois pour/contre. Je pense que la seule façon de décider si cela fonctionne ou non pour votre cas spécifique est de suivre la réponse de Kit Grose et Jung Lee et de commencer un test d'utilisabilité approfondi dans votre environnement.
Edit 2017: Nous avons ensuite supprimé notre fonction de tabulation automatique. C'était plus déroutant pour nos utilisateurs, et ne fournissait pas un avantage assez important par rapport à la non-tabulation automatique.
Une façon d'aider à gérer la maladresse de la tabulation automatique, par ex. J'ai tapé le numéro de téléphone entier et puis immédiatement frappé tabulation, seulement pour constater que l'entrée déjà tabulée automatiquement et maintenant je suis deux champs au lieu d'un, est de construire quelque chose pour saisir l'intention de l'onglet. Autrement dit, si le système vient de se tabuler automatiquement et que l'utilisateur appuie sur le bouton de tabulation avec x temps (disons 500 ms), ignorez l'onglet des utilisateurs car il n'était probablement pas destiné à tabuler un champ de plus.
Cela peut aider à réduire les erreurs lorsque la tabulation automatique affecte un sous-ensemble de champs dont les formats définis indiquent qu'ils sont complets. Cependant, vous devez prototyper et tester les interactions pour les composer et ne pas inclure accidentellement des cas où l'onglet était intentionnel, par exemple Je n'ai pas rempli le champ complètement ou pas du tout et j'ai cliqué sur tab. Dans ce cas, l'utilisateur a l'intention de passer manuellement pour une raison quelconque et vous ne devez pas annuler l'action.
Mais même avec cela, vous ne pouvez toujours pas contourner les problèmes de tabulation automatique car ils atteignent le nombre maximum de caractères, mais l'utilisateur n'était pas au courant de ce fait et continue de taper (car il regarde son clavier et non l'écran) uniquement pour se rendre compte plus tard, leur entrée est répartie sur plusieurs champs.
Il serait intéressant à la fin de tester le formulaire avec les utilisateurs à la fois en onglet automatique et en mode normal et de voir combien de temps sans avoir à appuyer sur le bouton de tabulation les enregistre et quelle méthode est moins sujette aux erreurs. Mon argent repose sur le fait que la fonction de tabulation automatique augmente les taux d'erreur et n'a en fait pas de gain de temps significatif.