Overlay-und-Dialog-System

Overlay- und Dialog-System

Zweck

Die Fähigkeit „Overlay- und Dialog-System“ bietet eine Methodik zur Verwaltung temporärer Inhaltsebenen, die über der primären Benutzeroberfläche liegen. Sie stellt sicher, dass Unterbrechungen proportional zur Aufgabe des Benutzers sind, Kontext wo möglich erhalten bleibt und die Oberfläche bei Verwendung von Modalen, Drawern oder Popovern zugänglich und reaktionsfähig bleibt.

Anwendungsfälle

• Entwerfen eines Bestätigungsablaufs für eine destruktive Aktion (Modal).
• Erstellen eines sekundären Arbeitsbereichs zum Bearbeiten komplexer Details, ohne den Seitenkontext zu verlieren (Drawer).
• Implementieren kontextbezogener Hilfen oder Tooltips für bestimmte UI-Elemente (Popover).
• Entwerfen einer mobil-spezifischen Entdeckungsebene für Filter oder Suche (Drawer).

Wann NICHT verwenden

• Primäre Navigation: Verwenden Sie keine Overlays für die Hauptseitenstruktur; verwenden Sie stattdessen site-navigation-system.
• Permanente Inhalte: Wenn die Informationen für den Benutzer jederzeit sichtbar sein müssen, sollten sie Teil des Basis-Seitenlayouts sein, nicht eines Overlays.
• Komplexe mehrseitige Abläufe: Wenn eine Aufgabe mehr als 2-3 Schritte erfordert, sollten Sie eine eigene Seite in Betracht ziehen, anstatt ein Modal, um Desorientierung des Benutzers zu vermeiden.
• Toast/Snackbar-Benachrichtigungen: Für passives, nicht-blockierendes Status-Feedback (z. B. „Gespeichert“, „In die Zwischenablage kopiert“) verwenden Sie stattdessen toast-and-snackbar-system – es behandelt Positionierung, Stapelung, Dauer und Barrierefreiheit für diese Ebene ausführlich.

Eingaben

1. Inhaltsvolumen: Wie viele Informationen müssen angezeigt werden?
2. Unterbrechungsstufe: Muss der Benutzer diese Aufgabe zwingend abschließen, bevor er fortfahren kann, oder ist sie optional?
3. Auslösekontext: Woher kommt der Benutzer und was erwartet er?
4. Plattform/Viewport: Handelt es sich um Mobilgeräte, Desktop oder ein responsives Hybrid-Design?

Ausgaben

1. Musterauswahl: Eine klare Entscheidung zwischen Modal, Drawer oder Popover basierend auf der Unterbrechungsmatrix.
2. Anatomie-Spezifikation: Definierte Bereiche (Kopfzeile, Inhalt, Fußzeile/Aktionen) und deren interne Hierarchie.
3. Verhaltensspezifikation: Regeln für das Verhalten des Hintergrunds, Schließauslöser und responsive Anpassung.
4. Barrierefreiheitsanforderungen: Fokusverwaltung und Definition der ARIA-Rollen.

Arbeitsablauf

1. Kategorisierung nach Unterbrechungsstufe

Bestimmen Sie die erforderliche „Schwere“ des Overlays:

• Stufe 1 (Hoch): Modal. Deaktiviert den Hintergrund. Verwenden Sie es für kritische Entscheidungen oder fokussierte Aufgaben.
• Stufe 2 (Mittel): Drawer. Gleitet von der Kante herein. Verwenden Sie es für komplexe Unteraufgaben, die vom Einsehen des übergeordneten Kontexts profitieren.
• Stufe 3 (Niedrig): Popover. An einem bestimmten Element verankert. Verwenden Sie es für kontextbezogene Einstellungen oder Informationen.

Für passives, nicht-blockierendes Status-Feedback (Stufe 4) siehe toast-and-snackbar-system – es liegt außerhalb des Rahmens dieser Fähigkeit.

2. Definieren der internen Hierarchie (Anatomie)

Wenden Sie visual-hierarchy-system auf das Overlay an:

• Kopfzeile: Klarer Titel und ein konsistenter „Schließen“-Mechanismus (X-Button).
• Inhaltsbereich: Der primäre Inhaltsbereich. Bei langen Inhalten das Scrollverhalten definieren (fixierte Kopf-/Fußzeile).
• Fußzeile: Primäre und sekundäre Aktionen, konsistent ausgerichtet (normalerweise rechtsbündig auf dem Desktop, vollbreit auf Mobilgeräten).

3. Etablieren von Höhe und Hintergrund

