Windows 7: Dialogfelder (Entwurfsgrundlagen)

Hinweis

Dieses Designhandbuch wurde für Windows 7 erstellt und wurde für neuere Versionen von Windows nicht aktualisiert. Ein Großteil der Anleitungen gilt immer noch grundsätzlich, aber die Präsentation und Beispiele spiegeln nicht unsere aktuelle Designanleitung wider.

Ein Dialogfeld ist ein sekundäres Fenster, in dem Benutzer*innen einen Befehl ausführen können, ihnen eine Frage gestellt wird oder sie Informationen oder Statusfeedback erhalten.

Ein typisches Dialogfeld.

Dialogfelder bestehen aus einer Titelleiste (um den Befehl, das Feature oder das Programm zu identifizieren, von dem ein Dialogfeld stammt), einer optionalen Hauptanweisung (um den Zweck des Dialogfelds zu erläutern), verschiedenen Steuerelementen im Inhaltsbereich (um Optionen bereitzustellen) und aus Commitschaltflächen (um anzugeben, wie Benutzer*innen die Aufgabe ausführen möchten).

Es gibt zwei grundlegende Arten von Dialogfeldern:

• Bei modalen Dialogfeldern müssen Benutzer*innen einen Vorgang abschließen und das Dialogfeld schließen, bevor es im Besitzerfenster weitergeht. Diese Dialogfelder eignen sich am besten für kritische oder seltene einmalige Vorgänge, die abgeschlossen werden müssen, damit es weitergeht.
• Bei nicht modalen Dialogfeldern können Benutzer*innen nach Bedarf zwischen dem Dialogfeld und dem Besitzerfenster wechseln. Diese Dialogfelder eignen sich am besten für häufige, sich wiederholende und laufende Aufgaben.

Ein Aufgabendialogfeld ist ein Dialogfeld, das mithilfe der Anwendungsprogrammierschnittstelle (Application Programming Interface, API) „Aufgabendialogfeld“ implementiert wird. Es setzt sich aus folgenden Komponenten zusammen, die auf verschiedene Arten miteinander kombiniert werden können:

• Eine Titelleiste, um die Anwendung oder das Systemfeature zu identifizieren, von der bzw. von dem das Dialogfeld stammt.
• Eine Hauptanweisung mit einem optionalen Symbol, um den Zweck des Dialogfelds zu identifizieren.
• Ein Inhaltsbereich für beschreibende Informationen und Steuerelemente.
• Ein Befehlsbereich für Commitschaltflächen – einschließlich einer Schaltfläche zum Abbrechen und optionalen Steuerelementen für weitere Optionen sowie zum Angeben, dass dieses <Element> nicht erneut angezeigt werden soll.
• Ein Fußnotenbereich für optionale zusätzliche Erklärungen und Hilfe (in der Regel für weniger erfahrene Benutzer*innen).

Ein typisches Aufgabendialogfeld.

Aufgabendialogfelder werden empfohlen, da sie einfach zu erstellen sind und eine einheitliche Optik bieten. Da für Aufgabendialogfelder mindestens Windows Vista erforderlich ist, sind sie für frühere Versionen von Microsoft Windows nicht geeignet.

Ein Aufgabenbereich ist wie ein Dialogfeld, wird aber nicht in einem separaten Fenster, sondern in einem Fensterbereich angezeigt. Daher vermitteln Aufgabenbereiche einen direkteren, kontextbezogenen Eindruck als Dialogfelder. Aufgabenbereiche und Dialogfelder sind sich trotz gewisser Unterschiede so ähnlich, dass ihre Richtlinien in diesem Artikel beschrieben werden.

Ein typischer Aufgabenbereich.

Eigenschaftenfenster sind ein spezieller Dialogfeldtyp zum Anzeigen und Ändern von Eigenschaften für ein Objekt, für eine Sammlung von Objekten oder für ein Programm. Darüber hinaus unterstützen Eigenschaftenfenster in der Regel mehrere Aufgaben, während Dialogfelder in der Regel eine einzelne Aufgabe oder einen einzelnen Schritt in einer Aufgabe unterstützen. Aufgrund ihrer spezialisierten Verwendung gelten für Eigenschaftsfenster andere Richtlinien.

Dialogfelder können Registerkarten enthalten und werden dann Dialogfelder mit Registerkarten genannt. Bei Eigenschaftenfenstern ist die Darstellung von Eigenschaften ausschlaggebend, nicht die Verwendung von Registerkarten.

Hinweis: Richtlinien für Layout, Fensterverwaltung, allgemeine Dialogfelder, Eigenschaftenfenster, Assistenten, Bestätigungen, Fehlermeldungen und Warnmeldungen werden in separaten Artikeln behandelt.

Ist das die passende Benutzeroberfläche?

Orientieren Sie sich an folgenden Fragen:

• Besteht der Zweck darin, Benutzer*innen Informationen zu liefern, ihnen eine Frage zu stellen oder ihnen auswählbare Optionen für die Ausführung eines Befehls oder einer Aufgabe zur Verfügung zu stellen? Falls nicht, verwenden Sie eine andere Benutzeroberfläche (User Interface, UI).
• Besteht der Zweck darin, Eigenschaften für ein Objekt, für eine Sammlung von Objekten oder für ein Programm anzuzeigen und zu ändern? Falls ja, verwenden Sie stattdessen ein Eigenschaftenfenster oder eine Symbolleiste.
• Soll eine Sammlung von Befehlen oder Tools bereitgestellt werden? Falls ja, verwenden Sie eine Symbolleiste oder ein Palettenfenster.
• Soll überprüft werden, ob Benutzer*innen mit einer Aktion fortfahren möchten? Gibt es einen klaren Grund, den Vorgang nicht fortzusetzen, und ist davon auszugehen, dass Benutzer*innen den Vorgang manchmal nicht fortsetzen möchten? Falls ja, verwenden Sie eine Bestätigung.
• Soll eine Fehler- oder Warnmeldung ausgegeben werden? Falls ja, verwenden Sie eine Fehlermeldung oder eine Warnmeldung.
• Liegt einer der folgenden Zwecke vor:
  • Öffnen von Dateien
  • Speichern von Dateien
  • Öffnen von Ordnern
  • Suchen oder Ersetzen von Text
  • Drucken eines Dokuments
  • Auswählen von Attributen einer gedruckten Seite
  • Auswählen einer Schriftart
  • Auswählen einer Farbe
  • Suchen nach einer Datei, einem Ordner, einem Computer oder einem Drucker
  • Suchen nach Benutzer*innen, Computern oder Gruppen in Microsoft Active Directory
  • Auffordern zur Eingabe eines Benutzernamens und eines Kennworts

Verwenden Sie stattdessen das entsprechende allgemeine Dialogfeld. Viele dieser allgemeinen Dialogfelder sind erweiterbar.

• Besteht der Zweck darin, eine mehrstufige Aufgabe auszuführen, die mehrere Fenster erfordert? Falls ja, verwenden Sie stattdessen einen Aufgabenfluss oder einen Assistenten.
• Besteht der Zweck darin, Benutzer*innen über ein System- oder Programmereignis zu informieren, das nicht mit der aktuellen Benutzeraktivität in Verbindung steht, keine sofortige Benutzeraktion erfordert und problemlos ignoriert werden kann? Falls ja, verwenden Sie stattdessen eine Benachrichtigung.
• Soll ein Programmstatus angezeigt werden? Falls ja, verwenden Sie stattdessen eine Statusleiste.
• Wäre eine direkte Benutzeroberfläche vorzuziehen? Dialogfelder erfordern die Aufmerksamkeit von Benutzer*innen und können ihre Arbeit unterbrechen. Manchmal ist diese Unterbrechung gerechtfertigt – beispielsweise, wenn Benutzer*innen eine Aktion ausführen müssen, die sich außerhalb des aktuellen Kontexts befindet. In anderen Fällen ist es besser, die Benutzeroberfläche innerhalb des Kontexts anzuzeigen – entweder mithilfe einer direkten Benutzeroberfläche (z. B. einem Aufgabenbereich) oder bei Bedarf mithilfe einer schrittweisen Anzeige.
• Soll ein nicht kritisches Benutzereingabeproblem oder eine spezielle Bedingung angezeigt werden? Falls ja, verwenden Sie stattdessen eine Sprechblase.
• Wäre bei Aufgabenflüssen die Verwendung einer weiteren Seite vorzuziehen? Grundsätzlich empfiehlt es sich, bei einer Aufgabe nacheinander mehrere Seiten innerhalb eines einzelnen Fensters zu durchlaufen. Verwenden Sie Dialogfelder, um direkte Befehle zu bestätigen, um Eingaben für direkte Befehle anzufordern und um sekundäre, eigenständige Aufgaben auszuführen, die am besten unabhängig und außerhalb des Hauptaufgabenflusses ausgeführt werden.
• Wenn Optionen zur Auswahl stehen: Ist es wahrscheinlich, dass Benutzer*innen die Optionen ändern? Falls nicht, ziehen Sie ggf. Alternativen in Betracht:
  • Verwenden der Standardoptionen ohne Nachfrage, aber mit der Möglichkeit, sie später zu ändern
  • Bereitstellen einer Version mit Optionen (z. B. Drucken... in einem Menü) sowie einer Version ohne Optionen (z. B. Drucken auf der Symbolleiste). Im Allgemeinen sollten Symbolleistenbefehle direkt ausgeführt werden und kein Dialogfeld auslösen.
• Gibt es für die Auswahl von Optionen eine einfachere, direktere Darstellungsform der Optionen? Falls ja, ziehen Sie ggf. Alternativen in Betracht:
  • Verwenden einer unterteilten Schaltfläche zum Auswählen von Befehlsvarianten
  • Verwenden eines Untermenüs für Befehle, Kontrollkästchen, Optionsfelder und einfache Listen

In diesen Beispielen werden anstelle von Dialogfeldern Untermenüs für einfache Auswahlvorgänge verwendet.

Entwurfskonzepte

Ordnungsgemäß verwendete Dialogfelder machen ein Programm leistungsfähig und flexibel. Bei nicht ordnungsgemäßer Verwendung können Dialogfelder Benutzer*innen sehr leicht verärgern, ihr Arbeit unterbrechen und dazu führen, dass sich die Verwendung des Programms indirekt und mühsam anfühlt. Modale Dialogfelder erfordern die Aufmerksamkeit von Benutzer*innen. Dialogfelder sind häufig einfacher zu implementieren als alternative Benutzeroberflächen und werden daher oftmals zu häufig verwendet.

Ein Dialogfeld ist am effektivsten, wenn seine Designmerkmale seiner Verwendung entsprechen. Das Design eines Dialogfelds wird größtenteils durch seinen Zweck (Anbieten von Optionen, Stellen von Fragen, Bereitstellen von Informationen oder Feedback), durch seinen Typ (modal oder nicht modal) und durch seine Benutzerinteraktion (erforderlich, optionale Antwort oder Bestätigung) bestimmt. Die Verwendung hängt dagegen in erster Linie vom Kontext (benutzerseitig oder programmseitig initiiert), von der Wahrscheinlichkeit einer Benutzeraktion und von der Häufigkeit der Anzeige ab.

Setzen Sie die folgenden Elemente wirksam ein, um effektive Dialogfelder zu gestalten:

