patrickandClaude Sonnet 5
7b62f63f64
STORAGE-KONZEPT.md und weitere Konzeptdokumente (PRODUKTARCHITEKTUR.md, SICHERHEITSKONZEPT.md, MIGRATIONSKONZEPT.md, SKALIERUNGSKONZEPT.md, SAAS-BETRIEBSMODELL.md, UI-UX-KONZEPT.md) sowie CLAUDE.md lagen bislang nur in einer lokalen, von origin/main historisch getrennten Branch-Linie vor. RET-16 (archive-kanban) braucht STORAGE-KONZEPT.md als Zieldatei auf main. Reiner Dokument-Add, keine Code-Aenderung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
7.5 KiB
NEXARCH 2.0 – UI/UX-Konzept
Stand: 2026-08-28 (Abschnitt 4/6 aktualisiert). Grundlage: Core SHL-01 (UI-Shell & Design-System, zentral), PRODUKTARCHITEKTUR.md, alle Oberflächen-Tickets über sieben Boards.
1. Grundprinzip: eine Shell, sieben Module
SHL-01 (Core) ist die alleinige Quelle für Layout-Shell, Basis-Komponenten (Tabelle, Dialog, Formularelemente, Toast) und Design-Tokens (Farbe, Abstand, Typografie). Jedes Fachmodul baut seine eigenen Oberflächen darauf auf, aber keines definiert eigene Tokens oder eigene Basis-Komponenten — das war bis zur Konsolidierung (siehe nexarch-state.json → konsolidierungen_durchgefuehrt) nicht sichergestellt, DMS hätte sonst die einzige Shell gehabt und alle anderen sechs Boards hätten sie kopiert oder wären visuell inkonsistent geblieben.
Test für "gehört das in SHL-01 oder ins Modul": Würde eine zweite, unabhängige Implementierung zum selben Ergebnis kommen müssen, damit NEXARCH wie ein Produkt aussieht (Button-Stil, Abstand, Farbpalette)? Dann Core. Ist es fachlich spezifisch für ein Modul (PDF-Viewer, Postfach-Ansicht, Genehmigungs-Ansicht)? Dann das jeweilige Board.
2. Navigationsmodell
Aus dem Master-Prompt-Ziel "modulare Oberfläche, Benutzer sehen nur Module für die sie Berechtigung haben" — technisch bereits durch Core LIC-02 (Feature-Flags je Tenant) und RBAC-01..04 (Rollen/Rechte) unterlegt:
- Globale Navigation (Teil von
SHL-01): Modul-Umschalter, sichtbar nur für aktivierte + berechtigte Module. Kein Modul zeigt sich selbst an, wenn Core es für den aktuellen Tenant/Benutzer nicht freigibt — das ist dieselbe Backend-seitige Durchsetzungspflicht aus dem Master-Prompt ("Aktivierung darf nicht nur UI-seitig erfolgen"), hier auf die Navigationsebene angewendet: die UI blendet aus, was das Backend ohnehin verweigern würde, nicht umgekehrt als alleiniger Schutzmechanismus. - Modul-interne Navigation: jedes Fachmodul definiert seine eigene zweite Ebene (DMS: Dokumente/Ordner/Papierkorb; Mail: Postfächer/Suche; Workflow: Aufgaben/Akten/Genehmigungen) — eigenständig, aber visuell aus denselben Shell-Komponenten.
- Globale Suche: im Master-Prompt gefordert, aktuell technisch NICHT als eigenes Ticket vorhanden — siehe Abschnitt 6 (offener Punkt). Die Suche existiert bisher nur je Modul (DMS
SRC-*, MailSRC-*, bewusst nicht zentralisiert, siehenexarch-state.json→bewusst_nicht_zentralisiert), aber eine modulübergreifende Ergebnisliste in EINER Suchleiste ist etwas anderes als ein gemeinsamer Suchindex und wurde bisher nicht bedacht.
3. Dashboard & Benutzer-/Tenant-Kontext
- Tenant-Kontext global sichtbar (welcher Mandant ist aktiv, bei Mehrfachzugehörigkeit umschaltbar) — gehört in
SHL-01, da jedes Modul denselben Tenant-Kontext braucht, nicht nur eines. - Ein Landing-Dashboard nach Login existiert bisher nur in Einzelteilen: Core
OPS-02(zentrale Statusseite, eher Admin-/Betriebssicht als Nutzer-Dashboard), ArchiveANA-02(Auswertungs-Dashboard, Kennzahlen-fokussiert), Mail/DMS haben kein eigenes Startseiten-Ticket. Kein Ticket bündelt bisher "was sieht ein normaler Benutzer beim ersten Login" — siehe Abschnitt 6.
4. Responsive, Theming, Sprache, Barrierefreiheit — zentral in SHL-01 verankert
Update 2026-08-28: WCAG 2.1 AA, i18n-Rahmen (mind. Deutsch/Englisch) und Theming (Hell/Dunkel) sind jetzt verbindliche, in SHL-01 verankerte Eigenschaften des Design-Systems (Akzeptanzkriterien 4-6, Prüfungen 5-6) — kein modulweiser Einzelfall mehr. Alle Frontend-Kacheln über alle 7 Boards (Core, DMS, Mail, Archive, Workflow, AI, Connect) hängen jetzt in dependsOn von SHL-01 ab und erben diese Eigenschaften strukturell. Zusätzlich existiert je Board ein Barrierefreiheits-Audit-Gate im Abschluss-Gate: DMS QA-11, Mail QA-08, Core QA-09, Workflow QA-08, AI QA-09, Connect QA-08 (Archive hat aktuell keine eigene Frontend-Kachel, daher kein Audit nötig).
- Theming: Design-Tokens aus
SHL-01sind die einzige Quelle für Hell/Dunkel-Werte, jetzt mit explizitem Akzeptanzkriterium und Prüfung ("Umschaltung Hell/Dunkel an einer Beispielkomponente ohne Layoutbruch") statt implizit über Breakpoint-Tokens. - Mehrsprachigkeit: DMS
UX-03/UX-04bleiben das einzige Board mit eigenem, ausführlichem i18n-Ticket (Infrastruktur + tatsächliche DE/EN-Übersetzungen der Inhalte) — das war weiterhin richtig so, dennSHL-01liefert nur den Rahmen (Sprachumschaltung, Übersetzungsmechanismus für Basis-Komponenten), nicht die modul-eigenen Textbausteine. Jedes Modul bindet seine Übersetzungen über den SHL-01-Rahmen ein, statt einen eigenen Mechanismus zu bauen. - Barrierefreiheit: WCAG 2.1 AA ist jetzt in jedem der 7 Boards durch ein Audit-Gate abgesichert, nicht nur DMS/Mail wie zuvor.
SHL-01s Akzeptanzkriterien 1 und 4 ("Kontrastwerte erfüllen mindestens AA" / "Basis-Komponenten erfüllen WCAG 2.1 AA als Grundeigenschaft") sind die gemeinsame Grundlage, auf der alle sechs Audit-Gates aufbauen.
5. Prinzipien aus dem Master-Prompt, konkret zugeordnet
| Master-Prompt-Ziel | Wo umgesetzt |
|---|---|
| Übersichtlich, schnell | SHL-01 Basis-Komponenten, keine schwere Anwendungsserver-Startzeit (Produkt-DNA-Linie aus allen Boards: "kein Alfresco-Overhead") |
| Responsive, Desktop und Tablet | DMS UX-01, Mail UX-04, Design-Tokens/Breakpoints in SHL-01 |
| Moderne Navigation | Abschnitt 2 dieses Dokuments |
| Modulare Oberfläche | Sieben-Boards-Architektur selbst (PRODUKTARCHITEKTUR.md Abschnitt 2) |
| Globale Suche | offen, siehe Abschnitt 6 |
| Dashboard | teilweise offen, siehe Abschnitt 6 |
| Benutzer-/Tenant-Kontext | Abschnitt 3 |
| Klare Workflows | Workflow-Board (Genehmigungen, Aufgaben, Akte) + dessen UI-Tickets (APR-03, TSK-04, RTE-03, VOR-05) |
| Nur berechtigte Module sichtbar | Abschnitt 2, Core LIC-02/RBAC-* |
6. Offene Punkte
- Globale, modulübergreifende Suche: keine Ausgangslage-Referenz in irgendeinem Board deutet auf eine gemeinsame Sucheingabe hin, die Ergebnisse aus DMS UND Mail UND Workflow-Akten gleichzeitig anzeigt. Die einzelnen Suchindizes bleiben bewusst getrennt (Entscheidung bereits getroffen) — aber eine gemeinsame Such-UI-Schicht, die mehrere modul-eigene Such-APIs parallel abfragt und zusammenführt, ist etwas anderes und wurde bisher nicht geplant.
- Zentrales Nutzer-Dashboard nach Login: existiert nur fragmentiert (Statusseite = Admin-Sicht, Auswertungs-Dashboard = Kennzahlen-Sicht). Kein Ticket für "was sieht eine normale Sachbearbeiterin direkt nach dem Einloggen" (offene Wiedervorlagen, neue Mails, zugewiesene Aufgaben aus mehreren Modulen gebündelt).
- Kein UI-Prototyp/Mockup vorhanden: dieses Dokument beschreibt Prinzipien und Zuständigkeiten, keine tatsächlichen Bildschirmentwürfe — die entstehen erst in der Umsetzung der einzelnen Oberflächen-Tickets.
Erledigt seit Stand 2026-08-26 (nicht mehr offen): Mehrsprachigkeits-Infrastruktur war unentschieden zwischen Zentralisierung und Pro-Modul-Wiederholung — inzwischen entschieden: SHL-01 liefert den zentralen i18n-Rahmen (Umschaltmechanismus), DMS UX-03/UX-04 bleibt bewusst das einzige Board mit vollständiger Übersetzungsarbeit, da Textbausteine modul-eigen sind (siehe Abschnitt 4). WCAG/Theming-Uneinheitlichkeit über die Boards ebenfalls behoben, siehe Abschnitt 4.
Rückfrage an dich: sollen globale Suche und zentrales Dashboard als neue Tickets ergänzt werden (vermutlich beide in Core SHL-Epic, da modulübergreifend), oder bleibt das für später zurückgestellt?