Prozesse

Nicht jede Interaktion mit dem Computer ist so feingranular, dass auf einen Tastenanschlag, einen Mausklick oder einen Tipp auf einen Touchscreen die ausgelöste Aktion so schnell beendet werden kann, dass das System unmittelbar danach für weitere Eingaben zur Verfügung steht. Im vorherigen Kapitel Rückmeldungen klang bereits an, dass Abläufe im Computer auch länger dauern können. Zudem lassen sich die zu erledigenden Aufgaben nur selten auf eine einzelne Eingabe mit entsprechender Rückmeldung reduzieren. Stattdessen bestehen sie aus zusammengesetzten Einheiten, etwa während eines Bestellvorgangs im Internet oder wenn eine Datei per Drag and Drop von einem Fenster in ein anderes geschoben werden soll.

Es gibt wohl kaum Situationen, in denen das Gefühl von erzwungenen Sequenzialitäten ähnlich stark ausgeprägt ist wie bei langlaufenden Prozessen, während derer eine weitere Nutzung blockiert ist. Die im vorherigen Kapitel vorgestellten fortlaufenden Rückmeldung geben zumindest Informationen über den Fortschritt des Prozesses und, im Falle automatischer Abläufe, über die voraussichtliche Laufzeit. Wenn solche Rückmeldungen früh genug erfolgen, ermöglichen sie es, alternative Handlungsstrategien zu entwickeln, also einen Prozess nur in Gang zu setzen, wenn es gerade passt, oder die noch verbleibende Zeit für eine Pause zu nutzen. Es können sich aber viele Probleme ergeben, die zu einem Gefühl des Gefangen- oder Fremdgesteuert-Seins führen können:

1. Es kommt vor, dass beim Anstoßen eines Prozesses nicht absehbar ist, wie lange er tatsächlich dauern wird.
2. Insbesondere kann ein Prozess auch versehentlich oder mit falschen Parametern gestartet worden sein, indem beispielsweise statt einer gleich hundert Dateien geöffnet werden.
3. Auch bei einer angenommenen langen Dauer können weitere zusätzliche Problem auftreten.
4. Die Entscheidung, bei einem langlaufenden automatischen Prozess parallele Aktivitäten zu starten, erfordert trotzdem den gelegentlichen Blick auf den Bildschirm, um zu sehen, ob der Prozess mittlerweile beendet worden ist.

In all diesen Fällen entstehen erzwungene Sequenzialitäten, denn man kann nicht so weitermachen, wie man es möchte, ist sich nicht darüber bewusst, dass man mit einer bestimmten Aufgabe weitermachen könnte und wartet daher unnütz oder man sieht sich genötigt, ständig zu überprüfen, in welchem Zustand sich das Softwaresystem gerade befindet. Diesen Problemen begegnen wir in diesem Kapitel mit den Anforderungen nach Attentionalität und Beeinflussbarkeit.

Ereignisbehandlungen

Um die Notwendigkeit, ständig überprüfen zu müssen, ob sich ein bedeutsamer Objekt- oder der Systemzustand geändert hat, stellen wir den Rückmeldungen aus dem vorherigen Kapitel Ereignisse an die Seite. Sie dienen dazu, auf solche Objekt- oder Systemzustandsänderungen hinzuweisen.

Im vorherigen Kapitel haben wir gefordert, dass ein digitales System auf eine Eingabe stets lokal, unmittelbar und differenziert mit einer Rückmeldung reagieren muss. Doch nicht jede dynamische Anzeige einer Software ist eine Rückmeldung im engeren Sinne. In vielen Fällen passieren Dinge, die von einer unmittelbar zuvor erfolgten Eingabe unabhängig sind. Wir bezeichnen solche Änderungen als „Ereignisse“. Beispiele für Ereignisse sind das Eintreffen einer neuen E-Mail im E-Mail-Programm, eine eingehende Textnachricht auf dem Smartphone, der Umstand, dass ein Videoexport fertig ist, oder die Mitteilung des Betriebssystems, dass die Kapazität der Festplatte nahezu ausgeschöpft ist. In diesen Ereignissituationen gilt es den Grund anzuzeigen, um angemessen darauf reagieren zu können.

