Cómo adaptar tablas de datos a formatos móviles o responsive

Este artículo también está disponible en: English (Inglés)

¡Hola de nuevo, seguidores del diseño! El artículo de hoy nace de una explícita petición de mi compañera Nadine, que se ocupa a menudo del tratamiento y pintado de datos. Y es que, a pesar de lo mucho que ha evolucionado el diseño, hay algunos elementos que no podemos terminar de desterrar: las tablas.

Admito que yo les tengo una especial manía por esa herencia de maquetar con ellas en HTML, que todavía sigue siendo increíblemente vigente en el diseño para correos electrónicos. Sin embargo, lo que es evidente es que las tablas (como conjuntos de columnas y filas) son la solución más universal para entender y mostrar datos.

Yo cuando tengo que usar tablas para maquetar emails

Ahora bien, es una solución nacida y forjada para espacios horizontales y relativamente anchos (y no hablo sólo de pantallas, también de folios, libros, etc.). Desde el momento en que pasamos a consumir información desde nuestros dispositivos móviles nos encontramos con que las tablas no son elementos tan sencillos ni intuitivos de adaptar.

¡Pero no temáis! Vamos a ver qué ideas y mecanimos podemos aplicar para tener algo que respete una buena experiencia de usuario en un contexto visual reducido. ¡Empecemos!

Nuestro material de ejemplo

La mejor manera de poner esto a prueba es tomando una tabla con datos de ejemplo. Para ello hemos seleccionado algo neutro pero jugoso: una lista de frutas y sus características alimenticias con datos sacados de aquí. Vamos a ir transformando esta tabla en diversas versiones para su consulta en una pantalla de móvil, aplicando -nunca mejor dicho- una macedonia de propuestas.


Propuesta 0 – De tabla a imagen

Pasar una tabla a imagen no es buena idea

Como bien dice el título, una opción -de las que una se encuentra documentándose para hacer el artículo- es convertir nuestra tabla a un formato de imagen. La añado como punto cero porque no considero que sea una solución de verdad, ni la vamos a aplicar, pero vale la pena mencionarla como apaño para casos muy concretos, como los siguientes.

Imaginemos que para nuestro proyecto el uso de tablas es prácticamente anecdótico. Imaginemos que usamos una aplicación de búsqueda y calificación de hoteles, donde cada hotel tiene una galería de imágenes y, en su ficha, algunos hoteles quieren añadir una tabla con los horarios de apertura del buffet de desayuno, el restaurante o la zona de piscinas. Crear una sección aparte con tablas responsive para esto puede ser un desarrollo inútil y una pérdida de recursos, ya que quizás no todos los hoteles nos den esa información y/o el formato varíe mucho de un caso a otro. La solución entonces puede ser pasarla a imágenes e incluirla en la galería de cada hotel.

Otro ejemplo podría ser un proyecto que haga uso de tablas muy básicas que, en un momento dado, pueden ser interesantes para que los usuarios las guarden. Quizás las quieran consultar con frecuencia y ver off-line, incluso imprimirlas. Por ejemplo, la tabla de un horario semanal de un gimnasio, que se va a mantener durante medio curso escolar. Si en lugar de usar una tabla convencional en código usamos una imagen ampliable, el usuario podrá ver estos datos de forma sencilla, girar el móvil si así lo desea y hacer zoom como está acostumbrado consumir imágenes, además de poder guardarlas o compartirlas fácilmente.

✅ Pros:

  • Es rápido y fácil de hacer (pero no indoloro).
  • El usuario consume los datos en formato de imagen, que le es familiar en un dispositivo móvil, y por lo tanto…
  • Fácil de compartir, fácil de imprimir, fácil de trabajar por parte del usuario.

❌Contras:

  • Perdemos los datos en el proyecto, ya no son legibles por parte de nuestra aplicación, ni editables, ni indizables, por lo tanto perjudica al SEO y mucho.
  • No es «interactivo» porque no se puede conectar directamente a una base de datos.
  • A la luz de lo anterior, dificulta la actualización de datos porque puede depender de que te pase otro departamento la imagen ya trabajada.
  • Puede forzar al usuario a girar el teléfono, es decir, perjudica a su experiencia.
  • Leer textos en formato imagen es incómodo y, si la imagen es pequeña, se pueden leer fatal.
  • Las imágenes pesan más que el código, de modo que aumenta el tiempo de carga (y eso es malo para el SEO y la experiencia de usuario).

En general los contras de esta solución pesan demasiado. Jamás recomendaría esta aproximación salvo que el hecho de crear una tabla vaya a llevarse mucho más tiempo y recursos de los que vale la pena invertir en ello. No obstante, haber pasado por esto nos puede llevar a una solución híbrida, como la siguiente:

Tabla en formato de datos con una versión descargable

