L’affichage des dates dans les applications web me pose toujours quelques cas de conscience. Celui-ci sera fonction de l’information que vous souhaitez donner, de l’importance que vous lui accordez, mais également du message que vous souhaitez faire passer. Et rien n’est jamais simple en ce bas monde.

Si la datation en soi est une information capitale

Quand la datation en soi est une information capitale pour vous, vous n’avez pas d’autre choix que d’afficher la date. Encore faut-il savoir comment.

Le format purement numérique, du type jj/mm/aa ou jj/mm/aaaa convient dans un environnement d’affichage d’informations brutes, dans lequel les chiffres tiennent la première place : facture, document légal, feuille de calcul Excel. Très pratiques également quand la place fait défaut, ce format transmet en revanche un ton relativement froid.

Il peut cependant poser problème, particulièrement quand du contenu en français est inséré dans une application anglophone. 06/02/2009 signifie en effet 6 février 2009 pour un francophone, et 2 juin 2009 pour un anglophone. Pas facile de s’y retrouver. On peut éventuellement contourner le problème en utilisant le format de date court du type 02 Jan 2009, mais il ne convient pas à tous les besoins.

Dans un cadre plus littéraire, ou lorsque le style prime sur l’information brute, je recommande l’affichage de la date en toutes lettres, du type 2 juin 2009. La date entièrement en lettres, du type le deux juin deux-mille neuf n’est elle, obligatoire que sur certains documents légaux, et vous devriez peu la croiser sur une application web.

Si le temps passé est plus important que la date elle-même

La date elle-même est parfois moins importante que le temps passé depuis la publication de l’information. À ce titre, de nombreuses applications utilisent maintenant cette information, parfois à tort et à travers.

L’information se présente généralement sous deux formats différents, en fonction du message à faire passer :

  • Temps passé par rapport à l’instant présent : il y a ….
  • Temps passé relativement à la publication d’une autre information : … plus tard.

Cette manière de faire est particulièrement adapté aux outils possédant des fonctionnalités de conversations, mais son utilisation doit être réfléchie afin de ne pas troubler les utilisateurs, et cela peut très vite devenir un casse tête. Prenons l’exemple d’un forum :

  • Le thread initial a été publié il y a ….
  • Un commentaire ou une réponse a été déposée … plus tard. On utilisera ce format là de préférence au précédent afin de lier la publication de l’information au message d’origine et non à la date du jour.

Le second cas peut rapidement devenir extrêmement problématique, par exemple lorsqu’il est possible de commenter un commentaire. Dès lors, plus tard s’applique-t-il au message d’origine ou au message de réponse ? La présentation du contenu doit normalement donner cette information, mais elle n’est malheureusement pas accessible à tous. Lors de l’inclusion de l’information sur un autre support, par exemple un flux RSS, on reviendra à l’affichage de la date littérale, ce format étant totalement incompréhensible hors de son contexte d’origine.

La question qui revient souvent par rapport à ce format de date est : durant combien de temps son utilisation est-elle pertinente. Il n’y a pas vraiment de réponse, mais j’aurais tendance à la fixer à 3 mois, durée au delà de laquelle elle a tendance à perdre son sens. C’est évidemment arbitraire, et le contexte applicatif aussi bien que métier doit vous permettre de juger au bout de combien de temps la date de publication doit prendre le pas sur la distance entre les interactions.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: