Exkurs: Mensch-Computer-Dialog

Obwohl die Idee, einen Computer mit Hilfe eines Dialogs zu steuern, technisch sehr aufwändig ist, wurde sie schon mit dem Aufkommen der Time-Sharing-Systeme in den 1960er Jahren propagiert. Später kamen Ideen eines computerisierten persönlichen Assistenten auf. Ein Video von Apple von 1987 etwa zeigt die Vision eines Knowledge Navigators, mit dessen Hilfe zum Beispiel eine wissenschaftliche Recherche durchgeführt werden kann und der gleich noch die Rolle der Telefonvermittlung übernimmt. Von solchen Szenarien sind wir nicht mehr weit entfernt. Dank KI-Sprachmodellen können wir uns mit einem Computer über wissenschaftliche Themen oder Kochrezepte unterhalten, fotorealistische Bilder erzeugen oder in Office-Software Folien automatisch generieren und per Text- oder Spracheingabe umformulieren lassen. Werden wir also bald alles durch ein Gespräch mit dem Computer erledigen? Hat die klassische Nutzungsschnittstelle ausgedient? Wenn das so wäre, dann wäre ja fast alles, was Sie in diesem Buch gelesen haben, bald obsolet. Lassen Sie uns deshalb ein paar Gedankenexperimente anstellen.

Wir stellen uns ein Computer-Assistenz-System vor, das perfekt funktioniert, also die gesprochene Sprache richtig erkennt und auch korrekt antworten und reagieren kann. In diesem angenommenen System gehen wir davon aus, dass es außer der Ein- und Ausgabe von Sprache keine andere Nutzungsschnittstelle gibt. Wir hätten somit einen Computer, den man für alle Arten von Aufgaben nutzen könnte, die man auch im Rahmen eines Telefonats erledigen kann. Man kann zum Beispiel das Wetter erfragen, etwas zu essen bestellen, Musiktitel abspielen, sich Geschichten oder neueste Informationen aus Wissenschaft und Technik vorlesen lassen und so weiter. Soweit dieses System auch Schnittstellen zu anderen technischen Komponenten hat, könnten wir beispielsweise auch Licht einschalten, Türen schließen, die Heizungstemperatur einstellen und vieles andere mehr.

Das Ganze hat aber seine Grenzen. Würden wir auf diese Art und Weise einen längeren Text wie z. B. einen Brief verfassen? Abgesehen davon, dass viele Menschen nicht in der Lage wären, ohne Vorlage druckreif zu sprechen (diktieren), müssten wir auch mit Unterbrechungen klarkommen und uns überlegen, wie wir Fehler korrigieren, wie wir jeweils spezifizieren, an welcher Stelle was wie ergänzt, geändert oder gestrichen werden soll. Wir gerieten in eine Situation, in der wir das bisher Gesprochene entweder komplett im Kopf haben oder ständig Teile des diktierten Textes neu erfragen müssten. Das ist äußerst unpraktisch oder, je länger der Text ist, sogar unmöglich. Erweitern wir das System also um einen Bildschirm zur Anzeige der Ausgabe, wobei die Eingaben weiterhin rein verbal erfolgen. Wir haben nun ein Computersystem, das wir per Textprompts bedienen können, das aber auch über eine Anzeige verfügt, auf der ein Text oder zumindest ein Ausschnitt davon dauerhaft zu sehen ist. Wir könnten ein solches System gut nutzen, um unter Vorgabe des gewünschten Inhalts und zusätzlicher Parameter einen Text generieren zu lassen. Doch wie geht es weiter, wenn der Text nicht perfekt ist, wenn hier und da etwas geändert oder wenn unterschiedliche Textteile zusammengefügt oder umgeordnet werden sollen?

