Cómo diseñar tablas responsive

Diseñar una tabla responsive consiste en conservar las relaciones útiles de la tabla cuando cambia el ancho disponible. Hacer que quepan todas las columnas es solo una de las posibles soluciones. Una tabla legible con desplazamiento puede servir mejor a una tarea de comparación que una ordenada pila de tarjetas que separa los valores que las personas necesitan comparar.

Empieza por la tarea. ¿La persona necesita comparar varios registros, encontrar uno, examinar sus detalles o actuar sobre un grupo? La respuesta determina qué información debe permanecer junta y cuál puede quedar detrás de un control. Sin ella, las decisiones responsive tienden a convertirse en una sucesión de fuentes más pequeñas, columnas ocultas y botones cada vez más apretados.

Los ejemplos desarrollados utilizan una cola de revisión ficticia con nombre del proyecto, responsable, estado, fecha límite y número de comentarios pendientes.

Identifica la relación que debe conservarse

Una tabla es útil porque la posición transmite significado. Puedes recorrer una columna de arriba abajo para comparar valores o una fila de lado a lado para relacionar un registro con sus atributos. Los cambios responsive pueden conservar una de esas relaciones y debilitar la otra.

En el ejemplo de revisión de proyectos, una persona responsable de la gestión quizá necesite encontrar el proyecto con la fecha límite más próxima que todavía tenga comentarios sin resolver. La fecha y el número de comentarios deben verse juntos, acompañados de la identidad del proyecto. Ocultar el número de comentarios porque casualmente ocupa la última columna impide completar esa tarea, aunque la pantalla resultante parezca más limpia.

Una persona que abre el proyecto que le han asignado para revisar tiene otra necesidad. Quizá le importen el nombre, el estado y una acción clara, dejando los demás detalles disponibles para después. Un resumen compacto con posibilidad de desplegar información podría funcionar bien. El conjunto de datos es el mismo, pero la vista inicial necesaria es distinta.

A continuación, señala la información necesaria para completar cada tarea. Una columna utilizada en todas ellas debe formar parte de la vista principal. Un campo que solo se utiliza después de elegir un elemento puede ser candidato a mostrarse bajo demanda. Es una decisión sobre cómo organizar la información para el trabajo del usuario, no una instrucción para eliminar datos menos importantes.

Separa el ancho de la tabla del ancho de la página

Una tabla ancha no tiene por qué hacer que toda la página se desplace lateralmente. En CSS, un contenedor con overflow-x: auto puede dar a la tabla responsive su propia zona de desplazamiento mientras el título, la descripción, los filtros y el texto que la rodea se adaptan al área visible. El propio contenedor debe poder encogerse dentro de la disposición de la página; un elemento hijo de ancho completo dentro de una columna de cuadrícula rígida todavía puede ensanchar toda la página. Así se limita la zona bidimensional al contenido que realmente la necesita.

La explicación del criterio Reflow del W3C admite una excepción para los contenidos cuyo significado o uso requiere dos dimensiones, entre ellos las tablas de datos. También distingue la tabla del contenido de sus celdas individuales, que sigue necesitando adaptarse adecuadamente. La excepción no justifica que todas las etiquetas o los párrafos de alrededor se desborden. Explicación del criterio Reflow del W3C.

En la práctica, permite que un nombre de proyecto largo ocupe varias líneas dentro de una celda de ancho razonable. No mantengas un enorme espacio vacío solo porque el diseño de escritorio lo utilizaba. Una tabla puede necesitar movimiento horizontal para conservar las relaciones entre columnas y, al mismo tiempo, beneficiarse de unas dimensiones de celda bien pensadas.

El contenedor necesita un límite reconocible. Si la última columna visible termina exactamente en el borde de la pantalla sin indicar que hay más contenido, los usuarios pueden dar por hecho que la tabla está completa. Mostrar parte de la columna siguiente, una barra de desplazamiento visible cuando el entorno lo permita o una indicación breve puede aclarar que hay continuación. Evita que un degradado decorativo sea la única explicación.

Siempre que sea posible, mantén el título de la tabla y el contexto de la tarea fuera de la zona desplazable. Un título como «Proyectos pendientes de revisión» explica qué tienen en común los registros. Una nota breve puede aclarar el orden inicial o una zona horaria pertinente. Son ayudas de orientación, no columnas adicionales que deban competir por el espacio.

USWDS muestra dos patrones responsive realmente distintos

El componente de tablas de U.S. Web Design System ofrece variantes con desplazamiento y con registros apilados. El ejemplo con desplazamiento conserva una matriz; el apilado presenta valores con etiquetas dentro de cada registro cuando el ancho es reducido. Sus ejemplos funcionales permiten apreciar la diferencia.