Die Begriffe „Ereignis“ und „Ereignisbehandlung“ kennen Informatiker auch aus der Programmierung. Wie schon beim Objektbegriff, als es für uns nicht wichtig war, ob objektorientierte Programmierung eingesetzt wird, ist es irrelevant, ob in der Programmierung mit einem Ereignissystem und einem entsprechenden Listener-Konzept²² gearbeitet wird oder ob ein regelmäßiges Polling²³ stattfindet. Relevant ist für uns das Ereignis auf der Ebene der Nutzungsschnittstelle.

Die Ereignisbehandlungen weisen Ähnlichkeiten mit Rückmeldungen auf. So gilt nach wie vor die Forderung nach Differenziertheit. Die Meldung, die auf Grundlage eines Ereignisses ausgegeben wird, muss also sowohl hinreichend Feed-Back- als auch Feed-Forward-Informationen bieten. Die weiteren Forderungen an Rückmeldungen, Unmittelbarkeit und Lokalität, lassen sich bei der Ereignisbehandlung indes nicht umsetzen, denn Ereignisse treten qua Definition nicht unmittelbar im Zusammenhang mit einer Eingabe auf. Damit entfällt auch die Lokalität als Gestaltungsmittel, denn die Annahme des aktuellen Ortes der Aufmerksamkeit haben wir an die Grundthese gekoppelt, dass der Ort der Eingabe auch der Ort der Aufmerksamkeit ist. Wenn es aber keinen direkten Zusammenhang zu einer Eingabe gibt, fehlt die Grundlage für die Umsetzung der Forderung nach Lokalität. Wir wissen bei Ereignissen noch nicht einmal, ob jemand gerade auf den Bildschirm schaut bzw. der Computer aktiv verwendet wird. An die Stelle von Lokalität und Unmittelbarkeit tritt bei Ereignissen deshalb die Forderung nach Attentionalität, also nach Aufmerksamkeitsleitung.

Einige Methoden zur Aufmerksamkeitsleitung haben wir bereits im Kapitel Architektur der Wahrnehmung kennengelernt. Dort haben wir zum Beispiel gesehen, dass Bewegungen im peripheren Wahrnehmungsbereich gut geeignet sind, die Aufmerksamkeit auf sich zu ziehen. Dies lässt sich auf die Gestaltung von Nutzungsschnittstellen übertragen. Bei MacOS beispielsweise springt ein Icon im Dock, wenn das dazugehörige Programm eine Meldung generiert, wenn es nicht das gerade verwendete Programm ist. Microsoft löst das Problem bei Windows ähnlich durch ein Blinken des entsprechenden Buttons in der Taskleiste. Auch in eigener Software kann man diese Technik nutzen und die Aufmerksamkeit durch Blinken oder Bewegungen auf Objekte lenken.

Bewegung im peripheren Sichtfeld erzeugt Aufmerksamkeit über den Sehsinn. Es hilft jedoch nichts, wenn der Bildschirm sich nicht im Wahrnehmungsbereich befindet. In diesem Fall müssen andere Sinne, das Gehör oder der Gefühlssinn, angesprochen werden. Klangausgaben und Vibrationen sind dazu gut geeignet. Der Klangausgabe kommt eine besondere Bedeutung zu, denn sie erlaubt als einzige eine Aufmerksamkeitsleitung auch in den Fällen, wo das Gerät, dass die Aufmerksamkeit auf sich lenken will, nicht Gegenstand der Wahrnehmung ist oder es sich nicht in sichtbarer Nähe befindet.

