0 Fork 0

Files

T

dejanandClaude Opus 5 cdf9066076 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

2026-08-29 19:51:55 +02:00

6.9 KiB

Raw Blame History

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:

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:

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.
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.
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 und die Diagrammregeln aus 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 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.

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.

6.9 KiB Raw Blame History