Dialogfenster

Überblick Visual Style Guide

Dialogfenster

Auf dieser Seite... (ausblenden)

  1.   1.  Modale und nicht-modale Dialogfenster
  2.   2.  Popup-Fenster
  3.   3.  Allgemeines
  4.   4.  Eigenschaften
  5.   5.  Verhalten
    1.   5.1  Schematischer Aufbau eines Dialogfensters
    2.   5.2  Layout/Design
    3.   5.3  Text in der Titelleiste
    4.   5.4  Buttons
  6.   6.  Sicherheitsabfragen

Dialoge werden verwendet um Eingaben oder Bestätigungen vom Benutzer einzuholen. Seit der Einführung der Siebar gelten Dialoge auch grundsätzlich als Repräsentation von Aktionen. Aktionen verbleiben dabei auf der jeweiligen Seite und vermeiden einen Kontextwechsel

Trotzdem sollten Dialoge nicht inflationär eingesetzt werden. Wenn möglich sollte eine Interaktion direkt auf der Seite stattfinden, auf der auch die zu bearbeitenden Informationen oder Elemente dargestellt werden.

1.  Modale und nicht-modale Dialogfenster

Bei modalen Dialogfenstern kann der Benutzer nicht in anderen Fenstern der Anwendung weiterarbeiten, sondern nur im Dialogfenster. Im Unterschied dazu erlauben nicht-modale Dialogfenster dem Benutzer auch die Interaktion mit dem Hintergrundfenster. Nicht-modale Dialogfenster werden in Stud.IP beispielsweise beim Stundenplan zur Eingabe von Terminen verwendet. Die Mehrzahl der Dialoge in Stud.IP ist jedoch modal.

Beim Aufruf eines modalen Dialogfensters wird das Hintergrundfenster durch geeignete optische Manipulation ("Ausgrauen" bzw. abdunkeln mit einem Overlay in Dunkelblau) als inaktiv gekennzeichnet.

Dialoge sind abzugrenzen von Notifications, die nie modal sind und nicht als eigenes Fenster erscheinen.

2.  Popup-Fenster

Popup-Fenster, d. h. sich separat öffnende Fenster, dürfen nicht verwendet werden.

3.  Allgemeines

Dialoge sollten einfach gehalten und nicht zu komplex sein, d. h. nur eine zugehörige Aktion sollte pro Dialog ausgeführt werden.

Dialoge sollten selbst erklärend sein und möglichst wenig (Erklärungs-) Texte enthalten.

Dialoge sollten nicht gestapelt werden, d. h. ein Dialog sollte sich nicht in einem Dialog öffnen (außer z . B. Datepicker, wo kein Button gedrückt werden muss). Für komplexere Dialoge sollten Wizards verwendet werden, in dene mehrere Dialoge hintereinander geschaltet sind oder Bereich innerhalb der Dialoge auf- und zugeklappt werden.

4.  Eigenschaften

Dialogfenster sind meist formularartig aufgebaut.

Dialoge sollten lesbar sein, ohne dass ein Scrollen im Dialog erforderlich wird. Eine Ausnahme bildet das vertikale Scrollen: Wenn es sich nicht vermeiden lässt (etwa weil Inhalte, lange Listen oder Aufklappelemente nicht das Dialogfenster passen) darf innerhalb des Dialogfensters gescrollt werden.

Die Seitengröße innerhalb eines Dialogfensters sollte sich während seiner Bearbeitung nicht ändern. Ausgenommen von dieser Einschränkung ist beispielsweise das dynamische Nachladen von Elementen einer Drop-Down-Liste oder das dynamische Einblenden von Ausfüllhinweisen bei Pflichtfeldern.

5.  Verhalten

Wenn man neben ein Dialogfester klickt, sollte sich dieses nicht schließen.

Wenn der Benutzer den Button Escape drückt, schließt sich das Dialogfenster, es sei denn, es wurden bereits Eingaben gemacht. Hier muss der Auto-Formsaver aktiviert werden, so dass der Nutzer auf eventuelle verlorengehende Inhalte hingewiesen wird.

5.1  Schematischer Aufbau eines Dialogfensters

5.2  Layout/Design

Grundsätzlich sind Dialoge gestalterisch so aufgebaut, dass sie von einer dunkelblauen Kopfzeile (Stud.IP-Brand-Color, siehe DesignFarbe) eingeleitet werden und einen weißen Hintergrund haben. Sie haben einen dünnen weißen Rand, einen leichten Schatten und dunkeln die dahinterliegende Seite ab. Buttons haben einen separaten Footer, analog zu Tabellen oder Formularen.

Beispiel für das Design:

Design-Vorschlag vom CSS Workshop in Bremen:

5.3  Text in der Titelleiste

Der Titeltext sollte aussagekräftig und spezifisch sein, damit Benutzer genau wissen, was sie tun sollen. Eine Dopplung zum Content muss vermeiden werden.

5.4  Buttons

Jeder Dialog ein X-Icon rechts in der Titelleiste, um den Dialog schließen zu können. Zusätzlich gibt es einen separaten "Abbrechen"/"Schließen"-Button, da viele Benutzer das x-Icon in der Titelleiste übersehen.

Auf dem Übernehmen-Button (accept-Button) wird ein Häkchen-Icon angezeigt.

Der Text auf dem Übernehmen-Button sollte ein spezifisches Verb sein wie beispielsweise "Löschen" oder "Anlegen" und nicht nur "OK".

6.  Sicherheitsabfragen

Sicherheitsabfragen werden verwendet insbesondere beim Löschen wichtiger Elemente oder bei anderen kritischen und unwiderruflichen Aktionen.

Sicherheitsabfrage sind eine vereinfachte Form des modalen Dialogs.

Sie enthalten einen Hinweis- oder Fragetext und zwei Buttons zum Bestätigen und Verwerfen.

Für Sicherheitsabfragen darf kein JavaScript Alert verwendet werden, da dieser auf jeden Betriebssystem anders aussieht.


JavaScript Alert unter Linux

Letzte Änderung am June 23, 2017, at 04:01 PM von ckater.