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

Many of the stock GTK+ dialogs are action dialogs. The print dialog is a good example: it is displayed in response to the user using the print action, and presents information and options for that print action. The two header bar buttons allow the print action to either be cancelled or carried out.

# Präsentationsdialoge

Presentation dialogs present information or controls. Like action dialogs, they have a header bar and a subject. However, instead of prefixing an action, their content relates to an application or content item.

## Beispiele

Preferences and properties are both examples of presentation dialogs, and both present information and settings in relation to a specific entity (either an application or a content item). Properties dialogs are a good example of how dialogs can be used to disclose additional information which is not always needed in the main application window.

Resist the temptation to provide a preference window for your application. Always question whether additional settings are really necessary. Most people will not bother to investigate the preferences that you provide, and configuration options will contribute to the complexity of your application. Make an effort to ensure that your application design works for everybody without the need to change its settings.

## 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

Message and action dialogs include primary buttons which affect the whole window. The order of these buttons, as well as the labels used, are a key part of the dialog.

## Reihenfolge

When a dialog includes an affirmative and a cancel button, always ensure that the cancel button appears first, before the affirmative button. In left-to-right locales, this is on the left.

This button order ensures that users become aware of, and are reminded of, the ability to cancel prior to encountering the affirmative button.

## Beschriftungen

Label the affirmative primary button with a specific imperative verb, for example: Save, Print, Remove. This is clearer than a generic label like OK or Done.

Error dialogs typically include a single button which dismisses the dialog. In this case, a specific action does not need to be referenced, and this can be a good opportunity to use humor. Apology Accepted or Got It are both examples of good labels.

## Default action and escape

Assign the return key to activate the primary affirmative button in a dialog (for example Print in a print dialog). This is called the default action, and is indicated by a different visual style. Do not make a button the default if its action is irreversible, destructive or otherwise inconvenient to the user. If there is no appropriate button to designate as the default button, do not set one.

You should also ensure that the escape key activates the cancel or close button, should either of them be present. Message dialogs with a single button can have both escape and return bound to the button.

Binding return and escape in this way provides a predictable and convenient way to continue through a dialog, or to go back.

# Allgemeine Richtlinien

Dialog windows should never pop up unexpectedly, and should only ever be displayed in immediate response to a deliberate user action.

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