Esa diferencia importa más que los nombres de los componentes. Una matriz hace visible la relación entre dos columnas mediante la posición. Un registro apilado repite las etiquetas para que un elemento pueda leerse de forma independiente. Los datos pueden ser idénticos y, aun así, cambiar sustancialmente el trabajo necesario para compararlos.

Pruébalo con la cola de revisión: busca la fecha límite más lejana entre los proyectos que tengan más de cinco comentarios. En una tabla puedes examinar juntas las columnas de cantidad y fecha. En tarjetas quizá debas recorrer cada registro y recordar el candidato anterior. Ahora cambia la tarea por «leer el responsable y la fecha límite de Cedar Lodge». La versión apilada puede resultar cómoda porque comparar ya no es lo principal.

Elige la transformación según el esfuerzo que exige al lector

Para la entrega a implementación, especifica algunas condiciones que deben mantenerse: el identificador de la fila sigue disponible, la unidad permanece unida al valor, se entiende por qué campo se está ordenando y la selección conserva el mismo alcance después de cambiar el tamaño. Estas condiciones son más duraderas que exigir que todas las columnas de escritorio quepan en un teléfono. Permiten cambiar la presentación sin modificar silenciosamente la tarea.

Pon a prueba los casos incómodos del patrón. Desplázate hasta el extremo derecho con una etiqueta de fila larga. Despliega registros vecinos cuyo contenido tenga distinta longitud. Selecciona un elemento, cambia el tamaño del área visible y continúa la misma acción. Una captura limpia del estado inicial no mostrará un recuento de selección desactualizado, una columna fija que tape valores o un panel de detalles asociado al registro equivocado.

Cuatro patrones responsive y sus contrapartidas

1. Conserva la tabla y permite el desplazamiento horizontal

El desplazamiento horizontal es una buena opción cuando la tarea principal es comparar valores alineados y todas las columnas siguen siendo pertinentes. Conserva la matriz en lugar de convertirla en otra estructura informativa. Sí obliga a recorrer el ancho, por lo que conviene diseñar esa navegación de forma deliberada.

En la tabla de revisión, coloca el nombre del proyecto cerca del principio y mantenlo visible si la implementación admite una columna fija fiable. De lo contrario, quien se desplace hasta la fecha límite puede perder la identidad de la fila que está leyendo. La columna fija del nombre debe ser lo bastante estrecha para dejar espacio útil a los demás datos.

No inmovilices la mitad de la tabla. En una pantalla estrecha, dos o tres columnas fijas pueden consumir casi toda el área visible y dejar apenas una franja para el contenido que se mueve. Empieza por el identificador más pequeño que conserve el contexto. Si los nombres de proyecto son largos, permite el ajuste de línea o utiliza con criterio un identificador secundario, en vez de fijar un bloque demasiado grande.

Las intersecciones de elementos fijos requieren un tratamiento visual cuidadoso. La celda superior izquierda puede situarse por encima tanto de una fila de encabezados fija como de una primera columna fija. Sin un orden de superposición claro y un fondo opaco, los valores pueden transparentarse o superponerse. Es un buen ejemplo de un detalle que puede verse bien en una imagen estática y fallar durante el desplazamiento.

Comprueba la navegación más allá de los gestos táctiles. Una persona que use el teclado debe poder acceder a la zona y manejarla cuando sea necesario, y el foco debe seguir siendo visible alrededor del contenido interactivo. Verifica el comportamiento implementado en los navegadores y tecnologías de apoyo pertinentes; añadir un contorno a una maqueta no demuestra que exista acceso mediante teclado.

2. Muestra las columnas prioritarias y despliega las demás

Las columnas prioritarias funcionan cuando la mayoría de las decisiones cotidianas dependen de un pequeño subconjunto de campos. Mantén visible ese subconjunto y ofrece después una forma clara de examinar los datos adicionales. Esto puede reducir el ancho sin sacrificar la tarea principal, pero solo si la prioridad elegida es correcta.

Para quien revisa un proyecto, su nombre, estado y fecha límite pueden formar una vista compacta útil. El responsable y el número de comentarios podrían aparecer en una fila desplegada. Para quien busca trabajos vencidos con comentarios sin resolver, ocultar el recuento sería una mala decisión. No existe una lista universalmente correcta de «columnas para móvil» independiente de la tarea del usuario.

Utiliza un control de despliegue cuyo estado expandido sea claro. El contenido desplegado debe verse asociado al registro correcto, especialmente cuando las filas vecinas se parezcan. Repite el nombre del proyecto dentro del panel de detalles si la ubicación del panel hace dudosa esa asociación. Evita etiquetas vagas que obliguen a adivinar si el control abre detalles, un menú o una página nueva.

