Affichage/présentation/ergonomie désélection de radio bouton

Bonjour,
dans un projet quelconque je souhaite rendre possible le fait de désélectionner un radio bouton.
Mais je ne trouve pas un moyen naturel/facile/simple/ergonomique.




Idée :
J'ai pensé à un tout petit bouton avec une croix, mais où le placer ? à la fin du label ? à droite de la dernière valeur ? est-ce vraiment la bonne idée ?

Peut être mieux lors du clique sur un radio bouton si celui-ci est déjà coché je le décoche ? un peu comme une checkbox
Modifié par Su4p (26 Feb 2014 - 15:45)

Bonjour,

un seul radio bouton, ça ne veut rien dire : c'est une checkbox qu'il faudrait utilser je suppose.
Dans le 1er cas, il n'y a qu'un seul état possible. Enfin si, il y en a 2 mais, c'est le sens de ta question, une fois un des choix fait pas moyen de revenir en arrière !
Dans le 2e cas, on obtient 2 états avec un seul composant (et on peut changer d'avis à tout moment).

Autres solutions (techniques, je dis pas qu'ergonomiquement c'est souhaitable...) :
- 2 boutons radio dont un a pour étiquette "Aucun" (déjà sélectionné ou en tout cas il faut se méfier côté serveur de l'état "aucun des 2 boutons coché")
- une liste de choix avec la 1ère option "vide" (ou "Choisissez truc")

Normalement, on n'est pas censé pouvoir ne rien sélectionner. Le principe de base du bouton radio veut qu'en tout temps une et exactement une option en tout et pour tout soit sélectionnée dans chaque groupe.

La solution la meilleure, à mon avis, est de prévoir un bouton radio supplémentaire type "aucun" / "pas de sélection" / "je ne sais pas".

Maintenant, si tu y tiens vraiment, le plus naturel me semble être, comme l'avis précédent, de décocher la sélection si on clique sur le choix actuellement coché. Au pire, l'utilisateur recliquera une deuxième fois pour réactiver le choix qu'il a décoché par mégarde.

Par contre, tout le monde ne trouvera pas instinctivement l'astuce et surtout pas au moment où il en a effectivement besoin. Le bouton supplémentaire explicitement labélisé a au moins le mérite d'être clair pour n'importe qui à n'importe quel moment.

Ton idée de croix est définitivement une mauvaise idée. ON imagine trop rapidement annuler une saisie laborieuse ou carrément fermer la page, avec une crois qui se rattacherait à on me sait pas trop quoi.

Pose-toi aussi la bonne question: est-ce que les boutons radio sont effectivmeent les éléments les plus judicieux à utiliser dans ton cas ? Réfléchis si les cases à cocher ou une lise déroulante ne serait pas plus approprié. Repense aussi à la philosophie dite de la moindre surprise.
Modifié par QuentinC (26 Feb 2014 - 22:27)

Premièrement, merci pour vos réponses.

Felipe a écrit :
un seul radio bouton

Ce n'est pas le cas; dans ce cas la j'utilise en effet une checkbox. (en me relisant j'admets que mon premier message pouvait porter à confusion)

La question se pose pour des elements multiples à choix unique d'où l'utilisation d'un radio bouton.

QuentinC a écrit :

La solution la meilleure, à mon avis, est de prévoir un bouton radio supplémentaire type "aucun" / "pas de sélection" / "je ne sais pas"

Je suis plus ou moins d'accord.
Oui il s'agit là de la solution la plus naturelle(pour les navigateurs) pour faire marcher les radio boutons.
Toutefois je trouve que ce modèle alourdi le formulaire avec une option inutile, et que il s'agit là d'une erreur qui a était perpétrée au fil du temps.

QuentinC a écrit :

L'accessibilité, c'est aussi savoir rester simple et ne pas compliquer plus que nécessaire.

C'est vrai pourquoi une checkbox peut ne pas être coché et un radio bouton non ? Je ne vois pas d'argument contre à part le "parce que c'est comme ça".

Quelqu'un sait-il pourquoi historiquement parlant le radio bouton a été fait de manière bloquante ?
Modifié par Su4p (27 Feb 2014 - 14:59)

a écrit :
Toutefois je trouve que ce modèle alourdi le formulaire avec une option inutile

Ce n'est pas une option inutile, si pour toi n'avoir aucune autre option sélectionnée fait sens pour ta logique.

a écrit :
C'est vrai pourquoi une checkbox peut ne pas être coché et un radio bouton non ? Je ne vois pas d'argument contre à part le "parce que c'est comme ça".
Quelqu'un sait-il pourquoi historiquement parlant le radio bouton a été fait de manière bloquante ?

Les boutons radio ont été conçus pour fonctionner en groupe de cette manière, tout comme les checkbox ont été conçues pour être indépendantes les unes des autres.

Historiquement, ça vient tout simplement de ceux qui ont conçu les élément de base des interfaces utilisateur modernes.

Dans une boîte de dialogue ou un formulaire, ils ont remarqué qu'on saisissait normalement des données de trois grands types différents :
1 - Des réponses booléennes (oui/non ou bien vrai/faux). Sur le papier ça se fait traditionnellement avec une case dans laquelle on met une croix pour « oui », et rien pour « non », et cela bien avant l'invention des GUI. Eh ben tiens alors, on va faire pareil, les utilisateurs comprendront facilement ! ET paf, les cases à cocher informatiques furent.
2 - Un choix et un seul parmi une liste finie d'options possibles. Traditionnellement sur papier, ça se présente aussi sous forme d'une série de cases qu'on peut cocher. Je ne sais pas si la forme ronde et la pastille caractéristique des boutons radio a été décidée dans un souci de différenciation uniquement au niveau informatique ou bien si on le faisait déjà sur papier bien avant, mais c'est la même idée, ne pas dérouter les utilisateurs en présentant une interface sous une forme plus ou moins familière / déjà connue.
En tout cas, en principe dans ce cas, ne cocher aucune des options proposées, même si ça reste possible, suppose quasiment toujours une erreur ou une saisie incomplète, même sur papier.
3 - Le texte libre. Pour ça, on a, tout simplement, les zones de texte, où on fait la différence entre le monoligne et le multiligne.

Plus tard, quelqu'un d'autre est arrivé avec la constatation que 5 boutons radio ou plus, ça emcombrait trop facilement l'écran et que ça rendait la saisie moins facile ou plus confuse du coup. ET paf, voilà les listes déroulantes; en ne perdant pas de vue que s'il n'y a aucune option sélectionnée, alors la saisie n'est pas complète. ET d'où la règle parfois évoquée de la vue d'ensemble ou de la limite des 5 (±2 selon les sources) options pour choisir entre liste déroulante ou boutons radio, car en fait, ils remplissent fondamentalement la même fonction.

Par contre, du côté des lises déroulantes, la première option sélectionnée par défaut est très souvent un pseudo-choix type « choisissez une option ». Conceptuellement, c'est totalement faux, le « choisissez une option » devrait être un placeholder (maintenant que ça existe), et le formulaire ne devrait pas pouvoir être envoyé tant qu'une véritable option n'a pas été sélectionnée.

Acte 4 dans l'histoire des GUI, on a innové dans le domaine de la saisie du texte libre. On a remarqué que le texte libre suit en réalité souvent des motifs bien définis, et n'est pas réellement libre. C'est là qu'on a ajouté les boutons ± pour faciliter la saisie de nombres précis, qu'on a inventé les sliders pour la saisie de nombres inscrits dans une fourchette bien définie mais où la précision exacte à l'unité près n'est pas forcément nécessaire (les sliders sont à l'image des potentiomètres et des glissières réelles, qui existaient aussi avant l'arrivée de l'informatique !), qu'on a imaginé les date picker pour faciliter la saisie de dates, etc. Par contre ici, on a perdu de vue, je ne sais pas pourquoi, qu'il est parfois plus facile de saisir une date manuellement plutôt que de naviguer dans un date picker, et du coup on n'offre même plus cette possibilité. Mais cette dernière petite constatation est aussi valable dans d'autres cas.

Bref, je ne sais pas jusqu'à quel point l'histoire des GUI que j'essaie de retracer ici colle vraiment à la réalité, mais c'est ma vision des choses. Désolé d'avoir fait si long !