Navegación del área autenticada de la app: panel del padre y futuras superficies de juego de niño/adulto

Hallazgos

1. La estructura de pestañas de Google Family Link. Tres pestañas fijas: Resumen (uso de hoy, app más usada), Controles (tiempo de pantalla / límites por app), Ubicación — más un centro de notificaciones compartido. Los hogares con varios menores tienen cambio rápido de perfil desde la misma envoltura [1]. Arquitectónicamente es el producto real más cercano a “Tu casa”: una cuenta de adulto gestionando menores, no un sitio de marketing.

2. Pestañas vs. lista de una sola pantalla, y dónde está la línea. Las pestañas inferiores sirven para 3-5 destinos primarios que se visitan con frecuencia [2]. En pantallas de configuración específicamente: las pestañas funcionan cuando los destinos son igual de importantes y no subordinados entre sí; cuando un destino es claramente primario y el resto secundario, o cuando hay más categorías variadas que eso, una sola lista desplazable sirve mejor [3][4]. La navegación de barra lateral es la decisión correcta para productos con 15-40 secciones (paneles de administración, dashboards SaaS) — no aplica a la escala de esta pantalla (2-5 secciones) [10].

3. Hallazgos de navegación de mc-20 (KINDER), reformulados para esta tarea. Máximo 2 toques desde abrir la app hasta “estar respondiendo un reto”. Toque 1: elegir avatar. Toque 2: tocar la mascota/Jugar. Antipatrón explícito: “deep or hidden navigation (hamburger menus, multi-level settings) inside the child-facing surface” [5]. Aplica a KINDER por diseño; el código hoy reutiliza este mismo patrón de cero chrome para TODAS las bandas de niño vía kids/jugar.astro (documentado explícitamente como una simplificación: “en esta rejilla conviven las tres bandas de niño… manda el piso más alto de los tres”).

4. Hallazgos de navegación de mc-21 (PRIMARIA). Cambio de perfil rápido y sin teclear; ninguna asunción de un login personal persistido (tablets familiares compartidas, Chromebooks escolares) [6]. Un elemento nuevo frente a KINDER: una franja ligera de contexto dentro de la sesión (indicador de progreso/racha) — la primera banda donde se recomienda algo de “dónde estoy en esta sesión”, pero todavía no un menú [7].

5. Hallazgos de navegación de mc-22 (SECUNDARIA/adolescentes). La única idea de chrome directamente transferible entre los cuatro documentos de banda: “Tablet: two-pane (problem + scratch/graph). Desktop: persistent skill-tree sidebar that phone omits — the ‘not a kids app’ signal on desktop leans toward Desmos/Khan-Academy-style utility density.” [8] Planteado explícitamente como densidad por superficie dentro de la pantalla de práctica, no como navegación de app a nivel de cuenta. El modo oscuro por defecto de esta banda ya está implementado en bandas.css.

6. Hallazgos de navegación de mc-23 (adulto/experto). “Expose explicit learner control over path: visible skip/reorder/jump-to-topic… honoring the self-concept assumption that adults disengage when the system controls sequencing.” [9] También dentro de la pantalla de práctica — densidad multipanel (problema, área de borrador, historial de intentos), no un menú de configuración/cuenta.

7. Lo que ninguno de los cuatro documentos de banda aborda. Un menú de navegación persistente, de primer nivel, orientado a la cuenta, para el área autenticada. KINDER/PRIMARIA quieren cero chrome por diseño. Los hallazgos de SECUNDARIA/adulto tratan de densidad de contenido dentro de la práctica. Esto confirma que el hueco de navegación del área privada que este documento aborda no tenía ninguna cobertura de investigación previa — la misma conclusión a la que llegó mc-49 para el sitio público antes de D-064.

8. El hueco del modelo de datos. migrations/0001_identity.sql, comentario sobre la ausencia deliberada de una columna role: “Sin columna role… una persona puede ser las tres cosas a la vez: el propio dueño es papá y aprendiz adulto (por-que-existe.md). Un rol excluyente obligaría a mentir.” Las capacidades se derivan: padre ⇐ tiene filas en child_profiles; maestro ⇐ tiene una fila en group_owner_identity (F9, sin construir); aprendiz ⇐ users.is_learner = 1, la única bandera explícita, fijada en el registro desde la puerta registro-aprendo pero nunca leída downstream antes de esta pasada.

Implicaciones de diseño