• Dialogfeldtext
• Hauptanweisungen
• Option „Dieses <Element> nicht mehr anzeigen“

Wichtigster Punkt

Achten Sie darauf, dass das Design des Dialogfelds (bestimmt durch den Zweck, den Typ und die Benutzerinteraktion) zur Verwendung des Dialogfelds (bestimmt durch den Kontext, die Wahrscheinlichkeit einer Benutzeraktion und die Häufigkeit der Anzeige) passt.

Verwendungsmuster

Dialogfelder weisen mehrere Verwendungsmuster auf:

• Fragedialogfelder (mit Schaltflächen) stellen Benutzer*innen eine einzelne Frage oder fordern sie auf, einen Befehl zu bestätigen. Sie verwenden einfache Antworten in horizontal angeordneten Befehlsschaltflächen.
• Fragedialogfelder (mit Befehlslinks) stellen Benutzer*innen eine einzelne Frage oder fordern sie auf, eine auszuführende Aufgabe auszuwählen. Sie verwenden detaillierte Antworten in vertikal angeordneten Befehlslinks.
• Auswahldialogfelder bieten Benutzer*innen eine Reihe von Optionen an, die in der Regel zur vollständigeren Angabe eines Befehls dienen. Anders als bei Fragedialogfeldern können in Auswahldialogfeldern mehrere Fragen gestellt werden.
• In Statusdialogfeldern wird Benutzer*innen während eines längeren Vorgangs (länger als fünf Sekunden) Statusfeedback angezeigt. Außerdem steht ein Befehl zum Abbrechen oder Beenden des Vorgangs zur Verfügung.
• In Informationsdialogfeldern werden Informationen angezeigt, die der Benutzer bzw. die Benutzerin angefordert hat.

Richtlinien

Allgemein

• Verwenden Sie keine scrollbaren Dialogfelder. Verwenden Sie keine Dialogfelder, die die Verwendung einer Scrollleiste erfordern, damit der Inhalt bei normaler Nutzung vollständig angezeigt werden kann. Gestalten Sie stattdessen das Dialogfeld um. Mögliche Optionen sind beispielsweise eine schrittweise Anzeige oder Registerkarten.

• Verwenden Sie keine Menü- oder Statusleiste. Ermöglichen Sie stattdessen den Zugriff auf Befehle und den Status direkt im Dialogfeld selbst oder über Kontextmenüs für die relevanten Steuerelemente.

  • Ausnahme: Menüleisten sind akzeptabel, wenn ein Dialogfeld dazu dient, ein primäres Fenster (z. B. ein Hilfsprogramm) zu implementieren.

  Falsch:

  

  In diesem Beispiel ist „Find Certificates“ (Zertifikate suchen) ein nicht modales Dialogfeld mit einer Menüleiste.

• Wenn ein Dialogfeld sofortige Aufmerksamkeit erfordert und das Programm nicht aktiv ist, lassen Sie die Taskleistenschaltfläche des Programms dreimal aufblinken, um auf das Programm aufmerksam zu machen, und lassen Sie die Schaltfläche anschließend hervorgehoben. Führen Sie keine weitere Aktion aus. Also stellen Sie das Fenster nicht wieder her, aktivieren Sie es nicht, und geben Sie keine Soundeffekte wieder. Respektieren Sie stattdessen die Auswahl des Fensterzustands des Benutzers bzw. der Benutzerin, und lassen Sie ihn bzw. sie das Fenster bei Bedarf aktivieren.

• Weitere Richtlinien und Beispiele finden Sie unter Taskleiste.

Modale Dialogfelder

• Verwenden Sie diese Dialogfelder für kritische oder seltene einmalige Vorgänge, die abgeschlossen werden müssen, damit es weitergeht.
• Verwenden Sie ein verzögertes Commitmodell, damit Änderungen erst wirksam werden, wenn sie explizit committet wurden.
• Implementieren Sie möglichst ein Aufgabendialogfeld, um ein einheitliches Aussehen zu erzielen. Da für Aufgabendialogfelder mindestens Windows Vista erforderlich ist, sind sie für frühere Versionen von Windows nicht geeignet.

Nicht modale Dialogfelder

• Verwenden Sie diese Dialogfelder für häufige, sich wiederholende und laufende Aufgaben.
• Verwenden Sie ein direktes Commitmodell, damit Änderungen sofort wirksam werden.
• Verwenden Sie bei nicht modalen Dialogfeldern eine explizite Befehlsschaltfläche vom Typ „Schließen“ im Dialogfeld, um das Fenster zu schließen. Verwenden Sie für beide eine Schaltfläche vom Typ „Schließen“ auf der Titelleiste, um das Fenster zu schließen.
• Es empfiehlt sich gegebenenfalls, nicht modale Dialogfelder andockbar zu machen. Andockbare Dialogfelder ermöglichen eine flexiblere Platzierung.

Einige nicht modale Dialogfelder in Microsoft Office sind andockbar.

Mehrere Dialogfelder

• Zeigen Sie in einem Besitzerauswahldialogfeld nicht mehrere zugehörige Auswahldialogfelder an. Andernfalls ist es für Benutzer*innen schwierig, die Bedeutung der Commitschaltflächen zu verstehen. Zeigen Sie bei Bedarf andere Dialogfeldtypen (z. B. Fragedialogfelder) an.
• Verwenden Sie bei einer Abfolge verwandter Dialogfelder nach Möglichkeit ein mehrseitiges Dialogfeld. Verwenden Sie einzelne Dialogfelder, wenn sie nicht eindeutig zusammenhängen.

Dialogfelder mit mehreren Seiten

• Verwenden Sie anstelle einzelner Dialogfelder ein mehrseitiges Dialogfeld, wenn Sie über die folgende Abfolge verwandter Seiten verfügen:
  • Eine einzelne Eingabeseite (optional)
  • Eine Statusseite
  • Eine einzelne Ergebnisseite

Die Eingabeseite ist optional, da es sein kann, dass die Aufgabe an einer anderen Stelle initiiert wurde. Dadurch wirkt die Umgebung stabil, unkompliziert und nicht überfrachtet.

In diesem Beispiel setzt sich die Windows-Netzwerkdiagnose aus Status- und Ergebnisseiten zusammen.

• Verwenden Sie kein mehrseitiges Dialogfeld, wenn die Eingabeseite ein Standarddialogfeld ist. In diesem Fall ist einheitliche Verwendung eines Standarddialogfelds wichtiger.
• Verwenden Sie maximal drei Seiten und keine Weiter- oder Zurück-Schaltflächen. Dialogfelder mit mehreren Seiten sind für Aufgaben mit einzelnen Schritten und Feedback vorgesehen. Sie sind keine Assistenten für mehrstufige Aufgaben. Im Gegensatz zu mehrseitigen Dialogfeldern vermitteln Assistenten einen schwerfälligen, indirekten Eindruck.
• Verwenden Sie auf der Eingabeseite spezifische Befehlsschaltflächen oder -links, um die Aufgabe zu initiieren.
• Verwenden Sie auf den Eingabe- und Fortschrittsseiten eine Schaltfläche vom Typ „Abbrechen“ und auf der Ergebnisseite eine Schaltfläche vom Typ „Schließen“.

Entwickler*innen: Sie können die Nachricht TDM_NAVIGATE_PAGE verwenden, um mehrseitige Aufgabendialogfelder zu erstellen.

Präsentation

Damit Dialogfelder leicht zu finden sind und mühelos verwendet werden können, empfiehlt es sich, das Dialogfeld eindeutig seiner Quelle zuzuordnen und dafür zu sorgen, dass es problemlos mit mehreren Monitoren funktioniert:

• Zeigen Sie Dialogfelder zunächst mittig im Vordergrund des Besitzerfensters an. Bei der nächsten Anzeige empfiehlt es sich, das Dialogfeld an seiner letzten Position (relativ zum Besitzerfenster) anzuzeigen, wenn dies wahrscheinlich praktischer ist.

Zeigen Sie Dialogfelder zunächst mittig im Vordergrund des Besitzerfensters an.

• Kontextbezogene Dialogfelder sollten in der Nähe des Objekts angezeigt werden, über das sie gestartet wurden. Platzieren Sie sie jedoch so, dass das Objekt nicht durch das Dialogfeld verdeckt wird (vorzugsweise nach rechts unten versetzt).

Die Eigenschaften eines Objekts werden in der Nähe des Objekts angezeigt.

• Zeigen Sie nicht modale Dialogfelder zunächst im Vordergrund des Besitzerfensters an, damit sie mühelos zu finden sind. Wenn Benutzer*innen das Besitzerfenster aktivieren, wird das nicht modale Dialogfeld möglicherweise verdeckt.
• Passen Sie bei Bedarf die ursprüngliche Position so an, dass das gesamte Dialogfeld auf dem Zielmonitor sichtbar ist. Ist ein größenveränderbares Fenster größer als der Zielmonitor, verkleinern Sie es so, dass es auf den Monitor passt.
• Wenn ein Dialogfeld erneut angezeigt wird, sollte es im gleichen Zustand angezeigt werden wie beim letzten Zugriff. Speichern Sie beim Schließen den verwendeten Monitor, die Fenstergröße, die Position und den Zustand (maximiert oder wiederhergestellt). Stellen Sie beim erneuten Anzeigen die gespeicherte Dialogfeldgröße, die Position und den Zustand unter Verwendung des entsprechenden Monitors wieder her. Ziehen Sie außerdem in Betracht, diese Attribute programminstanzübergreifend pro Benutzer bzw. Benutzerin beizubehalten.
• Legen Sie bei größenveränderbaren Fenstern eine Mindestfenstergröße fest, wenn es eine Größe gibt, unter der der Inhalt nicht mehr verwendbar ist. Passen Sie ggf. die Darstellung an, um den Inhalt auch bei kleineren Größen nutzbar zu machen.

In diesem Beispiel wird das Format von Windows Medienwiedergabe angepasst, wenn das Fenster für das Standardformat zu klein wird.

• Verwenden Sie nicht das Attribut „Immer im Vordergrund“.
  • Ausnahme: Verwenden Sie diese Option nur, wenn ein Dialogfeld einen im Wesentlichen modalen Vorgang implementiert und kurz angehalten werden muss, um auf das Besitzerfenster zuzugreifen. Ein Beispiel: Bei der Rechtschreibprüfung eines Dokuments verlassen Benutzer*innen gelegentlich das Dialogfeld „Rechtschreibprüfung“ und greifen auf das Dokument zu, um Fehler zu beheben.

Weitere Informationen und Beispiele finden Sie unter Fensterverwaltung.

Titelleisten

• Dialogfelder besitzen keine Titelleistensymbole. Titelleistensymbole werden zur optischen Unterscheidung zwischen primären Fenstern und sekundären Fenstern verwendet.
  • Ausnahme: Wenn ein Dialogfeld ein primäres Fenster (z. B. ein Hilfsprogramm) implementiert und daher auf der Taskleiste angezeigt wird, verfügt es über ein Titelleistensymbol. Optimieren Sie in diesem Fall den Titel für die Anzeige auf der Taskleiste, indem Sie wichtige Informationen an den Anfang stellen.
