Objektbezogenes Undo

Usability Pattern	Objektbezogenes Undo
Problem	Benutzer möchten Aktionen rückgängig machen, die sie für ein Objekt versehentlich oder irrtümlich ausgeführt haben oder deren Resultate nicht ihren Erwartungen entsprechen.
Lösung	Erlaube Benutzern, ausgeführte, objektbezogene Aktionen rückgängig zu machen und den vorigen Zustand des Objekts wiederherzustellen. Die objektbezogene Undo-Möglichkeit gleicht in weiten Teilen dem Globalen Undo . Allerdings wird beim objektbezogenen Undo für verschiedene Datenobjekte, die Benutzer mit dem System verwalten, jeweils eine eigene Undo-Historie verwendet. Dadurch können Benutzer Aktionen für einzelne Objekte rückgängig machen, unabhängig von zwischenzeitlich auf anderen Objekten ausgeführten Aktionen.
Nutzungskontext	Interaktive Systeme, die atomare, für den Benutzer erkennbar separierte Aktionen auf einzelnen Datenobjekten erlauben, z. B. Verwaltungsoperationen (Erzeugen, Löschen, Ändern etc.) Nutzungssituationen, bei denen Benutzer abwechselnd verschiedene Datenobjekte verwalten und gegebenenfalls Änderungen für einzelne Objekte rückgängig machen müssen
Begründung	Die Möglichkeit, Aktionen rückgängig zu machen, nimmt Benutzern die Furcht vor einer Fehlbedienung des Systems und ermutigt sie, die vom System angebotenen Aktionen ausprobieren (explorative Nutzung). Das Wissen darum, das Fehler nicht dauerhaft sind, sondern per Undo einfach korrigiert werden können, lässt Benutzer entspannter und zufriedener arbeiten. Die schnelle Fehlerkorrektur per Undo erhöht zudem die Benutzungseffizienz.
Gestaltungsgrundsätze	Lernförderlichkeit, Steuerbarkeit, Fehlertoleranz
Risiken, Nachteile, Kosten	Beim objektbezogenen Undo verwaltet das System mehrere Undo-Historien, innerhalb derer Benutzer Aktionen rückgängig machen und ggf. wiederherstellen können. Für Benutzer kann dies verwirrend sein, wenn sie z.B. eine Aktion auf einem Datenobjekt ausführen, dann zu einem anderen Datenobjekt wechseln und dort die Möglichkeit vermissen, die gerade ausgeführte Aktion zurückzunehmen (da die Undo-Historie des nun aktiven Datenobjekts leer ist). Ein globales Undo mit einer einzelnen Undo-Historie ist leichter verständlich, allerdings nicht so flexibel wie das objektbezogene Undo.
Zusammenspiel	Alternative Globales Undo Alternativ zur objektbezogenen Undo-Möglichkeit kann auch ein globales Undo angeboten werden, bei dem eine einzelne Undo-Historie für alle Aktionen geführt wird. Abhängigkeit Warnung In nahezu allen Systemen können Benutzer Aktionen ausführen, die aus technischen oder konzeptuellen Gründen nicht rückgängig gemacht werden können. Benutzer sollten darauf durch eine entsprechende Warnung explizit hingewiesen werden, damit sie nicht irrtümlich davon ausgehen, auch diese Aktionen per Undo zurücknehmen zu kömmen.
Anforderungserhebung	Identifiziere die Arten von Datenobjekten, die Benutzer mit dem System verwalten (z. B. verschiedene fachliche Datensätze). Für Objekte welcher dieser Arten soll jeweils eine eigene Undo-Historie geführt werden? Identifiziere Aktionen, die rückgängig gemacht werden können. Welche dieser Aktionen verändern Daten oder wesentliche Einstellungen, welche lediglich Darstellungsparameter? Welche dieser Aktionen können von Benutzern nur mit größerem Aufwand manuell zurückgenommen werden (z. B. durch das erneute Eingeben eines versehentlich gelöschten Datensatzes)?
Anforderungsspezifikation	Spezifiziere globale Anforderungen für das Usability Feature „Objektbezogenes Undo“ des Systems: Globaler ParameterObjektartenBenötigt Vorgabe der Arten von Objekten, bei denen für jedes Objekt eine eigene Undo-Historie geführt werden soll, um Benutzer ein objektbezogenes Undo zu ermöglichen Beispiel: „ Fachliche Datensätze mit objektbezogener Undo-Möglichkeit: Kunden, Rechnungen, Aufträge “ Globaler ParameterUndo-VerhaltenBenötigt Vorgabe der Undo-Strategie: Länge der Undo-Historie (max. Anzahl zurückzunehmender Aktionen), Einzel-Undo oder Mehrfach-Undo (Rückgängigmachen mehrerer Aktionen auf einmal) Beispiel: „ Lineares Undo: Benutzer sollen die jeweils zuletzt ausgeführte Aktion auf einem Objekt rückgängig machen können. Die Undo-Historie für jedes Objekt soll maximal die 10 zuletzt ausgeführten Aktionen umfassen. “ Globaler ParameterRedo-VerhaltenOptional Vorgabe der Redo-Strategie: Einzel- oder Mehrfach-Redo. Nur notwendig, falls Benutzern eine Redo-Möglichkeit angeboten werden soll. Beispiel: „ Benutzer sollen die jeweils zuletzt zurückgenommene Aktion einzeln wiederherstellen können. “ Globaler ParameterMehrbenutzerverhaltenOptional Vorgabe des Undo-/Redo-Verhaltens bei Mehrbenutzersystemen, d. h. bei paralleler Ausführung von Aktionen durch mehrere Benutzer (ggf. auf denselben Daten) Beispiel: „ Bei paralleler Bearbeitung der Datensätze durch mehrere Benutzer sollen Benutzer eigene und Aktionen anderer Benutzer rückgängig machen können. “ Spezifiziere, in welchen Interaktionen zwischen Benutzern und System das Usability Feature „Objektbezogenes Undo“ eingesetzt werden soll. Annotiere und ergänze dazu vorhandene Use Cases in der Spezifikation: Annotation @ Ablauf Objekt-UndoBenötigt Benutzer soll diesen Ablauf objektbezogen rückgängig machen können. Lokaler ParameterObjektartOptional Angabe der Art des Objekts, das durch diesen Ablauf verändert wird. Lokaler ParameterBedingungOptional Angabe der Bedingung, unter der der Benutzer den Ablauf rückgängig machen kann. Beispiel: „Das Dokument wurde zwischenzeitlich nicht gespeichert.“
Architekturentwurf	Um Aktionen objektbezogen rückgängig zu machen (Undo) bzw. wiederherzustellen (Redo), muss das System für jedes Datenobjekt die ausgeführten Aktionen in einer eigenen Historie protokollieren. Auf Architekturebene werden hierfür oft zwei Entwurfsmuster verwendet werden: Das Kommando-Entwurfsmuster (command pattern) erlaubt die Kapselung von Aktionen als Objekte, die alle für die Ausführung bzw. Rücknahme benötigten Informationen enthalten. Mit dem Memento-Entwurfsmuster (memento pattern) kann der aktuelle Zustand von Datenobjekten (z. B. fachlichen Datensätzen) gespeichert und so zu einem späteren Zeitpunkt wiederhergestellt werden.