Comment présenter les préréglages relatifs à un sélecteur de plage de dates
Nous développons un sélecteur de date et nous ne savons pas comment présenter les périodes prédéfinies. Le scénario est le suivant: Soit l'utilisateur utilise une période prédéfinie, par ex.
- 7 prochains jours
- 3 prochains mois
- 7 derniers jours
- 3 derniers mois
OU il/elle spécifie une date de début et une date de fin. Ma question est la suivante:
- Comment la fonctionnalité OR est-elle mieux représentée dans l'interface utilisateur?
Trois de nos multiples alternatives de conception sont:
Dans l'image ci-dessus, les "Paramètres alpha", etc. sont juste là pour montrer le sélecteur de date ranger dans le contexte d'autres contrôles.
Dans notre équipe, nous préférons l'alternative (C) car elle explique la relation OR de manière standard à l'aide des boutons radio. Cependant, on pourrait objecter qu'elle est trop expliquée, et que par exemple l'alternative ( B) est plus concis, mais si l'alternative (C) est la voie à suivre, comment cela devrait-il se comporter plus en détail, par exemple:
- Le choix d'une date prédéfinie doit-il remplir automatiquement les champs De et À sous la liste déroulante des préréglages?
- Et sinon: comment transmettre à l'utilisateur ce que "derniers 3 mois" signifie en termes de date de début exacte?
- L'option non sélectionnée doit-elle être grisée et réinitialisée?
- Et si c'est le cas, le champ non sélectionné doit-il devenir actif en cliquant non seulement sur le bouton radio correspondant, mais également sur les champs de saisie, par ex. la liste déroulante ou les champs de date?
Quelle est votre opinion à ce sujet? Quelle alternative préférez-vous - ou avez-vous de meilleures suggestions? Avez-vous de bons exemples de présentation de presets aux utilisateurs?
Dans cet ordre: B (avec la manipulation détaillée ci-dessous), A (épelé), C.
C est pour moi la "solution technicien typique": vous décidez d'abord comment spécifier la durée, puis vous spécifiez les données requises pour cet algorithme. Cependant, ce ne sont que deux contrôles supplémentaires à gérer, et les utilisateurs ne connaissent pas les options à venir. Cela dit, si vos utilisateurs sont des techniciens/penseurs analytiques et que c'est plus facile à mettre en œuvre, allez-y.
B serait préférable:
Exigences minimales:
- Les commandes "présélection" et date/heure sont toujours disponibles (jamais désactivées)
- la modification de la présélection modifie l'heure affichée dans les commandes de plage
- changer les commandes de plage change la présélection en "autre"
Presque parfait:
- comparer la sélection manuelle à vos préréglages et n'afficher "autre" que s'il n'y a pas de correspondance
- lorsque l'utilisateur sélectionne "autre" manuellement, affiche un indice comme "sélectionnez la date de début et de fin ici"
Avantages:
- Les utilisateurs ayant une vague idée de votre application disposent d'un ensemble d'options typiques
- Les utilisateurs reçoivent une rétroaction immédiate et concrète sur leurs choix
- Le choix peut être affiné, par ex. les "3 prochaines semaines" peuvent être facilement améliorées en "4 semaines"
Variantes:
- Au lieu de "autre", générez des représentations textuelles appropriées (par exemple, "les 17 prochains jours").
- Si l'application est principalement utilisée par des utilisateurs réguliers réguliers (quelques occasionnels), envisagez une entrée de texte gratuite comme Hisham l'a suggéré: cliquer sur pour saisir trois plages horaires dans une journée donnée est très bien, pour entrer 30 dans une heure est pénible, et du texte gratuit gagne.
(Je ne peux pas penser à une interface combinée simple qui ne pénalise pas en quelque sorte les utilisateurs novices, mais si vous attendez un large éventail d'utilisateurs, vous devrez peut-être envisager des solutions pour cela)
Notes de mise en page:
- J'omettrais le "de" purement pour un look épuré, mais il y a un compromis. J'essaie généralement de donner aux contrôles une taille égale et de les aligner sur quelques lignes pour éviter un aspect de "forme agitée".
- Grouper le préréglage et le sélecteur de date ensemble (c'est-à-dire les éloigner des autres sélections)
- "Duration" est bien sûr une étiquette stupide, désolé;)
(note latérale: instinctivement, je supposerais un intervalle de sept jours pour aller "du 17 février 0:00 au 23 février 23: 59: 59.9999 ..", mais je ne suis pas sûr que ce soit universel.)
Avez-vous envisagé de le faire de la manière 7 signaux le résoudre dans leurs applications? Champ de sélection unique avec des options "3 prochains jours", "7 prochains jours" et ainsi de suite, puis la dernière option étant "Plage personnalisée" (la microcopie n'est pas mon fort ici, j'admets, semble un peu trop technique) la dernière option afficherait les champs de datepicker.
Liste déroulante avec les options suivantes:
- 7 prochains jours
- 3 prochains mois
- 7 derniers jours
- 3 derniers mois
- personnalisé
Et quand ils sélectionnent les datepickers personnalisés apparaissent.
J'irais avec l'option C, mais avec quelques changements. À mon avis, le design est à carreaux en raison des périodes prédéfinies à options fixes:
Remplacez le menu contextuel des préréglages par un simple champ d'édition qui permet aux utilisateurs de taper, par exemple "7 jours" ou "7j". C'est un peu plus de travail car vous devez permettre aux utilisateurs d'abréger et d'analyser intelligemment, mais cela en vaut la peine, je pense.
Déposez les boutons radio; ce n'est plus une proposition "l'un ou l'autre".
Faites mettre à jour le champ d'édition automatiquement lorsque l'utilisateur fait une sélection sur les sélecteurs de date. Et vice versa: mettez automatiquement à jour les valeurs des sélecteurs de date lorsque l'utilisateur entre une nouvelle valeur dans le champ d'édition.
Remplacez le libellé "Période" par "Durée".
Ajoutez quelques étiquettes supplémentaires ici (De, À, etc.).
Je ne peux penser à rien d'autre. :-)
Je n'aime pas l'idée d'avoir deux types différents de champs de saisie pour manipuler les mêmes données. Je pense que ce serait déroutant. Dois-je sélectionner quelque chose dans le sélecteur de plage ET les deux champs de date? Que se passe-t-il si je règle manuellement la date dans les champs de date et que je sélectionne le sélecteur de plage par curiosité? Cela fonctionne-t-il toujours si je sélectionne une plage en premier et que je change une des dates? L'autre est-il changé pour s'adapter à la gamme? Tout cela n'est pas vraiment évident à partir des idées d'interface utilisateur.
Peut-être que c'est purement cosmétique, mais à mon humble avis, le sélecteur de plage ne devrait pas être un champ de formulaire, mais plutôt une sorte d'aide pour les deux champs de date. Quelque chose comme ca:
assistant de sélection de plage de dates
Et une fois que l'utilisateur a lui-même modifié l'une des dates, vous pouvez modifier l'assistant pour qu'il ne fonctionne que sur l'autre champ:
assistant de sélection de plage de dates 2
Le fait d'avoir les plages sous forme de liens au lieu d'un champ de formulaire indique au moins laquelle des données entrées compte à la fin.
(désolé, pas de réputation, donc je ne peux pas encore inclure d'images)
J'irais avec la version B parce que la période et les dates sélectionnables de - à sont connectées, par exemple si vous modifiez la période, les dates de début et de fin seront mises à jour et vice versa - si vous modifiez les dates de début et de fin, la période sera mise à jour.
La version A semble étrange car la période et les dates de début sont les mêmes, donc une logique "ou" entre les pauses.
La version C a un sélecteur inutile car vous n'avez pas à choisir de quelle manière vous entrerez le laps de temps, les deux mettront à jour les deux.