Hoy el dashboard responde “¿cuántos hay?”. Esta propuesta lo convierte en una superficie que responde “¿dónde está trabado y qué hago primero?” — con el área de cada bloque cargando la magnitud real, filtros de un solo clic y una sola lente activa a la vez. Cada rol ve exactamente su recorte, sin puertas grises.
En un mapa de magnitud, el área de cada bloque es el dato. La pregunta era
si ese dato podía ser dinero, porque el backend lo prohíbe explícitamente —
UnifiedPaymentStatsDto dice textual: “the admin app must NOT show
aggregated revenue or ticket-average totals”.
La decisión: la lente Dinero no se abre por ahora. El dashboard mide en
unidades operativas —CBM, conteos y días— y la regla del backend queda intacta. El dinero
sigue viviendo solo en /finanzas, con su gate actual. No hay toggle
apagado en pantalla: lo que no se construye, no se dibuja.
Cómo vuelve, si vuelve: el diseño ya lo contempla y el código conserva la
bifurcación. Abrirlo sería sumar un eje gateado por FINANCES y cambiar la
unidad del área — no rehacer los módulos. La decisión pendiente ese día será solo el
alcance por rol: ADMIN únicamente, o también MANAGER como está
gateado /finanzas hoy.
Un dashboard de widgets obliga a leer ocho cajas y armar la conclusión en la cabeza. Un mapa la entrega antes de leer: lo grande está trabado, lo oscuro está viejo. La jerarquía visual hace el trabajo que hoy hace el operador.
De ahí salen las tres reglas que gobiernan cada pixel de esta propuesta. Una sola lente activa — nunca dos escalas compitiendo en el mismo gráfico. El color tiene un trabajo por gráfico: magnitud (un tono, más oscuro = más), identidad (cuatro tonos en orden fijo) o estado (reservado, siempre con etiqueta). Un clic, un cambio: todo filtro es un chip; no hay formularios ni Aplicar.
El área de cada bloque es la magnitud; el tono es la antigüedad promedio — dos variables sin gastar el canal de identidad. Un clic entra al bloque, otro vuelve. Es interactivo acá abajo: probalo.
Están los 40 clientes activos, sin bucket de “Otros”: acá el color es secuencial y no categórico, así que ninguna paleta obliga a agrupar la cola — y ver la cola completa es justamente lo que responde “¿de quién dependo?”. Y cuando un bloque queda con un solo hijo —lo que pasa siempre al aislar un segmento— el anidado se colapsa a un bloque plano: un encabezado y un hijo repitiendo el mismo número no es jerarquía, es ruido.
Y sobre esa misma superficie corren tres ejes independientes, que es lo que evita que el dashboard se convierta en veinte pantallas: “Ver por” cambia qué agrupa el área (ruta, cliente, método de pago, destino) y “Comparar” cambia contra qué —mes anterior, año anterior o tres años atrás— y con eso el color deja de medir antigüedad y pasa a medir si crece o si cae, en escala divergente que se satura según el horizonte: un Δ de tres años no se mide con la misma vara que uno mensual. Cuatro ejes por cinco horizontes dan veinte vistas con dos controles y ninguna pantalla nueva.
El mapa dice dónde. Estos cuatro dicen por qué y desde cuándo. Cada uno usa la forma que su pregunta pide — ninguno es un gráfico porque quedaba lindo.
Nada de lo de arriba es gusto personal. El esqueleto es el mantra de Shneiderman (1996), que sigue siendo el estándar de facto para diseñar exploración de datos: panorama primero, después zoom y filtro, y el detalle solo cuando se pide. Sobre eso corren las reglas de marcas y color del sistema de diseño.
El mapa de bloques y el de Venezuela abren la pantalla. Antes de leer un solo número ya sabés dónde está el volumen y dónde está viejo. Un tablero de widgets te obliga a construir esa conclusión leyendo ocho cajas.
Clic en un segmento lo aísla; alt+clic lo quita. El filtro vive en una sola fila arriba de todo y alcanza a todos los módulos: KPIs, mapas, embudo, clientes, pagos y series. Nunca hay dos gráficos mostrando rebanadas distintas — esa es la forma más común de que un dashboard mienta.
El hover da el detalle, el clic entra un nivel, y cada gráfico tiene su vista de tabla. El tooltip nunca es el único camino a un dato: enseña, no guarda bajo llave.
Al aislar Marítimo, cada número se recalcula a su parte marítima — no se ocultan barras dejando totales viejos en pantalla. Es la diferencia entre un filtro real y un filtro decorativo.
Identidad (categórico, orden fijo), magnitud (secuencial, un tono), polaridad (divergente con gris al cero) o estado (reservado). Y el color sigue a la entidad: Marítimo es ámbar en el apilado, en la tendencia y en cualquier módulo que venga después. Filtrar nunca repinta a los que quedan.
Un dashboard que se cierra sin que pase nada es un informe bonito. Cada hallazgo del
alcance actual se convierte en una fila de “Qué hacer ahora” que deja la
cola de /acciones —que ya existe en el admin— ya filtrada al
mismo alcance. El dashboard no reconstruye el centro de acciones ni inventa un vocabulario
nuevo: usa los cinco tipos que la plataforma ya tiene, con sus mismos acentos. Y una acción
para la que no tenés permiso no aparece, igual que todo lo demás.
Magnitud → área o barra. Composición → apilado. Polaridad → divergente. Un número → una ficha, no un gráfico de una barra. Por eso el mes a mes tiene tres formas: son tres preguntas distintas sobre los mismos datos. Ese selector cambia la forma, no la rebanada — por eso vive en la tarjeta y no arriba con los filtros.
Mogos ya tiene dos capas: @Roles grueso (la ruta se abre o no)
y la matriz fina ResourceType × Action. La propuesta usa las dos
sin inventar una tercera: la ruta pide DASHBOARD:READ, y
cada módulo se monta solo si su recurso está en los permisos del usuario.
La regla de oro de la interfaz: un módulo sin permiso no se dibuja apagado — no existe. Nada de tarjetas bloqueadas con candado, que solo enseñan lo que no podés ver. El mapa se reacomoda con lo que sí tenés, y el resultado se siente completo en todos los roles.
| Módulo recurso requerido | ADMIN | MANAGER | Operación | AGENT |
|---|---|---|---|---|
| Mapa · lente Operación DASHBOARD:READ | ✓ | ✓ | ✓ | — |
| Mapa · lente Dinero FINANCES:READ | fuera de alcance | — | — | — |
| KPI · pagos por verificar PAYMENTS:READ | ✓ | ✓ | ✓ | — |
| Embudo de la orden ORDERS:READ | ✓ | ✓ | ✓ | ✓ propio |
| Cuellos de botella FREIGHTS:READ | ✓ | ✓ | ✓ | — |
| Bloque almacén WAREHOUSES:READ | ✓ | ✓ | ✓ | — |
| Eje “Cliente” + Top clientes CUSTOMERS:READ | ✓ | ✓ | ✓ | ✓ propios |
| Eje “Método de pago” PAYMENTS:READ | ✓ | ✓ | ✓ | — |
| Mes a mes · año contra año DASHBOARD:READ | ✓ | ✓ | ✓ | — |
| Acción · Aprobar orden ORDERS:UPDATE | ✓ | ✓ | ✓ | — |
| Acción · Consolidar WAREHOUSES:UPDATE | ✓ | ✓ | ✓ | — |
| Acción · Cobrar PAYMENTS:UPDATE | ✓ | ✓ | — | — |
| Acción · Atender / Responder MESSAGING:UPDATE | ✓ | ✓ | ✓ | ✓ propios |
La lente Dinero queda fuera de la rebanada 1 por decisión de negocio: el dashboard mide en
unidades operativas y los agregados monetarios siguen solo en /finanzas.
La paleta no se eligió por gusto: se derivó de los tokens de Mogos y se corrió contra los seis checks — banda de luminosidad, piso de croma, separación bajo daltonismo (protanopia y deuteranopia), piso de visión normal y contraste sobre la superficie. El orden de los slots es el mecanismo de seguridad: no se cicla ni se reordena.
$ node validate_palette.js "#B6791A,#1D93C0,#7E9B33,#1E5BBF" --mode light Palette (light, surface #FFFFFF, categorical): 4 slots [PASS] Lightness band todos dentro de L 0.43–0.77 [PASS] Chroma floor todos ≥ 0.10 [PASS] CVD separation peor par #7E9B33↔#1D93C0 ΔE 20.0 (protan) [PASS] Normal-vision floor peor par #7E9B33↔#1D93C0 ΔE 20.3 [PASS] Contrast vs surface todos ≥ 3:1 → ALL CHECKS PASS $ node validate_palette.js "#8BB7FF,…,#0C4196" --ordinal --mode light [PASS] Lightness monotone los pasos leen claro→oscuro [PASS] Adjacent ΔL todos los saltos ≥ 0.06 [PASS] Light-end contrast #8BB7FF a 2.04:1 sobre blanco [PASS] Single hue dispersión de tono 0° → ALL CHECKS PASS
La comparación temporal necesita una escala distinta: divergente, porque la pregunta ya no es “cuánto” sino “de qué lado del cero”. Dos tonos de marca, brazos simétricos en luminosidad y gris neutro en el medio — nunca un tono en el cero, que es el error que hace ver crecimiento donde no lo hay.
El rojo de marca queda fuera de la escala categórica a propósito. En el manual de Mogos el rojo es energía y alerta; si además fuera “serie 5”, un bloque en rojo dejaría de querer decir algo anda mal. La escala se corta en cuatro y el rojo se reserva. El modo oscuro tiene sus propios pasos sobre marino — validados aparte, no un volteo automático.
Es la única decisión bloqueante. Define si el backend expone agregados monetarios
gateados por FINANCES o si el mapa se queda en unidades operativas.
Cada módulo pide su propio recurso, así el guard corta datos que el rol no puede ver antes de que salgan del servidor. Un endpoint monolítico obliga a filtrar en el cliente, que es exactamente donde no se filtra nada.
/metricas convive con /dashboard mientras se valida.
El dashboard actual sigue siendo el home de operaciones; nadie se queda sin piso.
Los slots categóricos y la rampa secuencial suben a tokens.css de Mogos
como tokens de primera clase. El próximo gráfico ya nace correcto.
Todo lo que se ve acá arriba es interactivo y corre con datos de ejemplo — la geometría, los filtros y el recorte por rol son reales; los números, no. Falta una sola decisión para que deje de ser una propuesta.