• Z-Index-Strategie: Stellen Sie sicher, dass Overlays im richtigen Stapelkontext liegen. Bevorzugen Sie das native <dialog>-Element für Modale – es verwaltet seinen eigenen Top-Layer-Stapel, bietet das ::backdrop-Pseudo-Element für den Schleier und behandelt das Schließen mit der Escape-Taste nativ.
• Hintergrund (Schleier): Verwenden Sie ihn für Modale und Drawer, um den Hintergrund abzudunkeln und die Aufmerksamkeit zu fokussieren. Definieren Sie, ob ein Klick auf den Hintergrund das Overlay schließt. Bei <dialog> gestalten Sie den Schleier über ::backdrop anstelle eines manuell gerenderten <div>-Overlays.
• Hintergrund-Trägheit: Wenn ein Overlay geöffnet ist, muss der Rest der Seite nicht interaktiv und für assistive Technologien verborgen sein. <dialog>.showModal() erledigt dies automatisch; für benutzerdefinierte (Nicht-<dialog>) Overlays wenden Sie das inert-Attribut auf den Hintergrundinhalt an, anstatt sich allein auf aria-hidden zu verlassen.
• Schatten: Verwenden Sie Tiefe, um die Position des Overlays über der Basisebene anzuzeigen.

4. Entwurf für responsive Anpassung

Overlays müssen sich basierend auf der Bildschirmgröße transformieren:

• Desktop-Popover -> Mobil-Drawer: Kleine kontextbezogene Menüs werden auf Mobilgeräten oft zu unten ausgerichteten Drawern für bessere Daumenreichweite.
• Desktop-Modal -> Mobil-Vollbild: Große Modale sollten auf kleinen Bildschirmen den gesamten Viewport einnehmen, um den Platz zu maximieren.
• Drawer-Verhalten: Stellen Sie sicher, dass Drawer auf Mobilgeräten 90 % der Viewport-Breite nicht überschreiten.

5. Schließen- und Verlassen-Muster definieren

• Stellen Sie mindestens drei Möglichkeiten zum Verlassen eines nicht-kritischen Overlays bereit: „Schließen“-Schaltfläche, Escape-Taste und Klicken auf den Hintergrund.
• Für kritische (Warn-)Modale ist eine explizite Aktion erforderlich (z. B. „Abbrechen“ oder „Bestätigen“).

Entscheidungsregeln

• Die „Modal vs. Drawer“-Regel: Wenn der Benutzer während der Arbeit auf den Hintergrundinhalt Bezug nehmen muss, verwenden Sie einen Drawer. Wenn die Aufgabe ein „Stopp-und-Korrigieren“-Moment ist, verwenden Sie ein Modal.
• Die „Daumen“-Regel: Priorisieren Sie auf Mobilgeräten Bottom Drawers für Aktionen, um sie in der natürlichen Reichweite des Daumens zu halten.
• Die „Zwei-Schritte“-Regel: Wenn ein Overlay mehr als zwei interne „Ansichten“ oder Schritte erfordert, gehört es wahrscheinlich auf eine eigene Seite.
• Hintergrund-Logik: Erlauben Sie „Klicken außerhalb zum Schließen“ nur für nicht-destruktive Overlays. Niemals für Formulare, bei denen Daten verloren gehen könnten.

Einschränkungen

• Barrierefreiheit: Muss mit der Tastatur navigierbar sein. Modale müssen den Fokus einschließen (das native <dialog>-Element erledigt dies standardmäßig, wenn es über showModal() geöffnet wird). Hintergrundinhalte müssen mit inert (oder einem Äquivalent) versehen werden, sodass Screenreader- und Tastaturfokus nicht in sie entweichen können. Verwenden Sie role="dialog" oder role="alertdialog" mit aria-modal="true" und aria-labelledby-Verweis auf den Titel, wenn Sie das native Element nicht verwenden.
• Responsivität: Overlays dürfen niemals horizontales Scrollen verursachen. Der Inhalt im Inneren muss responsiv sein.
• Hierarchie: Das H1/der Titel des Overlays muss das markanteste Element innerhalb des Containers sein.

Häufige Fehlermuster

• Overlay-Suppe: Stapeln mehrerer Modale übereinander.
• Kontextverlust: Verwendung eines Modals, das genau die Informationen verdeckt, die der Benutzer zur Erledigung der Aufgabe benötigt.
• Das „Unsichtbare Schließen“: Verstecken des Schließen-Buttons oder zu klein machen für Touch (mind. 44x44px).
• Scroll-Konflikte: Ermöglichen des Scrollens der Hintergrundseite, während ein Overlay geöffnet ist (führt zu Desorientierung).
• Inkonsistente Aktionen: Vertauschen der Position von „Abbrechen“ und „Bestätigen“-Buttons in verschiedenen Overlays.

Validierungskriterien

• Das gewählte Muster (Modal/Drawer/Popover) entspricht der Unterbrechungsstufe der Aufgabe.
• Die interne Hierarchie ist klar mit einem deutlichen Titel und einer primären Aktion.
• Die responsive Anpassung (z. B. Popover zu Drawer) ist für Mobilgeräte definiert.
• Die Logik „Klicken außerhalb zum Schließen“ ist für das Datenrisiko angemessen.
• Fokusverwaltung und Tastatur-Barrierefreiheitsanforderungen sind spezifiziert.
• Die Höhe (Schatten/Hintergründe) unterscheidet die Ebene von der Basisseite.
• Hintergrundinhalte werden mit inert versehen (oder das native <dialog>-Element wird verwendet), wann immer ein Modal oder Drawer geöffnet ist.