Das Aufmerksamkeitslenkungspotenzial von Tönen bringt jedoch auch Nachteile mit sich, denn es betrifft immer die gesamte Umgebung. Was für den einen eine erwünschte Aufmerksamkeitslenkung darstellt, ist für die andere eine unerwünschte Störung, denn im Gegensatz zu visuellen Reizen kann man nicht weghören. In der Konsequenz bedeutetet dies, alle Techniken zur Aufmerksamkeitsleitung so sparsam wie möglich einzusetzen, denn sie verkörpern optische, akustische und taktile Schreihälse. Es ist in Ordnung, wenn uns jemand laut „Vorsicht!“ zuruft, um zu vermeiden, dass es zu einem Unfall kommt, aber wenn wir ständig angeschrien würden, ständig jemand wild winken oder uns anstupsen würde, wären wir schnell genervt und würden uns dieses Benehmen verbitten. Werden vor allem Klänge und Vibrationen zu häufig eingesetzt, wächst die Wahrscheinlichkeit, dass sie abgeschaltet werden. Sind Klang und Vibration aber erst einmal ausgeschaltet, gibt es keine Möglichkeit mehr, im wirklichen „Notfall“ doch noch für Aufmerksamkeit zu sorgen.

Attentionalität ist relativ undifferenziert

Die von uns vorgestellten Techniken zur Aufmerksamkeitsleitung haben gemeinsam, dass sie sich nicht dazu eignen, differenziert auf einen Umstand hinzuweisen. Zwar wäre es grundsätzlich möglich, verschiedene Klänge, verschiedene Bewegungsarten oder verschiedene „Vibrationsmuster“ für unterschiedliche Ereignisse zu verwenden, doch sind diese Rückmeldungen in ihrer Aussagekraft eingeschränkt. Bei Tönen und Bewegungen kommt noch hinzu, dass diese in der Regel nur kurz auftreten. Da es in der Natur der Sache liegt, dass die Aufmerksamkeit zur Zeit des Eintritts des Ereignisses woanders liegt, kann man bei der Gestaltung eines Systems nicht davon ausgehen, dass der Ereigniston zugleich den Ereignisgrund signalisiert.

Da solche Attentionalitäts-Techniken nicht differenziert sind, bedarf es weiterer Design-Elemente, um der im vorherigen Kapitel besprochenen Forderung nach Differenziertheit entsprechen zu können. Dies kann zum Beispiel eine Einblendung oder auch eine Meldungsbox sein. Eine solche Meldung komplementiert eine Aufmerksamkeitsleitung durch ein Geräusch sehr gut, denn in ihr kann zum einen umfangreich beschrieben werden, worum es geht und sie bleibt in der Regel so lange sichtbar, wie es notwendig ist, also etwa bis ein Missstand abgestellt ist oder bis der Nutzer die Meldung quittiert.

Beeinflussbarkeit

Die Forderung nach Attentionalität sorgt dafür, dass wichtige Ereignisse, wenn sie eintreten oder wenn sie eingetreten sind, entsprechend signalisiert werden. Wenn sie gut umgesetzt wird, sorgt sie für eine erhebliche Aufwandsreduktion, da der Aufwand entfällt, sich kontinuierlich auf dem Laufenden zu halten. Auch bei der zweiten Forderung zur Gestaltung von Prozessen, der Beeinflussbarkeit, geht es darum, eine möglichst maximale Handlungsflexibilität zu ermöglichen.

