Usabilidad de los calendarios

Hoy estoy pletórico, no sólo no voy a escribir sobre ActionScript, o Flash, o Flash Lite, sino que ni siquiera voy a tratar nada de programación, de hecho me voy a animar a atacar el uso que en mi opinión habitualmente se hace de forma incorrecta de un elemento que suele formar parte de muchas webs: los calendarios.

Voy a tratar de exponer mi visión sobre el mal uso habitual que se hace de los calendarios, ya que me gustaría que este post no sean más que mis reflexiones, sino que me fusiléis mis razonamientos todos aquellos que tengáis argumentos para hacerlo. (o aunque no los tengáis, pero entonces no esperéis que os haga caso).

El calendario es un componente que tiene principalmente dos funcionalidades en la web, la de introducción de datos, y la de organización temporal de información. Vamos a analizar ambas, aunque la primera en menor medida, la que más falla en la web habitualmente para mi es la segunda.

Calendario como selector de fechas o “Date Picker”

Esta forma de emplear los calendarios en formularios web, no solo me parece que no es incorrecta, sino que puede tener su razón de ser. Su competidor sería un selector de fechas en 3 bloques (dia / mes / año) o 2 bloques (dia / mes + año), que tiene algunas ventajas frente a los calendarios, y que para mi precisamente significan las claves para tomar una decisión correcta para cuando usarlos.

CASO A: Reserva de un vuelo de avión

En este caso, el usuario se encuentra en un contexto de búsqueda de una fecha, en condiciones habituales tiende a ser cercana (máximo unos meses de antelación), y normalmente en el caso de ser un viaje de ida y vuelta, dicha vuelta es relativamente cercana. Con esta situación un calendario aporta visualmente una referencia interesante a la hora de elegir una fecha, concretamente la ayuda visual que aporta un calendario mostrando los días de la semana, no es nada despreciable, ya que ayuda a orientar al usuario en su planificación más inmediata (la gente tiende a pensar cuando se trata de fechas próximas en formato semanal, no mensual).

De esta manera, cuando el calendario que se muestra al usuario, ya aparece situado en la fecha actual, es muy directa la selección del día deseado, con un solo clic, 2 máximo si el viaje fuera al mes siguiente. Punto a favor.

Si comparamos este sistema con la introducción por selectores independientes (dia/mes/año o dia/mes+año) podemos decir que en gran cantidad de casos el formato de calendario es mejor, ya que solamente cuando el viaje fuera muy a largo plazo, los selectores aportarían más velocidad y fiabilidad.

Como ejemplos existentes en la web de calendarios adecuados os dejo algunos:

Iberia
Se combinan las dos opciones comentadas, y además el calendario de vuelta muestra una referencia visual sobre el día de ida elegido
Rumbo
Mantiene 2 calendarios simultáneamente para ayudar más aun la referencia futura
Hotelopia
Mejora la combinación de las dos opciones aunando en un mismo selector mes y año.
Date Picker, jQuery
Concretamente el “flat mode, range selection, 3 calendars” que permite visualización de varios meses como el de rumbo, pero además te marca los intervalos de tiempo seleccionados de forma gráfica.

Y como ejemplo del tipo de selector de fechas en formato calendario que yo emplearia por su utilidad directa, os dejo el siguiente ejemplo que se utilizaba en KLM pero que actualmente han cambiado por otro diferente que pierde la velocidad de acceso a meses / años futuros:

Calendario con selector por mes año que favorece notablemente el acceso rápido a periodos diferentes

CASO B: Selección de fecha de nacimiento

Aunque el objetivo es idéntico al CASO A (seleccionar una fecha) el caso que planteo aqui es totalmente diferente al anterior, y creo que marca la diferencia clara entre cuando un calendario puede ser útil para introducir información y cuando no. Aqui se demuestra claramente que lo que ha de definir la decisión de qué elemento visual e interactivo emplear es su utilidad final, su contexto y su lógica, no su estética.

Cuando en la web se ha de introducir una fecha de nacimiento, normalmente el usuario tiene que remontarse más de una década hacia atrás, lo cual establece un punto clave a la hora de cubrir la facilidad de acceso a fechas tan lejanas. Las fechas de nacimiento se piensan y recuerdan en “absoluto”, y sin ninguna referencia espacial en la semana o mes, es decir: 03 de Enero de 1934, ni día de la semana, ni referencia general de un periodo, ni nada.