Würden wir solche Arbeiten gerne rein verbal erledigen? Selbst unter der Annahme, dass wir ein KI-Gegenüber haben, das uns bestmöglich versteht, wäre das wohl keine gute Idee. Um das zu verdeutlichen, ersetzen wir die KI kurzfristig einmal um eine klassische, menschliche Intelligenz, mit der wir die gleiche Aufgabe durchführen wollen. Diese Nutzungsschnittstelle entspräche nun einer Art von Videotelefonat, bei dem die Person am anderen Ende der Leitung das Gehörte auf eine Tafel schreibt. Wir können die Tafel sehen und unserem Gegenüber laufend Anweisungen geben, wie das Tafelbild entsprechend unserer Vorgaben zu verändern ist. Diese Art der Manipulation hat jedoch den Nachteil, dass sprachliche Befehle zur Manipulation physischer Objekte – und nichts anderes ist ein Text ja – immer indirekt sind. Stellen Sie sich vor, Sie wollen in dem Text ein Wort einfügen. Anweisungen wie „Füge im zweiten Absatz, in der zweiten Zeile vor ‘wichtig’ ein ‘sehr’ ein“ sind zwar verständlich, aber nicht besonders praktisch. Statt sprachlich über die Beschreibung der räumlichen Lage oder des Aussehens anzugeben, welches Objekt gemeint ist, wäre es doch viel einfacher, direkt auf das entsprechende Objekt zu weisen und es zu bearbeiten. Unsere bisher vorgestellte Nutzungsschnittstelle sieht das aber nicht vor.

Wir müssten für Aufgaben der Objektmanipulation wie bei der Textverarbeitung die Objekte also nicht nur sehen, sondern auch räumlich verdeutlichen können, worauf wir uns jeweils beziehen wollen.³ Eine solche Nutzungsschnittstelle wäre also immer auch grafisch-räumlich, ganz unabhängig davon, ob die jeweiligen Operationen dann schlussendlich aus einem Menü ausgewählt oder in natürlicher Sprache eingegeben werden.

Die Möglichkeiten der natürlich-sprachlichen Interaktion mit dem Computer werden in der Zukunft sicher zunehmen. In einigen Bereichen mögen sie die heutigen grafischen Nutzungsschnittstellen ersetzen und ergänzen, in vielen anderen Fällen werden sie das aber wohl nie tun, denn die Errungenschaft, Objekte am Bildschirm räumlich darzustellen, auf diese zeigen und sie an Ort und Stelle bearbeiten zu können, kann genauso wenig durch rein verbale Kommunikation ersetzt werden, wie Tafelanschriebe, Mitschriften und gedruckte Texte nur durch Vorlesen und Zuhören sinnvoll erschlossen werden können.

Unabhängig von den Vor- und Nachteilen sprachlicher und direkt-räumlicher Interaktionen ist das Paradigma des Mensch-Maschine-„Dialogs“ mit zusätzlichen Problemen behaftet, die mit den Fähigkeiten von Sprachmodellen nichts zu tun haben.

Programmierte Dialoge?

In seinem Buch „The Art of Interactive Design“ schlägt Chris Crawford vor, dass eine Nutzungsschnittstelle einen Dialog nachahmen soll, um „freundlicher“ zu wirken. Er charakterisiert dazu den schwer zu fassenden Begriff der Interaktion als „a cyclic process in which two actors alternately listen, think and speak.“⁴ Ob moderne KI-Sprachsysteme dieser Charakterisierung entsprechen, hängt davon ab, was genau sie unter „listen“, „think“ und „speak“ verstehen und ob das, was in einem KI-Modell passiert, wirklich ein Denken und Verstehen ist. Wir lassen diese philosophische Frage an dieser Stelle unbeantwortet, denn die „Dialoge“, auf die Crawford anspielt, sind weit entfernt von der Interaktion mit einem solchen Sprachsystem. Es geht vielmehr um recht einfache, aber häufig anzutreffende Situationen, in denen für die Ausführung einer Operation zusätzliche Informationen benötigt werden, oder solche, bei denen unerwünschte Konsequenzen auftreten können. Eine klassische Situation dieser Art liegt zum Beispiel vor, wenn eingegebene Informationen noch nicht gespeichert worden sind und im nächsten Schritt verloren gehen könnten, etwa wenn die Software beendet werden soll, aber der Inhalt der zuvor bearbeiteten Datei noch nicht gespeichert worden ist. In diesem Fall sollten, so Crawford, die Konsequenzen verdeutlicht und die Möglichkeit der direkten Speicherung angeboten werden. Ganz recht! Diese Hinweise entsprechen nicht nur unseren Forderungen nach Differenziertheit der Rückmeldung und nach Beeinflussbarkeit, sondern sind auch gängige Praxis, um die Konsequenzen von Fehlhandlungen zu reduzieren.