In diesem Beispiel der Apple-Präsentationssoftware Keynote ist schon die basalste Form der Beeinflussbarkeit nicht gegeben. In diesem Beispiel sollen Folien aus dem rechten Fenster in das linke Fenster kopiert werden. Dabei ist nicht berücksichtigt worden, dass die Folien viele Videos enthalten und sich zudem auf Netzlaufwerken befinden. Diese ungünstige Konstellation führt dazu, dass an ein Weiterarbeiten nicht zu denken ist, das Kopieren sehr lange dauert und das Programm während des Übertragungsvorgangs das System blockiert. Die ins Stocken gekommene Statusanzeige lässt zudem nichts Gutes vermuten. Zwei Gestaltungsdefizite treten zutage. Zum einen ist die Rückmeldung in keiner Weise differenziert, eine Abschätzung der Zeitdauer folglich nicht möglich. Zum anderen gibt es keine Möglichkeit der Einflussnahme auf den Kopierprozess. Es hätte sich angeboten, entweder nicht pauschal alle Folien zu kopieren, sondern nur einige, oder aber die Folien vorher auf die lokale Festplatte zu kopieren. Dazu hätte man den aktuellen Vorgang abbrechen müssen. Ein Abbrechen ist aber nicht vorgesehen. Es ist nur eine erzwungene Beendigung des Programms mithilfe eines Taskmanagers möglich, wobei jedoch alle Änderungen, die bis zu diesem Zeitpunkt erfolgt sind, verloren gehen.

Abbrechbarkeit

Es gibt eine Vielzahl von Gründen, einen angestoßenen Prozess abbrechen zu wollen. Im obigen Beispiel ist vor Beginn nicht ersichtlich gewesen, dass der Vorgang übermäßig lange dauern würde. Auch kommt es immer wieder vor, dass Prozesse versehentlich oder mit den falschen Parametern gestartet werden.

Jede Rückmeldung zu einem Prozess, der mehr als wenige Sekunden dauert, braucht daher die Möglichkeit zum Abbrechen. Ob dies der Fall ist, muss im Sinne einer differenzierten Rückmeldung ja ohnehin berechnet bzw. abgeschätzt werden. Die Beschriftung des Buttons mit dem generischen Begriff „Abbrechen“ ist in diesen Fällen unproblematisch, da die Fortschrittsanzeige bei einer differenzierten Rückmeldung den Prozess und seinen momentanen Bearbeitungszustand ohnehin anzeigt.

Auch Prozesse, die aus vielen Prozessschritten bestehen, sollten abbrechbar sein. Wird beispielsweise in einer Textverarbeitung ein Briefassistent gestartet, muss man diesen abbrechen können, wenn man die gewünschten oder fehlenden Hinweise erhalten hat oder sie nicht mehr benötigt. Wenn man es mit einer Reihe von Bildschirmmasken zu tun hat, die nacheinander aufgerufen werden – beispielsweise bei einem Bestellvorgang im Internet – sollte man jedoch die Abbruch-Option nicht mit „Abbrechen“ bezeichnen, da nicht klar ist, ob nur ein Prozessschritt oder der gesamte Vorgang abgebrochen wird.

Der Abbruch einer Aktion hat immer Konsequenzen, über die Klarheit herrschen muss. Die offensichtlichste Konsequenz ist, dass „Abbrechen“ die gestartete Operation ungeschehen macht. Die Konsequenzen eines Abbruchs können auch anderer Art sein, etwa dass eine Web-Anwendung nicht genutzt werden kann, weil der Anmeldeprozess nicht zu Ende gebracht werden konnte, oder dass eine Festplatte nicht nutzbar ist, weil die Formatierung nicht bis zum Ende durchgeführt worden ist. Zu jedem Abbrechen gehört daher eine differenzierte Rückmeldung, die über die Konsequenzen informiert.

Grundsätzlich sollte das Abbrechen eines Prozesses den Zustand vor seinem Auslösen wiederherstellen. Das bedeutet zum Beispiel beim Verschieben von Dateien, dass beim Abbrechen die Dateien vollständig am Ursprungsort verbleiben oder wiederhergestellt werden und am vermeintlichen Zielort keine der Dateien auftaucht. Das kann schwierig werden, wenn zum Beispiel beim Verschieben Dateien am Zielort überschrieben werden. In so einem Fall gibt es zwei Reaktionsmöglichkeiten. Die erste wäre ein Hinweis während des Kopierens, dass überschriebene Dateien nicht wiederhergestellt werden können. Es gibt zwar eine differenzierte Rückmeldung, doch wird die Verantwortung für die Konsequenzen in die Nutzung verlegt. Die zweite – und dies wäre die weitaus bessere Variante – sorgt dafür, dass überschriebene Dateien zunächst in ein temporäres Verzeichnis verschoben werden und erst nach Beendigung des Prozesses gelöscht werden.

