Saisie de la date: avec ou sans "bouton calendrier"?
Aujourd'hui, je travaille avec Primefaces et je dois choisir entre deux contrôles de saisie de date parmi ici: bouton Popup vs.
La différence:
Lorsque vous cliquez sur la saisie de texte "Popup", vous pouvez taper la date et AUSSI le calendrier s'affiche afin que vous puissiez sélectionner la date.
Lorsque vous cliquez sur la saisie de texte "bouton", vous pouvez uniquement taper et si vous souhaitez sélectionner dans le calendrier, vous devez cliquer sur le bouton pour l'ouvrir et sélectionner.
Je pense que celui avec le bouton est plus clair sur les résultats attendus et la spécificité de l'action, mais celui sans lui donne la même fonctionnalité (je pense que le niveau de confusion qui pourrait apporter est minimum car il n'y a qu'une entrée et une action finale ) donc je ne suis pas sûr que le bouton soit vraiment nécessaire.
Y a-t-il une raison pour laquelle je devrais considérer l'un plutôt que l'autre?
Quelqu'un l'a-t-il essayé avec des utilisateurs et remarqué une différence?
Existe-t-il une étude sur le sujet?
Je pense que vous avez presque répondu à votre propre question .
- L'approche par bouton permet de mieux communiquer le fonctionnement du widget, car elle est conforme au comportement idiomatique attendu pour la saisie de texte et le bouton de calendrier.
- L'approche contextuelle a un plus clair point d'entrée (seulement 1 contrôle) et nécessite seulement 1 clic (vs potentiel 2) pour que l'utilisateur puisse voir les deux options d'entrée.
Pour choisir entre les deux, déterminez simplement les qualités qui seront les plus importantes pour vos utilisateurs.
Si le widget va être utilisé fréquemment, utilisé par des experts, ou utilisé sous une forme dense où des boutons supplémentaires perturberont l'alignement de la grille ou ajouteront de l'encombrement, l'approche contextuelle peut être meilleure.
Si le widget est rarement utilisé, utilisé par des gens moins avertis en technologie ou utilisé dans des situations où les popups entrent en conflit avec les principes UX à l'échelle du site, alors le bouton peut être meilleur.
De nos jours, je préfère généralement l'approche popup, car:
- C'est plus rapide pour les utilisateurs experts et pour les utilisateurs novices
- Je préfère avoir un point d'entrée clair dans un widget plutôt que deux points d'entrée (bouton ou entrée), ce qui entraîne plus de charge cognitive car les utilisateurs doivent faire une pause pour choisir
- Un espace réservé ou une étiquette utile (par exemple Tapez ou sélectionnez une date (m/j/aa)) peut informer les utilisateurs qu'ils peuvent soit taper soit sélectionner
- Les contrôles de date contextuelle sont de plus en plus familiers aux utilisateurs grâce à leur utilisation populaire sur les sites d'agenda et de voyage
... mais c'est juste mon propre parti pris général. Il est plus important de déterminer quelles qualités seront utiles pour votre cas, d'où les compromis ci-dessus.
J'espère que cela pourra aider
Cet exemple avec lequel vous êtes allé n'est pas vraiment idéal. J'examinerais cela du point de vue de la façon dont l'utilisateur interagit avec le champ.
Prenez par exemple un utilisateur de clavier. S'ils tab dans un champ, il est probable qu'ils s'attendent à taper manuellement dans ce champ. Si la fenêtre contextuelle du calendrier apparaît également, à condition qu'elle n'obstrue pas le formulaire lui-même, il appartient à l'utilisateur de sélectionner la date - en tapant ou en déplaçant vers la souris et en la sélectionnant là (il ne semble pas que le calendrier soit le clavier -accessible dans cette démo).
Cependant, si l'utilisateur utilise le clavier et tabs pour le bouton de calendrier lui-même et le déclenche, vous pouvez supposer qu'il souhaite utiliser cette option de calendrier avec son clavier. Dans ce cas, le focus doit basculer sur le calendrier et leur permettre de choisir leur date à l'aide des touches fléchées.
Cet exemple ne leur permet pas vraiment de le faire, donc ce n'est pas celui que j'irais avec moi-même.
Personnellement, je prendrais l'approche champ + bouton et si l'utilisateur sélectionne le champ de texte (avec la souris ou le clavier), vous placez le curseur dessus pour qu'il puisse commencer à taper, et s'il sélectionne le bouton, vous transférez le focus à la fenêtre du calendrier.
Je suggérerais que l'option "Button" ait ses propres avantages et faiblesses.
Raison contre le 'Popup':
- Premièrement, si vous tabulez dans un champ plutôt que de cliquer dessus et qu'un calendrier déroulant apparaît sans que vous le demandiez, cela peut être gênant.
- Certains utilisateurs préfèrent taper uniquement et préfèrent ne pas être confrontés à une entrée secondaire sans la choisir. Alors qu'il est peu probable que vous aliéniez quelqu'un en lui faisant cliquer sur un bouton pour une option d'entrée visuelle secondaire.
- Pas idéal pour le toucher (voir pourquoi ci-dessous)
Raisons du 'bouton':
- Pas de surprise, les utilisateurs sont souvent anti-popup même lorsqu'ils sont des raccourcis utiles.
- Les utilisateurs ont l'option secondaire s'ils préfèrent et c'est un élément d'interface utilisateur suffisamment reconnaissable, donc cela ne causera pas de confusion.
- Écran tactile convivial, si un utilisateur clique sur le bouton, il peut utiliser cette option, tandis que dans le `` Popup '', si un utilisateur clique sur le champ du formulaire, son clavier apparaîtra et zoomera sur le champ et pourra ainsi potentiellement masquer partiellement le calendrier ou entièrement qui se sentra à la casse.
J'ai essayé de le diviser en pour et contre pour expliquer mon raisonnement derrière le choix de "Button" plutôt que de peser les avantages et les problèmes des deux.
Je souhaite que nous ayons utilisé Primefaces où je travaille, tout le monde est coincé avec Richfaces et c'est une douleur!
Le meilleur wuold serait si ouvert par le bouton ne désactiverait pas l'entrée, mais si ce n'est pas possible ... Je suis définitivement pour le popup.
Lorsque j'utilise le widget calendrier, je sélectionne parfois le jour dans la fenêtre contextuelle, puis je change l'année au clavier. Ceci est très important lorsque vous posez des questions sur la date de naissance, puis la date de voyage par exemple: dans le premier cas, en bloquant la saisie, je devrais cliquer à plusieurs reprises avant de pouvoir trouver mon année de naissance, dans le second cas, je peux gérer ce que je doivent sauter les mois prochains: alors quelle date vous demandez est un point.
Cependant, je pense qu'il est courant de voir un datepicker agir comme ça, même sans le bouton et les utilisateurs savent comment l'utiliser.