• Dialogfelder verfügen immer über eine Schaltfläche vom Typ „Schließen“. Nicht modale Dialogfelder können auch über eine Schaltfläche zum Minimieren verfügen. Größenveränderbare Dialogfelder können über eine Schaltfläche zum Maximieren verfügen.
• Deaktivieren Sie die Schaltfläche „Schließen“ nicht. Eine Schaltfläche zum Schließen gibt Benutzer*innen die Kontrolle und ermöglicht es ihnen, unerwünschte Fenster zu schließen.
  • Ausnahme: Bei Statusdialogfeldern können Sie die Schaltfläche „Schließen“ deaktivieren, wenn die Aufgabe abgeschlossen werden muss, um einen gültigen Zustand zu erreichen oder Datenverlust zu verhindern.
• Die Schaltfläche „Schließen“ auf der Titelleiste muss die gleiche Wirkung haben wie die Schaltfläche „Abbrechen“ oder „Schließen“ im Dialogfeld. Geben Sie ihr niemals die gleiche Wirkung wie „OK“.
• Wenn die Beschriftung und das Symbol der Titelleiste bereits gut sichtbar im oberen Bereich des Fensters angezeigt werden, können Sie die Beschriftung und das Symbol der Titelleiste ausblenden, um Redundanz zu vermeiden. Sie müssen jedoch weiterhin intern einen geeigneten Titel für die Verwendung durch Windows festlegen.

Interaktion

• Benutzerseitig initiierte Dialogfelder sollten immer den Eingabefokus erhalten, wenn sie angezeigt werden. Programmseitig initiierte Dialogfelder dürfen keinen Eingabefokus erhalten, da Benutzer*innen möglicherweise gerade mit einem anderen Fenster interagieren. Wenn eine solche Interaktion fälschlicherweise an das Dialogfeld übergeben wird, kann dies unbeabsichtigte Folgen haben.

• Weisen Sie den anfänglichen Eingabefokus dem Steuerelement zu, mit dem Benutzer*innen voraussichtlich am ehesten interagieren. Hierbei handelt es sich meist (aber nicht immer) um das erste interaktive Steuerelement. Weisen Sie den anfänglichen Eingabefokus möglichst nicht einem Hilfelink zu.

• Für die Tastaturnavigation sollte eine logische Aktivierreihenfolge verwendet werden (üblicherweise von links nach rechts und von oben nach unten). In der Regel orientiert sich die Aktivierreihenfolge an der Leserichtung. Dabei gelten allerdings folgende Ausnahmen:

  • Platzieren Sie die am häufigsten verwendeten Steuerelemente weiter vorn in der Registerkartenreihenfolge.
  • Platzieren Sie die Hilfelinks am unteren Rand eines Dialogfelds, also nach den Commitschaltflächen in der Aktivierreihenfolge.

  Gehen Sie beim Zuweisen der Reihenfolge davon aus, dass Benutzer*innen Dialogfelder für den jeweils vorgesehenen Zweck anzeigen. Benutzer*innen zeigen also z. B. Auswahldialogfelder nicht an, um Angaben zu überprüfen und auf „Abbrechen“ zu klicken, sondern um Optionen auszuwählen.

• Durch Drücken der ESC-TASTE wird ein aktives Dialogfeld immer geschlossen. Das gilt für Dialogfelder mit der Schaltfläche „Abbrechen“ oder „Schließen“ und sogar, wenn „Abbrechen“ in „Schließen“ umbenannt wurde, da die Ergebnisse nicht mehr rückgängig gemacht werden können.

Zugriffsschlüssel

• Weisen Sie nach Möglichkeit allen interaktiven Steuerelementen oder deren Bezeichnungen eindeutige Zugriffstasten zu.Schreibgeschützte Textfelder sind interaktive Steuerelemente (da Benutzer*innen darin scrollen und Text kopieren können) und profitieren deshalb von Zugriffstasten. Folgenden Elementen dürfen keine Zugriffstasten zugewiesen werden:

  • Den Schaltflächen „OK“, „Abbrechen“ und „Schließen“. Für diese Elemente werden EINGABETASTE und ESC-TASTE als Zugriffstasten verwendet. Steuerelementen, die „OK“ oder „Abbrechen“ bedeuten, aber eine andere Bezeichnung haben, sollte dagegen immer eine Zugriffstaste zugewiesen werden.

    

    In diesem Beispiel ist der positiven Commitschaltfläche eine Zugriffstaste zugewiesen.

  • Gruppenbezeichnungen. Normalerweise werden den einzelnen Steuerelementen innerhalb einer Gruppe Zugriffstasten zugewiesen, sodass die Gruppenbezeichnung keine benötigt. Falls allerdings nicht genügend Zugriffstasten verfügbar sind, können Sie der Gruppenbezeichnung eine Zugriffstaste zuweisen anstatt den einzelnen Steuerelementen.

  • Generische Hilfeschaltflächen. Hier wird F1 für den Zugriff verwendet.

  • Linkbezeichnungen. Es sind zu häufig zu viele Links vorhanden, um ihnen eindeutige Zugriffstasten zuzuweisen, und aufgrund der Unterstreichung, die oftmals zur Kennzeichnung von Links verwendet wird, sind die Unterstriche der Zugriffstasten nicht zu sehen. Verwenden Sie für den Zugriff auf Links stattdessen die TAB-TASTE.

  • Registerkartennamen. Für die Navigation zwischen Registerkarten wird STRG+TAB bzw. STRG+UMSCHALT+TAB verwendet.

  • Schaltflächen vom Typ „Durchsuchen“ mit „...“. Diese Schaltflächen zum Durchsuchen können keine eindeutigen Zugriffstasten zugewiesen werden.

  • Nicht beschriftete Steuerelemente wie Drehfeld-Steuerelemente, grafische Befehlsschaltflächen und nicht beschriftete Steuerelemente mit schrittweiser Anzeige.

  • Statischer Text, bei dem es sich nicht um eine Bezeichnung handelt, oder Bezeichnungen für nicht interaktive Steuerelemente wie etwa Statusanzeigen.

• Weisen Sie nach Möglichkeit Zugriffstasten für häufig verwendete Befehle gemäß den Standard-Zugriffstastenzuweisungen zu. Einheitliche Zugriffstastenzuweisungen sind zwar nicht immer möglich, aber besonders für häufig verwendete Dialogfelder bevorzugt.

• Weisen Sie zuerst Zugriffstasten für Commitschaltflächen zu, um sicherzustellen, dass sie über Standardtastenzuweisungen verfügen. Gibt es keine Standardtastenzuweisung, verwenden Sie den ersten Buchstaben des ersten Worts. Die Zugriffstasten für die Schaltflächen „Ja“ und „Nein“ sollten z. B. immer „J“ und „N“ sein, unabhängig von den anderen Steuerelementen im Dialogfeld.

• Weisen Sie die Zugriffstaste einem Zeichen zu, das sich weit vorne in der Bezeichnung befindet, damit die Zugriffstaste leicht zu finden ist. Verwenden Sie idealerweise das erste Zeichen, auch wenn weiter hinten in der Bezeichnung ein Schlüsselwort vorkommt.

• Verwenden Sie vorzugsweise breite Zeichen wie „w“, „m“ und Großbuchstaben.

• Verwenden Sie nach Möglichkeit einen deutlichen Konsonanten oder Vokal wie etwa „V“ in „Verlassen“.

• Verwenden Sie möglichst keine Zeichen, bei denen die Unterstreichung schlecht zu erkennen ist. Im Anschluss folgen einige Beispiele, beginnend mit den problematischsten Fällen:

  • Buchstaben, die nur ein einzelnes Pixel breit sind (z. B. „i“ und „l“)
  • Buchstaben mit Unterlänge (z. B. „g“, „j“, „p“, „q“ und „y“)
  • Buchstaben neben einem Buchstaben mit Unterlänge

Weitere Richtlinien und Beispiele finden Sie unter Tastatur.

Statusdialogfelder

Gehen Sie bei Aufgaben mit langer Laufzeit davon aus, dass Benutzer*innen andere Aktionen ausführen, bis die Aufgabe abgeschlossen ist. Gestalten Sie die Aufgabe so, dass sie unbeaufsichtigt ausgeführt wird.

• Zeigen Sie ein Dialogfeld mit Statusfeedback an, wenn ein Vorgang länger als fünf Sekunden dauert, sowie einen Befehl zum Abbrechen oder Beenden des Vorgangs.
  • Ausnahme: Verwenden Sie bei Assistenten und Aufgabenflüssen nur dann ein modales Dialogfeld für den Fortschritt, wenn die Aufgabe auf der gleichen Seite bleibt (also nicht auf einer anderen Seite fortgesetzt wird) und Benutzer nichts weiter tun können als zu warten. Verwenden Sie andernfalls eine Statusseite oder eine direkte Statusanzeige.
• Wenn der Vorgang eine Aufgabe mit langer Laufzeit (mehr als 30 Sekunden) ist und im Hintergrund ausgeführt werden kann, verwenden Sie ein nicht modales Statusdialogfeld, damit Benutzer*innen Ihr Programm weiterverwenden können, während sie warten.
• Nicht modale Statusdialogfelder zeichnen sich durch Folgendes aus:
  • Auf ihrer Titelleiste befindet sich eine Schaltfläche zum Minimieren.
  • Sie werden auf der Taskleiste angezeigt.
• Implementieren Sie nicht modale Statusdialogdialogfelder so, dass sie auch dann weiter ausgeführt werden, wenn das Besitzerfenster geschlossen wird.

In diesem Beispiel wird das Kopieren von Dateien fortgesetzt, auch wenn das Besitzerfenster geschlossen wird.

• Stellen Sie eine Befehlsschaltfläche zum Anhalten des Vorgangs bereit, wenn der Vorgang länger als ein paar Sekunden dauert oder die Gefahr besteht, dass er niemals abgeschlossen wird. Beschriften Sie die Schaltfläche mit „Abbrechen“, wenn durch Abbrechen des Vorgangs der vorherige Zustand der Umgebung (ohne Nebenwirkungen) wiederhergestellt wird. Beschriften Sie die Schaltfläche andernfalls mit „Beenden“, um anzugeben, dass der teilweise abgeschlossene Vorgang intakt bleibt. Sie können die Bezeichnung der Schaltfläche während des laufenden Vorgangs von „Abbrechen“ in „Beenden“ ändern, wenn es ab einem gewissen Punkt nicht möglich ist, den vorherigen Zustand der Umgebung wiederherzustellen.

In diesem Beispiel hat das Anhalten der Problemdiagnose keine Nebenwirkungen.

• Stellen Sie eine Befehlsschaltfläche bereit, um den Vorgang anzuhalten, wenn dieser länger als ein paar Minuten dauert und Benutzer*innen bei ihrer Arbeit beeinträchtigt. Dadurch müssen sich Benutzer*innen nicht zwischen dem Abschluss der Aufgabe und der Erledigung ihrer Arbeit entscheiden.
• Sammeln Sie vor dem Starten der Aufgabe möglichst viele Informationen.
• Wenn behebbare Probleme erkannt werden, lassen Sie die Benutzer*innen alle gefundenen Probleme am Ende der Aufgabe behandeln. Sollte das nicht funktionieren, müssen Probleme von den Benutzer*innen behandelt werden, wenn sie auftreten.
• Brechen Sie Vorgänge nicht aufgrund von behebbaren Fehlern ab.