Darüber hinaus schlägt Crawford in solchen Situationen vor, einen Dialog zwischen Mensch und Maschine zu simulieren und so zu tun, als würde der Computer über eigene Befindlichkeiten sprechen. Das Resultat wäre eine Meldung wie „Ich habe deinen Text noch nicht gespeichert. Wenn du das Programm jetzt schließt, geht dein Text verloren. Möchtest du das wirklich? Dies sind deine Möglichkeiten:“. Damit verbunden ist das Ziel, in einer Schnittstelle keine Aussagen mit Schuldzuweisungen zu formulieren oder unfreundliche oder rüde Ausdrucksweisen zu benutzen. Stattdessen fordert Crawford, dass die Meldungen die Schuld auf Seiten des Computers ausdrücken sollten, etwa in Titelzeilen wie „Ich brauche mehr Informationen“, „Ich kann damit nicht umgehen“ oder „Ich habe es vermasselt“.⁵

Da sind wir anderer Ansicht! Natürlich gilt es, bei Meldungen niemanden zu beschimpfen, sondern konstruktive Formulierungen zu verwenden, aber Meldungen in der Ich-Form auszugeben, den Computer sich selbst des Versagens bezichtigen zu lassen und durch Fragen Interesse an der nutzenden Person zu suggerieren, sind aufgesetzt und falsch. Formulierungen wie „Sind Sie sicher, dass sie das wirklich tun wollen?“ fragen persönliche Befindlichkeiten ab, auf die man unter anderen Umständen abgewogen antworten könnte. Etwa in der Art „Ich glaube schon, aber vielleicht sollte ich darüber nochmal nachdenken.“, „Ich bin generell keine sichere Person!“ oder „Lass mich damit jetzt in Ruhe!“? Doch solche auf Seiten des Systems „inakzeptablen“ Antworten offenbaren, dass es nicht um einen natürlichen Dialog geht. Vielmehr wird der Handlungsfluss absichtlich unterbrochen, indem das System erzwingt, eine Auswahl aus den vorgegebenen Handlungsoptionen zu treffen. Das ist sowohl inhaltlich als auch ergonomisch geboten, weil der mögliche Schaden in vielen Fällen den Aufwand einer zusätzlich erzwungenen Auswahl überwiegt. Die Software kann aber jeweils nur das „akzeptieren“, was bei der Entwicklung als Option vorgesehen worden ist.

Diese Meldung von OpenOffice stammt aus dem Jahre 2005. Sie erschien, wenn eine Datei in einem nicht unterstützten Dateiformat abgespeichert werden sollte. Nach Crawford müsste zunächst auf das Versagen der Software hingewiesen werden. In der Titelzeile müsste also „I screwed up“ stehen. Der Text sollte dann in der Ich-Form der Software die Schuld an der Misere zuweisen, etwa „I am not able to save your document properly in the format you selected. Some of the formatting or content might get lost, if you try anyway.“ Egal ob Aussagen oder Fragen, alle Elemente dieses „Dialogs“ sind vor der Nutzung entworfen und programmiert worden, weshalb sie nicht der von Crawford selbst angegebenen Definition einer Konversation entsprechen können, die er in folgendem Ablauf beschreibt: ⁶

1. Partner A hört Partner B zu und interpretiert die Worte zu einem großen Ganzen.
2. Partner A denkt über die Aussagen von Partner B nach, wägt sie ab und bildet sich in Gedanken eine Antwort.
3. Partner A antwortet Partner B, indem die Gedanken in Worte umgesetzt werden.
4. Nun macht Partner B dasselbe mit vertauschten Rollen.

Hier ist kein Sprachmodell am Werk, das eine Konversation führt und dessen Operationen man vielleicht, wenn man möchte, als zuhören, interpretieren, nachdenken und antworten bezeichnen könnte. Der Dialog ist (vor-)programmiert. Entwicklungszeit und Nutzungszeit sind getrennt. Zur Nutzungszeit können weder neue Fragen formuliert noch eigene Antworten kreiert werden. Die natürlich-sprachliche Interaktion reduziert sich auf die natürlich-sprachliche Beschriftung von vorgegebenen Auswahlalternativen. Das Resultat ist ein Pseudo-Dialog.

