GUI und Spiele

Die Grafikadventures haben seinerzeit – beginnend mit dem Erfolg von Maniac Mansion 1986 – die Landschaft der Computerspiele verändert. Es mußte bei den Abenteuerspielen nicht länger eine Wortfolge wie „Nimm Schlüssel” mit der Tastatur eingegeben werden, sondern der Spieler zeigte mit der Maus auf den Schlüssel und klickte anschließend auf den Befehl „Nimm”.

Ein Fakt, der oft ignoriert wird, ist, daß die Adventures den gleichen Weg nahmen wie die Betriebssysteme für Computer. Am Anfang standen Befehlsketten, die nur von Eingeweihten verstanden wurden, und vom Computer, wenn man sich nicht verschrieb. Ebenso kryptisch muteten die Befehlseingaben der Text-Adventures an. Das lag daran, daß der Parser nicht mit natürlicher Sprache umgehen konnte, die Spieler also in den Worten und der Syntax der Spiele denken und schreiben mußten. Es gab auch eine Spiele-Reihe mit einem sehr guten Parser; doch das Problem bestand stets darin, daß man entweder raten mußte, welche Befehle der Computer versteht, oder die Anleitung auswendig lernte.

Bei den Grafikadventures zeigte man einfach auf den Schlüssel im Grafikfenster – kannte der Computer diesen, zeigte er es an. Auch der Befehlswortschatz war stets erkennbar. Raten ade, Auswendiglernen ade. Falsche Kombinationen wurden freundlich kommentiert abgefangen „Ich kann das nicht nehmen.” Als angenehmer Nebeneffekt waren die Spiele auch deutlich einfacher zu lokalisieren, also in andere Sprachen zu übersetzen. Der Spieler sah beim Klicken auf den Schlüssel das Wort „Schlüssel”, während das Programm intern vielleicht mit „key” arbeitete. Aber ein englischer und ein deutscher Schlüssel sehen nun einmal gleich aus. Somit brauchten nicht mehr die Ortsbeschreibungen in ihren wichtigen Details und Finten übersetzt zu werden. Von der Umprogrammierung des Parsers ganz zu schweigen.

Es gibt ja auch keine deutsche DOS-Version, wohl aber deutsche Windows- und Mac-Versionen.

Objekt und Aktion

Der grundsätzliche Unterschied bestand und besteht in einem scheinbar grammatischen Detail. Bei der Bedienung einer grafischen Bedienoberfläche (auch Graphic User Interface, GUI, genannt) wird das Objekt angeklickt (z.B. das Icon) und erst danach die Aktion bestimmt (eine Mausaktion oder ein Befehl). Unter den Kommandozeilen-Interfaces (Command Line Interface, CLI) galt: erst die Aktion, dann das Objekt, z.B. „open file”.

Bei den Adventures wurde ebenfalls erst das Objekt angeklickt und anschließend der Befehl dazu. In der Befehlszeile entstand daraus eine sinnvolle Kombination, die nach einem Mausklick ausgeführt wurde (bei späteren Spielen wurde diese Prozedur vereinfacht und ein Klick eingespart, das Prinzip blieb dabei gleich). ABER: Ebenso konnte man erst auf den Befehl klicken und danach auf das Objekt. Das erschien logisch und entsprach in vielen Situationen auch dem eigenen Denken.

Frage: Denke ich „Der Schlüssel ist ein Element. Den möchte ich mitnehmen.” oder „Ich möchte etwas mitnehmen. Vielleicht den Schlüssel.”? Auf Betriebssystem-Ebene hieße das: „Diese Datei ist ein Element. Ich möchte sie kopieren.” oder „Ich muß etwas kopieren. Diese Datei dort.” Sicherlich wird je nach Situation die eine oder andere Strategie die effizientere sein.

Bei der Textverarbeitung und ähnlichen Programmen bzw. Programmteilen ist es vor allem durch Symbolleisten möglich, beide Strategien je nach Bedarf anzuwenden. Dabei fungieren die Symbolleisten zusätzlich auch als Statusleisten. Beispielsweise ist es möglich, Textteile zu markieren (Objekt) und dann auf Fett zu schalten (Aktion). Oder auf Fett schalten (Aktion) und erst danach den Text zu schreiben. Das Fett-Icon gibt jeweils darüber Auskunft, ob Fett aktiv ist oder nicht. Jedoch funktioniert es nicht, auf Fett zu schalten und dann durch schlichtes Markieren der Textteile diese einzufetten. Die Reihenfolge „erst Objekt, dann Aktion” ist höchst selten komplett umkehrbar.