In diesem Beispiel ermöglicht es Windows Explorer Benutzer*innen, die Aufgabe nach einem behebbaren Fehler fortzusetzen.

• Weisen Sie auf Probleme hin, indem Sie die Statusanzeige rot färben.

In diesem Beispiel wurde ein Wechseldatenträger während eines Dateikopiervorgangs entfernt.

• Wenn die Ergebnisse für Benutzer*innen offensichtlich sind, schließen Sie das Statusdialogfeld automatisch nach erfolgreichem Abschluss des Vorgangs. Verwenden Sie andernfalls nur Feedback, um Probleme zu melden:
  • Einfaches Feedback kann im Statusdialogfeld angezeigt werden. Ändern Sie in diesem Fall die Schaltfläche „Abbrechen“ in „Schließen“.
  • Wenn Sie detailliertes Feedback anzeigen möchten, schließen Sie das Statusdialogfeld, und zeigen Sie ein Informationsdialogfeld an.

Verwenden Sie für Abschlussfeedback keine Benachrichtigung. Verwenden Sie entweder ein Statusdialogfeld oder eine Benachrichtigung für eine erfolgreiche Aktion, aber nicht beides.

Restdauer

• Verwenden Sie folgende Zeitformate. Beginnen Sie mit dem ersten der folgenden Formate, bei dem die größte Zeiteinheit nicht null ist, und wechseln Sie dann zum nächsten Format, sobald die größte Zeiteinheit null wird.

Für Statusanzeigen:

Wenn verwandte Informationen in einem Doppelpunktformat angezeigt werden:

Restdauer: h Stunden, m Minuten

Restdauer: m Minuten, s Sekunden

Restdauer: s Sekunden

Bei begrenztem Platz auf dem Bildschirm:

h Std., m Min. verbleibend

m Min., s Sek. verbleibend

s Sekunden verbleibend

Ansonsten:

h Stunden, m Minuten verbleibend

m Minuten, s Sekunden verbleibend

s Sekunden verbleibend

Für Titelleisten:

hh:mm verbleibend

mm:ss verbleibend

0:ss verbleibend

In diesem kompakten Format werden die wichtigsten Informationen zuerst angezeigt, damit sie auf der Taskleiste nicht abgeschnitten werden.

• Bemühen Sie sich um präzise Schätzungen, spiegeln Sie aber keine falsche Genauigkeit vor. Wenn die größte Einheit Stunden ist, geben Sie ggf. Minuten an, aber keine Sekunden.

Falsch:

hh Stunden, mm Minuten, ss Sekunden

• Halten Sie die Schätzung auf dem neuesten Stand. Aktualisieren Sie die geschätzte Restdauer mindestens alle fünf Sekunden.
• Konzentrieren Sie sich auf die Restdauer, da dies die Information ist, die für Benutzer*innen am interessantesten ist. Geben Sie die verstrichene Gesamtzeit nur in Szenarien an, in denen diese Angabe hilfreich ist (z. B., wenn der Vorgang wahrscheinlich wiederholt wird). Wenn die geschätzte Restdauer mit einer Statusanzeige zusammenhängt, geben Sie keinen Text für „Prozent abgeschlossen“ an, da diese Information bereits durch die Statusleiste vermittelt wird.
• Achten Sie auf korrekte Grammatik. Verwenden Sie Einheiten im Singular, wenn die Zahl 1 ist.

Falsch:

1 Minuten, 1 Sekunden

• Verwenden Sie eine für Sätze übliche Großschreibung.

Weitere Informationen und Beispiele finden Sie unter Statusleisten.

Symbole und Grafiken

Grafiken

• Verwenden Sie keine großen Grafiken, die nur dazu dienen, den verfügbaren Platz zu füllen. Bemühen Sie sich stattdessen um eine simple Darstellung.

Falsch:

In diesem Beispiel hat die große Grafik keine Funktion.

Titelleistensymbole

• Dialogfelder besitzen keine Titelleistensymbole.
  • Ausnahme: Wenn ein Dialogfeld ein primäres Fenster (z. B. ein Hilfsprogramm) implementiert und daher auf der Taskleiste angezeigt wird, verfügt es über ein Titelleistensymbol.

Textkörpersymbole

• Wählen Sie das Textkörpersymbol basierend auf dem Entwurfsmuster aus:

Muster	Textkörpersymbol
Fragedialogfelder	Programm-, Feature-, Objekt-, Warnsymbol (bei potenziellem Datenverlust oder Systemzugriff), Sicherheitswarnung oder kein Symbol
Auswahldialogfelder	Keine.
Statusdialogfelder	Kein Symbol (aber möglicherweise eine Animation)
Informationsdialogfelder	Keine.

• Falsch:

In diesem Beispiel wird fälschlicherweise ein Warnsymbol für eine Frage verwendet, die keinen potenziellen Datenverlust oder Systemzugriff beinhaltet.

• Erwägen Sie die Verwendung von Symbolen, damit Benutzer*innen die Features Ihres Programms visuell erkennen können. Dies ist am effektivsten, wenn die Symbole leicht erkennbar sind und an mehreren Stellen innerhalb Ihres Programms verwendet werden.

In diesem Beispiel steht das gelbe Sternsymbol für „Favoriten“. Das Symbol ist leicht erkennbar und wird durchgängig in Windows verwendet, um Favoriten darzustellen.

• Verwenden Sie Symbole, um Benutzer*innen bei der Erkennung des betreffenden Objekts zu helfen.

In diesem Beispiel hilft das Symbol des Objekts Benutzer*innen dabei, den Typ der Datei zu erkennen, die geöffnet oder gespeichert wird.

• Erwägen Sie die Verwendung von Symbolen, um Features selbsterklärend zu machen.

In diesem Beispiel veranschaulichen die Symbole die Wirkung der jeweiligen Features für Benutzer*innen.

• Verwenden Sie in Infodialogfeldern ein Symbol für das Anwendungsbranding.

In diesem Beispiel wird eine Bitmap im Infofeld verwendet, um die Anwendung zu identifizieren und zu kennzeichnen.

Fußnotensymbole

• Bei Fußnoten empfiehlt sich ggf. die Verwendung eines Fußnotensymbols, um das Thema der Fußnote zusammenzufassen.

In diesem Beispiel weist das Fußnotensymbol darauf hin, dass die Frage Sicherheitsauswirkungen hat.

• Verwenden Sie kein Fußnotensymbol, das das Textkörpersymbol wiederholt.
• Verwenden Sie nicht die Standardsymbole für Fehler oder Informationen. Fehlerbedingungen müssen über das Textkörpersymbol vermittelt werden, und Fußnoten werden immer für Informationen verwendet, weshalb das Informationssymbol hier überflüssig ist. Sie können jedoch das Standardwarnsymbol und das gelbe Sicherheitsschild verwenden, um Benutzer*innen auf riskante Folgen aufmerksam zu machen.

Weitere Informationen und Beispiele finden Sie unter Symbole.

Commitschaltflächen

Hinweise:

• Diese Richtlinien gelten nicht für Fragedialogfelder mit Befehlslinks, da bei diesem Muster Befehlslinks anstelle von Schaltflächen verwendet werden.
• [Durchführen] und [Nicht durchführen] sind bestätigende bzw. negative Reaktionen auf die Hauptanweisung.

Allgemeines

• Wählen Sie die Commitschaltflächen basierend auf dem Entwurfsmuster aus:

Bezeichnung	Wert
Muster	Commitschaltflächen
Fragedialogfelder (mit Schaltflächen)	Eine der folgenden Kurzbefehlsgruppen: Ja/Nein, Ja/Nein/Abbrechen, [Durchführen]/Abbrechen, [Durchführen]/[Nicht durchführen], [Durchführen]/[Nicht durchführen]/Abbrechen
Fragedialogfelder (mit Links)	Abbrechen.
Auswahldialogfelder	Modale Dialogfelder: OK/Abbrechen oder [Durchführen]/Abbrechen Nicht modale Dialogfelder: Schaltfläche „Schließen“ im Dialogfeld und auf der Titelleiste Aufgabenbereich: Schaltfläche „Schließen“ auf der Titelleiste
Statusdialogfelder	Verwenden Sie „Abbrechen“, wenn dadurch der vorherige Zustand der Umgebung (ohne Nebenwirkungen) wiederhergestellt wird. Verwenden Sie andernfalls „Beenden“.
Informationsdialogfelder	Fast richtig.

• Mit Ausnahme von „Übernehmen“ führen alle Commitschaltflächen dazu, dass das Dialogfeldfenster geschlossen wird.

• Bestätigen Sie keine Commitschaltflächen. Unnötige Bestätigungen können äußerst lästig sein. Ausnahmen:

  • Die Aktion hat möglicherweise katastrophale Folgen.
  • Die Aktion steht eindeutig im Konflikt mit anderen Aktionen.
  • Wenn die Aktion fälschlicherweise ausgeführt wird, kann dies zu erheblichem Daten- oder Zeitverlust oder zu einem erheblichen Mehraufwand für den Benutzer bzw. für die Benutzerin führen.

  Weitere Richtlinien und Beispiele finden Sie unter Bestätigungen.

• Deaktivieren Sie keine Commitschaltflächen. Ausnahmen:

  • Wenn Benutzer*innen höhere Rechte für eine Änderung benötigen, deaktivieren Sie die Schaltflächen für positive Commits, bis der Benutzer bzw. die Benutzerin eine Änderung vornimmt. Dadurch sind sie gezwungen, auf „Abbrechen“ zu klicken, was vermeidet, dass Benutzer*innen ihre Rechte nur erhöhen, um ein Fenster zu schließen.
  • Weitere Ausnahmen finden Sie unter Deaktivieren oder Entfernen von Steuerelementen im Vergleich zum Ausgeben von Fehlermeldungen.

• Richten Sie Commitschaltflächen rechtsbündig in einer einzelnen Zeile am unteren Rand des Dialogfelds aus, aber platzieren Sie sie oberhalb des Fußnotenbereichs. Halten Sie sich an diese Vorgabe, auch wenn nur eine einzelne Commitschaltfläche (z. B. „OK“) vorhanden ist.

  Falsch:

  

  In diesem Beispiel ist die Schaltfläche „OK“ fälschlicherweise zentriert.

• Ordnen Sie die Commitschaltflächen in der folgenden Reihenfolge an:

  1. OK/[Ausführen]/Ja
  2. [Nicht ausführen]/Nein
  3. Abbrechen
  4. „Anwenden“ (sofern vorhanden)
  5. „Hilfe“ (sofern vorhanden)

• Wenn zahlreiche verwandte Commitschaltflächen vorhanden sind, fassen Sie sie mithilfe unterteilter Schaltflächen zusammen.

• Trennen Sie Commitschaltflächen (die das Fenster schließen) klar von allen anderen Befehlsschaltflächen (z. B. „Erweitert“).

Reagieren auf Hauptanweisungen

