Désactiver les dates passées ou afficher un message d'erreur?
Je travaille sur un projet où il y a un champ de datepicker. Les utilisateurs ne sont pas autorisés à choisir des dates passées (seules les dates actuelles et futures le permettent). À l'heure actuelle, nous avons deux options pour concevoir cela, soit:
- Désactiver les dates passées du sélecteur de dates
- Autoriser l'utilisateur à choisir des dates antérieures et afficher un message d'erreur s'il choisit une date antérieure
Quelle option dois-je choisir et quelles sont les raisons à l'appui? Besoin d'un raisonnement concret pour convaincre les autres membres de l'équipe.
Tout conseil, aide ou article lié serait d'une grande aide. Merci d'avance!
1 est la meilleure option car vous ne demandez pas à l'utilisateur d'effectuer un ensemble d'actions qui entraîneraient un message d'erreur. Il vaut mieux éviter le risque d'une erreur plutôt que de laisser l'utilisateur faire l'erreur et inciter l'utilisateur à faire quelque chose de mal.
vous pouvez désactiver les dates et afficher une info-bulle si l'utilisateur essaie de sélectionner les dates désactivées
Tous les deux.
Comme d'autres l'ont dit, il est préférable de désactiver les dates passées pour minimiser le risque de mauvaises données, mais vous devez également tenir compte du fait que parfois les choses ne fonctionnent pas comme prévu et toujours valider les données.
Si vous acceptez aveuglément l'entrée, que se passera-t-il si l'utilisateur trouve un moyen d'entrer une date dans le passé? S'ils trouvent un bogue et l'exploitent, alors vous ne vérifiez pas la validité ou leur faites savoir qu'ils ont fait quelque chose de mal, ils le feront probablement à nouveau à l'avenir et ne savent pas qu'ils ne devraient pas l'être.
En un mot:
- Limitez la plage dans le sélecteur de dates pour les décourager visuellement d'utiliser des dates antérieures ou non valides
- Vérifiez toujours leurs commentaires et faites-leur savoir s'ils ont fait quelque chose de mal.
L'option 1 est bien meilleure que l'option 2 car:
Il fournit un signal visuel indiquant que les dates passées ne peuvent pas être sélectionnées. Par conséquent, il empêche les erreurs (sélection de la date passée) de se produire. C'est sans erreur.
L'affichage d'un message d'erreur a un coût d'interaction élevé - si un utilisateur sélectionne une mauvaise date, un message d'erreur apparaîtra. Cela oblige l'utilisateur à lire et à comprendre le message, ce qui nécessite des ressources cognitives. Après cela, il doit cliquer pour fermer le message, encore une fois ce clic inutile qui pourrait être évité. Par rapport à la simple désactivation des dates passées où l'utilisateur peut ne pas cliquer du tout parce que les champs sont désactivés.
Fondamentalement, vous pouvez dire que la fermeture d'un message d'erreur nécessite plus de ressources cognitives (charge cognitive) que de restreindre les options de l'utilisateur. Et cela est conforme à l'heuristique d'utilisation pour minimiser la charge de mémoire à court terme des utilisateurs .
Les deux et...
. Ainsi, tout ce qui contrôle cette capacité doit contrôler toutes les façons d'entrer des données et permettre aux deux situations de coexister.
Programmation en limitations signifie généralement que vous devez les programmer plus tard. Essayez de rendre tout ce qui est piloté par les données et configurable dans toute la mesure du possible. Ensuite, vous pouvez changer quelque chose en un seul endroit et cela s'applique partout. (Aucun conseil pour vous sur la façon de rendre votre cerveau aussi intelligent.)
Empêchez les erreurs dans la mesure du possible
Jakob Nielsen l'a bien dit dans son 10 Heuristics for UI Design :
Prévention des erreurs
Encore mieux que de bons messages d'erreur est une conception soignée qui empêche un problème de se produire en premier lieu. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant de s'engager dans l'action.
Le but de votre conception est de faire des erreurs un cas Edge. Ils vont arriver, mais vous voulez que ce soit rare.
Comme quelqu'un d'autre l'a noté ici, il est bon de prendre en charge les widgets de calendrier natifs sur mobile dans la plupart des cas. Mais si vous concevez le vôtre (que vous voudrez sur le bureau), expliquez clairement la limitation. Vous pouvez même avoir besoin d'une sorte d'indice dans l'interface utilisateur expliquant pourquoi il n'y a pas de dates passées.
Des erreurs se produiront
Comme je l'ai dit ci-dessus, vous ne pouvez souvent pas éviter entièrement les erreurs avec n'importe quel composant. Par exemple, votre système ajoute-t-il des paramètres à l'URL pour spécifier la plage de dates? C'est une bonne chose pour partager des vues avec d'autres, mais que se passe-t-il si l'URL est suivie plus tard et que la plage est devenue invalide?
Vous avez besoin de messages d'erreur bien conçus et suffisamment succincts pour que les utilisateurs ne les ignorent pas (à quelle vitesse frappez-vous esc?) mais suffisamment descriptif pour savoir exactement quoi faire ensuite.