Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0addcfb382
Kairo-Jinkendo/docs/reference/design-principles/shinkan/NAVIGATION_IA_DESIGN_PRINCIPLES.md
Lars 0e2b938fbd
Some checks failed
Test Suite / lint-backend (push) Waiting to run
Details
Test Suite / build-frontend (push) Waiting to run
Details
Test Suite / k6 /health Baseline (push) Waiting to run
Details
Test Suite / playwright-tests (push) Waiting to run
Details
Deploy Development / deploy (push) Failing after 0s
Details
Test Suite / pytest-backend (push) Has been cancelled
Details
Sprint-0-Grundlagen: Spec-Handover, Designprinzipien-Referenz, Medien optional. 
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-04 19:03:57 +02:00

3.9 KiB
Raw Blame History

Navigation / IA – Designprinzipien (Extraktion)

Status: Analyse / Arbeitspapier
Stand: 2026-07-04
Geltungsbereich: Modul „Navigation & Information Architecture“

Serie: Designprinzipien für Produktfamilie · Shinkan Dokument 12 von 15
Mitai-Vergleich: NAVIGATION_IA_DESIGN_PRINCIPLES.md (#8)

Kernkomponenten:

Bereich Pfade
Hauptnav frontend/src/config/appNav.js
Admin-Nav frontend/src/components/AdminPageNav.jsx
Shells RequireAdmin, App-Layout in App.jsx
Return-Kontext .claude/docs/technical/NAV_RETURN_CONTEXT_SPEC.md
Styles frontend/src/app.css (.admin-top-nav, Bottom-Nav)

Modul

Navigation / IA

Single Source of Truth für Hauptnavigation (Mobile Bottom + Desktop Sidebar), separater Admin-Hub, Onboarding-Nav ohne Vereinsfeatures, rollen- und kontextabhängige Einblendung (Posteingang, Admin).

Designprinzipien

1. appNav.js als SSoT für Hauptnavigation
Prinzip getMainNavItems(isAdmin, opts) liefert Route, Label, Icon — eine Liste für Mobile und Desktop.
Begründung Gleiches Familien-Muster wie Mitai appNav; keine divergierenden Nav-Arrays.
Quelle appNav.js
Tragfähigkeit hoch
Einschränkung Tiefe Unterrouten (Übung bearbeiten) nicht in Top-Nav — Shell/Back.

2. Admin als separater Hub
Prinzip /admin/* mit horizontaler AdminPageNav — Plattform-Werkzeuge gebündelt.
Begründung Trainer-Nav bleibt schlank; Admin-IA skaliert unabhängig.
Quelle AdminPageNav.jsx
Tragfähigkeit hoch
Einschränkung Admin-Nav hardcoded Array — kein adminNav.js SSoT wie Mitai ideal.

3. Onboarding-Nav reduziert
Prinzip getOnboardingNavItems() — nur Verein + Einstellungen ohne Übungen/Planung.
Begründung Nutzer ohne Vereinsmitgliedschaft nicht in leere Bereiche führen.
Quelle appNav.js
Tragfähigkeit hoch
Einschränkung —

4. Kontextabhängige Items (Posteingang)
Prinzip showInbox Flag steuert Posteingang-Eintrag — Berechtigung aus Entitlements/Rolle.
Begründung Kein toter Nav-Link für Trainer ohne Inbox-Recht.
Quelle baseItems({ showInbox })
Tragfähigkeit hoch
Einschränkung Logik zur showInbox-Setzung in App.jsx pflegen.

5. Responsive: Bottom-Nav Mobile, Sidebar Desktop
Prinzip Gleiche Items, unterschiedliche Präsentation; CSS-Variablen für Abstände.
Begründung PWA-typisches Muster; 80px Bottom-Padding für Nav.
Quelle app.css; Design-System in CLAUDE.md
Tragfähigkeit hoch
Einschränkung Breakpoint-Konsistenz mit Mitai (1024px) prüfen beim Familien-Review.

6. Return-Kontext für tiefe Bearbeitung
Prinzip Spez NAV_RETURN_CONTEXT_SPEC — zurück zur Herkunftsliste mit Filter-State.
Begründung Übungs-Editor aus Suche/Planung ohne Navigations-Verlust.
Quelle Return-Context Spec
Tragfähigkeit mittel
Einschränkung Nicht alle Flows implementiert.

Nicht übernehmen

  1. Zwei unterschiedliche Nav-Arrays für Mobile vs. Desktop.
  2. Admin-Routen in Haupt-Bottom-Nav mischen (außer ein Admin-Einstieg).
  3. Hardcodierte Nav in jeder Page — zentral in appNav.js.
  4. Fehlender Onboarding-Gate — volle Nav ohne Verein verwirrt.

Verwandte Dokumentation