AzuTear
192 lines
9.9 KiB
Markdown
192 lines
9.9 KiB
Markdown
# Dashboard & Admin-Panel — Analyse + Plan
|
||
|
||
> Status: **Umgesetzt.** Dieses Dokument beschreibt die Analyse, die umgesetzte
|
||
> Dashboard-Readiness-Ausrichtung und die noch bewusst zurückgestellte Phase 2.
|
||
> Das Dashboard ist saisonbezogen, bleibt read-only und verlinkt in die Fachseiten.
|
||
|
||
---
|
||
|
||
## 0. Wichtigster Befund vorweg: gespaltene Datenquelle
|
||
|
||
Das Dashboard mischt **zwei verschiedene Saison-Quellen**, und das ist die Wurzel der meisten Probleme:
|
||
|
||
| Sektion | Datenquelle | Reagiert auf Jahr-Wechsel im Toolbar? |
|
||
|---|---|---|
|
||
| Metric-Cards (Nominierungen, Stimmen…) | `store.admin.metrics` → Backend `/dashboard` → **immer `IsCurrent`-Saison** | ❌ Nein |
|
||
| Top-Kategorien, Aktivitäten | `store.admin` (gleiche Quelle) | ❌ Nein |
|
||
| Jahreszahlen, Checks, Priority, Toolbar-Stats | `store.adminSeasonDetail` → **ausgewählte Saison** | ✅ Ja |
|
||
|
||
Wenn der Host im Toolbar das Jahr wechselt, ändern sich **die Hälfte der Kacheln nicht**.
|
||
„Stimmen gesamt" (Hero) und „Stimmen gesamt" (Jahreszahlen) können unterschiedliche Werte
|
||
zeigen. Das muss vereinheitlicht werden, **bevor** irgendetwas Neues draufkommt.
|
||
|
||
**Umgesetzt:** Die ausgewählte Saison (`adminSeasonDetail`) ist die führende
|
||
Dashboard-Quelle. `/api/admin/dashboard` akzeptiert optional `seasonId`; ohne
|
||
`seasonId` bleibt das alte `IsCurrent`-Verhalten kompatibel.
|
||
|
||
---
|
||
|
||
## 1. Ist-Zustand: bestehende Komponenten
|
||
|
||
**`AdminDashboardView.vue`** — Orchestrator, lädt alles aus `useAdminDashboardOverview()`
|
||
und arrangiert 6 Sektionen in Grids. Sauber, dünn, gut.
|
||
|
||
**`AdminPageHeader`** — nur Eyebrow „Dashboard" + Icon. Keine Begrüßung, kein Kontext.
|
||
|
||
**`AdminSeasonToolbar`** — Jahr-Auswahl + Phasen-Pill (nur Text) + 3 Mini-Stats
|
||
(Kategorien/Kandidaten/Reviews). Zeigt `isCurrent` als „Öffentlich sichtbar".
|
||
**Es fehlen alle Datumsangaben** (Nominierungsstart, Voting-Ende, Show-Termin),
|
||
obwohl sie in `adminSeasonDetail` vorliegen.
|
||
|
||
**`AdminDashboardHeroSection`** — „Live-Lage" als generierter Fließband-Satz + Status-Badge
|
||
+ Metric-Cards mit `Quelle: VoteEntries-Tabelle`. Die Quell-Labels sind entwicklersprachlich,
|
||
nicht host-tauglich.
|
||
|
||
**`AdminDashboardPrioritySection`** („Was zuerst?") — 4 Quick-Links (Reviews, Risiko,
|
||
Kategorien, Kandidaten) mit Permission-Filter. Gut gebaut. Aber statisch: zeigt immer
|
||
dieselben 4, unabhängig von der Phase.
|
||
|
||
**`AdminDashboardChecksSection`** — 3 Betriebs-Checks (Kategorien ohne Kandidaten,
|
||
Review-Backlog, Risk Flags) mit Deep-Links und ok/warn/danger. Stärkste Sektion,
|
||
weil handlungsorientiert.
|
||
|
||
**`AdminDashboardYearTotalsSection`** — 6 reine Zahlen. Überschneidet sich inhaltlich
|
||
stark mit den Hero-Metric-Cards (Nominierungen, Stimmen, Kategorien, Reviews, Risiko
|
||
tauchen doppelt auf).
|
||
|
||
**`AdminDashboardTopCategoriesSection`** — Top 5 nach Stimmen mit Balken.
|
||
**Während der Nominierungsphase nutzlos** (Stimmen = 0).
|
||
|
||
**`AdminDashboardActivitySection`** — hart auf 3 Audit-Einträge gedeckelt,
|
||
**kein Link zum vollen Audit-Log**.
|
||
|
||
---
|
||
|
||
## 2. Personas: was Host vs. Admin wirklich brauchen
|
||
|
||
**Der Host (Jayuhime)** denkt in der **Timeline der Show**, nicht in Tabellen:
|
||
- „Wo stehen wir gerade, und wie lange noch?" (Countdown bis Phasen-Ende / Show)
|
||
- „Stimmt die gespeicherte Phase mit dem Zeitplan überein?"
|
||
- „Ist die öffentliche Seite bereit? Stream-Link gesetzt, keine Wartung an?"
|
||
- „Sind wir bereit, Gewinner zu verkünden?"
|
||
- „Was zeigt die Community gerade?" (Beteiligung wächst)
|
||
|
||
**Der Admin / das Team** denkt **operativ**:
|
||
- „Was liegt in meiner Queue?" (Reviews, Risk, Clips)
|
||
- „Wo klemmt es?" (leere Kategorien, Backlog-Verteilung)
|
||
- „Wer hat zuletzt was geändert?" (Audit)
|
||
|
||
Das aktuelle Dashboard bedient **fast nur die Admin-Sicht**. Die Host-Sicht
|
||
(Timeline, Bereitschaft, Public-Health) fehlt fast komplett.
|
||
|
||
---
|
||
|
||
## 3. Verbesserungswürdig (bestehende Komponenten)
|
||
|
||
1. **Datenquelle vereinheitlichen** (siehe §0) — Metrics/Top-Kategorien/Aktivitäten auf
|
||
die gewählte Saison umstellen. Empfehlung: gewählte Saison als einzige Quelle.
|
||
2. **Quell-Labels host-freundlich machen** — „Quelle: VoteEntries-Tabelle" → weg damit
|
||
oder „Aktualisiert aus dem Live-Voting".
|
||
3. **Redundanz Hero ↔ Jahreszahlen auflösen** — eine der beiden Zahlen-Wände streichen;
|
||
Hero = Live/Aktion, Jahreszahlen = Summen.
|
||
4. **Top-Kategorien phasenabhängig** — in Nominierungsphase „Top nach Nominierungen"
|
||
statt nach Stimmen zeigen.
|
||
5. **Priority-Liste phasenabhängig priorisieren** — in Show-Vorbereitung „Gewinner setzen"
|
||
nach oben, in Nominierung „Reviews" nach oben.
|
||
6. **Aktivitäten** — auf 5–6 erhöhen + „Alles ansehen"-Link zum Audit-Log.
|
||
|
||
---
|
||
|
||
## 4. Was fehlt — neue Komponenten (mit Aufbau)
|
||
|
||
### 4.1 `AdminDashboardTimelineStrip.vue` — Phasen-Timeline mit Countdown
|
||
- **Wofür:** Die zentrale Host-Frage „Wo stehen wir, wie lange noch?" auf einen Blick.
|
||
- **Was es macht:** Zeigt die 4 Phasen (Nominierung → Voting → Aufbereitung → Show) als
|
||
horizontalen Strip mit Datumsspannen; die aktive Phase ist hervorgehoben; ein großer
|
||
Countdown zeigt „noch X Tage bis Voting-Ende" bzw. „bis zur Show". Warnt sichtbar,
|
||
wenn die gespeicherte Phase vom Zeitplan abweicht (die Logik existiert bereits in
|
||
`AdminSeasonPhaseSwitcher` als `autoPhase` — wiederverwenden).
|
||
- **Aufbau:** Eigene Computed in `useAdminDashboardOverview` (`timelinePhases`,
|
||
`activeCountdown`, `phaseMismatch`) gespeist aus
|
||
`adminSeasonDetail.*StartsAt/*EndsAt/showDate`; Datums-/Zustandsmapping aus
|
||
`Common/SeasonMappings.cs` (`ResolveTimelineState`) spiegeln. Reine Props-Komponente,
|
||
`<Card>` mit 4 Phasen-Segmenten (analog zu `HomeTimelineSection` der Landingpage,
|
||
gleiche Farb-Token). Optional Deep-Link zu `/admin/years` für Phasenwechsel.
|
||
|
||
### 4.2 `AdminDashboardReadinessCard.vue` — Show-Bereitschaft
|
||
- **Wofür:** „Sind wir bereit, live zu gehen / Gewinner zu verkünden?"
|
||
- **Was es macht:** Checkliste aus `votingWorkspace.summary`: votedSubcategories /
|
||
readySubcategories / **winnerSetSubcategories** vs. totalSubcategories, plus
|
||
„Show-Datum gesetzt", „Stream-URL gesetzt", „alle Gewinner gesetzt". Ein Fortschrittsring
|
||
„12 / 14 Unterkategorien gewinnerbereit".
|
||
- **Aufbau:** Computed `readinessItems` (Label, erfüllt-bool, Deep-Link). Quelle:
|
||
`adminSeasonDetail.votingWorkspace.summary` (bereits vorhanden, heute ungenutzt im
|
||
Dashboard!) + `showDate`/Stream-Banner-Link. `<Card>` mit Fortschrittsbalken + Liste mit
|
||
Häkchen/Warnungen. Nur sichtbar/relevant ab Voting-Phase.
|
||
|
||
### 4.3 `AdminDashboardPublicHealthCard.vue` — Öffentliche Seite
|
||
- **Wofür:** Der Host muss sehen, was die Community sieht.
|
||
- **Was es macht:** Ampel für: Saison öffentlich (`isCurrent`), Wartungsmodus an/aus,
|
||
Stream-Link vorhanden, Pflicht-Content (Impressum/Datenschutz) gepflegt. Plus
|
||
„Landingpage ansehen"-Button.
|
||
- **Aufbau:** Zieht aus `adminOptionalFeatureSettings` / Operational-Settings (Wartung)
|
||
+ `adminSiteSettings` (Content-Lücken). `<Card>` mit Status-Zeilen, Deep-Links nach
|
||
`/admin/content` und `/admin/settings/access`. Permission-gated auf `content`/`settings`.
|
||
|
||
### 4.4 `AdminDashboardQueueCard.vue` — vereinte Team-Queue
|
||
- **Wofür:** Admins/Reviewer wollen „meine offenen Aufgaben" inkl. **Clips**, die heute
|
||
komplett fehlen.
|
||
- **Was es macht:** Zählt Reviews offen, Risk offen, **Clips pending** in einer Karte mit
|
||
je Deep-Link und Badge. Ersetzt/erweitert die heutige Priority-Sektion um den Clip-Strang.
|
||
- **Aufbau:** Computed `queueItems` aus `pendingNominations.length`, `getRiskMetricValue`,
|
||
`clipSubmissions.filter(pending)`; jeweils Permission-gated (Clip nur wenn
|
||
`clipAdminMenuVisible`). Listen-`<Card>` wie `AdminDashboardPrioritySection`,
|
||
wiederverwendbares Item-Markup.
|
||
|
||
### 4.5 `AdminDashboardParticipationTrend.vue` (Phase 2) — Beteiligungsverlauf
|
||
- **Wofür:** „Wächst die Beteiligung?" — Motivation/Story für den Host.
|
||
- **Was es macht:** Mini-Sparkline Nominierungen/Stimmen über die letzten Tage.
|
||
- **Aufbau:** **Benötigt neues Backend** (Zeitreihe, heute liefert `/dashboard` nur Totals).
|
||
Daher klar als Phase-2 markieren, nicht im ersten Wurf.
|
||
|
||
---
|
||
|
||
## 5. Was bewusst NICHT ins Dashboard kommt
|
||
|
||
- **Tiefen-Analytics / Kategorie-Health-Matrix** → bleibt in `/admin/analytics`
|
||
(existiert dort bereits vollständig). Dashboard nur verlinken.
|
||
- **Voll-Editierbarkeit** (Phasen umschalten, Texte ändern, Gewinner setzen) → bleibt in
|
||
den Fachseiten. Dashboard ist **read + deep-link**, kein Editor. Ausnahme: höchstens
|
||
ein „Phase aktivieren"-Shortcut.
|
||
- **Volles Audit-Log mit Filtern** → bleibt in `/admin/users-logs`. Dashboard zeigt nur
|
||
die letzten 5 + Link.
|
||
- **Team-/Rollenverwaltung, Tracking-Rules, DB-Checks** → reine Settings, kein Tagesgeschäft.
|
||
- **Echtzeit-Sparkline** im ersten Release (Backend fehlt).
|
||
|
||
---
|
||
|
||
## 6. Empfohlene Ziel-Struktur (Reihenfolge = Sichtbarkeit)
|
||
|
||
```
|
||
1. PageHeader + Begrüßung („Hi Jayuhime") + Datum
|
||
2. SeasonToolbar (+ Datumsspannen ergänzen)
|
||
3. TimelineStrip + Countdown ← NEU, Host-Anker
|
||
4. [ Hero/Live-Lage | Queue-Card ] ← Queue NEU (inkl. Clips)
|
||
5. ChecksSection (beibehalten)
|
||
6. [ ReadinessCard | PublicHealthCard ] ← beide NEU
|
||
7. [ YearTotals (entschlackt) | TopCategories (phasen-aware) ]
|
||
8. ActivitySection (5 Einträge + Link)
|
||
```
|
||
|
||
**Reihenfolge der Umsetzung:**
|
||
1. **Datenquelle vereinheitlichen** (§0) — Fundament, blockiert alles andere.
|
||
2. **TimelineStrip + Toolbar-Datumsangaben** — größter Host-Mehrwert, Daten schon da.
|
||
3. **Queue-Card (mit Clips) + Readiness-Card** — füllt die echten Lücken, Daten schon da.
|
||
4. **PublicHealth-Card** — kleiner, aber wertvoll.
|
||
5. **Entschlacken** (Redundanz Hero/Jahreszahlen, phasen-aware Top-Kategorien).
|
||
6. **Phase 2:** Beteiligungs-Sparkline (braucht Backend-Zeitreihe).
|
||
|
||
> **Umgesetzt:** TimelineStrip, Readiness und Queue nutzen bestehende
|
||
> `adminSeasonDetail`-Daten. Der Dashboard-Endpoint ist zusätzlich saisonfähig,
|
||
> damit Metriken und Top-Kategorien beim Jahrwechsel konsistent bleiben.
|