1. El área autenticada del adulto tiene su propio layout, no Base.astro. El mismo principio que app/kids/** ya estableció para las superficies de niño, extendido al único hueco que quedaba (D-065).
2. Franja fija de pestañas arriba, no la maquinaria de cuatro contextos de D-064. Esta pantalla tiene 2-5 destinos, no “6 secciones + overflow compitiendo con un nav de marketing” — el problema que resuelve la complejidad de D-064 aquí no existe. Una fila de pestañas sticky simple, presente sin importar el display-mode (no hay ninguna navegación pestaña-de-navegador-vs-instalada con la que evitar apilarse), coincide tanto con el precedente de Family Link como con el instinto del propio producto de “no construir maquinaria que un problema no necesita”.
3. Las pestañas se derivan de lo que la cuenta realmente tiene, no de por qué puerta se registró. esFamilia = tiene ≥1 perfil de niño. esSolo = users.is_learner = 1. No son mutuamente excluyentes. Tope de 5 (HIG/Material 3, la propia cita de mc-49, reaplicada aquí).
4. “Cuenta” (passkey/contraseña/cerrar sesión) está siempre presente y siempre es real — es el único destino que nunca depende del tipo de cuenta, y garantiza que el panel nunca sea un callejón sin salida ni para una cuenta sin hijos ni is_learner (ej. solo-maestro, F9 sin construir).
5. La pestaña de aterrizaje es la primera pestaña REAL (no “próximamente”), no simplemente la primera en orden de despliegue — un aprendiz solo no debería abrir la app en un placeholder de “próximamente” cuando “Cuenta” tiene contenido real y funcionando.
6. La banda RUM es SERIO, no PUBLICO. D-037 permite medir las superficies de adulto; PUBLICO mezcla tráfico de marketing con uso autenticado del producto en el mismo saco de métricas.
7. Para las futuras bandas de niño (PRIMARIA, SECUNDARIA): cero chrome a nivel de cuenta, siempre — este es el lineamiento que el dueño pidió fijar ahora en vez de aplazar. El patrón de cero navegación con la rejilla de caras como entrada que kids/** ya implementa para KINDER sigue siendo el patrón de todas las bandas de niño. Lo que cambia por banda es la densidad de contenido dentro de la pantalla de juego, nunca la navegación a nivel de app: PRIMARIA añade una franja ligera de progreso dentro de la sesión (no un menú); la pantalla de práctica de escritorio de SECUNDARIA puede llevar un riel lateral persistente de árbol de habilidades, el teléfono sigue anclando el teclado sin chrome añadido; ninguna de las tres tiene jamás menú hamburguesa, barra inferior de pestañas ni ninguna estructura que exija más de 2 toques desde abrir hasta “estar respondiendo un reto”. Un niño nunca llega a layouts/Privada.astro — ese layout es solo para adultos por construcción (D-065).
8. Para la futura superficie de autoestudio adulto/pro (F5b/F10, sin construir): cuando se construya, vive como una pestaña “Practicar” real dentro de esta misma envoltura Privada.astro (no un layout nuevo) — la navegación visible de salto/saltar-de-tema de mc-23 ocurre dentro de esa pantalla, igual que dentro de cualquier pantalla de práctica, no como un segundo sistema de navegación a nivel de cuenta.

Preguntas abiertas para el dueño del proyecto

Ya resueltas en esta sesión, registradas aquí para trazabilidad:

1. Cuentas solo vs. familia, y cómo debe diferir el menú → resuelto: se deriva de los datos reales (is_learner, conteo de hijos), no de la puerta de registro; las pestañas son la unión de lo que aplica.
2. Si anticipar ya las pestañas de F8 → resuelto: sí, como pestañas visibles de “Próximamente”, en vez de reconstruir la navegación dos veces.
3. Si escribir el lineamiento de bandas futuras ahora o aplazarlo → resuelto: ahora (implicación de diseño #7 de arriba).

Siguen abiertas, para quien construya F5b/F9/F10:

1. Cuando la pestaña “Practicar” del adulto pase de placeholder a real, ¿reutiliza el modelado de entidades estilo child_profiles, o una tabla separada indexada directamente por users.id? (Fuera del alcance de la navegación; es una pregunta de contenido/datos para F5b.)
2. Cuando F9 (maestro/salón) se construya, ¿el maestro recibe una 6ª pestaña aquí, o un área /app/maestro/ completamente separada? El tope de 5 pestañas de este documento asume padre+aprendiz; una pestaña de maestro necesitaría su propia decisión de alcance en ese momento.