Caso de estudio 03 / 21CI/CD DevOps
Manual de usuario bilingüe que se rehace en cada build de cliente
Explica los controles de la app en 21 páginas, en dos idiomas, con puntos numerados en 600 capturas, y se rehace en cada build de cliente.
Stack
- Next.js
- React
- MUI
- TypeScript
- Node.js
- Headless Chrome
- next-intl
- WebP
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Un manual de usuario para la app web de la plataforma de monitoreo, en español y en inglés y para cada rol: 21 páginas, cada pantalla con su captura, un punto numerado sobre cada control con su línea de texto, y un buscador. Lo construí para que se haga solo: un programa recorre la app con datos de ejemplo anónimos, toma las capturas y coloca los puntos, y el build de cada cliente le agrega el nombre del cliente y entrega el manual dentro de la app, detrás de un «?» en cada pantalla, y aparte en archivos HTML y PDF.
5 conexiones· elige un componente para ver su recorrido
- Datos de ejemplo neutros a Build de producción: contestan cada llamada
- Build de producción a Generador de capturas: cada página, estado y tema
- Generador de capturas a Build del cliente: capturas y sus puntos
- Textos en dos idiomas a Build del cliente: revisados: no falta ninguno
- Build del cliente a Usuario de la app: «?» en cada pantalla y PDF
02Resultados
- R01Cuanto más alto, mejor
Controles y opciones fuera del mapa 3D, en los dos idiomas
Antes 0%, después 100%, desde 0. Cuanto más alto, mejor.AntesDespués - R02Cuanto más alto, mejor
Capturas con puntos, en dos idiomas y dos temas
Antes 0, después 600, desde 0. Cuanto más alto, mejor.AntesDespués - R03Cuanto más bajo, mejor
Controles cortados de la barra, en pantallas y anchos
Antes 21, después 0, a cero. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Cobertura: un PDF de 16 páginas de tablas sin capturas → 21 páginas, cada control y opción fuera del mapa 3D incrustado explicados en español y en inglés, sobre 600 capturas con puntos numerados
- Marcas: 64 elementos que se pueden pulsar sin una marca estable → 0, así cada punto numerado queda unido a su control
- Mantenimiento: un PDF fijo → se regenera en el build para las pantallas que cambiaron y suma 49 s cuando nada cambió
- Acceso: un menú general de ayuda → un «?» en cada pantalla que lleva a la sección de esa pantalla, un visor que busca en 1.3 ms y, por idioma, un HTML aparte y un PDF de unos 7 MB
Leer más
- Controles automáticos: ninguno → una revisión en cada pull request que falla si a un control le falta texto en algún idioma o si un nombre real llega al manual; 0 puntos tapados y 0 elementos de desarrollo en las capturas
- Barra superior: 21 controles cortados y 46 pares superpuestos en 39 combinaciones de pantalla e idioma a 9 anchos → 0; ahora cede espacio en un orden fijo, primero el hueco y al final los nombres de las pestañas
El desafío
El manual de la app web era un PDF de 16 páginas de tablas, sin capturas y con ocho meses de antigüedad, y la ayuda era un solo menú general: solo una pantalla tenía su propio botón de ayuda. Tampoco había cómo apuntar con seguridad a un control: 64 elementos que se pueden pulsar no tenían una marca estable, y muchos controles solo existen después de un clic, dentro de menús, listas y diálogos.
Leer más
Incluso los datos de ejemplo que debían ser anónimos aún traían nombres reales de sistemas.
Escribir el manual reveló además un defecto de la propia app: en ventanas de ancho mediano, la barra superior cortaba controles sin avisar. A unos 1064 px, un botón de administración quedaba cortado y el de salir caía fuera de la pantalla, porque el lado derecho de la barra siempre pedía 507 px y una caja estirada llenaba el centro.
Qué aprendí
Primero hay que medir el instrumento de medida. Descarté dos corridas del inventario (una abría mal las listas y otra contaba controles de la página siguiente) antes de que 64 elementos sin marca fueran una base confiable, y el control de la barra informó 45 cortes falsos hasta que esperó dos cuadros a que Chrome pintara. Escribir una frase para cada control también es una pasada de pruebas: reveló 11 defectos de la app, 7 de ellos textos que aparecen en un solo idioma.
Leer más
Las buenas intenciones no son un control: los datos que debían ser anónimos aún traían nombres reales, así que ahora una revisión del pull request falla ante cualquiera. El primer PDF pesaba 143.7 MB porque las imágenes entraban sin comprimir; imprimirlo desde copias comprimidas lo dejó en 7 MB.
Stack
- Next.js
- React
- MUI
- TypeScript
- Node.js
- Headless Chrome
- next-intl
- WebP
Habilidades
- Automatización de documentación
- Redacción técnica bilingüe
- Automatización de pruebas de interfaz
- Diseño de interfaces adaptables
- Ingeniería de entregas