• Verwenden Sie positive Commitschaltflächen, bei denen es sich um spezifische Antworten auf die Hauptanweisung handelt, anstatt generische Bezeichnungen wie „OK“ oder „Ja“/„Nein“. Benutzer*innen müssen die Optionen allein anhand des Schaltflächentexts verstehen können. Ausnahmen:

  • Verwenden Sie „Schließen“ für Dialogfelder, die über keine Einstellungen verfügen (beispielsweise Informationsdialogfelder). Verwenden Sie „Schließen“ niemals für Dialogfelder mit Einstellungen.

  • Verwenden Sie „OK“, wenn die „spezifischen“ Antworten trotzdem generisch sind (beispielsweise „Speichern“ oder „Auswählen“). Verwenden Sie „OK“, wenn eine spezifische Einstellung oder eine Sammlung von Einstellungen geändert wird.

  • Bei Legacydialogfeldern ohne Hauptanweisung können Sie generische Bezeichnungen wie „OK“ verwenden. Häufig sind solche Dialogfelder nicht darauf ausgelegt, eine bestimmte Aufgabe auszuführen, was spezifischere Antworten verhindert.

  • Bei manchen Aufgaben müssen sich Benutzer*innen mehr Gedanken machen und den Text aufmerksam lesen, um fundierte Entscheidungen treffen zu können. Dies ist in der Regel bei Bestätigungen der Fall. In solchen Fällen können Sie bewusst generische Bezeichnungen für Commitschaltflächen verwenden, damit Benutzer*innen sich die Hauptanweisungen durchlesen müssen und keine vorschnellen Entscheidungen treffen.

    Richtig:

    

    In diesem Beispiel müssen sich Benutzer*innen aufgrund der Verwendung der Schaltflächen „Yes“ (Ja) und „No“ (Nein) mindestens die Hauptanweisung durchlesen.

• Alternativ können Sie der Bezeichnung für positive Commitschaltflächen das Wort „trotzdem“ hinzufügen, um deutlich zu machen, dass das Dialogfeld einen Grund dafür enthält, den Vorgang nicht fortzusetzen, und dass Benutzer*innen den Text des Dialogfelds sorgfältig lesen sollten, bevor sie fortfahren.

  Richtig:

  

  In diesem Beispiel wird der Bezeichnung der Commitschaltfläche das Wort „anyway“ (trotzdem) hinzugefügt, um anzugeben, dass Benutzer*innen mit Bedacht vorgehen sollten.

• Verwenden Sie für negative Commitschaltflächen „Abbrechen“ oder „Schließen“ anstelle bestimmter Antworten auf die Hauptanweisung. Häufig stellen Benutzer*innen fest, dass sie eine Aufgabe nicht ausführen möchten, sobald ein Dialogfeld angezeigt wird. Wenn „Abbrechen“ oder „Schließen“ für bestimmte Antworten mit einer anderen Bezeichnung versehen wurde, müssen Benutzer*innen den Text aller Commitschaltflächen sorgfältig lesen, um zu ermitteln, wie der Vorgang abgebrochen werden kann. Eine einheitliche Bezeichnung von „Abbrechen“ und „Schließen“ trägt dazu bei, dass die Optionen problemlos gefunden werden können. Ausnahmen:

  • Verwenden Sie nicht „Ja“/„Abbrechen“. Verwenden Sie immer „Ja“/„Nein“ als Paar.
  • Verwenden Sie eine spezifische Antwort, wenn „Abbrechen“ nicht eindeutig ist.

• Ordnen Sie generische Bezeichnungen nicht über Text im Inhaltsbereich eine spezifische Bedeutung zu. Verwenden Sie stattdessen spezifische Commitschaltflächenbezeichnungen oder ein Fragedialogfeld mit Links, falls die Bezeichnungen lang sind.

  Falsch:

  

  In diesem Beispiel ist „OK“ mit „Weiter“ und „Abbrechen“ mit „Auf der Seite bleiben“ verknüpft.

Schaltflächen „Ja“ und „Nein“

• Verwenden Sie vorzugsweise spezifische Antworten anstelle der Schaltflächen „Ja“ und „Nein“. Die Verwendung von „Ja“ und „Nein“ ist zwar nicht falsch, spezifische Antworten sind allerdings schneller verständlich und ermöglichen eine effiziente Entscheidungsfindung. Bei Bestätigungen werden jedoch in der Regel die Schaltflächen „Ja“ und „Nein“ verwendet, damit Benutzer*innen ein wenig darüber nachdenken, bevor sie auf die Bestätigung reagieren.

• Verwenden Sie die Schaltflächen „Ja“ und „Nein“ nur für Ja-Nein-Fragen. Die Hauptanweisung sollte auf natürliche Weise als Ja-Nein-Frage ausgedrückt werden. Verwenden Sie niemals „OK“ und „Abbrechen“ für Ja-Nein-Fragen.

  Falsch:

  

  Richtig:

  

  Besser:

  

  In diesen Beispielen sind „Ja“ und „Nein“ zwar gute Antworten auf Ja-Nein-Fragen, spezifische Antworten sind aber noch besser.

• Formulieren Sie die Hauptanweisung ggf. als Ja-Nein-Frage, wenn Commitschaltflächen mit spezifischer Formulierung lang oder sperrig sind. Alternativ können bei längeren Antworten (ab fünf Wörtern) auf die Hauptanweisung Befehlslinks verwendet werden.

  Falsch:

  

  Richtig:

  

  Die spezifische Formulierung im Negativbeispiel ist zu lang, weshalb im Positivbeispiel „Yes“ (Ja) und „No“ (Nein) verwendet werden.

• Verwenden Sie keine Schaltflächen vom Typ „Ja“ und „Nein“, wenn die Bedeutung der Antwort „Nein“ unklar ist. Verwenden Sie in derartigen Fällen stattdessen spezifische Antworten.

OK-Schaltflächen

• In modalen Dialogfeldern bedeutet das Klicken auf „OK“, dass die Werte übernommen werden sollen und dass die Aufgabe ausgeführt und das Fenster geschlossen werden soll.

• Verwenden Sie keine OK-Schaltflächen als Antwort auf Fragen.

• Weisen Sie „OK“ keine Zugriffstasten zu, da die EINGABETASTE die Zugriffstaste für die Standardschaltfläche ist. Das erleichtert die Zuweisung der anderen Zugriffstasten.

• Beschriften Sie OK-Schaltflächen korrekt. Die OK-Schaltfläche muss mit „OK“ beschriftet werden (nicht mit „Ok“ oder „Okay“).

• Verwenden Sie keine OK-Schaltflächen für Fehler oder Warnungen. Probleme sind nie OK. Verwenden Sie stattdessen „Schließen“.

  Falsch:

  

  In diesem Beispiel sollte „Schließen“ anstelle von "OK" verwendet werden.

• Verwenden Sie in nicht modalen Dialogfeldern keine OK-Schaltflächen. Nicht modale Dialogfelder müssen über aufgabenspezifische Commitschaltflächen wie „Suchen“ verfügen. Einige nicht modale Dialogfelder benötigen allerdings nur eine Schaltfläche zum Schließen.

Schaltflächen vom Typ „Abbrechen“

• Durch Klicken auf „Abbrechen“ werden alle Änderungen verworfen, die Aufgabe wird abgebrochen, das Fenster wird geschlossen, und der vorherige Zustand der Umgebung wird ohne Nebenwirkungen wiederhergestellt. Bei geschachtelten Auswahldialogfeldern führt das Klicken auf „Abbrechen“ im Besitzerauswahldialogfeld dazu, dass auch alle Änderungen, die von den zugehörigen Auswahldialogfeldern vorgenommen wurden, verworfen werden.

• Stellen Sie eine Schaltfläche zum Abbrechen bereit, damit Benutzer*innen Änderungen explizit abbrechen können. Dialogfelder benötigen einen klaren Ausstiegspunkt. Verlassen Sie sich nicht darauf, dass Benutzer*innen die Schaltfläche „Schließen“ auf der Titelleiste finden.

  • Ausnahme: Stellen Sie keine Schaltfläche zum Abbrechen für Dialogfelder ohne Einstellungen bereit. Die Schaltflächen „OK“ und „Schließen“ haben in diesem Fall die gleiche Wirkung wie „Abbrechen“.

  Falsch:

  

  In diesem Beispiel entsteht der Eindruck, Benutzer*innen hätten keine Wahl, da sich die Schaltfläche „Schließen“ nur auf der Titelleiste befindet.

• Verwenden Sie keine Schaltflächen vom Typ „Abbrechen“ als Antwort auf Fragen.

  Falsch:

  

  In diesem Beispiel werden fälschlicherweise „OK“ und „Abbrechen“ als Antwort auf eine Ja-Nein-Frage verwendet.

• Weisen Sie „Abbrechen“ keine Zugriffstasten zu, da ESC als Zugriffstaste verwendet wird. Das erleichtert die Zuweisung der anderen Zugriffstasten.

• Verwenden Sie in nicht modalen Dialogfeldern keine Schaltflächen vom Typ „Abbrechen“. Verwenden Sie stattdessen „Schließen“.

• Deaktivieren Sie die Schaltfläche „Abbrechen“ nicht. Benutzer*innen müssen Dialogfelder immer abbrechen können.

  • Ausnahme: Sie können die Schaltfläche „Abbrechen“ in einem Statusdialogfeld deaktivieren, wenn der Vorgang während eines bestimmten Zeitraums nicht abgebrochen werden kann. Noch besser ist es allerdings, derartige Vorgänge so zu gestalten, dass sie jederzeit abgebrochen werden können.

Schaltflächen vom Typ „Schließen“

• Verwenden Sie Schaltflächen zum Schließen für nicht modale Dialogfelder sowie für modale Dialogfelder, die nicht abgebrochen werden können.
• Durch Klicken auf „Schließen“ wird das Dialogfeldfenster geschlossen, wobei ggf. bestehende Nebenwirkungen erhalten bleiben. Verwenden Sie nicht „Fertig“, da es sich dabei nicht um eine Imperativkonstruktion handelt. Bei geschachtelten Auswahldialogfeldern führt das Klicken auf „Schließen“ im Besitzerauswahldialogfeld dazu, dass alle Änderungen, die von den zugehörigen Auswahldialogfeldern vorgenommen wurden, erhalten bleiben.
• Platzieren Sie eine explizite Schaltfläche vom Typ „Schließen“ im Textkörper des Dialogfelds. Dialogfelder benötigen einen klaren Ausstiegspunkt. Verlassen Sie sich nicht darauf, dass Benutzer*innen die Schaltfläche „Schließen“ auf der Titelleiste finden.
• Stellen Sie sicher, dass die Schaltfläche „Schließen“ auf der Titelleiste die gleiche Wirkung hat wie „Abbrechen“ oder „Schließen“.
• Weisen Sie „Schließen“ keine Zugriffstasten zu, da ESC als Zugriffstaste verwendet wird. Das erleichtert die Zuweisung der anderen Zugriffstasten.

Schaltflächen vom Typ „Anwenden“

• Verwenden Sie in Dialogfeldern, bei denen es sich nicht um Eigenschaftenblätter oder Systemsteuerungen handelt, keine Schaltflächen vom Typ „Anwenden“. Die Schaltfläche „Übernehmen“ bedeutet, dass die ausstehenden Änderungen angewendet werden sollen, ohne das Fenster zu schließen. So können Benutzer*innen die vorgenommenen Änderungen bewerten, bevor sie das Fenster schließen. Dies ist jedoch nur bei Eigenschaftenblättern und Systemsteuerungen erforderlich.

  Falsch:

  

  In diesem Beispiel verfügt ein Auswahldialogfeld unnötigerweise über eine Schaltfläche vom Typ „Übernehmen“.

