Dans une forme, le passage de avancé à basique est-il une bonne idée?
J'ai une page Web/un formulaire que les utilisateurs doivent remplir avant de cliquer sur le bouton "continuer".
Même vieille histoire, je suppose. Cela ressemble à ceci:
report name: [...]
report type: (*) PDF
( ) HTML
Level Of Detail: [Easy v]
Template: [Natural v]
...
Pour rendre les opérations de l'utilisateur aussi simples que possible, la plupart des valeurs par défaut ont été définies.
Cependant, le nombre de champs est d'environ 10 options et je crains que la page ne semble trop intimidante.
Je pense mettre un interrupteur sur le dessus (basique/avancé) qui me permettrait de masquer/révéler les options.
Cela impliquerait que, si les utilisateurs accèdent à la page "de base", ils ne devraient pas se sentir trop intimidés.
Est-ce une bonne idée ?
dans l'affirmative, quelqu'un peut-il également fournir des exemples concrets de la manière dont cette approche a été adoptée?
Plus votre formulaire est long, moins il y aura de personnes qui l'utiliseront, et très souvent, la chute au fur et à mesure qu'elle grossit est abrupte. Gardez les formulaires aussi courts que possible. Si vous n'avez besoin que des informations de base, ne demandez que cela.
S'il y a une situation où vous avez besoin des informations les plus avancées, ne mettez pas de commutateur en haut. Vous ajouteriez quelque chose auquel les gens devraient penser avant même de commencer à remplir le formulaire.
Ce qui peut fonctionner est d'avoir le forme de base puis à la fin de celui-ci d'avoir plus d'options ou afficher avancé lien/bouton. Ce modèle est couramment utilisé dans Enregistrer ou Imprimer les formulaires dans les applications de bureau.
Étant donné que tout le formulaire est requis, je ne recommande pas de diviser la visibilité des champs le long des lignes de base et avancé.
Je voudrais d'abord essayer de regrouper les domaines connexes. Un formulaire plus long peut être rendu beaucoup plus facile à numériser et à comprendre (et à se sentir moins intimidant) lorsqu'il existe des sections claires qui organisent les champs connexes.
Si cela ne fonctionne pas trop bien, vous devriez envisager de diviser le formulaire en pages ou sections distinctes qui ne s'affichent que lorsque la page ou la section précédente est terminée.
Quelle que soit l'approche que vous adoptez, vous voudrez vous assurer que les utilisateurs peuvent voir les parties du formulaire qu'ils peuvent modifier sans effort, d'autant plus que vous fournissez des valeurs par défaut pour beaucoup d'entre eux. S'ils ne peuvent pas voir les champs, ils peuvent finir par accepter des valeurs par défaut qu'ils n'ont pas l'intention de prendre.
Comme le déclare JohnGB, vous devez garder vos formulaires aussi courts que nécessaire.
L'exemple réel pour ouvrir des champs supplémentaires dans un formulaire, est dans une boutique en ligne. Quand vous pouvez saisir votre adresse et alternativement une adresse de livraison.
Par défaut, une case cochée indique que votre adresse de livraison est la même que votre adresse de facturation. Une fois que vous décochez la case, les champs supplémentaires deviennent visibles (css).
Dans votre cas, j'aurais une case à cocher avec du texte, par exemple "Modèle par défaut" Si votre client décoche la case, vous pouvez révéler les champs qui doivent être remplis pour un modèle personnalisé.
Je ne sais pas combien de champs nous parlons, mais vous devriez absolument essayer de les avoir sur une seule page. Plus vous ajoutez de pages au processus de commande, plus vos clients ont de possibilités d'abandonner.
C'est un problème classique et les réponses pourraient être sous forme de divulgation progressive technique. Si le formulaire doit être long et il doit être long lorsqu'il n'y a pas d'autre moyen de collecter des informations et d'utiliser des techniques pour les résoudre. Bien sûr, limitez les questions et ayez le strict minimum.
Les formes courtes sont certainement un objectif souhaitable. J'utilise plusieurs façons de gérer les entrées de formulaire rarement utilisées.
Soyez un designer courageux: prenez une décision prudente sur un défaut, puis supprimez complètement l'option. Il est généralement difficile de convaincre l'équipe du projet de supprimer des éléments (peut-être parce que les techniciens sont souvent des fous de contrôle Tweak-heureux), mais les utilisateurs humains normaux préfèrent souvent ne pas avoir à prendre de décisions.
Masquer les options rarement utilisées: si vous devez vraiment inclure les options rares, vous pouvez les masquer sur un panneau extensible étiquetées pour ce qu'elles sont, par ex. customize formatting >>, ou customize detail level >>.
Une autre option de disposition est d'avoir une sélection de bouton radio pour ouvrir le panneau supplémentaire:
[o] standard page format
[ ] custom page format...
... puis lorsque la radio personnalisée est sélectionnée, développez le panneau avec les trois options relatives au format de page. C'est bon pour quand vous voulez offrir quelques configurations "prédéfinies":
[o] standard A4 page format
[ ] standard letter page format
[ ] custom page format...
Aussi, évitez les termes génériques comme basique/avancé. Les utilisateurs veulent savoir s'ils se soucient des détails supplémentaires et "Advanced" ne les aide pas à savoir à quoi s'attendre. J'aime le phrasé comme "personnaliser le ..." pour des situations comme celle-ci; à mes oreilles, il a un joli "ça va si vous ne le faites pas".