Sekundäre Fenster, die über primären, übergeordneten Fenstern erscheinen
Allan Day
aday@gnome.org
Calum Benson
Adam Elman
Seth Nickell
Colin Robertson
Christian Kirbach
christian.kirbach@gmail.com 2014
Mario Blättermann
mario.blaettermann@gmail.com 2016

# Dialogfenster

Dialoge sind sekundäre Fenster, die über einem primären, übergeordneten Fenster angezeigt werden. Sie stellen zusätzliche Informationen oder Bedienelemente dar, wie Einstellungen und Eigenschaften, oder zeigen Meldungen oder Fragen an.

GTK liefert bereits eine Anzahl vorgefertigter Dialoge mit, die Sie verwenden können, wie beispielsweise zum Drucken oder zur Farbauswahl.

Es gibt drei grundlegende Typen von Dialogen.

# Anwendungsfälle

Dialoge sind ein häufig verwendetes Designmuster. Es gibt etablierte Konventionen für den Einsatz der verschiedenen Dialogtypen, die Sie verwenden können. Die Richtlinien zu jedem der Typen vermitteln weitere Informationen hierzu.

Während Dialoge einerseits eine effektive Möglichkeit bieten, zusätzliche Bedienelemente oder Informationen bereitzustellen, können Sie beim Benutzer andererseits Unterbrechungen des Arbeitsablaufs verursachen. Stellen Sie sich deshalb immer die Frage, ob ein Dialog erforderlich ist, und versuchen Sie solche Situationen zu vermeiden.

Es gibt viele Wege, Dialoge zu vermeiden:

Ordnen Sie neue Nachrichten, Kontakte und Ähnliches eingebettet an.

Eingebettete Benachrichtigungen sind eine Alternative zu Meldungsdialogen.

Einblenddialoge können zusätzliche Bedienelemente oder Optionen auf eine weniger unterbrechende Weise anzeigen.

# Meldungsdialoge

Meldungsdialoge sind der einfachste Dialogtyp. Es werden Meldungen oder Fragen angezeigt sowie 1 bis 3 Knöpfe, über die der Benutzer antworten kann. Sie sind stets modal, was bedeutet, dass der Zugriff auf das übergeordnete Fenster durch sie verhindert wird. Meldungsdialoge sind eine gute Wahl, wenn es darum geht, dass dem Benutzer eine Meldung angezeigt und eine Antwort angefordert wird.

## Beispiele

Bestätigungsdialoge verwenden oft einen Meldungsdialog, um zu prüfen (oder bestätigen zu lassen), dass der Benutzer eine Aktion ausführen will. Sie enthalten zwei Knöpfe, einen zum tatsächlichen Ausführen und einen zum Abbrechen der Aktion.

Bestätigungsdialoge werden oft unabsichtlich oder automatisch »abgenickt«, wodurch Fehler nicht immer vermieden werden. Oft ist es besser, eine Routine zum Zurücknehmen von Aktionen anzubieten.

Fehlerdialoge zeigen dem Benutzer eine Fehlermeldung an. Sie enthalten oft einen einzelnen Knopf, mit dem der Benutzer bestätigt, dass er die Fehlermeldung gelesen hat und den Dialog schließen kann.

Fehlerdialoge sollten generell der letzte Ausweg sein. Sie sollten Ihre Anwendung so gestalten, dass keine Fehler auftreten und dafür sorgen, dass eine automatische Wiederherstellung möglich ist, wenn dennoch etwas schiefgeht.

# Aktionsdialoge

Aktionsdialoge stellen Optionen und Informationen zu einer spezifischen Aktion bereit, bevor diese ausgeführt wird. Sie haben eine Überschrift (die typischerweise die Aktion beschreibt) und zwei primäre Knöpfe – einen zum Ausführen und einen zum Abbrechen der Aktion.

Gelegentlich ist es notwendig, dass der Benutzer Optionen auswählen soll, bevor eine Aktion ausgeführt wird. In diesen Fällen sollte der bestätigende Dialogknopf ausgegraut werden, bis die benötigten Optionen ausgewählt wurden.

## Beispiele

Viele der vorgefertigten GTK-Dialoge sind Aktionsdialoge. Der Druckdialog ist dafür ein gutes Beispiel: Er erscheint als Reaktion darauf, wenn der Benutzer die Drucken-Aktion anstößt und zeigt Informationen und Optionen zu dieser Aktion an. Mit den zwei Knöpfen in der Kopfleiste kann der Druckvorgang entweder gestartet oder abgebrochen werden.

# Präsentationsdialoge

Präsentationsdialoge stellen Informationen oder Bedienmöglichkeiten bereit. Wie Aktionsdialoge haben sie eine Kopfleiste und ein ??? Jedoch anstelle eine Aktion vorzubereiten, bezieht sich ihr Inhalt auf eine Anwendung oder ein Inhaltselement.

## Beispiele

