J'ai des cases à cocher avec des valeurs de texte de longueurs variables (disons 5 caractères jusqu'à environ 60) - quelle est la disposition préférée? Valeur à gauche et case à cocher à droite, ou vice versa?
Bien que Microsoft et Apple ne soient pas explicites sur ce problème, Java Swing Look and Feel Guidelines indique explicitement que le label/value doit être à droite de la commande pour les langues lues de gauche à droite La même chose s'applique aux boutons radio .
L'ancien style de motif OSF indique également explicitement que l'étiquette est à droite des cases à cocher et des boutons radio (pg9-133). Et, pendant que nous faisons de l'archéologie, les normes IBM Common User Access stipulent que l'étiquette est à droite d'une case à cocher , mais elles sont silencieuses sur les boutons radio .
Quelles que soient les normes explicites, il est clair que les concepteurs doivent placer l'étiquette à droite du contrôle. Le raisonnement est probablement ce que vous intuitivez. Lorsque vous avez une colonne de cases à cocher avec des étiquettes de différentes longueurs, cette disposition permet aux cases à cocher et au début des étiquettes d'être alignées de manière cohérente sans aucun grand écart entre les étiquettes et les contrôles, en évitant soigneusement les problèmes d'alignement des étiquettes que les zones de texte et les listes déroulantes ont. Dans le monde des arbres morts, les étiquettes se trouvent souvent à droite des cases à cocher et des équivalents de boutons radio (par exemple, des bulles sur des formulaires scannés optiquement), donc cela ne jette pas les utilisateurs.
Pour choisir un ou plusieurs choix, étiquetez vers la droite. Cela permet un balayage visuel facile et laisse la souris/le doigt de l'utilisateur couler en ligne droite:
[ ] option 1
[ ] this is option 2
[ ] #3
Si l'étiquette était à gauche, ce serait un peu le bordel:
option 1 [ ]
this is option 2 [ ]
#3 [ ]
De plus, vous aurez souvent une étiquette "groupe" et bien que cela puisse certainement être placé en haut, c'est souvent à gauche:
Pick one or more options: [ ] option 1
[ ] this is option 2
[ ] #3
Notez que quel que soit le positionnement, les étiquettes doivent également être cliquables (utilisez les attributs FOR appropriés). Le problème est que tout le monde ne le sait pas et vise la case à cocher elle-même, donc les aligner aide.
Cependant, quand il n'y a qu'une seule case - généralement utilisée pour un processus d'adhésion ou de désinscription explicite, je pense que c'est OK de le mettre ensuite pour en faire une tâche un peu légère (comme vous voulez vraiment que les gens lire l'étiquette):
To opt in to our incessant spam emails we ask that you click this checkbox: [ ]
Si nous ignorons la possibilité d'un ordre de lecture de droite à gauche (utilisé dans certaines langues), je pense que l'étiquette devrait toujours être sur le côté droit de la case à cocher.
Sous Windows, il est en effet impossible de mettre une étiquette à gauche d'une case à cocher, d'un point de vue technique. Dans tout environnement de développement de logiciels Windows, une étiquette de case à cocher sera automatiquement sur le côté droit de la case à cocher. Il n'y a aucun moyen de changer cela. Ce que certains programmeurs vont faire est de créer une case à cocher sans étiquette du tout, puis de mettre une étiquette statique à gauche en tant que contrôle séparé. En plus d'être laid, il présente un inconvénient majeur: un utilisateur ne peut pas cliquer sur l'étiquette pour modifier l'état de la case à cocher.
Il devrait donc toujours être sur le côté droit de la case à cocher. Cependant ... Je sais que certaines personnes (et je ne suis pas d'accord avec elles) pensent qu'il y a une exception: lorsque la case à cocher fait partie d'une liste d'autres contrôles. Voir cet exemple:
Il y a donc des gens qui pensent que c'est bien parce que l'alignement est plus joli. Je ne. Je pense que la position de la case à cocher est correcte, mais la position de l'étiquette n'est pas correcte. Voyez-vous cela comme une exception?
L'hypothèse de base est que vous souhaitez utiliser l'option la plus lisible.
Un aspect important est scannability, comme il est facile d'obtenir un aperçu sans considérer consciemment chaque élément dans son intégralité. À cette fin, il est important que les cases à cocher aient une largeur constante. si vous alignez verticalement un côté des cases à cocher, l'autre côté sera également aligné verticalement. Le texte est de largeur variable, donc cela ne peut généralement pas être réalisé sans étirer le texte (ce qui peut le rendre très difficile à lire). Il est généralement recommandé de mettre les mots importants au début des phrases, donc pour le texte LTR, nous devons prioriser l'alignement à gauche sur l'alignement à droite.
Un autre problème est proximité, la proximité des informations pertinentes. Si nous plaçons les cases à droite de l'étiquette et les alignons verticalement, elles seront plus éloignées des étiquettes que si nous les mettons à gauche. La réponse semble donc être de les mettre du côté gauche.
D'un autre côté, vous devez considérer cohérence dans le formulaire. La plupart des contrôles de formulaire ne sont pas de largeur constante, et les placer à gauche de leurs étiquettes peut souvent créer un flux gênant (par exemple, placer le champ de saisie d'anniversaire à gauche de l'étiquette), où l'utilisateur doit faire des allers-retours pour numériser le formulaire. Un compromis serait d'utiliser des contrôles alignés à gauche uniquement s'ils sont tous de largeur constante et égale.
Une autre chose à considérer est qu'un ensemble de boutons radio est équivalent au HTML par défaut <select>
liste, tandis que les cases à cocher sont équivalentes à <select multiple="multiple">
.
Ma réponse instantanée est que la case à cocher doit être à gauche de l'étiquette, mais avant de répondre, je voulais valider les recommandations.
Malheureusement, les directives de Microsoft, Sun et IBM sur l'interface utilisateur ne sont pas explicites à cet égard (elles ont tendance à parler du moment où utiliser les cases à cocher sur le bouton radio, etc.), mais tous leurs exemples utilisent la convention de contrôle puis d'étiquetage.
J'opterais donc pour cela.
Du point de vue du programmeur, la case doit précéder le texte, car il est plus facile à aligner. Du point de vue de l'utilisateur, le texte doit venir en premier, car nous 1) lisons à quoi sert cette case à cocher 2) décidons de cliquer dessus ou non, dans cet ordre. La mise en page doit donc refléter le plan d'action de l'utilisateur.
Cela dépend de l'utilisation de la case à cocher.
cases à cocher de sélection (par exemple dans une liste d'éléments) doit être `` avant '' le texte (donc, à gauche dans une langue de gauche à droite comme l'anglais). Cela vous permet d'aligner à gauche les éléments et de toujours aligner les cases à cocher sans espaces inutiles. Il place également le mécanisme de sélection près du début de l'étiquette - les gens n'ont pas tendance à lire l'intégralité de l'étiquette, mais plutôt à la numériser, et cela commence au milieu à gauche.
Dans une liste de contrôle, les cases à cocher doivent précéder le texte, sans aucun doute. Les utilisateurs cherchent à agir sur les cases à cocher et analysent comme ci-dessus.
cases à cocher Options, dans le contexte d'autres options, peut être après l'étiquette. Cependant, en général, j'essaie de rester à l'écart des cases à cocher, car elles sont plutôt peu communicatives. Les contrôles plus récents comme le curseur de l'iPhone sont plus communicatifs, ou vous pouvez utiliser des boutons bistates, des listes déroulantes ou d'autres méthodes pour donner à l'utilisateur plus d'informations qu'un simple "vérifié/non vérifié".
Les boîtes à outils GUI de bureau telles que SWT encapsulent les cases à cocher en tant que variante de widget de bouton, où la propriété de texte du bouton devient l'étiquette. Il sera rendu, au moins sur les systèmes que je connais, à droite de la case à cocher. Contrairement au html, vous n'avez même pas à faire de choix.
Je vote pour "l'étiquette vient après" dans les langues LTR, simple, les gens vont scanner les choix et faire des vérifications en cliquant sur le début de l'étiquette (elle devrait être prise en charge), ou s'ils sont moins à l'aise avec l'ordinateur, recherchez le case à cocher, s'il y a comme 5 cases à cocher de différentes longueurs d'étiquette, imaginez le voyage que leurs mains, leurs yeux et leur cerveau doivent faire de l'étiquette à la case à cocher équivalente ... douloureux! donc la case à cocher doit être la plus proche possible de l'étiquette pour minimiser ce trajet
Donc pour un logiciel Windows ou Apple Apple, il semble clair de mettre la case à cocher à gauche. Si c'est à droite, pour respecter les principes de Gelstat, les étiquettes doivent être alignées à droite pour que les cases à cocher soient alignées verticalement ...
Mais pour le logiciel de périphérique mobile, la case à cocher à droite des étiquettes semble meilleure pour l'accessibilité. ..
Jetez un oeil sur SMS gestionnaire de smartphone lorsque vous souhaitez supprimer certains messages ....
Je voterais également pour le fait de suivre le modèle de "contrôle puis étiquetage" auquel quelqu'un a fait référence, mais avec la mise en garde que le contexte devrait prévaloir sur la convention.
Par exemple: Il existe un formulaire d'aide gouvernementale en ligne qui demande aux utilisateurs de rassembler plusieurs documents avant de commencer. Le système ne permet aux utilisateurs de passer à l'étape 1 du formulaire que s'ils ont coché chacun des éléments de la liste. Dans ce cas, les cases à cocher forment une liste de contrôle, dont l'écrasante majorité met des cases à gauche.
D'un autre côté, disons que nous avons un certain type d'application de vente au détail/vente avec une section de gestion des employés, et pour une raison quelconque, vous pouvez sélectionner plusieurs utilisateurs via une case à cocher, comme ceci:
Name Title Hire Date Select
-------- --------------- --------- ------
John Doe Sales Associate 9/12/03 [x]
Jane Doe Regional Manager 12/3/01 [x]
Dans ce cas, je pense que les cases à cocher devraient être à droite car la connotation est différente (vous sélectionnez des éléments pour une action ultérieure, pas pour une élimination de la liste). IOS (rien de spécifique dans le HIG, bizarrement) et Android ( http://developer.Android.com/guide/topics/ui/controls/checkbox.html =) faites flotter les cases à droite. Pour moi, cela a le plus de sens pour ce type d'application car cela donne une certaine distinction visuelle aux cases à cocher; les faire flotter à gauche dans ce cas serait, à mon avis, un peu d'alignement discordant- sage.
Il n'y a pas de taille unique, mais une chose à considérer est la cohérence. Vous remarquerez que certains prétendent que le fait d'avoir la case à cocher à gauche et l'étiquette à droite permet un meilleur alignement ... et pourtant ne préconiserait probablement jamais qu'un contrôle de zone d'édition soit visible à gauche de son étiquette descriptive. Si l'alignement était si important, ils le feraient aussi pour cela.
Certains autres mentionnent que la lecture de gauche à droite est pertinente pour avoir la case à cocher à gauche de l'étiquette ... comme si la lecture du texte en premier et le suivi direct de la case à cocher (réponse à ce texte) est moins intuitive que d'avoir un case à cocher ... en sautant pour lire l'étiquette, puis en revenant vers la gauche pour mettre votre entrée (essentiellement la réponse à l'étiquette). Il est difficile de voir comment avoir à fournir la réponse avant la question est fondamentalement plus intuitif.
Donc, au moins pour les interfaces de type formulaire avec de nombreuses entrées, il est clair que les cases à cocher doivent être à droite comme tous les autres contrôles d'entrée.