4 puntos por GN⁺ 2023-10-15 | 3 comentarios | Compartir por WhatsApp
  • Las etiquetas de fecha relativa en una UI web suenan humanas, pero a menudo no coinciden con la forma en que los usuarios realmente interpretan las fechas
  • Para una persona, “yesterday” significa el día anterior, de 0:00 a 23:59, no simplemente “hace menos de 24 horas”
  • Si la referencia cambia según la implementación, incluso dentro del mismo servicio la etiqueta “yesterday” puede variar y eso reduce la confianza en la fecha mostrada
  • Mostrar solo una cantidad de días en expresiones como “12 days ago” se siente lejano a la manera natural en que las personas perciben el tiempo
  • “last week/month/year” también abarca rangos amplios y ambiguos, así que para elementos más antiguos que ayer conviene mostrar una fecha específica

Por qué las etiquetas de fecha relativa confunden

  • Expresiones como “yesterday”, “2 days ago” o “a week ago” parecen formas humanas de expresar el tiempo, pero no son lo bastante precisas para interpretar una fecha real
  • En particular, “yesterday” tiene un significado claro para el usuario
    • Se refiere al día anterior al de hoy
    • Apunta al intervalo entre las 0:00 y las 23:59 del día anterior
    • No es lo mismo que la fórmula de cálculo “menos de 24 horas”
  • Las computadoras pueden implementar “yesterday” de maneras distintas, y si dentro del mismo servicio la etiqueta cambia, el usuario confiará menos en esa información de fecha

Para los elementos antiguos, es mejor mostrar la fecha

  • Expresiones como “12 days ago” no encajan bien con las unidades de tiempo en las que la gente suele pensar
  • “last week”, “last month” y “last year” también dejan ambigüedad porque cubren rangos amplios
  • Para elementos más antiguos que ayer, es más fácil de leer y de confiar mostrar una fecha concreta en lugar de una expresión relativa

3 comentarios

 
cosine20 2024-12-02

La verdad, tanto GitHub como YouTube hacen esto y realmente lo odio: mostrarlo como hace unos meses o hace unos años. Como también dicen en los comentarios de HN abajo, a veces pone hace 1 año cuando en realidad fue hace año y medio, y es demasiado ambiguo.

 
budlebee 2023-10-17