No obligues a desplegar información para encontrar una acción necesaria en casi todos los registros. Si la tabla es una cola de revisión, abrir una revisión puede merecer un control visible. Esconderlo junto a metadatos poco utilizados ahorra ancho a costa de trabajo repetido. Evalúa qué interacciones se realizan a menudo, no solo qué campos ocupan espacio.

Indica claramente qué columnas se omiten. Si quienes usan escritorio esperan un campo de responsable y este desaparece con un ancho estrecho, la interfaz debe ofrecer una vía comprensible para consultarlo. Una vista de detalles accesible, un selector de columnas o un resumen desplegado pueden cumplir esa función. Retirarlo sin indicación cambia la información disponible para el usuario.

3. Convierte cada registro en una tarjeta con etiquetas

Los registros apilados resultan útiles cuando se lee un elemento cada vez. Cada valor recibe una etiqueta visible y la fila se convierte en un pequeño resumen vertical. Esto puede funcionar en una lista de detalles de pedidos o en un conjunto de citas donde la comparación entre registros sea secundaria.

En la tabla ficticia de proyectos, una tarjeta podría llevar Cedar Lodge como título y mostrar después el estado, la fecha límite, el responsable y los comentarios pendientes. Como registro individual, se lee fácilmente. Sin embargo, comparar el número de comentarios de diez proyectos exige ahora buscar la misma etiqueta una y otra vez en una página mucho más alta.

Antes de elegir este patrón, pide a alguien que compare un mismo atributo en varios registros. Si necesita desplazarse hacia arriba y hacia abajo para recordar los valores, las tarjetas han sustituido el movimiento horizontal por una tarea de memoria mayor a lo largo del eje vertical. Puede seguir siendo aceptable, pero el intercambio debe ser deliberado.

Conserva el mismo orden de etiquetas y valores en todas las tarjetas. No coloques el estado al principio de una y después del responsable en otra solo porque falte un valor. Representa la ausencia con un texto significativo para que la estructura siga siendo predecible.

Evita insertar etiquetas únicamente como contenido generado decorativo sin comprobar el resultado accesible. Que una etiqueta «Fecha límite» sea visible y que su relación con el valor esté disponible mediante el código son cuestiones distintas. El marcado final debe comunicar los datos de forma coherente a quienes no estén mirando la tarjeta visual.

Si la versión de escritorio es una tabla semántica y la versión estrecha modifica su presentación visual, comprueba si las relaciones de la tabla siguen disponibles de la forma prevista. Si la página contiene presentaciones separadas, asegúrate de que el contenido oculto no cree controles duplicados ni lecturas repetidas. La transformación merece una revisión de implementación, no solo ajustes responsive de estilo.

4. Deja que las personas elijan qué comparar

Algunas tablas tienen muchas columnas justificadas, pero rara vez se necesitan todas a la vez. Un selector de columnas puede ayudar a crear una vista útil. Un modo específico de comparación puede permitir elegir un pequeño conjunto de registros y examinar juntos los atributos pertinentes.

Estos controles también añaden trabajo. Una persona nueva puede no saber qué columnas importan o dar por hecho que la vista predeterminada está completa. Ofrece una vista inicial razonable e indica con claridad cuándo hay columnas ocultas. La personalización debe ayudar a quienes conocen el trabajo, en vez de hacer que la comprensión básica dependa de una configuración previa.

En la tabla de revisión, la vista predeterminada podría incluir proyecto, estado, fecha límite y comentarios. Una persona coordinadora podría añadir el responsable, mientras que alguien que revisa sus propios proyectos podría retirarlo. El identificador del proyecto debe seguir disponible para que los registros no se conviertan en filas de números desconectados.

Un modo de comparación es más adecuado para elegir entre unas pocas alternativas que para trabajar con una cola larga. Seleccionar tres productos para compararlos puede ser razonable. Seleccionar todos los proyectos solo para descubrir cuál está vencido sería un desvío innecesario. No añadas un control de comparación simplemente porque la tabla sea ancha.

Si los usuarios pueden guardar una vista, define qué se guarda. La visibilidad de las columnas, su orden, la ordenación de los registros y los filtros son preferencias distintas. Una distribución de columnas guardada no debería conservar inesperadamente un filtro antiguo y ocultar registros nuevos. En un prototipo visual, documenta estos comportamientos como requisitos, en vez de dar a entender que existe persistencia solo porque se ha dibujado un botón de guardar.

Conserva el significado de etiquetas, números y celdas vacías

Los cambios responsive suelen sacar a la luz convenciones de contenido poco sólidas. Una fecha como «04/05» es ambigua incluso en una pantalla grande, pero el problema se hace más evidente cuando no queda espacio para explicaciones alrededor. Elige un formato adecuado para el público e incluye las zonas horarias o el contexto de las fechas relativas cuando afecten a la tarea.

