Quand faut-il ajouter un an à un horodatage?
Stack Exchange utilise des horodatages relatifs pour indiquer quand une action s'est produite; une question a été posée, une modification a été effectuée, etc. Cela se fait dès "il y a 2 jours"; quoi que ce soit avant il y a exactement 48 heures utilise l'horodatage complet. Si l'horodatage n'est pas dans l'année en cours, il inclut l'année.
Cependant, avec l'avènement d'une nouvelle année, cela semble créer une dissonance entre les dates, qui s'est produite il y a exactement deux jours alors qu'elles passaient de "il y a 2 jours" à l'année dernière.
Cette capture d'écran a été prise à 13:23:55 (UTC). J'ai utilisé Stack Overflow car il a le plus de questions mais c'est vrai pour tous les sites Stack Exchange.
Comme 2012 était l'année dernière, l'année a été ajoutée à l'horodatage, ce qui me donne l'impression que la question a été posée il y a plus longtemps qu'elle ne l'était réellement.
S'il n'est pas nécessaire d'inclure l'année, est-il plus compréhensible pour un utilisateur de ne pas la voir? C'est à dire. si c'est le 20e Juin 2013 devrait l'horodatage pour les dates après le 20e Juin 2012 pas inclure la partie année?
Votre solution proposée introduit également un saut. Si c'est le 20 juin 2013, et que je vois un article daté du "22 juin", je vais penser "juin de cette année", puis faire une double prise parce que c'est encore dans le futur. Quand c'est juin 2013, tous les articles de juin 2012 devraient être marqués "juin 12". À l'approche de la fin du mois, il serait peut-être bon de marquer les publications de juillet comme celles de l'année dernière.
Je pense que tout ce qui va du maintien du mois civil précédent sans année au maintien des 10 derniers mois civils sans année serait raisonnable. De cette façon, le "29 décembre" ressemble toujours à une date récente en janvier, mais un article qui a 11 mois a l'année supplémentaire comme marque d'âge.
Unix (je sais, ce n'est pas une référence courante dans un contexte UX) fait quelque chose comme ça lors de l'affichage des heures de fichier: les dates des fichiers au cours des 6 derniers mois sont affichées avec le mois, le jour, l'heure, les minutes tandis que les fichiers et les dates plus anciens à l'avenir sont affichés avec année, mois, jour. Cela a l'inconvénient de faire exactement un saut de 6 mois, je pense qu'il serait préférable d'aligner le saut avec un changement de mois civil.
Ce n'est pas un gros problème - quoi que vous fassiez, il y a un saut (d'il y a X jours à une date de calendrier).
Le site Web doit toujours inclure l'année dans le titre. Il s'agit de définir une norme non déroutante pour tout le monde. Il est également important pour les robots d'exploration et les scrappers Web, car la date UTC complète peut être facilement transformée en horodatage avec un seul appel de méthode, où les machines peuvent la comprendre.
Inclure l'année une fois que neuf mois se sont écoulés.
Vous ne voulez pas inclure l'année où elle est déduite, car c'est généralement une mauvaise idée d'augmenter le bruit sans augmentation du signal, en particulier lorsque ce bruit prend un horodatage au-dessus de l'échelle à dix caractères d'une seule fixation fovéa. Cela réduit la capacité de numérisation, ce qui pourrait être préjudiciable dans certains cas d'utilisation.
Cela étant dit, alors que les utilisateurs peuvent dire que `` 12 septembre '' signifie l'année dernière le 3 janvier, il pourrait falloir un peu plus de querelles mentales pour réaliser que quelque chose étiqueté `` 13 août '' vient du futur le 4 août. Il est beaucoup plus difficile de dire exactement si une date est en avant ou en arrière que de regarder et de se faire une idée de sa position "générale" dans le calendrier.
C'est pourquoi vous devez inclure le spécificateur d'année après 9 mois, plutôt que l'ensemble des 12.
Vous ne devriez vraiment pas avoir à faire trop réfléchir vos utilisateurs. Cela peut être évident maintenant, mais au milieu de l'année (disons avril), sera-t-il vraiment évident que "mars" signifie "il y a un mois" et "mai" signifie "il y a un an "? Pire encore, que se passe-t-il si c'est le 15 avril et que vous voyez "16 avril"? (cela peut être évité en le faisant au mois, cependant) C'est encore plus déroutant, surtout pour les gens comme moi qui ne gardent pas la date exacte en tout temps. Ce système oblige l'utilisateur à réfléchir une seconde parfois. Et, nous savons tous qu'un pilier central de l'utilisabilité est "Don't Make Me Think".
En revanche, le système actuel ne crée une légère confusion qu'aux alentours de janvier, date à laquelle 2012 vient de s'écouler. En février, le billet de décembre sera daté d'un certain temps.
Dans le cas de l'exemple SE, je ne vois pas d'énorme problème avec cela. Ce n'est pas comme si on vous disait que le message a été publié "il y a un an" par rapport à il y a quelques jours seulement.
Tant que vous laissez la date/l'heure sur un message plutôt que d'insister sur le fait qu'il y a juste "un an", 90% des gens seront assez intelligents pour comprendre que c'est récent, et les 10% restants s'en moquent.
Si vous voulez être pédant et résoudre ce problème, il serait insignifiant de dire que "tout ce qui a été publié la semaine dernière devrait utiliser des horodatages relatifs, et tout ce qui suit est daté".
Au moment où vous énoncez une date au lieu d'un temps écoulé (où 48 heures semblent vraiment fournir une bonne limite), l'année doit être mentionnée. Pourquoi? Imaginez simplement dans un avenir sombre et lointain un miroir qui ne connaissait pas votre Smart-date-adjuster (TM) devient la seule source disponible, sans aucune information sur la date réelle d'exploration.
Comment un visiteur devrait-il savoir maintenant si les informations fournies proviennent d'une période <12 mois ou non? Les informations pourraient être désespérément obsolètes ou encore assez utiles, mais sans date utile plus difficile à déterminer.
Essayer de réfléchir à toutes les façons de le faire et à ce qui a du sens pour moi ... (Je suis sûr que si tout le monde intervenait, il y aurait des milliers de suggestions différentes)
Je suppose que ce que je préférerais le plus serait de reporter les horodatages relatifs à 30 jours, puis d'afficher une date complète par la suite. Voir "il y a 2 heures" ou "il y a 10 jours" est super. Et puis quand je vois une date, je n'ai même pas besoin de la lire pour savoir que l'article a plus de 30 ans.
Je pense que nous sommes d'accord avec les années, je veux dire que nous remplissons tous des papiers avec des dates, et ces dates sont entièrement formatées et nous pouvons comprendre assez rapidement la différence entre janvier (un début d'année) et décembre (c'est la fin), donc, je pense que l'ajout de règles peu claires, comme sauter 6 (ou 9?) mois avant d'ajouter un an, ne fera qu'augmenter la complexité. Gardez les choses simples: l'année en cours uniquement est imprimée sans année.
Juste pour apporter un exemple d'un programme du monde réel qui le fait différemment, la commande ls trace la ligne à six mois. Cela ne semble pas être exactement six mois sur mon système, probablement pour faciliter le calcul:
-rw-rw-r-- 1 random random 0 Jul 3 2012 2012-07-03
-rw-rw-r-- 1 random random 0 Jul 4 00:00 2012-07-04
Et il passe immédiatement à l'inclusion de l'année pour tous les horodatages futurs:
-rw-rw-r-- 1 random random 0 Jan 1 00:00 2013-01-01
-rw-rw-r-- 1 random random 0 Jan 2 2013 2013-01-02
(Le YYYY-MM-DD portion est le nom du fichier, au cas où ce ne serait pas évident)
Dans ce cas, la même transition est utilisée pour ne plus afficher l'heure, car elle occupe le même espace que l'année. Cela conserve le cachet de la date dans dix caractères (hors espaces, douze avec) pour les deux formats pour une lisibilité facile.