Alternatives aux cases à cocher et aux boutons radio dans les enquêtes en ligne?
J'ai été chargé de concevoir une conception de questionnaire simple avec de nombreux types de questions. J'ai moi-même pris beaucoup de sondages sur le Web et j'en ai testé certains avec des utilisateurs. Le plus gros problème est qu'il est difficile de cliquer sur les boutons radio et les cases à cocher de taille standard, surtout après que l'utilisateur est fatigué en raison de trop de questions dans l'enquête. Un remède consiste à s'assurer que l'étiquette de la case à cocher/du bouton radio est également cliquable, mais peu d'utilisateurs le comprennent réellement.
Donc, ma solution est de créer une sorte de boutons/conteneurs qui peuvent être sélectionnés, mais comment distingueriez-vous les alternatives à sélection unique (bouton radio) et à sélection multiple (case à cocher)? Ou le résoudriez-vous d'une autre manière? Ma solution d'arrêt, à la Balsamiq:
Il en va de même pour l'affichage des questions matricielles. Dans ce cas, il est encore plus difficile de trouver l'alternative que vous souhaitez, donc ma solution est basée sur une grille avec une zone de clic beaucoup plus grande et également plus facile de trouver l'alternative que vous souhaitez avec plusieurs questions. Ma solution d'arrêt à celle-ci:
Toute suggestion serait très appréciée!
Martin, regardez ce que jQuery Mobile a fait avec les boutons radio et les cases à cocher. Voici une page de démonstration:
jQuery Mobile Docs: Galerie de contrôles de formulaire
Ils vous offrent deux options viables que je pense que vous apprécierez.
Gardez les cases à cocher et les boutons radio identiques mais en leur donnant une surface plus grande et plus cliquable.
Le nouveau Apple inspiré par iOS
UISegmentedControl. Il s'agit d'une nouvelle interface utilisateur qui a un objectif similaire aux boutons radio. Il s'agit d'un contrôle de style horizontal compact qui est facile à appuyer et à lire.
Voici une capture d'écran:
Un autre bon framework Web est Jo , mais ils n'ont pas de démo que vous pouvez lier directement. Téléchargez simplement leur framework et ouvrez les exemples. C'est tout aussi impressionnant.
J'ai lu les réponses de beaucoup d'autres ici qui expliquent pourquoi cela rompt avec ce Apple indiqué dans leurs directives d'interface utilisateur au début des années 1980. Pourtant, même Apple quand ils ont créé l'iOS en créant le UISegmentedControl. Je pense que Martin a une bonne raison de poser sa question, et je pense qu'il existe des alternatives très convaincantes qui fonctionnent dans le monde réel.
Vous pouvez peut-être essayer un mélange de boutons habituels (pour avoir une grande zone sur laquelle cliquer) et les commandes radio/cases à cocher habituelles. Je ne supprimerais pas totalement ces contrôles, car il faudrait alors ajouter des descriptions de texte comme "Sélectionnez un seul". ou "Sélectionnez plusieurs".
Vous pouvez également griser les radios/cases à cocher qui ne sont qu'un indice subtil.
Les problèmes que je vois avec votre solution:
- Les boutons ne sont généralement pas sélectionnés mais ils effectuent une action quelconque (comportement inattendu)
- Vous ne pouvez pas distinguer les options de sélection unique et multiple
- Les utilisateurs sont habitués aux boutons radio et aux cases à cocher, ils savent comment ils fonctionnent et à quoi s'attendre
- Solution de grille: Ici, vous ne voyez pas du tout ce qui est cliquable
ne solution facile: Créez des boutons qui ressemblent et se comportent comme des boutons radio et des cases à cocher, mais agrandissez-les afin de les cliquer plus facilement.
J'espère que ça aide, Phil
Options:
- Un curseur . Je trouve que le curseur est un choix intéressant, en particulier des questions telles que "noter cela entre 1-10". Avec et sans rainures.
- Case de sélection. Parfois, tous les choix n'ont pas besoin d'être visibles. Décidez de l'importance de montrer tous les choix.
- Celles que vous avez montrées ci-dessus.
Hmm, je pense que ce sont vos choix. Voir Livre d'Alan Cooper: About Face pour plus de détails ..
Je ferais généralement écho à ce que Phil dit ci-dessus, mais je vous suggère également de vous demander vraiment pourquoi vous envisagez de modifier certaines conventions de formulaire Web qui sont littéralement aussi anciennes que le navigateur moderne. Comme le dit Phil, les utilisateurs savent comment fonctionnent les boutons radio et les cases à cocher et, même s'ils ne peuvent pas expliquer explicitement leur objectif, c'est une seconde nature que les cases à cocher permettent plusieurs choix tandis que les radios n'en autorisent qu'un.
Ci-dessus, vous dites: "Le plus gros problème est qu'il est difficile de cliquer sur les boutons radio et les cases à cocher de taille standard, en particulier après que l'utilisateur est fatigué en raison de trop de questions dans le sondage. Cependant, je ne sais pas pourquoi vous vous sentiriez de cette façon. Quelle recherche auprès des utilisateurs finaux proposez-vous que cela soit vrai. La fatigue des formulaires/sondages se produit généralement lorsqu'il y a trop de champs/questions sur une page et cela peut être atténué en découpant le formulaire en segments logiques et en affichant une barre de progression.
Dans votre solution proposée, encore une fois comme le dit Phil, votre grille ne précise pas ce qui est cliquable et vos boutons ne fournissent pas un moyen simple de faire plusieurs sélections. Il y a la convention d'une liste déroulante où l'utilisateur peut maintenir plusieurs fois CTRL + clic, mais pourquoi feriez-vous cela si vous pouvez simplement leur donner des cases à cocher?
Comme vous l'avez dit, vous pouvez faire en sorte que l'ensemble du champ du formulaire, y compris l'étiquette, soit cliquable pour augmenter la facilité de clic et vous pouvez également envisager d'augmenter la taille de la police et la hauteur de la ligne pour aider davantage les utilisateurs. Au-delà de ces considérations, je ne vois pas pourquoi vous violeriez la convention comme vous le suggérez.
Je trouve généralement que fournir aux utilisateurs les contrôles standard est plus intuitif pour eux. moins c'est souvent plus, de l'autre côté la question de la matrice est une assez bonne idée, comme cela a été suggéré, assurez-vous de rendre les alternatives visuellement cliquables, bonne chance!
Je pense que votre meilleure solution ici est de continuer à utiliser des types standard de contrôles d'entrée, mais de les agrandir.
Cela permet aux types d'entrées d'être reconnaissables, mais augmentera leur utilisation en augmentant la taille cible. Cela pourrait probablement être fait avec différentes images pour les états de contrôle d'entrée.
Comme je l'ai souligné dans la réponse de Phil, faire cela avec CSS ne pouvait que causer des problèmes, mais je suis sûr que vous pouvez le contourner avec javascript. Bien sûr, vous devrez effectuer de nombreux tests pour vous assurer que l'expérience utilisateur est cohérente entre les navigateurs.
Je suis d'accord avec la solution d'erikrojo pour l'appariement des cases à cocher et des étiquettes (en utilisant une forme de `` tout cela est une possibilité de vol stationnaire cliquable '')
Quant à la matrice, une suggestion serait une forme de système de "classement par étoiles" mais peut-être visualisée autour d'un axe (neutre):
bad great
[ | ]
En survol, vous verriez où vous vous trouvez le long de l'axe avec un visuel sur la barre de plage ainsi qu'une info-bulle vous indiquant la note actuelle en langage clair (plutôt qu'un simple nombre):
bad great
[ |--- ]
^good
Et puis un clic "le verrouillerait":
bad great
[ |XXX ] good
Quelqu'un a-t-il déjà testé si votre Joe moyen connaît vraiment la différence entre une case à cocher et un bouton radio? Par exemple, en leur posant une question qui pourrait avoir une ou plusieurs réponses, mais ne propose que des boutons radio parmi lesquels choisir. Ensuite, vous pouvez voir s'ils essaient d'en sélectionner plusieurs ou s'ils réalisent que les radios signifient qu'ils ne peuvent en choisir qu'un. Pourrait même juste mettre une case à cocher et un bouton radio devant eux et leur demander d'expliquer la différence.
J'ai travaillé sur quelque chose de similaire et j'ai trouvé un design similaire au vôtre, mais comme les gens l'ont souligné, il n'y avait aucun moyen de déterminer lequel était une sélection multiple. Je n'étais pas convaincu que l'utilisateur serait en mesure de déterminer qu'il s'agit d'une sélection multiple simplement parce qu'il y a un carré sur le côté gauche du bouton plutôt qu'un cercle, donc au moment où la question dit "Ma question ici? appliquer ", mais je ne sais pas ce que je ressens à ce sujet.
Le défi de votre suggestion de remplacement des cases à cocher et des postes radio est qu'il n'y a pas de distinction visuelle entre les deux types de comportements. La meilleure conception d'interface utilisateur définit toujours les attentes des utilisateurs AVANT qu'ils n'aient à interagir avec le contrôle. Je n'ai pas encore assez de représentants pour commenter la réponse d'erikrojo, mais cela a certainement l'avantage de tirer parti des idiomes connus, tout en bénéficiant d'une zone de frappe plus large.
Un curseur, comme Glen le suggère, a l'avantage de se modeler sur des interfaces utilisateur tactiles du monde réel qui ne peuvent avoir qu'un seul état à la fois - il n'y a pas d'ambiguïté là-bas, comme c'est le cas avec les boutons radio. Le curseur est malheureusement également livré avec ses propres défis d'implémentation et d'utilisation, et est beaucoup plus difficile à présenter dans le contexte d'un formulaire avec un ensemble de contrôles divers.
Un cadran est une variante d'un curseur qui s'intègre mieux dans une mise en page (il est généralement plus compact), à un impact d'utilisation significatif (le mouvement du contrôle est en rotation - mais l'entrée de la souris de l'utilisateur a tendance à être axonométrique, ce qui peut conduire à confusion entre différentes implémentations)
Une approche différente pourrait consister à concevoir un composant supplémentaire à la fois pour les contrôles à sélection unique et à sélection multiple qui informe précisément l'utilisateur du nombre de sélections dont il dispose. J'essaierai d'expliquer le visuel en utilisant des éléments du monde réel, et vous pourrez ensuite résumer cela en une représentation numérique comme vous le souhaitez. Considérez une banque d'ampoules. Si j'ai 5 réponses possibles et que je peux sélectionner toutes, certaines ou aucune, alors j'ai 5 ampoules, toutes allumées. Lorsque je clique sur mes boutons de réponse (et non sur les ampoules - elles ne sont pas directement interactives), une ampoule s'éteint et le bouton sur lequel j'ai cliqué d'une manière ou d'une autre est sélectionné. Alors que je continue de sélectionner des réponses supplémentaires, plus d'ampoules s'éteignent.
Poursuivant ce concept, si j'ai une question à choix multiple et à réponse unique, il n'y a qu'une seule ampoule dans la banque. Il est clair pour moi dès le départ que j'obtiens une réponse.
Évidemment, utiliser des ampoules dans votre interface semblera idiot (ou peut-être pas?), Mais vous avez l'idée - nous définissons l'attente dès le départ sur le nombre de sélections/réponses que l'utilisateur sera autorisé à faire pour chaque question. Un inconvénient de cette approche serait que l'utilisateur peut sentir qu'il doit "utiliser" tous ses choix avant de passer à autre chose. Cela pourrait être facilement atténué en indiquant clairement qu'après que l'utilisateur a effectué sa première sélection (même si plusieurs réponses sont possibles), la question suivante devient active ou disponible. Cela pourrait se faire de multiples façons, allant de la désactivation/masquage de la question suivante, au simple affichage d'une coche ou d'un autre indicateur que les exigences de la question actuelle ont été remplies.