Utiliza unidades coherentes en las columnas numéricas. Un número de comentarios no debería compartir campo con un estado textual salvo que el encabezado y el formato expliquen la diferencia. Alinea de forma consistente los números comparables para facilitar la inspección de las diferencias. Evita reducir la precisión o eliminar unidades solo en pantallas estrechas sin considerar si los valores siguen significando lo mismo.

Decide cómo representar los datos vacíos. «Sin asignar», «Sin comentarios» y «No disponible» describen estados distintos; una celda en blanco no lo hace. En el ejemplo de revisión, un responsable todavía no asignado no debe tener el mismo aspecto que un campo que no ha conseguido cargarse.

Permite que las etiquetas largas ocupen varias líneas cuando eso conserve su significado. Las ayudas emergentes pueden aportar contexto adicional, pero sustituyen mal a una etiqueta necesaria que hay que descubrir repetidamente. Si el título de una columna es demasiado largo para funcionar en cualquier lugar, considera si puede redactarse con más precisión antes de recortarlo de inmediato.

El tutorial de tablas del W3C explica que las celdas de encabezado y de datos necesitan marcado estructural y asociaciones adecuadas. Esto permite una navegación que conserva el contexto más allá de la alineación visual. Utiliza esas indicaciones al implementar el patrón elegido, especialmente cuando tanto los encabezados de fila como los de columna aporten significado. Tutorial de tablas accesibles del W3C.

Mantén los controles vinculados al alcance correcto

La ordenación afecta a un conjunto; abrir detalles afecta a un registro; una acción por lotes afecta a los registros seleccionados. Estos alcances deben seguir diferenciándose cuando la disposición se estrecha. Comprimir todos los controles dentro del mismo menú puede hacer que no quede claro qué cambiará una acción.

Mantén cada acción de fila visualmente asociada a su registro. Un menú situado en el extremo derecho de una tabla ancha puede quedar fuera de la vista al desplazarse horizontalmente. Si abrir el proyecto es la tarea principal, un nombre con enlace puede ofrecer una vía estable, mientras el menú contiene acciones menos frecuentes. La mejor disposición depende de qué acción necesite acceso inmediato.

La selección requiere especial cuidado. Una casilla en una primera columna fija puede ser cómoda, pero no debe desplazar la identidad de la fila. Una vez seleccionados varios registros, muestra el recuento y aclara si la selección abarca la página actual o todo el conjunto de resultados filtrados. La versión responsive no debe cambiar ese significado sin avisar.

Un control de ordenación debe indicar la dirección activa sin depender por completo de una flecha diminuta. Comprueba que se siga entendiendo por qué campo se ordena si su columna está oculta. A veces resulta más claro trasladar la elección de ordenación a un control etiquetado encima de la tabla que mantenerla unida a un encabezado invisible.

Examina también los filtros y la paginación con el ancho estrecho. La tabla puede ser legible mientras la barra de filtros se sale de la página o los controles de paginación quedan demasiado juntos. Estos controles pertenecen a la misma tarea aunque estén fuera de la cuadrícula. Prueba el recorrido completo, desde encontrar registros hasta actuar sobre ellos.

Revisa con contenido incómodo y tareas reales

Utiliza contenido que ponga a prueba la disposición: un nombre de proyecto largo, un responsable sin asignar, un número elevado de comentarios, una fecha ausente y una etiqueta de estado que ocupe varias líneas. Incluye suficientes filas para exigir movimiento en la dirección que permite el patrón. Tres registros perfectamente uniformes revelan muy poco sobre una tabla responsive.

En la versión con desplazamiento, pide a quien revise la tabla que relacione una fecha límite lejana con el nombre de su proyecto después de moverse lateralmente. En la versión desplegable, pídele que encuentre un detalle y vuelva al registro siguiente. En las tarjetas apiladas, que compare un valor en varios proyectos. Estas tareas revelan si la relación conservada es la que el usuario necesita realmente.

Prueba el zoom del navegador además de los anchos estrechos de los dispositivos. Una persona que amplía el contenido en escritorio puede encontrarse con la misma disposición limitada por un motivo distinto. Comprueba que el texto siga siendo legible, los controles accesibles y las zonas fijas no cubran la mayor parte del espacio utilizable.

En OpenDesign puedes previsualizar la disposición de una tabla HTML con distintos tamaños predefinidos del área visible, añadir comentarios a una zona demasiado densa y ajustar el texto o los estilos. Mantén los registros de muestra y la tarea elegida dentro del contexto de diseño. Prueba el marcado semántico, el desplazamiento mediante teclado, la ordenación y el estado guardado en la tabla implementada.