web-dev-qa-db-fra.com

Afficher / masquer ou activer / désactiver les champs du formulaire

Je voudrais connaître les avantages et les inconvénients concernant la conception de formulaires de "champs dépendants". Par exemple, dans mon formulaire, j'ai un champ État matrimonial , et en fonction de sa valeur, j'ai besoin de connaître le numéro de document du partenaire et nom du partenaire .

  • Quels seraient les avantages/inconvénients de pas montrant les champs partenaires, et les afficher à la volée, selon la sélection de État matrimonial ?

vs.

  • Quels seraient les avantages/inconvénients de laisser les champs désactivés sur le formulaire et de l'activer sur la sélection d'autres champs?

D'autres solutions au problème seraient également appréciées.

Le formulaire est un formulaire Web pour une application Web d'entreprise, pas un site Web.

9
RMalke

Ce que vous demandez vraiment, c'est quels sont les avantages et les risques de divulgation progressive dans une conception de formulaire Web.

Avantages

L'avantage de l'utilisation de la divulgation progressive est que vous réduisez la charge cognitive de l'utilisateur en affichant uniquement les champs dont il a besoin pour terminer sa tâche. Au fur et à mesure qu'ils entrent plus de données, plus de champs peuvent être requis, mais ils n'ont à examiner et interpréter ces champs que si cela est nécessaire pour l'achèvement de la tâche.

Comme Jakob Nielsen écrit:

Dans un système conçu avec une divulgation progressive, le fait même que quelque chose apparaisse sur l'affichage initial indique aux utilisateurs que c'est important.

[...]

La divulgation progressive améliore [...] trois des les cinq composants de l'utilisabilité : apprentissage, efficacité d'utilisation et taux d'erreur.

Les autres avantages à la divulgation progressive sont:

  • Interfaces propres, plus simples et plus productives (une aubaine pour les petits écrans)
  • Le contenu important est priorisé en donnant la priorité initiale aux fonctionnalités les plus courantes
  • Le contenu moins important est masqué afin de ne pas dérouter les visiteurs
  • Le temps est économisé si le défilement est réduit et moins de rafraîchissements sont nécessaires
  • Moins d'erreurs se produisent car les utilisateurs novices prendront des mesures plus faciles et plus faciles à gérer

Désavantages

L'inconvénient de cette approche réside cependant dans la conception et la mise en œuvre.

Luke Wroblewski aime une citation particulière de Charles Mingus qui s'applique dans cette situation:

"Rendre le simple compliqué est chose courante; rendre la complexité simple, génialement simple, c'est la créativité. "

Dans un article UX Matters il écrit sur la complexité de la simplicité. La divulgation progressive, ou comme il l'appelle "engagement progressif", est la façon dont un flux de travail complexe peut être "perçu" comme simple par l'utilisateur. Atteindre cette perception est difficile:

Afin de présenter la bonne interface utilisateur au bon utilisateur au bon moment, les concepteurs doivent suivre plusieurs types d'utilisateurs et leurs différents états, puis mapper ces contextes à une présentation appropriée des fonctionnalités et du contenu. Ceci, bien sûr, est un défi non trivial et, par conséquent, est souvent mal fait. Si la logique n'est pas complètement réfléchie, certains utilisateurs se retrouvent avec trop d'options, tandis que d'autres pensent qu'ils en ont trop peu.

Les autres inconvénients incluent:

  • L'accessibilité peut être délicate, comme pour aider les lecteurs d'écran à naviguer vers les sections de page
  • Le temps de chargement des pages pourrait augmenter en raison de la taille du contenu de préchargement
  • Les technologies côté client comme JavaScript (Ajax), CSS3 ou Flash peuvent être désactivées par l'utilisateur (vous devez donc prendre en compte la dégradation gracieuse, ce qui pourrait augmenter le temps de développement)

La bonne nouvelle

La bonne nouvelle pour vous est que les principaux inconvénients de la divulgation progressive sont les plus importants dans les applications ou les interactions complexes, et non dans les formes transactionnelles.

Dans votre cas, vous décrivez des champs obligatoires qui ne sont requis que si un état particulier existe. Vous n'avez aucun problème à définir ce qu'est la "bonne interface utilisateur" pour le "bon utilisateur" au "bon moment". Vos règles commerciales doivent répondre clairement à toutes ces questions.

Les défis de mise en œuvre concernant l'accessibilité, le chargement des pages et les technologies côté client peuvent être atténués et testés.

Mise à jour :

  • Voici une question connexe qui contient des informations/opinions supplémentaires sur ce sujet.

  • Voici n autre avec un bon Joel Sposky citation:

    Il y a longtemps, il est devenu à la mode, voire recommandé, de désactiver les éléments de menu lorsqu'ils ne pouvaient pas être utilisés.

    Ne fais pas ça. Les utilisateurs voient l'élément de menu désactivé sur lequel ils veulent cliquer, et se retrouvent sans aucune idée de ce qu'ils sont censés faire pour que l'élément de menu fonctionne.

    Au lieu de cela, laissez l'élément de menu activé. S'il y a une raison pour laquelle vous ne pouvez pas terminer l'action, l'élément de menu peut afficher un message expliquant à l'utilisateur pourquoi.

19
Charles Wesley

Envisagez des alternatives à leur affichage ou non.

Un inconvénient de ne pas les afficher est que l'utilisateur n'a pas une idée précise de la durée d'un formulaire basé sur un défilement rapide. Les montrer peut rendre un formulaire compliqué et submerger l'essence de ce que vous cherchez.

Peut-être qu'une approche intermédiaire pourrait fonctionner, comme l'image grossière ci-jointe où de petits sous-champs véhiculent que plus d'informations seront demandées sous chaque champ de formulaire principal, sans certains des inconvénients de montrer chaque champ immédiatement.

enter image description here

3
Mark Gavagan

Lorsque vous avez une région dépendante de la valeur (a.k.a., entrées dépendantes de la sélection ) comme vous le décrivez, la règle de base que je recommande est de:

Désactivez les champs dans a lorsqu'il n'y a qu'un seul ensemble de champs qui dépendent de l'entrée . Cela fournit un aperçu à l'utilisateur de ce à quoi il peut s'attendre lorsqu'il sélectionne ou fournit une valeur particulière pour le champ de contrôle (état matrimonial, dans votre cas). C’est mieux que de cacher des champs car cela rend la forme visuellement stable sans espaces vides étranges ou autres champs qui glissent spontanément pour faire de la place. C'est mieux que de laisser les champs activés car les utilisateurs peuvent sauter mentalement les champs désactivés sans les étudier pour voir s'ils postulent ou non.

Masquez les champs lorsqu'il existe d'autres ensembles de champs qui dépendent de l'entrée . Autrement dit, si vous allez remplacer certains champs avec d'autres en fonction de l'entrée de l'utilisateur, masquez ceux qui ne s'appliquent pas. Étant donné que vous échangez des champs, le formulaire reste relativement stable. Il est préférable de le désactiver, car il empêche le formulaire d'être trop encombré avec de nombreux champs qui ne peuvent pas tous s'appliquer à la fois.

Il y a des zones grises, comme d'habitude. Par exemple, si pour une sélection vous avez un champ dépendant de l'entrée, mais pour une autre sélection, vous avez les quatre champs dépendant de l'entrée, il peut être préférable d'utiliser la désactivation pour maintenir la stabilité et fournir un aperçu. Le coût d'encombrement est assez faible.

J'ai tout ce que vous souhaitez savoir sur la désactivation et le masquage * sur Contrôle de vos contrôles .

* Mais j'avais peur de demander.

1
Michael Zuschlag