2010-02-02 9 views
3

Je travaille sur une application web où nous avons un panneau modal/une boîte de dialogue contextuelle pour collecter des données utilisateur. Le formulaire dans le panneau a grandi et nous avons suggéré de diviser le formulaire entre plusieurs onglets, mais notre client a suggéré d'ajouter des barres de défilement dans le panneau modal.Barres de défilement dans un panneau modal

Y a-t-il des problèmes d'ergonomie avec les barres de défilement dans un panneau modal? Je crois que c'est une mauvaise pratique mais j'aimerais avoir d'autres opinions.

Merci,

Glen

Mise à jour: Je vais vous expliquer le scénario plus en détail. Nous avons une page de recherche où les éléments de résultats de recherche peuvent être sauvegardés (copiés dans une autre zone du système). Des informations supplémentaires peuvent être enregistrées avec ces éléments (par exemple, des commentaires supplémentaires, l'affectation à d'autres compartiments - je ne peux pas entrer dans plus de détails que cela). Lorsqu'un utilisateur souhaite enregistrer un élément de résultat de recherche, il peut cocher un ou plusieurs éléments et cliquer sur un bouton de sauvegarde - c'est à ce moment que notre panneau modal apparaît.

À l'origine, les utilisateurs ont été redirigés vers une page distincte et ils ont suivi une série de pages. Nos clients ont estimé que cela prenait beaucoup de temps, nous avons donc changé la page pour utiliser un panneau modal.

Je ne suis pas sûr à 100% que l'utilisation d'un panneau modal est la meilleure conception, mais c'est ce que nous avons maintenant. Je me réjouis de toute autre idée.

Répondre

2

Eh bien, je dois vous demander, si vous avez une forme modale qui est si longue, ne devrait-elle pas être faite dans sa propre page? Je veux dire que tout le but des dialogues modaux est de dire à l'utilisateur ce qu'il doit savoir (qui est généralement ignoré et ennuyeux) ou d'obtenir des informations de l'utilisateur avant de continuer.

Vous dites que votre formulaire est destiné à la collecte des entrées utilisateur. Si c'est quelque chose que l'utilisateur doit entrer avant de procéder (comme dans une partie d'un flux de paiement ou quelque chose comme ça), alors je dirais qu'il est probablement préférable de consacrer une page entière au flux.

Si c'est quelque chose qui ressemble plus à un "se connecter ici avant de faire ce que vous faites", encore une fois, je pense qu'il serait plus logique que ce soit sa propre page qui vous ramène à la la page où vous étiez avant d'y entrer une fois que vous avez terminé de remplir le formulaire. C'est ainsi que fonctionne la page de vérification humaine Stack Overflow. Si c'est quelque chose d'énervant comme "donnez-nous votre avis sur le site", alors il ne devrait pas être modal du tout, mais plutôt une fenêtre pop-up facile à rejeter (oserais-je dire?).

Les dialogues modaux doivent être aussi brefs que possible. Si la brièveté est impossible et que le dialogue doit vraiment être modal, alors je pense qu'il serait plus logique de créer un flux de pages qui doit être rempli avant que l'on puisse accéder au suivant. Comme une caisse: vous devez ajouter des produits à un panier avant d'ajouter des informations d'expédition, et vous avez besoin d'informations d'expédition avant de pouvoir déterminer le coût de l'expédition. Ce genre de chose. Mais sans connaître la nature exacte de votre dialogue modal, je ne peux pas vous dire exactement quel serait le meilleur moyen de le faire.


EDIT: Aha! Vos clients senti cela prenait du temps, hein?C'est le genre de situation où vous devriez faire un test de convivialité en live très rapide et sale pour voir de quelle manière est réellement meilleur. Prenez quelques personnes au bout du couloir, montrez-leur la manière modale (avec le défilement) de le faire et montrez aux autres l'ancienne façon (non modale) de le faire et de voir ce qu'ils ont à dire.

(Idéalement, vous enregistrez la session et l'écran, et assurez-vous de ne pas laisser transparaître vos propres préférences personnelles. Demandez-leur simplement d'utiliser le système pendant que vous regardez pour voir dans quelle mesure ils exécutent la tâche. enregistrer à temps les deux méthodes pour voir si une façon est vraiment plus rapide que l'autre.)

Vous ne devriez jamais prendre une décision d'utilisabilité qui va à l'encontre de la norme (la norme dans ce cas étant "les grandes formes méritent leurs propres pages ") sans s'assurer qu'il est réellement plus utilisable de manière anormale. Quand il s'agit de l'utilisabilité, la norme est généralement la norme parce qu'elle est utilisable (mais pas toujours, c'est pourquoi vous devez tester). Si le client se défend, vous aurez au moins la preuve qu'il va à l'encontre des preuves empiriques que ce qu'il veut est stupide.

En fin de compte, cependant, ce sont les clients qui paient les factures. Si vous ne pouvez pas les amener à voir la raison, alors vous devrez tirer le meilleur parti de ce qu'ils vous disent. Si le formulaire doit être dans un dialogue modal, vous pouvez au moins essayer de cacher les champs non essentiels sous le pli (s'il y a des champs non essentiels) afin que la majorité des utilisateurs n'aura jamais à faire défiler.

Assurez-vous que les boutons pour soumettre le formulaire (ou tout ce que vous devez faire avec le formulaire) sont visibles, peu importe où l'utilisateur a fait défiler. Une très mauvaise idée serait de mettre tous les champs requis en haut et ensuite forcer l'utilisateur à faire défiler vers le bas pour cliquer sur le bouton "soumettre". C'est juste impoli.

0

Il semble logique de mettre une fenêtre modale ici - je suppose que vous le faites comme un calque sur la page. Mais ce que cela donne, c'est qu'il y a beaucoup de monde et que vous cherchez des moyens de gérer le nombre croissant d'éléments de l'interface utilisateur.

Pour répondre à votre question initiale sur les barres de défilement, non, elles ne sont pas verboten. Toutefois, comme l'a affirmé un autre, vous ne devez jamais concevoir d'éléments d'interface utilisateur dans la zone de défilement.

Il semble que de bonnes recherches sur les utilisateurs puissent être utiles ici. Quels éléments sont importants pour les utilisateurs? Quels éléments sont obligatoires et lesquels sont facultatifs? Peuvent-ils être catégorisés?

Certaines personnes suggèrent que les onglets sont utiles pour la catégorisation lorsque le nombre d'éléments de l'interface utilisateur déborde d'une boîte de dialogue. Dans ce cas, cependant, je pense que ce serait une mauvaise idée. Ce n'est pas une catégorie de boîte de dialogue, mais plutôt une boîte de dialogue de confirmation/sélection/entrée dans laquelle les utilisateurs enregistreront tout ce qui est entré et choisi. Il y a de bonnes chances que les onglets manquent les onglets et manquent d'informations. Et si quelque chose sur un onglet "arrière" est nécessaire et qu'un utilisateur n'y va pas, alors vous avez une expérience d'erreur vraiment médiocre.

Une des choses à propos du défilement est qu'il est facile pour les utilisateurs de souris. ils ont l'option de cliquer sur la barre de défilement ou (pour beaucoup) de rouler une molette de défilement. Une chose que vous n'avez peut-être pas envisagée, en particulier si certaines choses que les utilisateurs peuvent entrer ou choisir sont facultatives, est de créer des sections dans la boîte de dialogue qui peuvent être réduites et développées. Les sections avec les éléments requis seraient étendues par défaut et les sections avec les éléments optionnels seraient réduites par défaut. Si l'expansion d'une section ajoute une barre de défilement, cette addition à l'interface utilisateur est évidente pour les utilisateurs. Bien sûr, vous devrez peut-être comprendre comment tout cela pourrait fonctionner pour les personnes qui n'ont que des claviers, qui ont des handicaps, et qui pourraient avoir accès à cela sur un appareil mobile.

0

Je ne pense pas qu'un panneau à onglets soit fondamentalement meilleur ou pire qu'un panneau de défilement. Chacun a des avantages dans différentes situations. Cependant, le plus important dans votre cas est le suivant: Si vous avez besoin d'onglets ou de défilement, votre panneau est probablement trop complexe pour être modal. Plus l'entrée d'informations dans un panneau modal est importante, plus il est probable qu'un utilisateur doive aller ailleurs pour obtenir une réponse, et plus vous jetez de travail si l'utilisateur décide qu'il doit aller ailleurs pour une raison quelconque.

La solution consiste à déplacer autant d'informations que possible du panneau vers la page/fenêtre parent. Permettez aux utilisateurs d'entrer le «droit d'information supplémentaire» directement sur la page de résultats de recherche, ce qui leur permet d'explorer les résultats pour les aider à décider de l'information. Étant donné que les informations supplémentaires consomment apparemment beaucoup d'espace, faites en sorte que les commandes soient visibles et masquables, mais gardez toujours les entrées utilisateur entre les peaux et les émissions. Je pense que c'est correct pour les onglets ou le défilement pour garder l'empreinte réduite. Des informations supplémentaires sur un seul résultat de recherche doivent apparaître dans les contrôles à côté de ce résultat de recherche, plutôt que dans un panneau séparé. Le panneau d'enregistrement modal ne doit contenir que quelques commandes utiles à l'enregistrement, telles que le nom de fichier et l'emplacement, et peut-être le type de fichier. Si toutes les informations sont utiles à la sauvegarde, faites en sorte que le panneau de sauvegarde soit sans modèle. Qui a dit que vous ne pouvez pas?

Mettre toutes les informations de sauvegarde sur une autre page n'est pas beaucoup mieux qu'un panneau modal, puisque c'est aussi effectivement modal, dans le sens où les utilisateurs ne peuvent pas aller ailleurs sans perdre leur entrée. Même si vous prenez des mesures pour préserver les entrées des utilisateurs sur la page si elles vont sur une autre page, la plupart des utilisateurs abusés du Web penseront qu'ils peuvent perdre leur saisie, donc ils n'essaieront pas.