Dates / heures relatives - Arrondi et quelle est la précision?
Je lisais ceci question sur le formatage des dates et heures relatives, mais il y a encore un problème qui, selon moi, n'a pas encore été résolu.
J'aimerais:
Gardez les temps relatifs à seulement 1 unité, par exemple
1 hour agopar opposition à1 hour and 24 minutes ago.Lorsque l'heure/la date est survolée, nous affichons la date localisée, par exemple,
Tuesday, 24 July 2012 at 10:00 PM.
Étant donné ce qui précède:
Dois-je arrondir ou arrondir les temps? Par exemple, comment dois-je activer
1 hour and 24 minutes agoen justehours?Dois-je afficher les jours relatifs sous la forme
Yesterday,2 Days ago,3 Days agoouYesterday,Tuesday,Monday?À quel moment dois-je arrêter avec le
2 Days ago,Tuesday,Mondayet revenir à l'affichage des dates localisées?Dois-je prendre la peine d'avoir des heures/dates relatives pour
weeksetmonths?Quand dois-je supprimer la composante heure et afficher simplement la date/jour?
Arrondi - vous devez appliquer les mêmes règles que vous le feriez à un nombre à virgule flottante, donc "1 heure 24 minutes" est inférieur à 1,5 heure, il doit donc être arrondi à "1 heure". Lorsque vous passez 30 minutes, arrondissez.
J'irais avec "Hier", "il y a 2 jours" etc.
Une vérification rapide sur Stack Exchange montre qu'ils utilisent "Hier", "Il y a 2 jours", date localisée, tandis que (comme vous le faites remarquer) Facebook va pour les jours de la semaine. Je pense que la réponse dépend de la précision de la date. Vos utilisateurs ont-ils besoin de connaître la date exacte (facilement calculée à partir d '"aujourd'hui" et "d'hier", mais légèrement plus difficile à déterminer à partir de "lundi" ou "vendredi") ou est "quelque temps cette semaine" ou "récemment" bonne suffisant?
Si vous affichez déjà des dates plus anciennes en tant que date réelle plutôt que "il y a quelque temps" lorsque la date date de 2 ou 3 jours, alors avoir des dates relatives pour des semaines et des mois ne semble pas pertinent.
Bien que le composant de temps pour une date qui date d'un an ne semble pas pertinent, cela ne vaut probablement pas l'effort de codage supplémentaire pour le masquer pour les dates plus anciennes. L'avantage (le cas échéant) de masquer l'heure ne vaut probablement pas le coût de l'écriture et de la maintenance du code nécessaire.
Cependant, avec tout cela, cela dépend de la précision de vos dates et heures. Est-il important que la valeur affichée soit aussi précise que possible ou la date/heure exacte sur une info-bulle est-elle OK?
Arrondi: Comprenez que l'arrondi créera toujours une erreur. Si vous voulez vraiment aller de l'avant avec l'idée, voici ma suggestion:
Prenons les "semaines" comme exemple pour expliquer mon concept. (Vous voudrez peut-être saisir un calendrier maintenant ...) La journée d'aujourd'hui est le jeudi 26 juillet.
- Supposons que je sois allé chez le médecin le 14 juillet. Il y a 2 semaines, non?
- Supposons que je sois allé au cinéma le 2 juillet. Il y a 3 semaines, non ??
À première vue, cela peut sembler un simple arrondi mathématique (arrondi symétrique?), Mais ce n'est pas le cas!
Supposons que la journée d'aujourd'hui soit le samedi 28 juillet. Alors mes deux exemples sont toujours valables: je suis allé chez le médecin il y a 2 semaines et je suis allé au cinéma il y a 3 semaines.
Vous ne devez pas regarder l'intervalle de temps lui-même et le contourner. Vous devez déterminer la semaine de l'événement passé (c.-à-d. La semaine 27 pour les films) et la semaine du jour en cours (c.-à-d. La semaine 30). Soustrayez les deux (30 - 27) et c'est la différence de temps en semaines!
Vous pouvez appliquer ce concept à n'importe quelle unité de temps: heures, jours, semaines, mois, années, siècles, ...
C'est la chose la plus naturelle à faire quand on ne veut pas utiliser des expressions comme "approximativement", "plus que", "au moins", "presque", ...)
Tout d'abord, je suppose que vous avez une très bonne raison de ne pas vouloir utiliser plusieurs unités. En général, il est préférable d'utiliser des unités que les gens utilisent naturellement, et la plupart des gens iraient plus avec 1 heure 14 minutes que juste des heures entières. Mais en vous donnant le bénéfice du doute à ce sujet, en supposant que vous deviez le faire, voici ce que je recommanderais:
Si le temps était il y a 1 heure 45 minutes, ne arrondissez pas à 2 heures, car la plupart des gens prendront le temps donné comme un minimum. Utilisez un mot pour donner un contexte, par exemple:
- environ il y a 1 heure (meilleure option), ou environ il y a 2 heures (moins comme parler humain cependant)
- moins de il y a 2 heures (ne fonctionne bien que si vous arrondissez toujours).
Si vous allez suivre la méthode de l'arrondi en unités individuelles, je continuerais à afficher la date en termes relatifs et je donnerais simplement la date/l'heure exacte lorsque quelqu'un passe la souris dessus ou clique dessus. donc, je garderais les unités à: minutes, heures, jours, semaines, mois et années. Passer soudainement d'une heure relative à une heure précise est déroutant et vous devriez l'éviter.
Il semble qu'il n'y ait pas de solution commune pour un tel cas - cela dépend des tâches et des objectifs. J'ai eu un cas pour le tableau de bord affichant des informations de garantie et de réparation sur l'équipement. J'ai fait de telles hypothèses (peut-être inappropriées aux cas courants):
1) Les arrondis pour les horodatages et les dates ne sont pas corrects, car il n'est pas possible de faire la différence entre les valeurs correctes et arrondies - l'utilisateur peut être confus. Seules les valeurs relatives ("il y a 1 heure 23 minutes 35 secondes") doivent être arrondies.
2) Plus la date/heure est proche de la date/heure actuelle, plus elle doit être affichée avec précision. Par exemple, s'il faut deux jours pour démarrer une activité de révision/réparation - elle doit être affichée sur 2 jours (avec une date et une heure exactes). Mais si le matériel doit être vérifié au 28/12/2015, il suffit de dire "plus de 3 ans, à" décembre 2015 ", ou événement" à 2015 ".
3) Des arrondis plus humains et axés sur les tâches et moins mathématiques sont meilleurs. Par exemple, "il y a 1h29m" peut être arrondi à "il y a plus d'une heure" pour les messages d'alerte et à "il y a moins de deux heures" pour le fil d'actualités (mais l'utilisation d'un tel format de texte au lieu de chiffres doit en outre être vérifiée pour la lisibilité - par exemple, il n'est généralement pas applicable dans les listes ou les tableaux).
4) La combinaison de la date et de l'heure exactes et, visuellement séparément, de la valeur relative arrondie est plus efficace dans les applications critiques de date/heure (par exemple, les planificateurs et ce tableau de bord).
Donc, avec de telles hypothèses, réponses à vos questions:
1) Oui, les arrondis sont applicables aux valeurs relatives, car ils sont plus faciles à comprendre (pas besoin de comparer avec l'heure actuelle).
2) L'utilisation de noms de jours au lieu de valeurs immobilières peut être plus difficile à comprendre, car elle nécessite également des efforts cognitifs supplémentaires.
3) Oui, les valeurs relatives pour les jours et les mois peuvent être utiles dans certains scénarios de date/heure, mais dans le cas de messages informatifs simples (comme dans les fils de nouvelles), cela l'est inutilement.
4) Le temps peut être abandonné s'il n'est pas vital et si le moment était il y a plus de deux jours (ou le sera après deux jours).