Es gibt einzelne Fälle, in denen ein Wiederherstellen des vorherigen Zustands nicht möglich ist, wie zum Beispiel beim Formatieren einer Festplatte. Ein Zurückkehren zum vorherigen Zustand würde bedeuten, dass der komplette vorherige Plattenzustand gespeichert und beim Abbrechen zurückgeschrieben werden müsste. Das wäre zwar grundsätzlich möglich, doch in den meisten Fällen nicht praktikabel. Weitere Beispiele von nicht oder nicht ohne Weiteres abbrechbaren Prozessen sind Betriebssystem-Updates oder das Patchen per USB angeschlossener Geräte. Ist ein Abbruch eines Prozesses nicht möglich, muss ein entsprechender Hinweis vor dem Beginn erscheinen, der die geschätzte Zeit für den Prozess im Vorfeld angibt.

Nicht abbrechbare Prozesse nie automatisch starten!

Nicht abbrechbare Operationen dürfen auf keinen Fall automatisch gestartet werden, wie das bei der Update-Funktion von Microsoft Windows der Fall war. Der Update-Prozess wurde unabhängig von der aktuellen Nutzungssituation gestartet. Welche Folgen das haben kann, zeigt die folgende Anekdote²⁴ aus dem Jahr 2015:

Ein Basketballspiel der Finke Baskets Paderborn gegen die Niners Chemnitz in der zweiten Basketball-Bundesliga begann 25 Minuten zu spät. Der Grund dafür war, dass das Laptop, das die Anzeigetafel in der Paderborner Basketballhalle steuerte, nicht zur Verfügung stand, da es gerade ein automatisch initialisiertes Windows-Update installierte. Nachdem das Spiel schließlich gestartet war, gewann Paderborn mit 69:62. Chemnitz legte jedoch wegen des verzögerten Spielbeginns Protest gegen die Spielwertung ein. Am grünen Tisch ging das Spiel an Chemnitz; Paderborn wurde mit einem zusätzlichen Punktabzug bestraft. Diese Strafe hätte den Abstieg der Paderborner Mannschaft aus der zweiten Basketball-Bundesliga bedeutet. In einer Berufungsverhandlung konnte die zusätzliche Punktstrafe glücklicherweise noch abgewendet werden.

Auch wenn viele Alltagssituationen nicht so gravierende Konsequenzen mit sich bringen sollten, erfüllt das automatische Starten nicht abbrechbarer Prozesse gewissermaßen den Tatbestand der Nötigung.

Abbrechbarkeit von Eingabeoperationen

Auch in Bezug auf Eingaben ist Abbrechbarkeit ein wichtiger Aspekt. Das beginnt bei Texteingaben, die erst verarbeitet werden, wenn sie komplett abgeschlossen sind. Bei Kommandozeilen wird eine eingegebene Zeile erst ausgeführt, wenn sie durch Drücken der Return-Taste abgeschlossen wird. Die komplette Eingabe bis zu diesem Punkt kann daher als eine Eingabehandlung angesehen werden. In modernen Kommandozeilen-Interpretern kann sie abgebrochen werden, indem man STRG + c (oder am Macintosh Command + c) drückt. Damit wird die Eingabe abgebrochen und eine neue, leere Kommandozeile wird angezeigt.

