dejanandClaude Opus 5
b8bf987d0e
UI/UX-Prototyp der Analytics-Dashboards in HiveGrid, fachlich auf einen SHK-/Handwerksbetrieb zugeschnitten. Ziel ist die Übergabe an die Entwicklung, nicht der Produktivbetrieb. Inhalt: sechs Seiten (Übersicht, Finanzen, Aufträge, Kunden, Team, Komponenten), 26 KPIs, neun Chart-Bausteine, Filtersystem mit seitenabhängiger Relevanz und ein deterministischer Demo-Datensatz (420 Kunden, 1.900 Aufträge, Stichtag 30.07.2026). Drei Quellen sind zusammengeführt: die fachliche Planung mit dem Branchenpartner (Januar 2026), die Subframe-Komponentenbibliothek aus dem HiveGrid-Pitch und IBM Carbon Data Visualization für die Diagrammregeln. Herkunft und bewusste Abweichungen stehen in docs/HERKUNFT.md. Dokumentation: README, HANDOVER (was echte Logik braucht), docs/DESIGN-SYSTEM, KPI-KATALOG, DATENMODELL, NAVIGATION, HERKUNFT, ZIELSYSTEM (Einbauort in HiveGrid Cloud) und LEITPLANKEN (welche Cloud-Screens als Vorbild taugen). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
114 lines
5.0 KiB
Markdown
114 lines
5.0 KiB
Markdown
# HiveGrid Analytics Dashboard — UI/UX-Prototyp
|
|
|
|
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.
|
|
|
|
```bash
|
|
npm install
|
|
npm run dev # http://localhost:4300
|
|
```
|
|
|
|
---
|
|
|
|
## Was hier drin ist
|
|
|
|
| Bereich | Inhalt |
|
|
|---|---|
|
|
| **6 Seiten** | Übersicht, Finanzen, Aufträge, Kunden, Team, Komponenten |
|
|
| **26 KPIs** | vollständig definiert in [`docs/KPI-KATALOG.md`](docs/KPI-KATALOG.md) |
|
|
| **9 Chart-Bausteine** | Fläche, Säulen, liegende Balken, Ring, Trichter, Auslastung, Sparkline, Legende, Leerzustand |
|
|
| **Filtersystem** | Zeitraum + 5 Dimensionen, seitenabhängig relevant, in localStorage persistiert |
|
|
| **Demo-Datensatz** | deterministisch erzeugt: 420 Kunden, 1.900 Aufträge, ~1.260 Rechnungen, 2,4 Mio. € Jahresumsatz |
|
|
|
|
Alles ist deutschsprachig, weil die Oberfläche deutschsprachig ist — inklusive
|
|
Bezeichner im Code. Das erspart beim Einbau die ständige Übersetzung zwischen
|
|
`revenue` und „Umsatz".
|
|
|
|
---
|
|
|
|
## Wo was liegt
|
|
|
|
```
|
|
app/ Next.js App Router — je Seite nur ein Wrapper
|
|
features/dashboard/
|
|
components/
|
|
layout/ AppShell, PageHeader, PageContainer, Navigation
|
|
cards/ KPICard, ChartCard, AlertList, StatZeile
|
|
charts/ alle Visualisierungen + gemeinsamer Tooltip
|
|
filters/ Filterleiste und Mehrfachauswahl
|
|
tables/ DataTable (sortieren, suchen, blättern) + Badges
|
|
context/ Filter-, Widget- und Toast-State
|
|
data/ types · seed (Dummy-Daten) · calculations · filtering
|
|
hooks/ useAnalyseDaten
|
|
pages/ die sechs Seitenkompositionen
|
|
utils/ chartTheme (Carbon-Tokens), formatters, dateUtils
|
|
ui/ Subframe-Komponentenbibliothek (unverändert übernommen)
|
|
docs/ Design-System, KPI-Katalog, Navigation, Datenmodell, Herkunft, Zielsystem, Leitplanken
|
|
```
|
|
|
|
**Wichtigste Datei für den Einbau:** `features/dashboard/data/calculations.ts`.
|
|
Dort steht jede Kennzahl als reine Funktion — Datenquelle austauschen, Rest bleibt.
|
|
|
|
---
|
|
|
|
## Grundlagen
|
|
|
|
Drei Quellen sind hier zusammengeführt:
|
|
|
|
1. **Fachliche Planung** (Januar 2026, mit dem Branchenpartner erarbeitet) —
|
|
Seitenschnitt, KPI-Auswahl, Filtersystem, Zahlen- und Spacing-Regeln.
|
|
2. **Bestehender Pitch-Prototyp** — die Subframe-Komponentenbibliothek unter `ui/`
|
|
und die Gestaltungssprache der Oberfläche.
|
|
3. **IBM Carbon Data Visualization** — Chart-Regeln, Farbpalette, Achsen, Tooltips.
|
|
Siehe [`docs/DESIGN-SYSTEM.md`](docs/DESIGN-SYSTEM.md).
|
|
|
|
Welche Quelle was beigesteuert hat — und an welchen Stellen bewusst von der
|
|
Januar-Planung abgewichen wurde — steht in [`docs/HERKUNFT.md`](docs/HERKUNFT.md).
|
|
|
|
---
|
|
|
|
## Für die Entwicklung
|
|
|
|
[`HANDOVER.md`](HANDOVER.md) listet auf, was echte Logik braucht, was bewusst
|
|
Attrappe ist und in welcher Reihenfolge der Einbau sinnvoll ist.
|
|
|
|
Die Seite **/komponenten** zeigt jeden Baustein isoliert mit Dateipfad — der
|
|
schnellste Weg, sich zu orientieren.
|
|
|
|
---
|
|
|
|
## Zielsystem
|
|
|
|
Eingebaut wird das hier in **HiveGrid Cloud** (`HiveGrid-Cloud`, Gitea
|
|
`toolctrl-labs`) — die eigentliche Software: pnpm-Monorepo, React Router 7,
|
|
Prisma/Postgres, mandantenfähig. Zielort ist der Tenant-Dashboard-Screen unter
|
|
`…/<tenant>/dashboard`.
|
|
|
|
Dort steht bereits eine Implementierung — bewusst als **Interim-UI**: gebaut aus
|
|
derselben Subframe-Bibliothek gegen ein stabiles View-Model, damit die
|
|
Backend-Tickets nicht auf den finalen Screen warten müssen. Die finale Optik ist
|
|
dort als Nachzug vorgemerkt. Genau die Lücke füllt dieser Prototyp.
|
|
|
|
Die Ausgangslage ist günstiger als üblich: **dasselbe Subframe-Projekt**
|
|
(82 der 86 Komponenten identisch benannt) und **dieselbe Chart-Bibliothek**
|
|
(Recharts). Der Einbau ist ein Port, keine Neuimplementierung.
|
|
|
|
Anzupassen sind vor allem vier Dinge — Daten kommen als View-Model-Prop mit fünf
|
|
Zuständen statt als Import, Texte laufen über i18n, Diagramme brauchen eine
|
|
Textalternative für Screenreader, und das App-Chrome dieses Prototyps entfällt,
|
|
weil die Zielanwendung Shell und Sidebar mitbringt.
|
|
|
|
**Nicht alles in der Zielanwendung sieht heute final aus.** HiveGrid Cloud
|
|
arbeitet designer-first: Für jede Phase gibt es einen Brief mit den benötigten
|
|
UI-Elementen, den finalen Screen entwirft der Designer in Subframe — Layout und
|
|
Anordnung sind ausdrücklich dessen Entscheidung. Ein großer Teil dieser Screens
|
|
ist noch offen und läuft bis dahin auf Interim-UI. Für diesen Prototyp heißt
|
|
das: Verbindlich zu übergeben sind **Kennzahl-Definitionen, Chart-Regeln und
|
|
Verhalten** — die Pixelanordnung ist ein Vorschlag.
|
|
|
|
Details, Dateipfade und die konkrete Einbau-Liste stehen in
|
|
[`docs/ZIELSYSTEM.md`](docs/ZIELSYSTEM.md). Welche Bereiche der Zielanwendung
|
|
bereits finale Subframe-Screens tragen — und damit als Leitplanke taugen — steht
|
|
in [`docs/LEITPLANKEN.md`](docs/LEITPLANKEN.md).
|