docs(scope): Analytics und Dashboard als zwei Features festhalten
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
This commit is contained in:
dejanandClaude Opus 5 committed
1 parent
1bda20e045
commit
cdf9066076
4 files changed
+171
-1
No files matched your search
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
@@ -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.
|
||||
@@ -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
|
||||
|
||||
Reference in new issue
Block a user