Navigation for the Authenticated App Area: Parent Dashboard and Future Child/Adult Play Surfaces

Findings

1. Google Family Link’s tab structure. Three fixed tabs: Highlights (today’s usage, most-used app), Controls (screen time / app limits), Location — plus a shared notification hub. Multi-child households get fast profile switching from the same shell [1]. This is architecturally the closest real product to “Tu casa”: an adult account managing minors, not a marketing site.

2. Tabs vs. single-scroll-list, and where the line is. Bottom tabs suit 3-5 primary destinations accessed repeatedly [2]. Settings screens specifically: tabs work when destinations are equally important and not subordinate to each other; when one destination is clearly primary and the rest secondary, or when there are more varied categories than that, a single scrollable list serves better [3][4]. Sidebar navigation is the right call for products with 15-40 sections (admin panels, SaaS dashboards) — not applicable at this screen’s scale (2-5 sections) [10].

3. mc-20 (KINDER) navigation findings, restated for this task’s purpose. Max 2 taps from app-open to “answering a challenge.” Tap 1: pick avatar. Tap 2: tap mascot/Play. Explicit anti-pattern: “deep or hidden navigation (hamburger menus, multi-level settings) inside the child-facing surface” [5]. Applies to KINDER by design; the codebase currently reuses this same zero-chrome pattern for ALL child bands via kids/jugar.astro (explicitly documented as a simplification: “en esta rejilla conviven las tres bandas de niño… manda el piso más alto de los tres”).

4. mc-21 (PRIMARIA) navigation findings. Fast, no-typing profile switching; no assumption of a persisted personal login (shared family tablets, school Chromebooks) [6]. One new element vs. KINDER: a lightweight in-session context strip (progress/streak indicator) — the first band where “where am I in this session” is recommended at all, but still not a menu [7].

5. mc-22 (SECUNDARIA/teens) navigation findings. The one directly transferable chrome idea across all four band docs: “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] Explicitly framed as per-surface density inside the practice screen, not account-level app navigation. Dark-mode-by-default for this band is already implemented in bandas.css.

6. mc-23 (adult/expert) navigation findings. “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] Also inside the practice screen — multi-panel density (problem, scratch area, attempt history), not a settings/account menu.

7. What none of the four band docs address. A persistent, top-level, account-facing navigation menu for the authenticated area. KINDER/PRIMARIA want zero chrome by design. SECUNDARIA/adult findings are about in-practice content density. This confirms the private-app navigation gap this document addresses had no prior research coverage at all — same conclusion mc-49 reached for the public site before D-064.

8. The data-model gap. migrations/0001_identity.sql, comment on the deliberate absence of a role column: “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.” Capabilities are derived: parent ⇐ has rows in child_profiles; teacher ⇐ has a row in group_owner_identity (F9, unbuilt); learner ⇐ users.is_learner = 1, the only explicit flag, set at signup from the registro-aprendo door but never read downstream before this pass.

Design implications

1. The authenticated adult area gets its own layout, not Base.astro. Same principle app/kids/** already established for child surfaces, extended to the one remaining gap (D-065).
2. Fixed top tab strip, not the four-context machinery of D-064. This screen has 2-5 destinations, not “6 sections + overflow competing with a marketing nav” — the problem D-064’s complexity solves doesn’t exist here. A simple sticky tab row, present regardless of display-mode (there’s no competing browser-tab-vs-installed nav to avoid stacking with), matches both the Family Link precedent and the product’s own “don’t build machinery a problem doesn’t need” instinct.
3. Tabs are derived from what the account actually has, not from which door it registered through. esFamilia = has ≥1 child profile. esSolo = users.is_learner = 1. Not mutually exclusive. Cap at 5 (HIG/Material 3, mc-49’s own citation, reapplied here).
4. “Cuenta” (passkey/password/sign-out) is always present and always real — it’s the one destination that never depends on account type, and guarantees the dashboard is never a dead end even for an account with neither children nor is_learner set (e.g. teacher-only, F9 unbuilt).
5. Landing tab is the first REAL (non-”coming soon”) tab, not simply the first in display order — a solo learner should not open the app to a “coming soon” placeholder when “Cuenta” has real, working content.
6. RUM band is SERIO, not PUBLICO. D-037 permits measuring adult surfaces; PUBLICO mixes marketing traffic with authenticated product usage in the same metrics bucket.
7. For future child-facing bands (PRIMARIA, SECUNDARIA): no account-level chrome, ever — this is the lineamiento the owner asked to fix now rather than defer. The zero-navigation, avatar-grid-as-entry pattern kids/** already implements for KINDER stays the pattern for every child band. What changes per band is content density inside the play screen, never app-level navigation: PRIMARIA adds a lightweight in-session progress strip (not a menu); SECUNDARIA’s desktop practice screen may carry a persistent skill-tree sidebar, phone still docks the keypad with no added chrome; none of the three ever gets a hamburger menu, a bottom tab bar, or any structure requiring more than 2 taps from open to “answering a challenge.” A child never reaches layouts/Privada.astro — that layout is adult-only by construction (D-065).
8. For the future adult/pro self-study surface (F5b/F10, unbuilt): when it ships, it lives as a real “Practicar” tab in this same Privada.astro shell (not a new layout) — mc-23’s visible skip/jump-to-topic navigation happens inside that screen, the same way it would inside any practice screen, not as a second account-level nav system.

Open questions for the project owner

Already resolved this session, recorded here for traceability:

1. Solo vs. family accounts, and how the menu should differ → resolved: derived from real data (is_learner, child count), not signup door; tabs are the union of what applies.
2. Whether to anticipate F8’s tabs now → resolved: yes, as visible “Próximamente” tabs rather than rebuilding navigation twice.
3. Whether to write the future-band guideline now or defer → resolved: now (design implication #7 above).

Still open, for whoever builds F5b/F9/F10:

1. When the adult “Practicar” tab goes from placeholder to real, does it reuse child_profiles-style entity modeling, or a separate table keyed directly on users.id? (Out of scope for navigation; a content/data question for F5b.)
2. When F9 (teacher/classroom) ships, does the teacher get a 6th tab here, or a fully separate /app/maestro/ area? This document’s 5-tab cap assumes parent+learner; a teacher tab would need its own scope decision at that point.