Ebenfalls wichtig ist die Abbrechbarkeit bei grafisch-räumlichen Nutzungsschnittstellen. Die Eingabe eines gerade gedrückten Buttons etwa kann durch Wegziehen des Mauszeigers oder des Fingers vom Button abgebrochen werden. Hier kommen speziell die Lift-Off-Strategien, die wir im Kapitel Eingaben bereits angesprochen haben, wieder zum Tragen, denn Lift-Off ist die Technik, die dafür sorgt, dass es überhaupt einen Zeitraum gibt, in dem die Handlung noch abgebrochen werden kann. Würde ein Button gleich beim Herunterdrücken der Maustaste oder beim Aufsetzen des Fingers auslösen, wäre das nicht mehr möglich.

Ziehen und Verschieben (Drag and Drop) ist auch eine Lift-Off-Technik, denn auch hier wird erst am Ende der Handlung, wenn man den Finger wieder vom Touch-Display oder von der Maustaste nimmt, eine Funktion ausgelöst. Während der Drag-and-Drop-Handlung muss eine kontinuierlich differenzierte Rückmeldung erfolgen, die angibt, was jeweils im Falle des Fallenlassens am aktuellen Ort geschehen würde. Die Drag-and-Drop-Aktion startet mit dem Aufsetzen des Fingers oder dem Klicken der Maustaste. Sobald die Aktion gestartet ist, muss es eine unmittelbare und differenzierte Rückmeldung geben. Das Objekt wird etwa als markiert ausgezeichnet und dem Mauszeiger angeheftet. Während der kompletten Aktion muss der Zustand, der beim Beenden der Aktion zu diesem Zeitpunkt eintreten würde, kontinuierlich verdeutlicht werden. Der Mauszeiger ändert in Abhängigkeit vom unter dem Mauszeiger befindlichen Objekt seine Form, um jeweils konkret anzuzeigen, was passieren würde, wenn man das Objekt nun fallen ließe.

Dadurch, dass eine Drag-and-Drop-Aktion kontinuierliche Rückmeldung verlangt, zeigt sich, dass es sich bei ihr um einen längeren Prozess handelt, der entsprechende Mechanismen zur Steuerung während des Ablaufs anbieten muss. Auch in diesen Fällen ist die Möglichkeit des Abbruchs erforderlich, um die Notwendigkeit zusätzlicher oder auch unnützer Eingaben zu reduzieren, die zum Herstellen des gewünschten Zustands getätigt werden müssten.

Rücknehmbarkeit

Eng mit der Abbrechbarkeit verwandt ist die Rücknehmbarkeit. Gemäß der Forderung nach Abbrechbarkeit soll es jederzeit möglich sein, die aktuelle Bearbeitung zu beenden und zum Ausgangszustand zurückzukehren. Rücknehmbarkeit fordert das Gleiche, nur dass der Prozess, der rückabgewickelt werden soll, bereits abgelaufen ist. Es handelt sich also um eine Art „Abbrechen danach“. Die Möglichkeit, Prozesse sowohl abzubrechen als auch im Nachhinein zurücknehmen zu können, ermöglicht es, die Funktionalität einer Software zu explorieren. Interaktive Software, die die Anforderung nach Beeinflussbarkeit erfüllt, benötigt also eine „Rückgängig-Funktion“.

Die Umsetzung von Rückgängig-Funktionen beinhaltet viele komplexe Design-Entscheidungen. Dies beginnt mit der Granularität der Operationen. In LibreOffice beispielsweise ist beim Eingeben nicht jeder einzelne Buchstabe zurücknehmbar, sondern nur jedes Wort. In der Bildverwaltung und -bearbeitung Lightroom von Adobe wird schon das Wechseln zwischen zwei Bildern in der Ansicht als Aktion betrachtet, die zurückgenommen werden kann. Andere Gestaltungsmöglichkeiten beziehen sich darauf, wie viele Aktionen rückgängig gemacht werden können. Sehr simple Implementierungen erlauben nur ein einfaches „Undo“, also ein Rückgängigmachen der letzten Aktion. Das ist zwar besser als nichts, sorgt aber nicht für die beschriebene Sicherheit zum Explorieren, denn eine irrtümliche oder fehleingeschätzte Operation müsste unmittelbar nach der Aktion erkannt werden, um noch rückgängig gemacht werden zu können.

