Meilleur moyen pour les utilisateurs de sélectionner une plage de dates
Dans mon application, les utilisateurs sélectionnent une plage de dates pour laquelle des résultats sont requis. L'interface utilisateur ressemble à ceci:
Mes utilisateurs n'aiment pas cela, car le sélecteur de date les oblige à sélectionner une date spécifique. C'est beaucoup plus précis que nécessaire - la plupart des résultats compilés par le système ont des résultats mensuels ou trimestriels. Certains ne sont que annuels.
Les deux idées que j'ai trouvées sont les suivantes:
Sur la gauche, utilisez simplement une zone de liste déroulante pour sélectionner des dates valides. Le problème avec cette approche est que parfois les résultats seront quotidiens et que la plage de dates valide remonte aux années 1860. Cela représente beaucoup trop d'éléments à gérer dans une zone de liste déroulante.
À droite, à l'aide d'un trio de boites de dialogue pour sélectionner la date. Cela présente certains avantages. Si les résultats vont être mensuels, je pourrais désactiver le combo jour; si les résultats vont être trimestriels, je pourrais également restreindre les articles disponibles dans le combo du mois. Mais, il semble que cette conception nécessite un tas de clics pour être utilisée.
Qu'est-ce qu'une conception alternative pour l'UX qui permet aux utilisateurs de sélectionner simplement des dates "utiles" plus facilement?
Ma pile technologique est C #, WinForms, .NET 3.5
Mise à jour le 1er octobre
- Les plages de dates sélectionnées par mes utilisateurs sont généralement longues - plusieurs années à plusieurs décennies - entraînant des résultats clairsemés sur une longue période.
- Les seuls paramètres par défaut communs qui ont été identifiés sont "Dès que possible" pour la date de début, et "Jusqu'à aujourd'hui " comme date de fin.
Beaucoup de bonnes idées dans les réponses à ce jour - merci à tous.
Mise à jour le 2 octobre
- Certaines des réponses ci-dessous (et je suppose que beaucoup de lecteurs) supposent que j'ai besoin de la plage de dates pour la génération de rapports. En fait, cette partie particulière de mon application est plus un moteur de requête. Si ce détail inspire de nouvelles idées, veuillez répondre.
En général, les utilisateurs sont assez précis et rapides à saisir des dates sous forme de chaînes dans une zone de texte tant que votre validation n'est pas inutilement difficile et fournit une correction automatique décente et des valeurs par défaut pour les sous-champs (par exemple, en acceptant 2-9-04 comme ainsi que le 02/09/2004). Les contrôles de calendrier sont intéressants à fournir en option lorsque l'utilisateur n'est pas certain de la date (par exemple, dans les cas où l'utilisateur pense "mercredi la semaine prochaine"), mais ils ne devraient pas être le seul moyen d'entrer des dates. Des listes déroulantes distinctes pour chaque sous-champ ralentissent la tâche de l'utilisateur.
Si vous avez accès aux journaux de requêtes, étudiez-les pour mieux comprendre le type de dates utilisées par les utilisateurs. Bien que vous deviez prendre en charge des dates arbitraires remontant à 1860, vous n'aurez peut-être qu'à optimiser la conception pour un petit nombre de dates ou de modèles de date.
Voici quelques possibilités:
Valeurs par défaut. Il est possible que la plupart de vos requêtes soient prévisibles uniquement à partir de la page sur laquelle l'utilisateur se trouve (par exemple, pour le mois dernier ou le dernier trimestre ou l'année dernière selon la page/fenêtre). Par défaut, votre plage From-To correspond à ces valeurs pour chaque page et les utilisateurs n'auront presque jamais à entrer quoi que ce soit.
Liste des plages de dates typiques. Si quelques plages de dates constituent la grande majorité de vos requêtes (par exemple, chaque mois de l'année dernière), répertoriez-les dans une zone de liste ou une liste de boutons radio. Le dernier serait "Personnalisé" qui permet à quelques zones de texte avec des contrôles de calendrier de saisir par l'utilisateur des dates spécifiques.
Liste déroulante pour les entrées communes. S'il existe une liste prévisible relativement petite de valeurs De et À, fournissez une zone de liste déroulante De et À qui accepte chacune les dates saisies par l'utilisateur mais avec une liste déroulante des dates courantes De et À (par exemple, début de chaque trimestre dans la dernière année pour le champ De).
Zone de texte unique. Si la plupart des plages de dates sont des mois entiers, des trimestres et des années, fournissez deux méthodes pour saisir des plages de dates. La valeur par défaut comporte une seule zone de texte intitulée "Mois, trimestre ou année". qui accepte les entrées telles que "Sep" (par défaut, septembre le plus récent), "6/09", "3Q06" et "1933". Étudiez les documents écrits par les utilisateurs pour voir quels types de chaînes anticiper. La méthode non définie par défaut fournit des zones de texte From-To distinctes pour les dates arbitraires.
Micro-grammaires. Si ce sont principalement vos utilisateurs experts qui se plaignent de la saisie de la date, envisagez de prendre en charge les micro-grammaires pour les zones de texte De et À, où l'utilisateur peut entrer une date exacte ou divers autres raccourcis syntaxiques (par exemple, "Dernier trimestre" ou "LQ"). "Dans la zone Début est interprété comme tout du dernier trimestre terminé). Voir Collecte efficace de données avec des micro-grammaires de zone de texte
Pourquoi ne pas envisager un curseur de chronologie, avec les rapports les plus récents sur lesquels sélectionner des points d'accrochage?
Si vous avez des rapports remontant à 1860, à quelle fréquence doivent-ils revenir en arrière?
| Report XYZ, Jan 12, 1983 |
<--- Earlier \/ Later --->
|------------------------------||----------------------------------|
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Quelque chose comme ça pourrait leur permettre de le choisir visuellement? Avec la bulle au-dessus de la liste, cela devrait leur permettre de voir facilement ce qu'ils ont. Plus tôt/plus tard, un bouton/onglet s'arrête pour déplacer l'année, ou similaire. Le curseur est accessible au clavier.
Utilisez deux calendriers et atténuez les jours non sélectionnables. Vous donnerez à vos utilisateurs l'avantage des calendriers (être en mesure de voir un mois entier à la fois, sauter en arrière et en avant facilement dans le temps, et être en mesure de sélectionner n'importe quelle date qu'ils aiment) avec la contrainte de seulement certaines dates valides. Lorsqu'un utilisateur clique sur une date grisée, expliquez-lui pourquoi cette date n'est pas valide ou utilisez une légende.
Hipmunk.com fait un excellent travail de simplification. Ils ont deux calendriers en vue à tout moment et les dates avant aujourd'hui sont grisées (il est si évident de savoir pourquoi dans ce cas, ils n'ont pas besoin de préciser pourquoi, mais vous devrez peut-être). Un clic sur une date sélectionne la date de début et un nouveau clic sélectionne la date de fin. Notez comment ils ont également des champs de date en place afin que vous puissiez taper si vous le souhaitez, et les champs sont mis en évidence lorsque vous cliquez pour indiquer la date que vous allez sélectionner. Ce n'est pas conventionnel et ce n'est pas encore "ne me faites pas penser", mais c'est un excellent moyen de combiner ces commandes avec élégance sans ajouter un tas de widgets riches. Vérifiez-le:
Une chose que Hipmunk pourrait encore faire à l'OMI est de mettre en évidence les jours entre votre départ et votre retour, tout comme un détail visuel supplémentaire. En ce moment, vos yeux doivent encore analyser l'espace entre les deux dates comme "oh oui, chaque ligne de cette date jusqu'à cette date est l'endroit où je serai absent".
(Bonus génial: essayez de spécifier une date de départ après la date de retour)
Il s'agit en fait d'un logiciel Web que j'utilise au travail, mais l'idée peut être traduite assez facilement dans WinForms.
Je génère des rapports de plages de dates variables tout le temps avec ce contrôle. Les zones de texte ne sont pas masquées et pardonnent plutôt les valeurs qui peuvent être converties en dates, donc je peux texte libre différentes plages de dates sans problème. Une fois que vous avez tabulé hors du champ, la date est formatée dans un format de date "correct". S'il ne peut pas comprendre la date, le texte devient rouge et a un petit symbole d'erreur à côté de lui (comme si je tape une date ambiguë, comme 1109).
Si je dois faire quelque chose de spécifique, je peux cliquer sur le bouton du calendrier à droite de la zone de texte pour voir le calendrier (par exemple, si j'ai besoin de voir les rapports de la troisième semaine de mars 2009, je n'ai pas besoin de connaître les dates Du haut de ma tête).
Je préfère ce style, car il me faut à peine une seconde pour remplir les plages de dates - c'est juste 010109 tab 030109 tab puis je passe à la prochaine série de détails.
Haut, contrôle vide. Date du milieu, texte libre. Contrôle du bas, de la date et du calendrier
Quant à votre troisième option, j'ai un logiciel que je dois utiliser qui utilise ce style, et je le déteste - d'autant plus que je dois utiliser la souris. Je voudrais également souligner que les dates affichées sont les dates par défaut lorsque je charge la page, donc par défaut, il aimerait que je recherche des éléments supérieurs au futur, mais inférieurs au présent. Un ÉNORME inconvénient est que les années sont codées en dur dans les listes déroulantes - nous avons dû attendre jusqu'en février 2010 pour que 2010 soit ajouté afin de pouvoir rechercher quoi que ce soit récent.
Si vous savez à l'avance qu'une requête particulière n'a que des résultats trimestriels, vous pouvez en modifier la mise en page et choisir une sélection et une année comme celle-ci:
Et vous pouvez désactiver les trimestres de l'année en cours qui n'ont pas encore été générés.
Je n'ai pas lu toutes les réponses. Peut-être que quelqu'un a déjà suggéré de commencer par les contrôles dont la plupart des utilisateurs ont besoin la plupart du temps, puis de divulguer progressivement des contrôles supplémentaires. Par exemple, cliquez sur un lien pour afficher les contrôles pour le jour et le mois, pour plusieurs plages de dates qui ne se chevauchent pas, etc.
Ou ca:
Voici ma solution.
, 
Je suis amoureux du design utilisé dans le plugin jquery bootstrap-daterangepicker .
Fondamentalement, il a des plages par défaut et les champs de - à par défaut avec des sélecteurs de date qui mettent en évidence la plage sélectionnée. 
Champ de plage de dates défilable: 5 étapes d'interaction en tant qu'image .Png avec commentaires sur le russe!
Si cela est nécessaire - je peux faire l'instruction complète des zones d'interaction et fonctionnelles en anglais et page de démonstration.
Voici comment j'ai résolu un problème similaire ... vous pouvez modifier les 30 jours/60 jours/90 jours pour alerter les rapports les plus courants générés (annuel/trimestriel/mensuel). La fonctionnalité de plage de dates ouvre une info-bulle avec des capacités de plage de dates pour les utilisateurs qui recherchent spécifiquement une plage de dates, mais ne force pas un utilisateur à entrer des dates afin de générer des résultats. 
J'aime sa mise en œuvre dans l'application Google Agenda (MIUI). Il y a deux filateurs pour choisir la date et l'heure. Voilà à quoi ça ressemble:
Lorsque vous définissez la date et l'heure dans le premier sélecteur, le second est automatiquement réglé sur +1 heure.
qu'en est-il de l'utilisation du sélecteur de plage de dates jquery ui:
http://www.filamentgroup.com/lab/date_range_picker_using_jquery_ui_16_and_jquery_ui_css_framework/
vous pouvez préremplir certains paramètres par défaut et les configurer afin que l'année et le mois puissent être des listes déroulantes au lieu d'avoir simplement les flèches <> par mois.
Vous pouvez afficher un sélecteur de calendrier d'apparence normale, mais si l'utilisateur sélectionne le mois dans la barre de titre, il remplit automatiquement les dates de début et de fin comme début et fin du mois. De même pour l'année.
L'utilisateur peut remplacer la date de fin s'il souhaite une plage légèrement différente.
Je ne sais pas comment tu montrerais un quart.
Deux réflexions:
Pouvez-vous présenter différents sélecteurs de dates pour différents types de rapports (par exemple, vous avez dit que certains étaient annuels - dans ce cas, vous n'avez pas besoin de plus que l'année - ce qui pourrait être un simple champ de texte.)
La date de début/fin est-elle la façon dont les utilisateurs pensent au rapport? Dans plusieurs projets, j'ai travaillé sur les personnes qui veulent des rapports pensent en termes de date et de période plutôt qu'en deux dates. Ainsi, pour les rapports trimestriels, ils souhaiteraient peut-être commencer le troisième trimestre de 1980.