UX — Overhaul integral de la experiencia Attendee y Staff

[nicoechaniz]

Problema

La interfaz actual de la sala parece el resultado de apilar componentes y textos explicativos a medida que aparecieron necesidades, en lugar de una experiencia diseñada deliberadamente de punta a punta. Esto genera clutter, diluye las acciones críticas y aumenta la carga cognitiva tanto para attendees como para Staff.

Ejemplos observados en producción:

• El bloque persistente sobre la mano levantada explica en detalle que el nombre aparece sobre la imagen y se retira al bajar la mano o salir.
• El bloque “Cómo funciona la escucha” ocupa una porción importante de la sala con instrucciones permanentes sobre volumen, balance, cámara y micrófono.
• Advertencias y controles operativos importantes compiten visualmente con copy educativo de baja prioridad.

El problema no es una frase aislada: hace falta revisar la arquitectura de información, la jerarquía, la densidad y los recorridos completos.

Objetivo

Rediseñar de manera intencional, coherente y usable las superficies de sala para:

1. Attendee.
2. Facilitador/OP.
3. Operador.
4. Admin.

La experiencia debe destacar el evento, el audio, el tapiz, el chat/contribuciones y las acciones que requieren atención en ese momento. La explicación secundaria debe ser contextual, progresiva y descartable, no documentación permanente incrustada en la pantalla.

Trabajo de diseño previo

• Auditar todas las superficies y componentes visibles por rol, estado y viewport.
• Inventariar cada texto persistente, alerta, ayuda, control, badge y panel; decidir conservar, acortar, mover a ayuda contextual, mostrar una sola vez o eliminar.
• Mapear recorridos críticos: ingreso, espera, escucha, balance, mano levantada, invitación a escena, cámara/micrófono, contribuciones/chat, salida y reconexión.
• Mapear recorridos Staff: preparación, apertura, monitoreo, invitación/demotion/reconciliación, calidad de audio, operación del evento y cierre.
• Diseñar primero jerarquía y estados; recién después traducirlos a componentes.
• Explorar Google Stitch mediante MCP si está disponible y conectado, usándolo para ideación/prototipos y comparación de alternativas, no como sustituto de los contratos funcionales, accesibilidad ni pruebas reales.
• Validar las propuestas contra el lenguaje visual y la identidad canónica de Harmonic Beacon.

Criterios de aceptación

• Existe un diseño deliberado y documentado para attendee y cada rol Staff en desktop y móvil.
• La vista principal no contiene largos bloques de instrucciones permanentes.
• La ayuda secundaria usa progressive disclosure: tooltip, ayuda contextual, onboarding descartable o panel bajo demanda según corresponda.
• Las acciones y advertencias críticas son inmediatamente visibles y no compiten con copy explicativo.
• No hay controles duplicados ni dos representaciones incoherentes de identidad/estado.
• La jerarquía visual distingue con claridad contenido vivo, controles primarios, estado, alertas y ayuda.
• Se prueban recorridos completos con Chrome, Firefox/WebKit y tamaños móviles relevantes.
• Se revisa accesibilidad: teclado, foco, lectores de pantalla, contraste, targets táctiles y reducción de movimiento.
• Se mantiene intacto el contrato funcional de audio, mezcla Beacon/Session, cámara, micrófono, tapiz, contribuciones, roles, permisos y reconexión salvo cambios explícitamente aprobados.
• Antes/después queda documentado con evidencia visual y una lista de copy eliminado, condensado o movido.

Fuera de alcance

• Reescribir el motor de audio o streaming dentro de esta card.
• Cambiar roles/permisos por razones puramente visuales.
• Introducir textos nuevos para compensar una jerarquía confusa.

[nicoechaniz]

Stitch/MCP feasibility check (2026-08-22)

Yes, this workflow is technically available, but Stitch is not connected to the current Codex session yet.

Current upstream material:

• Google Labs publishes a Codex plugin marketplace with stitch-design, stitch-build and stitch-utilities: https://github.com/google-labs-code/stitch-skills
• That repository explicitly requires a configured Stitch MCP endpoint and links to the setup flow: https://stitch.withgoogle.com/docs/mcp/setup/
• The Gemini CLI Stitch extension documents the current Stitch MCP capabilities and authentication choices (Stitch API key or Google Cloud ADC): https://github.com/gemini-cli-extensions/stitch

Recommended setup when this card starts:

1. Connect the Stitch MCP endpoint using a dedicated project/key or scoped ADC; do not paste credentials into the repository or issue.
2. Add the Google Labs Stitch marketplace to Codex.
3. Install only stitch-design and stitch-utilities initially; add stitch-build only if we deliberately choose to translate an approved design into components.
4. Import/snapshot the real attendee and Staff surfaces and the Harmonic Beacon design system.
5. Generate and compare a small number of coherent end-to-end alternatives.
6. Treat Stitch output as prototypes: review accessibility, role/state coverage, responsive behavior and every existing functional contract before implementation.

This avoids using Stitch as a component generator that merely restyles the current accumulation.

[nicoechaniz]

Evidencia adicional observada en la prueba real

Scrollbars anidadas

• La página y el panel de la sala tienen scroll independiente.
• El scroll general no alcanza a revelar los controles de audio/video; el usuario debe descubrir que existe otro scroll dentro del panel.
• Esto rompe la orientación espacial, dificulta llegar a acciones críticas y es especialmente malo con trackpad/touch.

Orden móvil incorrecto

• En teléfonos, el panel de contribuciones/chat queda intercalado entre el video/tapiz y los controles de micrófono, cámara y demás acciones de la llamada.
• Como consecuencia, los controles de medios quedan fuera de contexto y las personas no los encuentran cuando los necesitan.

Criterios de aceptación añadidos

• Definir un único dueño de scroll por superficie principal. Evitar scroll containers anidados salvo un caso excepcional, explícito y probado.
• El scroll normal de la página debe permitir alcanzar todos los controles; ningún control crítico puede depender de descubrir un scroll interno.
• En móvil, los controles esenciales de llamada (micrófono, cámara, cambio de cámara cuando aplique, audio-only y salida) deben permanecer agrupados, visibles/encontrables y próximos al contexto audiovisual.
• Chat/contribuciones no debe interrumpir la continuidad entre contenido audiovisual y controles esenciales.
• Diseñar y probar por ancho y altura reales de viewport, incluido navegador móvil con barras dinámicas y safe areas.
• Validar teclado, touch, rueda/trackpad, foco y restauración de posición al abrir/cerrar paneles.
• Incorporar pruebas que fallen ante overflow inesperado y más de un scrollbar vertical relevante en la experiencia principal.

[nicoechaniz]

Regla explícita para el overhaul (detectada durante la prueba): no mostrar en la UI garantías internas ni disclaimers sobre lo que el código no hace. Texto retirado: “This monitor only warns: it never mutes, stops, or changes the transmission.” / “Este monitor sólo advierte: nunca silencia, corta ni modifica la transmisión.”

Criterio de aceptación: cada texto persistente de la interfaz debe cumplir al menos una función directa para la persona usuaria: describir un estado relevante, ayudar a decidir o indicar una acción concreta. Invariantes de implementación y garantías negativas pertenecen a tests, documentación técnica o runbooks, no a la superficie operativa.

[Mar-IA-no]

Evidencia adicional — prueba técnica 2026-09-02

La prueba confirmó varios síntomas ya contemplados por este overhaul:

• Para apagar o activar micrófono y cámara hay que bajar hasta el fondo; al hacerlo, las cámaras salen de vista.
• El bloque “Cómo funciona la escucha” podría pasar a ayuda contextual o mensajes emergentes al posicionarse sobre cada control.
• Los elementos secundarios diluyen controles indispensables y vuelven la experiencia especialmente incómoda dentro del navegador.
• Surgió como pregunta de producto si una app dedicada reduciría esta fricción. No se propone migrar todavía: primero conviene comprobar cuánto resuelve una jerarquía web responsive, sticky y de progressive disclosure.

Los defectos operativos concretos se vinculan además con #126, #495, #496 y #497.