From cdf906607687531160ffd02720f21fb00af4eea5 Mon Sep 17 00:00:00 2001 From: DeeCee03 Date: Sat, 29 Aug 2026 19:51:55 +0200 Subject: [PATCH] docs(scope): Analytics und Dashboard als zwei Features festhalten MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Klarstellung aus der Abstimmung: Der Prototyp wurde bisher als 'das Dashboard' bezeichnet, tatsächlich sind es zwei Features mit unterschiedlichem Zweck. Analytics beantwortet 'warum ist das so' — mehrerer Seiten, seitenübergreifender Zeitraum- und Dimensionsfilter, fachlich geschnitten. Das Dashboard beantwortet 'wie ist meine Lage' — Begrüßungsbildschirm, rollenbezogen, Widgets. Es zeigt die wichtigsten Charts aus Analytics, ist aber nicht darauf beschränkt: HR-Anträge ('2 neue Anträge'), Aufgaben und Termine gehören ebenfalls dorthin. Die Software sieht das bereits vor. DashboardWidgetDomain kennt 'hr', DashboardWidgetKind kennt 'list', und der Designer-Brief P11 nennt HR-Anträge wörtlich im Büro-Dashboard. Neu ist nicht der Scope der Software, sondern das Verhältnis zu diesem Prototyp. Drei Stellen bekommen dadurch einen anderen Zuschnitt: die Seite 'Übersicht' überschneidet sich mit dem Dashboard, der Handlungsbedarf ist eher ein Dashboard-Element, und Charts brauchen als Widgets einen eigenen Zeitraum, weil das Dashboard keinen globalen Filter hat. Sechs offene Punkte sind in docs/SCOPE-ANALYTICS-DASHBOARD.md Abschnitt 5 festgehalten. Nichts davon ist entschieden, am Code ist nichts geändert. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX --- HANDOVER.md | 5 + README.md | 9 +- docs/SCOPE-ANALYTICS-DASHBOARD.md | 154 ++++++++++++++++++++++++++++++ docs/ZIELSYSTEM.md | 4 + 4 files changed, 171 insertions(+), 1 deletion(-) create mode 100644 docs/SCOPE-ANALYTICS-DASHBOARD.md diff --git a/HANDOVER.md b/HANDOVER.md index 68f403b..d79a15b 100644 --- a/HANDOVER.md +++ b/HANDOVER.md @@ -1,5 +1,10 @@ # Übergabe an die Entwicklung +> **Vor dem Einbau lesen:** +> [`docs/SCOPE-ANALYTICS-DASHBOARD.md`](docs/SCOPE-ANALYTICS-DASHBOARD.md). +> Der Zuschnitt zwischen Analytics und Dashboard ist noch offen und betrifft die +> Übersichtsseite und den Handlungsbedarf. + Dieser Prototyp liefert **Gestaltung und Interaktion**, nicht die Anbindung. Was echt ist, was Attrappe ist und was beim Einbau zu tun bleibt: diff --git a/README.md b/README.md index 425c292..de4c472 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,13 @@ Gestaltungsvorlage für die Analytics-Dashboards in HiveGrid, fachlich auf einen SHK-/Handwerksbetrieb zugeschnitten. **Ziel dieses Repos ist die Übergabe an die Entwicklung** — nicht der Produktivbetrieb. +> **Offener Scope-Punkt:** „Analytics" und „Dashboard" sind zwei Features, nicht +> eines. Das Dashboard ist der Begrüßungsbildschirm und zeigt die wichtigsten +> Charts aus Analytics **plus** anderes (HR-Anträge, Aufgaben, Termine). Was das +> für den Zuschnitt dieses Prototyps bedeutet, steht in +> [`docs/SCOPE-ANALYTICS-DASHBOARD.md`](docs/SCOPE-ANALYTICS-DASHBOARD.md) — +> festgehalten, noch nicht entschieden, noch nichts danach gebaut. + ```bash npm install npm run dev # http://localhost:4300 @@ -48,7 +55,7 @@ features/dashboard/ utils/ chartTheme (Carbon-Tokens), formatters, dateUtils ui/ Subframe-Komponentenbibliothek (unverändert übernommen) docs/ Design-System, KPI-Katalog, Navigation, Datenmodell, - Herkunft, Zielsystem, Leitplanken, Prüffragen + Herkunft, Zielsystem, Leitplanken, Prüffragen, Scope scripts/verify-carbon.mjs gleicht chartTheme.ts gegen die Carbon-Referenz ab scripts/verify-layout.mjs misst Textkollisionen über alle Seiten und Breiten ``` diff --git a/docs/SCOPE-ANALYTICS-DASHBOARD.md b/docs/SCOPE-ANALYTICS-DASHBOARD.md new file mode 100644 index 0000000..c0f8d28 --- /dev/null +++ b/docs/SCOPE-ANALYTICS-DASHBOARD.md @@ -0,0 +1,154 @@ +# Scope: Analytics und Dashboard sind zwei Features + +**Stand: 29.08.2026 · Festgehalten, nicht entschieden.** +Auf dieser Grundlage ist noch nichts gebaut. Die offenen Punkte in Abschnitt 5 +sind mit den Kollegen zu klären, bevor jemand Code anfasst. + +--- + +## 1. Die Unterscheidung + +Bisher wurde dieser Prototyp als „das Dashboard" bezeichnet. Das ist ungenau — +es sind zwei Features mit unterschiedlichem Zweck: + +| | **Analytics** | **Dashboard** | +|---|---|---| +| Frage | „Warum ist das so?" | „Wie ist meine Lage?" | +| Charakter | Analysebereich, mehrere Seiten | Begrüßungsbildschirm, eine Seite | +| Einstieg | bewusst aufgesucht | erste Seite nach dem Login | +| Bedienung | Zeitraum + fünf Dimensionsfilter, seitenübergreifend | Widgets, je Widget nur Filter/Zeitraum | +| Inhalt | ausschließlich Auswertungen | Auswertungen **und anderes** | +| Zuschnitt | fachlich (Finanzen, Aufträge, Kunden, Team) | **rollenbezogen** (GF, Büro, Monteur) | + +**Der entscheidende Unterschied:** Das Dashboard zeigt die wichtigsten Charts +aus Analytics, ist aber **nicht darauf beschränkt**. Es ist der Ort für alles, +was beim Anmelden zählt — auch für Dinge, die keine Auswertung sind: +„2 neue Anträge", offene Dokumente, Termine heute, zugewiesene Aufgaben. + +Analytics liefert also Bausteine an das Dashboard, deckt es aber nicht ab. + +--- + +## 2. Was die Software dafür bereits vorsieht + +Das ist kein neuer Scope für HiveGrid Cloud — die Architektur ist darauf +ausgelegt. Belegt in `packages/view-models/src/dashboard/dashboard-page.vm.ts`: + +```ts +type DashboardRoleKey = "gf" | "office" | "monteur"; +type DashboardWidgetDomain = "general" | "sales" | "finance" | "projects" + | "tasks" | "hr" | "activity" | "comms" | "schedule"; +type DashboardWidgetKind = "hero" | "kpi" | "list" | "trend" | "chart"; +``` + +Die Domäne **`hr`** und die Art **`list`** existieren bereits. „2 neue Anträge" +ist damit ein `hr`/`kpi`- oder `hr`/`list`-Widget im Katalog — kein Sonderfall, +sondern der vorgesehene Weg. + +Der Designer-Brief P11 nennt die drei Rollen-Layouts sogar konkret: + +> **GF** (Begrüßung, Sales-KPIs, Umsatz-Forecast, Projekt-KPIs, Auslastung, +> offene Mängel, Team-heute) · **Büro** (Begrüßung, Projekt-KPIs, meine Tasks, +> Anrufe heute, **HR-Anträge**) · **Monteur** (meine Termine heute, meine +> Projekte, meine Tasks) + +**HR-Anträge stehen dort bereits im Büro-Dashboard.** Die Idee ist also +dokumentiert; was fehlt, ist die Verbindung zu unserer Analytics-Arbeit. + +--- + +## 3. Was das für diesen Prototyp bedeutet + +**Die fünf Analyse-Seiten sind das Analytics-Feature.** Daran ändert sich +nichts — Finanzen, Aufträge, Kunden, Team und die Diagrammbausteine bleiben, +wie sie sind. + +**Drei Stellen bekommen einen anderen Zuschnitt:** + +1. **Die Seite „Übersicht" überschneidet sich mit dem Dashboard.** + Sie ist heute als Einstiegsseite gebaut: Kennzahlenreihe, Handlungsbedarf, + Hauptdiagramm. Genau diese Rolle hat in der Software das Dashboard. Zwei + Einstiegsseiten nebeneinander wären eine Doppelung. + +2. **Der Handlungsbedarf ist eigentlich ein Dashboard-Element.** + „Was ist zu tun" ist die Frage des Begrüßungsbildschirms, nicht der Analyse. + Ich habe ihn in der letzten Runde bewusst nach oben auf die Übersicht + gezogen, weil dort die Handlungsebene fehlte — unter der neuen Trennung + gehört er wahrscheinlich ins Dashboard. + +3. **Charts müssen als Widgets einzeln funktionieren.** + Gute Nachricht: Sie tun es bereits. Die Diagrammkomponenten unter + `components/charts/` sind reine Komponenten, die ihre Daten als Prop + bekommen — sie hängen an keiner Seite. Was **nicht** mitwandert, ist die + Kartenhülle `ChartCard`: Ihr ⋯-Menü und das Ausblenden sind Analytics-Logik; + im Dashboard macht das die Widget-Registry. + + Zu beachten ist der **Bruch im Bedienmodell**: In Analytics wirkt eine + Filterleiste auf alle Karten gleichzeitig. Im Dashboard trägt jedes Widget + seinen eigenen Zeitraum (P11: „Edit = nur Widget-Filter/Zeitraum"). Ein + Chart, das aus Analytics ins Dashboard gehoben wird, verliert den globalen + Filter und braucht einen eigenen — sonst zeigt es stillschweigend einen + anderen Zeitraum als die Nachbarkachel. + +--- + +## 4. Wie die beiden zusammenhängen + +``` +Analytics (Bereich „Statistiken") Dashboard (Startseite) +├── Übersicht ← Rolle unklar, ┐ ├── Begrüßung +├── Finanzen siehe 5.1 │ ├── KPI-Kacheln ┐ aus dem +├── Aufträge ├──────┤ Trend-Charts ┤ Analytics- +├── Kunden │ ├── Listen ┘ Katalog +└── Team (Daten: v2) ┘ ├── HR-Anträge ┐ NICHT aus + ├── Meine Aufgaben ┤ Analytics + └── Termine heute ┘ +``` + +Die Kennzahl-Definitionen aus [KPI-KATALOG.md](KPI-KATALOG.md) und die +Diagrammregeln aus [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) gelten für **beide** +Features. Ein Umsatzchart im Dashboard rechnet und aussieht wie dasselbe Chart +in Analytics — sonst widersprechen sich zwei Seiten derselben Anwendung. + +--- + +## 5. Offene Punkte + +Nicht entschieden. Reihenfolge nach Tragweite: + +**5.1 Was wird aus der Seite „Übersicht"?** +- *A:* Sie wird das Dashboard. Analytics startet dann bei Finanzen. +- *B:* Sie bleibt als Analytics-Einstieg, verliert aber Handlungsbedarf und + Begrüßungscharakter und wird zur reinen Kennzahlen-Zusammenfassung. +- *C:* Sie entfällt; Analytics besteht aus vier fachlichen Seiten. + +**5.2 Welche Analytics-Charts werden Dashboard-Widgets?** +Der Katalog braucht eine Auswahl. Nicht jedes Chart taugt als Kachel — der +Vertriebstrichter etwa lebt von der Übergangsquote und wird klein unlesbar. + +**5.3 Wo lebt der Handlungsbedarf?** +Vermutlich Dashboard. Dann fehlt Analytics die Handlungsebene — bewusst +akzeptieren oder anders lösen. + +**5.4 Zeitraum-Modell im Dashboard.** +Globaler Filter wie in Analytics oder pro Widget wie in P11? Die Software hat +sich für „pro Widget" entschieden; das ist beim Übertragen zu beachten. + +**5.5 Navigation.** +Eigene Gruppe „Statistiken" neben Kunden/Projekte — siehe +[ZIELSYSTEM.md](ZIELSYSTEM.md) 3.1b. Hängt an 5.1: Solange unklar ist, ob es +eine Übersichtsseite gibt, ist auch der Einstiegspunkt der Gruppe offen. + +**5.6 Team-Seite.** +Unabhängig davon offen, weil Zeiterfassung im v2-Backlog steht — siehe +[DATENMODELL.md](DATENMODELL.md). + +--- + +## 6. Bis zur Klärung + +Am Code ändert sich nichts. Der Prototyp bleibt in seinem jetzigen Zuschnitt +brauchbar: Die Diagrammbausteine, Kennzahl-Definitionen und Regeln gelten +unabhängig davon, wie die beiden Features später geschnitten werden. Die +Übersichtsseite ist im Zweifel der Entwurf für das Dashboard — dann wäre sie +nicht falsch, sondern nur am falschen Ort. diff --git a/docs/ZIELSYSTEM.md b/docs/ZIELSYSTEM.md index a079463..e0467ed 100644 --- a/docs/ZIELSYSTEM.md +++ b/docs/ZIELSYSTEM.md @@ -194,6 +194,10 @@ Einstiegsseiten um dieselbe Rolle. Das ist eine Produkt- und Designentscheidung, keine Umsetzungsfrage. Sie gehört in die Runde mit dem Head of Design, nicht in den Einbau. +**Nachtrag 29.08.2026:** Die Frage hängt an einer größeren — „Analytics" und +„Dashboard" sind zwei Features. Siehe +[SCOPE-ANALYTICS-DASHBOARD.md](SCOPE-ANALYTICS-DASHBOARD.md). + ### 3.2 Kein eigenes App-Chrome `AppShell.tsx` aus diesem Prototyp fällt beim Einbau **weg**. Die Cloud-Routen