Commitschaltflächen für indirekte Dialogfelder

Hinweis: Indirekte Dialogfelder werden außerhalb des Kontexts angezeigt – entweder als indirektes Ergebnis einer Aufgabe oder aufgrund eines Problems mit einem System- oder Hintergrundprozess. Bei indirekten Dialogfeldern ist die Schaltfläche „Abbrechen“ mehrdeutig, da nicht klar ist, ob nur das Dialogfeld oder die gesamte Aufgabe abgebrochen wird.

• Wenn Benutzer*innen sowohl das Dialogfeld als auch die Aufgabe abbrechen müssen, stellen Sie Commitschaltflächen für beides bereit. Beschriften Sie die Schaltfläche, mit der das Dialogfeld abgebrochen wird, mit einer negativen Antwort auf die Hauptanweisung. Beschriften Sie die Schaltfläche, mit der die gesamte Aufgabe abgebrochen wird, mit „Abbrechen“. Durch die Verwendung von „Abbrechen“ kann das Dialogfeld in zahlreichen Kontexten verwendet werden.

  Richtig:

  

  In diesem Beispiel wird das obige Dialogfeld von Microsoft Paint als Reaktion auf die Verwendung des Befehls „Neu“ oder „Beenden“ angezeigt, wenn die Grafik nicht gespeichert wurde. „Nicht speichern“ schließt das Dialogfeld, ohne zu speichern. Bei Verwendung von „Abbrechen“ wird dagegen der Befehl „Neu“ oder „Beenden“ abgebrochen.

  Falsch:

  

  In diesem Beispiel gibt es keine Möglichkeit, die Aufgabe (das Schließen der Office-Symbolleiste) abzubrechen, die zur Anzeige dieses Dialogfelds geführt hat. Dieses Dialogfeld benötigt eine Schaltfläche vom Typ „Abbrechen“.

• Wenn Benutzer*innen nur das Dialogfeld abbrechen müssen, aber nicht die Aufgabe, verwenden Sie eine Schaltfläche mit einer spezifischen negativen Antwort auf die Hauptanweisung, und stellen Sie keine Schaltfläche vom Typ „Abbrechen“ bereit.

  

  In diesem Beispiel wird das Dialogfeld indirekt aufgrund der Navigation zu einer Webseite angezeigt, die ein ActiveX-Steuerelement installiert. Die Verwendung von „Abbrechen“ wäre hier nicht eindeutig. Daher wird stattdessen „Nicht ausführen“ verwendet.

Weitere Informationen und Beispiele finden Sie unter Befehlsschaltflächen.

Befehlslinks

• Stellen Sie mehrere längere Befehle mithilfe von Befehlslinks dar, anstatt Befehlsschaltflächen oder eine Kombination aus Optionsfeldern und einer OK-Schaltfläche zu verwenden. Dadurch können Benutzer*innen mit einem einzelnen Klick reagieren. Dieser Ansatz funktioniert jedoch nur für eine einzelne Frage.
• Zeigen Sie die am häufigsten verwendeten Befehlslinks zuerst an. Die resultierende Reihenfolge sollte grob auf die Wahrscheinlichkeit der Verwendung abgestimmt, aber auch logisch aufgebaut sein.
  • Ausnahme: Befehlslinks, die alles ausführen, sollten zuerst platziert werden.
• Wenn ein Befehlslink eine zusätzliche Erläuterung erfordert, geben Sie eine ergänzende Erläuterung an. Ergänzende Erläuterungen beschreiben, warum Benutzer*innen den Befehl ggf. auswählen sollten oder was passiert, wenn der Befehl ausgewählt wird.
• Verwenden Sie keine ergänzenden Erläuterungen, die nur eine wortreiche Wiederholung des Befehlslinks sind. Verwenden Sie ergänzende Erläuterungen nur, wenn ein Befehlslink nicht selbsterklärend ist. Wenn Sie eine ergänzende Erläuterung für einen der Befehlslinks bereitstellen, bedeutet das nicht, dass Sie Erläuterungen für alle Befehle bereitstellen müssen.

In diesem Beispiel beschreibt die ergänzende Erläuterung die Auswirkungen einer der Optionen.

• Verwenden Sie Formulierungen, die mit einem Verb enden (ohne Interpunktion am Ende)
• Wenn ein Befehl nachdrücklich empfohlen wird, kann der entsprechenden Bezeichnung „(empfohlen)“ hinzugefügt werden. Dieser Zusatz muss der Linkbezeichnung (und nicht der ergänzenden Erläuterung) hinzugefügt werden.
• Wenn ein Befehl nur für erfahrene Benutzer*innen gedacht ist, empfiehlt es sich gegebenenfalls, die Bezeichnung mit dem Hinweis „(erweitert)“ zu versehen. Dieser Zusatz muss der Linkbezeichnung (und nicht der ergänzenden Erläuterung) hinzugefügt werden.
• Stellen Sie immer eine explizite Schaltfläche vom Typ „Abbrechen“ bereit. Verwenden Sie hierfür keinen Befehlslink.

Falsch:

In diesem Beispiel wird im Dialogfeld anstelle einer Schaltfläche vom Typ „Abbrechen“ ein Befehlslink verwendet.

Weitere Informationen und Beispiele finden Sie unter Befehlslinks.

„Dieses <Element> nicht mehr anzeigen“

• Mit einer Option vom Typ „Dieses <Element> nicht mehr anzeigen“ können Benutzer*innen die wiederholte Anzeige eines Dialogfelds unterdrücken. Diese Option sollte allerdings nur verwendet werden, wenn es keine bessere Alternative gibt. Es ist besser, das Dialogfeld immer anzuzeigen, wenn Benutzer*innen es wirklich benötigen, oder es andernfalls einfach zu entfernen.
• Verwenden Sie diese spezielle Formulierung, ersetzen Sie <Element> durch das entsprechende Element, und passen Sie ggf. die Grammatik entsprechend an. Beispiel: „Diese Erinnerung nicht mehr anzeigen“. Wenn Sie sich ganz allgemein auf ein Dialogfeld beziehen, verwenden Sie „Diese Meldung nicht mehr anzeigen“.
• Machen Sie deutlich, wenn Benutzereingaben als zukünftige Standardwerte verwendet werden. Fügen Sie hierzu unter der Option den folgenden Satz hinzu: „Ihre Auswahl wird in Zukunft als Standard verwendet.“
• Aktivieren Sie die Option nicht standardmäßig. Wenn das Dialogfeld wirklich nur einmal angezeigt werden soll, lassen Sie die Option weg. Achten Sie darauf, dass das Standardverhalten für die Benutzer*innen nicht störend ist.

Falsch:

In diesem Beispiel sollte die Meldung nur einmal angezeigt werden. Es gibt also keinen Grund für eine Nachfrage.

• Stellen Sie sicher, dass die Einstellung pro Benutzer*in gespeichert wird.
• Wenn Benutzer*innen die Option auswählen und auf „Abbrechen“ klicken, wird diese Option wirksam. Diese Einstellung ist eine Metaoption. Sie entspricht also nicht dem Standardverhalten von Abbruchvorgängen, die ja so ausgeführt werden, dass keine Nebenwirkung zurückbleibt. Beachten Sie, dass Benutzer*innen, die nicht möchten, dass das Dialogfeld erneut angezeigt wird, es wahrscheinlich auch abbrechen möchten.
• Für den Fall, dass Benutzer*innen diese Dialogfelder wiederherstellen möchten, empfiehlt es sich gegebenenfalls, im Dialogfeld „Optionen“ des Programms einen Befehl vom Typ Meldungen wiederherstellen bereitzustellen.

Später nachfragen

• Stellen Sie diese Option zum Schließen eines Dialogfelds nur bereit, wenn Folgendes erfüllt ist:
  • Das Dialogfeld ist indirekt, was bedeutet, dass sich Benutzer*innen wahrscheinlich auf eine andere Aufgabe konzentrieren.
  • Benutzer*innen müssen nicht sofort reagieren und können ihre Arbeit erst einmal fortsetzen.
  • Die Frage ist mit gewissen Überlegungen oder Bemühungen verbunden, was bedeutet, dass Benutzer*innen ggf. bessere Entscheidungen treffen können, wenn sie mehr Zeit haben.
  • Das Dialogfeld oder die Option wird später automatisch angezeigt. (Benutzer*innen werden also eigentlich später gefragt.)
• Falsch:
• 
• In diesem Beispiel ist die Frage so einfach, dass das Hinzufügen einer Option vom Typ „Später nachfragen“ sie nur verkomplizieren würde.
• Gehen Sie ansonsten davon aus, dass Benutzer*innen direkt antworten, aber lassen Sie zu, dass das Dialogfeld über „Abbrechen“ oder „Schließen“ normal geschlossen werden kann. Bei ordnungsgemäßer Verwendung sollte diese Option nur selten erforderlich sein.

Mehr/Weniger

• Verwenden Sie die Schaltflächen „Mehr“ und „Weniger“ für die schrittweise Anzeige, um erweiterte oder selten verwendete Optionen, Befehle oder Details, die die Zielbenutzer*innen normalerweise nicht benötigen, anzuzeigen oder auszublenden. Dies vereinfacht die typische Verwendung des Dialogfelds. Blenden Sie häufig verwendete Optionen, Befehle oder Informationen nicht aus, da Benutzer*innen sie sonst möglicherweise nicht finden.

In diesem Beispiel werden selten verwendete Optionen standardmäßig ausgeblendet.

• Verwenden Sie Steuerelemente vom Typ „Mehr“/„Weniger“ nur, wenn es wirklich mehr Details gibt, die angezeigt werden sollen. Wiederholen Sie nicht nur die gleichen Informationen in einem anderen Format.
• Verwenden Sie Steuerelemente vom Typ „Mehr“/„Weniger“ nicht, um Hilfe anzuzeigen. Verwenden Sie hierfür stattdessen Hilfelinks oder Fußnoten.
• Kombinieren Sie bei Aufgabendialogfeldern nach Möglichkeit keine Steuerelemente vom Typ „Mehr“/„Weniger“ mit „Dieses <Element> nicht mehr anzeigen“. Diese Kombination sieht merkwürdig aus.
• Bezeichnungsrichtlinien finden Sie unter Steuerelemente für schrittweise Offenlegung.

Fußnoten

• Verwenden Sie Fußnoten für Informationen, die für den Zweck eines Dialogfelds nicht wesentlich sind, aber Benutzer*innen ggf. bei der Entscheidungsfindung helfen können. Die meisten Benutzer*innen sollten bei ihrer Reaktion auf das Dialogfeld auch ohne Prüfung der Fußnoten fundierte Entscheidungen treffen können.

In diesem Beispiel enthält die Fußnote eine ergänzende, aber nicht wesentliche Information.

Deaktivieren oder Entfernen von Steuerelementen im Vergleich zum Ausgeben von Fehlermeldungen

