- Les libellés de date relative dans les interfaces web ont l’air plus humains, mais ils correspondent souvent mal à la façon dont les utilisateurs se représentent réellement les dates
- Pour une personne, « yesterday » désigne la veille, de 0 h à 23 h 59, et non simplement « il y a moins de 24 heures »
- Si le critère varie selon l’implémentation, l’affichage de « yesterday » devient incohérent même au sein d’un même service, ce qui réduit la fiabilité perçue de l’affichage des dates
- Afficher depuis combien de jours uniquement sous forme numérique, comme « 12 days ago », s’éloigne de la perception du temps que les gens utilisent naturellement
- « last week/month/year » reste aussi ambigu à cause de plages trop larges ; pour les éléments antérieurs à hier, il est donc plus clair d’afficher une date précise
Pourquoi les libellés de date relative prêtent à confusion
- Des expressions comme « yesterday », « 2 days ago » ou « a week ago » semblent être des formulations temporelles humaines, mais elles ne sont pas assez précises pour juger d’une date réelle
- En particulier, « yesterday » a un sens clair dans l’esprit des utilisateurs
- signifie la veille
- désigne la période allant de 0 h à 23 h 59 du jour précédent
- ce n’est pas la même chose qu’un calcul de type « moins de 24 heures »
- Les ordinateurs peuvent implémenter « yesterday » de façons différentes, et si l’affichage varie au sein d’un même service, les utilisateurs font moins confiance à l’information de date
Pour les éléments plus anciens, mieux vaut afficher une date
- Une expression comme « 12 days ago » correspond mal à la manière dont les gens découpent habituellement le temps
- « last week », « last month » et « last year » restent eux aussi ambiguës à cause de leur portée très large
- Pour les éléments antérieurs à hier, il est plus facile à lire et plus fiable d’afficher une date précise plutôt qu’une formulation relative
3 commentaires
GitHub et YouTube aussi, franchement, j’ai horreur de ce genre d’affichage du type « il y a quelques mois » ou « il y a quelques années ». Comme le disent aussi certains avis sur HN ci-dessous, un « il y a 1 an » peut en réalité vouloir dire il y a un an et demi, donc c’est beaucoup trop ambigu.
Je suis tout à fait d’accord avec ça. Du point de vue de la conception, afficher « il y a xx jours » évite certes d’avoir à se soucier des différents formats de date selon les pays, comme AA.MM.JJ ou MM/JJ/AAAA, mais personnellement je préfère voir une vraie date plutôt que « il y a xx jours ».
Commentaires sur Hacker News
En particulier, l’affichage en temps relatif devient beaucoup trop imprécis
Sur YouTube, « il y a 1 an » peut vouloir dire n’importe quoi entre il y a 365 jours et il y a 729 jours
Pour savoir laquelle de deux vidéos affichées comme datant d’« il y a 1 an » est la plus récente, il faut réellement ouvrir la vidéo, aller jusqu’à la description et regarder la date
Comme je n’ai pas envie de faire des calculs de dates de tête, il suffit d’afficher un horodatage exact
Il faut afficher l’heure réelle au lieu de jeter une grande plage d’informations avec des formules comme « il y a 1 an »
Le « il y a 1 an » de YouTube peut signifier 365 à 729 jours, mais sur certains sites cela veut dire 183 à 548 jours avec un arrondi à l’année la plus proche, et sur d’autres on arrondit au mois jusqu’à 11 mois, puis on traite 350 à 548 jours comme « il y a 1 an »
Ailleurs encore, avec un critère du type « dans la dernière année calendaire », cela peut aller de 1 à 365 jours, voire de 364 à 729 jours
Une vidéo publiée le 14 octobre 2021 peut avoir 2 ans, mais si elle a été mise en ligne plus tard dans la journée, elle peut encore être affichée comme datant d’il y a 1 an
Par exemple, afficher jusqu’à 120 secondes, jusqu’à 120 minutes, jusqu’à 48 heures, jusqu’à environ 61 jours, puis jusqu’à 24 mois
Les dates relatives dans une liste sont généralement supportables, mais le problème de non-actualisation est bien plus agaçant, et le limiter à « hier » ne le résout pas
J’aimerais recommander cela encore plus fortement
Heureusement, l’horodatage apparaît souvent dans une infobulle
Par exemple, quand on regarde une version de package npm, on voit des choses du genre « version 5.3.27 was released ‘about a year ago’ » ; on se demande si c’est sérieux
J’essaie de déterminer l’ordre de publication d’anciens packages pour composer une combinaison figée de packages compatibles, mais 20 packages consécutifs sont tous affichés comme datant d’« environ 1 an », donc je dois ouvrir l’infobulle de chacun pour vérifier s’il s’agit d’une version récente
Ce genre de conception dépasse les bornes, et me semble relever de la même catégorie que les gens qui créent des ORM mappant des noms de tables irréguliers au singulier et au pluriel
Je ne sais pas pourquoi je ne le savais pas, et c’est plutôt utile
Ce qui est incroyable, c’est que non seulement ces gens ont encore un emploi, mais que cette méthode idiote s’est répandue everywhere, de npm à GitHub en passant par CircleCI
Plus largement, j’aimerais supprimer purement et simplement ces horodatages relatifs arrondis
L’app Mail d’iOS est particulièrement agaçante
Quand on l’ouvre, elle affiche « mis à jour à l’instant », mais si l’on tire pour actualiser, un e-mail non lu reçu il y a 2 heures apparaît soudainement
Il suffit d’afficher l’heure exacte de la dernière mise à jour
Si on ne les voit pas dans l’heure, ils deviennent aussitôt imprécis et n’affichent plus que « il y a 1 heure » ou « il y a 2 heures »
Il peut être indispensable de savoir exactement quand une notification est arrivée, mais il n’existe aucun moyen de le vérifier
Il suffit d’afficher l’heure ; je sais lire l’heure
Si c’est aujourd’hui, il n’affiche que l’heure ; sinon, il affiche la date et l’heure complètes
Avec des dates absolues, le navigateur peut les afficher selon le format préféré de l’utilisateur
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
Les designers web veulent que le site ait une apparence précise au pixel près, et le contrôle de l’affichage côté client va à l’encontre de cela
Cela reste possible, mais les sites web ne seront pas conçus pour cet usage ni ne l’aideront activement
Dans l’exemple, le rendu iOS/Safari donne l’impression qu’il n’y a pas de balise
Ce qui est particulièrement gênant avec les dates floues, c’est quand le jour de la semaine est l’information la plus importante
Par exemple, quand on consulte l’historique GitLab, il est bien plus utile de savoir si cela a été fusionné un vendredi que de voir « la semaine dernière » ou « il y a 2 jours »
Pour les historiques de chat aussi, près d’un changement de mois, il peut être important de savoir si la conversation a eu lieu avant ou après le début du mois
Même dans les autres cas, je préfère personnellement une date exacte à « il y a 4 semaines » ou « il y a 2 mois », et donner une date exacte ne réduit pas l’information
J’ai du mal à imaginer une situation où une date floue serait plus utile qu’une date exacte
Dans GitLab, on peut changer un réglage pour utiliser des heures absolues au lieu d’heures relatives
Exemple : October 14, 2023 11:51AM
https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
Je recommande vivement d’appliquer ce genre de chose aux logiciels courants basés sur le navigateur
Il existe des applications qui récupèrent des informations depuis une autre base de données, les reformatent et les affichent à l’utilisateur ; la mise à jour est coûteuse et longue, donc l’utilisateur doit la lancer manuellement quand c’est nécessaire
Dans ce cas, l’heure exacte de la dernière mise à jour n’a pas beaucoup d’importance ; ce qui compte, c’est l’ancienneté des données, autrement dit la probabilité qu’elles aient divergé de la source
Certaines informations doivent être actualisées au bout de quelques heures seulement, tandis que d’autres peuvent dater de 4 ou 5 jours, voire plus, sans qu’il soit nécessaire de lancer une mise à jour pouvant prendre jusqu’à 10 minutes
Pour cet usage, afficher une ancienneté approximative est plus utile que l’heure de la dernière mise à jour, et l’utilisateur n’a pas à faire le calcul par rapport à l’heure actuelle
Cela reste toutefois un cas rare, et dans la plupart des situations les dates relatives floues sont moins utiles
Par exemple : « cela se termine environ 4 à 5 heures après ce commentaire », ou « c’est corrigé, et la prochaine exécution démarre environ 15 heures après ce commentaire »
Parmi les apps que j’utilise et qui affichent mal les horodatages, la pire est gitg
Il suffit de voir cette capture d’écran
https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
Plusieurs commits sont affichés comme datant d’« il y a 3 jours », ce qui n’est guère mieux qu’une absence totale d’information
Impossible de savoir si c’était le matin ou l’après-midi, si tout était regroupé en moins d’une heure ou réparti sur toute la journée
Quand on n’a pas noté le temps passé pour un client et qu’il faut l’estimer une semaine plus tard, ce genre d’information compte ; il faut donc cliquer sur chaque commit et vérifier l’horodatage de l’autre côté de l’écran
Non seulement il affiche « il y a quelques jours », mais il essaie aussi de mettre en haut les éléments qu’il juge importants
On se retrouve donc avec deux listes partiellement redondantes mélangées, ce qui double l’horreur
https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
Il suffit d’afficher les deux
« il y a 1 heure (15:47) »
« la semaine dernière (MON 12 SEP 9:20) »
« il y a 2 ans (WED 14 APR 2021 11:47) »
Le format de date peut être choisi selon les préférences
Les personnes qui veulent plus de détails peuvent passer la souris sur la date relative
Quelques années plus tard, des entretiens utilisateurs ont montré qu’un simple soulignement de type lien hypertexte ne faisait pas penser aux utilisateurs qu’ils devaient passer la souris dessus, et nous sommes largement revenus en arrière
Maintenant que les emojis et les écrans haute définition sont courants, je me demande si un point d’interrogation discret ou une icône de loupe pour donner un indice d’infobulle suffirait aux utilisateurs plus âgés ou moins expérimentés
Il faut aussi inclure l’année
Trop souvent, sur des forums web, j’ai vu une date de commentaire affichée seulement sous la forme « 5 Jul », avant de me rendre compte plus tard que le commentaire datait de plusieurs années
Désormais, je ne fais plus confiance aux dates sans année et, si l’année n’est pas visible d’emblée, je finis par la chercher d’une manière ou d’une autre
Je vais plusieurs fois par semaine sur un forum qui existe depuis 20 à 30 ans, et les dates y sont indiquées comme 08/11/02 ou 09/03/04, ce qui prête beaucoup à confusion
« il y a 1 an » peut ne pas être assez précis, mais « il y a 11 mois » l’est généralement
Quand j’implémente ce genre de fonction, j’évite le nombre 1
Par exemple, j’affiche « il y a 6 jours » au lieu de « il y a 1 semaine »
Si c’est archivé par Google ou web.archive.org, et sauf si le libellé est calculé côté client, le temps relatif peut être basé sur la date d’indexation
Dans une archive, il y a aussi de fortes chances que JavaScript ne fonctionne pas correctement
Et pour afficher les dates de manière plus accessible, il peut être intéressant d’utiliser la balise
timeet l’attributdatetimehttps://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
Pour l’instant, dans les navigateurs, ce n’est pas très différent d’une balise
span, mais il n’y a aucun mal à rendre une page web compatible avec l’avenir