Das Hauptproblem dieses Pseudo-Dialog-Stils ist nicht eine Frage an sich, sondern das Erwarten einer Antwort, vor allem wenn die angebotenen Antwortoptionen auch noch generisch, also etwa mit „Ja“, „Nein“ oder „Okay“ vorgegeben werden. Eine Antwort wie „Ja“ oder „Nein“ auf den „Antwort“-Buttons bezieht sich inhaltlich stets auf die gestellte Frage, nicht auf die auszuführende Handlung bzw. den Folgezustand. Es ist also zusätzlicher mentaler Aufwand erforderlich, um auswählen zu können, welche Handlungskonsequenzen jeweils mit der generischen Antwortauswahl verbunden sind (Umsetzungsproblem). Dieser Zusatzaufwand soll in dem OpenOffice-Beispiel dadurch gemildert werden, dass zusätzlich textuell angegeben worden ist, was bei „Ja“ oder „Nein“ passiert. Doch stehen diese Informationen nicht am Ort der Handlung, dem zu drückenden Button, müssen somit an anderer Stelle erschlossen werden (Informationsbeschaffung). Wenn es kein grundsätzliches Problem bereitet, oberhalb der Buttons ihre Wirkungsweise darzustellen, warum schreibt man das dann nicht gleich auf die Buttons selbst? Der zusätzliche Übersetzungs- und Informationsbeschaffungsaufwand ist völlig unnötig! Selbstverständlich gilt weiterhin, dass zusätzliche Informationen z. B. über Nebeneffekte und Folgekonsequenzen hilfreich und teilweise notwendig sind, doch sollten sie nicht durch die Art der Gestaltung grundsätzlich erzwungen werden.

Begriffe wie Partner, Dialog oder Konversation machen in diesen, aus gutem Grunde programmierten Situationen keinen Sinn. Warum sollten wir sie dann simulieren, zumal durch den Pseudo-Dialog mehr Text entsteht, der wahrgenommen und interpretiert werden muss? Mögliche Verbesserungen, die wir nachfolgend beschreiben, tragen vielmehr dem Umstand Rechnung, dass es entscheidend ist, die der Entwicklung des Systems unterliegende Designrationalität für die Nutzung transparent zu gestalten bzw. offenzulegen.

Der Zweck der angezeigten ursprünglichen Meldung war nicht, situative Einschätzungen der Nutzungssituation zu erfragen. Vielmehr geht es bei solchen Meldungen darum, zwei (oder auch mehrere) Möglichkeiten des weiteren Programmablaufs zur Wahl zu stellen. Ein Pseudo-Dialog ist da hinderlich. Dies wird an der obigen Abbildung der gleichen Meldung aus dem Jahr 2008 deutlich, die eine Verbesserung mit sich bringt. Zwar wird unter der Problembeschreibung nach wie vor eine Frage gestellt, doch sind die Buttons jetzt mit dem Effekt beschriftet, der bei ihrer Auswahl eintritt. Ungeschickt ist allerdings die vage Angabe „aktuelles Format“ auf dem linken Button. Was das bedeutet, steht nach wie vor nur im Beschreibungstext, nicht am Ort der Handlung, dem Button.

Bis zum Jahr 2015 wurde die Meldung nochmals weiterentwickelt. Das einzige Überbleibsel des früheren Pseudo-Dialogs ist das Fragezeichen im Meldungs-Icon. Innerhalb des Meldungsfensters gibt es hingegen weder Fragen noch Antworten. Die Problembeschreibung ist in Fettschrift herausgestellt und die beiden Entscheidungsmöglichkeiten werden auf spezifisch beschrifteten Buttons angeboten. Auch die Beschriftung ist verbessert worden, denn auf den Buttons wird nicht mehr nebulös von einem aktuellen Format gesprochen, sondern dieses Format wird direkt angegeben.

Ist okay wirklich okay?

Eine sehr kritische „Antwortmöglichkeit“ in einer Meldung ist das „Okay“ bzw. das „OK“.