Zu einem Rückgängig, einem Undo, gehört auch das Gegenstück, das im Englischen „Redo“ genannt wird. Dies ermöglicht zum Beispiel ein Undo, das so weit zurück reicht, bis sich alles in einem Zustand befindet, der akzeptabel ist, um anschließend Schritt für Schritt im Redo die gemachten Operationen nachzuvollziehen. Im Deutschen wird die Redo-Operation oft mit „Wiederholen“ übersetzt. Diese Übersetzung ist irreführend, denn es wird ja keine Aktion ein weiteres Mal durchgeführt (im Sinne von „repeat“). „Wiederherstellen“ wäre eine bessere Übersetzung.

Generell ist ein Rückgängig-Machen in denselben Situationen schwierig, in denen auch ein Abbrechen schwer möglich ist. Sehr kompliziert wird das Rückgängig-Machen, wenn Objekte von mehreren Personen gleichzeitig bearbeitet werden. Was soll beispielsweise „Rückgängig“ bei einem kollaborativen Editor, wo mehrere Personen gleichzeitig schreiben können, bewirken? Werden nur die eigenen Aktionen oder auch die Aktionen anderer rückgängig gemacht? Wenn es nur die eigenen sind, diese Aktionen aber auf Grundlage der Handlungen anderer erfolgten, ist die Grundidee des Rückgängig-Machens, die Wiederherstellung des vorherigen Zustandes, nicht erfüllbar. Gilt ein Rückgängig für die Handlungen aller, entstehen andere Probleme. Um sie zu lösen, müsste es eine Art Änderungsprotokoll geben, in dem einzelne Operationen im Nachhinein entfernt werden können. Diese Art des Managements von Objektoperationen ist jedoch, ähnlich wie das Vorsehen mehrerer verschiedener Bearbeitungszustände in einer Bildverarbeitung, aufgabenabhängig und fällt damit in den Bereich der Gebrauchstauglichkeit.

Unterbrechbarkeit

In vielen Situationen ist eine Unterbrechung einem Abbruch vorzuziehen: zum Beispiel beim Kopieren großer Datenmengen von einem mobilen Gerät auf ein externes Speichermedium, wenn zwischenzeitlich das Gerät an einem anderen Ort genutzt werden soll.

In dem gezeigten Dialog ist das Kopieren eines großen Medienarchivs zu sehen. Es sind zwar schon dreißig Prozent kopiert, doch dauert der Prozess noch vier Stunden. Um die maximale Handlungsflexibilität in der Nutzung zu erhalten, ist die Möglichkeit einer Unterbrechung erforderlich, denn sonst müsste man den Prozess abbrechen und bei passender Gelegenheit von Neuem mit der Operation beginnen: eine Verschwendung von Zeit und Ressourcen bzw. gemäß unserer Leitlinie ein hohes Maß an erzwungener Sequenzialität.

Wenn eine Unterbrechung vorgesehen ist, gilt es, einige Punkte zu bedenken:

• Unterbrechen bedeutet, dass die Operation angehalten wird und alle notwendigen Informationen zur Fortsetzung gespeichert werden müssen. Das kann auch beinhalten zu speichern, dass eine bestimmte Netzwerkressource wieder zur Verfügung stehen muss, bevor eine Operation fortgesetzt werden kann.
• Durch das Unterbrechen wird die Operation, die unterbrochen worden ist, zu einem Objekt, das referenziert werden können muss. Es braucht also eine Erweiterung der Nutzungsschnittstelle, in der die unterbrochenen Prozesse zu sehen, wieder zu starten und abzubrechen sind.
• Ein Unterbrechen einer Operation kann, ähnlich wie ein Abbrechen, Folgen haben. Diese können weitreichender sein als die Wiederherstellung des vorigen Zustands beim Abbrechen, denn eine nur teilweise kopierte Medienbibliothek könnte sich durch die Unterbrechung in einem Zustand befinden, in dem sie nicht nutzbar ist. Auf solche Situation ist vor dem Unterbrechen differenziert hinzuweisen.