Si hemos dicho algo interesante aquí es que el usuario quiera poder guardar los datos y, en esos casos, recomiendo mantener nuestra tabla hecha en código y añadir un botón de descarga para proporcionarle una versión amigable a la impresión en formato PDF, que pesa poco y no pierde calidad.

Mantener la tabla en formato de datos y añadir una opción en PDF descargable hace la vida de los usuarios más fácil

Propuesta 1 – Síntesis de datos

Ahora sí empezamos con lo bueno. La manera en que una persona usa un ordenador de escritorio es diferente a la de su uso de un dispositivo móvil. Tenemos menos tiempo y menos espacio para impactarle, por lo tanto, debemos priorizar. Antes de proponer cualquier cambio gráfico es importante sintetizar: mostremos sólo lo principal para el usuario, al menos, en un primer nivel. Siempre podemos darle acceso a más detalles en pantallas secundarias. Esta propuesta de simplificación es útil para todos los casos porque se puede aplicar a cualquier tipo de dato y de contenidos.

Esta simplificación de tablas la podemos encontrar también el páginas como la de Bloomberg, en su sección de bolsa. Puedes ver que pasamos de 8 columnas en escritorio a 4 en móvil.

¿Consejos a la hora de sintetizar datos? 

  • Muestra sólo lo que los usuarios realmente necesitan saber. Haz un ejercicio de empatía (o un test de uso de tu aplicación) y deja sólo lo que más vaya a usar el usuario a la vista y accesible.
  • Deja fuera los datos inútiles. Datos intermedios o valores que interesan desde el lado de la investigación pero no de forma final al usuario no pintan nada en tu tabla.
  • Abrevia en la medida de lo posible y añade iconos o imágenes sustitutivas.
  • Elimina las repeticiones. Si algunos valores son redundantes o aportan información parecida, elige sólo una manera de mostrarlos.
  • Encuentra alternativas para ciertas dimensiones. Por ejemplo, no necesitamos la fecha de registro si ponemos un filtro de ordenación de más reciente a menos.

Aplicado a nuestro ejemplo:

En nuestros datos de prueba hemos decidido que lo principal para el usuario son, aparte de la identificación de las frutas, los valores de proteínas, calorías, fibra. Añadimos algunas imágenes y algunos cambios de estilo para hacerla más atractiva y… ¡Tachán!

✅ Pros:

  • Ayudamos a que la experiencia de la consulta de datos sea más abreviada, fácil y agradable.
  • Damos al usuario con rapidez la información que creemos que más valor tiene.
  • Visualmente destacamos los datos más importantes, eliminando «ruidos».

❌Contras:

  • Debemos sacrificar parte de la información, y no siempre todo lo esencial va a caber en el ancho de un móvil.
  • A menudo no es fácil establecer un sesgo de qué información es más importante que otra sin testeo previo.
  • Estamos orientando la experiencia de usuario entorno a lo que nosotros consideramos importante.

2 – El scroll/slide horizontal con feedback

Aunque la hemos dejado en un tercer lugar, ésta es sin duda la respuesta más evidente. Ésta es una solución para tablas bastante anchas y no infinitamente altas. Si la tabla no cabe de ancho, pues se corta y hacemos que el usuario se deslice en el eje horizontal para ver la integridad de los datos. Ésa es la solución más fácil. También es el comportamiento por defecto de una tabla en web si el contenedor supera el ancho, pero eso no lo hace responsive.

Algo crucial si vamos a usar un scroll es adaptarlo al lenguaje móvil, y que sea evidente para el usuario en qué posición se encuentra. Recordemos que en móvil los scrolls no suelen verse sin interacción del usuario. Debe ser intuitivo que la tabla tiene otros elementos, para invitar al usuario a desplazarse por ellos. Véase, por ejemplo, convirtiendo la tabla a slides y usando una barra de navegación como feedback, fija en la parte inferior de la pantalla.

Aplicado a nuestro ejemplo:

La idea de simplificar a lo que cabe es muy bonita, pero nos hemos cargado algunas dimensiones que quizás fueran esenciales por no caber en nuestro ancho de pantalla móvil. Vamos a retomar la idea de la simplificación pero con menos sacrificios. En esta ocasión vamos a darle una información adaptada: un top tres de vitaminas y de minerales, por ejemplo. En lugar de comparar por cantidades de estos valores, vamos a ordenarlos y mostrar qué tres elementos de estas dos categorías son más importantes en cada fruta. Pero, además, vamos a poner un sistema de paginación adaptado a móvil, de manera que el usuario sepa en qué parte de la tabla se encuentra.

✅ Pros:

  • La experiencia visual es agradable, resumida y permite la interactividad del usuario para saber más.
  • El orden de la información puede priorizarse fácilmente, poniendo lo más valioso delante y dejando lo menos evidente para el final de la tabla.