Teniendo en cuenta que los componentes calendario que se emplean en la web tienen por lo general un acceso sencuencial para todos los periodos posibles (meses y años), retroceder a una fecha tan lejana puede ser bastante tedioso. Aqui las ventajas de un triple selector son evidententes, y no tanto de un doble selector con formato combinado mes / año para el segundo, ya que al poder tener que retroceder muchos años, la combinación mes + año aumentaría notablemente la longitud del selector).

Otro punto a tener en cuenta aqui es que es mejor marcar el mes en texto que en numérico, ya que las fechas de nacimiento se recuerdan con más claridad en este formato que en el numérico. No es crítico, pero es un pasito más para facilitar al usuario su misión.

“En estos dos casos no he tenido en cuenta la introducción manual, por el problema que puede implicar la validación de la entrada, que en el caso de los dos componentes anteriores, si están bien realizados se reduce a que el propio usuario elija mal la fecha, pero que en una introducción 100% manual implica posibles errores al teclear, cosa que hay que evitar siempre que sea posible.”

Calendario como panel informativo

Este es el aspecto del uso de un calendario que más quiero elaborar, porque en mi opinión adolece de grandes problemas que los clientes o algunos desarrolladores, no ven, quizás por el hecho tan absurdo de querer una representación gráfica en formato calendario. Pero yo me pregunto… ¿aporta realmente algo al usuario?

Analizando lo que aporta un calendario gráfico para mostrar información:

  • Información sobre el mes, semana y día en el que nos encontramos, visión conjunta a nivel de mes.
  • Información visual, pero no informativa sobre determinados datos que pueden suceder en ese rango de tiempo visualizado.
  • Acceso a los elementos marcados en dicho periodo de tiempo (con un click)

Ahora tenemos que preguntarnos si eso es realmente información útil o es prácticamente inútil. Digo yo…

  • ¿Me aporta algo saber que el dia 5 hay algo, sin saber lo que es?
  • ¿Qué ocurre si un día hay más de un item informativo?
  • ¿Si pincho en un día con varios eventos o información, a dónde voy?
  • ¿Qué pasa si hoy es 30 de mes, que los eventos de dentro de 3 días no son importantes para mi porque son del mes siguiente?
  • ¿Por qué todo tiene que ser tan pequeño, para que quepa en una columna lateral de una web? ¿Es eso un motivo de peso para limitar la información?
  • Si el calendario está vacío… ¿qué debo pensar del él?
  • Y si el calendario está lleno de días marcados, ¿qué debo pensar de él? ¿tiene utilidad un calendario en el que casi todo los días se marcan de la misma manera (por ejemplo subrayado, otro color, negrita, etc.)?
  • ¿Por qué he de hacer un click, o si han sido considerados un pasar por encima de un elemento normalmente minúsculo, para saber lo que hay en un día?
  • ¿Me hace gracia tener que ir haciendo click en los días y volver atrás o seleccionar otro hasta encontrar la información que busco?

Estas son algunas de las preguntas más directas y evidentes… Se pueden hacer muchos esfuerzos a nivel de programación para solventar algunas de estas limitaciones, y que por desgracia no están implementadas en la mayoria de los calendarios informativos existentes, pero la pregunta es… ¿por qué complicar lo simple?

Una agenda de eventos, las noticias, las tareas pendientes por hacer, etc. no tienen tras de si el concepto de calendario en su esencia, no nos confundamos, representan de manera clara un listado de elementos informativos, y como tal se deberían tratar. El calendario sirve para mostrar una referencia temporal dentro de un contexto semanal/mensual/anual, pero no para mostrar información. Emplearlo como el intermediario entre el usuario y la información me parece un craso error, estamos poniendo una barrera adicional innecesaria entre los datos verdaderamente importantes y el usuario.

De esto se han dado cuenta hace mucho los organizadores personales, las agendas, las aplicaciones de gestión de proyectos, sistemas de gestión de contenidos,… Como una imagen vale más que mil palabras, os dejo una representación que he elaborado para representar lo que quiero decir, juzgar vosotros mismos.

Optimización del acceso a información en un modelo de agenda enfrentado con un modelo clásico de calendario

Una especie de dashboard de wordpress, un to-do list, un listado de eventos por proximidad, categorizado por colores, con limitaciones de rango de fechas mucho más flexibles, con posibilidad de ver los días importantes sin necesidad de navegar por meses, con posibilidad de conocer los eventos, noticias o tareas sin necesidad de hacer clic en un lugar que no sabemos a donde nos lleva…

Pues hasta aquí he llegado, ahora te toca a ti darme caña!