Parent & Athlete Landing Pages
What & Why
Parents are the paying customers — they register athletes, pay fees, and need a single, calm starting surface that guides them to the value of the academy. Today, when a parent logs in they land on the generic (LandingPage) or , which is shared with every other persona and surfaces everything at once. We will introduce a dedicated, opinionated post-login surface for the
Parent persona, plus a tightly linked
Athlete surface that is fully visible to the connected parents (athletes are under 18, so parents must see everything the athlete sees).
Both surfaces will share the same navigation spine but be visually distinguished by a thin top banner / background-tint cue so a parent always knows which "room" they are in. Event information — past, present, and future — is the headline pillar; evaluations, communications, payments, and athlete development sit alongside it.
Done looks like
- A parent who logs in is sent to (a new Parent Home), not the generic dashboard.
- The Parent Home shows, above the fold:
- A thin
parent-tinted top banner (e.g. warm/family color from the design tokens) labelled "Parent Home" with the parent's name and a child switcher. -
My Athletes — one row per child with name, photo, current training team(s) / status, and a "View athlete" button that opens the Athlete surface. -
Events at a glance — three clearly separated columns/cards:
Upcoming,
Today / This week, and
Recent / Past (last 30 days), each filtered to the parent's children. Each row links to the event detail and shows registration + payment state. -
Action needed strip — outstanding payments, unsigned waivers, pending registrations, training-team responses due, unread conversations.
- A "pillar" navigation row below the hero, in this fixed order, each opening a dedicated section/page:
1.
Events (past / present / future, with registration history) 2.
Payments & Registrations 3.
Communications (announcements + inbox conversations) 4.
Athlete Development (evaluations, feedback, training-team status, reports) 5.
Connections (coaches, co-guardians, family directory) 6.
Settings (notifications, profile, family management)
- Visiting opens the Athlete Home for one child, scoped to that athlete. It carries an athlete-tinted banner (different color from the parent banner — e.g. cool/court color) labelled "Athlete:
". The page shows:
- Upcoming schedule (next 14 days), recent attendance, latest evaluation/feedback, current training team(s), recent messages mentioning the athlete, and a "switch to another athlete" pill row. - A persistent
"Viewing as parent" chip in the banner when accessed by a parent, with a "back to Parent Home" link.
- The same Athlete Home is reachable by the athlete themselves at (their own) with identical content but the athlete-tinted banner only (no "Viewing as parent" chip). Athletes cannot see other athletes' homes; parents can only see their own connected children's homes (enforced server-side).
- Post-login routing: if the logged-in user has the PARENT academy role and no higher-precedence superadmin/coordinator persona is explicitly selected, the post-login redirect lands on . If the user is an athlete-only login, they land on . SuperAdmins / coordinators continue to land where they do today.
- The Parent and Athlete surfaces are clearly two different rooms at a glance — same nav spine, same shadcn components, but distinguishable banner color/tint plus surface label. Both meet AA contrast in light and dark mode.
- Every interactive and meaningful element on both pages has a stable following the fullstack-js convention.
- A short e2e spec (or two) confirms: parent login → lands on ; parent clicks an athlete → lands on ; server rejects a parent trying to view an unconnected athlete's home.
Out of scope
- Building any new event, evaluation, payment, or conversation back-end logic — these surfaces compose existing APIs (, , , , , , , , , , etc.) — no schema changes.
- Removing or deleting the current or page. They stay as-is for other personas and as a deep-link target; the new Parent Home becomes the default entry for parents and links into the existing pages where useful. A follow-up task can decide whether to retire once the new surface stabilizes.
- Coach / Referee / Coordinator / SuperAdmin landing redesigns.
- Mobile-app (Expo) versions — web only for this task.
- New notification or email flows.
- Any change to RBAC rules; we reuse the existing parent-can-see-own-children authorization that powers and .
Steps
1.
Role-aware post-login routing — Update the existing post-login redirect so a logged-in PARENT lands on and an athlete-only login lands on , preserving any explicit override and the existing SuperAdmin/Coordinator behaviour. Add checks so a user who is both parent and coach keeps their current selectable persona, but defaults to parent on first login of the day. 2.
Surface chrome (banner + tint tokens) — Add two named surface tints to the existing Tailwind/theme tokens (one "parent" and one "athlete"), define them for light and dark mode at AA contrast, and build a small component used by both new pages. The banner is a thin (~6–8px) top stripe plus a subtle full-page background tint so the room is unmistakable without being loud. 3.
Parent Home page () — New page component that composes existing TanStack queries (, , , , , , family event summaries) to render the hero (My Athletes + child switcher), the three Events columns (past / present / future scoped to the family), the Action Needed strip, and the six-pillar nav row. Reuse existing cards from where they already exist (e.g. , payment/registration cards) rather than recreating them — extract them into shared components if needed. 4.
Athlete Home page ( and ) — Single page component that takes a from the route and composes existing queries (, , , , child schedule from or per-athlete endpoint) into: schedule (next 14 days), attendance summary, latest evaluation / feedback, training team status, recent communications mentioning the athlete, and a child-switcher pill row when the viewer is a parent. Render the athlete-tinted and a "Viewing as parent — back to Parent Home" chip when the viewer is a parent and not the athlete themselves. 5.
Pillar sub-routes & wiring — Wire the six pillar buttons on Parent Home to existing routes (Events → filtered to family; Payments → existing payment portal; Communications → conversations inbox; Athlete Development → development report; Connections → community directory + co-guardians; Settings → notification settings / family management). Where an existing page does not have a family-scoped view, add a thin "filter by my family" toggle rather than building new pages. 6.
Route registration & guards — Register , , and in , each wrapped in a that requires parent (for ) or athlete-or-parent-of (for ). Server-side: ensure the existing parent-can-see-child authorization already enforced by and is the gate (no new auth code unless a gap is found — if a gap is found, fix it in this task and note it). 7.
SEO + accessibility polish — Per-page titles ("Parent Home — Elite Volleyball" and "Athlete:
— Elite Volleyball"), meta descriptions, focus order through hero → events → pillars, and dark-mode parity for both tints. Verify with keyboard nav and a quick contrast check. 8.
Tests — One e2e spec for the parent path (login → → click athlete → → see schedule + latest evaluation), one spec for athlete self-login landing on their own athlete home, and a backend test confirming rejects a parent requesting an unconnected athlete. Reuse the existing playwright + vitest patterns in and . 9.
Update — Add the two new routes and the parent/athlete surface convention (banner tints, default post-login destinations) under "Where things live" + "Architecture decisions" so the convention is discoverable.
Architectural constraints
- Compose, do not duplicate — every data point already exists in an API; this task is an IA + chrome reshuffle, not new domain logic.
- Parent visibility is total — anything an athlete can see in their own Athlete Home, the connected parent must also see in . The two routes render the same component with a prop that only changes the banner chip, not the data.
- Athlete privacy is bounded — athletes can never see another athlete's home; parents can only see their own connected children. Enforce server-side, not just in the UI.
- Surface cue is visual, not modal — never block the parent inside a "parent mode" they must dismiss; the tint and banner are passive cues.
- Terminology — Athletes (not Players), Parents/Guardians, Days (not Sessions), per the existing standards in .
- Timezone — All dates parsed as America/Regina local time, per existing convention.
Relevant files
- - - - - - - - - - -
