UX-Patterns
[admin] [ux] [design-system]
Wiederkehrende UI-Patterns im Admin. Diese Seite hält fest, wie bestimmte Interaktionen einheitlich aussehen sollen — sowohl als Referenz für Tenants, die das Verhalten erwarten, als auch als Anker für die Weiterentwicklung.
Heute ein Pattern dokumentiert (Sticky-Save-Footer). Weitere folgen mit den jeweiligen Sprints.
Sticky-Save-Footer auf Form-Pages
Wo: Auf den meisten Form-Pages im Admin haftet der Save-Button am unteren Rand, wenn das Formular länger als der Viewport ist. So musst du nie nach unten scrollen, um zu speichern.
Visuell: Schmale weiße Leiste mit einer 1-Pixel-Trennlinie nach oben, Save-Button rechts (bei Edit-Forms zusätzlich ein Lösch-Button links). Bleibt am unteren Rand kleben bis das Formular-Ende erreicht ist.
Wo aktiv (Stand 2026-05-28, 9 Forms):
- Rechnungsstellung (
/settings/billing) - Account-Editor (Portal-Kunden-Settings)
- Produkt-Editor (
/products/[id]/edit) — mit Lösch-Button links - Produkt-Neu (
/products/new) - Branding (
/settings/branding) - E-Mail-Vorlagen (
/settings/emails) - Rechtstexte (
/settings/legal) - E-Mail-Benachrichtigungen (
/settings/advanced/notifications) - Kunden-Einladen (
/customers/new)
Bewusst NICHT aktiv (2 Forms):
- Widget-Einstellungen (
/settings/widget) — Save bezieht sich auf den oberen Konfig-Block. Darunter folgen Live-Vorschau, Embed-Code und Shopify-Guide als Read-Only-Hilfen. Ein Sticky-Footer würde diese dauerhaft verdecken. - Sprache & Region (
/settings/advanced/language) — gleiche Form-Architektur: Save oben für die Sprach-Konfig, darunter Status-Tags zu Landing-Page-Sprachen.
In beiden Fällen wäre der "Save am Form-Ende"-Refactor strukturell falsch, weil die Read-Only-Sections inhaltlich an die Konfiguration anschließen. Falls langfristig anders gewünscht, wäre das ein eigener UX-Refactor.
Warum dieses Pattern: Auf langen Form-Pages (BillingForm ~120 Felder, EditProductForm 4 Tabs mit ~50 Feldern) war das Auffinden des Save-Buttons ein häufiger Schmerzpunkt. Sticky-Footer löst das ohne Layout-Bruch — Pattern ist additiv, ändert keine bestehenden Buttons.
Geschichte: Foundation in BillingForm (2026-05-15). Cleanup-Sprint Phase 3 (2026-05-27 → 2026-05-28) hat das Pattern auf 7 weitere Forms ausgerollt.