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

Findings

1. La estructura de pestañas de Google Family Link. Tres pestañas fijas: Highlights (uso de hoy, app más usada), Controls (tiempo de pantalla / límites de apps), Location — más un centro de notificaciones compartido. Los hogares con varios menores tienen cambio rápido de perfil desde el mismo shell [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 un solo scroll, y dónde está la línea. Las pestañas inferiores sirven para 3-5 destinos primarios accedidos con frecuencia [2]. Las pantallas de ajustes, específicamente: las pestañas funcionan cuando los destinos son igual de importantes y no están subordinados entre sí; cuando un destino es claramente primario y el resto secundario, o cuando hay categorías más variadas que eso, una sola lista desplazable sirve mejor [3][4]. La navegación con barra lateral es la elecció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 el propósito de 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 actual 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; sin asumir un inicio de sesión personal persistente (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 “dónde estoy en esta sesión” se recomienda en absoluto, pero sigue sin ser un menú [7].

5. Hallazgos de navegación de mc-22 (SECUNDARIA/adolescentes). La única idea de chrome directamente transferible de 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] Enmarcado 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 para 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 ajustes/cuenta.

7. Lo que ninguno de los cuatro documentos de banda aborda. Un menú de navegación persistente, de nivel superior, 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; profesor ⇐ 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.

Design implications

1. El área autenticada del adulto recibe 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 no existe aquí. Una simple fila de pestañas sticky, presente con independencia del display-mode (no hay ningún nav de pestaña-de-navegador-vs-instalada compitiendo con el que 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 siquiera para una cuenta sin hijos ni is_learner activado (p. ej. solo profesor, F9 sin construir).
5. La pestaña de aterrizaje es la primera pestaña REAL (no “próximamente”), no simplemente la primera en el orden de presentación — 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 de 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 cubo 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 diferir. El patrón de cero navegación con rejilla-de-avatares-como-entrada que kids/** ya implementa para KINDER sigue siendo el patrón de cada banda 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, y el teléfono sigue anclando el teclado numérico sin chrome añadido; ninguna de las tres recibe jamás un menú hamburguesa, una barra de pestañas inferior, ni estructura alguna 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 de adulto por construcción (D-065).
8. Para la futura superficie de autoestudio adulto/pro (F5b/F10, sin construir): cuando se entregue, vive como una pestaña “Practicar” real en este mismo shell Privada.astro (no un layout nuevo) — la navegación visible de saltar/saltar-a-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.

Open questions for the project owner

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

1. Cuentas solo vs. familiares, y cómo debería diferir el menú → resuelta: se derivan de datos reales (is_learner, número 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 → resuelta: 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 diferirlo → resuelta: 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 con clave directa sobre users.id? (Fuera del alcance de la navegación; es una pregunta de contenido/datos para F5b.)
2. Cuando F9 (profesor/aula) se entregue, ¿el profesor 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 profesor necesitaría su propia decisión de alcance en ese momento.