❌Contras:

  • La información que busca quizás no está al primer vistazo, debe hacer scroll (y, si no le resulta evidente, podemos perder su interés).
  • Poner el sistema de paginación de móvil puede no ser tan intuitivo si se trata de una web. El uso de librerías externas (como Slick -en nuestro ejemplo- o Bootstrap) hace la vida más fácil, aunque también aumenta el tiempo de carga.
  • Si hay muchos datos, el usuario se puede extraviar consultándolos, sobre todo si no mantenemos el hilo de la cabecera o la primera columna. Para eso…

3 – Scroll con elementos fijos o filas apiladas para no perderse

Ante los contras de la solución anterior tenemos… ¡las columnas fijas y las filas apiladas! No tiene mucho más misterio.

En primer lugar, las columnas fijas nos permiten mantener visible en todo momento el identificador del elemento que se consulta, evitando que el usuario se cruce de líneas sin darse cuenta a la hora de leer los datos. Lo mismo con las cabeceras en caso de que el listado sea muy alto.

Por otro lado, las filas apilables nos permiten colapsar y descolapsar categorías. En nuestro caso de las frutas no es demasiado interesante, pero imagina que los datos que mostramos en las filas son, por ejemplo, las especificaciones de un móvil, agrupadas por temas (pantalla, cámara, conectividad, etc.). Pues ahí sí puede ser muy interesante que, conforme el usuario haga scroll, no pierda de vista la categoría en la que se encuentra, a la cual le podríamos dar un comportamiento «sticky».

Aplicado a nuestro ejemplo:

Hemos mantenido la idea de la tabla anterior pero, esta vez, independizando la primera columna y la fila de cabecera, de manera que pueda mantenerse fija y siempre visible, mientras los valores varían dentro de la paginación.

✅ Pros:

  • Es fácil e intuitivo de usar.
  • El usuario no se pierde cuando navega ni vertical ni horizontalmente. Siempre tiene presente en qué dimensión se encuentra.

❌Contras:

  • Es válido para celdas con contenidos cortos. Si hubiera mucho, se haría bastante pesado de leer.
  • No es una buena solución para tablas con un exceso de datos porque obliga a hacer scroll bastantes veces.
  • No permite tener una visión clara de conjunto.

4 – De tabla a tarjetas de datos

Supongamos que, a pesar de todo, queremos seguir dándole al usuario toda la información que teníamos en nuestra tabla inicial. Lo que proponemos con este diseño es convertir cada elemento a una tarjeta de datos sintetizados, accesibles de un sólo vistazo. Ésta es una solución especialmente válida cuando tienes más columnas que filas y no tienes una enorme cantidad de datos en filas y/o te puedes beneficiar de otras opciones de filtrado para tu tabla (por ejemplo, una barra de filtros superiores o incluso una caja de búsqueda).

Un elemento muy útil para estos casos son los acordeones colapsables de datos. Gracias a los mismos podemos evitar que las tarjetas se hagan demasiado grandes y ocupen demasiado en la pantalla, de modo que siga siendo fácil pasar de un item a otro. 

✅ Pros:

  • Evitamos el scroll dentro de un mismo elemento.
  • Se puede aplicar a grandes cantidades de datos, sin sacrificar contenidos.
  • Le damos al usuario una visión de conjunto de un elemento con todos sus valores, añadiendo la opción de que despliegue detalles.
  • Es una manera versátil de presentar la información, que nos aporta mucha flexibilidad a nivel de diseño.

❌Contras:

  • Los nombres de las columnas se van a repetir.
  • Hace complicado establecer comparaciones entre elementos, porque la visión queda individualizada.
  • Si no tenemos otras formas de filtrar o son muchos elementos, complicamos la experiencia de usuario porque le obligamos a pasar por muchos elementos hasta encontrar el que busca.
  • Seguimos teniendo que hacer scroll en distintas direcciones para obtener todos los datos de interés.

5 – Comparador

A raíz del mayor contra de la solución anterior llegamos al comparador, que aúna lo mejor de varios mundos. Cuando sabemos que el consumo de datos se va a hacer esencialmente para comparar propiedades de distintos elementos, es la solución óptima, pero también va a suponer un desarrollo más largo y costoso.

Aquí vamos más allá de crear una tabla en sí, dándole al usuario la capacidad de elegir qué quiere meter en ella. Necesitamos pues plantear el diseño en dos partes: una dedicada a cada ficha de producto, y otra que contemple un comparador dinámico donde se puedan añadir elementos (hasta un límite razonable a nivel visual) y borrarlos a conveniencia.

Dejemos las frutas a un lado. Para ver esto en acción recomiendo visitar Kimovil, mi comparador preferido a nivel de diseño.

Kimovil tiene un comparador épico para móviles, tablets y otros productos.

