Warnung

Usability Pattern	Warnung
Problem	Benutzer möchten vermeiden, Aktionen irrtümlich oder versehentlich auszuführen, wenn sie diese Aktionen nicht einfach rückgängig machen können und die Ausführung z. B. Daten- oder Zeitverlust zur Folge hat.
Lösung	Warne Benutzer vor der Ausführung irreversibler Aktionen. Weise auf die Konsequenzen der Ausführung hin und darauf, dass die Aktionen nicht rückgängig gemacht werden kann. Lass Benutzer die Ausführung explizit bestätigen und biete auch die Möglichkeit zum Abbruch. Dabei sollte bei der Art der erforderlichen Bestätigung die Schwere möglicher Konsequenzen berücksichtigt werden. Biete Benutzern ggf. die Möglichkeit, vor der Ausführung der Aktionen zunächst andere Aktionen auszuführen, wenn dadurch irreversible Konsequenzen vermieden werden können, z. B. durch Speichern von Daten vor dem Beenden des Programms. Biete Benutzern ggf. die Möglichkeit, bestimmte Warnungen dauerhaft zu deaktivieren.
Illustration	In einem Textverarbeitungsprogramm möchte der Benutzer ein ungespeichertes Dokument schließen. Das System warnt den Benutzer und weist darauf hin, dass das Dokument ungespeicherte Änderungen enthält, die verloren gehen, wenn der Benutzer fortfährt. Das System bietet dem Benutzer die Möglichkeit, fortzufahren, das Dokument zunächst zu speichern oder die Aktion abzubrechen und zum Dokument zurückzukehren.
Beispiele	Warnung und Sicherheitsabfrage beim Leeren des Papierkorbs in Mac OS X Apple Mac OS X: Papierkorb Gelöschte Dateien verbleiben unter Mac OS X zunächst im Papierkorb , bis der Benutzer diesen explizit „leert“. Das Entleeren des Papierkorbs ist irreversibel. Das System warnt den Benutzer deshalb ausdrücklich, weist auf die Konsequenz des Aktion „Papierkorb leeren“ hin und fordert eine Bestätigung, bevor die Aktion ausgeführt wird. Warnung bei ungespeicherten Änderungen in OpenOffice OpenOffice: Warnung bei ungespeicherten Änderungen OpenOffice zeigt eine Warnung an, wenn Benutzer ein Dokument schließen oder das Programm beenden möchten und Änderungen an einem geöffnetes Dokument noch nicht gespeichert wurden. Benutzer haben die Möglichkeit, die Änderungen zu verwerfen oder doch noch zu speichern.
Nutzungskontext	Nutzungssituationen, in denen Benutzer nur gelegentlich mit dem System arbeiten und die Konsequenzen, die die Ausführung einer Aktion mit sich bringt, nicht erkennen können Aktionen, deren Resultate Benutzer nicht oder nur mit erheblichen Aufwand rückgängig machen können Aktionen, die bei irrtümlicher oder fehlerhafter Ausführung schwerwiegende Konsequenzen, etwa den Verlust von Daten, zur Folge haben
Begründung	Warnungen dienen der Fehlervermeidung: Das System erlaubt Benutzern, die irrtümliche Ausführung von Aktionen und resultierende ungewollte Konsequenzen zu verhindern.
Gestaltungsgrundsätze	Selbstbeschreibungsfähigkeit, Erwartungskonformität, Fehlertoleranz
Risiken, Nachteile, Kosten	Häufige Warnungen können dazu führen, dass Benutzer die Warnungen nicht mehr ernst nehmen und die Ausführung von Aktionen unbesehen bestätigen. Die Zahl der Warnungen sollte somit auf das notwendige Maß beschränkt werden. Die Möglichkeit, Aktionen rückgängig zu machen, sollte gegenüber Warnungen bevorzugt werden. Warnungen unterbrechen den Interaktionsablauf, den Benutzer erwarten. Häufige Warnungen können insbesondere Benutzer, die lange und regelmäßig mit dem System arbeiten, bei der Arbeit stören. Diesen Benutzern muss deshalb ggf. die Möglichkeit gegeben werden, bestimmte Warnung dauerhaft zu deaktivieren (aber bei Bedarf auch wieder zu aktivieren).
Zusammenspiel	Alternative Globales Undo Das Usability Pattern Globales Undo (Rückgängigmachen ausgeführter Aktionen) erhöht ebenfalls die Fehlertoleranz, ohne dabei, wie im Fall von Warnungen, den von Benutzern erwarteten Interaktionsablauf zu unterbrechen.
Anforderungserhebung	Identifiziere Aktionen, die Benutzer nicht oder nur mit erheblichem Aufwand rückgängig machen können. Bei welchen dieser Aktionen soll eine Warnung angezeigt und eine explizite Bestätigung der Ausführung eingeholt werden? Was soll passieren, wenn der Benutzer die Ausführung abbricht? In welchen Fällen sollen neben Ausführung und Abbruch der Aktion noch Alternativen angeboten werden (z. B. das Speichern von Daten vor dem Beenden des Systems)? Überlege, wie die Warnungen gestaltet werden sollen. Wie sollen Benutzer die Ausführung der Aktion bestätigen oder abbrechen können? Gibt es unterschiedliche Warnungstypen, abhängig von den Konsequenzen der Aktion?
Anforderungsspezifikation	Spezifiziere globale Anforderungen für das Usability Feature „Warnung“ des Systems: Globaler ParameterDarstellungBenötigt Vorgabe für die einheitliche Darstellung von Warnungen. Beispiel: „ Das System zeigt Warnungen als modale Dialoge an. “ Spezifiziere, in welchen Interaktionen zwischen Benutzern und System das Usability Feature „Warnung“ eingesetzt werden soll. Annotiere und ergänze dazu vorhandene Use Cases in der Spezifikation: Annotation @ Schritt WarnungBenötigt Das System soll Benutzer vor Ausführung dieses Schritts warnen und auffordern, die Ausführung zu bestätigen. Lokaler ParameterBedingungOptional Angabe der Bedingung für die Warnung. Das System soll Benutzer nur warnen, wenn die Bedingung erfüllt ist. Beispiel: „Das Dokument enthält ungespeicherte Änderungen.“ Lokaler ParameterZusätzliche AlternativenOptional Angabe zusätzlicher alternativer Wahlmöglichkeiten, die das System dem Benutzer anbieten soll (neben den Möglichkeiten Bestätigung und Abbruch). Beispiel: „Speichern des Dokuments vor dem Schließen“ Erweiterung + Ablauf Ablauf bei AbbruchOptional Alternativer Ablauf, wenn der Benutzer nach Warnung durch das System die weitere Ausführung des bisherigen Ablaufs abbricht. Nur notwendig, wenn der Abbruch zusätzliche Interaktionsschritte verlangt. Erweiterung + Ablauf Ablauf bei AlternativeOptional Alternative Abläufe, wenn der Benutzer vor der weiteren Ausführung des bisherigen Ablaufs noch zusätzliche Aktionen ausführen und so irreversible Konsequenzen verhindern möchte.
Architekturentwurf	Warnungen können als reguläre modale Dialoge umgesetzt werden; sie müssen in der Architektur zumeist nicht speziell berücksichtigt werden. Bei einem Abbruch darf das System Änderungen nicht übernehmen.