Wenn ich im Dateibrowser oder Finder Dateien löschen oder bewegen will, muß ich erst die Dateien markieren und dann auf löschen oder bewegen klicken. Warum kann ich nicht löschen oder bewegen klicken und mir dann die Objekte dazu suchen? Warum können Spiele und diverse Programme diese verschiedenen Denkstrategien unterstützen, ein Betriebssystem jedoch nicht?

Ein Vorschlag

Beispielsweise ließe sich folgendes relativ einfach realisieren. Abgesehen von den bekannten Wegen, eine Datei zu bewegen, könnte ich auf Bewegen klicken, eine Box erscheint, die nach der Datei fragt und die aus dem Öffnen/Speichern-Dialog bekannte Auswahl bietet. Nach derAuswahl wird auf die gleiche Art der Zielort angewählt. Die Box enthält nun die Zusammenfassung „Bewegen von Datei/en nach Ort” und die Buttons „Bewegen starten” und „Abbrechen”. Durch intelligentes Design ließe sich auch eine Änderung aller Auswahlen integrieren. Die Box enthält während des Bewegens dann den Fortschrittsbalken. Zweiter Vorteil: Häufige Aktionen, z.B. Sicherheitskopien oder das Verschieben lokaler Dateien in das gemeinsam genutzte Verzeichnis lassen sich so leicht automatisieren.

Scheinbar ist es so viel komplizierter, aber es würde in vielen Bereichen dem Denken entsprechen. Und viel umständlicher als Datei finden, markieren, Zielort finden und Aktion mit der Maus oder über Ausschneiden – Einfügen scheint es mir auch nicht zu sein. Wenn es für die meisten Aktionen sowieso verschiedene Möglichkeiten gibt (z.B. Fenster schließen unter Windows: Schließ-Icon rechts, Doppelklick auf Icon links, Einfachklick auf Icon links und Auswahl „Schließen”, Taste „Steuerung” und „W” oder Taste „Alternative” und „F4”, rechter Mausklick auf Titelleiste und „Schließen”, rechte Maustaste auf Fenster in Taskleiste und „Schließen”; ohne Anspruch auf Vollständigkeit), warum kann dann nicht auch die Objekt-Aktion-Reihenfolge umgekehrt zur Verfügung stehen?

Das hätte nebenbei noch den Vorteil, nicht willkürlich viele unvorhersehbare Möglichkeiten anzubieten, sondern stets einander ergänzende. Denn warum sollte beispielsweise die Frage „Wollen Sie die Dateien wirklich bewegen” nicht durch die gleiche Box, wie ich sie oben geschildert habe, ersetzt werden. D.h. egal, ob zuerst die Aktion oder das Objekt bestimmt wird, das Ergebnis ist das gleiche und ich klicke nur noch auf „Bewegen starten”. Das gleiche gilt für „Wollen Sie die Dateien wirklich in den Papierkorb legen?”.

Das Erkennbare

Noch einmal zurück zu den zahlreichen Möglichkeiten, ein Fenster zu schließen. In dem Sinne der einfachen und einfachst verständlichen Objekt-Aktion-Beziehung kann dafür nur die Direkte Manipulation als adäquat erachtet werden. Das wäre das Schließsymbol direkt am Fenster und die Tastenkombination (für „Fortgeschrittene”). Alle anderen Varianten sind schlecht bis gar nicht erkennbar (ein Streitfall wäre das Kontextmenü der Titelleiste) und widersprechen damit dem Prinzip der intuitiven Bedienung.

Insofern folgt das Dock bei MacOS X der bestechenden Logik der Einfachheit und Konsistenz. Darüber lassen sich keine Fenster schließen, auch nicht die minimierten, sondern nur Programme beenden. D.h. um ein Fenster zu schließen, muß es offen und sichtbar sein. Der Versuch, ein minimiertes Fenster zu schließen, wird somit nicht mit der Frage, ob ich die Änderungen in dem NICHT sichtbaren Fenster speichern möchte, quittiert. Bei Windows läuft es so. Diese Situation tritt unter MacOS X nur ein, wenn ich ein Programm schließe, dessen Fenster minimiert sind. Dann erfolgt die „Wollen Sie Änderungen speichern“-Abfrage ohne das Fenster wieder anzuzeigen. Wie kann ich über etwas entscheiden, das ich nicht sehe?

