Zum Inhalt springen
Doku

Patterns

Wie die Komponenten zu wiederkehrenden Mustern kombiniert werden. Neue Oberflächen sollen bestehende Seitenmuster fortsetzen statt neue Sonderlösungen zu erfinden.

Seitenmuster

Abschnitt betitelt „Seitenmuster“
  • Admin-Seiten: klare Header, Rücklinks, in sinnvolle Abschnitte gegliederte Formularbereiche mit farbigen Abschnittsicons (z. B. Details, Format, Termin, Thumbnail, Status). Arbeitsorientiert, kein Marketing-Layout.
  • Listen & Tabellen: scanbar, wichtige Zeilenaktionen direkt sichtbar oder über eindeutige Buttons. Für Teilnehmer, Attendance, Audit-Logs, Tracking.
  • Dashboard-/Listenkarten: kompakte Event-/Reihenkarten. Status, Teilnahmezustand, Format, Datum und Content-Indikatoren direkt erfassbar. Bildkopf (192px) oder Tropfen-Platzhalter (icon-droplet) mit Anfangsbuchstabe.
  • Detailseiten: Stammdaten/Termin/Format, Dokumente/Links/Recordings, Posts, Feedback-/Kalenderaktionen. Admin-Aktionen nur rollenbasiert einblenden, aber Sicherheitsentscheidungen liegen trotzdem serverseitig (Zero-Trust).
  • Uploads: Drop-Zonen mit Fortschrittsanzeige, direct-to-MinIO über vorbereitete Upload-URL und anschließende Registrierung.
  • Navigation: Header mit Logo, rollenbasierten Admin-Links, Notification- Glocke und User-Menü. Mobile und Desktop beide nutzbar.
  • Tracking & Audit: datenorientierte Recherche-Oberflächen: kompakte Filterzeile über scanbarer Tabelle, aufklappbare Zeilen mit Vorher/Nachher.

Empty States

Abschnitt betitelt „Empty States“

Leere Bereiche erklären kurz, was fehlt: eine ruhige, zentrierte Zeile in einer gerahmten Karte, keine illustrationslastige „Empty Hero”. Beispiele: keine Dokumente, keine Aufzeichnungen, keine Veranstaltungen.

Formular-Design

Abschnitt betitelt „Formular-Design“

Vollständige Feld-für-Feld-Referenz: apps/web/components/event-form.tsx und die übrigen Formulare. Hier die Kernregeln.

Architektur

Abschnitt betitelt „Architektur“

Default: native HTML-Forms mit Server Actions. Werte über FormData. Die serverseitigen Actions bleiben die Quelle der Wahrheit für Berechtigungen, Persistenz und Zero-Trust-Prüfungen.

<form action={saveAction}>
  <input type="hidden" name="eventId" value={event.id} />
  <FormSubmitButton className="section-submit h-9 rounded-lg px-4 text-sm font-semibold">
    Speichern
  </FormSubmitButton>
</form>

Erst wenn Anzeige-Logik nötig wird (Zeichenzähler, abhängige Felder, lokale Fehler, Vorschau, optimistische UI), wird das Formular zur "use client"- Komponente, bleibt aber beim Muster <form> + FormData + Server Action.

Form-Card

Abschnitt betitelt „Form-Card“
Veranstaltungsdetails
Titel * 24/80
KI-Safari Osnabrücker Land
Kurzbeschreibung (optional)
Eine Entdeckungsreise durch Künstliche Intelligenz für Unternehmer:innen und Führungskräfte.

Wird in Listenansicht und Kalender angezeigt.

Stammdaten speichern

Zentraler Container jedes Formulars: Header (Tropfen-Icon + Titel) plus Body mit Feldern. Die Header-Farbe folgt der Section-Farbe.

Section-Color in Formularen

Abschnitt betitelt „Section-Color in Formularen“
.section-red
Eingabe (fokussiert)
Speichern Primär / Stammdaten
.section-blue
Eingabe (fokussiert)
Speichern Dokumente, Veranstaltungsdetails
.section-amber
Eingabe (fokussiert)
Speichern Veröffentlichen, Speichern
.section-green
Eingabe (fokussiert)
Speichern Termine, Kalender
.section-purple
Eingabe (fokussiert)
Speichern Titelbild, Aufzeichnungen

section-*-Klasse am Container: Icon, Fokus-Ring und Submit erben die Farbe automatisch (siehe Abschnitte).

Submit-Buttons

Abschnitt betitelt „Submit-Buttons“
StufeStilEinsatz
Primär.section-submit, h-9, rounded-lg, font-semiboldHauptaktion, Farbe aus der Section
Sekundärgrauer Rahmen, weißer Grund, text-gray-600„Als Entwurf speichern”, „Abbrechen”
Tertiär (destruktiv)neutral, Hover in Section-Farbe + text-white„Entfernen” mit passendem Icon

Standardhöhe h-9, damit Buttons mit Inputs und Selects fluchten. In breiten Cards kompakt + rechtsbündig (flex justify-end), in schmalen Action-Cards w-full.

Validierung & Wording

Abschnitt betitelt „Validierung & Wording“

Fehlermeldungen beginnen mit „Bitte” und benennen das konkrete Feld, kein generisches „Pflichtfelder ausfüllen”:

SituationBeispiel
Feld fehlt„Bitte gib den Vornamen an.”
Mehrere Felder„Bitte gib den Vornamen und das Unternehmen an.”
Auswahl fehlt„Bitte wähle eine gültige Rolle aus.”
Format ungültig„Bitte gib eine gültige PLZ an (5 Ziffern).”

Pflichtfelder markiert <RequiredMark /> (text-primary), nicht text-red-500.

Meldungs-Banner

Abschnitt betitelt „Meldungs-Banner“

Statusmeldungen (Erfolg nach Redirect, Formularfehler, Info) sitzen als Banner am Kartenanfang oder -ende. Fehler-/Validierungsboxen sind der erlaubte semantische Rot-Kontext (bg-red-50 border-red-100 text-red-700), Warnungen entsprechend amber.

Barrierefreiheit

Abschnitt betitelt „Barrierefreiheit“

Querschnittsthema, nicht optional:

  • Fokus sichtbar: :focus-visible mit Ring in der Section-Farbe, nie outline: none ohne Ersatz.
  • Kontrast: solide Badge-/Button-Farben mit weißem Text, keine blassen Tieftöne als Standard.
  • Tastaturbedienung: alle interaktiven Elemente erreichbar. Popover-Selects (base-ui) bringen das Rollen-/Fokusverhalten mit, native <select> deshalb nicht nötig.
  • Bedeutung nicht nur über Farbe: Status zusätzlich über Text/Icon, nie allein über die Farbe.

Siehe auch

Abschnitt betitelt „Siehe auch“