• Wenn ein Steuerelement nicht für den aktuellen Kontext geeignet ist, haben Sie folgende Möglichkeiten:
  • Sie können Steuerelement entfernen, wenn Benutzer*innen es nicht aktivieren können oder wenn sie nicht erwarten, dass es relevant ist und sich sein Zustand nicht häufig ändert. Dadurch wird das Dialogfeld vereinfacht, und Benutzer*innen vermissen es nicht. Steuerelemente, die immer wieder erscheinen und verschwinden, sind lästig.
  • Sie können das Steuerelement deaktivieren, wenn Benutzer*innen erwarten, dass es relevant ist, oder wenn sich sein Zustand häufig ändert und Benutzer*innen problemlos folgern können, warum es deaktiviert ist. Ein Beispiel für eine einfache Schlussfolgerung wäre das Deaktivieren einer Commitschaltfläche, wenn ein einzelnes leeres Textfeld vorhanden ist, das eine Eingabe erfordert. Sie können Sprechblasen verwenden, um nicht kritische Probleme mit Benutzereingaben in Textfeldern und bearbeitbaren Dropdownlisten anzuzeigen. Falls das Problem allerdings nicht mit einer Sprechblase erklärt werden kann oder mehrere Steuerelemente betrifft, wäre die Schlussfolgerung nicht mehr einfach.
  • Lassen Sie ansonsten das Steuerelement aktiviert, und geben Sie eine Fehlermeldung aus, wenn es nicht korrekt verwendet wird. In diesem Fall wäre es für Benutzer*innen schwer nachvollziehbar, warum das Steuerelement deaktiviert ist. Benutzer*innen müssten das Problem durch Ausprobieren und logisches Denken ermitteln. Es ist besser, einfach eine hilfreiche Fehlermeldung bereitzustellen, um das Problem explizit zu erklären.
• Tipp: Wenn Sie nicht sicher sind, ob Sie ein Steuerelement deaktivieren oder eine Fehlermeldung ausgeben sollen, erstellen Sie zunächst die Fehlermeldung. Enthält die Fehlermeldung hilfreiche Informationen, die die Zielbenutzer*innen wahrscheinlich nicht auf die Schnelle schlussfolgern können, lassen Sie das Steuerelement aktiviert, und geben Sie den Fehler aus. Deaktivieren Sie andernfalls das Steuerelement.
• Wenn Sie ein Steuerelement deaktivieren, deaktivieren Sie auch alle zugehörigen Steuerelemente wie etwa die Bezeichnung, ergänzende Erläuterungen oder Befehlsschaltflächen. Lassen Sie aber die zugehörigen Gruppenfelder, die Gruppenbezeichnung oder die Gruppenerklärung aktiviert, sofern vorhanden.

In diesem Beispiel sind die Bezeichnungen der deaktivierten Textfelder ebenfalls deaktiviert, nicht aber die zugehörige Gruppenbezeichnung und Gruppenerklärung.

Erforderliche Eingabe

• Um anzugeben, dass Benutzer*innen Informationen in einem Steuerelement angeben müssen, stehen Ihnen folgende Optionen zu Verfügung:

  • Geben Sie nichts an, und behandeln Sie fehlende erforderliche Eingaben mit Fehlermeldungen. Dieser Ansatz ist verbessert die Übersichtlichkeit und funktioniert gut, wenn die meisten Eingaben optional sind oder Benutzer*innen wahrscheinlich keine Steuerelemente überspringen, sodass die Anzahl von Fehlermeldungen gering bleibt.

  • Versehen Sie die erforderlichen Eingaben am Anfang der Bezeichnung mit einem Sternchen. Erläutern Sie das Sternchen mithilfe einer der folgenden Optionen:

    • Eine Fußnote am unteren Rand des Inhaltsbereichs mit folgendem Hinweis: „* Erforderliche Eingabe“
    • Eine QuickInfo für das Sternchen mit dem Hinweis „Erforderliche Eingabe“

    Dieser Ansatz funktioniert gut, wenn es nicht viele erforderliche Steuerelemente gibt, ist aber eher schlecht geeignet, wenn die meisten Steuerelemente obligatorisch sind.

    

    In diesem Beispiel werden Sternchen verwendet, um die erforderlichen Eingaben zu kennzeichnen.

  • Wenn Eingaben für alle Steuerelemente erforderlich sind, fügen Sie an einer geeigneten Stelle am oberen Rand des Inhaltsbereichs den Hinweis „Alle Eingaben erforderlich“ hinzu. Dieser Ansatz verbessert die Übersichtlichkeit für diesen spezifischen Fall.

  • Kennzeichnen Sie optionale Eingaben, indem Sie nach der Bezeichnung den Hinweis „(optional)“ hinzufügen. Dieser Ansatz funktioniert nur gut, wenn die meisten Eingaben obligatorisch sind.

• Verwenden Sie aus Konsistenzgründen möglichst in Ihrem gesamten Programm die gleiche Kennzeichnungsmethode für erforderliche Eingaben. Kennzeichnen Sie also entweder erforderliche oder optionale Eingaben, und verwenden Sie nicht beide Kennzeichnungen im gleichen Programm.

Fehlerbehandlung

• Beugen Sie Fehlern vor, indem Sie Steuerelemente verwenden, die auf gültige Benutzereingaben beschränkt sind. Sie können die Anzahl von Fehlern auch durch Bereitstellung geeigneter Standardwerte reduzieren.

• Überprüfen Sie Benutzereingaben schnellstmöglich, und zeigen Sie Fehler möglichst nah bei der Eingabe an.

• Verwenden Sie für Benutzereingabeprobleme eine nicht modale Fehlerbehandlung (direkte Fehler oder Sprechblasen).

  • Verwenden Sie Sprechblasen für einzelne unkritische Benutzereingabeprobleme, die erkannt wurden, während sich der Benutzer bzw. die Benutzerin in einem Textfeld befindet, oder kurz nachdem ein Textfeld den Fokus verliert. Sprechblasen benötigen weder Platz auf dem Bildschirm noch das dynamische Layout, das zum Anzeigen direkter Meldungen erforderlich ist. Zeigen Sie immer nur eine einzelne Sprechblase an. Da das Problem nicht kritisch ist, ist kein Fehlersymbol erforderlich. Sprechblasen werden nach dem Klicken auf die Sprechblase, nach Behebung des Problems oder nach einem Timeout ausgeblendet.

    

    In diesem Beispiel weist eine Sprechblase auf ein Eingabeproblem hin, während sich der Benutzer bzw. die Benutzerin noch im Steuerelement befindet.

• Verwenden Sie direkte Fehler für die verzögerte Fehlererkennung. Hierbei handelt es sich in der Regel um Fehler, die beim Klicken auf eine Commitschaltfläche gefunden werden. (Verwenden Sie direkte Fehler nicht für Einstellungen, die sofort committet werden.) Es können mehrere direkte Fehler gleichzeitig vorhanden sein. Verwenden Sie normalen Text und ein Fehlersymbol mit 16 × 16 Pixeln, und platzieren Sie beides nach Möglichkeit direkt neben dem Problem. Direkte Fehler werden erst entfernt, wenn der Benutzer bzw. die Benutzerin einen Commit ausführt und keine weiteren Fehler gefunden werden.

  

  In diesem Beispiel wird ein direkter Fehler für einen Fehler verwendet, der nach dem Klicken auf die Commitschaltfläche gefunden wurde.

• Verwenden Sie für alle anderen Probleme eine modale Fehlerbehandlung (Aufgabendialogfelder oder Meldungsfelder). Dies schließt Fehler ein, die mehrere Steuerelemente betreffen, sowie nicht kontext- oder eingabebezogene Fehler, die beim Klicken auf eine Commitschaltfläche gefunden werden.

• Legen Sie den Eingabefokus auf das erste Steuerelement mit den falschen Daten fest, wenn ein Eingabeproblem gefunden und gemeldet wird. Scrollen Sie bei Bedarf die Ansicht, damit das Steuerelement sichtbar ist.

Weitere Informationen und Beispiele finden Sie unter Fehlermeldungen und Sprechblasen.

Hilfe

• Bei der Bereitstellung von Benutzerhilfe haben Sie folgende Optionen (angegeben in der bevorzugten Reihenfolge):

  • Versehen Sie interaktive Steuerelemente mit selbsterklärenden Bezeichnungen. Bezeichnungen interaktiver Steuerelemente werden von Benutzer*innen mit größerer Wahrscheinlichkeit gelesen als jeder andere Text.
  • Verwenden Sie Bezeichnungen in Form von statischem Text, um kontextbezogene Erklärungen bereitzustellen.
  • Stellen Sie einen spezifischen Hilfelink zu einem relevanten Hilfethema bereit.

• Platzieren Sie Hilfelinks unten im Inhaltsbereichs des Dialogfelds. Wenn das Dialogfeld eine Fußnote enthält und der Hilfelink damit verknüpft ist, platzieren Sie den Hilfelink in der Fußnote.

  

  In diesem Beispiel gilt der Hilfelink für das gesamte Dialogfeld.

  • Ausnahme: Wenn ein Dialogfeld mehrere unterschiedliche Gruppen von Einstellungen enthält, für die separate Hilfethemen verfügbar sind (z. B. innerhalb von Gruppenfeldern), müssen die Hilfelinks im unteren Bereich der Gruppen platziert werden.

• Verwenden Sie keine allgemeinen oder vagen Links zu Hilfethemen oder generische Hilfeschaltflächen. Allgemeine Hilfe wird von Benutzer*innen häufig ignorieren.

Weitere Informationen und Beispiele finden Sie unter Hilfe.

Standardwerte

• Schließen Sie in jedes Dialogfeld eine standardmäßige Commitschaltfläche ein.
• Fragedialogfelder:
  • Wählen Sie die sicherste Antwort als Standard aus, um Datenverluste oder Systemzugriffe zu verhindern. Wenn Sicherheit kein wichtiger Faktor ist, wählen Sie die wahrscheinlichste oder praktischste Option aus.
    • Ausnahme: Legen Sie keine destruktive Antwort als Standard fest, es sei denn, es gibt eine einfache, offensichtliche Möglichkeit, den Befehl rückgängig zu machen.
• Auswahldialogfelder:
  • Wählen Sie für die anfänglichen Standardwerte die sichersten Werte für das jeweilige Steuerelement aus, um Datenverluste oder Systemzugriffe zu verhindern. Wenn Sicherheit kein wichtiger Faktor ist, wählen Sie die wahrscheinlichsten oder praktischsten Optionen aus.
  • Wählen Sie für die nachfolgenden Standardwerte wieder die zuvor ausgewählten Optionen aus, wenn diese Werte wahrscheinlich wiederholt werden und diese Vorgehensweise sicher ist. Wählen Sie andernfalls die anfänglichen Standardwerte aus.

In diesem Beispiel wählen Benutzer*innen höchstwahrscheinlich die gleichen Druckeinstellungen aus wie beim letzten Mal. Die Anzahl der gewünschten Kopien ändert sich aber wahrscheinlich. Daher wird diese Einstellung nicht erneut ausgewählt.

Empfehlungen für Dimensionierung und Abstand

• Unterstützen Sie die Mindestbildschirmauflösung von Windows Vista (800 × 600 Pixel). Layouts können für Fenster mit anpassbarer Größe mit einer Bildschirmauflösung von 1.024 × 768 Pixel optimiert werden.
• Verwenden Sie nach Möglichkeit Fenster mit anpassbarer Größe, um Scrollleisten und abgeschnittene Daten zu vermeiden. Fenster mit dynamischem Inhalt und Listen profitieren am meisten von Fenstern mit anpassbarer Größe.
• Fenster mit fester Größe müssen vollständig sichtbar und so dimensioniert sein, dass sie in den Arbeitsbereich passen.
• Fenster mit anpassbarer Größe können für höhere Auflösungen optimiert und bei Bedarf zur Anzeigezeit auf die tatsächliche Bildschirmauflösung verkleinert werden.
• Wählen Sie eine für den Inhalt geeignete Standardfenstergröße. Scheuen Sie sich nicht davor, anfänglich größere Fenster zu verwenden, wenn Sie den Platz effektiv nutzen können.

Text

Allgemein

• Entfernen Sie redundanten Text. Suchen Sie nach redundantem Text in Titeln, Hauptanweisungen, ergänzenden Anweisungen, Inhaltsbereichen, Befehlslinks und Commitschaltflächen. Behalten Sie generell den vollständigen Text in Anweisungen und interaktiven Steuerelementen bei, und entfernen Sie alle Redundanzen an anderen Stellen.
• Verwenden Sie positive Formulierungen. Positive Formulierungen sind für Benutzer*innen einfacher zu verstehen.

Richtig:

Möchten Sie die Datei- und Druckerfreigabe aktivieren?

Falsch:

Möchten Sie die Datei- und Druckerfreigabe deaktivieren?

Die Formulierung muss jedoch zum zugeordneten Befehl passen, auch wenn der Befehl negativ formuliert ist. Verwenden Sie also beispielsweise „Deaktivieren“, um einen Deaktivierungsbefehl zu bestätigen.

• Verwenden Sie bei Bedarf das Wort „Fenster“, um auf das Dialogfeld zu verweisen.
• Verwenden Sie in der Hauptanweisung und im Inhaltsbereich die zweite Person (Sie/Ihr/Ihre), um Benutzer*innen darüber zu informieren, was zu tun ist. Oft ist die zweite Person impliziert.

Beispiele:

Wählen Sie die Bilder aus, die Sie drucken möchten.

Wählen Sie ein Konto aus.

• Verwenden Sie in Steuerelementen im Inhaltsbereich, die dazu dienen, auf die Hauptanweisung zu reagieren, die erste Person (ich/mir/mein/meine), damit Benutzer*innen dem Programm mitteilen können, was zu tun ist.

Beispiel: Fotos von meiner Kamera drucken

Dialogfeldtitel

• Verwenden Sie den Titel, um deutlich zu machen, zu welchem Befehl, Feature oder Programm ein Dialogfeld gehört.
  • Verwenden Sie bei benutzerseitig initiierten Dialogfeldern den Namen des Befehls oder Features zur Identifizierung. Ausnahmen:
    • Wenn ein Dialogfeld von vielen verschiedenen Befehlen angezeigt wird, empfiehlt es sich gegebenenfalls, stattdessen den Programmnamen zu verwenden.
    • Wenn dieser Titel mit der Hauptanweisung redundant wäre, verwenden Sie stattdessen den Programmnamen.
  • Wenn das Dialogfeld programm- oder systemseitig (und somit außerhalb des Kontexts) initiiert wurde, identifizieren Sie es anhand des Programm- oder Featurenamens, um Kontext bereitzustellen.
  • Verwenden Sie den Titel nicht, um zu erklären, was im Dialogfeld zu tun ist. Hierzu wird die Hauptanweisung verwendet.
• Verwenden Sie bei befehlsbasierten Namen den exakten Befehlsnamen, lassen Sie aber die Auslassungspunkte weg (sofern vorhanden). Bei Bedarf können Sie den Menütitel des Befehls einschließen, um einen geeigneten Titel zu erstellen. Beispiel: Verwenden Sie für einen Befehl vom Typ „Objekt...“ in einem Einfügemenü den Titel „Objekt einfügen“.
• Wenn ein nicht modales Dialogfeld auf der Taskleiste angezeigt wird, optimieren Sie den Titel für die Anzeige auf der Taskleiste, indem Sie wichtige Informationen an den Anfang stellen. Beispiele: „66 % abgeschlossen“ oder „3 Erinnerungen“.
• Schließen Sie die Wörter „Dialogfeld“ und „Fortschritt“ nicht in den Titel ein. Sie sind impliziert, und ohne diese Wörter ist der Titel für Benutzer*innen leichter zu erfassen.
• Verwenden Sie Groß-/Kleinschreibung für Titel ohne Interpunktion am Ende.

Hauptanweisungen

• Verwenden Sie die Hauptanweisung, um mit wenigen Worten zu erklären, was im Dialogfeld zu tun ist. Die Anweisung muss eine spezifische Aussage, eine Aufforderung oder eine Frage sein. Gute Anweisungen kommunizieren das Ziel, das Benutzer*innen mit dem Dialogfeld verfolgen, anstatt sich nur auf die Mechanik der Bearbeitung zu konzentrieren.
• Lassen Sie die Hauptanweisung weg, wenn das, was damit kommuniziert würde, offensichtlich ist. In solchen Fällen ist der Inhalt des Dialogfelds selbsterklärend. Beispielsweise benötigen die allgemeinen Dialogfelder „Datei öffnen“ und „Datei speichern“ keine Hauptanweisung, da ihr Kontext und Design ihren Zweck offensichtlich machen.
• Lassen Sie Steuerelementbezeichnungen weg, die die Hauptanweisung wiederholen. In diesem Fall wird die Zugriffstaste für die Hauptanweisung festgelegt.

Akzeptabel:

In diesem Beispiel ist die Bezeichnung des Textfelds nur eine Wiederholung der Hauptanweisung.

Besser:

In diesem Beispiel wird die redundante Bezeichnung entfernt und die Zugriffstaste für die Hauptanweisung festgelegt.

• Fassen Sie sich kurz, und verwenden Sie nur einen einzelnen, vollständigen Satz. Beschränken Sie die Hauptanweisung auf die wesentliche Information. Sollten weitere Erklärungen erforderlich sein, verwenden Sie ergänzende Anweisungen.
• Verwenden Sie nach Möglichkeit spezifische Verben. Spezifische Verben (wie „verbinden“, „speichern“ oder „installieren“) sind für Benutzer*innen aussagekräftiger als generische Verben (wie „konfigurieren“, „verwalten“ oder „festlegen“).
• Verwenden Sie eine für Sätze übliche Großschreibung.
• Schließen Sie bei Anweisungen keinen abschließenden Punkt ein. Beenden Sie Fragen mit einem Fragezeichen.
• Verwenden Sie für Statusdialogfelder eine Verlaufsform, um den aktiven Vorgang kurz zu erläutern, und platzieren Sie Auslassungspunkte am Ende. Beispiel: Ihre Bilder werden gedruckt...
• Tipp: Sie können eine Hauptanweisung bewerten, indem Sie sich vorzustellen, was Sie einem Freund oder eine Freundin sagen würden. Wenn die Hauptanweisung als Antwort unnatürlich, merkwürdig oder nicht hilfreich wäre, überarbeiten Sie sie.

Ergänzende Anweisungen

• Verwenden Sie bei Bedarf eine optionale ergänzende Anweisung, um zusätzliche hilfreiche Informationen zum besseren Verständnis oder zur Verwendung der Seite bereitzustellen. Sie können ausführlichere Informationen bereitstellen und Terminologie definieren.
• Wenn das Dialogfeld programm- oder systemseitig (und somit außerhalb des Kontexts) angezeigt wird, verwenden Sie die ergänzende Anweisung, um zu erläutern, warum das Dialogfeld angezeigt wird. Bei solchen Dialogfeldern ist der Kontext in der Regel nicht offensichtlich.
• Wiederholen Sie nicht einfach die Hauptanweisung mit anderen Worten. Lassen Sie stattdessen die ergänzende Anweisung weg, wenn es nichts hinzuzufügen gibt.
• Verwenden Sie vollständige Sätze, eine für Sätze übliche Großschreibung sowie Interpunktion am Ende.

Befehlslinks

• Verwenden Sie kurzen Linktext, der klar vermittelt und deutlich macht, wozu der Befehlslink dient. Es sollte selbsterklärend und auf die Hauptanweisung abgestimmt sein. Benutzer*innen sollten nicht erst ergründen müssen, was der Link wirklich bedeutet oder inwiefern er sich von anderen Links unterscheidet.
• Beenden Sie Befehlslinks immer mit einem Verb.
• Verwenden Sie die übliche Groß-/Kleinschreibung.
• Verwenden Sie keine Interpunktion am Ende.
• Geben Sie bei Bedarf weitere Erläuterungen in Form von vollständigen Sätzen mit Interpunktion am Ende an. Fügen Sie derartige Erläuterungen aber nur bei Bedarf hinzu. Außerdem ist es nicht erforderlich, Erläuterungen für alle Befehlslinks hinzuzufügen, nur weil bei einem der Befehlslinks eine Erläuterung nötig war.

Weitere Informationen und Beispiele finden Sie in den Richtlinien zu Befehlslinks.

Commitschaltflächen

• Verwenden Sie spezifische, selbsterklärende Commitschaltflächenbezeichnungen, die eine Antwort auf die Hauptanweisung sind. Im Idealfall sollten Benutzer*innen keinen weiteren Text lesen müssen, um die Bezeichnung zu verstehen. Benutzer*innen lesen viel eher Befehlsschaltflächenbezeichnungen als statischen Text.
• Beenden Sie Commitschaltflächenbezeichnungen mit einem Verb. Ausnahmen sind „OK“, „Ja“ und „Nein“.
• Verwenden Sie die übliche Groß-/Kleinschreibung.
• Verwenden Sie keine Interpunktion am Ende.
• Weisen Sie eine eindeutige Zugriffstaste zu.
  • Ausnahme: Weisen Sie den Schaltflächen „OK“ und „Abbrechen“ keine Zugriffstaste zu, da hierfür die EINGABETASTE bzw. die ESC-TASTE verwendet wird. Das erleichtert die Zuweisung der anderen Zugriffstasten.

Dokumentation

Bei Verweisen auf Dialogfelder gilt:

• Bezeichnen Sie Dialogfelder in der Programmierdokumentation sowie in anderen technischen Dokumentationen als Dialogfelder. Verwenden Sie an allen anderen Orten jeweils den Titel des Dialogfelds. Ist die Titelleiste ausgeblendet, verwenden Sie die Hauptanweisung, um auf das Dialogfeld zu verweisen.
• Wenn Sie ganz allgemein auf ein Dialogfeld verweisen müssen, verwenden Sie den Begriff „Fenster“ in der Benutzerdokumentation. Ein einfaches Fragedialogfeld oder eine Bestätigung kann als Nachricht bezeichnet werden.
• Verwenden Sie den exakten Titel oder den Text der Hauptanweisung (einschließlich der Großschreibung).
• Formatieren Sie den Titel nach Möglichkeit fett. Andernfalls können Sie den Titel in Anführungszeichen setzen, falls dies erforderlich ist, um Verwirrung zu vermeiden.

Beispiel: Klicken Sie unter Windows-Sicherheit auf Weitere Optionen.