Die räumliche Zukunft

Grafikadventures gibt es kaum noch, heutzutage sind es eher 3D-Adventures, in denen sich der Spieler mit den Cursortasten durch die Welt bewegt und mit einem radikal reduzierten Befehlsschatz auskommen muß. Ist dies auch eine Entwicklungsrichtung für Betriebssysteme? Durch optische Gestaltung (z.B. Schatten- und Lichtkanten) werden dort seit Jahren räumliche Effekte erzeugt, doch haben alle echten 3D-Versuche bisher nicht überzeugen können.

Die 3D-Welten lassen sich möglicherweise nicht auf die Betriebssysteme übertragen, zumal sich die Strategie der Adventures geändert hat: vom Gegenstände finden und miteinander kombinieren ist es nun eher ein Erkunden der Welt, Reden mit Figuren und einige – deutlich weniger – Manipulation von Gegenständen. Variante eins: der Umgang mit dem Computer besteht immer weniger im Manipulieren (Bewegen etc.) von Dingen, sondern eher in der Reaktion und Interaktion auf geschaffene Computer-Welten. Variante zwei: Möglicherweise wird die von Apple seit System 8 integrierte Spracherkennung weiter verbessert, so daß wir künftig in erster Linie mit dem Rechner reden und weniger zeigen und klicken. [UPDATE, 2010. Variante drei: Apple erfindet ein Zaubergerät namens iPod touch oder iPhone oder iPad, wo es keinen Mauszeiger mehr gibt, und man einfach mit dem Finger direkt die gewünschte Aktion ausführt, beispielsweise ein Icon von einem Ort an einen anderen bewegt.]

Fazit

System-Designer können bei den Designern von Grafikadventures eine Menge lernen. Nur möglichst nicht das „Verzwickte“, daß ich den Schlüssel zum Beispiel nur nehmen kann, wenn ich eine Person ablenke. Aber das Funktionsprinzip basiert darauf, stets den verfügbaren Befehlssatz und die Menge der manipulierbaren Objekte sichtbar darzustellen. Die Aufgabe der Spiele-Designer besteht darin, die Bedienung so effektiv wie möglich zu gestalten und damit das Frust-Potenzial auf Null zu senken, damit die Lösung der Spielaufgaben nicht zur Qual wird. Das Bedien-Interface und dessen Regeln stehen von Anfang an fest und geben den Rahmen vor. Hingegen scheinen System-Designer häufig nur eine Funktion umsetzen zu w/sollen, ohne an Konsistenz und Bedienkomfort zu denken – nicht selten, weil es kein verbindliches Konzept und feste Regeln zur Bedienung gibt.

Der GUI-Guide von Macintosh Anfang der 80er Jahre war da gutes Beispiel; schade, daß ihm viele Softwarefirmen nicht gefolgt sind. Denn das ist unterm Strich das, was das MacOS von manchen anderen Betriebssystemen unterscheidet: es gab ein Konzept und verbindliche Richtlinien (nach den damaligen Erkenntnissen der menschlichen Psyche), bevor überhaupt eine Zeile Code geschrieben wurde. Das Fazit also noch mal in aller Kürze: Erst denken, dann hinterfragen und noch mal denken und erst dann loslegen.

Nachtrag

Natürlich meine ich nicht, daß sich Systeme in jeder Hinsicht an Spielen orientieren sollen. Nur im Blick auf leichte, intuitive Bedienbarkeit, deren Möglichkeiten und Grenzen erkennbar sind. Quietschebuntes Design und fluffige Animationen allerorten sind für Spiele angemessen, jedoch muß ein System anderen Kriterien folgen. Es muß den Fokus auf die zu erledigende Arbeit lenken, dort halten und durch nichts, aber auch wirklich gar nichts davon abzulenken versuchen. Und noch etwas steht auf der Don’t-Liste ganz oben: Adaption. Sicher, das System muß sich den Bedürfnissen anpassen lassen, aber das kann es nun mal nicht selbst entscheiden. Sonst wird es zum pseudo-intelligenten Computergegener, der durch stete Änderung des Systems jedes Vertrauen in Stabilität und Konstanz zu erschüttern weiß.