0 Fork 0

Files

T

dejanandClaude Opus 5 b8bf987d0e feat(dashboard): Analytics-Dashboard als Gestaltungsvorlage zur Übergabe

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

2026-08-29 17:25:20 +02:00

5.0 KiB

Raw Blame History

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.

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`
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:

Fachliche Planung (Januar 2026, mit dem Branchenpartner erarbeitet) — Seitenschnitt, KPI-Auswahl, Filtersystem, Zahlen- und Spacing-Regeln.
Bestehender Pitch-Prototyp — die Subframe-Komponentenbibliothek unter ui/ und die Gestaltungssprache der Oberfläche.
IBM Carbon Data Visualization — Chart-Regeln, Farbpalette, Achsen, Tooltips. Siehe 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.

Für die Entwicklung

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. Welche Bereiche der Zielanwendung bereits finale Subframe-Screens tragen — und damit als Leitplanke taugen — steht in docs/LEITPLANKEN.md.

5.0 KiB Raw Blame History