Report Builder & Filtros Avanzados

En un query builder con condiciones combinadas, la lógica booleana debe verse, no inferirse. El operador AND/OR entre condiciones es un control seleccionable explícito, y los grupos anidados se delimitan con un borde lateral coloreado e indentación para que el orden de evaluación quede claro. La ambigüedad entre "cumplir todas las condiciones" y "cumplir cualquiera" es causa directa de reportes con resultados inesperados: los operadores booleanos confunden a usuarios no técnicos porque el uso coloquial de "y"/"o" difiere de su semántica lógica. Una lista plana de condiciones sin operador visible obliga a adivinar qué hace el sistema por defecto.

Cada condición del constructor debe leerse como una oración: [Campo] [operador] [valor], "Fecha es después de 2025-01-01", "Monto está entre 100 y 500". Los operadores usan palabras del dominio del usuario ("es", "contiene", "está entre", "es mayor que") en lugar de símbolos de programación (=, >, !=) y campos de texto libre crudos. La legibilidad de la condición construida predice directamente la confianza del usuario en el resultado: si tiene que traducir mentalmente status == "A" antes de confiar en el reporte, ya perdiste. Las etiquetas de campo también deben ser claras ("Estado del pedido", no "status").

Toda condición activa debe aparecer como un chip removible (con icono X) en una zona permanente sobre los resultados, fuera del panel de filtros. Cuando hay más de un filtro activo, un botón "Limpiar todo" siempre acompaña los chips. Ocultar el estado del filtro dentro de un panel cerrado obliga al usuario a reabrirlo solo para auditar qué tiene activo, y eleva el costo de corregir un filtro equivocado. Según Baymard, el 28% de los sitios no muestran un resumen de los filtros aplicados, dejando al usuario sin forma rápida de verificar qué condiciones están actuando.

Aplicar filtros al instante o bajo demanda no es estética: es rendimiento y costo. Para datasets pequeños o queries rápidas (~<200ms), la aplicación instantánea reduce fricción y valida cada selección en tiempo real. Para datasets grandes o queries con JOINs costosos, un botón "Aplicar" evita llamadas API redundantes, estados intermedios vacíos y bloqueos de la UI mientras el usuario sigue eligiendo. El error es disparar una query por cada checkbox sobre millones de filas, congelando la interfaz entre clics. La elección depende de la capacidad de fetch del sistema y la complejidad de la consulta, no de una preferencia visual.

En reportes de uso repetitivo los usuarios recrean las mismas combinaciones de filtros sesión tras sesión. El patrón de saved views permite nombrar, guardar, recuperar, marcar como predeterminada y compartir una configuración completa de filtros. Esto reduce carga cognitiva, elimina trabajo redundante y convierte el report builder en una herramienta de colaboración. El patrón formal (AWS Cloudscape) incluye seleccionar la vista, acciones (guardar nueva, actualizar la actual, eliminar, fijar default), indicador de cambios sin guardar y distinción entre vistas personales y compartidas con el equipo. Sin esto, el usuario reconstruye "Activo Y Fecha > 2025 Y Región Norte" cada vez que abre el reporte.

Un estado de cero resultados sin contexto es un callejón sin salida. El sistema debe identificar la condición más restrictiva, cuantificar cuánto se recupera al relajarla ("Quitar el filtro de Fecha mostraría 312 registros") y ofrecer un botón directo para hacerlo, además de un enlace a "Limpiar todos los filtros". No basta con "No se encontraron resultados": el usuario necesita saber que fue demasiado específico y cómo corregirlo sin empezar de cero. Baymard observa que cerca de la mitad de los sitios no dan formas efectivas de recuperarse de una búsqueda sin resultados, y que los usuarios suelen intentar 3-5 iteraciones antes de abandonar.

Un report builder vacío genera parálisis; uno que vuelca 50.000 filas sin filtrar genera ruido. Al abrir un reporte nuevo, pre-carga filtros sugeridos según el contexto del usuario (periodo actual, estado activo, su propia entidad) para mostrar un estado útil desde el primer render. Los filtros sugeridos deben ser descartables individualmente, cada uno con su X, no impuestos. Una vista predeterminada marcada como default que se aplica al entrar a la página logra exactamente esto. Limita además el número de filtros visibles a los atributos más relevantes para que el usuario navegue sin saturarse.

Un query builder complejo es uno de los patrones más exigentes en accesibilidad. Cada control de una condición (selector de campo, de operador, campo de valor) necesita un label explícito; cada condición se envuelve en role="group" con aria-label ("Condición 1"); y al actualizar los resultados, una región role="status" aria-live="polite" aria-atomic="true" anuncia el conteo nuevo ("248 registros encontrados") como una unidad, sin robar el foco. Toda la interacción debe ser operable por teclado siguiendo el patrón APG de combobox: el foco permanece en el campo mientras se navegan opciones con aria-activedescendant, Escape cierra el popup y Enter acepta. Tres selects sin label ni grupo dejan al usuario de lector de pantalla sin saber si el filtro funcionó.