Remplacer l'entrée radio par des "boutons"? (formulaires Web)
Est-il bon (ou correct) UX de remplacer les champs d'entrée radio par quelque chose qui semble un peu différent (veuillez regarder l'image pour voir ce que je veux dire). Je pense que la plupart des gens comprendront qu'ils doivent cliquer sur l'un d'eux, mais je n'en suis pas sûr.
"Femme" et "Homme" ont des boutons radio sous le capot qui ne sont pas affichés.
Image de démonstration:
Démo en direct: http://fiddle.jshell.net/s5uEX/show/ (Testé dans la dernière version de firefox. Version sémantiquement correcte et non CSS3/non js (sans ombre et ainsi de suite) sera là aussi plus tard, bien sûr)
Modifier:
J'ai beaucoup changé en fonction de vos réponses (merci!). http://fiddle.jshell.net/ge8Su/show/ - Cela ressemble maintenant plus à des boutons radio normaux. À mon avis, un bon compromis entre les attentes des utilisateurs et ce que je voulais réaliser.
Je voudrais essayer le meilleur des deux mondes, le rendre bon pour le toucher et le bureau en ajoutant les boutons radio à votre style de bouton:
Alors j'appuie sur le contrôle Répéter le mot de passe et l'application répète mon mot de passe pour moi?
C'est le problème: lorsque tous vos contrôles se ressemblent, l'utilisateur ne sait plus vraiment comment interagir avec eux. Vous devez soit inclure des instructions textuelles, qui consomment de l'espace et ralentissent l'utilisateur, ou l'utilisateur doit s'arrêter et réfléchir à la façon d'utiliser votre interface ("Hmm, il dit déjà Femme et Homme, donc je suppose que je sélectionne une plutôt que de taper quelque chose dedans, et je suppose que cela définit un champ, mais peut-être que cela m'amène à une page séparée pour des informations supplémentaires sur le sexe… Je suppose que je devrai simplement le découvrir "). Vous avez une interface TAMIDS: appuyez n'importe où; Peut-être que ça fait quelque chose.
Les différents contrôles doivent être différents. Les contrôles comme les zones de texte doivent ressembler à des contrôles de zone de texte standard, les contrôles avec un comportement de bouton radio doivent ressembler à des boutons radio standard, les contrôles avec un comportement de case à cocher doivent ressembler à des cases à cocher standard, etc. Des apparences standard doivent être utilisées afin de tirer parti de l'expérience utilisateur afin que les utilisateurs puissent anticiper le comportement. Je ne recommanderais pas d'apparences non standard même si elles distinguent les contrôles, car l'utilisateur doit alors faire l'effort d'apprendre le nouveau "code". Dans quelle mesure l'apparence doit-elle être proche de la norme? Assez proche pour être instantanément reconnu. Pour un bouton radio, à peu près n'importe quel cercle avec un point à l'intérieur devrait faire l'affaire, mais généralement l'approche la plus simple et la plus sûre consiste à utiliser l'apparence par défaut du contrôle.
Je ne vois aucun avantage à faire en sorte que ces boutons radio ressemblent à des champs de texte. Au moins dans le monde du bureau, la légende ainsi que le bouton radio lui-même sont sensibles à la saisie, donc ce n'est pas un problème de taille cible. Même si les tests ne montrent aucun inconvénient pour le temps de réponse à la sélection du sexe dans votre cas, le non-respect des normes compromet leur utilité, ce qui rend les utilisateurs plus susceptibles d'être confus dans d'autres situations lorsque cela est plus ambigu.
Pour un formulaire mobile, j'aime ça. Plus facile à taper sur les appareils tactiles, et assez intuitif (pour moi au moins). Cela s'améliorera probablement avec les ombres que vous avez l'intention d'ajouter.
Je ne sais pas si c'est une meilleure alternative aux boutons radio pour les formulaires non mobiles, mais je doute que cela causerait des problèmes majeurs. Bien sûr, vous devez tester cela pour être sûr.
Un problème intéressant auquel vous pouvez être confronté est qu'il est important plus clair que "mâle" et "femelle" soient des boutons si l'un d'eux est déjà sélectionné. Vous rencontrez le problème de choisir un état par défaut, mais alors comment êtes-vous sûr que quelqu'un voulait vraiment que ce soit la valeur par défaut, ou ils l'ont juste laissé rempli par erreur. Aussi quelque chose à tester.
Après l'avoir essayé, je pense qu'il est assez clair, surtout lorsque vous vous déplacez dessus, et que les "boutons" sont mis en évidence. Je n'ai aucune idée de ce que ce serait sur un mobile, mais je pense que c'est assez clair et évident.
En substance, ce que vous avez fait, il a pris le contrôle de bouton radio standard et l'a dépouillé - quelque chose qui était très courant et parfois irritant. Cependant, vous l'avez bien fait ici, et les commandes ont des possibilités raisonnablement claires, car elles semblent similaires aux boutons.
Je pense donc que cela fonctionne.
Il y a quelques problèmes qui peuvent être résolus avec une bonne conception visuelle:
- laquelle de ces options est actuellement "activée"?
- les choix sont-ils mutuellement exclusifs (c'est-à-dire qu'il s'agit de boutons radio ou de cases à cocher)?
Pour le premier numéro, j'ai vu des traitements ambigus. Si vous avez 3 options ou plus à sélectionner, il est généralement assez clair quelle est l'option sélectionnée. Cependant, consultez le problème 2 pour les environnements qui confondent cela.
Pour la seconde, vous pouvez imaginer utiliser un traitement similaire pour la sélection du jour de la semaine: [Mon | Mar | Mer. | Jeu | Ven | Sam | Sun] où chaque jour pouvait être "activé" de manière indépendante et non mutuelle. Il est compact et soigné et minimise l'encombrement ... mais signifie qu'un affichage de [1-1-2] est maintenant ambigu quant à savoir si l'état "1" est "activé", ou l'état "2" est "activé".