Les champs de formulaire les plus conviviaux pour saisir la date / l'heure?
Quelles sont les différentes façons d'avoir des champs dans une application pour la date, l'heure ou les deux? Quels sont les avantages et les inconvénients de chacun?
Les plus courants semblent être une combinaison de 2 à 3 listes déroulantes, ou un widget de calendrier de formulaire. Y a-t-il d'autres options disponibles? Lequel est le plus convivial?
Je crois qu'une zone de texte standard avec une indication du format attendu suffit souvent. Comme Kevin l'a mentionné, si vous utilisez un sélecteur de date, vous devez absolument fournir une méthode d'entrée directe. Beaucoup de gens préfèrent simplement taper la date.
Mais c'est ce que je fais sur Techinsurance.com ...
Bien sûr, j'ai également une validation côté client et serveur. La seule autre fonctionnalité que j'ai ajoutée est que s'ils entrent 12121999 ou 12-12-1999, le texte est automatiquement formaté avec des barres obliques lorsque vous perdez le focus dans la zone de texte. J'ai adopté cette technique en juin et elle a très bien fonctionné jusqu'à présent.
Je suis définitivement d'accord avec Rahul, que cela dépend du contexte. Un widget de calendrier est super utile pour reculer ou avancer de quelques mois, mais pas si bien pour choisir votre date de naissance - ce serait un cauchemar en cliquant!
Personnellement, je déteste ces listes déroulantes pour choisir votre date de naissance, car elles ont tendance à être difficile à atteindre votre sélection cible, mais j'en ai vu une astucieuse récemment dans le flux d'inscription sur Kontain.com. Comme vous pouvez le voir ci-dessous, ils ont présenté les options dans un tableau au lieu d'une liste (et ont fait de même pour le jour et l'année) et j'ai trouvé que c'était une amélioration impressionnante. Yay!
N'oubliez pas que la convivialité est le produit de votre audience et du domaine de votre application. Par exemple, si vous créez un service comme Kayak, vous vous concentrerez sur des utilisateurs raisonnablement avertis en technologie qui utiliseront beaucoup les contrôles de date au cours de leur expérience avec votre application. D'un autre côté, Google et Amazon ont un public plus large et moins d'interactions, ils ont donc des priorités différentes.
Dans cet esprit, voici quelques considérations:
Contrôle calendrier. Celles-ci peuvent être très utiles lorsque vous souhaitez communiquer des métadonnées supplémentaires sur les dates, heures ou périodes de temps lors de la sélection d'une date. Par exemple, sur un site de voyage, un utilisateur peut sélectionner une date pour réserver un hôtel. Vous pouvez utiliser le contrôle du calendrier pour indiquer les dates entièrement réservées. Étant donné que le contrôle du calendrier se compare le plus étroitement à son cousin du monde réel, le calendrier, vous rendez service aux utilisateurs en intégrant les interactions avec les dates et les heures dans leur modèle mental. Cependant, il existe des cas d'utilisation où les contrôles de calendrier deviennent maladroits; étant donné que le contrôle est modélisé autour de l'affichage d'un mois à la fois, vous repoussez le contrôle de sauter entre les mois dans des flèches ou des listes déroulantes (souvent). Cela peut être limitatif si vous essayez de donner à l'utilisateur plus de liberté pour choisir une date.
menus déroulants. Souvent, vous en verrez trois d'affilée: [Jour] [Mois] [Année]. Cela fonctionne bien lorsqu'un utilisateur sélectionne simplement une date qu'il connaît déjà à l'avance, comme sa date de naissance. Ils ne fonctionnent pas si bien si vous demandez à l'utilisateur de répéter une tâche impliquant des dates, car la plupart des utilisateurs utiliseront la souris et devront donc cliquer une fois sur chaque liste déroulante pour l'ouvrir, une fois sur chaque élément pour le sélectionner, et éventuellement faire défiler une longue liste (pour les dates de naissance, il n'est pas rare que le menu Année commence à 1920 et se termine à 2009). Assurez-vous d'en tenir compte si vous choisissez des menus déroulants.
champs de saisie de texte brut. Comme d'autres l'ont répondu, la bonne chose à propos des champs de saisie est que vous pouvez accepter pratiquement n'importe quoi. Dans ces cas, souvenez-vous des principes de conception de formulaire: n'imposez pas le formatage de votre base de données/backend à l'utilisateur final. Essayez d'être aussi généreux que possible en acceptant autant de formats que possible. Utilisez la validation côté client pour signaler les problèmes à l'utilisateur avant de soumettre le formulaire (les dates sont très faciles à valider en Javascript en donnant la chaîne remplie par l'utilisateur à la nouvelle fonction Date () et en voyant si vous obtenez une date).
Au-delà des contrôles, considérez certains principes de bon sens lorsque vous traitez avec des dates:
Vérifiez si l'utilisateur n'a pas fait d'erreur. Si vous concevez un site pour adolescents et que quelqu'un dit qu'ils sont nés en 1934, demandez-vous si cela devrait être une option et si c'est le cas, si vous devriez vérifier avec eux pour voir s'ils ont réellement 76 ans. Pas à des fins de validation de l'âge, mais comme un service à l'utilisateur. De même, si vous concevez un site de voyage, pensez à vérifier si l'utilisateur a vraiment l'intention de réserver des vacances à Hawaï en octobre 2011, pas en octobre.
Dans la plupart des cas, des sélections de temps spécifiques ne sont pas nécessaires et ne correspondent probablement pas au modèle mental de l'utilisateur. Lors de la planification d'un événement, la granularité maximale dont vous aurez probablement besoin est de 5 minutes d'intervalle. Offrez un contrôle qui permet aux utilisateurs de sélectionner 12:00, 12:05, 12:10 etc. plutôt que 60 options pour chaque minute. La granularité que vous décidez peut avoir un grand effet sur la convivialité du contrôle particulier que vous choisissez d'utiliser (comme les menus déroulants).
Regardez toujours au-delà des contrôles standard et dans le domaine des graphiques d'informations en option. Habituellement, ceux-ci seront compliqués et coûteux à mettre en œuvre, mais ils peuvent valoir la peine si la sélection de la date/heure est une caractéristique essentielle. Par exemple, hipmunk.com a une représentation visuelle fantastique des horaires de vol (lus, pas en entrée) qui pourrait être encore mieux s'il était interactif. Dans ces cas, n'oubliez pas de tenir compte des attentes de votre public.
Gardez la forme libre de saisie des données si possible
Les programmeurs sont paresseux! Laissez l'ordinateur fonctionner un peu et pensez à ne pas avoir de champ de date spécifique pour la saisie de la date initiale. Google Agenda, lors de la création d'un nouvel événement, vous permet simplement de dire:
- 4 juillet: dîner chez Joe
GC comprend ensuite tout cela pour vous (y compris où), et, en fonction de la localisation de votre profil utilisateur, sera intelligent sur ce que signifie 4/7: dîner chez Joe. Pour l'édition ultérieure, le contrôle du calendrier GC est agréable et facile à utiliser. Tenez compte des éléments suivants et de la facilité avec laquelle cela serait pour les utilisateurs:
- jeu suivant
- en 4 heures
- dans 2 semaines
Et ... SHOCK HORROR que se passe-t-il si l'utilisateur ne sait pas ?? Je n'ai pas beaucoup vu cela, mais pourquoi n'est-ce pas une entrée de date acceptable dans certaines circonstances:
- Dans environ 3 jours
Je sais que cela fait peur :) Mais Tog On Software Design , Bruce Tognazzini (auteur original de Apple Human Interface Guidelines) décrit la mise en œuvre de l'expérience utilisateur est un peu comme une magie astuce: "une illusion": semble facile, mais en dessous, toutes sortes de folie se passe.
J'obtiendrais le logiciel pour mettre un rappel automatique 1d avant de dire `` hé, maintenant vous vouliez faire des choses ''
Aussi, utilisez le contexte autant que possible:
- avant l'anniversaire de Joe
... si vous avez des contacts ou un graphique social, cela devrait être facile à comprendre; sinon, demandez.
Considérez plus d'un mois
Lorsque vous avez des plages de dates, considérez que les limites de mois sont un réel problème pour les vues de calendrier qui affichent un seul mois. iCal sur Mac est soigné de cette façon, car vous pouvez afficher un nombre quelconque de mois afin que vous puissiez facilement vérifier ce que signifient les dates exactes de "entre 2 et 3 semaines à partir de maintenant".
Normalement, j'utilise simplement une zone de texte standard et j'y ajoute le Jpery UI Datepicker.
Lorsque l'utilisateur met l'accent sur la zone de texte par onglet ou en cliquant ou que le contrôle du calendrier apparaît temporairement en dessous - sans perturber la saisie de texte:
L'utilisateur peut alors soit taper simplement une date dans n'importe quel format analysable, soit utiliser la souris avec la fenêtre contextuelle du calendrier. Sélectionner une date avec la souris la tapera simplement dans la zone de texte au format préféré du site pour l'utilisateur et fermera la fenêtre contextuelle.
Pour l'entrée de temps, j'ai trouvé quelque chose de similaire fait par quelqu'un que j'ai oublié qui, mais avec les (12 ou 24) heures apparaissant dans un widget tabulaire, sélectionnant une heure, puis affiche quelques options de minutes de choix comme 0, 15, 30 et 45. Comme avant, juste taper l'heure fonctionne très bien, en ignorant le popup.
En outre, un contrôle de calendrier peut être réglé pour afficher plus d'un mois à la fois, je l'ai généralement affiché 2-3 mois les uns à côté des autres - selon le contexte de la date. L'entrée de date dans mon cas tourne généralement autour du trimestre en cours. Une entrée de date de naissance ne fonctionnerait pas aussi bien que quelqu'un l'a déjà souligné ^^
Une alternative courante à plusieurs menus déroulants ou widgets est le texte d'aide au formatage standard. Parfois, vous le verrez à l'intérieur du champ de texte comme valeur par défaut et parfois à droite/en dessous du champ. Le texte par défaut dirait quelque chose comme "MM/DD/YYYY" ou "jj-mm-aaaa". Voici un exemple du formulaire d'inscription de Google:
Cela donne à l'utilisateur un contrôle total sur ce qu'il doit saisir et n'utilise qu'un seul champ de texte. Un inconvénient de cette approche est la nécessité d'une validation côté client supplémentaire pour s'assurer qu'ils ont respecté la convention de date appropriée.
La première question est de savoir combien de champs de saisie de date vous avez dans l'application et à quelle fréquence ils sont utilisés.
Si vous devez entrer votre jour de naissance lorsque vous vous inscrivez et c'est tout, eh bien, cela ne devrait probablement pas être une priorité pour vous.
Mais si vous avez beaucoup de dates, il y a des points à considérer dont personne n'a encore parlé:
Vous devez prendre soin du format de date préféré de l'utilisateur (je ne suis pas aux États-Unis, je veux que mes dates soient au format JJ/MM/AAAA, ces dates américaines avec le mois au début sont difficiles à lire et type).
En outre, considérez les autres contrôles autour du champ de date, s'il s'agit d'une page conçue pour que l'utilisateur interagisse avec elle avec la souris, vous devriez avoir un sélecteur de date qui ne peut être utilisé qu'avec la souris, par contre si vous avez des champs de texte autour de la date à laquelle l'utilisateur est susceptible d'être en "mode de frappe" et forcer une interaction qui nécessite la souris (comme plusieurs listes déroulantes) peut être ennuyeux.
Et enfin, vos utilisateurs ne sont pas mes utilisateurs, vous devez le tester, donner à la moitié des utilisateurs un champ de texte et un demi-calendrier graphique, mesurer combien d'utilisateurs remplissent chaque formulaire et combien de temps il faut en moyenne à chaque groupe pour remplir le formulaire .
Si c'est assez important pour l'obséder ici, c'est assez important pour le tester.
Mes deux cents: je suis aveugle et je pense que la meilleure chose est: 3 combo box! Une alternative pourrait être 2 combo box pour les mois et les jours et un texte d'entrée pour l'année mais vous devriez faire un contrôle sur ce champ ... Si je pense en tant que programmeur, je préfère un seul texte d'entrée mais si vous pensez que dans votre site pourrait être un "utilisateur noob" Je pense que la meilleure chose est la première option :)
En ce qui concerne la vitesse et la facilité d'utilisation, rien ne vaut la simple entrée numérique, par ex. 21/09/201. Utilisez un zone de texte unique mais (en dehors des "/" et "-") communs, acceptez également les onglets pour passer d'un champ au suivant une. Frapper "[tab]" devrait insérer un séparateur. En tant que séparateur, je préfère le tiret, car il sépare les champs plus clairement.
Ne forcez pas les gens à taper des zéros non significatifs.
Je n'utiliserais pas la saisie de texte comme des mois abrégés comme Bevan l'a suggéré car ils prennent plus de temps à entrer. Aussi, comment abréger? Trois lettres? Quatre? Comme je l'ai dit dans ma réponse à Bevan, c'est surtout une mauvaise idée si vous travaillez avec un public international; "Septembre" peut ne pas être "septembre" dans la langue de votre utilisateur.
Parler de publics internationaux: tout le monde n'utilise pas l'ordre MM-DD-YYYY (en fait, en dehors des États-Unis, presque personne ne le fait). Vous pouvez indiquer l'ordre requis sous la zone de texte. Une façon d'éviter l'ambiguïté de dates comme 5-06-201 est d'utiliser le format ISO 8601 YYYY-MM-DD.
Donnez une entrée de texte où l'utilisateur peut taper la date avec un indice du format qu'il peut utiliser, mais acceptez tout format sans ambiguïté indépendamment des séparateurs ou du nombre de chiffres. Lorsque l'utilisateur tape quelque chose d'autre que le format standard, mettez-le immédiatement à jour au format standard afin que l'utilisateur voit exactement comment vous interprétez la date sans ambiguïté. L'ajout d'une icône de calendrier pour donner aux utilisateurs qui souhaitent une option de sélection dans un calendrier est également bon - les utilisateurs qui veulent saisir une date n'ont pas à l'utiliser.
Je faisais juste quelques recherches à ce sujet. Les applications d'agenda sont un bon point de départ. Ma disposition préférée est la date avec l'heure à droite. Je n'aime pas le format date-heure-heure-date de l'agenda Google, mais le sélecteur de date et le menu déroulant sont assez clairement exécutés.
(Je n'ai pas pu poster l'image de celle-ci, mais je vous encourage à la vérifier)