Einstellungen und Eigenschaften sind Beispiele für Präsentationsdialoge. Beide stellen Informationen und Einstellungen in Relation zu einer spezifischen Entität dar (entweder eine Anwendung oder ein Inhaltsobjekt). Eigenschaftsdialoge sind ein gutes Beispiel dafür, wie Dialoge zur Auslagerung von Informationen verwendet werden können, die im Hauptfenster der Anwendung nicht permanent gebraucht werden.

Widerstehen Sie der Versuchung, ein Einstellungsfenster für Ihre Anwendung bereitzustellen. Fragen Sie sich stets, ob zusätzliche Einstellungen überhaupt notwendig sind. Die meisten Benutzer bemühen sich nicht damit, die möglichen Einstellungen herauszufinden, außerdem machen Konfigurationsoptionen Ihre Anwendung komplizierter. Versuchen Sie, Ihr Anwendungsdesign so zu gestalten, dass jeder ohne Änderungen der Einstellungen damit arbeiten kann.

## Unmittelbares und ausdrückliches Anwenden

Presentation dialogs are either instant or explicit apply. In instant apply dialogs, changes to settings or values are immediately updated. In contrast, explicit apply dialogs include a button for applying changes.

Instant apply should be used wherever possible. Instant apply presentation dialogs have a close button in their header bar, like a primary window.

Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour. Explicit apply dialogs include a Done and Cancel button (Cancel resets all values in the dialog to the state before it was opened and Done applies all changes and closes the window).

# Primäre Knöpfe

Meldungs- und Aktionsdialoge beinhalten primäre Knöpfe, die sich auf das gesamte Fenster auswirken. Die Anordnung der Knöpfe und deren Beschriftung nehmen innerhalb des Dialoges eine Schlüsselstellung ein.

## Reihenfolge

Wenn ein Dialog einen Knopf zum Bestätigen und einen zum Abbruch enthält, platzieren Sie den Abbrechen-Knopf stets vor dem Bestätigen-Knopf. Bei Spracheinstellungen mit Schreibweise von links nach rechts ist dies die linke Seite.

Diese Reihenfolge stellt sicher, dass dem Benutzer zuerst die Möglichkeit zum Abbruch signalisiert wird und danach erst die Möglichkeit zum Bestätigen der Aktion.

## Beschriftungen

Beschriften Sie den bestätigenden Knopf mit einem spezifischen imperativen Verb, zum Beispiel Save, Print oder Remove. Dies ist klarer verständlich als eine allgemeine Beschriftung wie OK oder Done.

Fehlerdialoge beinhalten typischerweise einen einzelnen Knopf, der den Dialog schließt. In diesem Fall braucht keine spezifische Aktion referenziert zu werden, und eine Prise Humor kann hier auch nicht schaden. Apology Accepted oder Got It sind Beispiele für passende Beschriftungen.

## Vorgabeaktion und Abbruch

Weisen Sie die Eingabetaste dem primären Bestätigungsknopf in einem Dialog zu (zum Beispiel Print in einem Druckdialog). Diese ist dann die Standardaktion, die durch einen anderen visuellen Stil kenntlich gemacht wird. Legen Sie keinen Knopf als Standardknopf fest, dessen Aktion irreversibel, destruktiv oder in anderer Form unbequem für den Benutzer ist. Gibt es keinen passenden Knopf, dessen Aktion sich als Standardaktion eignet, sollten Sie keinen dafür festlegen.

Sie sollten auch sicherstellen, dass die Escape-Taste den Cancel- oder Close-Knopf aktiviert, sofern einer davon vorhanden ist. In Meldungsdialogen mit einem einzelnen Knopf kann diesem sowohl die Escape- als auch die Eingabetaste zugeordnet werden.

Die Bindung der Eingabe- und Escape-Taste auf diese Weise stellt einen voraussehbaren und bequemen Weg zur weiteren Navigation durch einen Dialog dar oder zurück zu gehen.

# Allgemeine Richtlinien

Dialogfenster sollten niemals unerwartet geöffnet werden und wirklich nur als unmittelbare Reaktion auf eine absichtliche Aktion des Benutzers erscheinen.

Dialogfenster sollten stets ein Elternfenster haben.

Folgen Sie beim Entwurf von Fensterinhalten den Layout-Richtlinien.

Use view switchers or tabs to break up controls and information.

Vermeiden Sie die Stapelung von Dialogfenstern. Niemals sollten mehrere Dialogfenster gleichzeitig angezeigt werden.

Setzen Sie beim Öffnen eines Dialoges den anfänglichen Tastaturfokus auf jenes Element, von dem Sie erwarten, dass die Benutzer es zuerst benötigen. Dieser Fokus ist insbesondere für jene Benutzer von Bedeutung, die beim Navigieren durch Ihre Anwendung auf die ausschließliche Verwendung der Tastatur angewiesen sind.

# API-Referenz

GtkAboutDialog

GtkDialog

GtkMessageDialog