La verdad, me identifico mucho con esto. Desde la perspectiva de quien lo crea, si lo muestras como «hace XX días», no hace falta preocuparse por los distintos formatos de fecha según cada país, como YY.MM.DD o mmddyyyy y demás, pero a mí me gusta más que se muestre la fecha en lugar de «hace XX días».

 
GN⁺ 2023-10-15
Opiniones de Hacker News
  • En particular, la visualización de tiempo relativo se vuelve demasiado imprecisa.
    En YouTube, “hace 1 año” puede significar cualquier cosa desde hace 365 días hasta hace 729 días.
    Para saber cuál de dos videos marcados como “hace 1 año” es más reciente, hay que abrir el video y llegar hasta la descripción para ver la fecha real.

    • Se siente como si los diseñadores de UI se hubieran reunido para hacer un concurso de microagresiones de GUI para molestar a los usuarios, y la tendencia de “hace N días” hubiera ganado y se hubiera propagado por todas partes.
      No quiero calcular fechas mentalmente; basta con mostrar un timestamp exacto.
      No deberían tirar información en rangos amplios como “hace 1 año”, sino mostrar la hora real.
    • Lo más divertido es que cada sitio tiene distintos criterios de redondeo.
      En YouTube, “hace 1 año” puede ser hace 365 a 729 días, pero en algunos sitios significa entre 183 y 548 días al redondear al año más cercano, y en otros redondean por meses hasta los 11 meses y luego tratan de 350 a 548 días como “hace 1 año”.
      En otros lugares, con criterios como “dentro del último año calendario”, también puede abarcar desde hace 1 a 365 días hasta hace 364 a 729 días.
    • Si ahora es octubre de 2023, un video subido en noviembre de 2021 no debería aparecer como “hace 1 año”, sino como “hace casi 2 años”.
    • Incluso con la misma fecha, si la hora es posterior, se redondea hacia abajo.
      Aunque un video subido el 14 de octubre de 2021 tenga 2 años, si se subió más tarde ese mismo día todavía puede mostrarse como hace 1 año.
    • Se puede reducir la imprecisión evitando que el primer número sea 1 y cambiando a una unidad más pequeña.
      Por ejemplo, mostrar hasta hace 120 segundos, hasta hace 120 minutos, hasta hace 48 horas, hasta aproximadamente 61 días y luego hasta hace 24 meses.
      Las fechas relativas dentro de una lista suelen ser tolerables, pero el problema de que no se actualicen es mucho más irritante, y limitarlo solo hasta “ayer” no lo resuelve.
  • Quisiera recomendar esto con más fuerza.
    Por suerte, muchas veces el timestamp aparece como tooltip.
    Por ejemplo, al ver versiones de paquetes npm aparece algo como “version 5.3.27 was released ‘about a year ago’”, y uno se pregunta si están en sus cabales.
    Estoy intentando averiguar el orden de lanzamiento de paquetes antiguos para armar un conjunto fijo de paquetes compatibles, pero 20 paquetes consecutivos aparecen todos como “hace aproximadamente 1 año”, así que tengo que abrir el tooltip de cada uno para confirmar cuál es la versión más reciente.
    Este tipo de diseño cruza la línea, y parece obra de la misma clase de gente que crea ORM que mapean nombres de tablas con singulares y plurales irregulares.

    • De verdad YouTube también tenía tooltip.
      No sé por qué no lo sabía, y es bastante útil.
    • No es que no estén en sus cabales; simplemente son tontos o, siendo generosos, ignorantes hasta el punto de la incompetencia.
    • La gente que hace estas cosas en herramientas para desarrolladores es criminalmente incompetente.
      Lo sorprendente no es solo que sigan empleados, sino que esta idiotez se haya propagado por todas partes, desde npm hasta GitHub y CircleCI.
  • Más aún, quisiera eliminar por completo estos timestamps relativos redondeados.
    La app Mail de iOS es especialmente molesta.
    Al abrirla dice “actualizado hace un momento”, pero si deslizo para actualizar, de pronto aparece un correo no leído recibido hace 2 horas.
    Simplemente deberían mostrar la hora exacta de la actualización.

    • Los timestamps tontos de las notificaciones son peores.
      Si no los ves dentro de una hora, enseguida se vuelven imprecisos y solo muestran si fue “hace 1 hora” o “hace 2 horas”.
      Puede que necesite saber exactamente cuándo llegó cierta notificación, pero no hay forma de comprobarlo.
      Basta con mostrar la hora; sé leer la hora.
    • Una de las ventajas de Thunderbird es que todavía muestra la fecha y hora exactas.
      Si es hoy, muestra solo la hora; si no, muestra la fecha y hora completas.
  • Si se usa una hora absoluta, el navegador puede mostrarla según el formato preferido del usuario.
    https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

    • El sueño de la web en el que el servidor solo envía datos y el cliente elige cómo mostrarlos está completamente muerto.
      Los diseñadores web quieren que el sitio tenga una apariencia específica hasta el nivel de píxel, y el control de visualización del lado del cliente se interpone.
      Todavía se puede hacer, pero los sitios web no estarán diseñados pensando en ese uso ni lo facilitarán activamente.
    • No sé cómo se ve realmente para el usuario promedio.
      En el ejemplo, la salida de iOS/Safari parece como si no tuviera etiqueta.
  • Lo especialmente incómodo de las fechas difusas es cuando el día de la semana es la información más importante
    Por ejemplo, al revisar el historial de GitLab, es mucho más útil saber si se hizo el merge un viernes que ver “la semana pasada” o “hace 2 días”
    En los historiales de chat, si estás cerca del límite de un mes, puede importar si la conversación fue antes o después de principios de mes
    Incluso en otros casos, personalmente prefiero una fecha exacta a saber si fue hace 4 semanas o hace 2 meses, y dar la fecha exacta tampoco reduce la información
    Me cuesta imaginar una situación en la que una fecha difusa sea más útil que una fecha exacta

    • Soy integrante del equipo de GitLab
      En GitLab, si cambias la configuración, puedes usar tiempos absolutos en lugar de tiempos relativos
      Ej.: October 14, 2023 11:51AM
      https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
    • Hice un script de Greasemonkey que cambia las inútiles etiquetas de tiempo de Jira por fechas completas con día de la semana
      Recomiendo mucho aplicar algo así en el software basado en navegador que uses con frecuencia
    • En casos muy específicos, las fechas difusas pueden ser útiles
      Hay una aplicación que toma información de otra base de datos, la reformatea y se la muestra al usuario; como la actualización es costosa y tarda mucho, el usuario debe ejecutarla manualmente cuando la necesita
      En este caso, la hora exacta de la última actualización no importa demasiado; lo importante es qué tan viejos son los datos, es decir, qué tan probable es que estén desfasados respecto del original
      Algunos datos deben refrescarse después de apenas unas horas, pero otros pueden tener más de 4 o 5 días y seguir estando bien, así que no hace falta ejecutar una actualización que puede tardar hasta 10 minutos
      Para este propósito, es más útil mostrar la antigüedad aproximada que la hora de la última actualización, y el usuario no tiene que calcular comparándola con la hora actual
      Aun así, es un caso raro, y en la mayoría de los casos las fechas relativas difusas son menos útiles
    • Al comunicar horas en el futuro cercano a personas en varias zonas horarias, los tiempos relativos son útiles
      Algo como “termina unas 4 o 5 horas después de este comentario” o “ya se corrigió y la próxima ejecución empieza unas 15 horas después de este comentario”
  • De las apps que uso y que muestran mal las marcas de tiempo, la peor es gitg
    Basta ver esta captura
    https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
    Varios commits aparecen como “hace 3 días”, lo cual apenas es mejor que no tener información en absoluto
    No se sabe si fue por la mañana o por la tarde, si estuvieron agrupados en una hora o repartidos durante todo el día
    Cuando no registré las horas de trabajo de un cliente y tengo que estimarlas una semana después, esa información importa, así que tengo que hacer clic en cada commit y revisar la marca de tiempo al otro lado de la pantalla

    • La captura es una de las razones importantes por las que siempre hace falta mostrar la fecha completa
    • Outlook Webmail también es bastante malo
      No solo muestra “hace unos días”, sino que además intenta mostrar arriba los elementos que considera importantes
      Así terminan mezclándose dos listas parcialmente duplicadas, y lo horrible se duplica
    • Las marcas de tiempo de git se ajustan a la zona horaria local de cada desarrollador y no se verifican, así que en el desarrollo global esto puede complicarse aún más
      https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
    • Me sorprende que en gitg no parezca haber una forma de configurarlo para que siempre muestre fecha y hora completas
    • Si existiera un regulador de la industria, el formato mostrado en la captura sería candidato a falta profesional
  • Se pueden mostrar ambas cosas
    “hace 1 hora (15:47)”
    “la semana pasada (MON 12 SEP 9:20)”
    “hace 2 años (WED 14 APR 2021 11:47)”
    El formato de fecha puede ser el que prefieras

    • En frontend, me resultó útil renderizar tiempos relativos en la página y poner la marca de tiempo real o el formato de fecha en un tooltip
      Quien quiera ver más detalle puede pasar el mouse sobre la fecha relativa
    • Antes ponía la información exacta de hora y fecha en tooltips, pensando que “los usuarios que la necesiten pueden encontrarla sin sobrecargar la UI”
      Años después, en entrevistas con usuarios, quedó claro que un simple subrayado tipo hipervínculo no hace que los usuarios piensen “debería pasar el mouse por aquí”, así que revertí buena parte de eso
      Ahora que los emojis y las pantallas de alta resolución son comunes, me pregunto si dar una pista de tooltip con un signo de pregunta o una lupa que no estorbe sería suficiente para usuarios mayores o con menos experiencia
    • ¿Por qué no simplemente mostrar la fecha?
  • También debería incluir el año
    Demasiadas veces he visto foros web que muestran la fecha de los comentarios solo como “5 Jul” y recién después me doy cuenta de que el comentario era de hace varios años
    Ahora ya no confío en fechas sin año y, si no lo veo desde el principio, busco la forma de encontrarlo

    • El año debe escribirse con 4 dígitos
      Hay un foro al que entro varias veces por semana que tiene entre 20 y 30 años, y las fechas aparecen como 08/11/02, 09/03/04, etc.; es muy confuso
  • “hace 1 año” puede no ser lo bastante preciso, pero “hace 11 meses” suele bastar
    Al implementar una función así, prefiero evitar el número 1
    Por ejemplo, mostrar “hace 6 días” en lugar de “hace 1 semana”

  • Si queda archivado en lugares como Google o web.archive.org, salvo que la etiqueta se calcule del lado del cliente, puede terminar siendo un tiempo relativo basado en la fecha de indexación
    En un archivo, además, es muy probable que JavaScript no funcione correctamente
    Para mostrar fechas de forma más accesible, también vale la pena considerar usar la etiqueta time y el atributo datetime
    https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
    Aunque por ahora en los navegadores no difiere mucho de una etiqueta span, no está de más hacer que la página web sea compatible con el futuro