Les horodatages UTC, tels que ceux des textes flottants de Stack Exchange, doivent-ils inclure le jour de la semaine?
Il y a proposition sur Meta Stack Exchange pour ajouter le jour de la semaine aux textes de survol pour les horodatages sur Stack Exchange, qui affichent actuellement un horodatage UTC brut, de la forme YYYY-MM-DD HH:MM:SSZ, où le "Z" est un littéral qui indique qu'il s'agit d'un horodatage UTC.
capture d'écran utilisée dans la proposition MSE, par rolfl
Le contexte, bien sûr, est un événement en ligne dans un système utilisé dans le monde entier. Les horodatages sont utilisés par diverses personnes à diverses fins. Certaines utilisations, comme souligné dans la proposition MSE, nécessitent de déterminer le jour local de la semaine associé à l'horodatage.
Il y a eu une discussion dans les commentaires sur la question de savoir si le jour de la semaine était précédé d'une avance, par exemple, Mon 2015-01-26 09:22:17Z, serait, dans l'ensemble, plus utile ou plus nuisible.
Utile : permet au téléspectateur de voir, d'un coup d'œil, le jour de la semaine (UTC) auquel l'événement s'est produit. L'afficheur peut traduire de l'UTC vers un autre fuseau horaire pertinent et, dans le processus, déterminer s'il faut ajuster le jour de la semaine ainsi que l'heure et la date.
Nocif : augmente la probabilité qu'un téléspectateur intéressé par le jour de la semaine passe à côté du fait qu'il s'agit d'un horodatage UTC et prendra le jour indiqué de la semaine comme valide.
Dans un tel contexte, les horodatages UTC devraient-ils inclure le jour de la semaine ou non?
Existe-t-il une documentation UX ou existe-t-il des principes de conception UX standard qui répondent à cette question?
Les horodatages ne sont pas destinés à la plupart des utilisateurs
Affichage de noms conviviaux tels que 2 hours ago ou yesterday peut rapidement fournir un contexte à l'utilisateur au lieu de le montrer 2015-01-27 18:54:03.259 Le mélange des deux formats entraînera toujours des frictions (tout ce qui oblige un utilisateur à poser une question dans son esprit ajoute à la friction cognitive). Dans presque tous les cas, les mélanger fera plus de mal que de bien, alors laissez le jour de la semaine. Même au détriment de la mise en contexte, il ne devrait pas y avoir de doute que ce que je regarde est un horodatage.
Alors que les formats de date conviviaux sont mieux affichés dans l'interface utilisateur par défaut, les horodatages doivent être masqués jusqu'à ce qu'un utilisateur le demande (comme passer la souris sur une date/heure affichée ou modifier un paramètre)
Les noms conviviaux tels que ceux utilisés dans Outlook offrent un meilleur contexte que Monday ou Friday. Les noms de chaque jour de la semaine perdent leur contexte tous les 7 jours. Dire Tuesday aujourd'hui pourrait aider un peu, mais dire Tuesday la semaine prochaine serait déroutant même sans apporter d'horodatage au mixage ...
L'affichage du jour de la semaine (par exemple, lundi, mardi) généralement n'a de sens que lorsque la date est passée récemment (c'est-à-dire au cours de la dernière semaine) ou dans le futur. Lorsqu'une date s'est récemment écoulée, l'indication du jour de la semaine facilite la reconnaissance dans ce contexte limité. Pour les événements futurs, il est plus utile de savoir quel jour de la semaine il doit avoir lieu que de consulter un calendrier séparé.
Pour quelque chose qui s'est produit il y a plusieurs semaines, mois ou années, il est peu utile de dire explicitement le jour. Je pense que cela vaut pour les questions sur Stack Exchange. Je ne vois aucune valeur réelle à l'ajout de ces informations supplémentaires et je vois une opportunité de provoquer une confusion avec les fuseaux horaires.
Le titre de la question (également répété dans le corps) est:
Les horodatages UTC doivent-ils inclure le jour de la semaine ou non?
La réponse est "ça dépend" :
- Si humains n'a pas besoin de connaître le jour de la semaine pour un horodatage, alors non.
- Si les humains ont besoin de connaître le jour de la semaine pour l'horodatage, mais ils peuvent faire traiter la date pour eux, afin de déterminer le jour de la semaine, alors non, l'horodatage de base n'en a pas besoin.
- Si les humains ont besoin de connaître le jour de la semaine pour l'horodatage et le processus de calcul de ces informations serait manuel, ou prendrait beaucoup de temps, puis l'avoir intégré dans l'horodatage fournirait une bien meilleure expérience utilisateur.
- Si aucun humain n'est impliqué, il n'est pas nécessaire d'inclure le jour de la semaine.
C'est la réponse de base à la question centrale.
La question divise les composants de la rétroaction en "utile" et "nuisible":
utile: permet au téléspectateur de voir, d'un coup d'œil, quel jour de la semaine (UTC ) l'événement s'est produit le
Voilà toute l'idée. L'utilisateur doit connaître la journée, il est donc certainement utile de le lui dire en un coup d'œil.
nuisible: augmente la probabilité qu'un téléspectateur intéressé par le jour de la semaine rate le fait que c'est un horodatage UTC et que le jour de la semaine affiché sera valide
C'est un élément UX plus important que le focus le jour de la semaine uniquement. Il y a déjà de la confusion au sujet des horodatages UTC, et les utilisateurs qui 'survolent' ces horodatages sont pour la plupart (tous?) Déjà au courant du fait qu'ils sont en UTC. L'ajout du jour de la semaine ne rendra pas ces utilisateurs plus confus. Ce n'est pas le DayOfWeek qui rend le fuseau horaire déroutant, mais l'UTC lui-même. De plus, il existe d'autres raisons pour lesquelles UTC est/a été choisi, et ces raisons dépassent le cadre de cette question/réponse.
En fin de compte, non, l'ajout du jour de la semaine ne le rendra pas plus déroutant qu'il ne l'est déjà . Beaucoup de gens ne savent pas que les horodatages sont déjà UTC, et c'est un problème UX différent.
Appliquer cette logique à l'exemple fourni dans la question meta.se :
- il y a un horodatage
- il y a un élément humain
- il faut connaître le jour de la semaine pour l'horodatage
- le système ne permet pas une possibilité facile ou automatique de présenter le jour de la semaine pour la date.
Pour la situation décrite dans la méta-question, la bonne réponse serait d'inclure le jour de la semaine dans l'horodatage.
Une question intéressante sur l'expérience utilisateur serait où dans l'horodatage, mais ce n'est pas ce ceci La question UX demande.
La queue de la question est:
Existe-t-il une documentation UX qui traite de cette question, ou existe-t-il des principes de conception UX standard qui le font?
La question de base est la suivante: un utilisateur doit connaître le jour de la semaine pour une date, le gouvernement américain a un site Web adapté à la convivialité: www.usability.gov et il a les composants clés suivants pour la convivialité:
image dans le domaine public, mais créditée à Peter Morville
Là où l'aspect "utilisable" est défini comme "le site doit être facile à utiliser", et l'aspect "trouvable" est défini comme "le contenu doit être navigable et localisable sur site et hors site"
Rendre les informations requises (jour de la semaine pour une date) uniquement disponibles hors site est clairement une violation des aspects d'utilisabilité et de trouvabilité.
Sur la base de votre question centrée sur le proposition MSE :
Je dirais que la réponse serait non !
Je ne pense pas que ce serait utile car les utilisateurs lisant LTR verraient le jour et l'heure et arrêteraient complètement la lecture et manqueraient le Z réalisant que c'était une date/heure UTC.
Je suggérerais plutôt qu'il serait utile dans le contexte où vous fournissez réellement à l'utilisateur une info-bulle qui affiche le Jour, date et heure en ce qui concerne leur décalage UTC (le cas échéant) ou leur culture actuelle.
Cette réponse de Matt Johnson semble être un pas dans la bonne direction.
Je pense qu'une solution est.
Ne modifiez pas le texte du survol. Mais ajoutez le jour de l'heure locale au message "demandé il y a 2 jours". Donc, affichez "demandé il y a 2 jours (Web)" ou "demandé le 6 mars 13 à 12:24". Je n'ai pas besoin de savoir si le jour est moins de 24 il y a le vôtre, ou hier.