Un matiz: hay que tener cuidado de no sobrecargar nuestros comparadores nunca. Aunque en una vista de escritorio podamos tener en paralelo hasta unos 5 o 6 elementos, en móvil nunca deberíamos mostrar más de dos elementos, y facilitar que el usuario pueda desplazarse entre ellos con un sistema de navegación en slides o incluso con un drag&drop.

✅ Pros:

  • Se aplica a conjuntos de elementos con muchos campos y detalles, permitiendo una gran cantidad de datos.
  • Funciona para cualquier tipo de datos.
  • Facilita la comparación de elementos.
  • Es muy útil para plataformas de e-commerce o calificadores de productos.
  • Ayuda al usuario a tomar decisiones y le invita a la acción.

❌Contras:

  • Implica un desarrollo más largo y costoso.
  • En móvil sólo vamos a ver dos elementos por vez, así que las comparaciones quedan reducidas a esas dos dimensiones.
  • Complica la experiencia de usuario y el diseño para que el comparador sea intuitivo, usable y fácil de alterar.

6 – Pick and choose

Por último, otro caso en que le podemos dar poder al usuario es generando una tabla cuyas dimensiones sean dinámicas y dependan, por ejemplo, de un selector, de un filtro de búsqueda o de botones que toggleen la visibilidad. Dicho de otro modo: proporcionamos al usuario la opción de marcar y desmarcar dimensiones de consulta en la tabla. Para estos casos, lo ideal es comenzar con una tabla básica que tenga la información principal y proporcionar alguna manera para mostrar y ocultar otras dimensiones adiconales de forma fácil para el usuario.

Si crees que tu proyecto se puede beneficiar de este sistema, la mejor opción es echar un vistazo a alguna librería que te facilite este trabajo. Una de las más potentes es Data Tables, que es la que hemos usado en esta ocasión. Se basa en el formato tabla tradicional y es muy sencillo de implementar con diferentes tipos de proyecto.

* Si la versión en iframe te da problemas, prueba a desplazarte horizontalmente con el teclado o accede desde un móvil a esta dirección de la demo.

✅ Pros:

  • Podemos obtener lo mejor de las tablas vistas en casos anteriores pero sin limitar al usuario a las dimensiones elegidas.
  • Los datos no se sacrifican, sólo se dejan a distancia de un segundo click.
  • Permitimos una consulta de datos orientada a las preferencias del usuario, para que cruce las dimensiones que vea pertinentes.

❌Contras:

  • La responsabilidad de mostrar los datos adecuadamente recae sobre el usuario. Si no está bien planteado el diseño, la consulta puede no aportarle lo que desea.
  • Implica un «aprendizaje» mediante prueba y error, lo cual puede no casar bien con usuario no proactivos.
  • Una tabla dinámica es más compleja a nivel técnico y, por tanto, hay más cosas que pueden fallar. Si además dependemos de librerías externas quedareos bajo el paraguas de sus limitaciones.
  • El tiempo de desarrollo y diseño es mayor.

Referencia: Aplicación de las distintas soluciones en un caso real

Ahora que ya hemos visto distintas opciones para hacer nuestras tablas más agradables en materia de UX, te invito a que eches un vistazo al rediseño de Joe Winter para una macrotabla de riesgos. Es un caso real estupendo, donde se mezclan varias de estas ideas.

Joe Winter coge una tabla monstruosa y lo convierte en la app más amigable ever.

Resumiendo – consejos finales

Hemos visto un montón de opciones, pero no todas van a ser igual de adecuadas según el caso. ¿Qué es lo que deberíamos considerar a la hora de decantarnos por una solución u otra?

  • Tipos de dato y dimensiones de esos datos:
  • Existencia de prioridad de los datos: siempre suele haberla, pero hay casos en los que es mucho más evidente que ciertos datos son esenciales y otros aportan poco valor añadido. En esos casos puedes ignorar los últimos o dejarlos más escondidos, para aquellos casos en los que el usuario los quiera buscar.
  • Consumo de esos datos: debes preguntarte e imaginar cómo van a consultarse esos datos: ¿se van a usar de manera comparativa, se van a ver en su conjunto global, o quizás es interesante una evolución en el tiempo?
  • Girar el móvil debería ser el último recurso: tratemos de evitar esto siempre. Recuerda que el usuario está utilizando tu web o aplicación de una determinada forma. Si se ve obligado a cambiarla es porque has tomado una mala decisión de diseño. 

Espero que os haya resultado útil el artículo. Si queréis ver la magia detrás de las distintas tablas de frutas, aquí tenéis un enlace al repositorio de demo que he estado utilizando. ¡Y con esto acabamos!

Si aplicáis alguna de las soluciones del artículo a vuestro rediseño responsive, quiero verlo. Siempre me hace mucha ilusión la desestructuración de las tablas tradicionales a favor de soluciones más imaginativas. ¡Un saludo y cuidaos mucho!

Añade tu respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *