# Workflow-Feedback: Planung und Ausarbeitung Stand: 2026-06-27 Quelle: `VTuber Star Awards Workflow.docx` inklusive Kommentaren, abgeglichen mit dem aktuellen VTubeAwards-Repo. ## Executive Summary Die erste grosse Aenderung sollte den Core Workflow stabilisieren: Nominierung, Vorbereitung, Voting und Review/Auswertung. Das Feedback beschreibt weniger ein komplett neues Produktmodell als eine klarere Fuehrung durch bereits vorhandene Konzepte. Die wichtigsten Produktentscheidungen: - Kategorien mit Viewer-Groessen werden als einzelne Kategorien pro Unterkategorie abgebildet, gruppiert ueber `GroupName`. - Viewer duerfen pro Kategorie bis zu drei Stream- oder Kanal-Links nominieren. - Eine Nominierung muss nicht fuer alle Kategorien abgegeben werden. - Clip-Compilations werden nicht als Videodateien in der App gespeichert. - Voting und Gewinnerbereiche nutzen externe YouTube-/Twitch-Links oder Embeds. - Die Vorbereitung nach der Nominierung bleibt ein Admin-/Teamprozess mit manuellem Kontakt und Annahmestatus. - Showacts und Sponsoren werden als admin-verwaltbare Folgefeatures geplant, aber nicht in Phase 1 umgesetzt. ## Feedback-Analyse ### Kategorien und Unterkategorien Das Dokument beschreibt pro Award-Kategorie drei Unterkategorien nach Viewer-Groesse: - Hidden Star: 1 bis 20 Viewer - Rising Star: 21 bis 60 Viewer - Shining Star: 61+ Viewer Im aktuellen Datenmodell passt das am besten zu einzelnen `Category`-Datensaetzen pro Unterkategorie. Der uebergeordnete Award-Bereich, zum Beispiel `Gamer`, bleibt `GroupName`; die konkrete Unterkategorie wird `Name`, zum Beispiel `Hidden Star der Gamer`. Damit entsteht kein paralleles Kategorienmodell. Admin-, Public- und Voting-Flows koennen weiter mit `CategoryId` arbeiten. ### Nominierung Das Feedback wuenscht pro Kategorie bis zu drei Nominierungen als Stream-/Kanal-Links. Namen sind nicht zwingend noetig, weil die Admins aus dem Link den finalen Kandidaten erstellen oder zuordnen koennen. Geplanter Zielzustand: - Pro Kategorie koennen ein bis drei Links eingereicht werden. - Doppelte Links innerhalb derselben Kategorie werden blockiert. - Leere Kategorien duerfen uebersprungen werden. - Die Nominierungsoberflaeche wird wie ein Wizard aufgebaut: Kategorien links, Inhalt rechts, klare Weiter-Navigation. - Clip-Einreichung wird aus dem Nominierungsformular entfernt oder deutlich getrennt, weil laut Feedback Clips in der Nominierungsphase eher Probleme verursachen. Backendseitig existiert bereits eine passende Grundlage: `CreateNominationRequest` unterstuetzt mehrere `Nominations`, und die API verhindert doppelte Links innerhalb eines Requests. Die groesste Arbeit liegt daher im Public UI und in der Kommunikation der Regeln. ### Vorbereitung Nach der Nominierungsphase prueft das Team die Nominierungen, zaehlt aus und kontaktiert VTuber, ob sie die Nominierung annehmen. Erst danach werden Clip-Compilations relevant. Geplanter Zielzustand: - Admins sehen pro Review-Fall genug Signal, um Kandidaten zuzuordnen. - Final ausgewaehlte Nominierte bekommen einen Annahmestatus. - Admins koennen pro Kandidat eine externe Clip-Compilation-URL pflegen. - Es wird keine Upload-Infrastruktur fuer Videodateien gebaut. - Ungelistete YouTube-Videos oder Twitch-Clips koennen verlinkt oder eingebettet werden. Das haelt die Verantwortung fuer Hosting, Speicher, Copyright und Transcoding ausserhalb der App. ### Voting Das Feedback zum Voting betrifft vor allem Bedienung und Sicherheit vor unvollstaendigen Abgaben. Geplanter Zielzustand: - Das Voting bleibt ein gefuehrter Picker mit Kategorienavigation. - Es gibt einen klaren Weiter-Button unten rechts. - Das Modal behaelt eine stabile Groesse, damit beim Kategorienwechsel nichts springt. - Vor dem Absenden wird angezeigt, in welchen Kategorien noch keine Stimme gesetzt wurde. - Nutzer koennen Votes bearbeiten, solange die Votingphase aktiv ist. Backendseitig ist das Bearbeiten bereits angelegt: ein bestehendes Ballot wird beim erneuten Speichern ersetzt. Das sollte im UI bewusst als Feature kommuniziert werden. ### Review und Auswertung Das Dokument nennt zwei interne Regeln: - Eine Person kann maximal zwei Mal nominiert werden. - Eine Person kann maximal ein Mal gewinnen. Diese Regeln sollten nicht still im Public UI verschwinden, sondern als Admin-Guard und Review-Hilfe geplant werden. Geplanter Zielzustand: - Admins koennen final maximal vier Nominierte pro Unterkategorie festlegen. - Admins sehen Warnungen, wenn eine Person zu oft nominiert oder als Gewinner markiert wird. - Die App blockiert riskante finale Veroeffentlichungen oder verlangt eine bewusste Admin-Bestaetigung. - Gewinner werden pro Unterkategorie bestimmt; bei Gleichstand oder Sonderfaellen entscheidet das Team manuell. ### Website Extras Showacts und Sponsoren sind sinnvoll, aber nicht Teil der ersten Core-Workflow-Aenderung. Folgeplanung: - Showact-Bewerbungen werden als eigenes Website-Formular geplant, mit Admin-Liste zur Sichtung. - Sponsoren werden admin-verwaltbar, inklusive Logo, Link, Sichtbarkeit, Sortierung und optionaler Tier-Stufe. - Sponsorendarstellung kann als Landingpage-Banner, Karussell oder dedizierter Abschnitt umgesetzt werden. ## Priorisierte Umsetzung ### Phase 1: Public Nominierungs- und Voting-UX Ziel: Der Public Flow entspricht dem Feedback, ohne zuerst das Datenmodell stark umzubauen. Umsetzung: - Nominierungsmodal zu einem Wizard umbauen. - Pro Kategorie bis zu drei Link-Felder anbieten. - Kategorien als linke Navigation anzeigen. - Kategorien ohne Eingaben erlauben. - Doppelte Links clientseitig validieren und Backend-Fehler sauber anzeigen. - Clip-Einreichung aus dem Nominierungsflow entfernen oder als separaten, weniger prominenten Flow belassen. - Voting-Wizard um Weiter-Button und fehlende-Stimmen-Hinweis erweitern. - Vote-Bearbeitung sichtbar kommunizieren, wenn bereits gespeicherte Stimmen geladen wurden. Akzeptanz: - Eine Kategorie kann mit einem, zwei oder drei Links eingereicht werden. - Doppelte Links in derselben Kategorie werden blockiert. - Ein leerer Kategorienblock verhindert nicht das Absenden anderer Kategorien. - Voting kann gespeichert und in derselben Phase erneut geaendert werden. ### Phase 2: Admin-Vorbereitung und Clip-Compilation-Links Ziel: Das Team kann aus Review-Signalen finale Nominierte vorbereiten und externe Compilations pflegen. Umsetzung: - Admin-Review um einen klaren Schritt "finale Nominierte auswaehlen" erweitern. - Annahmestatus je finalem Nominee planen: offen, angefragt, angenommen, abgesagt. - Externe Clip-Compilation-URL, Titel und Plattform je Kandidat oder Kandidaten-Kategorie-Zuordnung pflegen. - Keine Videodateien speichern. - Optional Embed-Vorschau fuer YouTube/Twitch anzeigen, wenn technisch sicher moeglich. Akzeptanz: - Admins koennen sehen, welche Kandidaten fuer eine Unterkategorie final vorbereitet sind. - Externe Clip-Links erscheinen im Voting. - Fehlende Clips blockieren die App nicht, werden aber sichtbar markiert. ### Phase 3: Review, Gewinner und Archiv Ziel: Auswertung und Gewinnerdarstellung folgen den internen Regeln. Umsetzung: - Gewinner pro Unterkategorie verwalten. - Guard fuer "eine Person gewinnt maximal ein Mal" einplanen. - Konfigurierbare Regel "Gewinner braucht Clip-Link" einplanen; Standard blockiert Gewinner ohne gepflegte YouTube-/Twitch-Compilation. - Guard oder Warnung fuer "eine Person maximal zwei Mal nominiert" einplanen. - Gewinnerbilder im Archiv groesser und ruhiger darstellen. - Clip-Compilation im Archiv anzeigen; Standard ist externer Link oder Embed, kein Upload. - Countdown auf der Landingpage visuell groesser und prominenter gestalten. Akzeptanz: - Admins koennen Gewinner nicht versehentlich doppelt vergeben, ohne Warnung oder bewusste Bestaetigung. - Admins koennen steuern, ob Gewinner ohne Clip-Link blockiert oder nur gewarnt werden. - Archiv zeigt vorhandene Gewinner-Clips eingebettet an und bleibt bei fehlenden Clips stabil. - Countdown ist auf Desktop und Mobile gut lesbar. ### Phase 4: Showacts und Sponsoren Ziel: Website Extras werden admin-verwaltbar statt ueber externe Workarounds gepflegt. Umsetzung: - Showact-Bewerbungsformular als Public Feature umsetzen; Aktivierung laeuft ueber optionale Workflow-Einstellungen. - Admin-Ansicht fuer Showact-Bewerbungen umsetzen, inklusive Status `pending`, `shortlisted`, `accepted`, `rejected` und Review-Notiz. - Sponsorendatenmodell umsetzen: Name, Logo, URL, Tier, Sortierung, Sichtbarkeit, Saison. - Sponsorverwaltung im Admin-Panel umsetzen und Sponsorendarstellung auf der Landingpage an `SponsorsVisible` koppeln. - Public-Showact-Submit blockiert sauber, wenn Bewerbungen geschlossen sind, und nutzt den konfigurierbaren Admin-Hinweis. Akzeptanz: - Showact-Bewerbungen koennen ohne Google Form gesammelt werden. - Sponsoren koennen ohne Codeaenderung pro Saison gepflegt und sortiert werden. - Toggles fuer Showact-Bewerbungen und Sponsoren-Sichtbarkeit liegen im eigenen Modal fuer optionale Workflows. ## Interface- und Datenentscheidungen ### Beibehalten - `CategoryId` bleibt die zentrale Einheit fuer Nominierung und Voting. - `GroupName` bleibt die Gruppierung fuer uebergeordnete Award-Bereiche. - Die Nominierungs-API bleibt grundsaetzlich erhalten. - Die Voting-API bleibt grundsaetzlich erhalten. - Wiederholtes Vote-Speichern bleibt erlaubt und wird als Bearbeiten behandelt. ### Erweitern - Kandidaten oder Kandidaten-Kategorie-Zuordnungen brauchen externe Clip-Compilation-Metadaten, falls die vorhandene Clip-Zuordnung nicht ausreicht: - URL - Titel - Plattform - optionaler Embed-Status - Admin-Review braucht Statusinformationen fuer final ausgewaehlte Nominierte. - Gewinnerverwaltung braucht Guards fuer interne Regeln, inklusive "maximal ein Gewinnerplatz" und "Clip-Link fuer Gewinner erforderlich". ### Nicht bauen - Kein eigener Video-Upload. - Kein Speichern von Videodateien. - Kein paralleles Unterkategorienmodell neben `Category`. - Kein verpflichtendes Komplett-Ausfuellen aller Kategorien. ## Offene Produktfragen Diese Fragen muessen nicht vor Phase 1 beantwortet werden, sollten aber vor Phase 2 oder 3 geklaert sein: - Wird der Annahmestatus pro Kandidat global oder pro Kategorie gepflegt? - Soll eine abgesagte Person automatisch durch die naechste Review-Auswahl ersetzt werden koennen? - Soll die "maximal zwei Nominierungen"-Regel hart blockieren oder nur warnen? - Soll die "maximal ein Gewinner"-Regel hart blockieren oder Admin-Override erlauben? - Werden Sponsor-Tiers oeffentlich benannt oder nur intern zur Sortierung genutzt? - Welche Pflichtfelder braucht das Showact-Formular final? ## Test Plan ### Build und statische Checks - `npm run build` in `/Users/azu/Desktop/VTubeAwards/frontend` - `dotnet build Backend/Backend.csproj` in `/Users/azu/Desktop/VTubeAwards` ### Browserpruefung lokal - Nominierung mit einem Link in einer Kategorie. - Nominierung mit zwei Links in einer Kategorie. - Nominierung mit drei Links in einer Kategorie. - Doppelte Links in derselben Kategorie. - Leere Kategorien ueberspringen. - Voting-Kategorie wechseln. - Weiter-Button im Voting verwenden. - Fehlende-Stimmen-Hinweis vor dem Absenden pruefen. - Vote speichern, erneut oeffnen, aendern und erneut speichern. - Mobile Layout bei 360px, 390px und 768px ohne horizontales Overflow pruefen. ### API-Smoke-Checks - `GET /api/public/overview` - `GET /api/public/seasons/{year}/categories` - `GET /api/public/seasons/{year}/me` - `POST /api/public/nominations` mit authentifizierter Session. - `POST /api/public/votes` mit authentifizierter Session. ## Umsetzungshinweise - Phase 1 sollte moeglichst frontendlastig bleiben und bestehende Backend-Faehigkeiten nutzen. - Wenn Datenmodell-Migrationen noetig werden, sollten sie erst mit Phase 2 eingefuehrt werden. - Alle Public-UI-Aenderungen muessen gegen echte Backenddaten laufen, nicht gegen Demo-State. - Fuer echte UI-Aenderungen reicht ein Build nicht aus; der Flow muss im Browser geprueft werden. - Kleine Vue-Komponenten bevorzugen, besonders beim Umbau des Nominierungs- und Votingmodals.