In dieser Meldung wird ungeheuerliches kundgetan! Teile des geschriebenen Textes sind verloren gegangen und das Einzige, was man darauf „antworten“ kann, ist „OK“. Das ist aber überhaupt nicht okay! „Okay“ ist eine Antwort auf eine Aussage, mit der der Gesprächspartner einverstanden ist. Es findet jedoch kein Dialog statt und es geht auch nicht darum, mit etwas einverstanden zu sein. Angemessener wäre die nüchterne Beschriftung „Schließen“ oder „Gelesen“, denn das ist der einzige Grund für den Button: Zur Entwicklungszeit ist nicht absehbar, unter welchen Umständen bzw. wie schnell Text gelesen oder zur Kenntnis genommen wird.

Vorsicht mit Humor!

In eine ähnliche Richtung der Simulation eines Dialogs oder einer Konversation geht die Idee, Meldungen mit Humor aufzulockern. Der Versuch, unerfreuliche Situationen durch lustige Meldungen angenehmer zu gestalten, steigert nur noch potentiell den Ärger über die Situation. Beim ersten Mal mag es noch lustig sein, beim zweiten Mal vielleicht auch noch, aber irgendwann schlägt es in Aggressivität um. Insbesondere wenn durch einen Fehler Arbeit verloren gegangen ist, sind Entsetzen und Ärger unmittelbar da. Humoristische Bemerkungen in Pseudo-Dialogen sind grundsätzlich fehl am Platz. Humor erfordert ein gehöriges Maß an Fingerspitzengefühl und Einfühlungsvermögen in die jeweilige Situation. Programmierte Meldungstexte können das aufgrund ihrer Natur nicht.

Hier sehen Sie ein Beispiel für eine vermeintlich humoristische Meldung. Die mit „I screwed up“ betitelte Meldung wird in dieser Art, der Idee des Mensch-Computer-Dialogs folgend, von Crawford empfohlen. Einen Knopf mit „Shoot the programmer!“ zu beschriften, ist weder konstruktiv noch hilfreich, möglicherweise aber geschäftsschädigend.

Auch YouTube witzelt in einer Fehlermeldung. Unabhängig davon, wie gelungen ein Scherz oder Witz sein mag, sind humoristische Einlagen bei Meldungen problematisch, weil sie in vielen Nutzungskonstellationen sowohl bei unterschiedlichen Personen als auch bei ein und derselben Person nicht vorhersehbar sind, sie keine sachlichen Zusammenhänge beschreiben und ein solcher Pseudo-Dialog verletzend und stressfördernd wirken kann. Die Gestaltungsmaxime lautet daher: Meldungen sollten sich immer auf die Offenbarung der Designrationalität beschränken, d. h. angeben, was die Ursache einer Meldung ist und welche Handlungsoption angeboten wird, jedoch nicht ungeprüfte Annahmen und Spekulationen über die Nutzungssituation und die Befindlichkeiten der beteiligten Personen. Diese sind nicht vorhersehbar und während der Nutzungszeit nicht korrigierbar. Designentscheidungen müssen sachlich, aber sehr zurückhaltend abgefasst werden.

Fazit

Bis auf Weiteres müssen wir davon ausgehen, dass die Metapher vom partnerschaftlichen Dialog zwischen Mensch und Maschine eine ergonomische Gestaltung von Nutzungsoberflächen erschwert, da durch die Pseudo-Dialoge Sachverhalte verschleiert und nicht transparent gestaltet werden. Meldungen und sogenannte Dialoge werden vor der Nutzungszeit festgelegt, müssen also darauf gerichtet sein, während der Nutzung zu beschreiben, warum sie auftreten und was jeweils getan werden kann. Verständnisbildung und Lernen findet in den Köpfen der Menschen während der Entwicklung bzw. Nutzung statt, nicht jedoch in der Maschine, da die beiden Phasen zeitlich voneinander getrennt sind. Das Hineinversetzen in Absichten oder emotionale Befindlichkeiten bringt eine zusätzliche, weitaus komplexere Dimension ins Spiel, ohne damit einen erkennbaren ergonomischen Zugewinn erzielen zu können. Ob das für immer so bleiben wird, ist zwar offen, doch zeigen unsere eingangs dieser Exkursion beschriebenen Szenarien, dass für viele Aufgaben eine ergonomische Gestaltung von Nutzungsoberflächen nicht auf eine räumlich-visuelle Einbettung verzichten kann.