Richtig kompliziert wird es, wenn sich die Grundlagen, auf denen der ursprüngliche, jetzt unterbrochene Prozess abläuft, ändern. Im Falle eines halb kopierten Medienarchivs könnten zwischenzeitlich Strukturen im Ziel geändert oder aber Elemente in das zu kopierende Archiv hinzugefügt oder aus ihm entfernt werden. Soweit möglich sollten deshalb bei Unterbrechungen Änderungen am Archiv blockiert werden. Andernfalls sind Mechanismen vorzusehen, wie mit gegebenenfalls entstandenen Inkonsistenzen umgegangen werden soll.

Unterbrechbarkeit bei länger laufenden Bearbeitungen

Die Forderung nach Unterbrechbarkeit kann nicht nur bei langlaufenden Operationen angewandt werden, sondern gilt ebenso für lange Interaktionsfolgen. Der schon zuvor erwähnte Bestellvorgang sollte nicht nur jederzeit abbrechbar, sondern auch unterbrechbar sein, falls ein Teil der einzugebenden Daten gerade nicht vorliegt. Ohne Unterbrechbarkeit würde dies die erneute Eingabe aller bis zu diesem Zeitpunkt erfolgten Bestelleingaben erfordern.

Die Unterbrechbarkeit von Verarbeitungsschritten, wie zum Beispiel komplexen Eingaben in eine Datenbank, erfordert, dass Datensätze unabhängig von einer separat und bei Bedarf anzustoßenden Konsistenzprüfung schon erfasst werden können. Auf diese Weise kann der Mehraufwand, der sonst bei Nutzungsunterbrechungen erforderlich wäre, reduziert werden. Was wann und in welcher Reihenfolge zu tun ist, sollte nutzungsgetrieben und nicht systemgetrieben erfolgen. Voraussetzung ist jedoch, dass dem keine Sicherheitsbedenken entgegenstehen oder die Systemintegrität nachhaltig verletzt wird.

Zusammenfassend lässt sich feststellen, dass wir uns mit der Behandlung technischer Prozesse in einem Übergangsfeld zwischen Ergonomie und Funktionalität bewegen. Wie beim Übergang zwischen Ergonomie und Gebrauchstauglichkeit gehen wir damit über den von uns gesetzten Bereich ergonomischer Gestaltungsmaßnahmen hinaus. Neue Funktionalitäten und technische Innovationen werden jedoch in erster Linie von anderen Entwicklungsfaktoren als der Ergonomie getrieben, auch wenn die technischen Verbesserungen hinsichtlich einer flexiblen Nutzung zur Verbesserung der Gebrauchstauglichkeit beitragen oder intendiert sind. In diesem Abschnitt haben wir versucht, einige Gestaltungskonzepte vorzustellen, die nicht anwendungs- oder plattformspezifisch sind und deshalb übergreifend zu speziellen Betriebssystemen, Plattformen und Standards betrachtet werden können. Doch ist auch deutlich geworden, dass die Umsetzung ohne die Berücksichtigung des spezifischen technischen Kontextes nicht möglich ist. Dies betrifft beispielsweise auch viele Aspekte, die mit dem technischen Konzept der Nebenläufigkeit auftreten. Auch für diesen Bereich ließen sich einige anwendungs- bzw. plattformunabhängige Aspekte beisteuern, doch würden diese weitgehend im Bereich der Entwicklung technischer Plattformen liegen, weniger in der Ausprägung und Gestaltung ergonomischer Nutzungsoberflächen.