Dashboards sobre un data pool en AWS: el caso de un anillo inteligente
Diseño del dashboard de resumen. Las cifras son ilustrativas.
Construimos el portal de gestión interno de una empresa que fabrica un anillo inteligente: un wearable de salud que mide frecuencia cardíaca, oxígeno en sangre, temperatura de la piel, frecuencia respiratoria, sueño y actividad. A la empresa le faltaba un lugar donde su propio equipo pudiera ver cómo iba el negocio y mirar con detalle qué estaba haciendo el anillo de un cliente concreto.
En este post recorremos ese portal: cómo construimos sus dashboards, cómo se apoyan en el data pool de la empresa en AWS y qué aprendimos sobre representar datos de salud en el navegador.
Dos públicos, un portal
La vista de negocio. La dirección quería una pantalla que pudiera dejarse abierta en un monitor y que respondiera a "¿cómo vamos?" sin que nadie la tocara: anillos fabricados y vendidos, nuevos usuarios, actividad de sincronización, incidencias y anillos en reparación, siempre comparados con el periodo anterior.
La vista de soporte. Atención al cliente necesitaba justo lo contrario: buscar un usuario o un anillo por su número de serie y verlo todo, desde los dispositivos y las versiones de firmware hasta las propias mediciones, llegando a las señales en bruto, segundo a segundo, que el anillo había subido. Cuando un cliente decía que una lectura parecía incorrecta, aquí es donde alguien iba a averiguar por qué.
De dónde vienen los datos
La app del anillo guarda sus datos en DynamoDB y S3, algo que encaja con una app que lee los datos recientes de un usuario, pero no con un dashboard que compara a todos los usuarios y todos los días. Así que pusimos en medio un data pool en PostgreSQL, alimentado de forma continua por Lambdas, y dimos a cada widget su propio endpoint pequeño detrás de API Gateway.
Para el front-end, esto significaba que cada gráfico podía hacer una pregunta concreta y recibir los datos ya preparados para él.
Un wallboard que la gente mira de verdad
Una pantalla que nadie toca tiene que cambiar sola, o la gente deja de mirarla. El dashboard de negocio está construido alrededor de un movimiento que sigue siendo legible:
- Un ticker que recorre las cifras de este mes frente a las del anterior, cada una con su flecha hacia arriba o hacia abajo.
- Un gráfico central que rota cada 12 segundos entre ventas, actividad, usuarios, mediciones puntuales e incidencias.
- Tarjetas inferiores que se voltean entre quiénes son los usuarios y cuándo sincronizan sus anillos.
- Un único selector de periodo para semana, mes, año o un rango de fechas, y un botón de pausa, porque un gráfico que se mueve mientras alguien lo señala resulta frustrante.
El gráfico central muestra cinco conjuntos de datos bastante distintos. En lugar de montar cada uno a mano, describimos cada serie una sola vez: sus colores en modo oscuro y claro, su degradado, si se dibuja como barras o como área suavizada y si lleva línea de media. El gráfico se genera a partir de esas descripciones, así que añadir un tipo de dashboard nuevo pasó a ser cuestión de describirlo.
Por qué elegimos ECharts
Los datos de salud le piden mucho a una librería de gráficos: varias métricas con unidades distintas en un mismo gráfico, un día completo de lecturas por segundo, zoom, colores que dependen del valor y clics para profundizar. Elegimos Apache ECharts porque resuelve todo eso de forma nativa y deja el aspecto completamente en nuestras manos.
- Un gráfico es un único objeto de configuración. Ejes, series y tooltips son datos, y eso es lo que nos permitió generar los gráficos a partir de descripciones de series y reconstruirlos para el modo oscuro o para otro tamaño de pantalla.
- La personalización llega muy lejos. Degradados, sombras, barras redondeadas, etiquetas con texto enriquecido y tooltips totalmente propios son opciones, así que los gráficos siguen el diseño de la marca sin trucos.
- Lo difícil ya viene incluido. Varios ejes Y, zoom, líneas de media, color según el valor y un modo para grandes volúmenes de decenas de miles de puntos.
- Responde al usuario. Los eventos de clic y de zoom hicieron sencillos tanto el paso de un mes a un día como el zoom sincronizado.
Para unas pocas barras y donuts basta con una librería más ligera. Cuando los datos de salud o de sensores son el centro del producto, ECharts nos ahorró construir nuestra propia capa de gráficos.
Un día completo, segundo a segundo
La vista de soporte se abre sobre una persona, con pestañas de métricas de salud, señales en bruto, sueño y mediciones puntuales.
En métricas de salud, el usuario elige cualquier combinación de métricas y cada una recibe su propio eje, alternando izquierda y derecha para que nunca se solapen. Un mes se ve como barras diarias; al hacer clic en un día se entra en él, como medias por hora o como cada lectura individual.
Esa última vista es donde el volumen importa: un día tiene 86.400 segundos. Nuestra primera versión rellenaba cada segundo para cada métrica, hubiera datos o no. La segunda envía solo las lecturas que existen y las dibuja como una nube de puntos ligera sobre el día completo, de modo que un hueco en los datos se ve como un hueco en el gráfico, que es justo lo que soporte necesita ver.
Las señales en bruto apilan un gráfico por señal y hacen zoom a la vez: al acotar la ventana en uno, todos le siguen, así que una bajada de la temperatura de la piel puede compararse con la batería en el mismo segundo. El sueño se dibuja como un hipnograma coloreado por fases, y las mediciones puntuales marcan las lecturas poco fiables con un anillo hueco, para que soporte distinga un mal contacto de un valor bajo real.
Que se vea tan bien como el producto
El cliente fabrica un producto que la gente lleva puesto todos los días, y quería que su herramienta interna pareciera de la misma marca. La mayor parte del acabado salió de unas pocas decisiones aplicadas en todas partes:
- Primero, un kit de diseño. Botones, selectores y checkboxes en las cuatro familias de color de la marca, construidos antes que cualquier pantalla.
- Una sola regla de escalado. Los diseños estaban hechos a 1440 píxeles de ancho, y todos los tamaños, en las hojas de estilo y dentro de los gráficos, escalan desde esa base, así que el texto de los gráficos y el de la página mantienen su proporción en cualquier pantalla.
- Colores con significado. El oxígeno en sangre siempre es azul, la frecuencia cardíaca verde y la temperatura de la piel magenta, así que un gráfico con varios ejes se lee sin mirar la leyenda.
- Profundidad, con moderación. Barras con degradado, rellenos de área suaves, un halo al pasar el ratón y nombres de mes muy tenues detrás de las series largas.
- Modo oscuro por defecto, con una paleta oscura propia para cada gráfico en lugar de invertir los colores sin más.
Lo que hizo que el portal funcionara fue tratar los datos y los gráficos como un único problema de diseño: un data pool pensado para lo que los dashboards necesitaban preguntar, y un front-end que oculta las partes incómodas (volúmenes por segundo, procesos lentos, zonas horarias) a quien lo mira. El acabado visual se apoya sobre esa base, y es la parte que la gente recuerda.