Estoy convencido de que los seres humanos no estamos hechos para administrar el tiempo. Basta con recordar cuantas veces te han preguntado en los últimos días --"¿Qué día es?" para saber que tenemos un problema. Tenemos relojes, calendarios, agendas análogas y digitales, los omnipresentes celulares y sin embargo nadie parece saber la fecha.
Aun así, pocas personas hacen un esfuerzo consciente por facilitar la lectura de las fechas. Todo tipo de objetos diseñados --recibos, carteles, convocatorias, invitaciones-- parecen estar hechas para que las lea un robot y no un ser humano. A la izquierda un ejemplo al azar que me encontré en google: ".05.07 (SAT) 22:00 START". Tengo que hacer la cuenta manual "enero, febrero, mazro, abril, mayo, luego inferir que "SAT" es por Saturday y hacer la siempre tediosa (aunque sencilla) conversión de horario militar a horario humano (22:00 = 10:00 PM). Es el ejemplo perfecto de forma sobre función.
Es fácil seguir algunos lineamientos para facilitar la lectura de las fechas y el tiempo. Todo esto aplica únicamente al lenguaje escrito. Irónicamente, cuando expresamos fechas y horas oralmente, tendemos a ser mucho más claros --"Va a haber peda en mi casa el próximo sábado [días contextuales], caele como a las diez de la noche [hora flexible]".
Las horas
Casi siempre estarás mejor acompañado con el horario normal de 12 horas a el de 24. Sin embargo, en ciertas regiones del mundo el horario de 24 horas es el más usado. Si este es el caso, sólo ignórame. Siempre usa el indicador de am/pm (ante meridiem, post meridiem). Aunque a veces el contexto es suficiente --"Comida a las 3:00!"-- nunca está demás la aclaración. La convención más usada es la hora seguida por un espacio con el am/pm en mayúsculas, sin puntos, aunque yo uso minúsculas en el caso de tener una tipografía con números en cajas bajas:
Un problema de las horas es la ambigüedad que existe al medio día (12:00 PM) y a la media noche (12:00 AM), y nadie parece conocer con certidumbre cual es cual. En este caso acompaña la hora con un texto aclaratorio: 12:00 AM media noche, 12:00 PM medio día.
Un buen pretexto para usar el horario de 24 horas es para indicar lapsos de tiempo que crucen el medio día o la media noche, es difícil cuantificar cuantas horas hay entre las 10:00 AM y las 3:00 PM. Pero si escribo "el curso comenzará a las 10:00 y terminará 15:00" es mucho más fácil inferir su duración.
El tiempo relativo
En el mundo real aplicamos el tiempo relativo todo el tiempo y es de lo más sencillo --"Necesito que tengas eso listo dentro de una hora"-- en el mundo digital es igual de fácil y conveniente; y sin embargo muy pocas los programadores lo implementan. Blogs y sitios de noticias que actualizan constantemente a lo largo del día deberían de implementarlo, k10k lo hace, mientras que El Universal no. Si observamos las siguientes capturas de pantalla, nos damos cuenta de que en El Universal, con su combinación de tiempo absoluto con horario militar, la hora del posteo se vuelve completamente irrelevante, mientras que en k10k podemos juzgar la frescura de los links fácilmente.
En los blogs de publicación normal (espaciada) la fecha es relevante y siempre deberá de indicarse (aunque con poca jerarquía visual), pero la hora es poco relevante. Un ejemplo interesante que Sosa maneja es contextualizar el tiempo: --Escrito por sosa en la tardecita/a la hora de la comida/con insomnio es mucho más relevante que Escrito por sosa a las 5:00 PM/3:00 AM/2:00 PM.
Todas las aplicaciones web y de escritorio que administren tareas deben de tener tiempos relativos para el futuro. Esto es más importante para las fechas, pero también aplica para el tiempo. Quiero una alarma que me pueda avisar que mi tiempo se acabó dentro de 10 mins/1 hora/ 12 horas, y no hacer la operación aritmética yo mismo.
Los relojes análogos no han sido reemplazados por los digitales porque hacen precisamente esto: es mucho más fácil ver que tengo un cuarto de hora para llegar al trabajo a hacer la operación 8:45 = 15 mins para que se me haga tarde.
Las fechas
La manera mejor manera de expresar una fecha es evitar las abreviaciones e incluir el día de la semana: sábado, 16 de julio, 2006. Incluir el día de la semana muy importante en el caso de un evento, porque me permite saber de antemano si interfiere con mi horario normal. Ejemplo: me acabo de enterar de que sí voy a poder ver el primer partido entre Irán y México porque cae en domingo, antes de esto escuchaba "El partido es el 11 de junio" y no tenía la certidumbre de poder verlo. En el caso de eventos muy importantes me permite ir haciendo las previsiones necesarias para asistir. A la izquierda: un detalle de la interfaz de Basecamp, chéquenlo porque está repleto de detallitos que auxilian en la comprensión y escritura del tiempo.
La cosa cambia cuando hay que introducir una fecha en un formulario, en cuyo caso es mejor usar el formato dd/mm/aa (05/06/06) para el público hispanoparlante y mm/dd/aa para el angloparlante, por una parte porque ya prácticamente es convención y por otra porque me permite hacer operaciones aritméticas con la fecha, ej: si quiero recibir un recordatorio dentro de tres meses sólo tengo que sumar tres dígitos al mes en el que estoy sin tener que saber qué mes es: 05/06/06 → 05/09/06. Nunca está demás permitir cualquier tipo de fecha: 5/5/06 y 5/jul/2006 deberían de ser fechas válidas también.
Para la escritura de fechas siempre incluye un calendario como lo hacen sitios de viajes como Expedia, aunque hay ciertos contextos donde un calendario costumizado acomoda mejor. En Medicina.ru encontré un calendario para hacer una cita con un doctor, y me permite ver de un vistazo qué días y qué horas están disponibles. Ni siquiera hay que saber el idioma para entenderle.
Las fechas relativas
Uno de mis objetivos con este rediseño fue crear fechas relativas para los comentarios y para los posts, algo que Movable Type no hace de fábrica. Les compartiría el código, pero en serio, soy muy mal programador. Las fechas relativas permiten juzgar de un vistazo que tan antiguo es un comentario o un post. Si ven están viendo esto desde la página principal, podrán ver que es mucho más fácil entender cuándo se escribió cada cosa.
Una cosa que quise implementar (y que voy a hacer proximamente) es indicar cuando se hizo el último comentario. En las conversaciones asincrónicas (las que no se dan en tiempo real) es difícil entender cuando se hizo el último comentario. Nunca falta el estudiante desvelado que entra preguntando algo urgentemente en un post muerto hace años. Algo así le haría entender el contexto de la conversación:
Y por último: el hecho de que haya termido de escribir esto el 06/06/06 es pura coincidencia!